Token approvals are the silent liabilities of every DeFi user’s wallet. Every time you swap, lend, or stake through a decentralized protocol, you grant a smart contract permission to spend your tokens — often with no expiration and no limit. In May 2026 alone, approval-based exploits drained millions from DeFi users, including the Ekubo Protocol incident where attackers exploited an EVM router flaw to drain $1.4 million in WBTC from wallets with active approvals on the compromised contract. With Bitcoin trading near $80,000 and the DeFi ecosystem managing hundreds of billions in total value locked, the stakes have never been higher.
This advanced tutorial walks through building a fully automated, multi-chain token approval monitoring and revocation pipeline. You will learn how to detect risky approvals, automate revocation across Ethereum, Arbitrum, Optimism, and Base, and set up alerting for new approval events on your wallets. This is not a beginner’s guide — it assumes familiarity with smart contracts, Etherscan APIs, and basic scripting.
The Objective
The goal is to construct a system that continuously monitors your wallet addresses for token approvals across multiple chains, scores each approval based on risk factors, automatically revokes approvals that exceed a configurable risk threshold, and alerts you when new approvals are detected on unverified or recently deployed contracts. By the end of this tutorial, you will have a cron-driven pipeline that runs daily and keeps your approval surface area minimized.
Why does this matter? The Ekubo exploit demonstrates the exact failure mode. Users who had granted token approvals to Ekubo’s EVM v2 router months before the vulnerability was discovered had their WBTC drained without any new action on their part. The approval persisted silently until an attacker found a way to abuse it. Every active approval is a latent attack vector.
Prerequisites
Before starting, ensure you have the following: a Linux or macOS environment with Python 3.10 or later, API keys for Etherscan, Arbiscan, Basescan, and Optimistic Etherscan (free tier works), a funded wallet private key for automated revocation transactions (use a dedicated hot wallet, never your main vault), RPC endpoints for each chain (Alchemy, Infura, or public endpoints), and the Python packages web3, requests, and python-dotenv installed.
Store your API keys and wallet configuration in a .env file. Never commit this file to version control. The wallet you use for revocation transactions should contain only enough native tokens (ETH, ARB, OP, BASE) to cover gas costs — typically 0.01-0.05 ETH per chain per month for a moderate number of revocations.
Step-by-Step Walkthrough
Step 1: Build the approval scanner. The foundation is a function that queries the Etherscan API for ERC-20 approval events on your address. The Etherscan endpoint api.etherscan.io/api?module=account&action=tokentx&address=YOUR_ADDRESS returns all token transfers, but you need approval events specifically. Use the logs module with the Approval event signature 0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925 to filter for approval events from your address.
For each chain, create a configuration object containing the explorer API URL, the RPC endpoint, the chain ID, and the native currency for gas. Iterate through all ERC-20 tokens where you have an active approval and record the spender address, the token contract, and the approved amount. Most approvals are set to uint256.max (infinity), which is the riskiest configuration.
Step 2: Implement risk scoring. Not all approvals carry equal risk. Build a scoring system that evaluates each approval on multiple dimensions. Contract age: approvals on contracts deployed less than 90 days ago score higher. Verification status: unverified contracts score higher. Known exploit association: cross-reference spender addresses against databases of compromised contracts like those maintained by Revoke.cash. Approval amount: infinite approvals score higher than limited ones. Protocol reputation: approvals on audited, established protocols score lower.
Assign a composite risk score from 0 to 100. Approvals scoring above 75 should trigger immediate revocation. Scores between 50 and 75 should generate alerts for manual review. Scores below 50 can be logged for periodic auditing.
Step 3: Automate revocation. Revoking an approval is a simple transaction: call token.approve(spender, 0) from your wallet. Using Web3.py, construct and send these transactions programmatically. The gas cost is minimal — typically 45,000-65,000 gas units per revocation, which at current Ethereum gas prices means roughly $0.50-$2.00 per revocation on mainnet and fractions of a cent on L2s.
Implement a batch revocation function that processes all approvals above your risk threshold in sequence, waiting for each transaction to confirm before submitting the next. This prevents nonce conflicts and ensures clean execution. For L2 chains where gas is cheap, you can batch multiple revocations into a single multicall transaction using a contract like Multicall3.
Step 4: Set up monitoring and alerting. Configure your pipeline to run on a daily cron schedule. Use a lightweight notification system — Telegram bot API, Discord webhook, or simply email — to send summaries of revoked approvals and newly detected high-risk approvals. Include the contract address, token name, approved amount, and risk score in each alert.
Add a new-approval detection module that compares the current approval set against the previous day’s snapshot. Any new approval on a contract deployed within the last 30 days should trigger an immediate high-priority alert, regardless of its risk score. This catches scenarios where you interact with a new protocol that later turns out to be malicious or vulnerable.
Step 5: Extend to NFT approvals. ERC-721 and ERC-1155 tokens use the setApprovalForAll pattern, which grants blanket permission to transfer any token in your collection. This is even more dangerous than ERC-20 approvals because it covers assets that may be irreplaceable. Extend your scanner to detect these approvals using the ApprovalForAll event signature and include them in your risk scoring and revocation pipeline.
Troubleshooting
RPC rate limits: If you hit rate limits on free RPC endpoints, reduce your scan frequency to every 12 hours or switch to paid endpoints. Alchemy’s growth tier provides 300 million compute units per month for free, which is more than sufficient for daily approval scanning across multiple chains.
Revocation failures: Some tokens implement non-standard approval mechanics that reject approve(spender, 0). For USDT and similar tokens, you must first call approve(spender, 0) and then approve(spender, newAmount) in two separate transactions. Check the token contract’s implementation before assuming the standard pattern works.
Missed approvals: If your scanner fails to detect approvals on recently listed tokens, ensure you are using the latest token list from each chain’s explorer. New tokens may not appear in the API response for up to 24 hours after deployment.
Gas price spikes: During periods of high network activity, revocation gas costs can spike significantly. Implement a gas price threshold — skip revocations when gas exceeds a configurable multiple of the base fee and retry during the next scheduled run.
Mastering the Skill
Once your basic pipeline is operational, consider extending it with several advanced capabilities. First, implement MEV protection for your revocation transactions by using Flashbots RPC endpoints, preventing front-running of your approval changes. Second, build a historical analysis module that tracks your approval surface area over time, helping you identify periods when your risk exposure spiked and correlate them with specific protocol interactions.
Third, consider integrating with on-chain security feeds like Forta or Blockaid to automatically flag approvals on contracts that have been recently identified as vulnerable. This creates a reactive layer that responds to new exploit disclosures within minutes rather than waiting for the next scheduled scan.
Finally, if you manage multiple wallets or operate as a DAO treasury manager, deploy the pipeline as a Safe Module on Gnosis Safe, allowing automated approval management as a governed action rather than relying on a single private key. This brings institutional-grade approval hygiene to multi-signature setups.
The DeFi ecosystem’s composability is its greatest strength and its most persistent security challenge. Every connection between protocols creates a new trust assumption. By automating the monitoring and revocation of token approvals, you reduce your attack surface to only the approvals you actively intend to maintain. In a landscape where a single forgotten approval can cost you your entire WBTC position, this is not optional hygiene — it is essential infrastructure.
Disclaimer: This article is for educational purposes only and does not constitute financial or security advice. Always test automated systems on testnets before deploying with real funds. The author is not responsible for any losses incurred through the use of the techniques described above.
$1.4M drained from Ekubo and people still leave unlimited approvals on random routers. revoke.cash should be bookmarked by default tbh
the Ekubo exploit was wild because it was a router compromise not a user error. even careful people got hit if they had active approvals
Stefan P. router compromise vs user error is a critical distinction. even revoke.cash doesnt help when the router itself is the attack vector
Built something similar with Etherscan API last year. The hard part isnt detection, its getting users to actually run the script regularly. Automation is the right call here.
^ good point, I ran mine once and forgot about it for 6 months. The monitoring + alerting approach is what matters
most people only revoke after seeing a tweet about an exploit. the monitoring approach means you catch suspicious approvals before the drain happens
Multi-chain revocation is the real value add. Most tools only cover ETH mainnet and people forget they approved stuff on Arbitrum or Base months ago
cross-chain approvals are the worst. i had a compromised router on Optimism from 2024 that i only found when i manually checked. automation is overdue
cross-chain is exactly where the gap is. revoke.cash covers eth mainnet well but arbitrum and base approvals are a Wild West
audit_hook_ arbitrum approvals are a graveyard. found 3 active unlimited approvals from 2024 contracts i dont even remember interacting with
revoke_or_die finding 3 unlimited approvals from 2024 contracts on Arbitrum is exactly why multi-chain monitoring matters. most people never check L2s
Sasha V. detection is easy. getting people to care is the hard part. most users wont revoke until they see someone else get drained on twitter
calldata_witch detection being easy is true but the real problem is UX. no casual user will run a monitoring script. this needs to be built into wallets natively
calldata_witch exactly. ran a revoke script after the Ekubo news and found approvals from 3 contracts I dont even recognize. nobody checks until its too late
automated monitoring is the only scalable solution. nobody is manually checking etherscan for approvals every week. the alerting pipeline described here is practical
unlimited approvals are the original DeFi sin. protocols ask for them because its easier and users accept them because they dont know better