Worked example · 2022-07
Li.Fi v1 diamond-facet vulnerability — EVM — 2022-07
Summary
Li.Fi is a cross-chain DEX-and-bridge aggregator. Its core contract architecture from v1 used a diamond-proxy (EIP-2535) pattern: a single diamond contract delegates calls to multiple facet contracts, each implementing a slice of the protocol's surface.
In July 2022, an attacker exploited a vulnerability in one of Li.Fi's v1 diamond facets. The affected facet contained an access-control gap that allowed the attacker to invoke a privileged function path — extracting approximately $600K from the diamond contract. The specific facet was either not covered by the protocol's audit or was added/modified post-audit without re-auditing. The audited facets matched their audited bytecode; the audit scope simply did not extend to the vulnerable facet.
The v1 incident established the pattern that would recur in the July 2024 v2 exploit (~$11.6M): a diamond-pattern protocol with a legitimate audit, audited facets that matched their audited bytecode, and a post-audit (or audit-scope-marginal) facet that introduced an exploitable vulnerability.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| pre-2022-07 | Li.Fi deploys v1 diamond contract on Ethereum; audit engagement covers some facets but not all; post-audit facet additions/modifications occur | T9.008 surface present (latent) |
| 2022-07 (attack window) | Attacker identifies the unaudited/under-audited facet; exploits access-control gap to invoke privileged function path | T9.008 + T9.004 extraction |
| 2022-07 | Approximately $600K extracted from the Li.Fi diamond | T9.008 extraction |
| 2022-07 onward | Li.Fi patches the affected facet; protocol operations continue | (operator response) |
| 2022–2024 | Li.Fi v2 architecture evolves; diamond pattern retained; operational pattern of incremental facet addition continues | (latent T9.008 surface persists) |
| 2024-07-16 | Li.Fi v2 exploit: ~$11.6M extracted via a different facet with a missing-input-validation gap (see examples/2024-07-li-finance.md) |
T9.008 recurrence |
What defenders observed
The v1–v2 recurrence establishes T9.008 as a structural class, not an operational error. Li.Fi was not an incompetent operator — it was a protocol that used the diamond pattern as designed (modular facet additions for new integrations) and obtained legitimate audits. The structural feature that produced both exploits is the diamond pattern's unbounded facet set: audits cover the facets present at the time of the audit, but the protocol's operational need to add new facets (for new bridge integrations, new DEX routers, new fee modules) continuously creates post-audit facets outside the audit scope. The v1 incident was a warning that did not propagate into a structural change in the protocol's audit discipline — the same surface recurred at 19x the scale in 2024.
The audit claim was truthful but misleading. In both the v1 and v2 incidents, Li.Fi could truthfully claim that the audited facets matched their audited bytecode and that a legitimate audit firm had reviewed the protocol. The gap was not in the audit's accuracy but in its scope: the audit covered Facets A, B, C; the vulnerability lived in Facet D, which was added after (or at the margin of) the audit. This is the structural T9.008 audit-scope gap: a truthful audit claim about a subset of facets is presented as if it covers the entire diamond.
The diamond pattern's modularity is both its architectural advantage and its audit-scope vulnerability. The ability to add facets without redeploying the entire diamond is the pattern's core architectural benefit — it enables modular upgrades, smaller per-deployment bytecode, and incremental integration of new functionality. But the same property means that the diamond's security surface is the union of its facets, and the union grows over time while the audit scope is fixed at a point in time. A protocol that adds facets without re-auditing is a protocol whose security surface is expanding beyond its audited boundary.
What this example tells contributors writing future Technique pages
T9.008 is a recurrence-class Technique — multi-incident anchors on the same protocol are the strongest evidence of structurality. The Li.Fi v1 (2022) and v2 (2024) pair is the canonical multi-incident anchor for T9.008. Future contributors documenting T9.008 cases should track protocol-level recurrence: a protocol that experiences one diamond-facet exploit and does not change its audit discipline is a protocol with a standing T9.008 surface regardless of the specific facet that was patched.
The Li.Fi v1 case is the smaller but structurally prior anchor. At $600K, the v1 incident was an order of magnitude smaller than the v2 incident (~$11.6M). The scale difference is instructive: the structural surface (unaudited facets in a diamond pattern) was present in both; the smaller scale of v1 reflects the attacker's more limited working capital and the protocol's lower TVL at the time, not a less-severe vulnerability. The lesson is that small-scale diamond-facet exploits should be treated as structural T9.008 signals, not dismissed as immaterial because of the dollar figure.
The audit-scope gap is detectable pre-exploit. A defender querying the diamond's Louper interface to enumerate the current facet set and comparing against the published audit report's facet list would identify the T9.008 gap before exploitation. The detection surface lives at the audit-report-vs-diamond-Louper comparison layer, not at the on-chain runtime layer. The v1 and v2 Li.Fi incidents are evidence that this pre-exploit detection was not operationalised — neither the protocol nor its users queried the diamond's Louper interface against the audit scope.
Public references
- Li.Fi v1 2022 exploit: Rekt News incident report (~$600K); Li.Fi v1 post-mortem.
- Li.Fi v2 July 2024 exploit: Li.Fi official post-mortem; Cyfrin / Solodit post-incident technical write-up; BlockSec PhalconHQ forensic analysis; Halborn post-incident analysis; Rekt News incident report (~$11.6M).
[trailofbitsdiamond2023]— Trail of Bits diamond-pattern audit-process technical foundations.- EIP-2535 diamond pattern specification; Louper.dev diamond-inspection tooling.
Discussion
The Li.Fi v1 case is OAK's smaller-but-prior anchor for T9.008, paired with the Li.Fi v2 July 2024 case as the multi-incident structural anchor. The two cases together establish that the diamond-pattern facet-audit gap is a recurring vulnerability class that persists across protocol versions, audit engagements, and operator-awareness levels.
The structural lesson is that diamond-pattern audit claims should be indexed by facet set, not by protocol name. "Li.Fi is audited" is a misleading claim because the diamond pattern permits post-audit addition of facets outside the audit scope. The correct claim is "Li.Fi facets A, B, C (as enumerated in Audit Report X, published on date Y) are audited. Query the diamond's Louper interface for the current facet set. Facets added after date Y are not covered by Audit Report X." The v1-to-v2 recurrence demonstrates that this indexing discipline was not adopted between 2022 and 2024 — and that its absence created a standing T9.008 surface that was exploited twice.
For OAK's broader coverage, the Li.Fi v1 case provides the temporal-depth dimension to the T9.008 technique: the surface is not a 2024 discovery but a structural property of the diamond pattern observable from the protocol's earliest deployments. Contributors writing future T9.008 entries should track protocol-level recurrence as the strongest evidence of structurality, and should cross-reference the v1 and v2 Li.Fi cases as the canonical multi-incident anchor.