Worked example · 2023-11

KyberSwap Elastic tick-state-manipulation exploit — multi-chain — 2023-11-22

Loss: approximately $48M at time of exploit, drained from KyberSwap Elastic concentrated-liquidity AMM pools across multiple chains. Per-chain figures from public post-mortems (KyberSwap, Halborn, BlockSec, ChainLight, Hacken): Ethereum mainnet ~$20M, Arbitrum ~$20M, Optimism ~$5M, Polygon ~$2M, Base ~$1M, with smaller residuals on additional Elastic deployments. Aggregate post-recovery loss settled in the low-tens-of-millions range after partial recovery via grey-hat / negotiation channels.
Recovery: partial — limited grey-hat / negotiation-channel returns. The attacker explicitly conditioned full return of proceeds on a set of governance-and-operational demands (see "Discussion") that went beyond the conventional bug-bounty / ten-percent-bounty norm of post-incident negotiated returns. Partial returns occurred; the residual was not recovered in the negotiation window. Final remediation included KyberSwap-side compensation governance proposals and a structural pause / wind-down on the Elastic product line.
OAK Techniques observed: OAK-T9.004 (Access-Control / Logic Misconfiguration in tick-boundary state-machine accounting) as the extraction mechanism; OAK-T9.005 (arithmetic-precision-loss / inverse-square-root tick boundary edge case) as the underlying arithmetic flaw; OAK-T9.002 (Flash-Loan-Enabled Exploit) as the working-capital precondition. OAK-T8 broadly construed — the attacker's on-chain post-event message demanding "complete executive control of the company" is structurally an operator-extortion behaviour pattern; the Technique fit is approximate (T8 in OAK v0.1 covers supply-chain and software-distribution attacks, not extortion-as-recovery-channel), and contributors writing the v0.x corpus should consider whether post-event extortion-as-recovery-channel warrants its own Technique entry. See "Discussion".
Attribution: pseudonymous. The attacker self-identified via on-chain encrypted messages and conducted a public pseudonymous communication campaign, but no industry forensics provider has converted the on-chain analysis into a named-individual claim, and the on-chain pseudonymity has remained intact through 2024–2025. No public OAK-G01 / state-actor attribution.
Key teaching point: concentrated-liquidity AMMs introduce a tick-state-machine attack surface that legacy-AMM defender intuition does not cover. KyberSwap Elastic is a Uniswap v3-style concentrated-liquidity AMM. The exploit was not on the swap-math layer but on the tick-boundary state-machine — the bookkeeping that tracks which liquidity ranges are active as the pool's price crosses tick boundaries. The attacker constructed a sequence of swap and liquidity operations that drove the pool's state across a tick boundary in a way that left the tick-active-liquidity bookkeeping inconsistent with the actual deposited liquidity, and then exploited the inconsistency to extract liquidity at unfavourable-to-pool ratios. The structural OAK lesson is that concentrated-liquidity primitives are a new attack surface class with new defensive baselines, and that the defender community's experience with constant-product (Uniswap v2-style) AMM safety arguments does not transfer cleanly.

Summary

KyberSwap Elastic was a Uniswap v3-style concentrated-liquidity AMM, deployed across Ethereum mainnet, Arbitrum, Optimism, Polygon, Base, and additional EVM chains. On 2023-11-22, an attacker exploited a complex flaw in the tick-boundary state-machine of KyberSwap Elastic to drain approximately $48M aggregate across all chains in a coordinated multi-chain attack window.

The proximate cause — per KyberSwap, Halborn, BlockSec, ChainLight, Hacken, and academic post-incident write-ups, all converging on the same root-cause description — was a precision flaw in the inverse-square-root computation used at tick boundaries combined with an access / accounting flaw in how the pool tracked active liquidity ranges as the price crossed those boundaries. The Uniswap v3 concentrated-liquidity model maintains, for each tick, the net liquidity delta that activates or deactivates as the price crosses that tick. The pool's overall behaviour across a swap is a state-machine traversal: at each tick crossing, the active-liquidity figure is updated by the per-tick delta. KyberSwap Elastic's implementation of this state-machine traversal had an edge case — combining (i) a swap that crossed a specific class of tick boundary, (ii) a precision rounding in the inverse-square-root price computation at that boundary, and (iii) a liquidity operation interleaved with the swap — under which the post-traversal active-liquidity state did not match the actual deposited liquidity. The mismatch was extractable: subsequent operations against the inconsistent state allowed the attacker to remove more liquidity than they had deposited, paid in a different asset than they had supplied.

The attacker, using flash-loaned working capital, executed the manipulation sequence across each chain's KyberSwap Elastic deployment in a coordinated multi-chain attack window. The aggregate ~$48M figure consolidates the cross-chain proceeds.

For OAK's purposes the incident is a clean T9.004 + T9.005 + T9.002 chain. The novel OAK contribution of the worked example is twofold: first, the concentrated-liquidity tick-state-machine as a new T9.004/T9.005 attack-surface class distinct from the constant-product AMM surface; second, the post-event operator-extortion demands as an unusual recovery-channel-and-Technique-fit edge case (see "Discussion") that the OAK v0.x corpus may need to address explicitly.

Timeline (UTC)

When	Event	OAK ref
Pre-event	KyberSwap Elastic deployed across Ethereum, Arbitrum, Optimism, Polygon, Base, and additional chains; tick-state-machine implementation contains the inverse-square-root precision flaw at specific tick boundaries	T9.004 + T9.005 surface (latent)
2023-11-22 (attack tx window, multi-chain)	Attacker takes flash loans on each target chain; executes the tick-boundary manipulation sequence on each chain's Elastic pools; extracts proceeds; repays flash loans; nets ~$48M aggregate	T9.004 + T9.005 + T9.002 extraction (multi-chain)
2023-11-22 (within hour)	KyberSwap operations team detects the coordinated drain across chains; pauses Elastic markets; communicates with chain teams and forensic firms	(operator response)
2023-11-22 onward	Halborn, BlockSec, ChainLight, Hacken publish post-incident write-ups converging on the same tick-boundary precision-and-accounting root cause	(transparency)
2023-11-22 evening	Attacker publishes on-chain encrypted message demanding "complete executive control of the company" and additional governance-and-operational concessions as condition for return of proceeds	(unconventional T8-adjacent recovery-channel signal)
2023-11-23 → 2023-12	Negotiation period; partial returns occur; attacker's broader demands not met; residual remains in attacker's controlled addresses	(recovery channel)
2023-12 onward	KyberSwap-side compensation governance proposals; structural pause / wind-down posture on the Elastic product line	(defender response, structural)
Continuing 2024	Pseudonymity intact; no public arrest or named-individual attribution; partial proceeds remain unrecovered	(state)

What defenders observed

Concentrated-liquidity AMMs are a new attack-surface class. Constant-product (Uniswap v2-style) AMMs have a smooth, monotone price-curve and a single liquidity figure; the safety arguments for them rely on the price-curve's continuity and on invariants like x·y = k. Concentrated-liquidity (Uniswap v3-style) AMMs replace the smooth curve with a piecewise curve indexed by ticks, with per-tick liquidity-delta bookkeeping that mutates as the pool's price crosses each tick. The state-machine introduced by this design is more expressive and more capital-efficient — but it is also a new surface area for accounting flaws and arithmetic-precision flaws that the constant-product safety arguments do not cover. KyberSwap Elastic is the OAK v0.1 canonical case for a tick-state-machine flaw being weaponisable; defenders working on concentrated-liquidity primitives should not transfer Uniswap v2 defender intuition without re-examination.
The flaw composed an arithmetic-precision issue with an accounting issue. Either alone might have been bounded; the combination — inverse-square-root precision rounding plus tick-state accounting that did not reconcile against the deposited-liquidity ground truth across the boundary traversal — was the extractable edge. T9.004 and T9.005 in this case are not alternative classifications; they are simultaneous classifications. Defender review of concentrated-liquidity primitives should examine arithmetic-precision and accounting-consistency as jointly in scope, not as separable concerns.
Multi-chain coordinated execution is a 2023+ attacker capability. The attacker executed the manipulation sequence across multiple chains' Elastic deployments in a single coordinated attack window — implying both pre-attack reconnaissance across all chain deployments and execution-side capacity (gas, bridge access, flash-loan availability) on each chain. Defender monitoring focused on a single chain's Elastic deployment in isolation would have caught the on-chain attack but not its multi-chain scale; the structural detection lesson is that multi-chain coordinated attacks against multi-chain protocols require multi-chain monitoring as a first-class operational capability.
The attacker's post-event extortion demand is structurally unusual and Technique-fit-edge-case. Conventional 2023-era post-incident attacker negotiation operates within a small set of patterns: silence (no return); ten-percent-bounty norm (return 90% in exchange for legal-immunity language); conscience-return (Euler / Mango pattern); or no return with full laundering. KyberSwap's attacker pattern — explicit demands for governance-and-operational control of the operator entity as a condition of return — is not a pattern OAK's v0.1 framework has a clean Technique entry for. T8 (supply-chain and software-distribution) is the closest fit on the operator-targeting dimension, but T8 in v0.1 does not specifically cover post-incident extortion of a hacked operator. v0.x contributors writing the corpus should consider whether post-event extortion-as-recovery-channel warrants its own Technique under T8 or under a dedicated T-tier; KyberSwap is the canonical reference if so. Until that classification settles, the worked example notes T8 broadly construed as the closest match.
Detection latency was operator-acceptable; recovery latency was effectively infinite for the bulk of proceeds. KyberSwap paused Elastic markets within an hour of the multi-chain drain. By that time the funds were already in attacker-controlled addresses on each chain. Recovery-by-negotiation recovered a fraction; the residual remained.

What this example tells contributors writing future Technique pages

T9.004 / T9.005 contributors should explicitly cover the concentrated-liquidity tick-state-machine sub-pattern. This is a new attack-surface class as of 2023, distinct from constant-product AMM logic flaws and from lending-protocol logic flaws. The defensive baselines (state-machine reconciliation against deposited-liquidity ground truth at every tick traversal; arithmetic-precision audit of the inverse-square-root computation across all tick boundaries; multi-chain monitoring of multi-chain deployments) are different from constant-product AMM defensive baselines. T9.004 and T9.005 contributors should cross-reference KyberSwap as the v0.1 reference for the concentrated-liquidity sub-pattern.
OAK v0.x should consider a dedicated Technique for post-event extortion-as-recovery-channel. The KyberSwap attacker's demands for executive control of the operator entity exceed the conventional ten-percent-bounty / conscience-return patterns and resemble a different kind of attacker behaviour — one in which the attack is the opening move of a longer-term operational-control campaign rather than a one-shot extraction with a bounty negotiation tail. Whether this is rare enough to remain a per-incident footnote, or recurring enough to deserve a Technique entry, is a v0.x corpus question. The author's lean is that if a second case in this shape emerges by 2025–2026, the Technique entry is warranted; until then KyberSwap is the standalone reference.
Multi-chain coordinated attacks deserve explicit Tactic-or-Mitigations attention. The multi-chain nature of the KyberSwap attack is not a Technique addition but a Tactic-level consideration: the attacker executed the same Technique-set across multiple chains in a single coordinated window. Mitigations contributors should treat multi-chain monitoring as a first-class defender-side capability — not just per-chain monitoring run multiple times — and KyberSwap is the canonical worked example for why per-chain-only monitoring is insufficient for multi-chain protocols.
T9.002 is the precondition that makes per-iteration tick-state-manipulation profits useful at scale. The KyberSwap, Onyx, Penpie, Beanstalk, and bZx worked examples all share the same precondition / extraction structure. Worked examples should preserve the distinction between the precondition Technique (T9.002 flash-loan working capital) and the extraction Technique (T9.005 / T9.004 / T9.001 / T9.003) rather than collapsing them.

Public references

[kyberswappostmortem2023] — KyberSwap official post-incident statement and per-chain breakdown of drained pools.
[halbornkyber2023] — Halborn post-incident technical write-up with function-level walkthrough of the tick-boundary precision flaw.
[blocksec kyber2023] — BlockSec forensic analysis of the KyberSwap attack including the multi-chain transaction-trace breakdown.
[chainlightkyber2023] — ChainLight independent forensic analysis with bytecode-level annotations of the inverse-square-root precision flaw.
[hackenkyber2023] — Hacken post-incident analysis covering affected pools and the multi-chain coordination dimension.
[merklesciencekyber2023] — Merkle Science flow-of-funds analysis covering the per-chain proceeds tracking and the partial-recovery negotiation channel.
[zhou2023sok] — academic taxonomy classifying logic-misconfiguration and arithmetic-correctness as primary DeFi vulnerability classes.

Citations

[kyberswappostmortem2023] — KyberSwap operator post-mortem.
[halbornkyber2023] — Halborn KyberSwap post-mortem.
[blocksec kyber2023] — BlockSec KyberSwap forensic.
[chainlightkyber2023] — ChainLight KyberSwap analysis.
[hackenkyber2023] — Hacken KyberSwap analysis.
[merklesciencekyber2023] — Merkle Science flow-of-funds.
[zhou2023sok] — academic SoK classification.

Discussion

KyberSwap is OAK's reference case for two distinct features held in the same incident: the concentrated-liquidity tick-state-machine sub-pattern as a new T9.004/T9.005 attack surface, and the post-event operator-extortion recovery channel as a Technique-fit-edge-case that v0.x may need to address.

On the Technique side, KyberSwap Elastic's exploit is the v0.1 canonical case for concentrated-liquidity-specific accounting flaws. The Uniswap v3 design has been extensively studied in the academic and industry literature and is generally considered well-engineered; KyberSwap Elastic was a v3-derivative implementation, and its specific flaw was in the implementation of the state-machine traversal, not in the v3 design itself. The teaching point is structural: implementations of concentrated-liquidity primitives need a different defensive baseline than implementations of constant-product primitives, and the Uniswap v3 reference implementation's safety arguments do not automatically transfer to derivative implementations. Worked examples documenting subsequent concentrated-liquidity-class incidents (where they emerge) should cross-reference KyberSwap as the cohort precedent.

On the recovery side, the operator-extortion pattern is unusual and noteworthy. Conventional 2023-era attacker post-incident negotiation operates within a small set of patterns; KyberSwap's pattern of demanding executive control of the operator entity as a condition of return is a different shape. Whether this is a one-off — perhaps reflecting the specific attacker's psychological profile — or the leading edge of a recurring pattern (where attackers treat large-loss exploits as the opening move of an operator-takeover campaign rather than a one-shot extraction) is a v0.x corpus question. The author's lean is that it is closer to the leading-edge case than to a one-off, on the ground that 2024–2025 has seen multiple incidents with attacker-side communications departing from the conventional bounty-negotiation script (in different directions); a Technique entry for post-event extortion-as-recovery-channel is plausibly warranted in v0.x with KyberSwap as the canonical reference.

Three open questions remain for OAK v0.x. First, whether the concentrated-liquidity tick-state-machine sub-pattern of T9.004/T9.005 warrants its own Technique ID or stays within the broad construction with sub-class footnoting. Second, whether post-event extortion warrants a new Technique under T8 or as a fresh T-tier. Third, whether multi-chain coordinated execution should be treated as a Tactic-level Mitigations theme (defender-side: multi-chain monitoring as a first-class capability) or as a per-incident reporting field. The author's leans, in order: revisit in v0.x with sub-class footnoting in v0.1; warranted in v0.x with KyberSwap as canonical reference if a second case emerges; treat as Tactic-level Mitigations theme in v0.x.