Revoking Token Approvals from SSP

Every time you confirm a swap, deposit, or NFT listing on an EVM chain, you grant the dApp permission to move a specific ERC-20 token on your behalf. Those permissions — called approvals or allowances — stay on-chain after the transaction settles. Months later, the contract you trusted in March might still be allowed to drain that token in June. The fix is straightforward: revoke approvals you no longer need. This guide shows you how to do it from SSP, the self-custodial 2-of-2 wallet where every transaction (revokes included) is co-signed by your SSP Key.

If you're new to the concept, read Token Approvals: The Permissions You Keep Granting first. It explains why approvals exist and why unlimited allowances are the default attack surface in DeFi. This article is the cleanup companion.

A quick recap

When you sign an approve(spender, amount) call, the token contract records that spender (typically a router, vault, or marketplace contract) is allowed to transfer up to amount of that token from your address. Many dApps request 2^256 - 1 — effectively unlimited — to save you gas on future interactions. That convenience is also the risk: if the spender contract is later compromised, or you stop using the dApp but the allowance lingers, an attacker can drain the entire balance whenever they want.

Revocation reverses that grant. It does not undo past transfers and it does not "delete" anything — it simply sets the allowance back to zero.

How revocation works mechanically

A revoke is just another transaction. You call approve(spender, 0) on the same token contract, on the same chain where the original approval was granted. That single function call writes a new 0 into the contract's allowance[owner][spender] mapping, overriding the old number.

A few mechanics to internalize:

• One revoke per chain per token-spender pair. If you approved a USDC spender on Ethereum and the same spender on Polygon, you need two revoke transactions — one on each chain. Allowances are not shared across chains.
• Revocation is a standalone transaction. It costs gas just like any transfer. Plan for it: budget the native asset of the chain (ETH on Ethereum, MATIC on Polygon, etc.) to cover the fee.
• It can be cheaper than you fear. A revoke is a simple write, often cheaper than a swap. On Layer 2s like Base it's usually pennies.
• SSP still co-signs. Because SSP is a 2-of-2 wallet, the revoke transaction goes through the same flow as any other: your extension proposes it, your SSP Key reviews and co-signs it. Your protection extends to the cleanup itself — no single device can revoke unilaterally, and no single device can be tricked into approving something disguised as a revoke.

Two paths to revoke

You have two equally valid ways to revoke approvals from SSP. Pick whichever fits the situation.

Path 1: Use a reputable block explorer

This is the manual, transparent route. Useful when you know the exact token and spender you want to revoke, or when you don't want to connect to a third-party tool.

1. Open the token contract page on the appropriate explorer:
   • Ethereum: etherscan.io
   • Polygon: polygonscan.com
   • Base: basescan.org
   • BNB Smart Chain: bscscan.com
   • Avalanche: snowtrace.io
2. Go to the Contract tab, then Write Contract (or Write as Proxy if the token is a proxy contract — most major stablecoins are).
3. Find the approve function. The inputs are spender (the address you want to revoke) and amount (the new allowance).
4. Set amount to 0. Paste the spender address — copy it from your earlier transaction history, never type it from memory.
5. Connect your wallet. Most explorers support WalletConnect, which is the recommended way to connect SSP. Approve the connection in your extension.
6. Click Write. The explorer builds the approve(spender, 0) transaction and hands it to SSP. SSP's extension shows you the call details; your SSP Key co-signs; the revoke broadcasts.

This path is verbose but leaves zero ambiguity about what you signed.

Path 2: Use a dedicated revocation tool

For most users this is the practical option. revoke.cash is the widely-used, open-source tool for the job. It scans your address across supported chains, lists every active allowance, flags risky ones (unlimited amounts, unfamiliar contracts), and lets you revoke them — individually or in batches — via your connected wallet.

The flow:

1. Open revoke.cash directly in your browser. Bookmark the real domain and only visit from the bookmark. Phishing copies of revocation tools exist precisely because users arrive there ready to sign transactions.
2. Connect with WalletConnect, then scan the QR code or copy the URI into SSP.
3. Switch the chain selector to the chain you want to audit. revoke.cash will fetch your approvals on that chain.
4. Review the list. Each row shows the token, the spender, the allowance amount, and (usually) a label for the dApp.
5. Click Revoke next to anything you no longer use. Each revoke is a separate approve(spender, 0) transaction, co-signed by SSP.

A practical audit workflow

Once or twice a year, set aside 20 minutes and walk through this:

1. Connect SSP to revoke.cash via WalletConnect.
2. Review your active approvals on each chain you've used. Start with Ethereum — historically the densest approval graph — then move through Polygon, Base, BNB Smart Chain, and Avalanche.
3. Pick the riskiest items first. Sort or skim for unlimited allowances and unfamiliar dApp names. A protocol you swapped through once in 2024 and never touched again is a prime candidate. So is any contract you can't identify at all.
4. Revoke. Confirm the transaction in your SSP extension; the SSP Key prompts you to co-sign; the revoke broadcasts.
5. Co-sign on the SSP Key. This is the moment to double-check the destination. The SSP Key shows the contract you're calling and the function — confirm both match what you intended.
6. Repeat per chain. Allowances are per-chain. Don't assume revoking on Ethereum cleans up Polygon.

You don't need a clean slate. The goal is to keep allowances on contracts you actively use and zero out the rest.

Cautions

• Domain hygiene. Only use the official revoke.cash domain. Phishing clones target this exact workflow because the user is already in a transaction-signing mindset. Bookmark it; verify the URL bar before connecting.
• Per-chain reality. Revoking a USDC approval on Ethereum does not touch the USDC approval on Polygon, even though the token "looks the same" in your portfolio. Walk each chain explicitly.
• Gas budget. Revocation costs gas. On Ethereum a backlog of revokes can add up; do them when gas is calm. On Layer 2s the cost is negligible.
• Verify the spender, always. Before you sign any "revoke" transaction, confirm the spender address in the call matches the contract you intended to revoke. A malicious site could present a fake revoke UI that's actually issuing a new approval to an attacker. Reading the function name (approve) and the amount (0) on the SSP Key prompt is your last line of defense.
• Permits are different. Some tokens (USDC, DAI variants) support permit — off-chain signatures that act as approvals. revoke.cash will surface known permit-based grants where it can; treat anything you don't recognize the same way you'd treat an on-chain allowance.

The 2-of-2 advantage on cleanup

This is the often-missed point: revocation in SSP isn't a single click on a single device. Your extension drafts the revoke, but it cannot broadcast alone. Your SSP Key has to co-sign, and that co-sign step is where you inspect what's actually being submitted. If your extension were ever compromised and tried to submit a malicious "revoke" that was really a fresh approval, the SSP Key would surface the real function and amount on its screen. Two devices, two opportunities to catch a problem.

Routine approval hygiene is the highest-leverage DeFi habit most users skip. Set a calendar reminder, do the audit, sleep better. And keep reading the series — start with Ethereum in SSP if you want to ground the chain-specific bits, or revisit Token Approvals: The Permissions You Keep Granting to remind yourself why this matters.