Add EIP-6077: Invalidation for Signature-Based Operations

EIPS/eip-6077.md

@@ -0,0 +1,75 @@
+---
+eip: 6077
+title: Invalidation for Signature-Based Operations
+description: Extends EIP-712 and unifies EIP-2612 with many others
+author: Anton Bukov (@k06a), Mikhail Melnik (@zumzoom)
+discussions-to: https://ethereum-magicians.org/t/eip-6077-invalidation-abstraction-for-signature-based-operations/12162
+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-12-02
+requires: 712, 2612
+---
+
+## Abstract
+
+This EIP extends [EIP-712](./eip-712.md) and defines two methods to validate and invalidate signature-based operations, such as [EIP-2612](./eip-20.md)'s permit operation. This EIP provides two ways to track such operations and invalidate them:
+
+- main sequnce of incremental nonces per signer
+- sequence of incremental ids per signer per beneficiary
+
+## Motivation
+
+Same abstraction could be utilized by mutilple signature-based operations, moreover existing EIPs like [EIP-2612](./eip-2612.md) could be considered as fully compatible with the EIP.
+
+Multiple EIPs define operations that can be executed in behalf of signer and sometime introduce method naming collisions and other. For example, [EIP-2612](./eip-2612.md) defines both `permit` and `nonces` methods, but gives no clue that `nonces` is related to permit operation. In case of multiple same-level EIPs implemented within one smart contract (for example: permit, delegate, vote) it's obvious that they should use different nonces.
+
+## 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 and RFC 8174.
+
+- Smart contract implementing EIP-712 MUST also implement the following interface:
+
+    ```solidity
+    interface ISignatureOperations {
+        /// @dev Returns next nonce for the signer in the context of the operation typehash and operation beneficiary
+        /// @param typehash The operation typehash
+        /// @param signer The signer address
+        function operationNonces(bytes32 typehash, address signer) external view returns (uint256);
+
+        /// @dev Returns next id for the signer in the context of the operation typehash and operation beneficiary
+        /// @param typehash The operation typehash
+        /// @param signer The signer address
+        /// @param beneficiary The address of the spender, delegate, or other beneficiary of the transaction
+        function operationIds(bytes32 typehash, address signer, address beneficiary) external view returns (uint256);
+
+        /// @dev Increments nonce for the caller in the context of the operation typehash and operation beneficiary
+        /// @param typehash The operation typehash
+        /// @param nonce The operation nonce
+        function useOperationNonce(bytes32 typehash, uint256 nonce) external;
+
+        /// @dev Increments id for the caller in the context of the operation typehash and operation beneficiary
+        /// @param typehash The operation typehash
+        /// @param beneficiary The address of the spender, delegate, or other beneficiary of the transaction
+        /// @param id The operation nonce
+        function useOperationIds(bytes32 typehash, address beneficiary, uint256 id) external;
+    }
+    ```
+
+- Operation EIPs SHOULD use at leat one of the nonces or ids sequences per signer defined by this EIP or both.
+
+## Rationale
+
+TBD
+
+## Backwards Compatibility
+
+Fully backward compatibile with EIP-712.
+
+## Security Considerations
+
+TBD
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).