Allowance

Platforms like Aave and Compound require allowances to deposit collateral or supply assets to their liquidity pools. Granting an allowance to the protocol's core contract lets it custody your tokens, minting a derivative (like aTokens or cTokens) in return. This is also required for flash loans, where the borrower must approve the repayment amount to the lending contract within the same transaction.

• Key Use: Enabling collateralization and yield generation.
• Risk: A malicious or exploited contract could drain funds up to the allowance limit.

The ERC-20 Permit standard eliminates the need for a separate approve transaction. Instead, users sign a structured message (EIP-712) offline, granting an allowance. The spender submits this signature to a contract, which can then execute the allowance and the subsequent action (e.g., a swap) in one transaction.

• Benefit: Saves gas, improves UX, and enhances security by avoiding front-running on the approval.
• Adoption: Used by tokens like USDC and DAI, and integrated into wallets like MetaMask.

For ERC-20 tokens used as currency (e.g., WETH, USDC), NFT marketplaces like OpenSea require an allowance to facilitate purchases. For ERC-721/ERC-1155 NFTs themselves, a different mechanism—setApprovalForAll or approve—is used to grant listing rights.

In NFT staking or yield farming, you grant an allowance to a staking contract for the LP tokens or NFTs you wish to deposit, allowing it to lock them on your behalf in exchange for rewards.

Users often grant infinite (unlimited) allowances (e.g., 2^256 - 1) for convenience, eliminating the need for repeated approvals. However, this poses a significant security risk if the approved contract is compromised.

Finite allowances specify a exact maximum amount, offering better security but requiring more transactions. Best practices now encourage:

• Revoking unused allowances via approve(spender, 0).
• Using allowance management tools like revoke.cash to audit and reset permissions.
• Preferring permit signatures or gasless meta-transactions where possible.

When using cross-chain bridges (e.g., Across, Hop), you grant an allowance to the bridge's deposit contract on the source chain. This allows it to take custody of your tokens, lock or burn them, and mint a representation on the destination chain.

Similarly, layer-2 rollups often require allowances for depositing funds into their bridge contracts (e.g., Arbitrum's L1GatewayRouter). The allowance mechanism ensures the bridge can only move the specific, user-authorized amount.

The security of an allowance is only as strong as the spender contract it is granted to. A malicious or buggy spender can exploit its allowance beyond the user's intent. Common issues include:

• Logic flaws allowing unauthorized withdrawals.
• Upgradeable contracts where a malicious upgrade changes behavior.
• Centralization risks where the spender's owner has excessive control.

Users must audit or trust the spender's code and governance.

ERC-20 (fungible token) allowances grant a spending limit (uint256), while ERC-721 (NFT) allowances are typically granted for specific token IDs via approve() or for an operator to manage all NFTs via setApprovalForAll(). The risks differ:

• setApprovalForAll: Grants sweeping control over all current and future NFTs in a collection, an extreme risk.
• Specific approve: Lower risk but still requires vigilance for the approved token ID.

NFT marketplaces commonly request setApprovalForAll for UX, creating significant exposure.

The ERC-20 standard introduced the canonical approve and allowance model, enabling a token holder to authorize a third-party spender (like a DEX) to transfer a specific amount of tokens on their behalf. This is stored in a mapping: allowance[owner][spender]. While revolutionary, its basic design has limitations, such as the need for separate approvals per spender and the risk of front-running with approve.

ERC-2612 (Permit) extends ERC-20 by allowing users to approve token spending via off-chain EIP-712 signed messages instead of on-chain transactions. A user signs a structured message containing the spender and amount, which the spender can then submit to the contract. This enables:

• Gasless onboarding: Users can interact with dApps without holding native gas tokens.
• Batch operations: Combine approval and action (like a swap) in a single transaction, improving UX and reducing costs.

ERC-777 introduces the concept of operators—trusted entities authorized to send tokens on a user's behalf. Unlike ERC-20's fixed-amount allowance, operators can be authorized or revoked for all tokens. It also features:

• Hooks: Contracts can implement tokensToSend and tokensReceived for granular control over transactions.
• Backward Compatibility: ERC-777 tokens are also ERC-20 compliant. This standard provides more powerful delegation mechanics but requires careful implementation to avoid vulnerabilities.

ERC-1363 defines a payable token standard that allows tokens to notify a receiving contract after a transfer, similar to how ETH payments work. It adds transferAndCall and approveAndCall functions. After a transfer, the token contract calls a specific function on the recipient, enabling:

• Atomic interactions: A single transaction can pay for a service and trigger its execution (e.g., buying an NFT).
• Simplified logic: Removes the need for separate approve and subsequent call transactions, streamlining processes like subscription payments.

ERC-5827 introduces renewable allowances, where an approved spending limit automatically replenishes over time based on a defined rate. Instead of a static allowance amount, it sets parameters like:

• Max amount: The ceiling for the allowance.
• Recovery rate: How many tokens per second are added back to the available allowance. This model is ideal for streaming payments, subscriptions, and delegated vault management, providing continuous authorization without frequent manual approve transactions.

ERC-3009 generalizes the permit idea for direct transfers, not just approvals. A user can sign an authorization for a specific transfer (amount, recipient, deadline), which any party can then execute. Key features include:

• Meta-transactions: Enables gas abstraction for token transfers themselves.
• Replay protection: Uses a nonce per user to prevent signature reuse.
• Batch transfers: Multiple signed authorizations can be executed in one transaction. This standard decouples the signer from the transaction submitter, enabling sophisticated relay services.