Approval Standard

The standard defines a core ApprovalManager contract that delegates permission logic to separate, pluggable ApprovalModule contracts. This allows developers to implement custom approval policies (e.g., spending limits, multi-signature, time-locks) without modifying the core asset contract. Modules can be composed and swapped, enabling flexible and upgradeable security models.

Approvals are no longer simple binary allowances. The standard enables permissions based on specific contexts, such as:

• Spender: Which contract or address can act.
• Asset: The specific token or NFT (by contract address and token ID).
• Amount/Quantity: A precise maximum value.
• Expiry: A block timestamp or number when the approval becomes invalid. This prevents over-permissioning and limits the blast radius of compromised approvals.

All approvals are registered and managed on-chain through the ApprovalManager, creating a single, verifiable source of truth. This enables:

• Universal Revocation: Users can revoke all approvals for a compromised spender in a single transaction.
• Discovery & Auditing: Wallets and explorers can query the registry to display a user's complete approval state across all supported assets.
• Standardized Interfaces: A consistent IERC7579 interface for all compliant approvals.

ERC-7579 is designed to work alongside, not replace, existing token standards like ERC-20 and ERC-721. It acts as a middleware layer. Asset contracts remain simple, while the ApprovalManager handles complex permission logic. This ensures backward compatibility and allows dApps to adopt the standard incrementally.

The standard introduces robust security primitives:

• Batch Revocation: Revoke approvals for multiple spenders or assets in one call.
• Delegate Call Protection: ApprovalModules are executed via delegatecall within a secure, isolated context in the ApprovalManager to prevent storage collisions and external manipulation.
• Clear Event Logging: Standardized ApprovalSet and ApprovalRemoved events provide transparent on-chain records for monitoring and indexing.

The standard improves the experience for both developers and end-users:

• For Developers: A unified API for managing approvals across any asset type, reducing integration complexity.
• For Users: Wallets can build intuitive dashboards showing all active approvals, with easy one-click management and revocation. This directly addresses the problem of approval fatigue and forgotten permissions.

A common practice where users grant an unlimited allowance (e.g., 2^256 - 1) to avoid repeated transaction fees. This introduces significant security risks:

• Dormant Risk: A compromised or malicious spender contract can drain the entire approved token balance at any time.
• Principle of Least Privilege: Violates this security best practice. Users are advised to use allowance revocations (approve(spender, 0)) or time-bound approvals to mitigate risk.

Major DeFi protocols build upon base approval standards with custom logic:

• Uniswap & AMMs: Use approvals for adding/removing liquidity and swapping tokens via their router contracts.
• Lending Protocols (Aave, Compound): Require approvals to deposit collateral (supply) and often use approve + permit for efficient debt management.
• Aggregators (1inch): Use approvals to access funds for finding and executing optimal trade routes across multiple DEXs.

The traditional method for token allowances, defined in the original ERC-20 standard. It requires two transactions:

• First transaction: The token holder calls approve(spender, amount) to grant an allowance.
• Second transaction: The approved spender calls transferFrom(owner, recipient, amount) to move the tokens. This model introduces UX friction and security risks, such as allowance front-running, which the Approval Standard aims to solve.

A foundational standard for typed structured data hashing and signing. The Approval Standard (EIP-2612) builds directly upon EIP-712. It allows users to sign a human-readable permit message off-chain, which includes:

• The token contract address
• The approved spender
• The allowance amount
• A deadline for the permit This signature can then be submitted by any relayer, enabling gasless transactions.

A transaction pattern where a user signs a message off-chain, and a third-party relayer pays the gas fees to submit it on-chain. The Approval Standard is a key enabler for this pattern for token transfers. Other related mechanisms include:

• Gas Station Network (GSN): A decentralized system for sponsoring transaction gas.
• ERC-2771: A standard for secure meta-transactions with trusted forwarders. These patterns improve user onboarding by abstracting away the need for native gas tokens.

A related concept where token holders delegate voting power without transferring assets. Governed by standards like ERC-20Votes and ERC-6372, this uses a similar signature-based model for gasless delegation. Key differences from the Approval Standard:

• Purpose: Delegates voting power, not spending authority.
• State: Tracks a historical checkpoint of delegated votes for each block.
• Revocation: Often involves a new delegation transaction rather than setting an allowance to zero.

Best practices and tools for mitigating risks associated with token approvals, which apply to both traditional ERC-20 and permit-based systems.

• Infinite Allowance Risks: Granting unlimited (type(uint256).max) approval can lead to total fund loss if the spender contract is compromised.
• Revocation: Users must actively revoke allowances they no longer need.
• Approval Scanners: Tools like Revoke.cash and Etherscan's Token Approval Checker help users audit and manage active allowances across protocols.

A companion standard to EIP-2612 that extends the permit pattern beyond allowances to direct token transfers. It allows a user to sign an authorization for a one-time transfer of tokens to a specific recipient. This is useful for:

• Gasless payments: Paying for services without holding gas.
• Batch processing: Pre-authorizing multiple transfers to be executed later. Like EIP-2612, it uses EIP-712 signatures and includes a nonce and expiry to prevent replay attacks.