Wallet Approvals: Permissions You Forgot

A token approval is a standing permission that lets another address move a specific token out of your wallet, up to an amount you set. You grant it every time you trade on a decentralised exchange, deposit into a contract, or mint something. The transaction you sign is not the trade; it is the permission that makes the trade possible.

The permission outlives the trade. A token approval granted in a hurry last year still exists today unless you revoked it, and the contract holding it can use it at any time without asking again. That is the part most people never see, because the interface that asked for the approval does not send a reminder.

• An approval is a separate onchain transaction from the swap or deposit that prompted it.
• Unlimited approvals are the default in many interfaces because they save gas on repeat use.
• A malicious or compromised contract can use an old approval months later, with no further signature from you.
• Reviewing and revoking costs a transaction fee, so revoke the approvals that are large relative to the risk, not every approval.

What a token approval actually grants

It grants a numeric allowance. The token contract stores a record that says this address may transfer up to this many units of this token on behalf of your address. Nothing moves at that point, and nothing is locked.

Allowance mechanics

Standard token contracts expose two functions: one sets the allowance, one spends it. Setting it writes a number against the pair of addresses. Spending it calls a transfer that reduces the number and moves the tokens. The spender never needs your key, only the allowance you already granted.

Unlimited means the maximum the number can hold, which is a 78-digit value. In practice it is indistinguishable from “any amount you will ever hold”, which is why an unlimited approval to a contract that later turns hostile is equivalent to handing over the balance.

Why the spend can happen later

The allowance sits in the token contract, not in the application you used. If the application is abandoned, sold, or upgraded to new logic, the allowance remains valid because the token contract has no concept of whether the spender is still trustworthy. Nothing expires. Nothing notifies you.

This is the mechanism behind most “my wallet was drained while I did nothing” reports. The drain is often the delayed use of a permission granted weeks earlier, at a moment when the wallet held more than it did on the day of the approval.

Why unlimited is the default

The gas arithmetic

Unlimited approvals are cheaper over a series of trades. An exact approval must be reset before it can be raised again, and some token contracts require setting the allowance to zero first, which means two transactions instead of one. Interfaces optimise for the second trade, not the first.

The failure mode it avoids

An approval for an exact amount can also fail mid-route when slippage or a fee changes the required input, so the trade reverts after you have paid for the approval. Unlimited removes that failure and moves the cost to a risk you cannot see.

An approval is not a payment. It is a promise that the other contract may take payment later, and the promise does not expire when the interface that asked for it disappears.

What a token approval does not let anyone do

It does not give access to your wallet, your key, or your other assets. The permission is limited to one token contract and one spender address. An approval for one token cannot move a different token, and an approval to one contract cannot be reused by another.

It cannot move the native coin of a chain either, because native balances are not held in a token contract and there is no allowance to spend. That is why drainers usually target token approvals plus whatever native balance can be swept by a separate transaction you are asked to sign.

It cannot sign new transactions, change your settings, or approve further spending. Every additional permission requires another signature from you. The danger is not that one approval escalates; it is that approvals accumulate quietly across years of use.

How to review and revoke a token approval

Review on a block explorer or a reputable approval-checking tool that reads the token contracts directly. Anything that asks you to paste a phrase, or to sign a message to “scan” your wallet, is not a scanner.

1. Connect the address you actually use, read-only if the tool supports it. A scanner needs no signing permission.
2. List approvals by token and spender, then sort by the dollar value of the allowance rather than by date.
3. Identify spenders you do not recognise, and contracts attached to applications you no longer use.
4. Check whether a large allowance belongs to an active, audited router you still trade through. Those are the ones worth keeping.
5. Revoke by setting the allowance to zero, one transaction per approval, and confirm each onchain.
6. Re-check after a week: some applications re-request unlimited approval on your next interaction, silently restoring what you removed.
7. Prefer exact approvals when an interface offers the choice, even at the cost of an extra transaction.

Revocation costs a fee, and on a congested chain that fee can exceed the value at risk for a small balance. Sort by exposure, revoke from the top, and accept that a dust-level approval to a dead contract is not worth a transaction.

Approval types compared

The types differ in what they expose and how long the exposure lasts. The table covers the ones you will actually encounter.

The fourth row is the one people miss. A signature that costs no gas feels harmless, but a permit can grant exactly the same spending right as an approval transaction, and it can be presented as a “login” or a “verification” step.