Using a token in a decentralised application usually requires two transactions: one to grant permission and one to act. The permission does not expire when the action finishes, and that persistence is where a great deal of loss originates.
Contracts cannot take tokens, only be given them
A token balance lives in the token's own contract, which records who holds what. Another contract cannot reach in and move your balance on its own.
The standard therefore includes an allowance: an amount the holder authorises a named contract to move on their behalf.
Approving sets that allowance. Only afterwards can the application pull the tokens, and only up to the amount approved.
Unlimited approvals became the convention
Approving the exact amount needed means a fresh approval, and a fresh fee, for every interaction.
To avoid this, interfaces began requesting an effectively unlimited allowance so that one approval covers all future use of that application.
The result is a persistent standing authorisation. The trade completes, the user moves on, and the permission remains in place indefinitely.
The exposure is to future code, not present code
An allowance points at a contract address. If that contract is upgradeable, the code behind the address can change while the permission stays attached.
A contract that was audited and safe when approved can later be replaced, and every outstanding allowance becomes exercisable by whatever the new code does.
This is why large drains sometimes affect users who have not interacted with an application for months. They granted permission once, and the permission was still there.
Signature-based approvals shift the risk
Newer patterns let a holder sign an off-chain message authorising a spend, which the application submits along with the action.
These signatures can carry an expiry and a specific amount, so the authorisation is narrow and self-cancelling rather than open-ended.
The trade-off is that signing requests look harmless. A signature costs nothing and produces no on-chain record, so users approve them casually, and malicious sites exploit exactly that.
Revocation is a deliberate act
Setting an allowance back to zero requires a transaction and a fee, which is why most users never do it.
Reviewing outstanding approvals periodically, and removing those tied to applications no longer in use, closes an exposure that otherwise accumulates silently with every new application tried.
Separating funds across wallets achieves something similar by limiting what any single approval can reach, which is why active users often keep a small wallet for experimentation and a separate one for holdings.