In this article
A token approval is a standing permission you record on a token, allowing one named contract or account to move up to a stated amount of that token out of your wallet, and you review and revoke old ones by listing every open permission for your address on each network you use and sending a transaction that sets each unneeded one back to zero. The permission stays open until it is used up or you change it. It has no expiry date of its own.
For a business or a professional who pays or gets paid in stablecoins, approvals are the part of wallet hygiene that is easiest to forget. A payment leaves a visible trace: a debit, a receipt, a line in the books. An approval leaves none of these. It moves no money on the day it is given, so it appears in no statement, and it can sit unused for years on a wallet whose balance has grown tenfold since.
None of this requires reading code. An approval has three parts, a wallet shows them before you confirm, and a public record keeps them afterwards. What follows covers what the permission is, why it exists, how its size changes what is exposed, how to read the prompt, and a review routine a finance lead can run every quarter with a second person.
Worked example detailed further down: a wallet holding 84,000 USDC pays one 6,500 USDC invoice, then receives 40,000 USDC.
What does a token approval actually allow?
A token approval allows one named address, called the spender, to move up to a stated amount of one specific token from your wallet, at a time of its choosing, without asking you again. It does not hand over your wallet, your keys or any other asset.
The mechanism comes from the ERC-20 standard, the specification published through the Ethereum Improvement Proposals process that almost every stablecoin on Ethereum-compatible networks follows. The standard defines three functions that work together. The first, approve, is the one you call: in the words of the specification, it allows the spender "to withdraw from your account multiple times, up to the value amount". The second, allowance, is a read-only question anyone can ask the token: how much is this spender still allowed to withdraw from this owner? The third, transferFrom, is what the spender calls to actually move the tokens, and the specification says it should fail unless the owner has deliberately authorised the caller.
Three consequences follow from that design, and each one matters for a review.
The permission is stored inside the token, not inside your wallet software. Your wallet app is only a window on it. Changing wallet apps, reinstalling one or disconnecting from a website leaves the permission exactly where it was.
The permission is a ceiling, not a payment. Approving 6,500 USDC moves nothing. Each time the spender draws on the permission, the remaining allowance drops by the amount moved, and when it reaches zero the spender can move nothing more.
The permission is public. The standard requires the token to emit a record, the Approval event, every time an approval succeeds. That public record is what makes a review possible: any block explorer can rebuild the list of permissions an address has granted.
A useful comparison for a finance team is a direct debit mandate with a ceiling. You sign it once, the other side draws on it when it needs to, and it stays in force until you cancel it. The difference is that a bank mandate names a company you can call, while a token approval names an address running a program.
Why does paying with a token usually take two steps?
Paying with a token usually takes two steps because a contract cannot pull tokens from your wallet on its own: you first approve the contract as a spender, and only then does the payment transaction let the contract collect the amount. The first prompt grants the permission, the second one uses it.
A plain transfer from you to another person needs no approval. You call the token, the token moves the amount, and the matter is closed. The two-step pattern appears as soon as a program sits in the middle: an exchange that swaps your USDC for another asset, a payment contract that splits an amount among several recipients, a lending service, a subscription. For the program to do its job, it has to collect the tokens from you as part of its own operation, and under the ERC-20 standard the only way to collect from someone else's wallet is transferFrom, which requires a prior approval.
This is why a first payment through a new service shows two prompts, and why each of them costs a network fee. It is also why the second payment through the same service often shows only one prompt: the approval given the first time was larger than the first payment, and what remains of it is being reused. A single-prompt payment through a contract is a sign that a permission is already open.
The two steps are also two separate decisions. The payment prompt is about this invoice. The approval prompt is about your relationship with the spender from now on. Treating the first prompt as a formality on the way to the second is how large standing permissions accumulate unnoticed.
What is the difference between an exact and an unlimited approval?
An exact approval permits the spender to move only the amount of the payment in front of you and is used up by that payment, while an unlimited approval permits the spender to move any amount of that token, now and in the future, until you revoke it. Between the two sits a capped approval, set to a round figure above the current payment.
Applications often request the unlimited form by default. The Ethereum Foundation's documentation gives the reason plainly: projects do this to minimise the number of requests, so that the user approves once and never again. That saves a fee and a click on every later payment. The same documentation states the cost: a spender holding such a permission can move all of those tokens even after you have withdrawn your funds from the platform into your own wallet, and it recommends approving only what you need or revoking access regularly.
In practice, "unlimited" is a very large number rather than a special setting. By a convention followed by the widely used OpenZeppelin token library, an allowance set to the largest number the token can store is treated as infinite and is not reduced when the spender draws on it. The ERC-20 standard itself does not define that behaviour, so how a particular token treats the maximum value depends on how it was written. For a review, the practical reading is the same: an allowance far above any balance you will ever hold is unlimited.
| Criterion | Exact approval | Capped approval | Unlimited approval |
|---|---|---|---|
| Amount permitted | The payment amount | A chosen ceiling above it | Any amount |
| After the payment | Nothing remains | The unused part remains | Everything remains |
| Next payment to the same spender | New approval, new fee | No approval until the cap is used | No approval, ever |
| Covers tokens received later | No | Up to the unused part | Yes, all of them |
| Needs revoking afterwards | No | Yes, if unused | Yes |
No row of this table makes one form wrong in every case. A treasury wallet that pays the same audited contract every day may reasonably hold a capped permission sized to a week of payments. What the table shows is that convenience and standing exposure rise together, and that the choice belongs to you: some wallets let you edit the amount in the approval prompt before confirming, replacing the requested figure with your own.
How much does an open approval expose? A worked example
An open approval exposes, to its one spender, the smaller of two numbers: the allowance that remains and the balance of that token in the wallet. An exact approval that has been used exposes nothing, and an unlimited one exposes the whole balance, including money that arrives later.
Take a worked example, with invented figures. A brokerage keeps a payment wallet holding 84,000 USDC. It pays one supplier invoice of 6,500 USDC through a payment contract, which leaves 77,500 USDC in the wallet. Some days later a client pays the brokerage 40,000 USDC into the same wallet, bringing the balance to 117,500 USDC. The only thing that varies is the size of the approval given before the invoice was paid: exact (6,500 USDC), capped at a planned month of payments (20,000 USDC), or unlimited.
| Approval given | Allowance left after paying 6,500 | Exposed with 77,500 in the wallet | Exposed with 117,500 in the wallet |
|---|---|---|---|
| Exact, 6,500 USDC | 0 | $0 | $0 |
| Capped, 20,000 USDC | 13,500 USDC | $13,500 | $13,500 |
| Unlimited | Unlimited | $77,500 | $117,500 |
Two things stand out. The capped permission holds its line: the client's 40,000 USDC arrives and the exposure does not move, because the ceiling is the remaining allowance and not the balance. The unlimited permission follows the balance upward, so the exposure grew by 40,000 USDC on a day when the brokerage did nothing but get paid.
"Exposed" here has a precise meaning. It does not mean the money is lost or at risk today. It means that the safety of that amount no longer depends only on your own keys: it also depends on the spender's contract behaving as intended for as long as the permission stays open, including after any change to that contract and after you have stopped using the service. A control review asks the same thing of any standing mandate: who can move how much, and is that still needed?
The figure also has to be read per spender. A wallet with five unlimited USDC approvals does not have five times its balance exposed, but it has five separate programs each able to reach the whole balance.
Can a signature that costs no gas still grant an approval?
Yes: on tokens that support the permit function, a signature produced in your wallet at no cost can grant exactly the same permission as an approval transaction, once someone submits that signature to the token. No fee does not mean no effect.
The permit function comes from EIP-2612, an extension to the ERC-20 standard. Its motivation, as the specification states it, is that the ordinary approve function has to be called by the token holder directly, which means the holder needs ether to pay the transaction fee before doing anything else. Permit removes that requirement. You sign a structured message off the network, and the message itself becomes the authorisation.
The signed message carries five things: the owner (your address), the spender, the value, a deadline after which the signature can no longer be used, and a nonce, a counter that prevents the same signature from being used twice. The specification is explicit that the party who submits the signature can be any address. In normal use it is the application you are dealing with, which submits your permit and collects the payment in one transaction, so that you see a signature request followed by a single payment instead of two fee-paying steps.
For the signer, the points that matter are these.
A signature request is not automatically harmless. Wallets present signatures and transactions differently, and a request that shows no network fee can feel like a login or a terms-of-use confirmation. A permit is neither. If the message names a spender and a value, you are being asked to grant an allowance.
The fields to read are the same as for an approval, plus the deadline. EIP-2612 allows the deadline to be set to the maximum value, which, in the specification's words, creates permits that effectively never expire. A short deadline limits how long an unused signature remains valid.
A signed permit that has not been submitted yet is invisible to a review. It exists only as a message held by whoever received it, so no approval list can show it. Once submitted, it becomes an ordinary allowance on the token: it appears in the same lists and is revoked in the same way.
Not every token implements permit. It is an optional extension, so whether a signature can create an allowance depends on the token in question.
How do you read an approval prompt before confirming?
Reading an approval prompt means checking three fields before you confirm: which token the permission covers, which address is named as spender, and what amount is permitted. If any of the three is not what you expected for the payment you are making, the correct action is to reject the prompt, which costs nothing.
Wallets word these prompts differently ("approve", "set spending cap", "give permission to access"), but the underlying fields are the three arguments of the standard, and they can always be found on the confirmation screen or in its details view.
| Field | What it tells you | What to check |
|---|---|---|
| Token | The asset the permission covers | It is the token you are paying with, on the network you intend to use |
| Spender | The address that will be allowed to move the token | It matches the contract address the service publishes in its official documentation |
| Amount | The ceiling of the permission | It equals the payment, or a cap you chose; a very large or "unlimited" figure is a decision, not a default |
| Deadline (signatures only) | Until when the signed permission can be submitted | It is short, not far in the future or unlimited |
The spender field deserves the most attention, because it is the one a busy person skips. The name of the website you are on is not the spender. The spender is an address, and the only reliable check is to compare it with the address published by the service itself, character by character at both ends, or through a saved address book entry your team maintains.
One more habit helps. When an approval request appears and you did not start a payment, a deposit or a swap a moment earlier, reject it. An approval is always the first half of an operation you chose to begin, never something that should arrive on its own.
How do you review and revoke old approvals?
You review old approvals by looking up your wallet address in a tool that lists every permission the address has granted on a given network, and you revoke one by sending a transaction that sets its allowance to zero. Three families of tools do this: a block explorer's token approval page, a dedicated approval checker, and the permissions screen that some wallets include.
All three read the same public record, so they should agree. Under the ERC-20 standard, calling approve again overwrites the current allowance with the new value, which is why a revocation is simply an approval of zero to the same spender.
- List your addresses and networksWrite down every wallet address the business uses and every network each one has been used on. A firm with two wallets active on two networks has four lists to review, not one.
- Open an approval list for the first addressUse a block explorer's token approval page, an approval checker or your wallet's permissions screen. Reach the tool from a bookmark you saved yourself, never from a link in a message or an advert. Viewing the list only requires the public address.
- Select the right networkEach list covers one network at a time. The Ethereum Foundation's documentation notes that a list for Ethereum Mainnet will not show permissions granted on another network.
- Read each line as token, spender, amountFor every entry, note the token, the spender address and its label if the tool gives one, the remaining allowance and the date it was granted.
- Sort the entries into keep, reduce or revokeKeep a permission only if you can name the service, still use it and accept the amount. Reduce one that is larger than your use. Revoke everything you cannot identify or no longer need.
- Send the revocationsConnect the wallet, choose revoke on each entry and confirm in the wallet. Check that the prompt shows the same token and spender with an amount of zero. Each revocation is its own transaction with its own network fee.
- Confirm the resultReload the list after the transactions are confirmed, which can take from about a minute to several depending on the network, and check that the revoked entries are gone or show zero.
- Record what you didKeep the date, the address, the network, the entries reviewed, the decisions and the transaction references, so the next review starts from a known state.
When reducing an allowance instead of removing it, the ERC-20 specification advises that interfaces set the allowance to zero first and then to the new value for the same spender. In practice this means two transactions: revoke, then approve the lower amount the next time you actually pay.
If you cannot tell what a spender is, revoking is the cautious choice. The Ethereum Foundation's documentation says the same: when unsure, you can revoke everything, and the only consequence is having to grant a permission again the next time you use a service.
What does revoking cost, and what does it not undo?
Revoking an approval costs one network transaction fee per permission, paid in the network's own coin, and it only closes the permission from that point on: transfers the spender already made under it are not reversed. The Ethereum Foundation's documentation is direct on the first point, stating that you have to pay the fee for the cancellation to succeed.
The cost has a practical consequence for a business wallet. A wallet that holds only USDC and no ether cannot revoke anything on Ethereum, because the fee is not payable in USDC. A payment wallet should therefore always hold a small reserve of the native coin of every network it operates on, sized for a round of revocations, not only for the next payment. The fee itself varies with network conditions and from one network to another, so no fixed figure applies; your wallet shows an estimate before you confirm.
The second point is the one most often misunderstood. A revocation is not a refund, a dispute or a chargeback. It changes the allowance from its current value to zero, and that is all it does. Tokens moved before the revocation was confirmed stay where they were sent. Revoking is a preventive control, and its value comes from being done before it is needed.
Revoking also leaves existing positions untouched. According to the Ethereum Foundation's documentation, removing a spender's permission does not end a staking, pooling or lending position you hold with that service; it only stops the service from pulling further tokens from your wallet. You may need to approve again to add funds later.
Finally, revoking carries no downside for your own funds. The same documentation states that revoking token access should never result in a loss of funds when done through a reputable tool. The only thing given up is the convenience of a single-prompt payment next time.
What does an approval not cover?
An approval covers one token, one spender and one network, and nothing beyond that combination. Each of those three limits works in your favour when you grant a permission and against you when you review, because the same limits mean a single review screen never shows everything.
One token. A USDC approval says nothing about any other stablecoin or asset in the wallet. Each token keeps its own record of allowances. A service that handles three tokens for you holds three separate permissions, and revoking one leaves the other two open.
One spender. The permission names a single address. A service that replaces its contract with a new version at a new address will ask for a fresh approval, and the permission given to the old address stays open unless you close it. Old versions of services you still use are a common finding in a first review.
One network. The same token name on two networks is two different token contracts with two separate allowance records. A permission granted on one network does not exist on another, and a revocation on one does not reach the other.
Not the network's own coin. Ether and the native coins of other networks are not ERC-20 tokens and do not use this allowance mechanism. The approvals discussed here concern tokens such as stablecoins.
Not your wallet connection. Connecting a wallet to a website and approving a spender are different things. The Ethereum Foundation's documentation states that disconnecting from a site does not remove token permissions. Clearing the list of connected sites in a wallet is tidy, but it revokes nothing.
Not a time limit. A standard approval made by transaction has no expiry date; in the words of the same documentation, contract permissions have no expiration date. The deadline in a permit signature limits when the signature can be submitted, not how long the resulting allowance lasts.
How should a business run a quarterly approval review?
A business should treat open approvals as standing payment mandates: keep a register of them, review it every quarter, and have one person prepare the review and a second person approve the decisions before any transaction is sent. The principle is the same separation of duties a finance team applies to bank mandates and supplier payment details.
The register is a simple sheet with one line per permission: wallet address, network, token, spender address, the service the spender belongs to, the amount, the date granted, the business reason and the person who granted it. The first review builds it from the approval lists. Every later review compares the lists against the register, so that anything on the lists and not in the register is a finding by itself.
| Quarterly check | Preparer | Second person |
|---|---|---|
| Inventory of wallets and networks is current | Updates the list, adds any new wallet or network | Confirms nothing in use is missing |
| Approval list exported for each wallet on each network | Produces the lists | Opens one list independently and compares |
| Every entry matched to the register | Marks matched, unknown and outdated entries | Reviews every unknown entry |
| Keep, reduce or revoke decided per entry | Proposes a decision with a reason | Approves or changes each decision |
| Unlimited permissions justified | States why an exact or capped amount is not workable | Accepts the reason or asks for a cap |
| Revocations sent and confirmed | Sends the transactions | Checks the reloaded list shows them closed |
| Fee reserve on each network | Reports the native coin balance | Confirms it covers a round of revocations |
| Register and review record filed | Updates the register and files the record | Signs off with the date |
Where the wallet itself requires two signers for a transaction, the second person's approval of each revocation happens in the wallet. Where it does not, the second person's check is done on the lists and recorded in the review file.
Two rules make the quarterly review lighter over time. The first is an approval policy written in one sentence, for example: exact amounts by default, a capped amount where a service is used at least weekly, unlimited only with a written reason. The second is to separate wallets by purpose, so that the wallet that interacts with services and grants permissions holds a working balance, and reserves sit in a wallet that grants no permissions at all. Under the worked example above, an unlimited permission on a working wallet holding 6,500 USDC and one on a wallet holding 117,500 USDC are the same line in a list and very different exposures.
When should approvals be reviewed outside the quarterly cycle?
Approvals should be reviewed immediately, without waiting for the quarter, whenever something changes about who can act on the wallet, which services it uses or how much it holds. A calendar review catches drift; an event review catches the moments when a permission stops matching the business.
The events worth writing into a procedure are few:
- A service is no longer used. Closing an account or moving to another provider ends the relationship in your books, but not on the token. Revoke the permissions on the day you stop.
- A service announces a new contract version. Approve the new address when you first use it, and revoke the old one in the same session.
- A service discloses a defect in one of its contracts. Revoke the permissions given to the affected address first and read the details afterwards. Use your own bookmark to reach the approval list, not a link circulated with the announcement.
- A person with access to the wallet leaves or changes role. Review what was granted during their tenure along with the usual access changes.
- The balance is about to rise sharply. Before a large client payment or a transfer from reserves lands on a working wallet, check which unlimited permissions will apply to it the moment it arrives.
- A prompt was confirmed in a hurry. If anyone on the team is unsure what they approved or signed, list the wallet's permissions straight away and close anything unexpected.
Each of these takes minutes when the register exists and the fee reserve is in place. The work is the same as in the quarterly routine, applied to one wallet and one spender, with the same record kept at the end. A permission that is known, sized to its use and closed when the use ends is an ordinary operating tool; the review exists to keep every open permission in that state.
