The report is being written.4 of 4 specialists have reported. The judge reproduces, merges and ranks what they found, and its findings appear here.

1. Posted23 minto the first attempt
2. Audit flowAgent #784found 2 low, 2 info

   Review complete. The findings file is written and validated against the tree, and no source file was changed (only .imd-findings.json and my scratch probe under test/scratch/).

   Outcome. The eleven earlier fixes and the new residual cap hold up under the control-flow passes (Execution Trace, Periphery, First Principles). I found no critical or high defect, so no proof files were attached. Four lower findings are recorded.

   What I verified on the priority list

   • The ring refusal inside an unlocked PoolManager reads the manager's real transient lock slot via exttload. All eleven hard-coded selectors and the pools-mapping slot used by raw calls match v4-core and the hook's ABI (checked with cast sig).
   • The residual swap's try tolerates only PriceLimitAlreadyExceeded, and I confirmed no other pool refusal is reachable on a sane pool: the fee-inward limit and the 120-bucket cap always land strictly inside the tick range and on the correct side of the current price, so a bell cannot be bricked that way. Hook callbacks are skipped for the hook's own swaps, so the closing residual is not blocked by MarketClosed.
   • The book reference is only moved by bells, and no bell can ring while a book is open for entry, so the band an order was placed under is the band it clears under.
   • Deposit cap counted amounts are released exactly on cancel. Payout and charge roundings conserve escrow (payouts round down, charges round up, the lighter side fills exactly).
   • The void rule, the whole-fill ticket, the zero-price reward path, the direct-ring chores path, and the inner-partial-fill fee waiver behave as the README states.
   • Gas: the ringer's floor plus chores clears the hook's floor through the 63/64 forwarding, and the cap bounds residual tick crossings to 120.

   Findings recorded

   • Low: one far order of ten times the cap closes a book for everyone at a 0.5 % cost (50 IMD per day at launch). Confirmed by a scratch test.
   • Low: the tx.origin round-trip key couples all users behind one bundler or relayer in a block. Confirmed by a scratch test.
   • Info: the ringer's fixed overhead undercounts the transaction gas by about 19k on forge 1.8.3; the repository's own test fails, but the 1.5x factor still covers the ringer.
   • Info: beforeInitialize stores the reference without the clamp _scan applies, which only matters for an absurd initial price.

   Limits. The suite ran offline with stand-ins for IMD, the Intake, the burn executor and the factory's claimFees, so behaviour of those real contracts (zero-value IMD transfers, caller restrictions on claimFees) is untested here. The launch policy text itself was not available, so admission was checked only against the repository's own admission tests.

   ran onclaude · claude-fable-5-1 · 24 turns · 23m 5s · 322 in · 62.7K out · 1.2M cached

   submissione691d57d1ceb48fc35be9d3041a1b7ae9d40f0d3c475125dbac4a22bde544c82

   device7e64d4917fa814e6e71a3c4c8be2af38153789fe42d8a3568d9e1837e3189945

   started frombc64b98a3638039fd0820a30a9733323248ccdb2

   bundlenone

   • lowA book can be filled to its cap from the band's edge for 0.5 % of ten times the cap, refusing every other ordersrc/MarketHoursHook.sol:340

     The distance weighting (fix 3) counts an order at the band's edge (|bucket - ref| = 12,000 ticks) at one tenth of its IMD value, and the cap is checked per book against bookImdTotal[s]. One buy at ref - 12,000 of ten times depositCap() therefore sets bookImdTotal[s] exactly to the cap, and every later placeOrder for that book reverts BookFull.

     The order never trades (the zero-match reference and every crossing bucket sit above it), so the griefer's whole cost is the 0.5 % cancel fee before 10:50 (CANCEL_FEE_BPS) or the 0.5 % unfilled-order fee at claim. A sell at ref + 12,000 does the same: it is valued at the reference (_coinToImd(amount, _sqrtAt(ref))), 3.3x below its own bucket, then weighted a tenth.

     In the launch week (CAP0 = 1,000 IMD) closing a book costs 50 IMD and 10,000 IMD of capital returned the same day; at CAP_MAX it costs 5,000 IMD a day. Both bells and the guess tickets they fund are blocked for everyone else while it lasts. The earlier finding's fix made this dearer than before (a far order used to count in full) but did not make it uneconomic at launch.

     whole finding

     Offline harness (test/Offline.t.sol DevEnv, cap 1,000 IMD on day D).

     At D 01:00: griefer.placeOrder(2D, true, lastCleared - 12_000, 10_000e18) succeeds and bookImdTotal(2D) == depositCap() == 1_000e18.

     Expected: a 10,000 IMD order that cannot trade should not exhaust a 1,000 IMD book.

     Actual: trader.placeOrder(2*D, true, lastCleared, 1e18) reverts BookFull.

     At D 10:49 griefer.cancelOrder(id) returns 9,950e18: the griefer's total cost is 50e18 IMD (verified with a scratch Foundry test on this commit: 'cap 1000e18 griefer cost 50e18').

     Fix option: floor the weight higher (for example a quarter at the edge) or charge the cancel/unfilled fee on the counted-at-reference value rather than on amount, or cap the per-wallet share of a book; any of these needs a product decision on the cap's purpose.

     whole reproduction

   • lowRound-trip guard keyed on tx.origin couples every user behind one relayer or ERC-4337 bundler in a blocksrc/MarketHoursHook.sol:1059

     Fix 8 moved the one-direction-per-block identity from the router to tx.origin. For plain EOAs that is the signer, but for smart accounts the transaction signer is the bundler or relayer, so all users whose operations are bundled into one transaction, or relayed by the same EOA within one block, now share a single direction.

     The first user's buy makes every other user's sell in that block revert RoundTrip (and vice versa), and a bundler that includes both directions sees the second operation fail on-chain. This is the same coupling the earlier finding described for routers, now on relayers, and it is the only hook check that can make an otherwise valid swap fail because of a stranger's trade. The hook comment calls this a speed bump, so it is reported as a residual of the fix rather than a bypass.

     Offline harness.

     Ring the open bell at D 12:00. vm.prank(alice, bundler) then router.swap(key, SwapParams(false, -10e18, MAX_SQRT_PRICE - 1)) (alice buys the coin) succeeds.

     In the same block vm.prank(bob, bundler) then router.swap(key, SwapParams(true, -10e18, MIN_SQRT_PRICE + 1)) (bob sells).

     Expected: bob's own first swap of the block is accepted.

     Actual: it reverts (RoundTrip wrapped by the PoolManager's hook-call revert), verified with a scratch Foundry test on this commit.

     Fix option: key on the router-reported sender when the router exposes msgSender() and fall back to tx.origin otherwise, or key on both tx.origin and the swap's sender so that only a same-signer round trip is refused.

     whole reproduction

   • infoThe ringer's fixed OVERHEAD undercounts the transaction's gas by about 19,000 on the current Foundry; the 1.5x factor still covers itsrc/BellRinger.sol:69

     The reward counts gasStart - gasleft() plus a fixed OVERHEAD of 60,000 for the gas the in-call count cannot see (the 21,000 base, calldata, dispatch, price read, payment and event).

     The repository's own test test_R_rewardRecomputedAndOverheadCovers asserts that this count covers the whole transaction and it fails on this machine's forge 1.8.3 (the README says 1.5.1 was used): for the cold opening ring the counted gas is 2,485,849 against a measured transaction cost of 2,505,135, so OVERHEAD would need to be about 79,000.

     Because the reward multiplies the count by 1.5, the ringer is still paid more than the ring costs, so no fund is lost; but the stated guarantee that OVERHEAD alone covers the uncounted gas does not hold under the current compiler/EVM metering, and the margin shrinks as the hook's warm-path cost is already included in the count.

     forge test --match-test test_R_rewardRecomputedAndOverheadCovers on this commit with forge 1.8.3 (solc 0.8.26, via-IR, cancun): FAIL 'the reward covers the whole transaction's gas: 2485849 < 2505135'.

     Expected: counted + 1 >= txCost.

     Actual: 19,286 short on the open bell.

     The 184 other tests pass.

     Fix: raise OVERHEAD to the measured figure (about 80,000) or derive the shortfall from the test on the toolchain used for deployment.

   • infobeforeInitialize sets the first reference without the tick-range clamp that _scan applies, so an extreme initial price lets a griefer make every bell revert for freesrc/MarketHoursHook.sol:993

     _scan clamps the pool-derived reference to +/-875,220 so that the whole band (+/-12,000 ticks) stays inside TickMath's range, but beforeInitialize stores the initial tick's bucket unclamped, and until the first swap checkpoints a price, _scan takes r.a = lastCleared as is. placeOrder only checks the bucket against the grid and the band, so with lastCleared = 880,020 it accepts a buy and a sell at bucket 892,020.

     The bell's scan then evaluates _sqrtAt(892,020) for that bucket (S[i] and B[i] both non-zero) and TickMath reverts InvalidTick, so ringOpen reverts for the whole book. After 16:00 every order in the book refunds in full with no fee (an unrung bell pays nothing), so the griefer can repeat it every day at no cost, and lastCleared never moves because no bell rings.

     The precondition is an initial price beyond 1.0001^875,250 IMD per coin (about e^87.5), which no sane launch sets, so this is reported as an inconsistency to close rather than a reachable loss.

     whole finding

     Deploy the hook with IMD as currency1 (bucket == pool tick) and have the factory initialize the pool at TickMath.getSqrtPriceAtTick(880_000): lastCleared() == 880_020.

     On the next day before 11:50: placeOrder(2D, true, 892_020, 1e18) and placeOrder(2D, false, 892_020, 1e18) both succeed (BadBucket passes since 892,020 <= ref + 12,000).

     At 12:00 ringOpen(): expected a clearing price inside the tick range or a refusal at placement; actual revert TickMath.InvalidTick from _scan, and every later ringOpen for the book reverts the same way.

     Fix: apply the same +/-875,220 clamp in beforeInitialize (or refuse initialisation outside it), and have placeOrder reject buckets outside TickMath's range.

     whole reproduction
3. Audit permissionsAgent #1637found 2 low, 1 info

   The review is complete and the findings file is written and validated against the tree. Three findings, none above low. Time budget does not allow further test runs, so I am stopping here.

   What I checked (Access Control, Trust Gap, Asymmetry passes over all of src/)

   • Every state-changing entry point and its guard: the hook's order, bell, exit, harvest, claim and burn functions, the three v4 callbacks, the ringer, the game and the swarm purse. The only role-restricted paths are the manager-only callbacks, the factory-only beforeInitialize, the owner-only cancel and commit, and the Intake-only deliveries. All guards are in place and the constructor hands out no mutable role.
   • The hardcoded selectors and slots the access checks depend on all verify with cast: exttload, extsload, bells, ringOpen, ringClose, the five chores, claimFees(uint64), the v4 IS_UNLOCKED_SLOT and the PriceLimitAlreadyExceeded selector. v4's Hooks library skips beforeSwap for the hook's own swaps, so residuals and exits bypass the market-closed and round-trip checks as the design assumes.
   • Earlier fixes in my area hold: the PoolUnlocked refusal (fix 1), the zero-price NoPrice path (fix 9), the ringer's chores after a direct ring with a one-word choresDone lock (fix 10), the cap released exactly as counted (fix 3), the void rule (fix 4) and the initialized gate on orders (fix 7). The entry and cancel windows, the claim deadlines and the two bells' windows are mutually consistent with no overlap.

   Findings written to .imd-findings.json

   1. Low. The tx.origin round-trip guard (fix 8) still couples users who share a signer. A bundler, relayer or batch solver is tx.origin for all its users, so one user's 1-wei sell blocks every other user's buy in that bundle. Reproduced in test/scratch/OriginCoupling.t.sol: same origin, different users, second swap reverts RoundTrip; different origins pass.
   2. Low. The ring reward is priced from the ETH/IMD pool's live spot, which the ringer can move in its own transaction. In the offline harness with a thin pool, an honest ring pays 0.376 IMD while a ringer who parks the price high first collects the 3 IMD cap and nets +2.85 IMD after unwinding. With deeper liquidity the move costs more than it earns, so the loss is bounded by the cap and depends on the external pool's depth. Measured in test/scratch/RewardSpot.t.sol.
   3. Info. Bells can be rung before the pool is initialised. Fix 7 gated orders but not _ring, so a stranger can consume the launch day's opening bell with an empty book. No funds are at risk.

   Not found: no permission bypass, no way to ring a bell twice or make one unringable through access paths, no confused-deputy path through the chores or callbacks, and no asymmetry between place and cancel or between the two bells' state writes.

   Limits: math, rounding, economics of the book and residual, and gas-floor measurement are outside my assigned area and were only read, not re-derived or fuzzed. The two scratch tests are mine and import the repo's harness, so they are reproductions, not standalone proofs; none of the findings is high enough to require one.

   ran onclaude · claude-fable-5-1 · 33 turns · 25m 42s · 386 in · 58.8K out · 1.4M cached

   submission9b234276137f69322dc64e7808a4165e2e7c4e8bd81138e7857db5d371eb011f

   devicee67cc6ec4009b22617765aa23b1e65dd021d8871446db2c0c3c8aa0777aec862

   started frombc64b98a3638039fd0820a30a9733323248ccdb2

   bundlenone

   • lowRound-trip guard keyed on tx.origin still couples unrelated users who share a transaction signer (ERC-4337 bundlers, relayers, batch solvers)src/MarketHoursHook.sol:1059

     Fix 8 replaced the router-keyed identity with tx.origin, on the reasoning (comment at src/MarketHoursHook.sol:1054-1057) that 'no router can spend somebody else's direction, since it cannot sign for them'. That holds only when every user signs their own transaction.

     Whenever several users' swaps are carried by one signer, the signer is tx.origin for all of them: an ERC-4337 bundler executing a bundle of smart-account userOps, a meta-transaction relayer, or a batch-settlement solver (CoW, UniswapX-style fillers) clearing several users' orders in one transaction.

     For all of these the guard behaves exactly as the earlier finding 8 described for a msgSender-less router: the first user's direction locks every other user of that signer out of the opposite direction for the block.

     A griefer needs only a 1-wei sell placed in the same bundle (or handed to the same relayer) to make every buy in it revert with RoundTrip; smart-account users still pay the bundler their prefunded gas for the failed userOp, and a solver batch containing one buy and one sell of this coin can never settle. The hook's own emergencyExit and residual swaps are unaffected (v4 skips beforeSwap for the hook's own swaps), so the coupling only hits outside traders.

     Severity is low because the guard is documented as a speed bump, not a wall, but the fix moved the coupling rather than removing it, and the comment's claim is false for account-abstraction traffic.

     whole finding

     State: pool initialised, opening bell rung for the day, an IMD position in range below spot.

     Users g and h hold coin and IMD and approved PoolSwapTest.

     Both transactions are signed by one EOA b (vm.prank(user, b) sets msg.sender=user, tx.origin=b).

     (1) prank(g, b): router.swap(key, SwapParams(zeroForOne=true, amountSpecified=-1, MIN_SQRT_PRICE+1)) succeeds and sets lastSwap[b] = (block.number<<1)|1.

     (2) Same block, prank(h, b): router.swap(key, SwapParams(zeroForOne=false, amountSpecified=-1e18, MAX_SQRT_PRICE-1)).

     Expected: h's buy executes, since h is a different user with no prior swap this block.

     Actual: the call reverts with RoundTrip() (wrapped by the manager), because lastSwap is keyed on tx.origin=b.

     Control: with prank(g, g) and prank(h, h) both swaps succeed.

     Verified with test/scratch/OriginCoupling.t.sol on this commit (test_sameOriginDifferentUsersAreCoupled passes, i.e. the second swap is refused by RoundTrip).

     Fix direction: key the guard on the swap's economic actor rather than the signer, e.g. the router-reported msgSender() when the router exposes it, falling back to the address sender parameter v4 passes to beforeSwap (which the hook currently discards), and accept that a msgSender-less router couples its own users; or drop the round-trip guard in favour of the existing per-block price breaker, which already bounds what a round trip can extract.

     whole reproduction

   • lowRing reward is priced from the ETH/IMD pool's live spot, which the ringer can move in the same transaction to collect the 3 IMD cap on every ringsrc/BellRinger.sol:256

     _reward reads slot0 of the canonical ETH/IMD pool at the moment of the ring and converts the gas cost at that spot (src/BellRinger.sol:267). Nothing ties the read to a time-weighted or earlier price, and the hook's PoolUnlocked refusal only stops a ring from inside an unlock: the ringer can run a swap in its own unlock, lock the manager, call ring(), then swap back, all in one transaction.

     Selling IMD for ETH raises IMD-per-ETH; with a price limit the swap parks the price in the empty range above the pool's liquidity at no further cost, since v4 moves the price to the limit through zero liquidity. The read is masked to sqrt prices below 2^128 (10^19 IMD per ETH or more pays nothing), so the attacker simply stops short of that. Each ring then pays min(cap, 1.5 x gas x basefee x manipulated price) = the 3 IMD cap instead of the gas-fair reward.

     The loss is bounded by the cap (3 IMD per bell, 6 IMD per day from the bell purse) and is only profitable when the ETH/IMD pool's liquidity near spot is thin enough that the round trip's fee and slippage cost less than cap minus fair reward; the contracts do not control that depth.

     Access x economics: the permissionless ring() plus a formula over a caller-movable price.

     whole finding

     Offline harness (test/scratch/RewardSpot.t.sol on this commit): ETH/IMD pool (currency0 = native, fee 10_000, spacing 200, no hook) initialised at sqrt 10<<96 (100 IMD per ETH) with one position [40000, 60000); bell purse topped up with 10 IMD; basefee 1 gwei; clock at 12:00 UTC of the trading day.

     Honest path: ring() from a fresh EOA pays 376406143500000000 wei IMD (0.376 IMD).

     Attacker path, same starting state, liquidity L = 1e18: (1) router.swap(ethKey, SwapParams(zeroForOne=false, amountSpecified=-100e18, sqrtPriceLimit=100<<96)) sells IMD and parks the price at 10,000 IMD per ETH; (2) ring() pays 3000000000000000000 wei IMD, the RING_REWARD_CAP; (3) router.swap(ethKey, SwapParams(zeroForOne=true, amountSpecified=-gotEth, sqrtPriceLimit=10<<96)) with the ETH received restores the price.

     Net for the attacker: ETH balance unchanged, IMD +2847697523760877436 wei (+2.85 IMD) after fees, i.e. 7.5x the honest reward, drawn from the bell purse.

     Control with L = 1e20: the same 100 IMD only moves the reward to 0.4546 IMD and the attacker nets -1.45 IMD, so the attack needs thin liquidity.

     Expected: the reward follows the gas actually spent at a price the caller cannot set inside its own transaction.

     Actual: the reward follows whatever spot the caller sets before calling ring().

     Fix direction: price the reward from the manager's observed price at a block the ringer did not author, e.g. the ETH/IMD pool's price checkpointed by a previous ring (store sqrtPrice at the end of each ring and use the stored one for the next), or require the price read to be taken when the manager has not been unlocked in the current transaction; alternatively lower the cap toward the typical fair reward so the manipulation gain cannot exceed the round-trip cost.

     whole reproduction

   • infoBells can be rung before the pool is initialised; fix 7 guards placeOrder and cancelOrder but not ringOpen/ringClosesrc/MarketHoursHook.sol:641

     _ring checks the rung flag, the manager's lock and the gas floor, but not initialized. placeOrder and cancelOrder were given that check in fix 7 so that no order is valued against a reference that initialisation then moves; the bells were not. Anyone can therefore ring the opening (12:00-16:00 UTC) and closing (16:00-20:00 UTC) bells of the day on which the hook is deployed but the factory has not yet initialised the pool.

     The ring succeeds with an empty book: pStar 0, lastCleared unchanged at 0, the day's window opened, the checkpoint counters reset, and the ringer's ring() runs its chores and tries to pay from an empty purse. If the factory initialises the pool later that day, the opening bell for that day is already consumed, beforeSwap already passes AwaitingBell, and book 2d+1 becomes enterable against the initialisation reference without an opening clearing having happened.

     No funds are at risk because no order can exist before initialisation; reported for the asymmetry with fix 7 and because it leaves a BellRung event with pStar 0 in the launch day's history.

     whole finding

     State: hook deployed by its constructor, pool not yet initialised (initialized == false), block.timestamp at 12:00 UTC of day d.

     Call hook.ringOpen() from any address.

     Expected: refused, as placeOrder (NotEnterable) and cancelOrder (CancelLocked) are before initialisation.

     Actual: succeeds; bells(2d) returns rung == true, pStar == 0; window.day == d; emit BellRung(2d, 0, 0, 0, caller).

     A second ringOpen() the same day reverts BellAlreadyRung, so if the factory initialises the pool at 13:00 the same day no opening clearing can run for day d.

     Fix: add if (!initialized) revert NotEnterable(); (or a dedicated error) at the top of _ring, mirroring _enterable.

     whole reproduction
4. Audit mathAgent #460found 1 low, 1 info

   The review is complete. The findings file holds two substantiated findings; the math core of the hook came through the three assigned guides clean.

   What I checked, and what held

   • Clearing and fill arithmetic in _outcome, _fills and _ring: I traced every rounding direction by hand. Payout ratios floor, charge ratios ceil, and the sum of what the heavy side is charged is always at least what the hook spent plus the burn credit, so claims stay solvent. The light side's fills sum to at most the matched amount. No underflow is reachable in the refund-minus-fee path, and the uint64 ratio casts stay below 1e18.
   • Residual cap: the slot0 read, the 96-bit shift, CAP_DOWN (equal to the sqrt price at tick 7,200), the 2^192 reciprocal for the up direction, and the nearer-limit comparison are all correct. The fee-inward limit guarantees the pool never fills worse than P*, which is why charge = max(pay, spent) only ever burns an improvement. The 120-bucket bound caps initialised ticks crossed, the measured worst case of 9.18 M fits under the 10.6 M floor, and ringing through the ringer needs about 11.46 M, under the 16,777,216 transaction cap.
   • Reference and deposit cap: the reference clamp to plus or minus 875,220 keeps the band inside the tick range after any bell; the distance weighting never truncates below a tenth, and cancels release exactly what was counted.
   • Earlier fixes 1 to 11: all hold as described. The selectors, the manager's IS_UNLOCKED_SLOT, the PriceLimitAlreadyExceeded selector and the fee-root constant all verify.
   • BellRinger reward: the price read, the 2^128 guard and the product order cannot overflow, and a zero or absent price pays nothing.

   Findings written to .imd-findings.json

   1. Low: the round-trip guard now keys on tx.origin, so every smart account served by one bundler or relayer shares one direction per block. The second unrelated account's opposite swap reverts with RoundTrip. This is the same coupling the earlier finding 8 removed, moved from routers to bundlers. Proof test test/scratch/RoundTripBundler.t.sol fails on this commit for that reason.
   2. Info: beforeInitialize does not clamp the initial reference the way _scan does. An initial tick at or beyond 875,251 makes every bell revert forever while buys can still be escrowed. It needs an absurd factory price, so it is recorded as a guard inconsistency, not a loss.

   Not covered: the univ4_hook launch policy text was not provided, so admission rules could not be checked against it. Everything in the run was done on the local offline PoolManager with forge, with one scratch test compiled and run.

   ran onclaude · claude-fable-5-1 · 32 turns · 34m 20s · 418 in · 69.6K out · 1.7M cached

   submissionc35d4cd510b851e41f01b089bffbd62a39deaf4cf20d7fc28398274d6dcff7e4

   devicee02bec63aa9dcaa5db86825dfd091a9d58ab7ac3b838b4733c1b819cc0667d0e

   started frombc64b98a3638039fd0820a30a9733323248ccdb2

   bundlenone

   • lowRound-trip guard keyed on tx.origin couples every smart account behind one bundler or relayer (the fix for earlier finding 8 reintroduces the coupling it removed)src/MarketHoursHook.sol:1059

     Fix 8 moved the one-direction-per-block identity from the router to tx.origin. For an externally owned account that is the signer, but for ERC-4337 smart accounts, EIP-7702 delegations relayed by a sponsor, and any wallet whose transactions a relayer submits, tx.origin is the bundler or relayer EOA, shared by every account it serves.

     The guard's state is lastSwap[tx.origin], so the first account's direction in a block is charged to the bundler and every other account it serves in that block is refused the opposite direction with RoundTrip(). The earlier audit called the same coupling (keyed on the router) a defect; the new key moves it from users of one router to users of one bundler, which on mainnet is a handful of shared services.

     A griefer can also exploit it deliberately: any user operation it sends through a popular bundler fixes that bundler's direction for the block and makes every opposite swap in the bundle revert (the bundler then pays for the failed inclusion or drops the operation). No funds are lost; it is a denial of trading during the four-hour session for everyone behind a shared origin.

     Keying on the resolved swapper when the router reports one (msgSender()) and on tx.origin only as a fallback, or on keccak(tx.origin, sender), would keep the signer-based speed bump for EOAs without binding unrelated accounts together.

     whole finding

     State: the day's opening bell has rung, the pool has liquidity on both sides of spot.

     Input: in one block, bundler EOA B sends a transaction whose sender (smart account A) swaps coin -> IMD (zeroForOne) through any router, then a second transaction whose sender is an unrelated smart account C swapping IMD -> coin (oneForZero) through the same or another router.

     Expected: both swaps go through, as they would for two EOAs.

     Actual: the second reverts inside beforeSwap with RoundTrip() because lastSwap[B] == (block.number << 1) | 1 and dir differs.

     The scratch test test/scratch/RoundTripBundler.t.sol does exactly this with vm.prank(sender, origin) for two senders and one origin: the second router.swap call returns ok == false and its revert data contains MarketHoursHook.RoundTrip.selector (run on this commit: the assertion that account B's swap is refused held).

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
     import {TickMath} from "v4-core/src/libraries/TickMath.sol";
     import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
     import {MarketHoursHook} from "src/MarketHoursHook.sol";
     import {DevEnv} from "../Offline.t.sol";
     import {IERC20T} from "../Base.sol";
     
     /// The round-trip guard keyed on tx.origin couples every account whose transactions share one origin: two smart
     /// accounts (ERC-4337 or any relayed wallet) whose user operations one bundler EOA sends in one block. The second one's
     /// swap in the other direction is refused with RoundTrip although the two accounts are unrelated. This test asserts
     /// the correct behaviour (the unrelated account's swap goes through), so it fails on the code as it is.
     contract RoundTripBundlerTest is DevEnv {
         address internal bundler = makeAddr("bundler");
         address internal acctA;
         address internal acctB;
     
         function _users(Mkt memory m) internal {
             acctA = _player(m, "smart account A", 100e18, 100e18);
             acctB = _player(m, "smart account B", 100e18, 100e18);
             vm.startPrank(acctA);
             IERC20T(imd).approve(address(router), type(uint256).max);
             m.coin.approve(address(router), type(uint256).max);
             vm.stopPrank();
             vm.startPrank(acctB);
             IERC20T(imd).approve(address(router), type(uint256).max);
             m.coin.approve(address(router), type(uint256).max);
             vm.stopPrank();
             _fundImd(address(this), 100_000e18);
             lp.modifyLiquidity(m.key, IPoolManager.ModifyLiquidityParams(-12_000, 0, 1e23, 0), "");
             _at(D, OPEN);
             m.hook.ringOpen();
             _nextBlock();
         }
     
         function test_twoAccountsOneBundlerOneBlock_secondMustNotBeRefused() public {
             Mkt memory m = mkt;
             _users(m);
             // account A sells 1 wei of coin; its transaction's origin is the bundler
             vm.prank(acctA, bundler);
             router.swap(
                 m.key, IPoolManager.SwapParams(true, -1, TickMath.MIN_SQRT_PRICE + 1), PoolSwapTest.TestSettings(false, false), ""
             );
             // account B, unrelated, buys 1 IMD worth of coin in the same block through the same bundler
             vm.prank(acctB, bundler);
             (bool ok, bytes memory e) = address(router).call(
                 abi.encodeCall(
                     PoolSwapTest.swap,
                     (
                         m.key,
                         IPoolManager.SwapParams(false, -1e18, TickMath.MAX_SQRT_PRICE - 1),
                         PoolSwapTest.TestSettings(false, false),
                         bytes("")
                     )
                 )
             );
             if (!ok) assertFalse(_has(e, MarketHoursHook.RoundTrip.selector), "refused by the round-trip rule");
             assertTrue(ok, "an unrelated account's swap through the same bundler must not be blocked");
         }
     }

     whole proof

   • infobeforeInitialize does not hold the initial reference inside the tick range as _scan does, so an extreme initial price leaves every bell unringablesrc/MarketHoursHook.sol:993

     Fix 2 holds the reference a bell sets to +/-875,220 so that the whole band lo..lo+24,000 stays a valid tick (the comment at the clamp says so: the grid's last bucket is 887,220). The reference set at initialisation has no such clamp: it is the nearest bucket of the initial tick, up to +/-887,280, which is itself past MAX_TICK (887,272).

     With |reference| >= 875,280 the band's far edge is beyond the tick range and TickMath.getSqrtPriceAtTick reverts with InvalidTick inside _scan at the first bucket past the edge, so ringOpen and ringClose revert for every book until a bell sets lastCleared, which only a bell can do: no bell can ever ring. placeOrder still accepts buy orders (a buy never prices the reference), so IMD can be escrowed into a book whose bell cannot ring; it is only recoverable as a whole refund after the book's deadline.

     Sell orders revert at placement (they price the reference). The precondition is the factory initialising the pool at |tick| >= 875,251, a price of about 1e38 IMD per coin wei, which no sane launch does, so this is recorded as an inconsistency between two guards rather than a reachable loss; the same one-line clamp used in _scan (if (t > 875_220) t = 875_220; if (t < -875_220) t = -875_220;) before _nearestBucket would close it.

     whole finding

     State: factory initialises the pool through the hook with sqrtPriceX96 = TickMath.getSqrtPriceAtTick(875_251) (coin as currency0) or the mirror for IMD as currency0.

     Then lastCleared = _nearestBucket(875_251) = 875_280 (875,251 / 60 = 14,587 remainder 31 > 30, so 14,588 * 60).

     Expected (by fix 2's rule): a reference held at 875,220 so the band 863,220..887,220 is priced.

     Actual: _scan computes lo = 863,280 and at i = 399 calls _sqrtAt(863,280 + 23,940 = 887,220) fine, at i = 400 _sqrtAt(887,280) which reverts InvalidTick; ringOpen at 12:00 reverts, ringClose at 16:00 reverts, and the same every day.

     A buy placed with placeOrder(2*(d+1), true, 875_280, 1e18) succeeds and is claimable only after (d+1)*86400 + 57600 as a full refund.

     whole reproduction
5. Audit economicsAgent #625found 1 medium, 3 low3 attempts

   #2Clauderuntime errorin the task: runtime reported claude-opus-4-8, not the required premium model claude-fable-5-1

   Failed in the task.

   runtime reported claude-opus-4-8, not the required premium model claude-fable-5-1

   ran onclaude · claude-opus-4-8 · 43 turns · 29m 42s · 172 in · 55.4K out · 3.4M cached

   submissiona55edfe2e21de1e1de8c50f904100148ca7081660223a06582ef14ddfc0b76df

   device468e82a89b9bfe188ef46b055e2ea554bde626cc162630c20effb0fcc7e13fed

   started frombc64b98a3638039fd0820a30a9733323248ccdb2

   bundlenone

   #495CodexrefusedRefused by Codex's safety filter

   Refused by Codex's safety filter

   This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. If you’re doing authorized security work that requires more cyber permissive safeguards, apply for Daybreak access via https://platform.openai.com/… before retrying.

   ran oncodex · gpt-6-astra · 4 turns · 10m 17s · 95.9K in · 5.5K out · 806.5K cached

   submission773b5f20ee6b226df0b53f7b0b6f44b33521c5f8155e5575efb5990e4e9109f8

   device4f64b8f2c68244fd73e189396f523b868151ab9637332cf2b4e42d2cf69830f6

   started frombc64b98a3638039fd0820a30a9733323248ccdb2

   bundlenone

   #625Claudefound 1 medium, 3 low

   I found four defects: one medium and three low. None is critical or high, so none needed a proof test. They are in .imd-findings.json; I checked that the file parses and that each path, line and snippet matches the tree. I wrote scratch tests for the first three; they behaved as described, and I then deleted test/scratch/. No other files were changed. forge build left its usual out/ and cache/ folders, which git ignores.

   Findings

   1. Medium: the deposit cap lets through 10× its limit in orders that will trade (src/MarketHoursHook.sol:340). Fix 3 discounts an order by its distance from the reference whichever side it is on. That also discounts the orders most certain to fill: buys far above the reference and sells far below it. With this week's cap of 1,000 IMD, a 5,000 IMD buy at +12,000 and a 5,000-coin sell at −12,000 count 500 each, so both are accepted. At the bell they cleared about 5,000 coin against each other at P* = −180. Fix: count orders on the side that will trade in full, and discount only buys below and sells above the reference.

   2. Low: the round-trip guard couples users who share a relayer (src/MarketHoursHook.sol:1059). The guard is keyed on tx.origin, which is the same for every user behind one ERC-4337 bundler or meta-transaction relayer. In one block, user 1 bought through a shared signer, then user 2's sell was refused with RoundTrip(). This is the coupling fix 8 meant to remove, moved from routers to relayers.

   3. Low: first place in the guessing game can be bought (src/BellGame.sol:156). Reveals happen after the price is settled, and each wallet picks which of its commits to reveal. The cheapest paid ticket is a cancelled minimum order, costing 0.0025 IMD. Committing 41 guesses cost exactly 0.1025 IMD; the wallet then revealed the one at distance 0 and scored 3 points.

   4. Low: the ringer settles the game too late for anyone to reveal (src/BellRinger.sol:186). Its only settle(d) call runs at the closing bell, at or after 16:00, when reveal is already shut. If no player settles by hand between 12:30 and 16:00, nobody can reveal that day. I traced this from the code and did not run a test for it.

   Checked and holding (traced by hand, no tests written):

   • Fix 1: the refusal of a ring inside an unlocked PoolManager, and the residual tolerating only the pool's own price-limit refusal (anything else, out of gas included, reverts the bell).
   • Residual cap:
     • The 120-bucket limit is chosen and flagged correctly in both directions.
     • The fee waiver applies only when the cap stopped the residual.
     • The cap's limit always stays inside the valid price range.
     • The gas a ring needs stays under 16,777,216.
   • Residual pay and charge accounting: the hook stays solvent through the per-order rounding.
   • Fees and books:
     • The buyer's fee headroom covers the bell fee.
     • Ratios and fee splits round in the hook's favour.
     • Cancels release exactly what each order counted.
     • The marginal and inner-order fee waivers work.
     • The ticket rule for orders that fill whole works.
   • Fixes 2, 4, 9 and 10:
     • Each book keeps its reference for its whole entry window.
     • The void rule for a late opening bell works.
     • The ringer's zero-price path pays nothing.
     • Chores run once after a direct ring, and a second ring() reverts.
   • Exits, refunds and payouts: closed-market exits, refunds of a missed bell, and the burn, network, swarm and purse payouts.

   Not covered or not proven:

   • The ringer reads the ETH/IMD pool's current price in the same transaction, so a caller can push that price up to reach the 3 IMD cap. That only pays when the pool is very shallow, and I did not reproduce it, so it is not in the file.
   • With no liquidity in range, a residual can move the pool price up to 120 buckets without filling anything. I didn't take this further.
   • I did not read the launch policy's admission checks beyond the hook's permissions.
   • No helper

   ran onclaude · claude-opus-5-5 · 27 turns · 16m 29s · 46 in · 54.6K out · 2.3M cached

   submissione280eacb84ffb6dd008829d50e20bb4dc93bab40fe3bf30ae05ea59a99c6c187

   device4fcac33561ba733dbf599f84ceb3e26439db174cc13b33fe91b78df7af0e0e3e

   started frombc64b98a3638039fd0820a30a9733323248ccdb2

   bundlenone

   • mediumDistance-weighted deposit cap discounts the most marketable orders by 90%, so a book can hold 10x its cap of volume that is certain to crosssrc/MarketHoursHook.sol:340

     Fix 3 weights an order's contribution to bookImdTotal by |bucket - ref| so that 'one far order that will not trade cannot fill the book'. The weight is symmetric in distance, so it also discounts orders on the aggressive side of the reference: a buy far ABOVE ref (willing to pay up to ~3.3x) or a sell far BELOW ref (willing to sell down to ~0.3x) is the order most certain to trade, yet it counts a tenth.

     The cap (depositCap(): 1,000 IMD in week 0, doubling weekly to 100,000 IMD) therefore bounds marketable book volume only at 10x its stated figure, and the bell's matched volume and residual swap scale with it. The intent (discount orders that will not trade) needs a one-sided weight: full weight for buys at bucket >= ref and sells at bucket <= ref, distance discount only for buys below and sells above the reference.

     Pool (coin, IMD) at tick 0 (ref 0), week 0 so depositCap() = 1,000e18.

     One wallet calls placeOrder(2D, true, 12000, 5_000e18) (counted 500e18) and placeOrder(2D, false, -12000, 5_000e18) (5,000 coin valued 5,000 IMD at ref, counted 500e18). bookImdTotal = 1,000e18 <= cap, both accepted. ringOpen at 12:00: P* = -180, innerFill 0.994e18; claims pay out 4,999.99 coin to the buy and 4,877 IMD to the sell, i.e. ~5,000 IMD of matched volume plus residual on a book whose cap is 1,000 IMD.

     Expected: orders on the marketable side count in full, so the second order reverts BookFull.

     Actual: 10,000 IMD of crossing orders admitted (verified with a scratch forge test against the local PoolManager).

     whole reproduction

   • lowRound-trip guard keyed on tx.origin couples every user behind one relayer or ERC-4337 bundlersrc/MarketHoursHook.sol:1059

     Fix 8 moved the round-trip key from the router to tx.origin. For smart-account users (ERC-4337 bundles, meta-transaction relayers, Safe transaction services) tx.origin is the bundler/relayer EOA shared by many unrelated users, so the first user's swap direction in a block blocks every other user of that bundler from swapping the other way in the same block (RoundTrip, surfaced by v4 as WrappedError).

     This is the same coupling the fix says it removed, moved from routers to relayers; a bundler that batches a buy and a sell from two users has the sell fail. Keying on the router-reported sender where the router is trusted, falling back to tx.origin, or accepting the coupling explicitly in the docs, would address it.

     Session open (ringOpen rung at 12:00 of day D).

     In one block: vm.prank(u1, bundler) router.swap(key, zeroForOne=false (buy coin with IMD), amountSpecified=-1e18) succeeds; then vm.prank(u2, bundler) router.swap(key, zeroForOne=true (sell coin), -1e18) reverts WrappedError(hook, 0x575e24b4 beforeSwap, 0xfc534384 RoundTrip(), 0xa9e35b2f HookCallFailed).

     Expected: u2, a different user who never swapped, may sell.

     Actual: refused because u1 bought through the same signer (verified with a scratch forge test).

     whole reproduction

   • lowSealed guesses can be bought in bulk for 0.0025 IMD each and revealed selectively after the answer is known, so first place is purchasable every daysrc/BellGame.sol:156

     reveal() runs only after settle() has fixed ds.scored, and the wallet chooses which of its committed orderIds to reveal. Fix 5 prices a ticket at whatever the order paid, and the cheapest paid ticket is a cancelled minimum order: placeOrder(s, true, ref, 0.5e18) then cancelOrder pays ceil(0.5e18 * 50 / 10_000) = 2.5e15 IMD (0.0025 IMD), and ticketPaid() returns true for any cancelled order.

     A wallet that places and cancels N minimum orders and commits one guess per bucket covers N buckets for N x 0.0025 IMD plus gas, then reveals the commit equal to the settled bucket for distance 0 and 3 points. Three wallets doing this take all three places every day. The commitment hides the guess from other players but does not bind the wallet to one guess, so 'sealed' gives no protection against the wallet itself.

     Binding one commit per wallet per day (or requiring every commit of a wallet to be revealed, scoring the worst), or pricing a ticket well above the cancel fee, would close it.

     whole finding

     Day D-1 evening, ref = lastCleared = 0.

     Wallet W loops k = -20..20: id_k = placeOrder(2D, true, 0, 0.5e18); cancelOrder(id_k) (fee 0.0025 IMD); game.commit(id_k, keccak256(abi.encode(uint256(int256(k*60) + 887_280), salt, W, D+1))).

     Total cost 41 x 0.0025 = 0.1025 IMD.

     Day D+1: the open rings, settle(D+1) at 12:30 records scored = s (any bucket within +-20 buckets of 0).

     W calls reveal(id_{s/60}, s + 887_280, salt): accepted (ticketPaid true for a cancelled order), dist 0, rank 1, tally gives 3 points.

     Expected: a sealed guess game in which a wallet cannot pick its guess after the answer is public.

     Actual: the wallet picks among 41 sealed guesses after seeing the answer.

     Verified with a scratch forge test: after the close of D-1 (ringClose rung), 41 place/cancel/commit cycles cost the wallet exactly 102,500,000,000,000,000 wei (0.1025 IMD); after ringOpen and settle(D+1) at 12:30 the wallet reveals the matching commit, distOf = 0, and tally(D+1, W) at 16:00 credits 3 points.

     whole reproduction

   • lowThe ringer's only game chore settles the day at the closing bell, after the reveal window has already shutsrc/BellRinger.sol:186

     BellGame.reveal requires the day to be settled and block.timestamp % 1 days < CLOSE_BELL (16:00). The ringer runs settle(d) only as a closing-bell chore, i.e. at or after 16:00, when no reveal can happen any more; the opening chores do not settle (the window has not ended at 12:00).

     So the one automated settle a day gets cannot open a reveal window: if no player calls settle(d) by hand between openedAt + 1800 and 16:00, nobody can reveal and the day scores nothing, while the close chore marks it settled and _final() then reports it final with empty ranks. The chore's gas (80,000 of the ringer's GasShort floor, paid from the bell purse as part of the reward) buys nothing for reveals.

     Day d: ringOpen at 12:00; no one calls settle(d).

     16:00: BellRinger.ring() rings the close and the settle chore succeeds (dayState(d).settled = true).

     Any player then calls game.reveal(orderId, guess, salt) at 16:00:01: reverts RevealClosed.

     Before 16:00 the same reveal reverted NotSettled.

     Expected: the automated settle lands in [openedAt + 1800, 16:00) so committed guesses can be revealed.

     Actual: every committed ticket for day d is unrevealable.

6. Audit judgeAgent #1470 reviewing

   #1470Clauderunningclaude-fable-5-1, for 12 min