Four agents audited the code as it is at e1fd7c7, 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)

3 low6 info

• 1.lowOracle history survives a rollback to the old hook and cannot be reseeded, so a forward re-upgrade prices the 600 s floor off a stale tick with no fresh warmupflat/MigrationFeeHookV2.sol:2755

          require(_settings().launched && _oracle().count == 0, "Oracle already seeded");

  BuybackOracle state lives in ORACLE_SLOT and is written only by MigrationFeeHookV2 (beforeSwap/afterSwap/initializeBuybackOracle). The documented rollback points the proxy back to 0x23efc76d (the live implementation today), which never writes that slot, while user swaps keep moving the pool tick.

  When V2 is upgraded in again, initializeBuybackOracle reverts because count != 0, and BuybackOracle._cumulativeAt (line 1728) extrapolates the whole rollback gap with the frozen self.tick. meanTick only checks that time-600 >= oldest observation, which the old startedAt satisfies, so no new warmup applies and for up to 600 s minimumBuybackOutput is derived from the pre-rollback price.

  If CLAUS got cheaper in ETH terms during the rollback (tick rose) the floor is below the live market and the only remaining bound is the keeper-chosen quotedTick/maxTickDrift, which v52 was meant to stop relying on; if CLAUS got dearer every buyback reverts for up to 600 s. The oracle cannot distinguish 'no swaps under V2' (tick genuinely unchanged, extrapolation correct) from 'swaps unrecorded under the old implementation'.

  Preconditions: an owner-executed rollback and re-upgrade plus a keeper buyback inside the first 600 s, all privileged actors, hence low. It does not affect the planned first activation: ORACLE_SLOT reads zero on the live proxy today (verified via eth_getStorageAt on chain 4663). Merged from the economics and math specialists (same mechanism, same fix).

  Fix preserving the design: let initializeBuybackOracle (onlyOwner, outsideSwap) reset count/startedAt and require a fresh 600 s warmup when it is called again (or when now - self.timestamp > WINDOW and the implementation changed), and make the documented rollback/re-upgrade procedure include that call.

  whole finding

  Using BuybackOracle exactly as the hook calls it: record(tick 0) at t=1,000,000 (seed), record(0) at t+700 (oracle ready).

  Roll back for 86,400 s during which the live tick moves to +6932 (1 ETH buys about 2x the CLAUS) and nothing is recorded.

  Re-upgrade and let the first swap record tick 6932 at R=t+700+86,400.

  In the same block meanTick returns 0 and minimumOutput(1e18) returns about 0.995e18 although the live price implies about 2e18.

  Expected: OracleNotReady until 600 s of post-reactivation history exists.

  Actual: a floor about 50% below the live price is accepted. test/scratch/OracleRollback.t.sol::test_reupgradeUsesStaleTickWithoutWarmup fails on the current code with 'next call did not revert as expected' (run with forge 1.8.3, solc 0.8.26, via_ir).

  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;
  
  import "forge-std/Test.sol";
  import {BuybackOracle} from "flat/MigrationFeeHookV2.sol";
  
  contract OracleHarness {
      BuybackOracle.State internal s;
      function record(int24 tick) external { BuybackOracle.record(s, tick, uint64(block.timestamp)); }
      function mean() external view returns (int24) { return BuybackOracle.meanTick(s, uint64(block.timestamp)); }
      function minOut(uint128 a) external view returns (uint256) { return BuybackOracle.minimumOutput(s, a, uint64(block.timestamp)); }
  }
  
  /// Models V2 -> rollback to old implementation (which never writes ORACLE_SLOT) -> V2 again.
  contract OracleRollbackTest is Test {
      OracleHarness h;
      function setUp() public { h = new OracleHarness(); }
  
      function test_ringWrapAndSameTimestampSpamDoNotDoS() public {
          vm.warp(5_000_000);
          h.record(100);
          for (uint256 i = 1; i <= 1300; ++i) {
              vm.warp(5_000_000 + i);
              h.record(int24(int256(100 + (i % 7))));
              h.record(-800_000); // same-timestamp spike, zero weight
              h.record(int24(int256(100 + (i % 7))));
          }
          int24 m = h.mean();
          assertGe(m, 100); assertLe(m, 107);
      }
  
      function test_reupgradeUsesStaleTickWithoutWarmup() public {
          vm.warp(1_000_000);
          h.record(0);                       // initializeBuybackOracle at tick 0
          vm.warp(1_000_000 + 700);
          h.record(0);                       // normal V2 swaps, oracle ready
          // Rollback to the old implementation for one day. Real swaps move the
          // pool to tick +6932 (ETH buys ~2x the CLAUS) but nothing is recorded.
          vm.warp(1_000_000 + 700 + 86_400);
          // Re-upgrade to V2; initializeBuybackOracle cannot reseed (count != 0).
          // The first swap's beforeSwap records the *current* tick.
          h.record(6932);
          // Buyback in the very same block. Today mean() returns the stale tick 0
          // and minOut(1 ether) ~= 0.995e18 although the live price gives ~2e18:
          // the floor is ~50% weaker and no fresh 600 s warmup applies.
          // Expected: stale history is unusable until 600 s of fresh observations.
          vm.expectRevert();
          h.minOut(1 ether);
      }
  }

  whole proof

• 2.lowFixed 50 bps floor over the 600 s TWAP ignores the batch's own price impact: the configured 0.5 ETH maxBatch is not executable at live pool depth and buybacks stall during uptrendsflat/ClausBuybackVaultV2.sol:2218

          require(p.minBuyOutput >= hook.minimumBuybackOutput(p.amountIn), "Oracle minimum");

  The vault requires minBuyOutput >= hook.minimumBuybackOutput(amountIn) = ceil(0.995 * amountIn * 1.0001^ceil(TWAP600 tick)) and passes that same value to the router as amountOutMinimum. The reference is a spot-equivalent quote and includes no allowance for the vault's own impact. For a constant-liquidity exact-input swap the realised output relative to spot is L/(L + amountIn*sqrtP).

  Live state read from chain 4663 at block 108,807,336 (pool 0x51c9a331..., liquidity 44751331626749337822233, sqrtPriceX96 0x5bf56b74fb628a07b3620079e48, tick 145885, about 2.16e6 CLAUS per ETH, about 30.4 ETH virtual depth) gives a 162 bps shortfall for 0.5 ETH, 82 bps for 0.25 ETH and 49 bps for 0.15 ETH; with TWAP == spot the largest executable batch is about 0.153 ETH.

  After one successful buyback the TWAP lags the pushed-up spot for 600 s so the next batch must be smaller still. The same mechanism makes every buyback revert when spot CLAUS is more than about 0.5% minus impact above the 10-minute mean (normal uptrend), and lets a front-runner block one keeper transaction by moving spot about 50 ticks (cost about 4% in hook fees on a position of about 0.25% of in-range depth, roughly 0.008 ETH at current depth).

  A protocol fee of up to 0.1% could additionally be set by the pool manager's protocolFeeController 0x6d0009504D129CF5002Dba61D9Ae8575AA79314c (code present) and would eat into the margin.

  These are liveness limitations, not value extraction: the keeper cannot lower the floor, a reverted buyback does not consume lastBuybackBlock, and sustained manipulation (holding the price away from market for most of 600 s while paying 2% hook fee per leg against a gain bounded by 0.5% of at most 0.5 ETH per ArbSys block) is not profitable at current depth. The AMM history is not an external fair-value oracle; this must be re-assessed if liquidity thins.

  Reported because review-context.json and the README state maxBatch stays 0.5 ETH while that value cannot be used as configured. Merged from the permissions (low), economics (info) and flow (info) specialists.

  Operational fix: size batches to about 0.15 ETH or less at current depth; a depth-aware floor would be a design change requiring a scope decision.

  whole finding

  State: live liquidity 44751331626749337822233 and tick 145885, oracle warmed with a flat 600 s history at tick 145885 so minimumBuybackOutput(0.5e18) = ceil(0.995 * 0.5e18 * 1.0001^145885).

  Input: keeper calls buyAndBurn(Plan{amountIn=0.5e18, minBuyOutput=that floor, quotedTick=145885, maxTickDrift=0, valid quoteBlock/hash, deadline=now+60}).

  Expected per the declared policy: 0.5 ETH spent and burned.

  Actual: the pool delivers L/(L+amountIn*sqrtP) = 98.38% of the spot quote, below 99.5%, so the router reverts V4TooLittleReceived and the whole call reverts; amountIn=0.15e18 (99.51%) succeeds.

  Numbers computed from the live extsload reads above; the shortfall formula is exact for a swap that stays inside one tick range.

  whole reproduction

• 3.lowCLAUS sent directly to the vault is stranded: the burn path only burns the per-call delta and recovery is ETH-onlyflat/ClausBuybackVaultV2.sol:2237

          burned = token.balanceOf(address(this)) - balanceBefore;

  buyAndBurn computes burned = balanceOf(this) - balanceBefore, burns exactly that, and then requires balanceOf(this) == balanceBefore (line 2240). recoverUnspentFees (line 2249) moves native ETH only. Any CLAUS that reaches the vault outside a buyback (direct transfer by mistake, airdrop, token distribution) is therefore never burned and can never be moved by the owner.

  The hook's claimLiquidityFees pays ETH only, so this is not reachable through protocol flows, and it is not exploitable for profit; value is stranded in a contract whose purpose is burning. Minimal fix preserving the design: burn the whole post-swap balance in buyAndBurn (require the delta >= minBuyOutput and totalSupply to drop by the amount burned), or add an owner-only sweep of key.currency1 that burns rather than transfers.

  Verified with a mock harness against the exact flat source (chainid 4663, manager/router/ArbSys mocked at the hardcoded addresses, vault funded with 1 ETH): 1) token.mint(vault, 5e18) simulating a direct transfer.

  2. keeper calls buyAndBurn(amountIn 0.1 ETH); router delivers 1e20 tokens, burned == 1e20 and the Burn mismatch check passes.

  3. token.balanceOf(vault) is still 5e18; owner calls recoverUnspentFees(owner, 0) and the balance is unchanged.

  Expected: owner can recover or the next buyback burns it.

  Actual: no function in the contract can move or burn it (test_strayTokensStuck passes, i.e. the tokens remain).

  whole reproduction

• 4.infoOracle seeding is not exclusive to initializeBuybackOracle: the first swap after the upgrade seeds it, so a non-atomic upgrade makes the planned batch revert with 'Oracle already seeded'flat/MigrationFeeHookV2.sol:2755

          require(_settings().launched && _oracle().count == 0, "Oracle already seeded");

  beforeSwap and afterSwap call _recordBuybackPrice unconditionally (lines 2852 and 2865) and BuybackOracle.record seeds on count == 0 (line 1675: startedAt = time, count = 1). 'Exactly once' is enforced by the count check, but the ordering 'upgrade, then seed through the administrator' holds only if ProxyAdmin.upgradeAndCall and initializeBuybackOracle run in the same administrator.execute batch, which the plan states.

  If the upgrade ever lands in a separate transaction, or the batch is retried after a partial failure, any user swap seeds the oracle first and the batch containing initializeBuybackOracle reverts as a whole; the 600 s warmup then counts from that swap. No safety property is weakened (no path resets history and OracleNotReady blocks buybacks for 600 s regardless of who seeded); this is a procedural constraint. Merged from the permissions and flow specialists.

  Mitigation: keep upgrade and seed in one batch (as planned) or make initializeBuybackOracle a no-op when count != 0.

  whole finding

  State: proxy upgraded to MigrationFeeHookV2 in transaction A with no further calls.

  Any user swaps on the pool in transaction B (beforeSwap -> _recordBuybackPrice -> record seeds count = 1).

  Transaction C: administrator.execute([oldVault.configure(keeper,maxBatch,false), hookAdmin.upgradeAndCall(...) or omitted, hook.initializeBuybackOracle(), hook.setLiquidityVault(newVault), oldVault.recoverUnspentFees(...)]) reverts at initializeBuybackOracle with 'Oracle already seeded' (require at line 2755) and the whole batch fails.

  Expected under the atomic plan: batch succeeds.

  Code path confirmed by reading record() and the unconditional _recordBuybackPrice() calls.

  whole reproduction

• 5.infoRollback asymmetry: with the new vault selected, reverting the hook to the old implementation makes every buyback revert until the old vault is re-selected and re-enabledflat/ClausBuybackVaultV2.sol:2217

          IClausFeeHook hook = IClausFeeHook(address(key.hooks));

  ClausBuybackVaultV2 depends on two selectors that exist only in MigrationFeeHookV2: minimumBuybackOutput(uint128) (line 2218) and markBuyback() (line 2235). The live implementation 0x23efc76d (verified as the current ERC-1967 implementation of 0x15bbcdb3 on chain 4663; a live eth_call of minimumBuybackOutput on the proxy reverts) has neither. The old vault, conversely, never calls markBuyback and pays the 2% hook fee on its own buyback.

  A rollback is therefore not a single upgradeAndCall: the administrator batch must also setLiquidityVault(oldVault) and oldVault.configure(keeper, maxBatch, true), and the new vault must be disabled and drained via recoverUnspentFees. Operational dependency, not a defect; consistent with the README's statement that rollback is a new forward transaction. Combine with the stale-oracle finding above when planning a rollback followed by a re-upgrade.

  State: allocation().vault == newVault, hook implementation rolled back to 0x23efc76dbb3f340732929d28f4244b3d1c703eb7.

  Input: keeper calls newVault.buyAndBurn(valid plan).

  Expected by an operator assuming a plain rollback: buyback executes.

  Actual: the staticcall hook.minimumBuybackOutput(p.amountIn) reverts (selector absent in the old implementation, as the live probe shows) and buyAndBurn reverts; oldVault.buyAndBurn also reverts with 'Fee destination changed' until setLiquidityVault(oldVault) is executed.

  whole reproduction

• 6.infoTrust assumptions: the administrator operator holds upgrade, fee, fee-destination, accrued-fee redirection and ETH recovery powers over both contracts (intended; documented, not a bypass)flat/MigrationFeeHookV2.sol:2810

          if (value >= DENOMINATOR) revert InvalidFee();

  Live state on chain 4663 (block 108,807,336): hook proxy owner = ClausAdministrator 0x979d58..., ERC-1967 admin = ProxyAdmin 0xf2eaa0... (UPGRADE_INTERFACE_VERSION 5.0.0) whose owner is the same administrator, administrator owner (founder) = 0xBb145c... (also the fee recipient), operator = 0x8aCA88..., managedTarget true for the proxy, the ProxyAdmin and the old vault.

  ClausAdministrator.execute lets the operator call any selector on managed targets except renounceOwnership and transferOwnership.

  Accepted consequences: (a) the operator can upgrade the hook to any implementation via ProxyAdmin.upgradeAndCall; (b) setFee accepts up to 999,999 pips (only value >= 1,000,000 reverts at line 2810), far beyond the published 2%; (c) setLiquidityShare, setLiquidityVault and setFeeRecipient redirect both future and already-accrued fees at the write moment (AccruedFeesRedirected; liquidityOwed is currently 9,765,744,775,603 wei and is what the activation batch moves to the new vault); (d) vault.recoverUnspentFees can send the vault's entire ETH balance to any address and configure can disable the keeper.

  Founder recovery is preserved: setOperator(0) revokes, renounce is blocked, transferOwnership is founder-only, and the new vault's constructor sets owner = administrator directly (no pending two-step). LP principal is untouched by every path: the hook only mints/burns its own ERC-6909 native claims (balance 9,765,744,775,603 wei live) and never modifies positions.

  No permission bypass was found: every state-changing entry point is onlyOwner+outsideSwap, keeper/owner-gated (buyAndBurn), manager-only (hook callbacks, unlockCallback reached only via the hook's own unlock), vault-only (markBuyback), or permissionless-but-harmless (claimLiquidityFees, claimTreasuryFees, receive). Merged from the permissions and flow specialists. Any tightening (cap feePips in code, founder-only setFee) is a policy decision.

  whole finding

  State: operator 0x8aCA88... is set and the proxy is a managed target (both true live).

  Input: operator calls administrator.execute([{target: hookProxy, data: setFee(999999)}]).

  Expected under the published 2% policy: rejected.

  Actual: accepted (only value >= DENOMINATOR reverts); the next non-exempt 1 ETH exact-input ETH->CLAUS swap pays 0.999999 ETH fee.

  Likewise administrator.execute([{target: newVault, data: recoverUnspentFees(anyAddress, balance)}]) succeeds once the founder has registered newVault via setTarget.

  Within the agreed trust model.

  whole reproduction

• 7.infoKeeper-supplied quotedTick/maxTickDrift is a self-referential guard; protection against a misbehaving keeper rests entirely on the oracle floor, which holdsflat/ClausBuybackVaultV2.sol:2215

          require(p.maxTickDrift <= 100 && uint256(drift) <= p.maxTickDrift, "Price moved");

  The keeper chooses quotedTick, so it can always pass quotedTick = current tick and maxTickDrift = 0, making the 'Price moved' check a no-op against the keeper itself.

  This was the v51 concern; in v52 it is remediated because line 2218 independently requires minBuyOutput >= hook.minimumBuybackOutput(amountIn), which the keeper cannot influence: 600 s time-weighted mean tick rounded up (meanTick lines 1700-1710), output rounded up (mulDivRoundingUp), fixed OUTPUT_FACTOR 995_000, warmup enforced (OracleNotReady before oldest+600), zero weight for same-timestamp swaps (record line 1684), 601 slots keep a full 600 s window under one write per second, non-monotonic time rejected.

  The specialist's ring-wrap and same-second spam test (test_ringWrapAndSameTimestampSpamDoNotDoS) passes on this code. Treasury payout is no longer coupled to buybacks (the vault never calls claimTreasuryFees; a rejecting recipient reverts only claimTreasuryFees and treasuryOwed is preserved). Reported so the drift check is not mistaken for a second line of defence.

  Keeper self-sandwich is bounded to below 0.5% of a batch of at most 0.5 ETH minus the vault's own impact and costs about 4% in hook fees, so it is unprofitable.

  whole finding

  State: oracle warm, spot tick 150000, TWAP tick 144152.

  Input: keeper calls buyAndBurn(Plan{quotedTick=150000, maxTickDrift=0, minBuyOutput=minimumBuybackOutput(amountIn), ...}).

  Expected if the drift check were a real guard: revert because spot is 5848 ticks above the reference.

  Actual: drift check passes (0 <= 0); the call then reverts only because the swap cannot deliver 99.5% of the TWAP-implied output (router V4TooLittleReceived).

  The floor, not the drift check, protects the vault.

• 8.infoFee split rounds the odd wei to treasury: the 'equal' 50/50 split deviates by at most 1 wei per swapflat/MigrationFeeHookV2.sol:2891

              a.liquidityOwed+=lp;a.treasuryOwed+=fee-lp;

  lp = fee * liquiditySharePips / 1e6 truncates and treasury receives fee - lp, so for every odd fee amount the treasury side gets one wei more than the buyback side. The total fee is conserved, the 2% rate (feePips 20_000, live value 0x4e20 verified) and the 500_000 share (live allocation verified) are unchanged from the baseline hook, and the deviation is bounded by 1 wei per swap. Informational.

  beforeSwap/afterSwap for a zeroForOne exact-input swap with amountSpecified = -51 (51 wei): fee = 5120000/1e6 = 1 wei; lp = 1500000/1e6 = 0; treasuryOwed += 1, liquidityOwed += 0.

  Expected under a strictly equal split: 0.5 wei each (not representable).

  Actual: 0 to buyback, 1 to treasury.

• 9.infoCoverage and dependency evidence: builds reproduced and live proxy/admin/vault state verified on chain 4663; router ABI variant, protocol-fee controller behaviour and token burn semantics remain assumflat/ClausBuybackVaultV2.sol:2146

      IClausRouter public constant ROUTER = IClausRouter(0x204FAca1764B154221e35c0d20aBb3c525710498);

  Entry files read in full: flat/MigrationFeeHookV2.sol (2977 lines: v4-core/OZ-upgradeable libraries, BuybackOracle library, MigrationFeeHookV2) and flat/ClausBuybackVaultV2.sol (2259 lines: v4-core/OZ libraries, forked IV4Router, ClausBuybackVaultV2), plus baseline/ClausAdministrator.sol, baseline/MigrationFeeHookOriginal.sol and baseline/ClausBuybackVault.sol for upgrade compatibility.

  Verified: both build/*.standard-input.json compile with solc 0.8.26 (viaIR, 200 runs, cancun, ipfs metadata) to runtime keccak 0xf168150e... and 0x0109bbdc... exactly matching build/manifest.json, the embedded sources are byte-identical to the flat files, and node build/verify-hashes.mjs passes.

  Storage: Settings/Allocation slots and layouts are unchanged from the baseline, ORACLE_SLOT is a new namespaced slot, EXEMPT_SLOT is transient only, no reinitializer is needed.

  Live (chain 4663, block 108,807,336, via the public RPC the task names): proxy implementation = 0x23efc76d (old), ERC-1967 admin = 0xf2eaa097 (ProxyAdmin 5.0.0, owner = administrator), proxy owner = administrator, administrator owner = 0xBb145c..., operator = 0x8aCA88..., managedTarget true for proxy, ProxyAdmin and old vault; old vault owner = administrator, enabled = true, keeper = 0xAc796F..., maxBatch 0.5 ETH, ETH balance 0, totalEthSpent 0.679 ETH and totalTokensBurned 1.165e24 (so the forked router encoding and action codes used identically by the new vault have executed live); hook feePips 20000, launched true, poolId 0x51c9a331..., allocation share 500000, vault = old vault, liquidityOwed 9,765,744,775,603 wei (matching the hook's ERC-6909 native claim balance), treasuryOwed 0; ORACLE_SLOT = 0; ArbSys at address(100) answers arbBlockNumber and arbBlockHash; CLAUS has 18 decimals and burn(uint256) is callable.

  Harness checks run against the exact flat sources (test/scratch/HookHarness.t.sol, VaultHarness.t.sol, OracleRollback.t.sol; forge 1.8.3, solc 0.8.26, via_ir): a swap seeds the oracle and initializeBuybackOracle then reverts; administrator seeding, a second seed reverting, OracleNotReady at 599 s and a correct floor (0.995 x 1.0001^tick, rounded up) at 600 s; markBuyback rejected for non-vault callers; the exempt zeroForOne exact-input swap pays no hook fee, a partial fill reverts PartialFill, a full fill accrues nothing and consumes the flag; a following swap pays 2% split exactly 50/50 into liquidityOwed/treasuryOwed with matching ERC-6909 claims; a oneForZero swap neither consumes nor benefits from the flag; one successful buyback per ArbSys block and a reverted buyback not consuming the block; the 601-slot ring with same-second spam keeps the mean inside the observed tick range.

  Remaining assumptions, to be checked as post-deployment gates: (1) the router at 0x204FAca1 keeps the forked ExactInputSingleParams layout and action codes on the activation block; (2) the protocol-fee controller 0x6d0009... does not set a protocol fee on this pool; (3) CLAUS burn reduces balance and totalSupply by exactly the amount (the vault's Burn mismatch check would otherwise block every buyback); (4) L2 timestamps never regress: BuybackOracle.record (line 1683) is on the hot path of every swap and would revert all swaps while block.timestamp < last observation (Arbitrum-style sequencers enforce non-decreasing timestamps, so this is a dependency, not a reachable defect); (5) a live dry-run of buyAndBurn on a fork was not performed here (no fork allowed).

  Activation gates: extcodehash(new implementation) == 0xf168150e..., extcodehash(newVault) == 0x0109bbdc..., newVault.owner() == administrator, administrator.managedTarget(newVault) == true, allocation().vault == newVault only after the batch, buybackOracleState() observations == 1 right after the batch and ready == true after 600 s, oldVault.enabled() == false. Merged from the math and flow specialists' coverage notes.

  whole finding

  Not a code defect.

  Each listed assumption is checked by: cast code on the router at the activation block and a staticcall of execute with the encoded plan on a fork; IProtocolFees.protocolFeeController()/pool protocolFee read; a forked buyAndBurn dry run at a block after the batch; and the timestamp property is enforced by the sequencer.

  Verified items above were read with eth_call/eth_getStorageAt on chain 4663.