ERC-8067: NFT Permit Extension for Smart Wallet

ERCs
1

Abstract

This proposal extends ERC-7564 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 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 or ERC-1155 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 interfaces

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. 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.