Incidents

Resupply, 26 June 2025

Same integers, same formula (ResupplyPairCore.sol:573 then :282), different arithmetic. rate is collateral wei per 1e18 reUSD wei; LTV is in units of 1e-5 (maxLTV 95,000); max borrow is the reUSD the 1-wei position may owe at maxLTV, rounded down (the protocol's favour); digits is −log10 of the relative error against the exact value.

Reading the table: the deployed rate has 0 correct digits (it is 0 where the truth is one half). divUp blocks the attack but is a one-mark ruler too: it reads one half as 1, doubling the LTV and halving what an honest borrower could take (0.95 reUSD instead of 1.9). Dividing by the price at the end needs no new library and gets the verdict and the LTV right to the integer. FP127 and FP19 carry the half and give the exact verdict and the exact cap.

Range: FP127 holds integers below 2^127 ≈ 1.7e38, so its port of this line takes the price as an exact integer only while totalAssets stays under 170311.325 crvUSD with one share outstanding (85 times the attack's); above that the port reverts (_q in the test) rather than floors. FP19 has no such wall.

The whole replay, with its provenance and what its test asserts: docs/benchmarks/replay-resupply.md.

Bunni v2, 2 Sep 2025 (Ethereum)

• Idle-adjusted USDC balance (balance0 − idle, what queryLDF prices with): 28 → 4 wei over 44 withdrawals (-85.7%).
• Shares burned: 14363547901296 of 1596285787955479539002 (0.000000900%); pro rata the balance should have moved by 0.000000251947 wei.
• Total liquidity: 58303205157163981 → 9114083388149667 (-84.37%). At 28 wei the pool was bound by the USDT estimate; the USDC estimate takes over below 25.59 wei and falls in proportion to the balance from there.
• The chain shows the end of it directly: the first swap after the withdrawals passed totalLiquidity = 9114083388149667 and active balances (3, 455681386673) into BunniSwapMath.computeSwap (trace 0.6.3.2.0.2.0.0.5); the replay reproduces all three. (queryLDF's active balance is min(balance, liquidity × density), which floors 4 to 3.)

Same 44 withdrawals, idle balance held differently

Token transfers out are unchanged in every row (raw and vault withdrawals floor in the pool's favour, the vault burns shares rounded up); only the stored idle balance and its update differ.

Start: active 28 wei, liquidity 58303205157163981. Liquidity takes integer balances, so for FP127, FP19 and exact the active balance is floored before queryLDF (the idle balance rounded up: the same direction as the deployed code, applied once instead of 44 times).

Per step (active USDC, wei; deployed / mulDivUp / exact):

step   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44
dep   28  29  28  27  27  26  26  25  25  24  23  23  22  22  21  20  20  19  19  18  18  17  16  16  15  15  14  14  13  12  12  11  11  10  10   9   8   8   7   7   6   6   5   4   4
up    28  30  30  30  31  31  32  32  33  33  33  34  34  35  35  35  36  36  37  37  38  38  38  39  39  40  40  41  41  41  42  42  43  43  44  44  44  45  45  46  46  47  47  47  48
exact 28  30  29  29  30  30  30  30  31  30  30  31  31  31  31  31  31  31  32  32  32  32  32  33  32  33  33  33  33  33  34  33  34  34  34  34  34  35  34  35  35  35  35  35  36   (rounded to the nearest wei)

The whole replay, with its provenance and what its test asserts: docs/benchmarks/replay-bunni.md.

The Balancer V2 Composable Stable Pool exploit, five rulers

• FP127 and FP19 charge exactly the exact-rational amount on all 90 + 75 calls. That is asserted call by call in the test, and no call lowers D*. Inside the format the upscaled 17 osETH-wei stays 17.988250947729518883 to within 2^-128. The only rounding to the wei grid is the final ceil, which favours the pool.
• mulUp alone defeats the attack as executed: every micro call now over-charges, and the per-call ratio is 8.154 (osETH) and 5.227 (wstETH) instead of 0.01774 and 0.003688. It does not make every call safe. All 30 + 25 restore calls still lower D*, by exactly the deployed amount (-8609.12 and -5.6335e+10 wei-eq). Their given-out token is WETH, whose scaling factor is exactly 1, so mulUp changes nothing there. Their loss comes from the token-in balance: 1 wei of the rate token upscales by mulDown to 1, against a true 1.058 or 1.218. mulUp also over-charges a trader heavily at these balances: 1,041,412 against the exact 957,169 on swap 23.
• Round-to-nearest at the boundary instead of ceil, with exact maths inside: 14 + 5 calls lower D* by under half a wei of the token in each. The 0.01% fee keeps the phase net positive, with ratios 1.0035 and 1.0025. FP127's claim therefore depends on keeping the boundary's direction.
• The attacker's plan itself cannot be executed under the alternatives. Replayed adaptively (drain to 18, take 17, restore with the recorded WETH amount) on each model's own balances, it reaches swap 25 under mulUp and swap 25 under exact pricing with less of the rate token left than it means to leave behind (13 wei against 18). In the wstETH pool it fails at swaps 28 and 31. Under deployed pricing it reproduces the on-chain sequence exactly.

The whole replay, with its provenance and what its test asserts: docs/benchmarks/replay-balancer.md.

The Balancer V1 drain of 31 August 2026

• Five pools, not one. SlowMist's five transactions hit five different Balancer V1 BPools, all deployed by Balancer's own BFactory 0x9424B1412450D0f8Fc2255FAf6046b98213B76Bd, between 02:28 and 03:36 UTC. SlowMist named only the first pool as the vulnerable contract.
• Every attack join paid one token unit for about one and a half. Across the 438 joins (joinswapPoolAmountOut, maxAmountIn = 1), the exact price was 1.5007879 to 1.5274949 units. The deployed maths charged 1 every time. In the opposite direction, each of the 489 dust exits (exitswapPoolAmountIn, minAmountOut = 1) was worth 0.491 to 0.499738 units, and the pool paid 1.
• The loss is one rounding step. bmul(tokenInRatio, tokenBalanceIn) (BMath.sol:156-182, line 174) multiplies an 18-decimal ratio by a balance held in raw token units: satoshi for WBTC and renBTC, 10^-6 for USDC. bmul rounds half up (BNum.sol:63-73). At a balance of 3 units, 3 × 1.499999999999999997 = 4.499999999999999991 rounds to 4 rather than 5, so the attacker pays 1. On an exit, 3.4999… rounds down, so the pool pays out 1.
• The binomial series is not involved. In every attacked pool the attacked token's normalized weight is 1/4, 1/8 or 1/10. So boo = 1/w is a whole number, and bpow returns from bpowi (BNum.sol:108-126). bpowApprox is never called in any join or exit. Where it did run (in 109 swap calculations), it stopped at a term below 1e-10, and its residual against the exact power was at most 4.2e-11 relative.
• Direction closes the loop; precision does not. FP127, FP19 and 200-digit mpmath, each rounded toward the pool (ceil in, floor out), give 2 for every join and 0 for every dust exit, so every one of them reverts on the attacker's own limits. BNum's own 18-decimal ratio, kept on a 10^-18 grid and rounded up once at the end, gives the same answers. But the same exact formula rounded once to nearest only blocks these calls because the attacker tuned them to the deployed rounding. Re-tuned to nearest-once from the same state, one join/exit cycle in pool 1 still nets 6.987% of the BPT supply (deployed: 7.035%). Toward the pool it nets -0.0548%, a loss. The deployed ratio had 18 correct digits. What it lacked was a rounding direction at the token grid.

The whole replay, with its provenance and what its test asserts: docs/benchmarks/replay-balancer-v1.md.