Dashboard · VantagePlanned

Exploited Contract Approvals: Is Your Wallet Still Exposed?

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

Open token approvals to contracts that have been exploited, per wallet and per incident, with the value a flaw could still take.

ShareEmail itvoltfincrypto.com/apps/exploited-contract-approvals
Blueprint

What the dashboard will show.

The dashboard as it will open in Vantage. Each figure is named here and arrives with its receipt; until its data is published, its place stays empty.

  • Wallet address
  • Chain

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.

Figuretoken_approvalsAwaiting data

Value still exposed

USD

The smaller of each allowance and the wallet's token balance, summed and valued at oracle prices.

Figuretoken_holders_snapshotAwaiting data

Incidents involved

count

Distinct incidents whose exploited contracts this wallet still has approvals to.

Figuresecurity_incidentsAwaiting data

Chains with exposure

count

Covered chains where this wallet has at least one open approval to an exploited contract.

Figuretoken_approvalsAwaiting data

Open approvals to exploited contracts

Each approval's token, chain, spender, incident, incident date, allowance, value exposed and the transaction that granted it.

Tabletoken_approvalsAwaiting data

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.

Notetoken_approvals

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.

Figuresecurity_incidentsAwaiting data

Value still exposed, all wallets

USD

Value all wallets could still lose through open approvals to exploited contracts, at the latest block.

Figuretoken_approvalsAwaiting data

Exposed value by incident

USD

Value still exposed through each incident's exploited contracts at the latest block.

Bar charttoken_approvalsAwaiting data

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.

Tabletoken_approvalsAwaiting data

Wallet address
Any EVM address
Chain
Every covered chain
About

What it answers, and for whom.

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.

Method

How it will be measured.

Every figure will be read at a block, kept with its source and its exact read, and open a receipt anyone can re-check.

How receipts work →
  1. 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.
  2. 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.
  3. 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.
  4. 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.

The data it needs

Chain data, with some off-chain sources

  • token_approvalsTo buildToken approvalsActive ERC-20 and NFT approvals per wallet and spender, with the spender's label and when the approval was set.
  • security_incidentsTo buildHacks and exploitsA registry of exploits, hacks and rug pulls: date, chain, protocol, attack type, amount lost and the transactions involved.
  • token_holders_snapshotTo buildToken holders and concentrationHolder counts, top holders and concentration shares of registry tokens at a pinned block, with contract and exchange labels.
  • native_prices_dailyTo buildOracle prices by dayReference prices of major assets read from on-chain oracle feeds (Chainlink latestRoundData) at each day's last block, with each round's update time.
  • A reviewed registry of exploited spender contracts by incident, recorded with each post-mortem (off-chain)
  • ERC-20 Approval and ApprovalForAll logs naming those spenders, on each covered chain
  • allowance(owner, spender), isApprovedForAll, balanceOf and Permit2 allowances at the latest block
Questions

Questions people ask.

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.

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.

Build Exploited Contract Approvals: Is Your Wallet Still Exposed? on verified data.

Start free in Voltfin Studio: boards, tables and reports where every number opens its receipt. Tell us which data you need first and we will build it next.