Add EIP-5827: Auto-renewable allowance extension

EIPS/eip-5827.md

@@ -0,0 +1,106 @@
+---
+eip: 5827
+title: Auto-renewable allowance extension
+description: Extension to enable automatic renewals on allowance approvals
+author: zlace (@zlace0x), zhongfu (@zhongfu), edison0xyz (@edison0xyz)
+discussions-to: https://ethereum-magicians.org/t/eip-5827-auto-renewable-allowance-extension/10392
+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-10-22
+requires: 20, 165
+---
+
+## Abstract
+
+This extension adds a renewable allowance mechanism to [EIP-20](./eip-20.md) allowances, in which a `recoveryRate` defines the amount of token per second that the allowance regains towards the initial maximum approval `amount`.
+
+## Motivation
+
+Currently, EIP-20 supports 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 DCA 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 giving an 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.
+
+```solidity
+interface IERC5827 {
+    /// @notice Emitted when a new allowance is set
+    /// @param _owner owner of token
+    /// @param _spender allowed spender of token
+    /// @param _value   initial and maximum allowance given to spender
+    /// @param _recoveryRate recovery amount per second
+    event SetRenewableAllowance(
+        address indexed _owner,
+        address indexed _spender,
+        uint256 _value,
+        uint192 _recoveryRate
+    );
+
+    /// @notice grants an allowance of _value to _spender initially, which recovers over time based on _recoveryRate up to a limit of _value
+    /// SHOULD throw when _recoveryRate is larger than _value
+    /// MUST emit SetRenewableAllowance event
+    /// @param _spender allowed spender of token
+    /// @param _value   initial and maximum allowance given to spender
+    /// @param _recoveryRate recovery amount per second
+    function approve(
+        address _spender,
+        uint256 _value,
+        uint192 _recoveryRate
+    ) external returns (bool success);
+
+    /// @notice Moves `amount` tokens from `from` to `to` using the
+    /// allowance mechanism. `amount` is then deducted from the caller's
+    /// allowance factoring in recovery rate logic.
+    /// SHOULD throw when there is insufficient allowance
+    /// @param from token owner address
+    /// @param to token recipient
+    /// @param amount amount of token to transfer
+    function transferFrom(
+        address from,
+        address to,
+        uint256 amount
+    ) external returns (bool);
+
+    /// @notice fetch amounts spendable by _spender
+    /// @return remaining allowance at the current point in time
+    function allowance(address _owner, address _spender)
+        external
+        view
+        returns (uint256 remaining);
+
+    /// @notice fetch approved max amount and recovery rate
+    /// @return amount initial and maximum allowance given to spender
+    /// @return recoveryRate recovery amount per second
+    function renewableAllowance(address _owner, address _spender)
+        external
+        view
+        returns (uint256 amount, uint192 recoveryRate);
+}
+```
+
+Base method `approve(address _spender, uint256 _value)` MAY emit `SetRenewableAllowance` with a `recoveryRate` of 0.
+
+Both `allowance()` and `transferFrom()` MUST be updated to include allowance recovery logic.
+
+## 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 EIP-20 token contracts can delegate allowance enforcement to a proxy contract that implements this specification.
+
+## Security Considerations
+
+This EIP introduces a stricter set of constraints compared to EIP-20 with unlimited allowances. However, when `_recoveryRate` is set to a large value, large amounts can still be transferred over multiple transactions.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).
+