A project moves to a new contract, you open the migration page, and before a single token has moved your wallet asks you to approve the old one. The prompt looks like an extra step somebody added to the flow. It is not. It is the only way an ERC-20 balance can be handed to anything other than you, and reading it properly is what separates a migration from a drained wallet.
What the approval actually grants
An approval is a write to a ledger that lives inside the legacy token contract. It records one number against one pair of addresses: how much of that token a named spender is allowed to move out of your account. Signing it moves nothing, sends nothing to the project, and commits you to no swap.
In the ERC-20 token standard that ledger is reached through two functions. `approve` allows a spender to withdraw from your account, repeatedly, up to a set amount, and `transferFrom` is the call that actually moves tokens from one address to another. The specification presents the pair as a withdraw workflow that lets contracts transfer tokens on your behalf, and a migration contract is one of those contracts with no special standing.
Where the entry is stored matters more than it sounds. The allowance sits in the legacy token, not in the migration contract, so it outlives the migration page, the swap itself, and the project. Closing the tab does not clear it.
Why the swap contract has to ask
A swap has to take custody of the old units before it can credit the new ones. The contract cannot reach into your account on its own, and the only party the token contract will listen to about your balance is the account that holds it.
The apparent alternative is to send the legacy tokens to the contract yourself with an ordinary transfer. That does move the tokens, and it also fails: a plain transfer arrives as a balance with no accompanying call, so the contract is never told the transfer happened and has nothing to credit against. The ERC-223 standard was written around exactly this failure. Pulling with `transferFrom` instead gives the contract one call in which it receives the old units and pays out the new ones, and that call needs an allowance in place first.
Two transactions, and only the second one swaps
The approval and the swap are separate transactions, each with its own gas. ERC-2612 states the shape plainly: if a user needs to interact with a smart contract, then they need to make 2 transactions, `approve` and the smart contract call which will internally call `transferFrom`.
Because they are separate, the first can succeed while the second still fails. A swap window that has closed, a payout reserve that has been emptied, a paused contract: none of those are visible to the approval, which only writes a number and returns. An approval confirming is not evidence that the migration behind it works.
The reverse trap sits one step later. A swap that previews correctly can still revert on chain, and a successful simulation answers a question about the state at one moment rather than the state your transaction lands in. When the swap reverts, the allowance you granted is untouched and still standing.
Migrations that have no reason to ask
Not every migration runs on an allowance. The shape you were told about should match the prompt you got.
| How the migration is run | What you send | Does an approval belong here |
|---|---|---|
| A swap contract pulls your legacy units | An approval, then the swap call | Yes |
| You transfer legacy tokens to a published address | One ordinary transfer | No |
| Holders of record are credited from a snapshot | Nothing | No |
| A platform converts its own pooled balance | Nothing | No |
The row that should stop you is the third. A distribution announced as automatic has no mechanism that needs your allowance, so a page asking for one is asking for something the described migration does not use. That mismatch costs nothing to notice and does not depend on trusting anybody's judgement about the site.
The three fields in the prompt that decide everything
Every approval prompt carries the same three fields, whatever your wallet calls them.
| Field | What it grants | Check it against |
|---|---|---|
| Token | Which contract's ledger the entry is written into | The legacy contract address in the project's own announcement |
| Spender | Which address may pull from your account | The migration contract address from that same announcement |
| Amount | The ceiling on what that address can take | The tranche you intend to swap now |
Compare addresses in full. A lookalike address can share the first and last few characters with the real one, and the middle is where the difference sits.
The spender field is the one that carries the loss, which is why a wallet drainer does not need to break anything. It puts its own address in that field and lets you sign an approval that is valid and correctly formed. The transaction succeeds exactly as written, and the balance leaves later, on the attacker's schedule rather than yours.
When the request is a signature instead of a transaction
An allowance does not always arrive as a transaction. ERC-2612 extends the ERC-20 standard with a `permit` function that allows users to modify the allowance mapping using a signed message, instead of through `msg.sender`, and a valid permit sets the allowance for that spender to the stated value, increments a nonce, and emits an approval event.
The consequence is that a screen showing a message to sign, with no gas and no pending transaction, can grant precisely what an approval transaction grants. It also leaves nothing in your own transaction history at the moment you sign, because the signed message is submitted by somebody else.
So read a signature request for the same three fields. A permit names the spender and the value it is setting, plus a deadline that the specification requires the current block time to be at or below. If a page presents the signature as a login or a confirmation while the typed data names a spender and an amount, the typed data is what will execute.
Exact amount or unlimited, and the allowance that stays behind
Work an example. A wallet holds 10,000 legacy units and the project has opened a swap. Approving 2,500, swapping that tranche, and checking what arrives against the announced ratio turns the migration into something you have observed rather than assumed. The remaining 7,500 then needs a second approval, which is one more gas payment and the whole cost of the method.
An unlimited approval removes that second payment and replaces it with standing permission over that token for as long as the entry survives. The migration contract keeps the right to pull any legacy units that reach your account afterwards, including a legacy balance you recover from an old wallet years later.
Finish by clearing what is left. An exact-amount approval is consumed by the swap it was granted for, while anything larger leaves a live entry behind, and a token approval that outlives its purpose is a permission nobody is watching any more. Setting the allowance back to zero is itself a transaction with its own gas, so do it deliberately once the migration is finished.
The bottom line
A migration asks for an approval because ERC-20 gives it no other way to take your old tokens. The approval is a number written into the legacy token contract naming an address and a ceiling: it moves nothing, proves nothing about the migration behind it, and does not expire when the page closes.
That reduces the whole job to three checks. Does this migration shape need an allowance at all, is the spender the address the project published, and is the amount the tranche you meant to swap. A signature request answers to the same three, and a granted approval outlives everything around it, so clear it when the swap is done. To keep learning the fundamentals, follow more from Bitbase Academy.
Related reading
Other Bitbase articles on this topic:
- How to Revoke a Governance Delegation
- How to Calculate a Token Treasury Runway
- ATR Indicator: How Average True Range Measures Volatility
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] Ethereum Improvement Proposals, ERC-20: Token Standard, the approve and transferFrom methods (status: Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-2612: Permit Extension for EIP-20 Signed Approvals, Abstract and Specification (status: Final) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, Motivation (status: Final) eips.ethereum.org
