OAK — OnChain Attack Knowledge

Worked example · 2022-07

Li.Fi v1 diamond-facet vulnerability — EVM — 2022-07

Loss
approximately $600K extracted from the Li.Fi diamond-proxy contract on Ethereum via a facet-addition vulnerability in the protocol's v1 architecture. This incident is structurally distinct from the July 2024 Li.Fi exploit (~$11.6M, examples/2024-07-li-finance.md): the 2022 v1 exploit involved a different facet, a different vulnerability class, and a smaller scale — but established the diamond-pattern facet-audit gap as a recurring vulnerability surface for the same protocol, making Li.Fi the multi-incident anchor for T9.008.
OAK Techniques observed
OAK-T9.008 (Diamond-Pattern Facet-Audit Incomplete) — primary; the Li.Fi v1 diamond contract deployed a facet whose logic path contained a vulnerability that was outside the scope of the protocol's audit coverage. The audited facets matched their audited bytecode; the gap was in a facet added (or modified) outside the audit scope. OAK-T9.004 (Access-Control Misconfiguration) — composing; the facet-level vulnerability was an access-control gap that allowed an attacker to invoke a privileged function path.
Attribution
pseudonymous. No public named-individual attribution. The attacker address is identifiable on-chain; no regulatory enforcement action or named-individual attribution was published for the v1 incident.
Key teaching point
The Li.Fi v1 (2022) and Li.Fi v2 (July 2024) exploits are the canonical multi-incident anchor demonstrating that the diamond-pattern facet-audit gap (T9.008) is a recurring structural vulnerability class, not a one-off operational error. The same protocol, the same diamond architecture, the same audit-scope limitation — two exploits, two years apart, different facets, both attributable to facets that were outside (or at the margin of) the audit scope. The recurrence establishes that the diamond pattern's structural property — the audit scope is bounded by the facets present at the time of the audit, while the facet set is unbounded and extensible post-audit — creates a standing vulnerability surface that persists across protocol versions and audit engagements.

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.

Techniques demonstrated (2)