LI.FI incident, 2024-07-16
What happened to LI.FI?
On 16 July 2024 an attacker used a newly deployed LI.FI contract facet that skipped call validation to pull about $11.6M of stablecoins from 153 wallets that had given LI.FI infinite token approvals on Ethereum and Arbitrum. LI.FI disabled the facet and later reimbursed affected users; bridged funds in transit were not the target.
Sources: LI.FICointelegraphBlockSecDefiLlama
Key facts
- Date (UTC)
- Protocol
- LI.FI Diamond contract (the API/SDK behind Jumper and many wallet bridges)
- Reported loss
- ≈ $11.6M in USDC, USDT and DAI from 153 wallets (LI.FI's incident report); early on-chain tallies by rekt.news and DefiLlama put it at $9.73M LI.FIThe BlockCointelegraphBlockSecrekt.newsDefiLlama
- Root cause
- Token-approval abuse — a newly deployed facet (GasZipFacet) allowed arbitrary calls without the whitelist check used elsewhere, so wallets with infinite approvals were drained LI.FIBlockSec
- Chains
- Ethereum, Arbitrum
- Recovery
- Users made whole
- Official post-mortem
- Incident Report 16th July
Timeline
All dates and times in UTC.
- 2024-07-11 — GasZipFacet deployed (five days before the attack) to add gas refuelling to bridge transactions. BlockSec
- 2024-07-16 — Nearly 100 exploit transactions move ≈ $11M of USDT, USDC and DAI to the attacker within 30 minutes; LI.FI disables the facet on all chains. BlockSec
- 2024-07-18 — LI.FI publishes its incident report and a voluntary compensation plan. LI.FI
- 2024-07 → 2024-10 — Attacker launders the ETH, 99.9% through Tornado Cash. BlockSec
Where did the funds go, and was anything recovered?
LI.FI announced a voluntary plan to reimburse 100% of affected users (Cointelegraph); BlockSec later reported that the plan was carried out and affected users were fully reimbursed (BlockSec).
The stolen stablecoins were swapped to ETH within about 30 minutes; over the following ~3 months 99.9% was moved into Tornado Cash and a small part sent to the exchange eXch (BlockSec). We found no report of the stolen assets themselves being recovered.
Which routes and bridges were affected?
Only wallets that had given the LI.FI Diamond contract an infinite token approval on Ethereum or Arbitrum were at risk; finite approvals — the default in the LI.FI API, SDK and widget — were not affected (LI.FI). Bridge routes themselves were not attacked: the loss came from token approvals left on the router contract, not from funds in transit.
Our reviews of the bridges involved: Jumper (LI.FI)
Why did it happen?
LI.FI's contract is a "diamond": one address with many plug-in facets. Most facets call DEXs and bridges only through a whitelist of approved targets and functions. The new facet reused the LibSwap helper, which can make arbitrary calls, but the whitelist check was missing; LI.FI attributes this to an individual human error in the deployment review (LI.FI). Anyone could therefore make the LI.FI contract call transferFrom on a token and pull funds from any wallet that had approved it without a limit.
The pattern is not new. LI.FI suffered a smaller approval exploit (≈ $600K, 29 wallets) in March 2022 (Cointelegraph), and Socket/Bungee lost ≈ $3.3M the same way in January 2024. Aggregator routers are attractive targets because users approve them once and use them for many routes, so a single unchecked call path exposes every standing approval. The damage was capped by LI.FI's choice of finite approvals as the default — users who accepted a front-end's "infinite" option carried the risk.
For bridge users the lesson is about approvals, not about bridging: the bridge leg was never touched, yet wallets that had used LI.FI weeks earlier lost money.
Aggregators also add a layer users rarely see: the front-end (Jumper, a wallet, a dApp) chooses the route, but the approval goes to the aggregator's contract. Your risk therefore includes every module that contract can call.
What should users have done then, and what should they do now?
At the time
The protective step was to revoke the LI.FI Diamond approval (0x1231…f4eae) on Ethereum and Arbitrum as soon as the alert went out — revoke tools such as the explorer's token-approval page do this in one transaction — and to avoid granting infinite approvals in the first place.
Now
Approve only the exact amount you are bridging, and periodically revoke approvals to routers you no longer use; this applies to every aggregator, including Jumper (LI.FI) and Bungee. When a front-end asks for an approval, check the spender address against the project's documented contracts. On upswap we never ask for approvals: we show quotes only.
What is still unverified?
- 待核实 Why the figures differ is not explained by either side: LI.FI's report (≈ $11.6M, 153 wallets; echoed by The Block) vs rekt.news and DefiLlama ($9.73M, the stablecoins later swapped to 2,857 ETH); Cointelegraph counts 156 wallets.
- 待核实 LI.FI announced on 23 July 2024 that it had started its voluntary compensation scheme; completion is reported only by BlockSec — we have not found LI.FI's own completion notice.
Sources
6 independent publishers. Links checked on the date shown.
- Incident Report 16th July — LI.FI · Official · checked
- Li.Fi releases incident report following $11M hack — Cointelegraph · Media · checked
- Illicit fund flow case study: LI.FI attack (MetaSleuth) — BlockSec · Security firm · checked
- DefiLlama Hacks — LI.FI, 2024-07-16 — DefiLlama · Database · checked
- LiFi/Jumper - Rekt — rekt.news · Security firm · checked
- LI.FI publishes incident report about nearly $12 million hack, blames 'human error' — The Block · Media · checked
- We have initiated the voluntary compensation scheme (X, 23 Jul 2024) — LI.FI · Official · checked
How do I cite this page?
Burn, A. / upswap.io (2026). LI.FI incident (2024-07-16). Updated 2026-10-24. https://upswap.io/incidents/lifi-2024#summary. CC BY 4.0. Accessed ____.
Stable anchors: #summary #facts #timeline #funds #affected #analysis #then #now #sources #cite