Four agents audited the code as it is at 440edec, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown)

1 low2 info

• 1.lowWindow-start reserves are stored inside the caller's own transaction, so flash liquidity at the previous burn (or at observe()) and again at the next burn lifts the size bound to MAX_PER_BURNsrc/IMDBuyAndBurn.sol:219

          obsUsdc = uint112(rUsdc);

  Change (1) bounds a burn by DEPTH_BPS of min(reserves now, reserves stored at the window's start). Both terms are plain getReserves() snapshots, and the stored one is written by _observe() at the end of buyAndBurn() (line 133) and in observe() (line 147), inside a transaction anyone can send.

  Uniswap v2 mint()/burn() of LP shares pays no fee, so a caller can wrap their own buyAndBurn() (or observe() on a window older than MAX_WINDOW) in add-liquidity / remove-liquidity: that burn is still held to the old bound, but the snapshot it leaves is the inflated reserves (obsUsdc = 4,373,694 USDC while the pair holds 437,328).

  MIN_WINDOW later the same caller flash-adds again around the next burn and both terms of the min are inflated, so the cap is MAX_PER_BURN ($1,000) instead of 0.1% of the real reserves (about $414 at Base's reserves).

  The guarantee in the contract comment (lines 28-29, 33-35) and README lines 11 and 24 ('liquidity added inside the burn's transaction cannot raise it', 'unless the author has owned more than two thirds of the pair's liquidity since the window began') therefore holds only within one transaction: two instants of flash liquidity 30 minutes apart suffice, and nobody needs to hold anything across the window.

  A balanced two-leg price manipulation does the same without LP (buy WETH with about 1x pair A's USDC and sell about 1x pair B's FP: spotOut stays equal to twapOut, the burn passes the check and stores obsUsdc = 876,382 USDC, 2x real), at round-trip fee cost.

  Impact: with the cap at $1,000 the sandwich economics in the comment no longer hold once the pumped pair's real USDC reserve is under MAX_PER_BURN / 0.3% = about $333k (today about $439k; the economics specialist measured the attacker's net at -$1.47 at $438k and +$14.73 at $250k with mock pairs, i.e. a within-tolerance sandwich pays below roughly $420k once the attacker's LP share of the burn's own fees is counted).

  Loss per paying window is bounded by MAX_DEVIATION_BPS x MAX_PER_BURN = $30 instead of $12, repeatable every MIN_WINDOW while the balance is >= $1,005.

  Mitigating facts verified on Base today: the WETH/FP pair is the shallower leg ($414 vs $439), so lifting the cap above $439 needs WETH and FP added to pair B at both instants; Fren Pet (limitsInEffect = true, sellTotalFees = buyTotalFees = 4, pair 0xDE66 is an automatedMarketMakerPair) taxes each FP transfer to or from the pair at 4%, and FP has no flash source, so in practice an attacker who only flashes pair A (USDC and WETH are flash-loanable on Base) lifts the cap from $414 to the deeper leg's real depth ($439), and reaching $1,000 costs tens of thousands in FP tax for a $30 gain.

  No profitable path exists at today's liquidity and fee settings, hence low; but the bound no longer provides what the code and README claim, the margin now depends on pool size (which DEPTH_BPS was introduced to remove) and on Fren Pet's owner keeping the tax.

  Fix options that preserve the design: (b) in the burn's _observe() never raise the stored depth (store the new reserves only when _depth(new) <= _depth(stored)) and let only observe() on a stale window take a fresh snapshot; a patched copy with that change makes the attached proof pass (cap stays 414.489760 with flash liquidity). observe() on a stale window stays wrappable, so also (a) choose MAX_PER_BURN <= 0.1% of the smallest reserve you want the 3x margin to hold for (for example $300 for a $300k USDC reserve), or (c) document that the 3x margin holds only while the pumped pair's USDC reserve exceeds MAX_PER_BURN / 0.003 = $333k.

  Reported by all four specialists (flow, permissions, math as low; economics as medium); merged here, kept at low because the economics specialist's profitability figure ignores the 4% FP tax on the pair B leg.

  whole finding

  Mock pairs with Uniswap v2's K, fee and cumulative-price rules at Base's reserves (pair A 180 WETH / 437,328 USDC, pair B 170.6 WETH / 64,077 FP), burner holding 5,000 USDC, 31 minutes after deployment. preview().usdcIn = 414.489760 (honest cap, 0.1% of pair B's WETH valued in USDC).

  Transaction 1: mint 9x each pair's reserves into both pairs and sync(), buyAndBurn() (spends 414.49, bounded by the reserves stored at deployment), remove the 9x and sync().

  State: obsUsdc = 4,373,694.489760 USDC, obsWethB = 1,706.17 WETH, while the pairs hold 437k USDC / 170.6 WETH.

  Warp 31 minutes with no extra liquidity held: preview() cap = 415.688964 (now = real).

  Transaction 2: mint 9x again and sync(), preview().cap = 1000.000000 = MAX_PER_BURN.

  Expected: at most 414.49 USDC (0.1% of liquidity really present during the window).

  Actual: 1,000 USDC.

  Same result when the storing transaction is observe() on a window older than 2 hours.

  Run: forge test --match-path test/scratch/FlashLiquidityAcrossBurns.t.sol -vv, fails with 'liquidity never held across the window must not raise the bound: 1000000000 > 414489760'.

  With a patched copy that never raises the stored depth at the end of a burn the same test passes (cap 414.489760).

  whole reproduction
  proof · a Foundry test that fails on this code and passes once it is fixed

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  // Finding: the reserves stored at the window's start (obsUsdc, obsWethA, obsWethB) are written by _observe() at the
  // end of buyAndBurn(), inside a transaction anyone can send. Liquidity added before that burn and removed right after
  // it, in the same transaction, becomes the "window start" reserves, so the next burn's bound is 0.1% of liquidity
  // nobody held for a single second. The bound meant to resist flash liquidity (min of now and then) is then
  // min(flash, flash). Mock pairs with the real Uniswap v2 K and fee rules, no fork.
  
  import {Test} from "forge-std/Test.sol";
  import {IMDBuyAndBurn} from "src/IMDBuyAndBurn.sol";
  
  contract MockToken {
      mapping(address => uint256) public balanceOf;
      function mint(address to, uint256 a) external { balanceOf[to] += a; }
      function transfer(address to, uint256 a) external returns (bool) {
          balanceOf[msg.sender] -= a;
          balanceOf[to] += a;
          return true;
      }
  }
  
  /// Minimal Uniswap v2 pair: same reserves, cumulative-price and fee/K rules as UniswapV2Pair, plus sync() and an LP
  /// burn modelled without LP tokens
  contract MockPair {
      address public token0;
      address public token1;
      uint112 r0;
      uint112 r1;
      uint32 last;
      uint256 public price0CumulativeLast;
      uint256 public price1CumulativeLast;
  
      function init(address t0, address t1) external {
          token0 = t0;
          token1 = t1;
          _update();
      }
      function getReserves() external view returns (uint112, uint112, uint32) { return (r0, r1, last); }
      function sync() external { _update(); }
      function removeLiquidity(address to, uint256 a0, uint256 a1) external {
          MockToken(token0).transfer(to, a0);
          MockToken(token1).transfer(to, a1);
          _update();
      }
      function _update() internal {
          uint32 now32 = uint32(block.timestamp);
          unchecked {
              uint32 dt = now32 - last;
              if (dt > 0 && r0 != 0 && r1 != 0) {
                  price0CumulativeLast += ((uint256(r1) << 112) / r0) * dt;
                  price1CumulativeLast += ((uint256(r0) << 112) / r1) * dt;
              }
          }
          r0 = uint112(MockToken(token0).balanceOf(address(this)));
          r1 = uint112(MockToken(token1).balanceOf(address(this)));
          last = now32;
      }
      function swap(uint256 out0, uint256 out1, address to, bytes calldata) external {
          (uint256 o0, uint256 o1) = (r0, r1);
          if (out0 > 0) MockToken(token0).transfer(to, out0);
          if (out1 > 0) MockToken(token1).transfer(to, out1);
          uint256 b0 = MockToken(token0).balanceOf(address(this));
          uint256 b1 = MockToken(token1).balanceOf(address(this));
          uint256 in0 = b0 > o0 - out0 ? b0 - (o0 - out0) : 0;
          uint256 in1 = b1 > o1 - out1 ? b1 - (o1 - out1) : 0;
          require(in0 > 0 || in1 > 0, "INSUFFICIENT_INPUT");
          require((b0 * 1000 - in0 * 3) * (b1 * 1000 - in1 * 3) >= o0 * o1 * 1e6, "K");
          _update();
      }
  }
  
  contract FlashLiquidityAcrossBurnsTest is Test {
      address constant USDC = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913;
      address constant WETH = 0x4200000000000000000000000000000000000006;
      address constant IMD = 0xFF0C532FDB8Cd566Ae169C1CB157ff2Bdc83E105;
      address constant PAIR_A = 0x88A43bbDF9D098eEC7bCEda4e2494615dfD9bB9C; // WETH/USDC, WETH is token0 as on Base
      address constant PAIR_B = 0xDE66c35e01ED8e619Bf092352338ef94f2327337; // WETH/IMD, WETH is token0 as on Base
  
      IMDBuyAndBurn burner;
      address attacker = makeAddr("attacker");
  
      function setUp() public {
          vm.warp(1_760_000_000);
          address tok = address(new MockToken());
          vm.etch(USDC, tok.code);
          vm.etch(WETH, tok.code);
          vm.etch(IMD, tok.code);
          address pair = address(new MockPair());
          vm.etch(PAIR_A, pair.code);
          vm.etch(PAIR_B, pair.code);
          // Base reserves at block 52647419
          MockToken(WETH).mint(PAIR_A, 180.0e18);
          MockToken(USDC).mint(PAIR_A, 437_328e6);
          MockPair(PAIR_A).init(WETH, USDC);
          MockToken(WETH).mint(PAIR_B, 170.6e18);
          MockToken(IMD).mint(PAIR_B, 64_077e18);
          MockPair(PAIR_B).init(WETH, IMD);
          burner = new IMDBuyAndBurn();
      }
  
      /// Adds (mult - 1) times the current reserves at the current ratio, as an LP mint would
      function _addLiquidity(address pair, uint256 mult) internal returns (uint256 a0, uint256 a1) {
          (uint112 x0, uint112 x1,) = MockPair(pair).getReserves();
          a0 = uint256(x0) * (mult - 1);
          a1 = uint256(x1) * (mult - 1);
          MockToken(MockPair(pair).token0()).mint(pair, a0);
          MockToken(MockPair(pair).token1()).mint(pair, a1);
          MockPair(pair).sync();
      }
  
      function test_FlashLiquidityAroundPreviousBurnRaisesTheCap() public {
          MockToken(USDC).mint(address(burner), 5_000e6);
          vm.warp(block.timestamp + 31 minutes);
          (uint256 honestCap,,,,) = burner.preview();
          emit log_named_decimal_uint("honest cap (0.1% of the real reserves)", honestCap, 6);
  
          // Burn N, wrapped in one transaction: add 10x liquidity to both pairs, burn, remove it again
          (uint256 a0, uint256 a1) = _addLiquidity(PAIR_A, 10);
          (uint256 b0, uint256 b1) = _addLiquidity(PAIR_B, 10);
          burner.buyAndBurn(); // still bounded by the real reserves stored at deployment
          MockPair(PAIR_A).removeLiquidity(attacker, a0, a1);
          MockPair(PAIR_B).removeLiquidity(attacker, b0, b1);
          emit log_named_decimal_uint("obsUsdc stored by burn N", burner.obsUsdc(), 6);
          emit log_named_decimal_uint("obsWethB stored by burn N", burner.obsWethB(), 18);
  
          // Thirty-one minutes later: nobody held any extra liquidity in between
          vm.warp(block.timestamp + 31 minutes);
          (uint256 capNoFlash,,,,) = burner.preview();
          emit log_named_decimal_uint("cap at burn N+1 before adding liquidity", capNoFlash, 6);
  
          // Burn N+1, wrapped again: add 10x liquidity, then the bound the burn uses
          _addLiquidity(PAIR_A, 10);
          _addLiquidity(PAIR_B, 10);
          (uint256 capFlash,,,,) = burner.preview();
          emit log_named_decimal_uint("cap at burn N+1 with flash liquidity", capFlash, 6);
          assertLe(capFlash, honestCap, "liquidity never held across the window must not raise the bound");
      }
  }

  whole proof

• 2.infoStored window-start reserves can be lowered in the storing transaction (a WETH dump before observe() or a burn, or a pair A LP removing its share), shrinking the next burn towards the $5 floor for onesrc/IMDBuyAndBurn.sol:147

          _observe();

  The other direction of the brief's question. observe() has no price or depth check (none is possible, the window it starts has no TWAP yet) and _observe() stores whatever the pairs hold in that transaction. Selling WETH into the USDC/WETH pair lowers rUsdc and raises rWethA, which lowers both depthA and depthB in _depth() (lines 227-228) and makes IMD cheaper along the route, a direction _withinTolerance() never rejects (line 176).

  So an attacker who dumps WETH, calls observe() (window older than MAX_WINDOW) or buyAndBurn() (window 30 min to 2 h old), and buys the WETH back in the same transaction leaves obsUsdc and obsWethA depressed; the next burn is bounded by depthThen (line 192) for the whole following window. The stored cumulative prices are unaffected (the pair accrued the honest price up to this block; the manipulated price counts for zero seconds when unwound in the same transaction).

  A liquidity provider of the USDC/WETH pair gets the same effect for free (no swap fee, no Fren Pet tax on pair A) by removing its share before the storing transaction and re-adding it after; it only binds when it brings depthA(then) under depthB, i.e. a share above about 5% today. Change (2) guarantees this cannot block: size = max(cap, THRESHOLD), so the worst case is a $5 burn in one window, and that burn's own _observe() stores honest reserves again.

  It is griefing at a loss (about $2,000 of WETH in fees and impact to defer about $388 of burning by 30 minutes), with nothing to gain, so no code change is needed; the README's 'observe() ... can never delay a burn' (line 20) and contract line 38 should say that it cannot delay a burn but can shrink the next one for a window, and the trust assumptions could note that an LP of the USDC/WETH pair can throttle one window for free.

  If a bound is wanted, a floor such as depthThen >= depth / 4 would cap the throttle at 4x while keeping the same-transaction flash-liquidity bound within that factor. Reported by all four specialists (permissions as low, the others as info); the swap and LP variants are merged here.

  whole finding

  Mock pairs at Base's reserves (pair A 180 WETH / 437,328 USDC, pair B 170.6 WETH / 64,077 FP), burner holding 1,000 USDC, window idle for 2 hours and 1 second.

  Attacker in one transaction: sell 540 WETH into pair A (USDC reserve falls to 109,578, WETH to 720), call observe() (succeeds, stores obsUsdc = 109,578.551742 and obsWethA = 720), buy the WETH back: net cost 0.812435 WETH.

  Warp 31 minutes: preview().usdcIn = 25.964029 USDC (expected about 414 at the real reserves); buyAndBurn() spends 25.96.

  Warp 31 minutes: preview().usdcIn = 412.702164, the effect lasted one window.

  Same trade in front of a burn (window 31 min old, 2,000 USDC): the burn passes the price check (IMD cheaper), stores obsUsdc = 109,604.515771, costs the attacker 0.971853 WETH, and the next burn is 26.002208 USDC.

  LP variant: remove 90% of pair A (162 WETH, 393,595 USDC) before observe(), re-add after and sync(): next preview().usdcIn = 43.732800 USDC.

  Run: forge test --match-path test/scratch/JudgeRepro.t.sol --match-test 'Deflates|Throttles' -vv (the tests assert the shrunk sizes and pass).

  whole reproduction

• 3.infoThe THRESHOLD-floor sentence understates the floor's share of a thin reserve: $5 to $9.99 is 0.2% only at the $5,000 boundary and grows without bound below it, inverting the sandwich margin under abousrc/IMDBuyAndBurn.sol:36

  /// THRESHOLD floor (pools worth under about $10,000) a burn can reach 0.2% of a reserve, which halves that margin.

  With size = max(cap, THRESHOLD) and the remainder rule (balance < size + THRESHOLD spends the whole balance, line 197), a burn in a pool whose 0.1% depth is under $5 spends between $5 and $9.99 whatever the reserve. The share of the reserve is therefore up to $9.99 / reserve: 0.2% at a $5,000 reserve (the 'pools worth about $10,000' boundary in the comment is right, two sides of $5,000), but 1% at a $1,000 reserve and 10% at $100.

  The margin does not merely halve: a sandwich's gain d x S versus the pump's fee 0.3% x d x R inverts once R < S / 0.003, i.e. a USDC reserve under $3,330 for S = $9.99 ($1,667 for S = $5), for a gain of at most 3% x $9.99 = $0.30 per window.

  This is the intended drain-rather-than-lock tradeoff from the 564c3cc7 round and the amounts are cents, so it is a documentation precision note (contract line 36 and README line 25-26), not a code change: say that below about $10,000 of pool value the burn's share grows as the pool shrinks (1% at a $1,000 reserve) and that under about $6,600 of pool value a within-tolerance sandwich pays, bounded by cents per window. Reported by the flow and economics specialists; merged.

  The flow specialist's claim that the boundary is $5,000 rather than $10,000 does not hold: the comment speaks of pool value, which is twice the reserve.

  whole finding

  Mock pairs: pair A 0.412 WETH / 1,000 USDC, pair B 170.6 WETH / 64,077 FP; burner holding 9.99 USDC; window 31 minutes old. _quote(): depthA = 1,000e6 x 10 / 10_000 = 1 USDC, cap = 1 USDC, size = THRESHOLD = 5 USDC, balance 9.99 < 5 + 5 so usdcIn = 9.99 USDC = 0.999% of the USDC reserve; buyAndBurn() spends all 9.99 USDC.

  Expected per the comment: at most 0.2% of a reserve.

  Run: forge test --match-path test/scratch/JudgeRepro.t.sol --match-test FloorShare -vv (asserts usdcIn = 9.99e6 and share >= 0.99%, passes). test/ThinPoolLock.t.sol's VeryThinPoolTest shows the floor binding at a $4,855 reserve, consistent with the $10,000 pool-value boundary.

  whole reproduction

1. Posted11 minto the first attempt
2. Audit mathAgent #1066found 1 low, 1 info

   Review complete. The findings file is in place and valid.

   Deployment check. The contract at 0xcad3cecbb402b9a7f5c08e3dbee57a34d2f949fa on Base is a Sourcify full match (creation and runtime), the verified source is byte-identical to the working tree at 440edec, and a local build matches the on-chain runtime code except at the immutable slots. Its live state is the deployment observation (window start reserves 437,220 USDC, 180.06 WETH, 170.61 WETH; nothing spent yet). The existing suite passes on a Base fork, 22 of 22.

   Both changes since 218b030 are correct as specified.

   • The min of reserves now and at the window start cannot be raised by liquidity added in the burn's transaction alone, cannot be set below the $5 floor, and cannot make a burn revert. Lowering it by swaps is uneconomic under the constant product: halving the USDC reserve costs about $1,300 in fees per leg, and reaching the $5 floor needs over $100k.
   • The floor and remainder rule never strand USDC: a burn spends at least $5, a remainder under $5 goes with the last capped burn, and the only overshoot is under $5 above the cap, which the README documents.
   • The TWAP math is unchanged and holds: the post-burn re-observation reads the same cumulative the quote used, no realistic overflow in the Q112 products, and both tolerance sides round the same way.

   Findings written to .imd-findings.json:

   1. Low. Bracketed flash liquidity defeats the window-start bound. Both terms of the min are instantaneous snapshots taken inside transactions anyone can send. Adding flash liquidity in the storing transaction (observe on a stale window, or the previous burn) and again 30 minutes later around the burn makes both terms inflated, so the burn is bounded only by MAX_PER_BURN. Mock reproduction: honest cap 414.92 USDC, bracketed burn 1,000 USDC. Economics bound the harm: a within-tolerance sandwich on the enlarged burn yields at most $30 against about $39 in fees leaked to other LPs at today's pool size, and lifting the WETH/FP leg costs Fren Pet's 4% tax on liquidity adds, confirmed on the fork. Suggested fix is a minimum over the last two or three observations, or documenting the limit and lowering MAX_PER_BURN.
   2. Info. An LP can throttle one window for free. Removing its share around the storing transaction and re-adding it caps the next burn by that share while still earning fees; the burn still runs and restores the full cap afterwards. Mock reproduction: 414.92 USDC becomes 41.49 USDC for one window.

   No high or critical issues, so no finding carries a proof file. The reproductions are in test/scratch/BracketedJit.t.sol and test/scratch/FpTaxOnFork.t.sol, which are not part of the submission. I changed no files outside the findings file and the scratch directory.

   ran onclaude · claude-fable-5-1 · 22 turns · 10m 41s · 322 in · 43.8K out · 836.4K cached

   submissionfdffe1eb4063564ca2b3547f97750a69f7000bdf269cf11910fab977a6aa28ae

   device9f3c23750c16c22cc1085e59ecad85fcf6f2023a2f7e0e27cac0403c1c2ecaa3

   started from440edec3d64447552f198588d5ae267109fb1ce0

   bundlenone

   • lowWindow-start reserve bound is bypassed by flash liquidity in both the storing transaction and the burn's transactionsrc/IMDBuyAndBurn.sol:191

     Change (1) bounds the burn by DEPTH_BPS of min(reserves now, reserves stored at the window start). Both terms are plain reserve snapshots, and both snapshots are taken inside transactions anyone can send: _observe() runs at the end of buyAndBurn() and in observe(), so the stored reserves are read while any flash liquidity added earlier in that same transaction is still in the pairs.

     An attacker who adds liquidity (no price move, so the TWAP check is untouched) in the transaction that stores the window start (observe() on a window older than MAX_WINDOW, or simply the previous burn, which anyone can trigger), removes it, and adds it again MIN_WINDOW later around the next buyAndBurn(), makes both terms of the min the inflated value. The burn is then bounded only by MAX_PER_BURN instead of 0.1% of the real reserves.

     The README's sentence 'liquidity added inside the burn's transaction cannot raise the bound' holds only for liquidity added in one transaction; bracketing two transactions 30 minutes apart (gas plus flash-borrowable capital, no swap fees) raises it.

     Economics: with the bound raised to MAX_PER_BURN a within-tolerance sandwich (3% of the burn) yields at most 0.03 x 1,000 = $30 per burn against about 9e-5 x R of fees leaked to other LPs on the pumped pair (independent of the attacker's JIT share), about $39 at today's $437k USDC/WETH pair, so it is griefing today and becomes marginally profitable only if the shallower pair falls under roughly $330k.

     Raising the bound above the WETH/FP leg's real depth also requires adding FP to that pair, which Fren Pet taxes at 4% on the fork (1,000 FP sent to the pair credits 960), so in practice the bypass lifts the cap to the deeper of the two legs (today from $415, the WETH/FP leg, to $438, the USDC/WETH leg) unless the attacker pays that tax. Impact is therefore a larger-than-designed burn exposed to a within-tolerance sandwich, bounded by MAX_PER_BURN; it cannot drain or block.

     Fix options: keep the stored reserves as the minimum over the last two or three observations (each additional bracket costs another 30-minute JIT), or document that the bound is only as strong as MAX_PER_BURN against a bracketing attacker and lower MAX_PER_BURN accordingly.

     whole finding

     Mock pairs with Base reserves (USDC/WETH 437,557 USDC / 179.92 WETH, WETH/FP 170.61 WETH / 64,077 FP), burner holds 2,000 USDC. Honest cap = min(0.1% x 437,557, 0.1% x 170.61 WETH valued in USDC) = 414.915516 USDC; preview() after 31 minutes returns usdcIn = 414.915516 (expected and actual). Then: warp 2 hours; in one transaction mint 9x both reserves into both pairs, sync, call observe(), take the 9x back, sync (obsUsdc == 4,375,570 USDC). Warp 31 minutes; in one transaction mint 9x again, sync, preview() -> usdcIn = 1,000.000000 USDC (MAX_PER_BURN) and buyAndBurn() spends 1,000 USDC, 2.4x the real depth bound. Expected: a burn bounded by 0.1% of the liquidity that was really in the pools during the window (about 415 USDC). The same works with the previous burn as the storing transaction (second test). Run: forge test --match-path test/scratch/BracketedJit.t.sol -vv (tests test_JitAtObserveAndAtBurnRaisesTheCapToMaxPerBurn and test_JitAtPreviousBurnAndAtBurnRaisesTheCap pass, i.e. the bypass is demonstrated).

     // SPDX-License-Identifier: MIT

     pragma solidity 0.8.26;

     import {Test} from "forge-std/Test.sol";

     import {IMDBuyAndBurn} from "src/IMDBuyAndBurn.sol";

     contract MockToken {

     mapping(address => uint256) public balanceOf;
     
     function mint(address to, uint256 a) external { balanceOf[to] += a; }
     
     function take(address from, uint256 a) external { balanceOf[from] -= a; } // test-only "remove liquidity"
     
     function transfer(address to, uint256 a) external returns (bool) {
     
         balanceOf[msg.sender] -= a;
     
         balanceOf[to] += a;
     
         return true;
     
     }
     

     }

     /// Minimal Uniswap v2 pair: same reserves, cumulative-price and fee/K rules as UniswapV2Pair, plus sync()

     contract MockPair {

     address public token0;
     
     address public token1;
     
     uint112 r0;
     
     uint112 r1;
     
     uint32 last;
     
     uint256 public price0CumulativeLast;
     
     uint256 public price1CumulativeLast;
     
     function init(address t0, address t1) external {
     
         token0 = t0;
     
         token1 = t1;
     
         _update();
     
     }
     
     function sync() external { _update(); }
     
     function getReserves() external view returns (uint112, uint112, uint32) { return (r0, r1, last); }
     
     function _update() internal {
     
         uint32 now32 = uint32(block.timestamp);
     
         unchecked {
     
             uint32 dt = now32 - last;
     
             if (dt > 0 && r0 != 0 && r1 != 0) {
     
                 price0CumulativeLast += ((uint256(r1) << 112) / r0) * dt;
     
                 price1CumulativeLast += ((uint256(r0) << 112) / r1) * dt;
     
             }
     
         }
     
         r0 = uint112(MockToken(token0).balanceOf(address(this)));
     
         r1 = uint112(MockToken(token1).balanceOf(address(this)));
     
         last = now32;
     
     }
     
     function swap(uint256 out0, uint256 out1, address to, bytes calldata) external {
     
         (uint256 o0, uint256 o1) = (r0, r1);
     
         if (out0 > 0) MockToken(token0).transfer(to, out0);
     
         if (out1 > 0) MockToken(token1).transfer(to, out1);
     
         uint256 b0 = MockToken(token0).balanceOf(address(this));
     
         uint256 b1 = MockToken(token1).balanceOf(address(this));
     
         uint256 in0 = b0 > o0 - out0 ? b0 - (o0 - out0) : 0;
     
         uint256 in1 = b1 > o1 - out1 ? b1 - (o1 - out1) : 0;
     
         require(in0 > 0 || in1 > 0, "INSUFFICIENT_INPUT");
     
         require((b0 * 1000 - in0 * 3) * (b1 * 1000 - in1 * 3) >= o0 * o1 * 1e6, "K");
     
         _update();
     
     }
     

     }

     /// The size bound is min(DEPTH_BPS of reserves now, DEPTH_BPS of reserves at the window start). Both can be flash

     /// liquidity: add it in the transaction that stores the window start (observe() on a stale window, or the previous

     /// burn), remove it, and add it again in the burn's transaction.

     contract BracketedJitTest is Test {

     address constant USDC = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913;
     
     address constant WETH = 0x4200000000000000000000000000000000000006;
     
     address constant IMD = 0xFF0C532FDB8Cd566Ae169C1CB157ff2Bdc83E105;
     
     address constant PAIR_A = 0x88A43bbDF9D098eEC7bCEda4e2494615dfD9bB9C; // W
     

     whole reproduction

   • infoStored window-start reserves can be lowered by a liquidity provider at no cost, throttling the next burn (never blocking it)src/IMDBuyAndBurn.sol:219

     The reserves stored by _observe() are whatever the pairs hold at that instant. A liquidity provider of either pair can remove its share immediately before the storing transaction (observe() on a stale window, or the previous burn) and put it back right after, paying only gas and no swap fee: the whole next window then runs with depthThen reduced by that share, while the LP keeps earning fees on the full position during the window.

     A non-LP cannot do this cheaply: lowering obsUsdc by a factor f with swaps needs (f-1) x 180 WETH of input into the USDC/WETH pair (0.3% fee each way, about $1,300 per halving) and reaching the $5 floor needs f of about 87, over $100k in fees; draining the WETH/FP pair's WETH also pays Fren Pet's 4% sell tax.

     Neither path can block: change (2) makes size = max(cap, THRESHOLD), so the throttled burn still spends at least $5 and, by calling _observe() again at its end with the real reserves, restores the full cap for the following window. Impact is a one-window slowdown of burning at the LP's choice, consistent with the README's existing assumption that an LP owning liquidity controls depth.

     No code change needed; worth a line in the trust assumptions (the 'has owned more than two thirds of the pair's liquidity since the window began' sentence covers sandwich profit, not this throttle).

     whole finding

     Mock pairs with Base reserves, burner holds 2,000 USDC, window older than MAX_WINDOW.

     In one transaction: take 90% of both tokens out of both pairs, sync, observe(), put them back, sync.

     Warp 31 minutes: preview() returns usdcIn = 41.491551 USDC instead of 414.915516 (one tenth; expected: the real depth bound since the liquidity was present for the whole window), buyAndBurn() succeeds with that size, and 31 minutes later preview() is back to about 415 USDC.

     Run: forge test --match-path test/scratch/BracketedJit.t.sol --match-test test_LpRemovalAroundObserveThrottlesTheNextBurn -vv (see the test source attached to the first finding, contract LoweredWindowStartTest).

     whole reproduction
3. Audit permissionsAgent #1215found 2 low

   The findings file is in place and excluded from git by the repository's own exclude list. The tree is otherwise clean, with no scratch files left.

   Outcome: two low findings, nothing high or medium. The deployment at 0xcad3…49fa is verified on Sourcify with a creation and runtime match, and its source is byte-identical to the tree. All 22 project tests pass on a Base fork.

   What I checked in the assigned area

   • Change (1), window-start reserves. The arithmetic and the same-transaction flash-liquidity bound are correct. The weakness is where the value is written: _observe() runs at the end of a permissionless burn, so the attacker who wraps burn N with add-then-remove liquidity sets the stored reserves to the inflated ones, and at burn N+1 the bound is min(flash, flash). With mock pairs at Base's reserves the cap rises from $414 to the $1,000 maximum with zero holding time. It stays unprofitable today because a sandwich on the USDC/WETH pair still pays 0.3% of the honest reserve in fees to other LPs, which beats the gain while that reserve exceeds about $333k, and because the Fren Pet pair must be inflated too. The README's "owned since the window began" claim no longer holds. Reported as low with a proof test that fails on the current code.
   • Deflation of stored reserves. A sell of WETH into pair A followed by observe() or a burn, then unwinding, stores depressed reserves and cuts one window's burn to about $26. It costs the attacker about 0.8 WETH per window and the following burn restores the real bound. Griefing at a loss, reported as low with the numbers.
   • Flash swaps do not help the attacker: reserves are stale during the callback and the burn's own swap hits the pair lock.
   • Change (2), THRESHOLD floor and remainder rule. Correct. No remainder under $5 is ever stranded, a burn is never zero, and the overshoot is bounded by $5 or 2x THRESHOLD in a very thin pool.
   • Access control, trust gap, asymmetry. No roles, no ETH path, observe and burn windows partition the timeline without gap or overlap, and the burn and observe() share one _observe(). The Fren Pet owner and Circle powers remain as documented trust assumptions.

   Not covered: a numeric sandwich simulation at the inflated cap with LP fee shares. The profitability bound in finding 1 is analytical.

   ran onclaude · claude-fable-5-1 · 28 turns · 12m 28s · 354 in · 50.7K out · 1.1M cached

   submission17bdd59d09b95b972eeb904384d870b6745c51ccabfa49f1c82bdf573c8bdd15

   device3b9f88f55251764de70b4cb439f71dccf68bef0e9370c8b835b00bc381d6052f

   started from440edec3d64447552f198588d5ae267109fb1ce0

   bundlenone

   • lowWindow-start reserves are written inside the previous burn's transaction, so flash liquidity around burn N sets the bound of burn N+1src/IMDBuyAndBurn.sol:219

     _observe() runs at the end of buyAndBurn() (line 133) and stores the pairs' current reserves as obsUsdc, obsWethA and obsWethB (lines 219-221). buyAndBurn() is permissionless, so an attacker can wrap it: add liquidity to both pairs, call buyAndBurn(), remove the liquidity, all in one transaction. The stored 'window start' reserves are then the flash-inflated ones.

     Thirty minutes later the attacker wraps burn N+1 the same way, and _quote() computes depth = min(now, then) = min(flash, flash) (line 192): the bound is DEPTH_BPS of liquidity that nobody held for a single second. The contract comment (line 28-29) and README promise that 'liquidity added inside the burn's transaction cannot raise' the bound and that a sandwich is unprofitable 'unless the author has owned more than two thirds of the pair's liquidity since the window began'.

     Neither holds: the two-thirds share is needed only at two instants, which flash loans can supply.

     With the bound lifted to MAX_PER_BURN the only remaining protection is economic: a pump of d on the USDC/WETH pair costs the attacker 0.3% * d * (honest reserve) in fees paid to other LPs, against a gain of d * MAX_PER_BURN, so a sandwich is profitable only once the honest USDC reserve of pair A is below MAX_PER_BURN / 0.3% = about $333k (today $437k, a 24% margin), and the attacker must also supply WETH/FP liquidity to the second pair at both instants (FP's 4% tax on transfers to and from the pair applies to that liquidity unless the attacker is fee-exempt).

     No profitable path exists at today's liquidity, hence low; but the new guard does not provide what it claims and the margin now depends on the pool's size, which the previous audit round introduced DEPTH_BPS to remove.

     Fix options: (a) document the real bound (MAX_PER_BURN must stay under 0.3% of the smallest honest USDC reserve expected, and lower MAX_PER_BURN or add a hard cap in USDC-reserve terms accordingly); (b) make the stored reserves non-increasing within a burn, e.g. store min(reserves now, stored value) in the burn's _observe() and only let observe() (idle window older than MAX_WINDOW) raise them, which forces the attacker to hold liquidity from a cold start; the proof below passes with (b).

     A fix that only re-samples 'then' at another attacker-wrappable moment is not a fix.

     whole finding

     Mock pairs with Uniswap v2 rules at Base's reserves (pair A 180 WETH / 437,328 USDC, pair B 170.6 WETH / 64,077 FP), burner holds 5,000 USDC, 31 minutes after deployment.

     Expected: the next burn's bound stays at 0.1% of the real reserves, about $414, no matter what happens inside the burns' transactions.

     Actual: honest cap 414.489760 USDC; tx 1 = mint 9x reserves into both pairs + sync, buyAndBurn() (spends 414.49, bounded by the reserves stored at deployment), remove the 9x again; _observe() has stored obsUsdc = 4,373,694 USDC and obsWethB = 1,706 WETH, ten times the real reserves.

     After 31 minutes with nobody holding extra liquidity, preview() still reports a cap of 415.69 (now = real). tx 2 = mint 9x again + sync, then preview(): cap = 1000.000000 = MAX_PER_BURN, 2.4x the honest bound.

     Run the proof: forge test --match-path test/scratch/FlashLiquidityAcrossBurns.t.sol -vv, it fails with 'liquidity never held across the window must not raise the bound: 1000000000 > 414489760'.

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     // Finding: the reserves stored at the window's start (obsUsdc, obsWethA, obsWethB) are written by _observe() at the
     // end of buyAndBurn(), inside a transaction anyone can send. Liquidity added before that burn and removed right after
     // it, in the same transaction, becomes the "window start" reserves, so the next burn's bound is 0.1% of liquidity
     // nobody held for a single second. The bound meant to resist flash liquidity (min of now and then) is then
     // min(flash, flash). Mock pairs with the real Uniswap v2 K and fee rules, no fork.
     
     import {Test} from "forge-std/Test.sol";
     import {IMDBuyAndBurn} from "src/IMDBuyAndBurn.sol";
     
     contract MockToken {
         mapping(address => uint256) public balanceOf;
         function mint(address to, uint256 a) external { balanceOf[to] += a; }
         function transfer(address to, uint256 a) external returns (bool) {
             balanceOf[msg.sender] -= a;
             balanceOf[to] += a;
             return true;
         }
     }
     
     /// Minimal Uniswap v2 pair: same reserves, cumulative-price and fee/K rules as UniswapV2Pair, plus sync() and an LP
     /// burn modelled without LP tokens
     contract MockPair {
         address public token0;
         address public token1;
         uint112 r0;
         uint112 r1;
         uint32 last;
         uint256 public price0CumulativeLast;
         uint256 public price1CumulativeLast;
     
         function init(address t0, address t1) external {
             token0 = t0;
             token1 = t1;
             _update();
         }
         function getReserves() external view returns (uint112, uint112, uint32) { return (r0, r1, last); }
         function sync() external { _update(); }
         function removeLiquidity(address to, uint256 a0, uint256 a1) external {
             MockToken(token0).transfer(to, a0);
             MockToken(token1).transfer(to, a1);
             _update();
         }
         function _update() internal {
             uint32 now32 = uint32(block.timestamp);
             unchecked {
                 uint32 dt = now32 - last;
                 if (dt > 0 && r0 != 0 && r1 != 0) {
                     price0CumulativeLast += ((uint256(r1) << 112) / r0) * dt;
                     price1CumulativeLast += ((uint256(r0) << 112) / r1) * dt;
                 }
             }
             r0 = uint112(MockToken(token0).balanceOf(address(this)));
             r1 = uint112(MockToken(token1).balanceOf(address(this)));
             last = now32;
         }
         function swap(uint256 out0, uint256 out1, address to, bytes calldata) external {
             (uint256 o0, uint256 o1) = (r0, r1);
             if (out0 > 0) MockToken(token0).transfer(to, out0);
             if (out1 > 0) MockToken(token1).transfer(to, out1);
             uint256 b0 = MockToken(token0).balanceOf(address(this));
             uint256 b1 = MockToken(token1).balanceOf(address(this));
             uint256 in0 = b0 > o0 - out0 ? b0 - (o0 - out0) : 0;
             uint256 in1 = b1 > o1 - out1 ? b1 - (o1 - out1) : 0;
             require(in0 > 0 || in1 > 0, "INSUFFICIENT_INPUT");
             require((b0 * 1000 - in0 * 3) * (b1 * 1000 - in1 * 3) >= o0 * o1 * 1e6, "K");
             _update();
         }
     }
     
     contract FlashLiquidityAcrossBurnsTest is Test {
         address constant USDC = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913;
         address constant WETH = 0x4200000000000000000000000000000000000006;
         address constant IMD = 0xFF0C532FDB8Cd566Ae169C1CB157ff2Bdc83E105;
         address constant PAIR_A = 0x88A43bbDF9D098eEC7bCEda4e2494615dfD9bB9C; // WETH/USDC, WETH is token0 as on Base
         address constant PAIR_B = 0xDE66c35e01ED8e619Bf092352338ef94f2327337; // WETH/IMD, WETH is token0 as on Base
     
         IMDBuyAndBurn burner;
         address attacker = makeAddr("attacker");
     
         function setUp() public {
             vm.warp(1_760_000_000);
             address tok = address(new MockToken());
             vm.etch(USDC, tok.code);
             vm.etch(WETH, tok.code);
             vm.etch(IMD, tok.code);
             address pair = address(new MockPair());
             vm.etch(PAIR_A, pair.code);
             vm.etch(PAIR_B, pair.code);
             // Base reserves at block 52647419
             MockToken(WETH).mint(PAIR_A, 180.0e18);
             MockToken(USDC).mint(PAIR_A, 437_328e6);
             MockPair(PAIR_A).init(WETH, USDC);
             MockToken(WETH).mint(PAIR_B, 170.6e18);
             MockToken(IMD).mint(PAIR_B, 64_077e18);
             MockPair(PAIR_B).init(WETH, IMD);
             burner = new IMDBuyAndBurn();
         }
     
         /// Adds (mult - 1) times the current reserves at the current ratio, as an LP mint would
         function _addLiquidity(address pair, uint256 mult) internal returns (uint256 a0, uint256 a1) {
             (uint112 x0, uint112 x1,) = MockPair(pair).getReserves();
             a0 = uint256(x0) * (mult - 1);
             a1 = uint256(x1) * (mult - 1);
             MockToken(MockPair(pair).token0()).mint(pair, a0);
             MockToken(MockPair(pair).token1()).mint(pair, a1);
             MockPair(pair).sync();
         }
     
         function test_FlashLiquidityAroundPreviousBurnRaisesTheCap() public {
             MockToken(USDC).mint(address(burner), 5_000e6);
             vm.warp(block.timestamp + 31 minutes);
             (uint256 honestCap,,,,) = burner.preview();
             emit log_named_decimal_uint("honest cap (0.1% of the real reserves)", honestCap, 6);
     
             // Burn N, wrapped in one transaction: add 10x liquidity to both pairs, burn, remove it again
             (uint256 a0, uint256 a1) = _addLiquidity(PAIR_A, 10);
             (uint256 b0, uint256 b1) = _addLiquidity(PAIR_B, 10);
             burner.buyAndBurn(); // still bounded by the real reserves stored at deployment
             MockPair(PAIR_A).removeLiquidity(attacker, a0, a1);
             MockPair(PAIR_B).removeLiquidity(attacker, b0, b1);
             emit log_named_decimal_uint("obsUsdc stored by burn N", burner.obsUsdc(), 6);
             emit log_named_decimal_uint("obsWethB stored by burn N", burner.obsWethB(), 18);
     
             // Thirty-one minutes later: nobody held any extra liquidity in between
             vm.warp(block.timestamp + 31 minutes);
             (uint256 capNoFlash,,,,) = burner.preview();
             emit log_named_decimal_uint("cap at burn N+1 before adding liquidity", capNoFlash, 6);
     
             // Burn N+1, wrapped again: add 10x liquidity, then the bound the burn uses
             _addLiquidity(PAIR_A, 10);
             _addLiquidity(PAIR_B, 10);
             (uint256 capFlash,,,,) = burner.preview();
             emit log_named_decimal_uint("cap at burn N+1 with flash liquidity", capFlash, 6);
             assertLe(capFlash, honestCap, "liquidity never held across the window must not raise the bound");
         }
     }

     whole proof

   • lowA trade before observe() or before a burn stores deflated reserves and cuts the next burn to about $26 for one window, at a cost of about 0.8 WETHsrc/IMDBuyAndBurn.sol:147

     The stored reserves can be lowered as well as raised. Selling WETH into the USDC/WETH pair lowers rUsdc and raises rWethA, which lowers both terms of _depth() (line 226-230) and makes IMD cheaper, a direction the TWAP check never rejects (line 176). An attacker who does that, calls observe() (allowed because the window is older than MAX_WINDOW) or buyAndBurn(), and buys the WETH back in the same transaction leaves obsUsdc and obsWethA at the depressed values.

     The next burn is bounded by depthThen (line 192) and shrinks towards THRESHOLD; the burn after it stores real reserves again, so the effect lasts one window. This contradicts the comment at line 37-38 and the README ('observe() ... can never delay a burn') only in degree: the burn runs, but for a fraction of its size. It is pure griefing at a loss: the round trip costs the attacker 0.6% of the swap in fees plus the burn's gain from the depressed price, and nothing is extracted.

     Reported because the task asks whether the stored reserves can be set by an attacker to block burns: they can be shrunk for one window at a cost two orders of magnitude above the amount delayed.

     Fix: none needed beyond documenting it; a floor such as max(depthThen, depth / 4) would cap the griefing at a 4x reduction while keeping the same-transaction flash-liquidity bound within that factor, if the requester prefers.

     whole finding

     Mock pairs at Base's reserves (pair A 180 WETH / 437,328 USDC), burner holds 1,000 USDC, window idle for 2 hours and 1 second.

     Attacker, in one transaction: sell 540 WETH into pair A (receives 327,750 USDC, USDC reserve falls to 109,578, WETH reserve to 720), call observe() (succeeds, stores obsUsdc = 109,578.551742 and obsWethA = 720), buy the WETH back with the USDC.

     Attacker net cost: 0.812435 WETH (about $2,000).

     Expected: 31 minutes later the burn spends the real bound, about 414 USDC.

     Actual: preview() and buyAndBurn() spend 25.964029 USDC (0.1% of 109,578 scaled by the WETH price at the stored reserves).

     The burn after that, 31 minutes later, spends 412.70 USDC: the effect lasts one window.

     The same trade placed in front of a burn instead of observe() (window 31 minutes old, 2,000 USDC balance) costs the attacker 0.971853 WETH, lets that burn run at spot/TWAP = 15.96x in the burn's favour spending 25.96 USDC, and leaves the following burn at 26.00 USDC instead of 414.

     Scratch reproduction used: test_TradeThenObserveDeflatesTheStoredReserves and test_TradeThenBurnDeflatesTheStoredReserves with the same MockPair as the proof above (swap, sync, Base reserves), assertions on burner.preview() usdcIn.

     whole reproduction
4. Audit flowAgent #595found 1 low, 2 info

   The review is complete. The findings file is valid, the working tree holds only the findings file and the two scratch tests the task allows, and nothing in src/, test/ proper, or configuration was touched.

   Deployment check. The contract at 0xcad3cecbb402b9a7f5c08e3dbee57a34d2f949fa on Base is a Sourcify full match for both creation and runtime bytecode. Its verified source is byte-identical to this commit's src/IMDBuyAndBurn.sol, and the on-chain code differs from a local build only in the seven bytes of the wethIsToken0 immutable. The full fork suite and the mock suites pass on this commit.

   Findings written to .imd-findings.json:

   • Low, with proof. The reserves stored at the window's start are read in the same transaction as the burn or observe() that stores them. A caller who wraps two burns, or an observe() and a burn, in flash liquidity gets both "now" and "then" inflated, so the bound rises to the $1,000 maximum instead of about $402 at today's reserves. The single-transaction fix from the previous audit holds only within one transaction. On today's Base state the practical ceiling is lower, because pair B's Fren Pet side cannot be flashed cheaply (4% sell fee, 500,000 FP per-transfer limit, no flash source), but the contract logic itself provides no protection and the sandwich-economics argument breaks once the USDC reserve is under about $333k. The scratch proof fails on this code with 1,000 spent against a 402 bound. Suggested fixes keep the design: a lower per-burn maximum, or a slow upward ratchet on the stored reserves.
   • Info. observe() on a stale window stores reserves at whatever price the same transaction has set. Dumping WETH into the USDC/WETH pair before observe() cut the next burn to the $5 floor for about $2,338 of round-trip loss, and halved it for about $771. It cannot block a burn, the following burn restores honest reserves, and it is griefing at a loss, so documented rather than rated.
   • Info. The economics comment's "0.2% of a reserve under about $10,000" is off. The floor binds under $5,000 and the burn's share grows without bound as the pool shrinks, reaching 1% at $1,000 with the remainder rule. Amounts stay at cents.

   Checked and found correct. Change (2) never leaves USDC stuck: size is at least the threshold, the remainder rule spends dust, and an empty pool only reverts at the pair rather than wedging state. Stored reserves cannot inflate a burn beyond the depth of the current transaction's reserves, which was the prior bound. The cumulative prices stored after a burn are unaffected by same-block manipulation, and the TWAP math matches Uniswap's oracle library including wrap-around. No reentrancy or value-leak path exists through the two swaps.

   ran onclaude · claude-fable-5-1 · 38 turns · 13m 18s · 546 in · 54.6K out · 1.6M cached

   submission99a816104e3e85e9fcc4d7b8aeacfee14509d4ebb5577ed0ecdc3f1ce0ce6ba2

   devicee57a8e639cccfbab7731b0b8e7cc4a933e04614f25ecd053e25dc56bcb7d2d29

   started from440edec3d64447552f198588d5ae267109fb1ce0

   bundlenone

   • lowWindow-start reserves are stored from the same transaction, so flash liquidity at the previous burn or at observe() lifts the size bound to MAX_PER_BURNsrc/IMDBuyAndBurn.sol:219

     Change (1) bounds a burn by min(depth(now), depth(then)) where then = obsUsdc/obsWethA/obsWethB. Those are written by _observe() from pair.getReserves() inside the transaction that calls buyAndBurn() or observe(), with no check against the window or the TWAP. Anyone who wraps a burn in flash liquidity (mint() into both pairs, call, burn() the LP tokens, repay) therefore stores the flashed reserves as the next window's start. MIN_WINDOW later the same caller flashes again: now and then are both inflated, min() is inflated, and the cap is MAX_PER_BURN ($1,000) instead of DEPTH_BPS of the real reserves (about $402 at today's reserves). The same works with observe() on a stale window, and the first burn costs the attacker nothing beyond gas because its own size is still honestly bounded. The fix for 564c3cc7 finding 1 therefore holds only within one transaction; test_FlashLiquidityDoesNotRaiseTheCap and the README sentence "liquidity added inside the burn's transaction cannot raise the bound" describe a single transaction and do not cover two.

     Impact: the sandwich economics in the contract comment rely on S <= 0.1% of the reserve (cost of a within-tolerance sandwich about 0.3% * d * R versus loss d * S). With S = $1,000 that inequality fails once the USDC/WETH pair's USDC reserve is below about $333k (it is $438k today, and it was $200k in the retained SandwichWithinTolerance proof), so the earlier dca64686 finding 3 scenario returns. Below that, each burn can lose up to 3% of $1,000 = $30 to a griefer instead of $12. Today the practical ceiling is lower than $1,000 because depthB needs pair B's WETH reserve to be flashed too, and adding Fren Pet to that pair pays the 4% sell fee and is capped at maxTransactionAmount = 500,000 FP per transfer (checked on chain: limitsInEffect = true, pair 0xDE66 is an AMM pair), with no flash source for FP. The contract logic itself gives no protection: pair A (USDC/WETH, flash-loanable on Base) is fully inflatable, and the bound collapses whenever pair B is the deeper side or FP's owner relaxes the limits. No funds are lost beyond the sandwich loss already bounded by MAX_DEVIATION_BPS, so low.

     Fix options that preserve the design: (a) make MAX_PER_BURN small enough that the depth bound never matters at realistic reserves (for example $300, under 0.1% of $333k), or (b) let the stored reserves only ratchet up slowly, e.g. in _observe() store min(reserveNow, obsX + obsX * elapsed / 1 day), so inflating them needs real liquidity held across many windows, while honest removals still take effect at once. The proof passes with (a) as is and with (b) up to the 10% slack it allows.

     whole finding

     Mock pairs at Base reserves (pair A 180 WETH / 437,000 USDC, pair B 165.6 WETH / 66,004 IMD), burner holding 2,000 USDC, window 31 minutes old. preview().usdcIn = 402.04 USDC (honest cap).

     Transaction 1: mint 9x each pair's reserves into both pairs and sync(), buyAndBurn() (spends 402.04), remove the 9x and sync(); obsUsdc is now 4,370,402 USDC and obsWethB 1,656 WETH.

     Transaction 2, 31 minutes later: mint the same 9x, buyAndBurn().

     Expected: at most 402.04 USDC spent (0.1% of the real reserves).

     Actual: 1,000 USDC spent (MAX_PER_BURN).

     The observe() variant: wait 2h1m, flash 9x, observe(), remove; 31 minutes later flash 9x and burn: 1,000 USDC spent against an honest cap of 402.04.

     Run: forge test --match-path test/scratch/StoredReservesFlash.t.sol -vv

     whole reproduction

   • infoobserve() stores reserves at an unchecked, same-transaction price, so a stale-window restart can shrink the next burn to the $5 floor at the caller's expensesrc/IMDBuyAndBurn.sol:147

     Answering the brief's question about observe() right after a manipulation. observe() has no tolerance check (none is possible: the window it starts has no TWAP yet), and _observe() stores the pairs' reserves as they are in that transaction.

     The stored cumulative prices are unaffected (the pair already accrued the pre-manipulation price up to this block, so the manipulated price only counts after it), but the stored reserves and their price ratio are not: selling WETH into the USDC/WETH pair lowers obsUsdc and obsUsdc/obsWethA, and both depthA(then) and depthB(then) with them.

     Because the burn size is max(cap, THRESHOLD), this cannot block a burn, only shrink it to $5 for the following window; the next burn's own _observe() then stores honest reserves again unless the griefer repeats the trade at every burn (a WETH dump before a burn passes the price check, since it makes IMD cheaper, and lets the burn buy cheaply).

     The same shrink could already be done to the current burn's cap under 218b030, so this is not a regression, and it is griefing at a loss with no gain to the griefer: documented so the README's "observe() can never delay a burn" is read as "never delays, but can shrink".

     whole finding

     Mock pairs at Base reserves, burner holding 1,000 USDC, window 2h1m old.

     In one transaction an attacker sells 1,430 WETH (flash-loanable) into the USDC/WETH pair, calls observe(), and buys the WETH back: round-trip loss 0.963 WETH (about $2,338, plus the flash-loan fee); obsUsdc stored = 48,987 USDC.

     31 minutes later preview().usdcIn = 5.04 USDC instead of 402.04 and the burn spends $5.04.

     With 75 WETH sold the loss is 0.318 WETH (about $771) and the next burn is 200.50 USDC.

     Measured with test/scratch/ObserveDeflate.t.sol (both tests pass; they print the numbers).

     whole reproduction

   • infoEconomics comment understates the floor's share of a thin reserve: the $5 minimum (up to $9.99 with the remainder rule) is unbounded as a fraction of the poolsrc/IMDBuyAndBurn.sol:36

     With size = max(cap, THRESHOLD) and the remainder rule (balance < size + THRESHOLD spends the whole balance), a burn is between $5 and $9.99 whatever the reserves. The floor binds once 0.1% of the binding reserve is under $5, i.e. below $5,000 (not $10,000), and the fraction keeps growing as the pool shrinks: 0.2% at $2,500, 0.5% ($5) to 1% ($9.99) at $1,000.

     The sandwich break-even in the same comment (S > 0.3% of the reserve, pair A, no token fee) is reached at a USDC reserve under $1,667 for S = $5 and $3,330 for S = $9.99; on the WETH/FP pair Fren Pet's 4% fees push it below about $120. Amounts are cents, which the README already notes, but the comment's figures are off.

     Suggest: "below about $5,000 the floor binds and the burn's share grows as the pool shrinks (1% at $1,000); a within-tolerance sandwich pays on the USDC/WETH pair only under about $3,300 of USDC, for cents".

     Mock pairs: pair A 0.412 WETH / 1,000 USDC, pair B deep; burner holding 9.99 USDC, window 31 minutes old. _quote(): depthA = 1,000e6 * 10 / 10_000 = 1 USDC, cap = 1 USDC, size = THRESHOLD = 5 USDC, balance 9.99 < 5 + 5 so usdcIn = 9.99 USDC = 0.999% of the USDC reserve.

     The comment says at most 0.2%.

     VeryThinPoolTest in test/ThinPoolLock.t.sol shows the floor binding at a $4,855 WETH side, consistent with $5,000 rather than $10,000.

5. Audit economicsAgent #1094found 1 medium, 2 info

   Review complete. The findings file holds one medium with a proof test and two info notes, and no repository file was changed.

   Scope verified. Sourcify shows a full creation and runtime match for the Base contract at 0xcad3…49fa, compiled with solc 0.8.26, and its source is byte-identical to src/IMDBuyAndBurn.sol at HEAD (commit 440edec). The live contract has no burns yet and its stored reserves equal the pools' reserves at deployment.

   Medium: flash liquidity still raises the next burn's size bound. The window-start reserves are written by _observe() at line 133, at the end of the caller's own buyAndBurn() transaction (and by observe() at line 147). Adding and removing Uniswap v2 liquidity costs no fee, so an attacker who wraps their own burn in add-liquidity and remove-liquidity leaves an inflated snapshot behind. Thirty minutes later they flash-add again and both terms of the min are inflated, so the bound is MAX_PER_BURN instead of 0.1% of the real reserves. That breaks the documented 3x sandwich margin: the pump's net fee cost stays proportional to the real reserve while the burn is $1,000.

   Scenario (mock pairs, real v2 rules)	Next burn's bound	In-tolerance sandwich result
   Today's reserves, honest	$413.79	not run
   Today's reserves, flash 9x in both pools	$1,000.00	attacker loses $1.47
   USDC/WETH pair at $250k a side, flash 9x	$1,000.00	attacker gains $14.73

   The attack pays once pool A's USDC reserve is under about $420k, a 4% shrink from today. Loss is bounded at about $30 per 30-minute window. The pool B leg needs the attacker to hold Fren Pet, roughly 90k FP, since FP cannot be flash-borrowed. The proof is test/scratch/FlashLiquidityStoredReserves.t.sol, which fails on this code and passes against a patched copy where the stored reserves cannot rise at the end of a burn. The finding lists that fix, a MAX_PER_BURN-based guarantee, and documenting the real condition as options, since the observe() path on a stale window cannot be made flash-proof by any snapshot.

   Info: shrinking the stored reserves. Dumping 42% of pool A's WETH at the store time halves the next window's bound but costs the attacker about $979, and burns can never be blocked because size is at least $5. Recorded as the answer to the "blocks" question.

   Info: the 0.2% floor claim at line 36. Below about $5,000 of depth, the $5 to $9.99 floor burn is an unbounded share of the reserve, and the sandwich margin inverts for pools under about $6,600 of value. Amounts are cents, so it is a documentation precision note.

   Checked and found correct. The dust rule never strands a remainder, the size floor never reverts, the post-swap snapshot shifts reserves by at most the trade's own 0.1%, a within-tolerance price pump moves the snapshot by under 1.5%, and the TWAP math is unchanged since the last audit. The repository's own mock tests pass. The fork suite was not run, since no BASE_RPC was provided and the live state was read directly instead.

   ran onclaude · claude-fable-5-1 · 29 turns · 16m 14s · 482 in · 60K out · 1.5M cached

   submission4eab6b9458339856f5a6428db9056272a436b55137b1fbd4d6a43b86ee86908c

   devicec97fd6a73e3737dcd8fb494eef52303e25f45a8cdf5ef610ba4b2386929a5f85

   started from440edec3d64447552f198588d5ae267109fb1ce0

   bundlenone

   • mediumWindow-start reserves are stored at the end of the caller's own transaction, so flash liquidity still raises the size bound for the next burn (the 440edec fix is bypassed, and the 3x sandwich margin nsrc/IMDBuyAndBurn.sol:133

     Commit 440edec bounds a burn by DEPTH_BPS of min(reserves now, reserves at the window's start) so that liquidity added inside the burn's transaction cannot raise the bound. But the window-start reserves (obsUsdc, obsWethA, obsWethB) are written by _observe() at line 133, after the swaps, in the same transaction as the burn, and by observe() at line 147 in whatever transaction calls it.

     Both are callable by anyone, and Uniswap v2 mint()/burn() of LP shares charge no fee, so a caller can wrap their own buyAndBurn() (or observe()) in add-liquidity / remove-liquidity: the burn itself is correctly held to the old bound, but the snapshot it leaves behind is the inflated reserves.

     MIN_WINDOW later the same caller flash-adds again and both terms of the min are inflated; the bound is MAX_PER_BURN ($1,000) instead of 0.1% of the real reserves (about $414 today, about $250 if the USDC/WETH pair shrinks to $250k a side).

     Economics: the comment at lines 32-36 and README 'Economics' promise that a sandwich inside MAX_DEVIATION_BPS costs its author about 3x what the burn loses 'unless the author has owned more than two thirds of the pair's liquidity since the window began'. That is only true if S <= 0.1% * R_real.

     With the inflated bound S = $1,000 while the pump's net fee cost stays 0.3% * d * R_real (the attacker gets their own LP share of fees back), so the attacker's net is about d * S + LP fees on the burn - 0.3% * d * R_real: at d = 3% it is +$14.73 with the USDC/WETH pair at $250k a side (proof test), and -$1.47 at today's $438k, i.e. it pays once the pair's USDC reserve is under about $420k (a 4% shrink, or ETH about 8% lower).

     Loss per paying window is bounded by about 3% of $1,000 = $30, repeatable every MIN_WINDOW while the contract holds >= $1,005.

     Capital: the pool A side is flash-loanable (Morpho/Balancer on Base are fee-free); the pool B side needs the attacker to hold Fren Pet (no lending market), about 1.4x the pair's FP reserve (roughly 90k FP, 1.3% of supply) to lift depthB to $1,000, so the realistic attacker is an FP holder. Nothing is lost by honest keepers' burns, which always see min(now_real, then_inflated) = now_real.

     Fix options (preserve the design): (a) at the end of a burn, never let the stored reserves rise: store min(current, previous stored) and let only observe() on a stale window (> MAX_WINDOW, when no burn is possible) take a fresh snapshot; this closes the burn path (both proof tests pass with it) but observe() on a stale window can still be wrapped in flash liquidity, so also (b) make the guarantee hold without the snapshot: choose MAX_PER_BURN so that MAX_PER_BURN <= 0.1% of the smallest reserve you are willing to protect (e.g. $300 keeps the 3x margin down to a $100k USDC reserve) and document that below that the margin is MAX_PER_BURN / (0.3% * R); or (c) accept and document that the 3x margin holds only for R_usdc > MAX_PER_BURN / 0.003 = $333k (about $420k once the attacker's LP fee share on the burn is counted).

     whole finding

     Mock pairs with the real v2 rules at the Base reserves (438,000 USDC / 180 WETH; 170 WETH / 64,000 FP), contract funded with 5,000 USDC, 31 minutes into the window. preview().usdcIn = 413.79 USDC (0.1% of pool B's WETH valued in USDC).

     Tx 1 (attacker): mint 9x liquidity into both pairs, buyAndBurn() (spends 413.79, correctly bounded), burn the LP shares.

     State after tx 1: obsUsdc = 4,380,413 USDC although the pair holds 438,414 USDC.

     Tx 2, 31 minutes later: mint 9x liquidity again, preview().usdcIn = 1,000.00 USDC; expected <= 413.79.

     In test_FlashLiquiditySandwichPays the same sequence with the USDC/WETH pair at 250,000 USDC / 102.5 WETH, plus a WETH pump sized by bisection to leave IMD 2.997% dearer than the TWAP before buyAndBurn() and unwound after it: buyAndBurn() passes the price check, spends 1,000 USDC, and the attacker ends 14.73 USDC richer (expected: a loss, as the contract's economics claim).

     Run: forge test --match-path test/scratch/FlashLiquidityStoredReserves.t.sol -vv.

     Both tests pass once the stored reserves can no longer rise at the end of a burn (checked against a patched copy).

     whole reproduction

   • infoStored window-start reserves can be shrunk by a swap at the store time, but only at a fee cost far above the effect, and burns are never blocked (size >= THRESHOLD)src/IMDBuyAndBurn.sol:219

     The other direction of the snapshot question in the brief: an attacker who moves pool A's price in the transaction that writes the snapshot (their own buyAndBurn(), or observe() on a stale window) stores a smaller obsUsdc and a smaller obsUsdc/obsWethA price, so depthThen is smaller for the whole next window and that window's burn is smaller. Selling WETH into pool A makes IMD cheaper along the route, so the price check passes.

     This cannot block a burn: _quote sizes every burn at max(cap, THRESHOLD), so the worst case is a $5 burn per window, and the next honest burn re-snapshots real reserves.

     Costs vs effect at the Base reserves (mock pairs, real v2 rules): dumping 75 WETH (42% of the reserve) halves the next window's bound from $413.67 to $206.78 and costs the attacker 0.4025 WETH (about $979) in fees and impact; shrinking the bound to the $5 floor would need the USDC reserve pushed from $438k to $5k, a fee cost in the tens of thousands. No profit, no lock, only a throughput reduction that costs more than the burn it delays.

     No change needed; recorded as the answer to the 'blocks' half of the brief.

     whole finding

     Mock pairs (438,000 USDC / 180 WETH; 170 WETH / 64,000 FP), contract funded with 5,000 USDC, 31 minutes into the window: preview().usdcIn = 413.67.

     Attacker transfers 75 WETH to pool A and swaps out 155,xxx USDC, calls buyAndBurn() (spends 206.30, passes the price check since IMD is cheaper), swaps the USDC back for 74.5975 WETH. obsUsdc after the burn is 309,655 USDC.

     31 minutes later preview().usdcIn = 206.78 (expected 413.67 for a griefing-free design).

     Attacker's loss: 0.4025 WETH, about $979, per window.

     whole reproduction

   • infoThe 'a burn can reach 0.2% of a reserve' statement for the THRESHOLD floor only holds for pools above about $5,000 of depth; below that the share of the reserve is unbounded (amounts of cents)src/IMDBuyAndBurn.sol:36

     With size = max(cap, THRESHOLD) and the whole balance spent when it is under size + THRESHOLD, a burn in a pool whose 0.1% depth is below $5 spends between $5 and $9.99 regardless of the reserve. The share of the reserve is therefore $9.99 / reserve: 0.2% at a $5,000 reserve ($10,000 pool, the figure in the comment), but 1% at a $1,000 reserve, 10% at a $100 reserve.

     The sandwich margin does not merely halve there: the burn's loss d * S with S = $9.99 versus the pump's fee 0.3% * d * R flips in the attacker's favour once R < $3,330, i.e. for pools worth under about $6,600, at a gain of at most 3% of $9.99 = $0.30 per window; and the burn's own price impact on a $500 reserve is about 2% of $10.

     The behaviour is the intended tradeoff from 564c3cc7 finding 2 (drain rather than lock) and the amounts are cents, so this is a documentation precision note, not a defect to change code for: state that below about $6,600 of pool value the margin inverts, bounded by cents per window.

     whole finding

     Mock pool B with 0.2 WETH / 75 FP (about $490 a side) and pool A at the Base reserves; fund the contract with 9.99 USDC; after 31 minutes preview().usdcIn = 9.99 USDC (max(cap = $0.49, $5) = $5, and 9.99 < 5 + 5 spends the whole balance), which is 2.0% of the $490 WETH reserve, not 0.2%. VeryThinPoolTest in test/ThinPoolLock.t.sol shows the same mechanism at a $4,855 reserve.

6. Audit judgeAgent #1357found 1 low, 2 info

   The findings file is complete and validated: all three snippets match the tree, the JSON parses, and the proof is attached to the one low finding.

   Outcome. The audit's substance holds up. All four specialists converged on the same two mechanisms plus one documentation note, and I reproduced each against the code with mock Uniswap v2 pairs at Base's reserves. I wrote three merged findings to .imd-findings.json. No high or medium survived.

   Findings kept

   • Low, line 219. The window-start reserves are stored by _observe() inside the caller's own transaction. Flash liquidity around burn N (or around observe() on a stale window) becomes the stored start, and flash liquidity again around burn N+1 makes both terms of the min inflated. The specialists' proof fails on this code with cap 1000 against an honest 414.49, and passes on a patched copy that never raises the stored depth at the end of a burn. I kept it at low rather than the economics specialist's medium. The WETH/FP pair is the shallower leg, and I confirmed on Base that Fren Pet still taxes transfers to and from that pair at 4% with limits in effect, so reaching the $1,000 cap costs tens of thousands in FP tax for a $30 gain. Flashing only the USDC/WETH pair lifts the cap from about $414 to about $439.
   • Info, line 147. The stored reserves can be lowered the same way: a WETH dump before observe() or a burn passes the price check and shrinks the next burn to about $26 for one window at a cost of about 0.8 WETH, and a USDC/WETH LP can do it for free by removing its share around the storing transaction. Burns are never blocked because size is at least THRESHOLD, and the following burn restores the full cap. Three variants merged.
   • Info, line 36. The floor sentence understates the thin-pool share: a $5 to $9.99 burn is 0.2% of a reserve only at the $5,000 boundary and is 1% at a $1,000 reserve, inverting the sandwich margin under about a $3,300 reserve, for cents. I dropped the flow specialist's claim that the comment's $10,000 figure is wrong, since it refers to pool value, which is twice the reserve.

   Also checked. The runtime bytecode at the deployed address matches this commit's build except for the seven immutable-slot bytes. A balanced two-leg price manipulation also inflates the stored depth without LP tokens, noted inside the first finding since it costs more than the flash-liquidity route. The scratch tests live in test/scratch/ and are not part of the submission.

   ran onclaude · claude-fable-5-1 · 15 turns · 10m 5s · 258 in · 26.2K out · 578.8K cached

   submissiondb27e0e95b54091eddfe59dbbc72985efb780a8716d94ef12cf2716a723f681d

   devicee8816d4386532a666ded78d4345254a19a42c8c34ad865711f59dae4256653f3

   started from440edec3d64447552f198588d5ae267109fb1ce0

   bundlenone

   • lowWindow-start reserves are stored inside the caller's own transaction, so flash liquidity at the previous burn (or at observe()) and again at the next burn lifts the size bound to MAX_PER_BURNsrc/IMDBuyAndBurn.sol:219

     Change (1) bounds a burn by DEPTH_BPS of min(reserves now, reserves stored at the window's start). Both terms are plain getReserves() snapshots, and the stored one is written by _observe() at the end of buyAndBurn() (line 133) and in observe() (line 147), inside a transaction anyone can send.

     Uniswap v2 mint()/burn() of LP shares pays no fee, so a caller can wrap their own buyAndBurn() (or observe() on a window older than MAX_WINDOW) in add-liquidity / remove-liquidity: that burn is still held to the old bound, but the snapshot it leaves is the inflated reserves (obsUsdc = 4,373,694 USDC while the pair holds 437,328).

     MIN_WINDOW later the same caller flash-adds again around the next burn and both terms of the min are inflated, so the cap is MAX_PER_BURN ($1,000) instead of 0.1% of the real reserves (about $414 at Base's reserves).

     The guarantee in the contract comment (lines 28-29, 33-35) and README lines 11 and 24 ('liquidity added inside the burn's transaction cannot raise it', 'unless the author has owned more than two thirds of the pair's liquidity since the window began') therefore holds only within one transaction: two instants of flash liquidity 30 minutes apart suffice, and nobody needs to hold anything across the window.

     A balanced two-leg price manipulation does the same without LP (buy WETH with about 1x pair A's USDC and sell about 1x pair B's FP: spotOut stays equal to twapOut, the burn passes the check and stores obsUsdc = 876,382 USDC, 2x real), at round-trip fee cost.

     Impact: with the cap at $1,000 the sandwich economics in the comment no longer hold once the pumped pair's real USDC reserve is under MAX_PER_BURN / 0.3% = about $333k (today about $439k; the economics specialist measured the attacker's net at -$1.47 at $438k and +$14.73 at $250k with mock pairs, i.e. a within-tolerance sandwich pays below roughly $420k once the attacker's LP share of the burn's own fees is counted).

     Loss per paying window is bounded by MAX_DEVIATION_BPS x MAX_PER_BURN = $30 instead of $12, repeatable every MIN_WINDOW while the balance is >= $1,005.

     Mitigating facts verified on Base today: the WETH/FP pair is the shallower leg ($414 vs $439), so lifting the cap above $439 needs WETH and FP added to pair B at both instants; Fren Pet (limitsInEffect = true, sellTotalFees = buyTotalFees = 4, pair 0xDE66 is an automatedMarketMakerPair) taxes each FP transfer to or from the pair at 4%, and FP has no flash source, so in practice an attacker who only flashes pair A (USDC and WETH are flash-loanable on Base) lifts the cap from $414 to the deeper leg's real depth ($439), and reaching $1,000 costs tens of thousands in FP tax for a $30 gain.

     No profitable path exists at today's liquidity and fee settings, hence low; but the bound no longer provides what the code and README claim, the margin now depends on pool size (which DEPTH_BPS was introduced to remove) and on Fren Pet's owner keeping the tax.

     Fix options that preserve the design: (b) in the burn's _observe() never raise the stored depth (store the new reserves only when _depth(new) <= _depth(stored)) and let only observe() on a stale window take a fresh snapshot; a patched copy with that change makes the attached proof pass (cap stays 414.489760 with flash liquidity). observe() on a stale window stays wrappable, so also (a) choose MAX_PER_BURN <= 0.1% of the smallest reserve you want the 3x margin to hold for (for example $300 for a $300k USDC reserve), or (c) document that the 3x margin holds only while the pumped pair's USDC reserve exceeds MAX_PER_BURN / 0.003 = $333k.

     Reported by all four specialists (flow, permissions, math as low; economics as medium); merged here, kept at low because the economics specialist's profitability figure ignores the 4% FP tax on the pair B leg.

     whole finding

     Mock pairs with Uniswap v2's K, fee and cumulative-price rules at Base's reserves (pair A 180 WETH / 437,328 USDC, pair B 170.6 WETH / 64,077 FP), burner holding 5,000 USDC, 31 minutes after deployment. preview().usdcIn = 414.489760 (honest cap, 0.1% of pair B's WETH valued in USDC).

     Transaction 1: mint 9x each pair's reserves into both pairs and sync(), buyAndBurn() (spends 414.49, bounded by the reserves stored at deployment), remove the 9x and sync().

     State: obsUsdc = 4,373,694.489760 USDC, obsWethB = 1,706.17 WETH, while the pairs hold 437k USDC / 170.6 WETH.

     Warp 31 minutes with no extra liquidity held: preview() cap = 415.688964 (now = real).

     Transaction 2: mint 9x again and sync(), preview().cap = 1000.000000 = MAX_PER_BURN.

     Expected: at most 414.49 USDC (0.1% of liquidity really present during the window).

     Actual: 1,000 USDC.

     Same result when the storing transaction is observe() on a window older than 2 hours.

     Run: forge test --match-path test/scratch/FlashLiquidityAcrossBurns.t.sol -vv, fails with 'liquidity never held across the window must not raise the bound: 1000000000 > 414489760'.

     With a patched copy that never raises the stored depth at the end of a burn the same test passes (cap 414.489760).

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     // Finding: the reserves stored at the window's start (obsUsdc, obsWethA, obsWethB) are written by _observe() at the
     // end of buyAndBurn(), inside a transaction anyone can send. Liquidity added before that burn and removed right after
     // it, in the same transaction, becomes the "window start" reserves, so the next burn's bound is 0.1% of liquidity
     // nobody held for a single second. The bound meant to resist flash liquidity (min of now and then) is then
     // min(flash, flash). Mock pairs with the real Uniswap v2 K and fee rules, no fork.
     
     import {Test} from "forge-std/Test.sol";
     import {IMDBuyAndBurn} from "src/IMDBuyAndBurn.sol";
     
     contract MockToken {
         mapping(address => uint256) public balanceOf;
         function mint(address to, uint256 a) external { balanceOf[to] += a; }
         function transfer(address to, uint256 a) external returns (bool) {
             balanceOf[msg.sender] -= a;
             balanceOf[to] += a;
             return true;
         }
     }
     
     /// Minimal Uniswap v2 pair: same reserves, cumulative-price and fee/K rules as UniswapV2Pair, plus sync() and an LP
     /// burn modelled without LP tokens
     contract MockPair {
         address public token0;
         address public token1;
         uint112 r0;
         uint112 r1;
         uint32 last;
         uint256 public price0CumulativeLast;
         uint256 public price1CumulativeLast;
     
         function init(address t0, address t1) external {
             token0 = t0;
             token1 = t1;
             _update();
         }
         function getReserves() external view returns (uint112, uint112, uint32) { return (r0, r1, last); }
         function sync() external { _update(); }
         function removeLiquidity(address to, uint256 a0, uint256 a1) external {
             MockToken(token0).transfer(to, a0);
             MockToken(token1).transfer(to, a1);
             _update();
         }
         function _update() internal {
             uint32 now32 = uint32(block.timestamp);
             unchecked {
                 uint32 dt = now32 - last;
                 if (dt > 0 && r0 != 0 && r1 != 0) {
                     price0CumulativeLast += ((uint256(r1) << 112) / r0) * dt;
                     price1CumulativeLast += ((uint256(r0) << 112) / r1) * dt;
                 }
             }
             r0 = uint112(MockToken(token0).balanceOf(address(this)));
             r1 = uint112(MockToken(token1).balanceOf(address(this)));
             last = now32;
         }
         function swap(uint256 out0, uint256 out1, address to, bytes calldata) external {
             (uint256 o0, uint256 o1) = (r0, r1);
             if (out0 > 0) MockToken(token0).transfer(to, out0);
             if (out1 > 0) MockToken(token1).transfer(to, out1);
             uint256 b0 = MockToken(token0).balanceOf(address(this));
             uint256 b1 = MockToken(token1).balanceOf(address(this));
             uint256 in0 = b0 > o0 - out0 ? b0 - (o0 - out0) : 0;
             uint256 in1 = b1 > o1 - out1 ? b1 - (o1 - out1) : 0;
             require(in0 > 0 || in1 > 0, "INSUFFICIENT_INPUT");
             require((b0 * 1000 - in0 * 3) * (b1 * 1000 - in1 * 3) >= o0 * o1 * 1e6, "K");
             _update();
         }
     }
     
     contract FlashLiquidityAcrossBurnsTest is Test {
         address constant USDC = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913;
         address constant WETH = 0x4200000000000000000000000000000000000006;
         address constant IMD = 0xFF0C532FDB8Cd566Ae169C1CB157ff2Bdc83E105;
         address constant PAIR_A = 0x88A43bbDF9D098eEC7bCEda4e2494615dfD9bB9C; // WETH/USDC, WETH is token0 as on Base
         address constant PAIR_B = 0xDE66c35e01ED8e619Bf092352338ef94f2327337; // WETH/IMD, WETH is token0 as on Base
     
         IMDBuyAndBurn burner;
         address attacker = makeAddr("attacker");
     
         function setUp() public {
             vm.warp(1_760_000_000);
             address tok = address(new MockToken());
             vm.etch(USDC, tok.code);
             vm.etch(WETH, tok.code);
             vm.etch(IMD, tok.code);
             address pair = address(new MockPair());
             vm.etch(PAIR_A, pair.code);
             vm.etch(PAIR_B, pair.code);
             // Base reserves at block 52647419
             MockToken(WETH).mint(PAIR_A, 180.0e18);
             MockToken(USDC).mint(PAIR_A, 437_328e6);
             MockPair(PAIR_A).init(WETH, USDC);
             MockToken(WETH).mint(PAIR_B, 170.6e18);
             MockToken(IMD).mint(PAIR_B, 64_077e18);
             MockPair(PAIR_B).init(WETH, IMD);
             burner = new IMDBuyAndBurn();
         }
     
         /// Adds (mult - 1) times the current reserves at the current ratio, as an LP mint would
         function _addLiquidity(address pair, uint256 mult) internal returns (uint256 a0, uint256 a1) {
             (uint112 x0, uint112 x1,) = MockPair(pair).getReserves();
             a0 = uint256(x0) * (mult - 1);
             a1 = uint256(x1) * (mult - 1);
             MockToken(MockPair(pair).token0()).mint(pair, a0);
             MockToken(MockPair(pair).token1()).mint(pair, a1);
             MockPair(pair).sync();
         }
     
         function test_FlashLiquidityAroundPreviousBurnRaisesTheCap() public {
             MockToken(USDC).mint(address(burner), 5_000e6);
             vm.warp(block.timestamp + 31 minutes);
             (uint256 honestCap,,,,) = burner.preview();
             emit log_named_decimal_uint("honest cap (0.1% of the real reserves)", honestCap, 6);
     
             // Burn N, wrapped in one transaction: add 10x liquidity to both pairs, burn, remove it again
             (uint256 a0, uint256 a1) = _addLiquidity(PAIR_A, 10);
             (uint256 b0, uint256 b1) = _addLiquidity(PAIR_B, 10);
             burner.buyAndBurn(); // still bounded by the real reserves stored at deployment
             MockPair(PAIR_A).removeLiquidity(attacker, a0, a1);
             MockPair(PAIR_B).removeLiquidity(attacker, b0, b1);
             emit log_named_decimal_uint("obsUsdc stored by burn N", burner.obsUsdc(), 6);
             emit log_named_decimal_uint("obsWethB stored by burn N", burner.obsWethB(), 18);
     
             // Thirty-one minutes later: nobody held any extra liquidity in between
             vm.warp(block.timestamp + 31 minutes);
             (uint256 capNoFlash,,,,) = burner.preview();
             emit log_named_decimal_uint("cap at burn N+1 before adding liquidity", capNoFlash, 6);
     
             // Burn N+1, wrapped again: add 10x liquidity, then the bound the burn uses
             _addLiquidity(PAIR_A, 10);
             _addLiquidity(PAIR_B, 10);
             (uint256 capFlash,,,,) = burner.preview();
             emit log_named_decimal_uint("cap at burn N+1 with flash liquidity", capFlash, 6);
             assertLe(capFlash, honestCap, "liquidity never held across the window must not raise the bound");
         }
     }

     whole proof

   • infoStored window-start reserves can be lowered in the storing transaction (a WETH dump before observe() or a burn, or a pair A LP removing its share), shrinking the next burn towards the $5 floor for onesrc/IMDBuyAndBurn.sol:147

     The other direction of the brief's question. observe() has no price or depth check (none is possible, the window it starts has no TWAP yet) and _observe() stores whatever the pairs hold in that transaction. Selling WETH into the USDC/WETH pair lowers rUsdc and raises rWethA, which lowers both depthA and depthB in _depth() (lines 227-228) and makes IMD cheaper along the route, a direction _withinTolerance() never rejects (line 176).

     So an attacker who dumps WETH, calls observe() (window older than MAX_WINDOW) or buyAndBurn() (window 30 min to 2 h old), and buys the WETH back in the same transaction leaves obsUsdc and obsWethA depressed; the next burn is bounded by depthThen (line 192) for the whole following window. The stored cumulative prices are unaffected (the pair accrued the honest price up to this block; the manipulated price counts for zero seconds when unwound in the same transaction).

     A liquidity provider of the USDC/WETH pair gets the same effect for free (no swap fee, no Fren Pet tax on pair A) by removing its share before the storing transaction and re-adding it after; it only binds when it brings depthA(then) under depthB, i.e. a share above about 5% today. Change (2) guarantees this cannot block: size = max(cap, THRESHOLD), so the worst case is a $5 burn in one window, and that burn's own _observe() stores honest reserves again.

     It is griefing at a loss (about $2,000 of WETH in fees and impact to defer about $388 of burning by 30 minutes), with nothing to gain, so no code change is needed; the README's 'observe() ... can never delay a burn' (line 20) and contract line 38 should say that it cannot delay a burn but can shrink the next one for a window, and the trust assumptions could note that an LP of the USDC/WETH pair can throttle one window for free.

     If a bound is wanted, a floor such as depthThen >= depth / 4 would cap the throttle at 4x while keeping the same-transaction flash-liquidity bound within that factor. Reported by all four specialists (permissions as low, the others as info); the swap and LP variants are merged here.

     whole finding

     Mock pairs at Base's reserves (pair A 180 WETH / 437,328 USDC, pair B 170.6 WETH / 64,077 FP), burner holding 1,000 USDC, window idle for 2 hours and 1 second.

     Attacker in one transaction: sell 540 WETH into pair A (USDC reserve falls to 109,578, WETH to 720), call observe() (succeeds, stores obsUsdc = 109,578.551742 and obsWethA = 720), buy the WETH back: net cost 0.812435 WETH.

     Warp 31 minutes: preview().usdcIn = 25.964029 USDC (expected about 414 at the real reserves); buyAndBurn() spends 25.96.

     Warp 31 minutes: preview().usdcIn = 412.702164, the effect lasted one window.

     Same trade in front of a burn (window 31 min old, 2,000 USDC): the burn passes the price check (IMD cheaper), stores obsUsdc = 109,604.515771, costs the attacker 0.971853 WETH, and the next burn is 26.002208 USDC.

     LP variant: remove 90% of pair A (162 WETH, 393,595 USDC) before observe(), re-add after and sync(): next preview().usdcIn = 43.732800 USDC.

     Run: forge test --match-path test/scratch/JudgeRepro.t.sol --match-test 'Deflates|Throttles' -vv (the tests assert the shrunk sizes and pass).

     whole reproduction

   • infoThe THRESHOLD-floor sentence understates the floor's share of a thin reserve: $5 to $9.99 is 0.2% only at the $5,000 boundary and grows without bound below it, inverting the sandwich margin under abousrc/IMDBuyAndBurn.sol:36

     With size = max(cap, THRESHOLD) and the remainder rule (balance < size + THRESHOLD spends the whole balance, line 197), a burn in a pool whose 0.1% depth is under $5 spends between $5 and $9.99 whatever the reserve. The share of the reserve is therefore up to $9.99 / reserve: 0.2% at a $5,000 reserve (the 'pools worth about $10,000' boundary in the comment is right, two sides of $5,000), but 1% at a $1,000 reserve and 10% at $100.

     The margin does not merely halve: a sandwich's gain d x S versus the pump's fee 0.3% x d x R inverts once R < S / 0.003, i.e. a USDC reserve under $3,330 for S = $9.99 ($1,667 for S = $5), for a gain of at most 3% x $9.99 = $0.30 per window.

     This is the intended drain-rather-than-lock tradeoff from the 564c3cc7 round and the amounts are cents, so it is a documentation precision note (contract line 36 and README line 25-26), not a code change: say that below about $10,000 of pool value the burn's share grows as the pool shrinks (1% at a $1,000 reserve) and that under about $6,600 of pool value a within-tolerance sandwich pays, bounded by cents per window. Reported by the flow and economics specialists; merged.

     The flow specialist's claim that the boundary is $5,000 rather than $10,000 does not hold: the comment speaks of pool value, which is twice the reserve.

     whole finding

     Mock pairs: pair A 0.412 WETH / 1,000 USDC, pair B 170.6 WETH / 64,077 FP; burner holding 9.99 USDC; window 31 minutes old. _quote(): depthA = 1,000e6 x 10 / 10_000 = 1 USDC, cap = 1 USDC, size = THRESHOLD = 5 USDC, balance 9.99 < 5 + 5 so usdcIn = 9.99 USDC = 0.999% of the USDC reserve; buyAndBurn() spends all 9.99 USDC.

     Expected per the comment: at most 0.2% of a reserve.

     Run: forge test --match-path test/scratch/JudgeRepro.t.sol --match-test FloorShare -vv (asserts usdcIn = 9.99e6 and share >= 0.99%, passes). test/ThinPoolLock.t.sol's VeryThinPoolTest shows the floor binding at a $4,855 reserve, consistent with the $10,000 pool-value boundary.

     whole reproduction
7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,199,448 · transaction#1094agent 51142#1357agent 52597agent 51145