Your father passed away three years ago, and a wallet he left still holds assets that have not been moved. You recover it with the seed phrase and are about to transfer funds when you notice most of the USDC is gone—taken by an old contract he approved three years ago.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
This is not a joke. In security incidents above $1 million in 2025, 38% were carried out through Permit-style approvals. Even more common: a user gave a DApp unlimited approval years ago, and later the project upgraded its contract or shut down. But the on-chain approval record remains valid permanently. An attacker does not need your private key. They only need a vulnerable or malicious contract to call transferFrom() and move the assets.
Inheriting a DeFi position is not just "recovering staked assets," but also "cleaning up all contract permissions." If this part is not handled, the moment your executor gets the wallet, the assets are already exposed to risk.
Why old approvals are especially dangerous in inheritance situations
Normally, you may check your approvals regularly. But after you pass away, the first thing an executor does after recovering a wallet is "transfer funds," not "check approvals."
Moreover, on-chain approvals do not automatically expire. The unlimited USDT approval you gave Uniswap V2 three years ago is still valid today. Worse, if that old contract was later targeted by hackers, has a vulnerability, or the project replaced the contract without shutting down the old one, attackers can abuse the old contract's vulnerability to use your transferFrom() permission and take the assets.
Data from 2025 confirms this: phishing-related attacks, including malicious approvals, caused nearly $723 million in losses. In another case, an Alchemix user had pre-approved a malicious contract, and attackers used the vulnerability to take about $1 million in yvWETH positions—the flaw was not in the Alchemix protocol itself, but in the contract the user had approved in advance.
This is why "revoke approvals before inheritance" is not optional—it is mandatory. Your executor may not know that the first thing to do after recovering the wallet should be to check Revoke.cash, not rush to transfer funds.
Step 1: Use a tool to scan all historical on-chain approvals
First, you need to know which contracts this wallet address has given "backdoor" access to.
[What to do]: Use an approval management tool to scan all ERC-20 approval records for the wallet address on each chain.
[How to do it]:
Open Revoke.cash, a mainstream cross-chain approval revocation tool. Connect the wallet and select the relevant chain—Ethereum, BNB Chain, Polygon, etc. The page lists all active approvals, including the approved spender contract address, the approved amount, and whether it is unlimited, plus the approval time.
You can also use built-in wallet tools: imToken's "Authorization Management" feature—EVM and Layer 2 wallet users can search for Revoke.cash in the "Browser" page—or TokenPocket's "Authorization Detection" feature under "More Tools."
[Completion standard]: You or the executor can see a complete approval list showing each approval's contract address, amount—unlimited or a specific number—and approval time.
Step 2: Separate "what to revoke" from "what to keep"
Not every approval should be revoked. If you are still using a protocol—for example, you still have funds deposited in Aave—revoking may interrupt operations. Prioritize cleaning up these three types:
| Approval type | How to judge | Suggested action |
|---|---|---|
| High-risk target | Approval given to an unknown contract or personal address, or a contract imitating a well-known DApp. On a block explorer, a short deployment time and few calls usually indicate high risk. | Revoke immediately |
| Excessive approval | The approved amount is unlimited or clearly far larger than needed for actual transactions. | Revoke immediately |
| Old approval | The approval was made long ago and the DApp is no longer used—for example, a protocol you used once three years ago and never opened again. | Revoke immediately |
For DeFi protocols still in use, if the approval is unlimited, it is best to switch to "as-needed approval" after the executor takes over—manually set the amount needed for the current transaction instead of accepting unlimited by default.
[Completion standard]: You find at least two or three old contracts that are no longer used but still have active approvals, and list them for revocation.
Step 3: Execute the revocation
Revoking an approval is essentially an on-chain transaction: you call the approved contract's approve function and set the allowance to 0.
[What to do]: Submit the revocation transaction through a tool and wait for on-chain confirmation.
[How to do it]—using Revoke.cash as an example:
After connecting the wallet, find the approval you want to revoke in the list and click "Revoke" or "Cancel approval."
Confirm the signature request in the wallet and approve the gas fee.
Wait for the transaction to be confirmed on-chain. The confirmation time depends on network congestion and the gas price.
[Completion standard]: The approval entry disappears from the list, or the amount shows 0. Note: revoking an approval requires paying the gas fee on that network. If the wallet has no native token on the relevant chain, such as ETH or BNB, the executor must first deposit a small amount of gas to complete the revocation.
Common mistake: thinking "disconnecting the wallet" revokes approval
Many people click "Disconnect Wallet" in a DApp, believing that this withdraws the permission. That is wrong. Disconnecting only ends the session between the frontend and the wallet. The on-chain approval record still exists.
The only way to cancel an approval is to send an on-chain revoke transaction and set the allowance back to 0.
Risk reminder
If you hold assets on multiple chains, approvals on each chain are separate. Revoking an approval on the Ethereum mainnet does not affect your approvals on BNB Chain or Arbitrum. The executor must scan and revoke approvals on every chain where assets are held. In your inheritance checklist, clearly state: "After recovering the wallet, first check all chain approvals on Revoke.cash, confirm there is nothing unusual, and only then transfer funds."
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
How to verify the operation is complete
After revoking, do a final check:
Refresh the list on Revoke.cash or a wallet authorization detection page and confirm the revoked entries no longer appear.
Check the transaction logs on a block explorer for the
Approval(address indexed owner, address indexed spender, uint256 value)event and confirm thevaluefield is 0.Make a small test transfer: send 10 USDC from the recovered wallet to an exchange or another address to confirm the transfer succeeds and no unusual approval is triggered during the process.
After the executor finishes moving assets, it is recommended to clear all approvals on the original wallet address to zero at once, then create a new wallet for future operations to avoid leaving any historical risk behind.
