What Is a Token Approval?

Key Takeaways

A token approval is a permission slip, not a payment. Calling the ERC-20 approve(spender, amount) function tells a token's smart contract that a specific address is allowed to move up to a set amount of that token out of your wallet, whenever it chooses, without asking you to sign again. Nothing moves at the moment you approve; the approval only becomes a transfer later, when the spender calls a separate function. Understanding that gap — between granting permission and something actually happening with it — is the single most important idea in this guide and the foundation for everything else in Swoopr's Token Approvals & Blind Signing series.

Direct answer: A token approval is an on-chain permission, created by calling a token contract's approve(spender, amount) function, that lets a specific address — typically a smart contract such as a DEX router or lending protocol — pull up to amount of that token from your wallet without needing a fresh signature each time. It doesn't move any funds by itself; it only authorizes a future transfer that the approved spender may or may not ever execute.

• Approving a token is a separate, prior transaction to the swap, deposit, or stake it's meant to enable — not part of the same action.
• Approvals exist because smart contracts have no built-in way to reach into your wallet and take tokens without your explicit, prior authorization.
• Approving does not move funds. Only a later transferFrom() call, made by the spender, actually moves tokens — and it can be made at any time, not just once.
• Your exposure is set by the approved amount, not by the size of the transaction that prompted the approval.
• Block explorers like Etherscan let you see every approval an address has ever granted, across every token.
• Approvals don't expire on their own; they remain usable until revoked or fully spent.

The ERC-20 approve() Function, Explained Plainly

ERC-20 is the technical standard that almost every fungible token on Ethereum and Ethereum-compatible chains follows — it's the specification behind stablecoins like USDC and USDT, governance tokens, wrapped assets, and thousands of other tokens you can hold in a self-custody wallet. The standard defines a small set of required functions every compliant token contract must implement, and two of them matter most for this guide: transfer(to, amount), which moves tokens directly from the caller's own address, and approve(spender, amount), which does something fundamentally different.

Calling approve(spender, amount) does not move any tokens. It writes a single number into the token contract's internal storage — an "allowance" — recorded against the pairing of your wallet address and the spender address you named. That number represents the maximum amount of the token the spender is now permitted to move out of your wallet, at a time of the spender's choosing, without asking you to sign anything else first. The spender is almost always a smart contract rather than a person: a decentralized exchange's router contract, a lending protocol's pool contract, a staking contract, or a bridge contract, each of which needs to be able to pull tokens from many different users' wallets as part of executing the action those users requested.

Think of it less like handing someone cash and more like adding a name to your bank account as an authorized user with a spending limit, except the "bank" here is a public, permissionless smart contract, and the authorization is itself a transaction recorded permanently on the blockchain. Once the approval transaction confirms, the permission exists independently of the transaction that created it — it isn't tied to a single subsequent action, and it doesn't disappear when you close your wallet app or navigate away from the site that requested it.

Every approval is scoped to exactly one token contract and one spender address at a time. Approving Uniswap's router to spend your USDC says nothing about your DAI, and approving Uniswap's router says nothing about a different protocol's router, even if both are swap contracts. Each pairing gets its own independent allowance, which is why a wallet that's been used across many DeFi protocols for months or years frequently has dozens of separate outstanding approvals, most of them long forgotten by the person who granted them.

Approve function signature

The function signature itself, as defined in the ERC-20 standard, is worth seeing directly: function approve(address spender, uint256 amount) external returns (bool). The two parameters are exactly the two pieces of information described above — which address gets permission, and how much of the token it's allowed to move — and every wallet's approval confirmation screen is, underneath its plain-language summary, showing you a decoded version of a call to this exact function.

Why Approvals Exist: How DeFi Actually Works

It's worth asking why this two-step system exists at all instead of protocols simply moving your tokens when you click "swap." The answer is a basic and deliberate limitation of how smart contracts work: a contract can only execute code when something calls it, and it can never unilaterally reach outside of the blockchain's rules to take an action on an account that hasn't explicitly authorized it. A DEX router contract has no more inherent ability to take tokens out of your wallet than a stranger on the street does — both need your prior, explicit permission, recorded in a form the token contract itself will honor.

That constraint is precisely what approve() solves, and it's why swapping a token you've never used with a given protocol before is, the first time, always two separate transactions rather than one.

The normal flow: approve, then swap

Consider a straightforward example: swapping USDC for ETH on Uniswap for the first time. The sequence looks like this:

1. Transaction 1 — Approve. Your wallet sends a transaction calling USDC's approve() function, naming Uniswap's router contract as the spender and specifying an amount (commonly either exactly the swap amount, or a larger/unlimited amount, depending on what the interface requests and what you confirm). This transaction only updates the allowance recorded in USDC's contract; your USDC balance is completely unchanged when it confirms.
2. Transaction 2 — Swap. A second, separate transaction calls Uniswap's router contract and asks it to execute the swap. Internally, the router now calls USDC's transferFrom(yourAddress, routerAddress, amount), which succeeds because the allowance from step 1 authorizes exactly this. The router receives your USDC, executes the trade through its liquidity pools, and sends you ETH in return.

Two transactions, two separate signatures, two separate gas fees — and this is completely normal, expected behavior, not a bug or a sign of a malicious dApp. The next time you swap USDC on the same router, if the existing allowance is still large enough to cover the new swap, the interface will typically skip straight to step 2, since a sufficient approval is already in place. This is also why swapping ETH itself needs no approval step at all: ETH is the network's native asset, not an ERC-20 token, and a contract can receive it directly as part of a single transaction without any separate permission system.

Practical checklist

• Expect two transactions and two signatures the first time you interact with a new token-and-protocol pairing; that's normal, not a red flag by itself.
• Check which address your wallet's confirmation screen lists as the spender before approving — it should match the protocol you intend to use.
• Remember that native assets like ETH don't require approvals; only ERC-20 tokens do.
• A protocol asking for an approval before it has told you what action that approval enables is worth pausing on and reading closely.

Common mistake

The common mistake is assuming the approve step and the swap step are the same authorization, and that confirming the approval is just a formality on the way to the "real" transaction. They are two independent grants of permission, reviewed and confirmed separately by your wallet, and the approval step deserves exactly as much scrutiny as the swap itself — arguably more, since it's the approval, not the swap, that determines your standing exposure afterward.

Approval vs. Transfer: The Distinction That Determines Your Risk

The most important technical fact in this entire guide is this: approving a token and transferring a token are two different function calls, and only one of them moves value. approve() writes a number to storage. transfer() and transferFrom() are the functions that actually debit one address and credit another. Confusing these two, or assuming that approving is itself a kind of transfer capped at a safe amount, is the root of nearly every misunderstanding people have about approval risk.

transferFrom(from, to, amount) is the function a spender calls to actually move tokens it has been approved for. Before executing, the token contract checks the caller's recorded allowance against the from address; if the allowance is at least amount, the transfer succeeds and the contract reduces the allowance by that amount (unless the allowance was set to the maximum possible value, treated by convention as effectively unlimited and left unchanged). If the allowance is insufficient, the call reverts and nothing moves.

Two properties of this mechanism matter enormously for risk:

• Timing is entirely up to the spender. Nothing in the ERC-20 standard requires transferFrom() to be called immediately after approval, or as part of any specific transaction. A spender contract can call it a second later, a year later, or never. From the token holder's side, an approval simply sits there as live, exercisable permission for as long as it remains outstanding.
• It can be called more than once, up to the allowance. A single approval is not consumed by one use. A spender can call transferFrom() repeatedly — in separate transactions, spaced arbitrarily far apart — as long as the cumulative amount moved stays within the approved allowance. An approval for 10,000 USDC could be drawn down in one transaction or in fifty smaller ones; the contract enforces only the running total against the original limit.

This is the entire technical basis for why a malicious or compromised spender is dangerous: it isn't limited to the transaction size you had in mind when you approved, and it isn't limited to acting once. A legitimate protocol you approved months ago and haven't used since still holds a live, callable allowance today, exactly as usable to it as the day you granted it — and if that protocol's contract is later exploited, or if you were tricked into approving an address that was never legitimate in the first place, the outstanding allowance is exactly what an attacker's contract calls transferFrom() against.

Practical checklist

• Treat "I approved it" and "it moved my funds" as two separate facts, true at two separate, possibly far-apart points in time.
• Assume any outstanding approval is live and exercisable today, regardless of how long ago you granted it or how much you've used the protocol since.
• Don't assume a protocol you trusted at the time of approval remains equally trustworthy indefinitely; approvals persist even if the protocol's security posture changes.

Common mistake

The common mistake is treating an old, unused approval as harmless simply because nothing has happened yet. Nothing having happened yet is not the same as nothing being able to happen; the allowance remains fully callable by the spender until it's revoked or spent, which is exactly why periodically reviewing and revoking unused approvals (covered in Swoopr's dedicated revocation guide, linked below) is a real, ongoing security practice rather than a one-time setup step.

Worked Example: Reading an Approval Transaction on Etherscan

Illustrative example — addresses shown are for demonstration only.

Suppose you're about to swap 500 USDC for ETH on Uniswap for the first time from a wallet that's never interacted with Uniswap's router before. Your wallet software prompts you to sign an approval, and your wallet's confirmation screen — or, after the fact, a block explorer like Etherscan — shows a transaction with roughly the following shape.

Transaction summary, as a block explorer would present it:

• From: your wallet address
• To: the USDC token contract address
• Method: Approve
• Function called: approve(address spender, uint256 amount)
• spender: Uniswap's router contract address, e.g. 0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45
• amount: 500000000

Reading the parameters. The To field tells you which token's contract you're granting permission on — here, USDC, not ETH and not any other token; approving one token contract never affects your holdings of any other. The spender parameter is the address being granted permission, and matching it against the protocol's official, published router address is the single most important check available to you, since a phishing site's fake "swap" button can just as easily populate this field with an attacker's address instead. The amount parameter is a raw integer expressed in the token's smallest unit; USDC uses six decimal places, so 500000000 represents 500000000 ÷ 10⁶ = 500.00 USDC, matching the swap you intended to make.

What an unlimited approval looks like instead. Had the interface requested unlimited approval — the default many dApps use so users don't have to re-approve for every future transaction — the amount field would instead show the maximum possible value a uint256 can hold: 115792089237316195423570985008687907853269984665640564039457584007913129639935. Block explorers and well-designed wallets typically render this recognizable maximum value as "Unlimited" in their plain-language summary rather than showing the raw number, precisely because it's meaningless to a human as a quantity — it exists purely as a convention meaning "no practical cap."

What happens next. This approval transaction, once confirmed, only updates USDC's internal allowance record for the pairing of your address and the router address. Your USDC balance shown in any wallet or explorer is unchanged. A second transaction — the actual swap — follows, and it's that second transaction, calling the router's swap function which in turn calls transferFrom(), that finally moves your 500 USDC out of your wallet in exchange for ETH.

Why this matters for reading any approval. The same three fields — the token contract in To, the spender address, and the amount — are exactly what to check on any approval transaction, whether you're reviewing one before signing it in your wallet or auditing one you've already signed on a block explorer. A mismatched spender address or an unexpectedly large amount are the two concrete, checkable signals that something is wrong, well before any funds have actually moved.

Where to Check Your Existing Approvals

Because approvals persist silently and accumulate across every protocol you've ever used, most active wallets have far more outstanding approvals than their owner remembers granting. Fortunately, every approval is public, permanent blockchain data, which means it's fully visible to anyone who knows how to look, including you.

Block explorers are the standard tool for this. Etherscan, the most widely used explorer for Ethereum and many EVM-compatible chains, provides a dedicated Token Approvals feature accessible from any wallet address's page: it lists every ERC-20 and NFT approval that address has ever granted and is still outstanding, showing the token, the spender, and the current allowance for each one, with unlimited approvals typically flagged explicitly. Other explorers for other chains (BscScan, Arbiscan, Polygonscan, and similar) offer equivalent tooling, since the underlying ERC-20 approval mechanism is identical across EVM-compatible chains.

Running this kind of check periodically — after using a new protocol, after a period of inactivity, or simply on a recurring schedule — turns an invisible, accumulating liability into something concrete you can review and act on. For a full walkthrough of these tools, including how to interpret what you see and how to use third-party approval-checking dashboards safely, see Swoopr's Token Allowance Checker Tools guide. Once you've identified an approval you no longer want active, the process for removing it — sending a new transaction that sets the allowance back to zero — is covered in detail in Swoopr's How to Revoke Token Approvals guide.

Practical checklist

• Look up your own wallet address on your chain's primary block explorer and review its token approvals at least once.
• Pay particular attention to any approval flagged as unlimited, and to any spender address you don't recognize.
• Make reviewing approvals a recurring habit, not a one-time cleanup, since new approvals accumulate every time you use a new protocol.

Misconceptions Versus Reality

Risks, Limitations, and Exceptions

• This guide describes the standard ERC-20 approval mechanism; some tokens implement non-standard variations, and some protocols use intermediary approval systems (such as Permit2-style contracts) that add an extra layer on top of the base mechanism described here.
• Not every approval is risky — the mechanism itself is a necessary, ordinary part of how DeFi functions, and the vast majority of approvals to well-established, audited protocols are never misused.
• Block explorer approval listings depend on accurate on-chain indexing and can occasionally lag behind the most recent transactions.
• Reviewing and revoking approvals reduces standing exposure but doesn't undo a transfer that has already occurred through an approval that was already exploited.
• This guide focuses on ERC-20 tokens specifically; NFT approval mechanisms (setApprovalForAll and similar) work on a related but distinct principle, covering entire collections rather than a bounded token amount.

Practical Implementation Checklist

1. Before signing any approval, check your wallet's confirmation screen for the token, the spender address, and the amount, not just the label the dApp gave the transaction.
2. Confirm the spender address matches the protocol's official, published contract address rather than assuming the interface got it right.
3. Where a dApp offers the choice, prefer an amount scoped to what you actually intend to use rather than accepting a default unlimited approval.
4. Remember that the approve step and the swap (or deposit, or stake) step are two separate authorizations, each worth reading independently.
5. Periodically look up your wallet address on your chain's block explorer and review every outstanding approval it lists.
6. Revoke approvals for protocols you no longer use, and treat any approval you don't remember granting as worth investigating.
7. Read Swoopr's companion guides on unlimited vs. limited approvals, revocation, and allowance-checker tools before granting or reviewing approvals at scale.

Frequently Asked Questions

Sources and Methodology

This guide describes the standard ERC-20 token approval mechanism as formally specified and documented in the following sources, current as of mid-2026:

• EIP-20: Token Standard: The official Ethereum Improvement Proposal defining the ERC-20 standard, including the exact function signatures and required behavior for approve(), allowance(), and transferFrom() described throughout this guide.
• Ethereum.org Developer Documentation: Ethereum.org's documentation on token standards and smart contract interaction describes how approvals fit into the broader pattern of contract-to-contract and wallet-to-contract permissioning on Ethereum and EVM-compatible chains.
• Etherscan Documentation: Etherscan's own documentation on its Token Approvals feature explains how the explorer surfaces on-chain allowance data for a given wallet address, which this guide references as the primary tool for checking existing approvals.

The worked example transaction in this guide uses illustrative addresses and amounts constructed for educational clarity and does not describe a specific real transaction.

This content was reviewed by the Swoopr Editorial Team in August 2026 and reflects publicly available information at that time. Token standards and the tooling built around them continue to evolve; treat this guide as a structural explanation of the underlying mechanism rather than an exhaustive or permanently current catalog of every wallet or protocol's specific approval interface.

Conclusion

A token approval is on-chain permission, not a payment: calling approve(spender, amount) authorizes a specific address to move up to a set amount of a specific token from your wallet, at a time of its choosing, without moving anything itself. That gap between granting permission and something actually happening with it is what makes approvals both essential to how DeFi functions and, when granted carelessly or to a malicious address, the mechanism behind some of the largest wallet-draining losses in crypto. Use this page as the foundational reference for Swoopr's Token Approvals & Blind Signing series, then move to the linked guides below to go deeper on limited vs. unlimited approvals, checking what you've already granted, and revoking what you no longer want active.

Related Reading

• Token Approvals & Blind Signing — the parent hub for this content group, covering the full range of approval and signature-related risks.
• Unlimited vs. Limited Approvals — a closer look at the tradeoffs between the two approval types introduced in this guide.
• How to Revoke Token Approvals — the step-by-step process for removing an approval you no longer want active.
• Token Allowance Checker Tools — a walkthrough of the block-explorer and dashboard tools for reviewing every approval a wallet has granted.