ERC-5827: Auto-renewable allowance extension

Extension to enable automatic renewals on allowance approvals

Metadata

Status: StagnantStandards Track: ERCCreated: 2022-10-22

Authors

zlace (@zlace0x), zhongfu (@zhongfu), edison0xyz (@edison0xyz)

Requires

EIP-20, EIP-165

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This extension adds a renewable allowance mechanism to ERC-20 allowances, in which a recoveryRate defines the amount of token per second that the allowance regains towards the initial maximum approval amount.

Motivation

Currently, ERC-20 tokens support allowances, with which token owners can allow a spender to spend a certain amount of tokens on their behalf. However, this is not ideal in circumstances involving recurring payments (e.g. subscriptions, salaries, recurring direct-cost-averaging purchases).

Many existing DApps circumvent this limitation by requesting that users grant a large or unlimited allowance. This presents a security risk as malicious DApps can drain users' accounts up to the allowance granted, and users may not be aware of the implications of granting allowances.

An auto-renewable allowance enables many traditional financial concepts like credit and debit limits. An account owner can specify a spending limit, and limit the amount charged to the account based on an allowance that recovers over time.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Base method approve(address _spender, uint256 _value) MUST set recoveryRate to 0.

Both allowance() and transferFrom() MUST be updated to include allowance recovery logic.

approveRenewable(address _spender, uint256 _value, uint256 _recoveryRate) MUST set both the initial allowance amount and the maximum allowance limit (to which the allowance can recover) to _value.

supportsInterface(0x93cd7af6) MUST return true.

Additional interfaces

Token Proxy

Existing ERC-20 tokens can delegate allowance enforcement to a proxy contract that implements this specification. An additional query function exists to get the underlying ERC-20 token.

The transfer() function on the proxy MUST NOT emit the Transfer event (as the underlying token already does so).

Automatic Expiration

Rationale

Renewable allowances can be implemented with discrete resets per time cycle. However, a continuous recoveryRate allows for more flexible use cases not bound by reset cycles and can be implemented with simpler logic.

Backwards Compatibility

Existing ERC-20 token contracts can delegate allowance enforcement to a proxy contract that implements this specification.

Reference Implementation

An minimal implementation is included here

An audited, open source implemention of this standard as a IERC5827Proxy can be found at https://github.com/suberra/funnel-contracts

Security Considerations

This EIP introduces a stricter set of constraints compared to ERC-20 with unlimited allowances. However, when _recoveryRate is set to a large value, large amounts can still be transferred over multiple transactions.

Applications that are not ERC-5827-aware may erroneously infer that the value returned by allowance(address _owner, address _spender) or included in Approval events is the maximum amount of tokens that _spender can spend from _owner. This may not be the case, such as when a renewable allowance is granted to _spender by _owner.