How to Review Token Approval Risks Before Connecting a Wallet
A plain-language checklist for understanding token approvals, spending limits and contract permissions before using a DeFi application.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A token approval is a permission you grant, not a payment you make. When you sign an approval, you are telling a contract that it may move a specified amount of a specified token out of your wallet, up to a limit you choose, until you revoke it. Nothing leaves your account at the moment you sign. That delay is exactly what makes approvals dangerous: the screen looks harmless, the funds are still there, and the permission can be exercised later by code you have never read.
Understanding that difference — approval versus transfer — is the whole job. Once you can tell the two apart, the rest of the review is a sequence of small questions about the contract, the network, the amount and the route back out.
Approve and transfer move in opposite directions
An ERC-20 transfer call moves tokens from your address to a recipient. An approve call writes a value into the contract’s allowance mapping for a spender, and moves nothing. The practical consequence is that approving costs you gas and gives nothing back; the exposure only shows up later, in a separate transaction that someone else initiates.
This is why an approval screen can look unremarkable. There is no amount leaving, no recipient receiving, no balance change to notice afterwards. The number on that screen is a ceiling on future withdrawals, not a payment.
The dangerous case is the combination. A phishing site asks you to sign an approval, then immediately asks for a transaction that exercises it. Both screens appear in the same session, and the second one looks like the real action. Airdrop scams work this way: the claim page asks you to “approve” a transaction, and that approval hands over your keys or your token allowance.
Unlimited approvals are the default, not the exception
Most front ends request an unlimited allowance because it saves the user a second approval later. Ethereum.org’s security guidance is explicit about the tradeoff: do not allow unlimited spend limits, because an unlimited spend could enable the smart contract to drain your wallet. Set the limit to the amount the transaction actually needs.
The practical reading of an unlimited approval is that the contract can move your entire balance of that token, at any point in the future, for as long as the approval stands. Revoking it does not undo anything the contract already did; it only removes the remaining permission. So the size of the number on the approval screen is the size of your worst case, not the size of your trade.
If a front end refuses to accept a limited approval, that refusal is information. It is not a safety feature working in your favour.
Read the four fields before you sign
An approval screen carries a small amount of data, and all four fields are checkable against the interface you believe you are using.
Spender is the contract receiving the permission. It should be a named protocol address you have independently confirmed, not an address displayed only inside the page asking for it. A spender you cannot name is a spender you cannot revoke from a position of knowledge.
Token is what the allowance covers. An allowance on a stablecoin and an allowance on a wrapped or bridged version of the same asset are different permissions, and many incidents are an attack on the cheaper-to-move of two assets you hold both of.
Amount is the ceiling. Set it to what this action needs. If the number is so large it exceeds your entire balance, that is a deliberate choice by the front end, not a default you can ignore.
Network decides who is affected. An approval on Ethereum mainnet and the same approval on an L2 are separate permissions, and revoking one leaves the other intact. Wallets frequently show the network name in the prompt; treat a mismatch with the interface you are on as a stop condition.
The route back out exists, and you should find it before you sign
An approval is revocable. That reversibility is the reason the risk is acceptable at all, and it is also the reason you should locate the revocation path while you are still deciding rather than after something looks wrong.
Revocation is itself a transaction with a fee, and it targets the same allowance you are trying to remove. Two consequences follow. First, revocation is not free, which is a mild practical reason not to sign approvals carelessly. Second, revoking an allowance a protocol legitimately needs will break that protocol’s next request, so you want to know which approvals you actually depend on.
Keep a short list: protocol, spender address, token, the limit you set, and the date. A list of five entries is manageable. A list you have never written is the reason an old approval survives a year.
Domain context is not optional
None of the four fields can be verified from inside the interface asking for the signature. The spender address means nothing unless you know which domain produced it, and ethereum.org’s guidance on phishing makes the mechanism explicit: an attacker can spoof a link preview so the text shows one domain while the click lands on another. Always check that you are on the right domain, especially after clicking a link.
This is why the approval review cannot be separated from where you arrived. A correct approval for a legitimate protocol, signed on a cloned front end, is the most common shape of this incident and the least detectable after the fact.
What this review cannot tell you
Reading an approval screen does not tell you what the contract does with the permission afterwards. An allowance that looks reasonable can be handed to a contract with logic you cannot verify from the interface, and that contract can exercise the approval in a way you did not intend.
It also does not tell you whether the protocol is solvent, audited, or honest. Approval risk is a permissions question; protocol risk is a separate question with a separate answer. Conflating them means assuming a reputable protocol makes any spender safe.
Related reading
- What a token approval screen usually means
- How to review wallet permissions after using a dapp
- How to verify a token contract before a DeFi action