Token Approvals: The Permissions You Keep Granting

Every time you interact with a DeFi app — swapping on a DEX, depositing into a lending market, bridging an ERC-20 — you almost certainly granted a token approval. Most users sign these in seconds and forget them. Yet that single approve transaction is one of the most consequential things you do on Ethereum: it hands a smart contract standing permission to move your tokens, often without further confirmation. This guide covers what a token approval is, why dApps ask for them, the risks of unlimited allowances, and what this means when you sign approvals through SSP.

Why approvals exist at all

ERC-20 tokens are not stored "in" your wallet the way ETH is. An ERC-20 token contract is a ledger: a mapping from addresses to balances. When you hold 1,000 USDC, what exists on chain is a row in the USDC contract saying your address owns 1,000 units.

Because the balance lives inside the token contract, only that contract can move it. When you send USDC to a friend, your wallet calls the token's transfer function directly.

But a DEX, where a different contract (the router) needs to pull USDC out of your address to execute a swap, cannot reach into the token contract and grab your balance. ERC-20 solves this with a two-step delegation pattern:

1. You call approve(spender, amount) on the token contract. This sets an allowance: a record that the spender is authorized to move up to amount of your tokens.
2. The spender later calls transferFrom(yourAddress, destination, amount) on the token contract. The token contract checks the allowance, decrements it, and moves the tokens.

The approval is the unlock. Without it, the router cannot touch your USDC at all.

What is actually being granted

Read approve(spender, amount) plainly. You are telling the ERC-20 contract: "this address can withdraw up to this many of my tokens, at any time, in any number of transactions, until I change it."

A few things follow:

• Standing permission, not a one-off action. Once granted, the spender does not need your signature again to pull tokens until the allowance is spent down or revoked.
• Per-token. Approving the DEX router for USDC does not let it touch your DAI; you need a separate approval for DAI.
• Per-spender. A different contract — even from the same dApp — has its own allowance.
• No expiry. ERC-20 has no built-in deadline. An allowance set in 2023 is still active in 2026 unless used up or revoked.

You can inspect any allowance on a block explorer like etherscan by reading the token contract's allowance(owner, spender) view function.

The infinite-allowance pattern

If approvals are per-amount, why does almost every DEX prompt you for an enormous number — usually 2^256 - 1, displayed as "unlimited" or MaxUint256 — instead of just the amount you are swapping?

The answer is UX and gas. If a DEX requested a fresh allowance equal to the trade size on every swap, you would pay an approval transaction every time and confirm two transactions for what feels like one action. Asking for an unlimited allowance once lets you swap freely afterwards with one transaction per trade.

It is genuinely convenient. It is also genuinely riskier. An unlimited allowance means the spender contract is permitted to drain your entire current balance of that token — and any future balance — at any moment, without you signing anything else.

For a well-known, audited, immutable contract, the practical risk is usually low. For a freshly-deployed dApp, an upgradeable proxy, or an unknown contract, an unlimited allowance is a much larger surface than the trade you intended.

The real risk: a standing key to your tokens

The danger of approvals is not the approval transaction itself. It is what happens after. Consider a few scenarios:

• The spender contract has a bug. An attacker exploits its transferFrom logic, and every wallet with a non-zero allowance is drained.
• The spender contract is upgradeable. Whoever controls the upgrade keys pushes new logic that pulls tokens from anyone with an active allowance.
• You approved a malicious clone. A phishing site mimicked a real dApp's URL, and the contract you approved was attacker-controlled all along.
• The spender's signing keys are compromised. The official contract is fine; the operator's wallet was not, and approvals are exercised by an intruder.

In every case, you do not sign anything when the drain happens. The approval granted weeks earlier is the only authorization the attacker needs. "Approve only what you need, and revoke what you no longer use" is not paranoia; it is the same principle as not leaving spare house keys with every contractor you have ever hired.

How approvals quietly accumulate

A wallet active for a year or two in DeFi has accumulated dozens of approvals: every DEX, every aggregator, every lending market deposit, every NFT marketplace, every bridge. Users almost never revoke. The result is a long tail of standing permissions, many of them unlimited, many granted to contracts the user no longer interacts with.

This is the silent attack surface. It does not show up in any single transaction; it is the cumulative residue of normal use. Auditing and pruning that list is one of the most effective security habits in self-custody — the next article covers exactly how in revoking token approvals from SSP.

A newer pattern: EIP-2612 permit

ERC-20 predates much of modern DeFi, and the two-transaction approve-then-swap dance has long been awkward. EIP-2612 introduced an alternative for tokens that opt in: instead of sending an approve transaction on chain, the user signs an off-chain message (a permit) authorizing a specific spender, amount, and deadline. The dApp submits that signature along with the swap in a single transaction.

permit is gas-efficient, scoped (it carries an explicit amount and expiry), and harder to leave dangling because the deadline forces it to expire. Not every ERC-20 supports it — USDC and DAI do, many older tokens do not — but where available it is generally safer than a long-lived approve allowance. That said, permit signatures can themselves be phished: a malicious site asking you to "sign in" can slip a permit underneath. Read what you are signing.

What this means inside SSP

SSP is a self-custodial 2-of-2 multisig wallet: every on-chain transaction is co-signed by the SSP browser extension and the SSP Key mobile app. On Ethereum and the EVM networks SSP supports (Polygon, Base, BNB Smart Chain, Avalanche), this is implemented as an ERC-4337 smart account with a Schnorr-aggregated signature — but at the application layer, an approval looks like any other transaction.

A few things to keep in mind:

• An approval is a transaction your 2-of-2 must co-sign. When a dApp prompts for approve, SSP surfaces it like any other tx. You see the spender address and requested amount on both devices before confirming.
• Once granted, the spender does not need SSP to act again. The multisig protects the moment of approval, not the standing permission afterwards. If you approve an unlimited allowance to a malicious contract, your multisig will not save you from the eventual drain.
• Watch the spender address. dApps occasionally upgrade routers; if the spender on the approval screen does not match the contract you expect, stop and verify.
• WalletConnect-initiated approvals look the same. Whether a dApp prompts in-page or via WalletConnect, the flow and risks are identical.

Habits worth building

A few concrete practices keep the approval surface manageable:

• Prefer the smallest workable allowance. When a dApp offers "exact amount" vs. "unlimited," exact is the safer default for contracts you do not regularly use.
• Treat unlimited approvals as commitments. Reserve them for a small set of contracts you trust and use often. For everything else, scope.
• Audit periodically. Once a quarter, list your active approvals on each chain and revoke anything you no longer use. Tools like revoke.cash make this routine.
• Be wary of unfamiliar dApps. A new protocol with no audit history asking for an unlimited allowance is the highest-risk combination in DeFi.
• Protect the keys that grant approvals. SSP's multisig raises the bar, but standard hygiene still applies — see seed phrase best practices.

The mental model to take away

A token approval is not a click; it is a key. Each one stays in the lock until you remove it, and each one grants its holder the ability to move tokens you have not yet earned. Used with care, allowances are the plumbing that lets DeFi work. Treated as throwaway clicks, they are the slow accumulation of risks you forgot you took on.

Understand the permission you are granting, prefer scoped grants where the dApp allows it, and prune your standing approvals on a schedule. For deeper protocol details, the ERC-20 standard documentation on ethereum.org is the canonical reference. New to SSP on Ethereum? Our Ethereum in SSP guide covers the basics.