Approval Scams via Proxy Contracts: Bypassing Revocations
Approval scams via proxy contracts are a sophisticated type of DeFi attack where malicious actors exploit the upgradeable nature of proxy contracts to evade token approval revocations. In these scams, attackers deploy a proxy contract that users approve to spend their tokens, typically under the guise of a legitimate DApp. The critical vulnerability lies in the fact that while users can revoke on-chain approvals, they often mistakenly revoke the implementation contract's address rather than the proxy's address, leaving the proxy's allowance intact.
This guide dives deep into how attackers design proxy contracts to bypass revocations, drawing on real DeFi protocols and known attack patterns. You will learn the exact mechanics, see comparison tables, and understand how to audit and protect yourself against these threats. The goal is to equip intermediate users with the knowledge to identify and neutralize proxy-based approval scams.
- The core trick: users approve the proxy address, then try to revoke the implementation address, leaving the proxy's allowance active.
- Always verify the exact spender address on a block explorer before approving, and ensure it is not an upgradeable proxy with a single owner.
- Revoke allowances using the proxy's address, not any other contract that appears in the transaction history.
- Use tools like Revoke.cash or Etherscan Token Approvals to audit all your approved spenders, and prioritize revoking proxy contracts.
- Support protocols that use immutable logic or transparent upgrade governance (timelocks, DAO multisigs) to reduce trust assumptions.
- If you suspect a proxy has been upgraded maliciously, immediately revoke the proxy address and consider moving your funds to a new wallet.
1. The Basics: Token Approvals and Proxy Contracts
A token approval is a permission granted by a user to a specific spender address (e.g., a smart contract) to spend up to a certain amount of the user's tokens. The ERC-20 standard exposes approve() and transferFrom() for this. A proxy contract, common in upgradeable smart contracts, is a contract that delegates calls to an underlying implementation contract using delegatecall. The proxy's address remains fixed, but the logic can be changed by upgrading the implementation.
In many DeFi protocols (e.g., Uniswap V3's NonfungiblePositionManager, Compound's cTokens), users interact with a proxy that acts as the entry point. The user approves the proxy address, not the implementation. The key risk: the proxy's owner (often a multisig) can upgrade the implementation to a malicious version.
2. How Approval Scams via Proxy Contracts Work
An attacker deploys a proxy contract that initially presents benign functionality, such as a simple token swap or staking interface. The user, trusting the frontend, calls approve() on their token contract, setting the proxy address as the spender. The proxy then holds an allowance from the user.
After enough users have approved the proxy, the attacker upgrades the implementation to a malicious contract. This new implementation contains a transferFrom call that drains the user's tokens. Critically, even if the user later calls approve() to set the allowance for the proxy to zero, that revocation works. However, many users mistakenly revoke the allowance for the implementation address (which they never approved), thinking that will stop the attack. This is ineffective because the proxy's allowance is linked to the proxy address, not the implementation.
Some proxy designs also allow the owner to 'transfer' the allowance to a different proxy or contract via internal storage, making on-chain revocation even harder.
3. Real-World Example: The Proxy Upgrade Heist
Consider a representative attack pattern seen in phishing campaigns that impersonate well-known DeFi frontends. The attacker deploys a proxy contract mimicking a legitimate protocol's interface. Users are prompted to approve the proxy address. After accumulating approvals, the attacker upgrades the implementation to a drainer contract that transfers all approved tokens to a wallet. Affected users who tried to revoke by setting approve(implementation, 0) failed to stop the theft because the proxy address still had its original approval.
This attack exploits the common confusion between proxy and implementation addresses.
Lesson: Always verify the exact address you are approving—it should be the proxy, not the implementation under it. Revoke the proxy address, not the implementation.
4. Comparison Table: Standard Approval vs Proxy-Based Approval Scam
| Aspect | Standard ERC-20 Approval | Proxy-Based Approval Scam |
|---|---|---|
| Spender address | Static contract | Proxy contract (upgradeable) |
| Logic after approval | Fixed behavior | Can change via upgrade |
| Common revocation mistake | Rare (single address) | User revokes implementation, not proxy |
| Attacker's ability to bypass revocation | Not possible | By upgrading implementation or using internal allowance forwarding |
| Detection | Straightforward via block explorer | Requires auditing the proxy's ownership and upgradeability |
5. Bypassing Revocations: The Core Mechanics
Attackers bypass token approval revocations in several ways using proxy contracts:
- Revocation of wrong address: As mentioned, users often target the implementation contract's address. The proxy's allowance remains untouched.
- Upgrade after revocation: An attacker can upgrade the proxy to a malicious implementation that ignores the zero allowance (though the ERC-20 token contract enforces it). However, some tokens have flawed allowance implementations.
- Proxy with storage-based allowance mapping: The proxy contract may store its own 'internal allowance' that overrides the on-chain allowance. The proxy then calls
transferFromfrom a different contract that does have on-chain approval. This requires the user to also approve the internal contract. - CREATE2 and deterministic addresses: Attackers precompute the address of a new proxy (using CREATE2) and trick users into approving that address. Even if the user revokes the old proxy, the new one already has an allowance from a previous approval (if the user was tricked into approving it).
These methods make it critical to not only revoke but also to verify the spender's upgradeability and ownership.
6. The Role of Multisig and Timelocks in Proxy Ownership
Many legitimate DeFi protocols use multisig wallets or DAO governance to control proxy upgrades. However, attackers can deploy proxy contracts with a single owner (themselves) or a compromised multisig. Users should check who controls the proxy. If the owner is an EOA (externally owned account), the proxy is high-risk.
Even with a timelock, an attacker can front-run a revocation transaction by upgrading the proxy before the user's transaction confirms. This window exists because revocation is not atomic with the upgrade. Using tools like Etherscan's Proxy Reader or OpenZeppelin Defender can reveal the admin address and upgrade history.
To mitigate, some tokens implement a revokeAll() function that removes approvals for all spenders, but this is rare.
7. How to Detect and Audit Proxy Contract Risks
Before approving any contract, follow these audit steps:
- Check the contract source code: On Etherscan, verify if the contract is a proxy (look for patterns like
delegatecallandimplementationvariable). - Identify the implementation address: Use
implementation()or storage slot methods (ERC-1967). - Review the upgrade mechanism: Is there a
upgradeTo()function? Who is the owner? Use tools like OpenZeppelin Upgrades Plugins or Tenderly to simulate upgrades. - Analyze the proxy's allowance: After approval, revoke the proxy address, not the implementation. Use Revoke.cash or Etherscan Token Approvals to see all allowances.
- Check for selfdestruct: Some proxies include a selfdestruct function that can remove the proxy, but approvals remain on the token contract. An attacker can redeploy a new contract at the same address (impossible) or use a different address.
8. Prevention Strategies for DeFi Users
To protect yourself from approval scams via proxy contracts:
- Approval minimization: Use the
increaseAllowance()anddecreaseAllowance()functions to adjust allowance without revoking entirely. Prefer token contracts that support these to reduce trust. - Use dedicated revocation tools: Regularly scan your approved spenders with Revoke.cash or Etherscan. Pay attention to proxy contracts; revoke the proxy address specifically.
- Hardware wallet and transaction simulation: Use Rabby Wallet or MetaMask with transaction simulation to see what
approve()actually does. Avoid blind signing. - Check contract ownership: If a contract you're approving has an owner that is a single EOA, do not approve. Prefer protocols with multisig or timelocks.
- Monitor proxy upgrades: Subscribe to alerts for proxy upgrade events on the contracts you have approved. This can be done via Etherscan or The Graph.
9. Future Outlook: Immutability vs Upgradeability Trade-offs
The DeFi ecosystem is gradually moving toward immutable contracts where possible. Uniswap V4 uses hooks but keeps core contracts immutable. Liquity and MakerDAO use immutable core contracts with peripheral proxies. However, many protocols still rely on upgradeable proxies for bug fixes and feature additions.
Users should demand transparency: clear documentation of proxy governance, upgrade delay (timelock), and open-source proxy implementations. A new standard, ERC-6551 (Token Bound Accounts), introduces proxy contracts for NFTs, which could create new vectors for approval scams if not properly audited.
Until then, the best defense is education: understand what you approve, revoke the correct address, and never trust a proxy that can be upgraded by a single entity.
Common mistakes to avoid
- Revoking approval for the implementation contract address instead of the proxy address.
- Assuming all proxies are benign because they are used by well-known protocols; attackers can deploy fake proxies that mimic the same interface.
- Ignoring the upgradeability status of a contract before approving it; assuming approval is safe if the contract has a non-zero owner.
- Using the same approval amount for all dApps; not setting a custom allowance or using the minimal amount needed.
- Failing to regularly monitor and revoke unused approvals, especially for proxy contracts that may have been compromised.
Frequently asked questions
Can proxy contracts bypass token approval revocations by changing their own address?
No, a proxy contract cannot change its own address. However, attackers can use CREATE2 to deploy a new proxy at a predictable address that already has an approval from a previous transaction (if the user was tricked into approving it). They can also use storage-based allowance systems to maintain control after revocation.
How can I tell if a contract I approved is a proxy?
Use a block explorer like Etherscan. Look for the 'Read as Proxy' option. Check if the contract has a function like `implementation()` or storage slots defined in ERC-1967. Tools like OpenZeppelin Defender and Tenderly can also detect proxies.
Should I never approve any upgradeable proxy contract?
Not necessarily. Many reputable DeFi protocols use upgradeable proxies for legitimate reasons. The key is to only approve proxies that are governed by a multisig or DAO with a timelock, and to regularly revoke unused allowances. Avoid approving proxies owned by a single EOA.
What is the difference between revoking approval for the proxy vs. the implementation?
The approval is tied to the address you called `approve()` on. That address is the proxy (the contract you interacted with). The implementation is a separate contract that the proxy delegates to. Revoking the implementation does nothing to the proxy's allowance. You must revoke the proxy address.
Can I be safe by only using unlimited approvals?
No, unlimited approvals are riskier. If you approve unlimited amount to a proxy, and the proxy is upgraded maliciously, the attacker can drain your entire balance. Always use minimal allowances and revoke them after use.
Related reading
Track the entities behind the concepts
DeFi Intel maps 11,000+ protocols, tokens and companies to a typed knowledge graph — with live data, incidents and regulation.