Revoke token allowances
Review the standing token approvals on any Stellar address and set the ones you no longer want to zero.
An allowance is a standing approval that lets another address spend your SEP-41 tokens up to a limit. You grant them when you use a DeFi app, and they stay active until they expire or you revoke them.
The allowance viewer at /allowances lists the active ones on any address. You do not have to
close anything to use it, and looking is read-only and free.
Review an address
Open the viewer
Go to Allowances in the top navigation.
Enter an address
Paste any G account address or C contract address and select Scan. With a wallet
connected, Scan my own address fills in your address and scans it. You need no wallet to
look.
Read the results
Each row shows:
| Column | What it tells you |
|---|---|
| TOKEN | The token symbol and its contract address |
| SPENDER | Who can spend it, named when the app knows the app or protocol |
| SPEND LIMIT | The most that spender can still move. Unlimited for an unbounded approval |
| EXPIRES | When the approval ends on its own |
A spender the app does not know on this network is flagged Unrecognized spender. That does not make it malicious. Inspect it with the explorer link.
Show inactive allowances adds the approvals that expired or are already zero.
Revoke one
Select Revoke on a row. The app builds the revoke and shows Network fee up to ... XLM before anything is signed. Select Sign to sign it in your wallet, or Cancel. The approval is set to zero, and the row updates to Revoked once the ledger confirms it. When the ledger includes the revoke but it fails, the row says the allowance is still live, links the transaction, and offers Retry revoke. When the app cannot learn the outcome in time, the row shows Not confirmed and asks you to refresh the list, because the revoke can still land.
The token's own code decides what a revoke costs, so the fee is on screen first. When the revoke has to be rebuilt before it is signed, because another revoke landed first or its time window ran out while you read the fee, and the rebuilt one costs more, nothing is signed: the row shows the new fee and asks you to check it.
Only the owner of the approvals can change them, so revoking needs the wallet that owns the address you are viewing. With another wallet, or none, the page stays read-only and says so.
Revoke several at once
When an address has at least two active approvals you can revoke, a bar above the list offers Revoke all, and Revoke ... unrecognized when some but not all of the spenders are unknown to the app. Revoking also cancels approvals for apps you still use, and you re-approve those the next time you use them. If you are cleaning up, start with the unrecognized ones.
The bar first builds every revoke and reads its fee, then asks you to confirm with the total: Network fees: up to ... XLM in total. A revoke that cannot be built is listed and not signed. After you confirm, the bar signs and confirms one approval at a time, so your wallet prompts once per approval. No revoke is signed for more than the fee you confirmed: one whose fee has gone up by then is not signed, the result lists it with its new fee, and you can revoke it again from its row. You can select Stop after current at any point, and whatever is already revoked stays revoked.
Keep the tab open until the bar finishes. Each approval is its own transaction, so leaving partway revokes some and not others.
What the scan covers
The viewer reads approve events from Soroban RPC, which keeps about seven days of event history. When the deployment has a Lumeus key for the network, the viewer also reads every approve event the address ever granted from Lumeus, a hosted Stellar history index, and combines the two lists. The line under the page title says which one you get: its whole approve history through Lumeus or the last 7 days of on-chain events.
Without Lumeus, an approval granted more than about seven days ago and never changed since does not appear, so check the spending app directly if you know you approved something earlier. When the scan cannot cover the whole window, or Lumeus cannot be read, the page says The scan didn't finish and names the reason. A Lumeus failure leaves the last seven days checked, and Scan tries again.
A token contract can emit approve events for any spenders it likes. When one contract reports approvals for more than 20 different spenders, the viewer lists the 20 most recent and says Some approvals aren't listed. Stellar asset contracts, which run no custom code, are never cut.
When the on-chain value disagrees
The list is built from the latest approve event per token and spender, then each one is read back
from the token contract's own allowance(). When the two disagree, the row shows the on-chain
figure and says the event can be fabricated or stale. When the read fails, the row says the amount
is unverified. Trust the on-chain value, and revoke when you do not recognize the spender.
Allowances during a close
A close revokes every active allowance it finds before the merge. It confirms each one against the
token's allowance() first and skips the ones that already read zero. A revoke that fails does not
stop the close: closing the account does not remove an allowance, so the result lists any that
stayed in place.
Why this is worth doing
Allowances persist. Unless an expiry was set, an approval you granted months ago is still live today. If that spender is later compromised, every account with an active approval to it is exposed up to the approved amount. Pruning the ones you no longer need removes that exposure.
How it works underneath
SEP-41 allowances covers the event scan, the on-chain confirmation, and the exact call a revoke builds.