# Exploited Contract Approvals: Is Your Wallet Still Exposed?

> Check open approvals to hacked contracts: allowances still pointing at exploited routers and spenders, the value still exposed per wallet and revocations since.

Markdown copy of https://voltfincrypto.com/apps/exploited-contract-approvals

**Question:** Does this wallet still have open token approvals to exploited contracts, and how much could still be taken through them?

- Kind: Dashboard in Voltfin Vantage
- Topic: [Security and risk](https://voltfincrypto.com/topics/security)
- Chains: Ethereum, Base, Arbitrum, OP Mainnet, BNB Chain, Polygon
- Status: Planned. The data is not published yet, so this page states no figure; each figure will open its receipt when it is.

Some exploits drain not a protocol's own funds but its users' wallets. When a router or aggregator has a flaw that lets anyone make it call transferFrom, every token that users approved to it can be taken, as happened to SushiSwap's RouteProcessor2 in 2023, Socket in January 2024 and LI.FI in July 2024. Those approvals stay valid until their owners change them, often long after the incident.

This dashboard keeps a reviewed list of exploited spender contracts and reads every allowance still pointing at them. Check one wallet to see its open approvals to exploited contracts and the value each exposes, or look across all wallets to see how many are still exposed after each incident and how quickly approvals were revoked.

Exposure is the value a spender could actually move: the smaller of the allowance and the wallet's balance at the latest block. Each row names the token contract and the spender, so the approval can be closed on the right chain.

## Blueprint

### Check a wallet

One wallet's open approvals to exploited contracts and the value each exposes.

- **Approvals to exploited contracts** (count): Open allowances and NFT approvals from this wallet to spenders in the exploited-contract registry, at the latest block.
- **Value still exposed** (USD): The smaller of each allowance and the wallet's token balance, summed and valued at oracle prices.
- **Incidents involved** (count): Distinct incidents whose exploited contracts this wallet still has approvals to.
- **Chains with exposure** (count): Covered chains where this wallet has at least one open approval to an exploited contract.
- **Open approvals to exploited contracts**: Each approval's token, chain, spender, incident, incident date, allowance, value exposed and the transaction that granted it.
- **How to close each approval**: The call that closes each open approval, approve with zero or setApprovalForAll with false, on the token contract and chain named in its row.

### Incidents

Exposure left behind by each approval exploit, across all wallets.

- **Exploited spenders tracked** (count): Contracts in the registry that attackers used to move approved tokens, across covered chains.
- **Value still exposed, all wallets** (USD): Value all wallets could still lose through open approvals to exploited contracts, at the latest block.
- **Exposed value by incident** (USD): Value still exposed through each incident's exploited contracts at the latest block.
- **Exposure after each incident**: Each incident with its spenders, wallets exposed at the attack block, wallets still exposed, approvals revoked since and value exposed now.

Filters: Wallet address (Any EVM address); Chain (Every covered chain).

## How it will be measured

- Exploited spenders come from a reviewed registry of incidents in which an attacker used approvals granted to a contract, each with its post-mortem as the source and every affected contract address.
- Open approvals are rebuilt from ERC-20 Approval and NFT ApprovalForAll logs to those spenders and confirmed with allowance(owner, spender) or isApprovedForAll at the latest block; Permit2 allowances are read from Permit2.
- Value exposed is the smaller of the allowance and the owner's balanceOf at the same block, valued at oracle prices, since a spender can never move more than the wallet holds.
- Approvals stay listed until they are set to zero, even when the contract was paused or patched, because the approval itself remains valid and a pause can be lifted.

## Data it needs

- `token_approvals` (to build): Active ERC-20 and NFT approvals per wallet and spender, with the spender's label and when the approval was set.
- `security_incidents` (to build): A registry of exploits, hacks and rug pulls: date, chain, protocol, attack type, amount lost and the transactions involved.
- `token_holders_snapshot` (to build): Holder counts, top holders and concentration shares of registry tokens at a pinned block, with contract and exchange labels.
- `native_prices_daily` (to build): Reference prices of major assets read from on-chain oracle feeds (Chainlink latestRoundData) at each day's last block, with each round's update time.
- Source: A reviewed registry of exploited spender contracts by incident, recorded with each post-mortem (off-chain)
- Source: ERC-20 Approval and ApprovalForAll logs naming those spenders, on each covered chain
- Source: allowance(owner, spender), isApprovedForAll, balanceOf and Permit2 allowances at the latest block

## Questions

### What happens to my approvals when a protocol I used is hacked?

Nothing, unless you change them. An approval lets a spender contract move your tokens until you set it to zero. If the exploit worked through approvals, a wallet that still has an allowance and a balance can be drained through the same flaw, which is what this dashboard checks.

### How did the LI.FI and Socket approval exploits work?

Both contracts could be made to execute an arbitrary call supplied by the caller. Attackers used that to call transferFrom on tokens users had approved to the contract, moving the tokens to themselves. Users who had given unlimited approvals could lose their whole balance of those tokens.

### How do I revoke an approval to a hacked contract?

Call approve with the spender's address and an amount of zero on the token's contract, on the chain where the approval was given; for NFTs, call setApprovalForAll with false. Many wallets offer this in their settings. Each row names the token, the spender and the chain.

### Why is the exposed value lower than the approval?

An approval is a ceiling, often unlimited, but a spender can only move what the wallet holds. Exposure is the smaller of the allowance and the current balance, so an unlimited approval on an empty token shows no exposure until a balance arrives.

### Are Permit2 approvals affected by these exploits?

They can be. If the exploited contract was a Permit2 spender, a Permit2 allowance to it exposes the tokens just as a direct approval would. The dashboard reads Permit2 allowances as well as direct ones.

## Glossary

- **Allowance**: The amount of a token a spender contract may move from an owner's wallet, set by an approval and reduced as the spender uses it.
- **Arbitrary call flaw**: A bug that lets anyone make a contract call any function on any target, such as transferFrom on tokens approved to it.
- **Permit2**: A shared approval contract: users approve tokens to it once, and it grants time-limited allowances to individual spenders.

## Related apps

- [Token Approval Checker: Open Allowances by Wallet](https://voltfincrypto.com/apps/token-approval-checker)
- [Wallet Drainer Tracker: Phishing Losses by Month](https://voltfincrypto.com/apps/wallet-drainer-tracker)
- [Crypto Hack Tracker: Exploits and Losses This Year](https://voltfincrypto.com/apps/crypto-hack-tracker)
- [EIP-7702 Delegation Checker: Is Your Wallet Delegated?](https://voltfincrypto.com/apps/eip-7702-delegation-checker)
- [Token Safety Check: Mint, Blacklist and Owner Powers](https://voltfincrypto.com/apps/token-safety-check)
- [North Korea Crypto Hacks: Lazarus Group Theft Tracker](https://voltfincrypto.com/apps/north-korea-crypto-hacks-tracker)

Build it in Voltfin Studio: https://app.voltfincrypto.com/signup?next=%2F