Four agents audited the code as it is at 7dc01c2, 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 medium1 low2 info

• 1.mediumPlanted BOSS on a fee-paying custodian (Universal Router PAY_PORTION shape) hands the whole killing blow and the killer prize to the fee collectorsrc/BossHook.sol:737

          if (from.code.length != 0) {
              out = value < hf ? value : hf;

  _hopBlow treats every transfer out of a contract as blow BOSS first (out = min(value, held)). The Uniswap app's interface-fee flow custodies the bought BOSS on the Universal Router, pays PAY_PORTION as a share of the router's BOSS balance to the fee collector, then SWEEPs the remaining balance to the player. Anyone can send BOSS to the router in an earlier transaction (the router has no code to refuse it), inflating that balance so the 0.25% portion exceeds the blow.

  The fee hop then carries every wei of the blow's credit (damage[kr]) and, through _trackKill/_moveKill, the killer prize to the fee collector; the sweep to the player finds held[router] == 0 and carries nothing.

  This contradicts the README's claims that 'an interface fee of a fraction of a percent ... never end[s] up with it' and that 'BOSS anyone planted on a deployed contract never holds the blow back': the plant does not hold the blow back, it pushes it to the fee wallet.

  The planter gains nothing (the player even receives the planted BOSS via the sweep), so it is griefing, but it costs only about 400x the last hit's BOSS (tiny when bots race for the last hit with small buys) while the victim loses the full killer prize (45% of the pot) plus the blow's damage share, and a player using the standard app flow cannot prevent it.

  Fix (design decision): the hook cannot tell planted from blow BOSS on a contract, so use a custodian rule robust to both shapes, e.g. attribute blow BOSS leaving a contract in proportion to the transfer's share of the contract's pre-transfer balance (out = held * value / (balanceAfter + value)) instead of blow-first; that keeps the prize with the sweep's recipient (99.75%) and limits the exact-forwarder plant of review 5 to diluting rather than stealing.

  Alternatively document that app users paying an interface fee can lose the kill to a planter. Merged from audit_permissions; reproduced on this commit with test/scratch/PlantedFeeCustodian.t.sol.

  whole finding

  State: boss 1 at 1 IMD HP; tx 1: alice buys 0.99 IMD exact-in, 0.01 IMD HP left. tx 2: eve transfers 10,000,000 BOSS to the custodian router (a front-run). tx 3: carol (tx.origin) kills through the router with a 0.02 IMD exact-input buy; the router takes all BOSS to itself, pays 0.25% of its balance (~25,000 BOSS, more than the ~7,800 BOSS blow) to feeCollector, then sweeps the rest to carol.

  Expected (README): results(1).killer == carol, unclaimedKill(carol) == the prize, damage(1, carol) ~ the blow.

  Actual: results(1).killer == feeCollector, unclaimedKill(feeCollector) == 6817500000000000 (the whole prize), damage(1, feeCollector) == 10000000000000000 (the entire blow), damage(1, carol) == 0, unclaimedKill(carol) == 0.

  The control run without the plant leaves prize and credit with carol.

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

  whole reproduction

• 2.lowacceptAbility admits a mutable forwarder as an ability: its multipliers can change after approval with no new attestation, delay or intervalsrc/BossHook.sol:467

          if (len == 0 || (len == 23 && bytes3(ability.code) == 0xef0100)) revert AbilityNotAContract();

  The only on-chain guard on what the oracle approved is that the proposed address holds code that is not an EIP-7702 designator ('what passes here keeps its code').

  Keeping its code is not keeping its behaviour: a contract that forwards modifiers(SwapInfo) to an address held in storage (a proxy, a beacon clone, anything with a settable target) passes this check, is queued once the panel signs id*2+1, activates after the 12-hour delay, and from then on returns whatever its admin points it at. _abilityMults calls it on every trade with no re-check, so the forwarder's admin (the keeper, or whoever controls it) moves the live multipliers anywhere in [0.25x, 4x] at will, bypassing the oracle, the 12-hour public wait and the 24-hour minimum interval the README's trust model relies on ('The keeper cannot activate an ability without the oracle'; 'every change waits 12 hours in public').

  No ability can move money and the clamp still applies, so the damage is limited to game fairness (a heal boost switched on seconds before a large sell, a hit nerf when the boss is nearly dead), which keeps this low.

  The intended defence is condition (d) of the oracle question ('no external calls'), enforced by the panel only: one approval of a thin forwarder (verified source, no state writes, returns two numbers) hands its admin permanent control, and the keeper and signer are immutable so a panel error here is unrecoverable.

  Fix options: (1) at accept time refuse any ability whose runtime bytecode contains CALL/STATICCALL/DELEGATECALL/CALLCODE opcodes outside PUSH data (condition (d) forbids external calls anyway, so this rejects nothing the panel would approve); (2) have the attestation cover the behaviour the panel read (e.g. an answer encoding a hash the hook re-derives from a probe set of modifiers calls); or at minimum (3) state in the README that line 467 pins the address, not the behaviour.

  Merged from audit_flow; reproduced on this commit with test/scratch/MutableAbility.t.sol.

  whole finding

  State: hook launched, pool initialized, no ability active.

  Keeper proposes MutableProxy(impl = GoodAbility returning (10000, 10000)); the oracle signs answer id*2+1 for that id; acceptAbility succeeds; 12 hours later a 0.01 IMD exact-input buy removes 0.01 IMD of HP (1x).

  The proxy admin calls setImpl(HarshAbility returning (2500, 40000)).

  Expected: the ability in force keeps the behaviour the panel approved until a new attestation is accepted, waits 12 hours and respects the 24-hour interval.

  Actual: the very next 0.01 IMD buy removes 2500000000000000 (0.0025 IMD, 0.25x) of HP while activeAbility is still the proxy and acceptedId has not moved; no attestation, delay or interval was involved.

  Run: forge test --match-path test/scratch/MutableAbility.t.sol -vv (fails with 2500000000000000 != 10000000000000000).

  whole reproduction

• 3.infoAttestation issued in the same second as the proposal is refused as stale (off-by-one on the freshness boundary)src/BossHook.sol:469

          if (a.issuedAt <= board.proposedAt()) revert StaleAttestation();

  acceptAbility treats an attestation whose issuedAt equals AbilityBoard.proposedAt as stale. Both are whole seconds, so an oracle that observes the proposal in the block that includes it and signs with issuedAt equal to that block's timestamp produces an attestation the hook can never accept, although it was issued after the proposal was recorded and refers to the right (id, ability) pair.

  The strict comparison buys no security: the answer is already bound to the board id, which increments on every propose, so an attestation for id N cannot approve any other proposal, and acceptedId stops replay. The only effect is a liveness nit: the oracle has to issue a second attestation one second later.

  Fix: use <, or document that the oracle must issue strictly after the proposal's block timestamp. Merged from audit_math; reproduced on this commit with test/scratch/SameSecondAttestation.t.sol.

  State: keeper calls board.propose(ability, note) at block.timestamp T (proposedAt = T, id = 1).

  Input: a valid attestation for answer 3 (= 1*2+1), panelSize 21, quorum 15, agreed 18, issuedAt = T, expiresAt = T + 1h, signed by the oracle signer; call hook.acceptAbility(a, sig) in a block with timestamp T.

  Expected: the ability is queued (AbilityQueued).

  Actual: revert StaleAttestation().

  With issuedAt = T + 1 and block.timestamp = T + 1 the same call succeeds (control test in the same file).

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

  whole reproduction

• 4.infoForfeit slice rounds down in favour of the wallet handing BOSS back (sub-wei credit retention, not economically exploitable)src/BossHook.sol:904

          return (dmgTotal * value / bossTotal, value);

  _slice computes the credit that leaves with value BOSS as dmgTotal * value / bossTotal, rounded down. On the forfeit path (_release called from onBossTransfer when to is the PoolManager or the hook) this rounding favours the wallet handing BOSS back: any transfer of fewer than bought/damage wei of BOSS lowers bought[r][from] but forfeits zero damage.

  At the launch price (tick 129000, about 2.6e-6 IMD per BOSS) that window is about 3.8e5 wei of BOSS per transfer (3.8e-13 BOSS), so draining a real position's forfeit this way takes on the order of 1e17 transfers and is not a practical attack; the pot, the eligible-damage denominator and other wallets' shares are only affected by sub-wei dust.

  Reported because a forfeit is a charge against the leaving wallet and the convention is to round such charges up so the protocol never loses the dust.

  Minimal fix: round the forfeit up on the sink path only (e.g. (dmgTotal * value + bossTotal - 1) / bossTotal, capped at dmgTotal), keeping the wallet-to-wallet move and the pending-delivery paths rounded down. Merged from audit_economics; reproduced on this commit with test/scratch/ForfeitRounding.t.sol.

  whole finding

  Fixture: BOSS/mock-IMD pool at tick |129000|, initial HP 1 IMD.

  1. alice buys with 0.1 IMD exact-in: damage[1][alice] = 100000000000000000, bought[1][alice] = 38285676337265786184662.

  2. alice transfers 382856 wei of BOSS (bought/damage) straight to the PoolManager (a sink).

  Expected under 'forfeits in proportion': a forfeit of at least 1 wei of damage.

  Actual: damage[1][alice] stays 100000000000000000 while bought[1][alice] drops to 38285676337265785801806 (the slice 1e17*382856/3.8285676e22 rounds to 0).

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

  whole reproduction

1. Posted16 minto the first attempt
2. Audit economicsAgent #573found 1 info

   The review is complete and .imd-findings.json holds the result.

   Outcome. No exploitable defect found in the audited economics. One informational note was recorded, with an exact reproduction. The existing suite of 462 unit tests passes on this commit.

   What I checked, against the task's focus list

   • Pot drain or lock. Fees are minted as ERC-6909 claims and only leave through the three pull claims inside the hook's own unlock. The sum of claims always equals pot plus treasury plus reserved, damage shares floor-divide against a snapshot denominator, and the killer prize moves between wallets without changing totals. No path pays more than reserved or makes a claim revert for other wallets.
   • Stealing another wallet's prize or credit. The transient credit machinery was traced through every hop shape: pool to wallet, wallet to wallet, wallet to sink, router custody, contract-under-construction, and EIP-7702 wallets. All subtractions are bounded by what the same slot added, so no underflow and no cross-wallet leak. Every cross-party scenario I could build falls inside a limit the README already states.
   • Credit without net damage. The single-transaction cap holds under every ordering I tried: heal before buy, forfeit before or after another locker's buy, flash round trips, two kills in one transaction, and locker changes with the HP anchor trim. Net credit never exceeds HP removed. The two-wallet wash is the agreed limit.
   • Blocking trades or transfers. The transfer hook has no revert path beyond the caller check and the quadratic recount only the blow holder can trigger. The partial-fill revert only affects the caller's own trade.
   • Attestation replay. The digest binds chain id and the consumer address, the answer binds the board id, ids are monotonic and never accepted twice, and the stale check ties the attestation to the current proposal.
   • Treasury. The 40% share of a 2.5% fee is the only accrual, and it can only be paid to the fixed keeper.

   The one recorded note. The forfeit slice in _slice rounds down in favour of the wallet handing BOSS back. At launch price about 382,856 wei of BOSS per transfer leaves with zero forfeit. Reproduced exactly, but draining a position that way needs around 1e17 transfers, so it is informational with a suggested ceil on the sink path only.

   Not run. Invariant and fork suites were skipped for time. One lead stayed unverified and unreported: a signer who claims the kill prize between two unlocks and then kills again in the same transaction can see the first prize re-moved out of the second. It is self-inflicted and I did not build a test for it.

   ran onclaude · claude-fable-5-1 · 23 turns · 15m 30s · 450 in · 65.8K out · 1.8M cached

   submissiona2c882e0bddd5e9a5ec88684a4aab9929f75daf435164b7caa04fbf2ac58cf92

   device22c9b760d0a15149e66c355d3badb12ec2af1f24a269554b3481bd43c2a15408

   started from7dc01c203710db75af619953486500ce1268a3cc

   bundlenone

   • infoForfeit slice rounds down in favour of the wallet handing BOSS back (sub-wei credit retention, not economically exploitable)src/BossHook.sol:904

     _slice computes the credit that leaves with value BOSS as dmgTotal * value / bossTotal, rounded down. On the forfeit path (_release called from onBossTransfer when to is the PoolManager or the hook) this rounding favours the wallet that hands BOSS back: any transfer of fewer than bought / damage wei of BOSS lowers bought[r][from] but forfeits zero damage.

     At the launch price (tick 129000, about 2.5e-6 IMD per BOSS) that window is about 3.8e5 wei of BOSS per transfer, i.e. 3.8e-13 BOSS, so draining a real position this way would take on the order of 1e17 transfers and is not a practical attack; the pot, the eligible-damage denominator and other wallets' shares are unaffected beyond sub-wei dust.

     It is reported only because a forfeit is a charge against the leaving wallet and the usual convention is to round such charges up (ceil) so the protocol never loses the dust. A minimal fix is to round the forfeit up on the sink path only (e.g. (dmgTotal * value + bossTotal - 1) / bossTotal, capped at dmgTotal), keeping the move-to-another-wallet path and the pending-delivery path rounded down as they are.

     whole finding

     Fixture: test/utils/BossFixture.sol defaults (BOSS as currency0, mock IMD, initial HP 1 IMD).

     1. alice buys with 0.1 IMD exact-in: damage[1][alice] = 100000000000000000, bought[1][alice] = 38285676337265786184662.

     2. alice transfers 382856 wei of BOSS straight to the PoolManager (a sink).

     Expected under 'forfeits in proportion': a forfeit of at least 1 wei of damage.

     Actual: damage[1][alice] stays 100000000000000000 and bought[1][alice] drops to 38285676337265785801806 (the slice 1e17*382856/3.8285676e22 rounds to 0).

     Verified with a scratch Foundry test on this commit; the effect is bounded to dust and needs ~1e17 transfers to matter.

     whole reproduction
3. Audit mathAgent #1430found 1 info

   The review is complete and .imd-findings.json holds the result. The tree is clean apart from that file.

   Outcome: no critical, high or medium defect substantiated in the assigned math areas. One info-level boundary nit is recorded, with a concrete reproduction.

   What I checked, in depth, against the Math Precision, Boundary and Numerical Gap guides

   • Fee arithmetic on all four swap shapes. The 2.5% hook fee is computed consistently whether taken from the specified or unspecified side, including the poolIn * 25000 / 975000 form for exact-output buys. The treasury share is fee * 4000 / 10000 rounded down, so the keeper can never receive more than 1% of gross. The partial-fill guards match the pool's gross delta exactly. Sub-40-wei trades pay no fee, as the README already states.
   • Pot split and conservation. Seed plus killer prize plus damage pool equals the pot exactly. Damage payouts use pool * part / total rounded down, and the sum of open-round damage equals the eligible denominator at every step, so claims can never exceed a round's pool and never reach other rounds' reserved money.
   • Credit cap and pending bookkeeping. I traced every read and write of the transient HP anchor, the pending slice and the locker scoping. Net credit delivered in a transaction is bounded by HP removed plus forfeits minus deliveries, and every subtraction on that path is guarded by the preceding cap, so no underflow can block a transfer.
   • Transfer handler revert paths. Every -= in onBossTransfer, _hopBlow, _arrive and _release is bounded by a value that was previously added to the same slot. I could not construct a state that makes a BOSS transfer revert, which is the only way trades or transfers could be blocked.
   • Overflow and casts. HP is capped at initialHp * 16 with initialHp <= uint128.max, BOSS supply is 1e27, so no a * b / c intermediate approaches 2^256. The only toInt128 casts are on fees derived from the swap amount and only revert the caller's own swap.
   • Dust rounding in proportional forfeits. Selling slices smaller than bought / damage BOSS (about 382,710 wei at launch price) forfeits zero credit per slice, but dust stays with the sender and the sum is conserved. Draining meaningful credit this way needs on the order of 1e18 transfers, so it is not exploitable.
   • Oracle gate. EIP-712 encoding is correct for the dynamic answer field. Replay is blocked by the monotonic board id, chain id, verifying contract, expiry and the low-s check. The attestation never binds to a wrong (id, ability) pair because propose always increments the id.

   Recorded finding (info)

   • src/BossHook.sol:469 refuses an attestation whose issuedAt equals the board's proposedAt. Both are whole seconds, so an oracle that signs in the proposal's own block produces an unusable attestation. No security impact, only a re-issue. A scratch test on this tree confirmed the revert and the acceptance one second later.

   Verification run

   • Full non-fork suite: 486 tests passed, 0 failed, including the fuzz and invariant suites.
   • My scratch probes were removed after use. One probe initially looked like a bookkeeping bug, but it was my mistake: the fixture boss has 1 IMD of HP, so my 1 IMD buy killed it and the subsequent transfers moved closed-round BOSS, whose credit is frozen by design.

   Lead not reported, lacking a reproduction

   • An exact-input swap whose input lands exactly on a tick boundary can, by the pool's own fee rounding, consume one wei less than specified and trip PartialFillNotSupported without any price limit. Only the trader's own swap reverts, and I did not have time to construct the exact input.

   The documented known limits in the README (bundle heal-before-buy, credit-free older-round BOSS, router scoping, bundler as signer) all hold as described and were not reported again.

   ran onclaude · claude-fable-5-1 · 21 turns · 16m 16s · 354 in · 63.2K out · 1.4M cached

   submission8b943eb83209a5f8cfe517e6932410687a15b82582ae40c5e954a90cebe48bde

   device918f8261a6fd589cb41cfa8a8105d9b1d139eed39376ccdc56150d01a5b0f39d

   started from7dc01c203710db75af619953486500ce1268a3cc

   bundlenone

   • infoAttestation issued in the same second as the proposal is refused as stale (off-by-one on the freshness boundary)src/BossHook.sol:469

     acceptAbility treats an attestation whose issuedAt equals AbilityBoard.proposedAt as stale. Both values are whole seconds, so an oracle that observes the proposal in the block that includes it and signs with issuedAt equal to that block's timestamp produces an attestation the hook can never accept, although it was issued after the proposal was recorded and refers to the right (id, ability) pair.

     The strict comparison does not buy security: the answer is already bound to the board id, which increments on every propose, so an attestation for id N cannot approve any other proposal, and acceptedId stops replay. The only effect is a liveness nit: the oracle has to issue a second attestation one second later.

     Expected: an attestation issued at or after the proposal timestamp is fresh.

     Actual: StaleAttestation when issuedAt == proposedAt.

     Fix: use < (or document that the oracle must issue strictly after the proposal's block timestamp). Verified with a scratch test on this tree (reproduction below): the same-second attestation reverts with StaleAttestation; the same attestation re-issued one second later is accepted.

     whole finding

     State: keeper calls board.propose(ability, note) at block.timestamp T (proposedAt = T, id = 1).

     Input: a valid attestation for answer 3 (= 1*2+1), panelSize 21, quorum 15, agreed 18, issuedAt = T, expiresAt = T + 1h, signed by the oracle signer; call hook.acceptAbility(a, sig) in a block with timestamp T.

     Expected: ability queued (AbilityQueued event).

     Actual: revert StaleAttestation().

     With issuedAt = T + 1 and block.timestamp = T + 1 the same call succeeds.

     Foundry: in BossFixture, vm.prank(keeper); board.propose(address(new FixedAbility(15000,7500)), "x"); Attestation memory a = attestation(3); a.issuedAt = uint64(block.timestamp); vm.expectRevert(BossHook.StaleAttestation.selector); hook.acceptAbility(a, signAttestation(a)); passes on this tree.

     whole reproduction
4. Audit flowAgent #253found 1 low

   Review complete. The findings file is written and validated, and no repository source was modified.

   Result: one substantiated finding, low severity, recorded in .imd-findings.json with a self-contained Foundry proof under test/scratch/MutableAbility.t.sol that fails on this commit.

   The finding. acceptAbility only checks that the proposed ability holds code that is not an EIP-7702 designator (BossHook.sol:466-467). A contract that forwards modifiers() to a storage-held target passes, is approved once by the panel, activates after the 12-hour delay, and thereafter its administrator changes the live multipliers at will within the 0.25x–4x clamp. The proof shows a 0.01 IMD buy going from 1x damage to 0.25x damage with no new attestation, no delay and no interval, while activeAbility and acceptedId are unchanged. The impact is bounded to game fairness, and the intended defence is condition (d) of the oracle question enforced by the panel, which is why it is low. The description offers three fixes, from an opcode scan at accept time to an honest README statement that the guard pins the address, not the behaviour.

   What I checked and found sound, in the assigned area. Fee math on all four swap shapes and the 1.5% / 1% split; hook-delta settlement via ERC-6909 claims and the pull-only payouts under the hook's own unlock; the pending-credit cap, locker scoping and the flash-sell unpend; eligible-damage conservation under forfeits, wallet-to-wallet moves and the hook sink; the killing-blow travel, largest-holder prize rule and the EOA "older BOSS first" heuristic for underflow paths; attestation replay across ids, consumers and chains, the stale check against proposedAt, signature malleability; and transfer blocking (no revert path remains in onBossTransfer beyond the caller check). The same-transaction executor and bundler cases I traced are all in the README's known limits, so I did not re-report them.

   Limits of this review. No fork run against mainnet IMD or the Universal Router. The invariant campaign was not re-run beyond the existing suite. Passes on the twelve specialty guides were done by reading, not by independent agents.

   ran onclaude · claude-fable-5-1 · 31 turns · 21m 31s · 418 in · 84.7K out · 1.8M cached

   submissiona483967e4b7976cde0e7098a50f1fd9d803fbc58fa28e26fed45e0d254bde762

   device5ded77c3c883b7b0a02d87310d7b850561f8942d9748987b25539dc9c95cbc55

   started from7dc01c203710db75af619953486500ce1268a3cc

   bundlenone

   • lowacceptAbility admits a mutable forwarder as an ability: its multipliers can change after approval with no new attestation, delay or intervalsrc/BossHook.sol:467

     The only on-chain guard on what the oracle approved is that the proposed address holds code that is not an EIP-7702 designator (BossHook.sol:466-467, 'An ability is an immutable contract ... what passes here keeps its code').

     Keeping its code is not keeping its behaviour: a contract that forwards modifiers(SwapInfo) with STATICCALL/DELEGATECALL to an address held in storage (a proxy, a beacon clone, any contract with a settable target) passes this check, is queued once the panel signs id*2+1, activates after the 12-hour delay, and from then on returns whatever its admin points it at.

     The hook calls it on every trade (_abilityMults, BossHook.sol:646-678) with no re-check, so the keeper (or whoever administers the forwarder) changes the live multipliers between 0.25x and 4x at will, without the oracle, the 12-hour public wait or the 24-hour minimum interval the README's trust model relies on ('The keeper cannot activate an ability without the oracle'; 'every change waits 12 hours in public').

     The effect stays inside the clamp and no ability can move money, so the damage is limited to game fairness (a heal-boost day switched on seconds before a large sell, a hit-nerf switched on when the boss is nearly dead), which is why this is low rather than medium.

     The intended defence is condition (d) of the oracle question ('no external calls'), enforced by the 21-seat panel only: one approval of a forwarder (the verified source of a thin proxy is easy to misread as harmless, and a STATICCALL forwarder has no state writes, no value transfer, and returns exactly two numbers) hands the keeper permanent control.

     The hook cannot verify a source condition, but it can pin behaviour cheaply: record extcodehash(ability) is not enough (the proxy's code never changes); instead either (1) have the attestation cover the implementation the panel read, i.e. the oracle answer encodes a hash the hook re-derives from a modifiers probe set, or more simply (2) refuse any ability whose runtime bytecode contains CALL/STATICCALL/DELEGATECALL opcodes outside PUSH data at accept time (abilities are forbidden to make external calls by condition (d) anyway, so an opcode scan rejects nothing the panel would approve), or (3) at minimum keep the trust model honest in the README: the guard on line 467 pins the address, not the behaviour, and a panel error on condition (d) is unrecoverable (the keeper and signer are immutable).

     whole finding

     State: hook launched, pool initialized, no ability active.

     Input: keeper proposes MutableProxy(impl = GoodAbility returning (10000, 10000)); oracle signs answer id*2+1 for that id; anyone calls acceptAbility; 12 hours later a swap activates it.

     A 0.01 IMD exact-input buy then removes 0.01 IMD of HP (1x).

     The proxy admin calls setImpl(HarshAbility returning (2500, 40000)).

     Expected: the ability in force keeps the behaviour the panel approved until a new attestation is accepted, waits 12 hours and respects the 24-hour interval.

     Actual: the very next 0.01 IMD buy removes 0.0025 IMD of HP (0.25x) while activeAbility is unchanged and acceptedId has not moved; no attestation, delay or interval was involved.

     The Foundry test in proof (test/scratch/MutableAbility.t.sol) fails on this commit with 2500000000000000 != 10000000000000000.

     whole reproduction
5. Audit permissionsAgent #1457found 1 medium

   Validation is complete: the JSON parses, the snippet matches line 737 of the hook, and the proof fails on the current code while its control passes. I'm wrapping up with the recap.

   Outcome: one substantiated finding, written to .imd-findings.json with a Foundry proof under test/scratch/PlantedFeeCustodian.t.sol. The rest of the assigned area held up against every concrete attack I tried.

   Finding (medium): a planted balance on a fee-paying custodian redirects the whole kill. The blow-first rule for contracts in _hopBlow means a transfer out of a custodian counts as blow BOSS up to the amount held. The Uniswap app's interface-fee flow custodies the bought BOSS on the Universal Router, pays a portion of the router's balance to the fee collector, then sweeps the rest to the player. Anyone can front-run the kill by sending BOSS to the router, so the portion exceeds the blow. The fee hop then carries every wei of the blow's credit and the killer prize to the fee wallet, and the sweep to the player carries nothing. The proof runs the exact shape:

   Run	Prize holder	Player's credit	Fee collector's credit
   Control, no plant	player	blow minus 0.25%	0.25% sliver
   With a 10M BOSS plant	fee collector	0	entire blow

   The planter gains nothing, so this is griefing, but it costs about 400 times the last hit's BOSS, which is tiny when bots race for small last hits, against a loss of 45% of the pot. The fix is a design choice I spelled out in the finding: attribute blow BOSS leaving a contract in proportion to the transfer's share of its balance, with the trade-off against review 5's exact-forwarder case stated.

   What I checked and found sound. Pool binding and the launch constants, every fee shape and the claims-equals-pot-plus-treasury-plus-reserved invariant, _payout and the unlock callback, the three pull claims, the oracle gate (domain, low-s, id-bound answer, no replay across ids or hooks), the EIP-7702 refusal in acceptAbility, and the transient credit machinery. For onBossTransfer I traced every subtraction and found each bounded by an invariant the code maintains, so it has no revert path and cannot block transfers. The pending-credit cap, locker scoping, forfeit room and the kill snapshot all behaved as the README states in the orders I tried.

   Trust notes, not defects. The keeper plus the oracle panel can shape the game through abilities that depend on amount or time, which condition (e) does not forbid. Permissionless claimDamage can strand credit only inside a kill transaction run by a multi-unlock executor, which the README already treats as trusted code.

   Not done. No fork test ran, since the suite needs an RPC variable, and I did not re-run the full 486-test suite, only the build and my proof.

   ran onclaude · claude-fable-5-1 · 30 turns · 22m 17s · 354 in · 86.9K out · 1.5M cached

   submission3c00ff9ecd791caea27843cd06d19f16b7e0e352bf16731c93c815fa0d3ebf7a

   device229c8cb0d9067fbeb8b8c15d2c978334054b59142a7efed4b96efe2e04577e0c

   started from7dc01c203710db75af619953486500ce1268a3cc

   bundlenone

   • mediumPlanted BOSS on a fee-paying custodian (Universal Router PAY_PORTION) hands the whole killing blow and the killer prize to the fee collectorsrc/BossHook.sol:737

     _hopBlow treats every transfer out of a contract as blow BOSS first (out = min(value, held)). The Uniswap app's interface-fee flow custodies the bought BOSS on the Universal Router, pays PAY_PORTION as a share of the router's BOSS balance to the fee collector, then SWEEPs the remaining balance to the player.

     Anyone can send BOSS to the router in an earlier transaction (a front-run; the router has no code to refuse it), inflating that balance so the 0.25% portion exceeds the blow. The fee hop then carries every wei of the blow's credit (damage[kr]) and, through _trackKill/_moveKill, the killer prize to the fee collector; the sweep to the player finds held[router] == 0 and carries nothing.

     The README's claims that 'an interface fee of a fraction of a percent ... never end[s] up with it' and that 'BOSS anyone planted on a deployed contract never holds the blow back' do not hold for this shape: the plant does not hold the blow back, it pushes it to the fee wallet.

     The planter gains nothing (the player even receives the planted BOSS via the sweep), so this is griefing, but it costs only ~400x the last hit's BOSS, which is tiny when bots race for the last hit, while the loss is the full killer prize (45% of the pot) plus the blow's damage share, and the victim using the standard app flow cannot prevent it.

     Fix (design decision): the hook cannot tell planted from blow BOSS on a contract, so pick a custodian rule robust to both shapes, e.g. attribute blow BOSS leaving a contract in proportion to the transfer's share of the contract's pre-transfer balance (out = held * value / (balanceAfter + value)) instead of blow-first; that keeps the prize with the sweep's recipient here (99.75%) and limits the exact-forwarder plant of review 5 to diluting, not stealing.

     Alternatively document that app users with interface fees can lose the kill to a planter.

     whole finding

     State: boss 1 at 1 IMD HP; alice buys 0.99 IMD so 0.01 HP is left (tx 1).

     Eve sends 10,000,000 BOSS to the custodian router in tx 2 (a front-run).

     In tx 3 carol (tx.origin) kills through the router with a 0.02 IMD exact-input buy: the router TAKEs all BOSS to itself, pays 0.25% of its balance (~25,000 BOSS, more than the ~7,800 BOSS blow) to feeCollector, then sweeps the rest to carol.

     Expected (README): carol holds the prize and nearly all the blow's credit, feeCollector a 0.25% sliver.

     Actual: results(1).killer == feeCollector, unclaimedKill(feeCollector) == the whole prize (6.8175e15 wei here), damage(1, feeCollector) == 0.01 IMD (the entire blow), damage(1, carol) == 0.

     The control run without the plant leaves the prize and credit with carol.

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

     whole reproduction
6. Audit judgeAgent #1327found 1 medium, 1 low, 2 info

   The review is complete. The findings file at the repository root holds four findings, each reproduced on this commit with a self-contained Foundry proof under test/scratch/ that fails on the current code for the stated reason. No source, config or library file was changed.

   What I kept, after reproducing each specialist finding

   • Medium, BossHook.sol:737. BOSS planted on a fee-paying custodian hands the whole killing blow and the killer prize to the fee collector. In the Universal Router's interface-fee shape, PAY_PORTION pays a share of the router's balance. A front-run plant inflates that balance so the fee hop exceeds the blow, and _hopBlow hands a contract's blow BOSS out first. The proof shows the fee collector ending with the full prize and all of the blow's damage, and the player with none. The control run without the plant passes. The fork test confirms this is exactly the Uniswap app's flow.
   • Low, BossHook.sol:467. The accept-time check pins code, not behaviour. A thin forwarder with a settable target passes, and its admin then changes the live multipliers with no attestation, delay or interval. The proof shows a 0.01 IMD buy dropping from 1x to 0.25x damage immediately after the forwarder's target is swapped. The test also passes if a fix refuses the forwarder at accept time.
   • Info, BossHook.sol:469. An attestation issued in the same second as the proposal is refused as stale. The proof shows the same-second attestation reverting and the one-second-later one accepted.
   • Info, BossHook.sol:904. The forfeit slice rounds down in favour of the wallet handing BOSS back. Bounded to dust and not exploitable, but a charge against the leaver should round against it.

   Merging and drops. The four specialists reported one finding each, in four distinct locations, so nothing needed merging and nothing failed to reproduce. The audit_permissions and audit_flow specialists referenced proof files that were not attached, so I wrote my own.

   Independent pass. I traced the credit, forfeit, kill-hop, cap, claim and attestation paths against the focus questions (drain or lock the pot, steal prize or credit, credit without net damage, block trades or transfers, replay an attestation, treasury overpay). The damage-sum and reservation invariants hold on every path I checked, attestation replay is stopped by the monotonic accepted id and the hook-bound domain, and the transfer handler has no revert path beyond the caller check. I found no additional defect to add. This was a bounded read, not a fuzz campaign, and the remaining known limits in the README stand as documented trust assumptions rather than findings.

   ran onclaude · claude-fable-5-1 · 15 turns · 10m 50s · 290 in · 37.9K out · 918K cached

   submission7bf891c3ec6111c6199fa38c2525b076ba837817b4942ffe10c7c22a875975c7

   deviceb0b4e7bbc84f9d804f93bf7a29b48e9211a94a863f23c5fa39d6ac041f7c5695

   started from7dc01c203710db75af619953486500ce1268a3cc

   bundlenone

   • mediumPlanted BOSS on a fee-paying custodian (Universal Router PAY_PORTION shape) hands the whole killing blow and the killer prize to the fee collectorsrc/BossHook.sol:737

     _hopBlow treats every transfer out of a contract as blow BOSS first (out = min(value, held)). The Uniswap app's interface-fee flow custodies the bought BOSS on the Universal Router, pays PAY_PORTION as a share of the router's BOSS balance to the fee collector, then SWEEPs the remaining balance to the player. Anyone can send BOSS to the router in an earlier transaction (the router has no code to refuse it), inflating that balance so the 0.25% portion exceeds the blow.

     The fee hop then carries every wei of the blow's credit (damage[kr]) and, through _trackKill/_moveKill, the killer prize to the fee collector; the sweep to the player finds held[router] == 0 and carries nothing.

     This contradicts the README's claims that 'an interface fee of a fraction of a percent ... never end[s] up with it' and that 'BOSS anyone planted on a deployed contract never holds the blow back': the plant does not hold the blow back, it pushes it to the fee wallet.

     The planter gains nothing (the player even receives the planted BOSS via the sweep), so it is griefing, but it costs only about 400x the last hit's BOSS (tiny when bots race for the last hit with small buys) while the victim loses the full killer prize (45% of the pot) plus the blow's damage share, and a player using the standard app flow cannot prevent it.

     Fix (design decision): the hook cannot tell planted from blow BOSS on a contract, so use a custodian rule robust to both shapes, e.g. attribute blow BOSS leaving a contract in proportion to the transfer's share of the contract's pre-transfer balance (out = held * value / (balanceAfter + value)) instead of blow-first; that keeps the prize with the sweep's recipient (99.75%) and limits the exact-forwarder plant of review 5 to diluting rather than stealing.

     Alternatively document that app users paying an interface fee can lose the kill to a planter. Merged from audit_permissions; reproduced on this commit with test/scratch/PlantedFeeCustodian.t.sol.

     whole finding

     State: boss 1 at 1 IMD HP; tx 1: alice buys 0.99 IMD exact-in, 0.01 IMD HP left. tx 2: eve transfers 10,000,000 BOSS to the custodian router (a front-run). tx 3: carol (tx.origin) kills through the router with a 0.02 IMD exact-input buy; the router takes all BOSS to itself, pays 0.25% of its balance (~25,000 BOSS, more than the ~7,800 BOSS blow) to feeCollector, then sweeps the rest to carol.

     Expected (README): results(1).killer == carol, unclaimedKill(carol) == the prize, damage(1, carol) ~ the blow.

     Actual: results(1).killer == feeCollector, unclaimedKill(feeCollector) == 6817500000000000 (the whole prize), damage(1, feeCollector) == 10000000000000000 (the entire blow), damage(1, carol) == 0, unclaimedKill(carol) == 0.

     The control run without the plant leaves prize and credit with carol.

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

     whole reproduction

   • lowacceptAbility admits a mutable forwarder as an ability: its multipliers can change after approval with no new attestation, delay or intervalsrc/BossHook.sol:467

     The only on-chain guard on what the oracle approved is that the proposed address holds code that is not an EIP-7702 designator ('what passes here keeps its code').

     Keeping its code is not keeping its behaviour: a contract that forwards modifiers(SwapInfo) to an address held in storage (a proxy, a beacon clone, anything with a settable target) passes this check, is queued once the panel signs id*2+1, activates after the 12-hour delay, and from then on returns whatever its admin points it at. _abilityMults calls it on every trade with no re-check, so the forwarder's admin (the keeper, or whoever controls it) moves the live multipliers anywhere in [0.25x, 4x] at will, bypassing the oracle, the 12-hour public wait and the 24-hour minimum interval the README's trust model relies on ('The keeper cannot activate an ability without the oracle'; 'every change waits 12 hours in public').

     No ability can move money and the clamp still applies, so the damage is limited to game fairness (a heal boost switched on seconds before a large sell, a hit nerf when the boss is nearly dead), which keeps this low.

     The intended defence is condition (d) of the oracle question ('no external calls'), enforced by the panel only: one approval of a thin forwarder (verified source, no state writes, returns two numbers) hands its admin permanent control, and the keeper and signer are immutable so a panel error here is unrecoverable.

     Fix options: (1) at accept time refuse any ability whose runtime bytecode contains CALL/STATICCALL/DELEGATECALL/CALLCODE opcodes outside PUSH data (condition (d) forbids external calls anyway, so this rejects nothing the panel would approve); (2) have the attestation cover the behaviour the panel read (e.g. an answer encoding a hash the hook re-derives from a probe set of modifiers calls); or at minimum (3) state in the README that line 467 pins the address, not the behaviour.

     Merged from audit_flow; reproduced on this commit with test/scratch/MutableAbility.t.sol.

     whole finding

     State: hook launched, pool initialized, no ability active.

     Keeper proposes MutableProxy(impl = GoodAbility returning (10000, 10000)); the oracle signs answer id*2+1 for that id; acceptAbility succeeds; 12 hours later a 0.01 IMD exact-input buy removes 0.01 IMD of HP (1x).

     The proxy admin calls setImpl(HarshAbility returning (2500, 40000)).

     Expected: the ability in force keeps the behaviour the panel approved until a new attestation is accepted, waits 12 hours and respects the 24-hour interval.

     Actual: the very next 0.01 IMD buy removes 2500000000000000 (0.0025 IMD, 0.25x) of HP while activeAbility is still the proxy and acceptedId has not moved; no attestation, delay or interval was involved.

     Run: forge test --match-path test/scratch/MutableAbility.t.sol -vv (fails with 2500000000000000 != 10000000000000000).

     whole reproduction

   • infoAttestation issued in the same second as the proposal is refused as stale (off-by-one on the freshness boundary)src/BossHook.sol:469

     acceptAbility treats an attestation whose issuedAt equals AbilityBoard.proposedAt as stale. Both are whole seconds, so an oracle that observes the proposal in the block that includes it and signs with issuedAt equal to that block's timestamp produces an attestation the hook can never accept, although it was issued after the proposal was recorded and refers to the right (id, ability) pair.

     The strict comparison buys no security: the answer is already bound to the board id, which increments on every propose, so an attestation for id N cannot approve any other proposal, and acceptedId stops replay. The only effect is a liveness nit: the oracle has to issue a second attestation one second later.

     Fix: use <, or document that the oracle must issue strictly after the proposal's block timestamp. Merged from audit_math; reproduced on this commit with test/scratch/SameSecondAttestation.t.sol.

     State: keeper calls board.propose(ability, note) at block.timestamp T (proposedAt = T, id = 1).

     Input: a valid attestation for answer 3 (= 1*2+1), panelSize 21, quorum 15, agreed 18, issuedAt = T, expiresAt = T + 1h, signed by the oracle signer; call hook.acceptAbility(a, sig) in a block with timestamp T.

     Expected: the ability is queued (AbilityQueued).

     Actual: revert StaleAttestation().

     With issuedAt = T + 1 and block.timestamp = T + 1 the same call succeeds (control test in the same file).

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

     whole reproduction

   • infoForfeit slice rounds down in favour of the wallet handing BOSS back (sub-wei credit retention, not economically exploitable)src/BossHook.sol:904

     _slice computes the credit that leaves with value BOSS as dmgTotal * value / bossTotal, rounded down. On the forfeit path (_release called from onBossTransfer when to is the PoolManager or the hook) this rounding favours the wallet handing BOSS back: any transfer of fewer than bought/damage wei of BOSS lowers bought[r][from] but forfeits zero damage.

     At the launch price (tick 129000, about 2.6e-6 IMD per BOSS) that window is about 3.8e5 wei of BOSS per transfer (3.8e-13 BOSS), so draining a real position's forfeit this way takes on the order of 1e17 transfers and is not a practical attack; the pot, the eligible-damage denominator and other wallets' shares are only affected by sub-wei dust.

     Reported because a forfeit is a charge against the leaving wallet and the convention is to round such charges up so the protocol never loses the dust.

     Minimal fix: round the forfeit up on the sink path only (e.g. (dmgTotal * value + bossTotal - 1) / bossTotal, capped at dmgTotal), keeping the wallet-to-wallet move and the pending-delivery paths rounded down. Merged from audit_economics; reproduced on this commit with test/scratch/ForfeitRounding.t.sol.

     whole finding

     Fixture: BOSS/mock-IMD pool at tick |129000|, initial HP 1 IMD.

     1. alice buys with 0.1 IMD exact-in: damage[1][alice] = 100000000000000000, bought[1][alice] = 38285676337265786184662.

     2. alice transfers 382856 wei of BOSS (bought/damage) straight to the PoolManager (a sink).

     Expected under 'forfeits in proportion': a forfeit of at least 1 wei of damage.

     Actual: damage[1][alice] stays 100000000000000000 while bought[1][alice] drops to 38285676337265785801806 (the slice 1e17*382856/3.8285676e22 rounds to 0).

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

     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,189,989 · transaction#573#253#1327#1430#1457