--- eip: 8067 title: NFT Permit Extension for Smart Wallet description: EIP-712 permit extension enabling NFT approval and operator authorization for ERC-7564 smart contract wallets author: Xiang (@wenzhenxiang) discussions-to: https://ethereum-magicians.org/t/eip-8067-contract-wallet-management-nft-permit-extensions/25990 status: Draft type: Standards Track category: ERC created: 2025-10-29 requires: 165, 712, 1271, 7564 --- ## Abstract This proposal extends [ERC-7564](./eip-7564.md) NFT manager modules with an off-chain permit flow for approvals. It introduces nonce-tracked `nftPermit`, `nftPermitForOne`, and `nftPermitForAll` functions, enabling individual token approvals and operator approvals (both per-asset and global) to be set via typed-data signatures presented by relayers. The extension defines canonical [EIP-712](./eip-712.md) schemas, nonce accounting, and execution requirements for compliant implementations. ## Motivation ERC-7564 equips smart wallets with an on-chain permissions framework for NFTs, but every interaction still requires the wallet contract to submit its own transaction. Users must maintain gas balances, and dApps that want gasless marketplace listings or delegated staking access resort to bespoke signature formats that do not interoperate. Introducing a standard permit flow allows the wallet owner to sign once off-chain while a dApp or relayer later submits the operation on-chain and pays gas for the user. This enables: - universal coverage for any [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md) asset managed by the wallet's NFT module; - interoperable tooling because wallets, marketplaces, and relayers share one EIP-712 schema and nonce model. the ERC-7564 permit extension allows NFT dApps to provide gasless, permissioned operations through a unified standard instead of fragmented, project-specific signatures. This proposal extends ERC-7564 directly to introduce a canonical EIP-712 permit flow within the existing NFT management model. By defining scoped nonces and standardized typed-data structures, it enables interoperable off-chain approvals without introducing a separate approval mechanism or fragmenting wallet integrations. ## 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. **Compliant contract must implement the [ERC-165](./eip-165.md) interfaces** ```solidity interface IERC8067 { /// @notice Returns the current nonce for individual token approvals function nftApproveNonce(address asset, uint256 tokenId, address operator) external view returns (uint256); /// @notice Returns the current nonce for per-asset operator approvals function nftApprovalForOneAllNonce(address asset, address operator) external view returns (uint256); /// @notice Returns the current nonce for global operator approvals function nftApprovalForAllAllNonce(address operator) external view returns (uint256); /// @notice Sets individual token approval via off-chain signature function nftPermit( address asset, address operator, uint256 tokenId, uint256 deadline, bytes calldata signature ) external returns (bool success); /// @notice Sets or revokes per-asset operator status via off-chain signature function nftPermitForOne( address asset, address operator, bool approved, uint256 deadline, bytes calldata signature ) external returns (bool success); /// @notice Sets or revokes global operator status via off-chain signature function nftPermitForAll( address operator, bool approved, uint256 deadline, bytes calldata signature ) external returns (bool success); } ``` All functions MUST mirror the behaviour of their on-chain ERC-7564 counterparts once the signature is accepted. Implementations MUST support wallets that verify signatures through [ERC-1271](./eip-1271.md). If a wallet wraps signatures, the module MUST unwrap them before verification. ### Typed-Data Each function MUST hash one of the following primary types before invoking the wallet's signature validation logic. The `wallet` field identifies the smart wallet executing the module. In all payloads `nonce` is the value returned by the corresponding nonce view function. | Function | Primary Type | Fields | |----------|--------------|--------| | `nftPermit` | `NFTPermit` | `wallet`, `asset`, `operator`, `tokenId`, `nonce`, `deadline` | | `nftPermitForOne` | `NFTPermitForOne` | `wallet`, `asset`, `operator`, `approved`, `nonce`, `deadline` | | `nftPermitForAll` | `NFTPermitForAll` | `wallet`, `operator`, `approved`, `nonce`, `deadline` | Every permit MUST use the following domain values: - `name = "NFTManager Permit"` - `version = "1"` - `chainId` = the executing chain - `verifyingContract = address(this)` ### Nonce Semantics - Nonces MUST be scoped as described in the interface. - Each permit function MUST increment its corresponding nonce immediately before other state changes and MUST revert on replay. ### Execution Requirements Implementations MUST follow these rules when processing a permit: 1. Treat `deadline == 0` as non-expiring; otherwise require `block.timestamp <= deadline`. 2. Recover the signer from the EIP-712 digest. If the recovered address is a contract, validate the digest using ERC-1271 on the wallet address. The recovered/validated signer MUST equal the wallet owner. 3. Implementations MUST increment the nonce before calling external token contracts so that reverts cannot reopen a signature. 4. Verify the provided nonce matches the current stored nonce for the corresponding scope. 5. Increment the scoped nonce before invoking the underlying ERC-7564 approval function. 6. Emit the same events as the corresponding ERC-7564 functions. 7. Revert on any validation failure or if the downstream approval call reverts. Wallets MAY expose additional permit helpers, but they MUST NOT change the semantics defined above. ## Rationale ERC-7564 already defines approval functions for NFT managers inside smart wallets. The permit extension mirrors those entry points so that wallets can capture the same behaviour with off-chain signatures: - The shared domain name enables reusable tooling while remaining specific to NFT managers. - Reusing existing ERC-7564 methods after verification keeps events and downstream integrations unchanged. ## Backwards Compatibility Existing ERC-7564 modules remain valid. Clients shoukd detect permit support via ERC-165 or by probing for the new function selectors. ## Security Considerations - Wallets should bound permit validity windows and monitor outstanding `approved = true` operator signatures to limit abuse. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).