Token Approval

What Is a Token Approval?

A token approval is a transaction on an EVM-compatible blockchain that grants a specific smart contract permission to transfer up to a certain number of tokens from your address. The mechanism is fundamental to how DeFi protocols work: before a DEX, lending protocol, or yield aggregator can move your tokens, you must first approve it to do so.

This two-step pattern exists because of how the ERC-20 standard is designed. Unlike sending ETH directly in a transaction, ERC-20 tokens live inside a token contract that tracks balances in an internal ledger. A smart contract cannot simply "take" your tokens: it must call the token contract's transferFrom function, which checks whether you previously granted a sufficient allowance.

The approval itself does not move any tokens. It only updates the token contract's internal records to note that "address A has permitted contract B to spend up to N tokens on A's behalf." The actual transfer happens later, when the contract calls transferFrom.

How It Works

The ERC-20 standard defines three functions that power the approve/transferFrom pattern:

// Grant spender permission to transfer up to 'amount' of your tokens
function approve(address spender, uint256 amount) external returns (bool);

// Check how much 'spender' is still allowed to transfer from 'owner'
function allowance(address owner, address spender) external view returns (uint256);

// Move tokens from 'from' to 'to' (requires prior approval)
function transferFrom(address from, address to, uint256 amount) external returns (bool);

Under the hood, the token contract stores approvals in a nested mapping:

mapping(address owner => mapping(address spender => uint256 amount)) private _allowances;

A typical DeFi interaction follows this sequence:

1. You call approve(dexContract, 1000e18) on the token contract, authorizing the DEX to spend up to 1,000 of your tokens
2. You call the DEX's swap() function with your trade parameters
3. Inside swap(), the DEX calls token.transferFrom(you, pool, amount)
4. The token contract checks that _allowances[you][dex] is greater than or equal to amount, then transfers the tokens and decrements the allowance

Each approval requires a separate on-chain transaction with its own gas fee. This is why swapping a token for the first time on a DEX requires two wallet confirmations: one for the approval and one for the swap itself.

The Infinite Approval Problem

Many DeFi protocols request an allowance of type(uint256).max (2^256 - 1): effectively unlimited. This is marketed as a convenience because you only need to approve once and can interact with the protocol repeatedly without paying for additional approval transactions.

The tradeoff is security. An unlimited approval means the contract can drain your entire balance of that token at any time, not just the amount you intended to trade. If the contract has a vulnerability, or if its owner upgrades it to include a malicious function, every wallet that granted unlimited approval is at risk.

The Approve Front-Running Vulnerability

The approve function has a known race condition. If you change an existing allowance (say from 100 to 50 tokens), the spender can front-run your transaction:

1. You have an existing allowance of 100 tokens to a spender
2. You submit a transaction to reduce it to 50
3. The spender sees your pending transaction in the mempool and quickly spends the original 100 tokens with a higher gas price
4. Your approval transaction confirms, setting the allowance to 50
5. The spender now spends another 50, getting 150 total instead of 50

The standard mitigation is to first set the allowance to zero, then set it to the new value in a second transaction. OpenZeppelin's SafeERC20 library provides safeIncreaseAllowance and safeDecreaseAllowance functions that handle this safely.

Newer Approval Standards

EIP-2612: Permit

Finalized in 2020, EIP-2612 adds a permit function to ERC-20 tokens. Instead of sending an on-chain approval transaction, the token holder signs an off-chain message (using the EIP-712 typed structured data standard) authorizing the spender. The signature is then submitted alongside the actual operation in a single transaction.

function permit(
    address owner,
    address spender,
    uint256 value,
    uint256 deadline,
    uint8 v, bytes32 r, bytes32 s
) external;

The deadline parameter ensures signatures expire, preventing stale approvals from being replayed. USDC, DAI, and most ERC-20 tokens deployed since 2021 support EIP-2612 natively. The result is a single transaction where the user pays gas only once, combining approval and action into one step.

Uniswap Permit2

Permit2, introduced by Uniswap, extends gasless approvals to any ERC-20 token, even those without native permit support. Users grant a one-time traditional approval to the Permit2 contract, and from that point forward, every application authorization happens via off-chain EIP-712 signatures with built-in expiration times.

This centralizes approval management: instead of granting separate allowances to dozens of DeFi contracts, you approve Permit2 once per token and control per-application access through time-bounded signatures. If you stop using an application, its authorization automatically expires without requiring a revocation transaction.

Use Cases

Token approvals are required for virtually every DeFi interaction that moves your tokens:

• Swapping tokens on a DEX: the router contract needs approval to pull your input tokens
• Depositing into a lending protocol: the lending contract needs approval to transfer your collateral
• Providing liquidity to an AMM pool: the pool contract needs approval for each token you deposit
• Bridging tokens cross-chain: the bridge contract needs approval to lock or burn your tokens on the source chain
• Staking in a rewards contract: the staking contract needs approval to transfer your tokens into its custody

Risks and Considerations

Exploited Contracts Drain Approved Wallets

The most severe risk of token approvals is that a compromised or vulnerable contract can steal tokens from every wallet that approved it. Approvals persist indefinitely unless revoked, so a contract you interacted with months ago can still access your tokens.

Notable incidents demonstrate the scale of this risk. In 2024, the Li.Fi protocol lost $9.7 million when attackers exploited a contract vulnerability: only wallets with infinite approvals were affected. SenecaUSD lost $6.5 million and SocketDotTech (Bungee) lost $3.3 million through similar approval-based attacks the same year. These exploits share a pattern: attackers find a way to call transferFrom against users who granted excessive allowances.

Phishing and Malicious Approvals

Scammers build fake DeFi frontends that prompt users to sign approval transactions granting unlimited allowances to attacker-controlled contracts. Because the approval transaction looks routine (it does not move tokens immediately), many users confirm without reading the details. The attacker then drains the approved tokens at their convenience.

Best Practices

• Approve exact amounts rather than unlimited: if you are swapping 500 USDC, approve exactly 500 USDC instead of the maximum uint256 value
• Regularly audit and revoke unused approvals using tools like Revoke.cash, which supports over 100 EVM-compatible networks
• Prefer protocols that support EIP-2612 permits or Permit2, which include built-in expiration mechanisms
• Review every approval transaction carefully in your wallet before confirming: check which contract address is being approved and for how much
• Use a smart contract audit as a signal of trust, but remember that even audited contracts can contain undiscovered vulnerabilities or be upgraded maliciously

Token Approvals vs. Bitcoin's UTXO Model

Token approvals are a concept specific to account-model blockchains like Ethereum. Bitcoin's UTXO (Unspent Transaction Output) model works fundamentally differently: there is no shared balance that multiple contracts can draw from. Each UTXO is a discrete coin that can only be spent by providing a valid signature in a transaction. There is no equivalent to "approve contract X to spend my Bitcoin" because Bitcoin transactions consume UTXOs atomically.

This architectural difference means that Bitcoin and Bitcoin Layer 2 protocols like Spark are not susceptible to approval-based exploits. Users of the UTXO model never need to worry about revoking stale permissions or auditing outstanding allowances. For a deeper comparison of these two models, see the research article on UTXO model vs. account model.

Frequently Asked Questions

What happens if I don't revoke an old approval?

The approval remains active indefinitely. If the approved contract is later compromised through a vulnerability or malicious upgrade, the attacker can call transferFrom to drain your approved tokens at any time. Regularly reviewing and revoking unused approvals is an important part of wallet security hygiene.

Does revoking an approval cost gas?

Yes. Revoking is simply setting the allowance to zero by calling approve(spender, 0), which requires an on-chain transaction and a small gas fee. This is one reason unlimited approvals persist: users are reluctant to pay to revoke permissions they granted for free interactions.

Can a token approval steal my ETH?

No. ERC-20 approvals only apply to the specific token contract you approved. They cannot touch your ETH balance or other tokens. However, a malicious transaction can combine a token approval with other actions, so always verify what you are signing.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.