The bytecode told a different story than the whitepaper.
On March 14, 2026, a MEV bot operating on the Linea network extracted $8.2 million from a native DEX by exploiting a subtle integer rounding mismatch in the protocol's fee calculation. The exploit was not a reentrancy attack, not a flash loan manipulation, and not an oracle price feed issue. It was a pure arithmetic error, buried in the Solidity implementation of a formula that the whitepaper described as "mathematically proven."
I spent the next 48 hours decompiling the contract bytecode, replicating the execution traces, and mapping the exact stack state at the moment of the exploit. The result confirms a pattern I have observed in over 30 audits: complexity is the bug, clarity is the patch.
Context: The Linea-Native DEX and Its Fee Model
Linea is a zkEVM Layer 2 network that has attracted significant liquidity since its mainnet launch in 2024. The native DEX, called LyraSwap, is a constant product AMM that supports concentrated liquidity—similar to Uniswap V3 but with a tweaked fee structure. LyraSwap's whitepaper introduced a "dynamic fee multiplier" that adjusts based on volatility, aiming to reduce impermanent loss for LPs.
The core innovation: the fee multiplier is computed using a time-weighted average of the pool's price deviation from the external oracle. The formula is:
fee_multiplier = base_fee (1 + alpha abs(price_deviation))
Where alpha is a configurable parameter (default 0.05), and price_deviation is the percentage difference between the pool's spot price and the Chainlink oracle price.
This is elegant in theory. In practice, the implementation used fixed-point arithmetic with 18 decimal places, but the multiplier was stored as a uint256 with 6 decimal places. The conversion introduced a rounding error that could be triggered by a specific sequence of swap operations.
Core: The Arithmetic Exploit, Step by Step
I decompiled the relevant contract functions using Foundry's debugger and traced the execution of the fee calculation. The vulnerability is in the _calculateFeeMultiplier function, which the whitepaper claimed was "audited by three independent firms."
Let me reproduce the critical code path (simplified for clarity):
