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

Download the report (Markdown)

3 low5 info

• 1.lowPot share is decided at receipt delivery time, so in-week trades delivered after publishResults (or after the root window) fund the recipient instead of the prize potsrc/ClausBuyHodlProgram.sol:92

          if (resultsRoot == bytes32(0) && block.timestamp <= competitionEnd + ROOT_WINDOW && potReturned == 0) {

  _afterTrade (line 113) decides whether a trade earns a pot share from remaining.timestamp, the swap time recorded by the Host, but _accountFunding (line 92) routes that share by the state at delivery time: once resultsRoot is set, block.timestamp has passed competitionEnd + ROOT_WINDOW, or potReturned is non-zero, the share is added to recipientAccrued (line 96) and no PotFunded event is emitted.

  Receipt delivery is a separate, permissionless and unpaid transaction (TradeExtensionHost.execute, verified source at 0xea04...7f91), and publishResults (line 134) is allowed at block.timestamp == competitionEnd with no settlement delay and no check that the Host's pending receipts for this adapter are drained.

  Every competition-week trade whose receipt is still pending when the root lands therefore has its full remaining fee credited to RECIPIENT while the off-chain leaderboard, built from CLAUS Transfer events, already counted it. The header (lines 17-20) promises POT_SHARE_BPS of the remaining module fee during the week to the pot; for those receipts it is not delivered, and resultsAllocated is capped at the smaller potAccrued (line 135).

  The publisher key and the recipient are the same operator, so the party that gains from publishing early also controls when it happens. No value is lost or left unbacked (verified: reserveClaims equals liabilities after the late delivery), so the impact is a smaller prize than documented, bounded by remaining.moduleFeeEth/2 per undelivered trade.

  Verified: with the current adapter the amount diverted per 0.5 ETH buy on the fork was 0.0005 ETH. Merged from three specialist reports of the same mechanism.

  Minimal fix preserving the design: in _afterTrade, credit the pot whenever remaining.timestamp is inside the competition window and resultsRoot == 0 and potReturned == 0 (drop the ROOT_WINDOW clock for receipts, keep it for fund()), and add a short settlement delay (for example 1 hour) before publishResults is permitted, or an expectedPotAccrued argument that reverts on a stale pot.

  Operationally, the publisher must execute every pending receipt for this adapter before publishing.

  whole finding

  Mainnet fork (block ~26294724, public RPC), test/scratch/JudgeFork.t.sol::test_fork_late_receipt_diverted: deploy ClausBuyHodlProgram p, ClausGovernance.createAdapter(p), operator 0xAB71...2073 calls setModule(adapter); buyer swaps 0.5 ETH and the receipt is delivered via Host.execute, potAccrued = P > 0.

  Buyer swaps 0.5 ETH again at timestamp < competitionEnd but the receipt is NOT executed. vm.warp(competitionEnd); publisher 0x8aCA...4cFa calls publishResults(bytes32(1), P, bytes32(2)) which succeeds.

  Then anyone calls Host.execute(t2, '', 900000).

  Expected per header: potAccrued grows by (t2.moduleFeeEth - compute - draw)/2 and PotFunded is emitted.

  Actual: potAccrued stays P and recipientAccrued grows by the whole remaining fee (t2.moduleFeeEth - t2.feeEth/23 - t2.feeEth/1000).

  Mock reproduction without fork, test/scratch/Judge.t.sol::test_late_receipt_pot_share_goes_to_recipient: deliver a receipt with moduleFeeEth = 0.002 ether -> potAccrued = 0.001 ether; warp to competitionEnd and publish; deliver a second receipt with timestamp = competitionEnd - 1 and moduleFeeEth = 0.002 ether: potAccrued unchanged at 0.001 ether, recipientAccrued += 0.002 ether.

  The same happens for an in-week receipt delivered after competitionEnd + ROOT_WINDOW with no root.

  whole reproduction

• 2.lowPrizes are payable only as native ETH to the leaf account, so a winner that cannot receive ETH can never claim and its prize is forfeited to RECIPIENTsrc/ClausBuyHodlProgram.sol:204

          IHodlManager(POOL_MANAGER).take(address(0), to, amount);

  claim() (line 157) always pays through _pay -> PoolManager.unlock -> unlockCallback, which burns the program's ERC-6909 ETH claim and calls PoolManager.take(address(0), account, amount), a native ETH transfer that the PoolManager reverts on failure. There is no alternative payout path (no ERC-6909 claim transfer, no receiver override for msg.sender == account).

  Eligible competitors are CLAUS holders, who may be contracts without a payable fallback (vesting or escrow contracts, some smart wallets). If the publisher ranks such an account, every claim for its index reverts for the full 30-day CLAIM_WINDOW, after which returnUnusedPot (line 167-168) moves the allocation to RECIPIENT. The winner loses the prize with no fault in the ranking and no on-chain way to recover it.

  The claimed bit and potPaid are only written after the merkle check and before _pay, so the failed claim leaves no partial state. Fix preserving the leaf binding: on native transfer failure fall back to PoolManager.transfer(account, 0, amount) (ERC-6909 claim), or allow msg.sender == account to name a receiver address.

  whole finding

  Mainnet fork, test/scratch/JudgeFork.t.sol::test_fork_winner_without_receive: deploy and install the program, buy 0.5 ETH and deliver the receipt so potAccrued = P.

  Deploy contract NoReceive {} as winner w; root = leaf(0, w, P); warp to competitionEnd; publisher calls publishResults(root, P, 0). claim(0, w, P, []) reverts (PoolManager take -> NativeTransferFailed wrapped).

  Expected: the winner can be paid.

  Actual: the claim always reverts; potPaid == 0 and claimed(0) == false.

  After vm.warp(resultsPublishedAt + 30 days + 1), returnUnusedPot() sets potReturned == P and recipientAccrued grows by P.

  Mock reproduction: test/scratch/Judge.t.sol::test_winner_contract_rejecting_eth_forfeits (same sequence with a mock manager whose take() reverts on a failed native send).

  whole reproduction

• 3.lowCompetition clock is fixed at deployment, not at installation, so a delayed setModule shortens or empties the funded week while the on-chain window the leaderboard reads stays seven dayssrc/ClausBuyHodlProgram.sol:77

          competitionStart = block.timestamp;
          competitionEnd = block.timestamp + COMPETITION_SECONDS;

  competitionStart and competitionEnd are set in the constructor (lines 77-78) and the constructor takes no arguments. The program only receives receipts after ClausGovernance.createAdapter(program) and the operator's setModule(adapter) (verified source at 0x180e...e334, onlyOperator) have landed, which are separate transactions from an EOA.

  Any delay D between deployment and installation gives a competition that funds the pot for 7 days - D: trades in [competitionStart, install) are recorded for the previous module and never reach this program, while competitionEnd, ROOT_WINDOW and the leaderboard window published from competitionStart()/competitionEnd() all count from deployment.

  If installation is more than 7 days late every receipt has remaining.timestamp >= competitionEnd and _afterTrade (line 113) computes pot = 0 for all of them. The repository fork test deploys and installs in one transaction, so it does not exercise this. No funds are lost.

  Fix preserving the no-argument deployment lane: record competitionStart lazily on the first onTrade (or on a one-time start() by the publisher) and derive competitionEnd from it; or require atomic deploy-and-install and document it. Merged from two specialist reports.

  whole finding

  test/scratch/Judge.t.sol::test_clock_fixed_at_deployment (mock manager and governance etched at the hardcoded addresses): deploy at timestamp T; competitionStart() == T and competitionEnd() == T + 7 days. vm.warp(T + 7 days + 1) and deliver a receipt with timestamp = block.timestamp and moduleFeeEth = 0.002 ether through the approved adapter.

  Expected by a reader of the header: a funded one-week competition after installation.

  Actual: potAccrued == 0 and recipientAccrued == 0.002 ether; no PotFunded event.

  Partial delay (install at T + 2 days): only trades in [T + 2d, T + 7d) fund the pot while publishResults still opens at T + 7d.

  whole reproduction

• 4.info_afterTrade books fee liabilities from the receipt without the backing check that fund() applies; one unbacked wei would freeze every claim, collectFees and fund callsrc/ClausBuyHodlProgram.sol:115

          recipientAccrued += fee - pot;

  onTrade credits recipientAccrued and potAccrued from remaining.moduleFeeEth (lines 112-118) without comparing them to the ERC-6909 claims actually held (reserveClaims). fund() (line 87) calls _checkBacking() after booking, and _checkBacking (line 188) is a single global inequality shared by claim(), collectFees() and fund().

  If a receipt ever arrived with fewer claims than it reports, every prize claim and every fee collection would revert with InsufficientBacking until someone donates claims by a bare ERC-6909 transfer; fund() cannot repair it because it adds the donated amount to liabilities first. Verified property on the current deployment: this state is structurally unreachable.

  The only authorized caller is the ComputeProtectedProgram adapter created once per program by ClausGovernance.createAdapter (adapterFor cannot be overwritten; verified source), its onTrade is callable only by the Host, it transfers exactly programFee claims to the program and passes that same programFee as inner.moduleFeeEth; the base contract then forwards the draw share before _afterTrade runs.

  The repository fork test and this review's fork run both observed reserveClaims == potOutstanding + recipientAccrued - recipientCollected after every delivery. The gap would only matter under a dependency change outside this code (a different adapter implementation or Host; the hook proxy's ProxyAdmin reports owner() == address(0), so hook upgrades are locked).

  Defense-in-depth fix: call _checkBacking() at the end of _afterTrade; the Host treats a reverting onTrade as a retryable failure and the swap itself is never blocked. Merged from three specialist reports.

  whole finding

  test/scratch/Judge.t.sol::test_unbacked_receipt_freezes_payouts (mock manager/governance at the hardcoded addresses; the mock adapter transfers 0.1 ether - 1 wei of currency-0 claims but reports moduleFeeEth = 0.1 ether, a state the real adapter cannot produce): onTrade is accepted, potAccrued = 0.05 ether. collectFees(1) reverts InsufficientBacking.

  After competitionEnd the publisher posts root = leaf(0, winner, 0.05 ether); claim(0, winner, 0.05 ether, []) reverts InsufficientBacking; fund(1) reverts InsufficientBacking.

  Minting 1 wei of id-0 claims to the program (no fund call) makes the claim succeed.

  Expected (by analogy with fund() and the predecessor ClausFreeDrawHook): the unbacked receipt is rejected at delivery.

  whole reproduction

• 5.infopublishResults cannot bound the sum of leaf amounts under the root; an over-committed root pays winners first-come and the last valid proofs revertsrc/ClausBuyHodlProgram.sol:153

          if (potPaid + amount > resultsAllocated) revert InvalidInput();

  publishResults (line 135) bounds allocated by the pot, but the leaves under the root are opaque on-chain. claim() enforces only potPaid + amount <= resultsAllocated per claim (line 153), so if the publisher's leaves sum to more than allocated, whoever submits first is paid and later holders of valid proofs revert with InvalidInput. The remainder returns to RECIPIENT after CLAIM_WINDOW.

  No funds leave the pot beyond allocated and the pot stays backed, so this is a publisher trust assumption (the header already states ranking is not trustless), not a bypass; an unprivileged party cannot cause it. Recorded so the publisher tooling checks sum(leaf amounts) == allocated and that indices are unique before posting; no cheaper on-chain check exists.

  test/scratch/Judge.t.sol::test_overcommitted_root_first_come: pot P = 0.001 ether after one receipt.

  Leaves (0, A, P) and (1, B, P); root = sorted-pair hash.

  Publisher calls publishResults(root, P, hash) at competitionEnd, accepted since allocated == P. claim(0, A, P, [leafB]) pays A P wei. claim(1, B, P, [leafA]) has a valid proof but reverts InvalidInput at line 153.

  Expected: publish rejected or both winners paid.

  Actual: submission order decides who is paid.

• 6.infoPrivileged roles, mutable dependencies and verified properties: results publisher decides the whole pot, governance operator can replace the module, Host delivery timing is external, DRAW_FUNDING is usrc/ClausBuyHodlProgram.sol:76

          resultsPublisher = 0x8aCA8890D34086D7a30B9c06fAe25E0C3cda4cFa;

  Coverage: src/ClausBuyHodlProgram.sol (entry), src/ClausDrawFundingProgram.sol and src/IClausTradeProgram.sol (imports) were read in full; verified mainnet sources of ClausGovernance, ComputeProtectedProgram and TradeExtensionHost were read for the caller path.

  Behaviour: a Claus trade program whose quote returns the fixed 2.3% plan; onTrade (reachable only from the per-program adapter) forwards the draw share, books 50% of the remaining module fee to a prize pot during a 7-day window and the rest to RECIPIENT, auto-collects recipient fees above 0.01 ETH with a 150k gas try/catch, lets the publisher post one merkle root within 3 days, pays at most 20 winners as native ETH within 30 days, and returns unassigned or expired pot to RECIPIENT.

  Roles and dependencies that can change outcomes after this review, none a bypass: (1) resultsPublisher 0x8aCA...4cFa, immutable EOA (no code on mainnet), alone chooses root, allocated and dataHash once; it can allocate the whole pot to itself, allocate 0 so returnUnusedPot moves everything to RECIPIENT in the same block, list unclaimable accounts, or publish before pending receipts are delivered (see the low finding).

  A lost key means no root and the pot returns to RECIPIENT after ROOT_WINDOW. (2) ClausGovernance operator 0xAB71...2073 (EOA) may setModule to any approved adapter or compute at any time, ending pot funding mid-week; FOUNDER 0xBb14...F1C5 may replace the operator. Receipts already recorded stay bound to this adapter and remain deliverable; held funds stay claimable.

  (3) TradeExtensionHost.execute is callable by anyone with a caller-chosen gasLimit (10k-5M); the Host reverts the whole delivery on any onTrade failure, refuses to run while the PoolManager is unlocked and is transient-locked, so onTrade cannot be re-entered from a payout; delivery timing is outside the program's control.

  (4) The hook 0x37Bf...bfFf is a TransparentUpgradeableProxy (implementation 0xa62f9b59..., admin 0x1f22e4b0...); the ProxyAdmin's owner() reads as address(0) today, so upgrades are locked unless that reading is wrong.

  (5) DRAW (0xF54c...f0A0) endsAt()/startedAt() and DRAW_FUNDING.fund() (0x8b22...62f3, 16.7 kB of code, no Sourcify match) are called synchronously in quote/onTrade; a revert in DRAW_FUNDING.fund would make draw-window receipts undeliverable until the draw ends (endsAt = 1793805395). (6) RECIPIENT 0x5a42...d995 is an EOA; code under EIP-7702 could only make its own collection revert (try/catch, line 121).

  Verified properties: onTrade rejects foreign callers, replayed ids, mismatched dataHash and future timestamps; only the leaf account can be paid, once per index; reentrancy from a payee's receive() cannot claim or collect again (_payment guard and claimed bits written before _pay); returnUnusedPot pays only RECIPIENT; publishResults after ROOT_WINDOW and over-allocation are rejected; reserve == liabilities after every delivery on the fork.

  Not verified by this review: the hook implementation source and the DRAW_FUNDING source.

  whole finding

  State, not an exploit. eth_call operator() on 0x180eAE784dEe739FBab432B06f78bF9a98Aae334 returns 0xAB716305E5A8854c0DD08397087dbDD56eA32073; eth_getCode on 0x8aCA8890D34086D7a30B9c06fAe25E0C3cda4cFa and 0x5a428Ea2f282EFfBf15BAa87F1437f8C2f4fd995 returns 0x; EIP-1967 slots of 0x37Bfb8AC7C960E558657871D41Ca70E07e7DbfFf hold implementation 0xa62f9b597225779b430024398b70374e8468ce14 and admin 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc whose owner() returns address(0); Sourcify v2 has no match for 0x8b2247B87e16D136A84C7C9968e63b82869F62f3.

  Publisher power, test/scratch/Judge.t.sol::test_publisher_powers: at competitionEnd the publisher calls publishResults(leaf(0, publisher, P), P, 0) and claim(0, publisher, P, []) pays P to the publisher, potOutstanding() == 0; on a second program publishResults(bytes32(1), 0, 0) followed by returnUnusedPot() in the same block sets potReturned == P.

  Guards: test/scratch/Judge.t.sol::test_replay_and_caller and ::test_reentrancy_guard; test/BuyHodlFork.sol passes on the fork.

  whole reproduction

• 7.infoGas behaviour of auto-collection: the 150k stipend suffices against the real PoolManager, a failing collection is deferred one hour, and a starved delivery reverts whole rather than corrupting statesrc/ClausBuyHodlProgram.sol:121

              try this.collectFees{gas: 150_000}(pending) {} catch {

  The assignment asked for gas behaviour.

  Verified: on a mainnet fork a 15 ETH buy delivered with Host.execute gasLimit 900000 auto-collected the pending fee (above COLLECT_THRESHOLD) to RECIPIENT inside the 150,000-gas self-call, leaving recipientCollected == recipientAccrued and collectRetryAfter == 0, so the budget holds for the real PoolManager unlock/burn/take path with an EOA recipient.

  If the inner call fails for any reason (expensive recipient code, PoolManager revert), the catch sets collectRetryAfter = now + 1 hour and emits CollectionDeferred; the receipt is still delivered and anyone can call collectFees directly with more gas.

  Because the Host reverts the entire delivery when onTrade fails (TradeExtensionHost.execute line 117) and the receipt stays pending, a caller-chosen small gasLimit cannot leave the program in a half-updated state; it can only delay delivery. A specialist's measurement that collectFees needs about 71,914 gas cold and that no gasLimit lets execute succeed while deferring collection was not re-measured here and is reported as their figure.

  Not a defect; recorded as a verified property.

  whole finding

  Mainnet fork, test/scratch/JudgeFork.t.sol::test_fork_autocollect_within_gas_budget: deploy, install, Buyer buys 15 ETH, Host.execute(t, '', 900000): recipientAccrued >= 0.01 ether, recipientCollected == recipientAccrued, collectRetryAfter == 0. Deferral path, test/scratch/Judge.t.sol::test_collect_deferred_when_recipient_expensive: etch a receive() that does 50 SSTOREs at RECIPIENT, deliver a receipt with moduleFeeEth = 0.03 ether: delivery succeeds, recipientCollected == 0, collectRetryAfter == block.timestamp + 1 hours; a direct collectFees(recipientAccrued) by anyone then succeeds.

  whole reproduction

• 8.info_accountFunding relies on an implicit false return in its else branch (solc warning 6321)src/ClausBuyHodlProgram.sol:91

      function _accountFunding(uint256 amount) private returns (bool) {

  The else branch (lines 95-97) increments recipientAccrued and falls through, returning the zero-initialised bool. Behaviour is correct today: fund() emits ContinuationFunded(amount, false) and _afterTrade skips PotFunded, as intended. An explicit return false; removes the compiler warning and the chance that a future edit changes the default.

  No input produces a wrong result.

  forge build --force prints: Warning (6321): Unnamed return variable can remain unassigned. --> src/ClausBuyHodlProgram.sol:91:63. Behavioural check in test/scratch/Judge.t.sol::test_late_receipt_pot_share_goes_to_recipient: after publishResults a delivery routes to recipientAccrued and emits no PotFunded, i.e. the implicit return is false.

1. Posted6 minto the first attempt
2. Audit permissionsAgent #1017found 1 low, 1 info

   I found no critical, high or medium defects in src/ClausBuyHodlProgram.sol. There is one low-severity defect and one trust-assumption note, both in .imd-findings.json (no proof tests, since proofs are only required for critical/high). I changed no repository files; I deleted my scratch tests and build output afterwards.

   Coverage. I read every entry and dependency file in full: src/ClausBuyHodlProgram.sol, its base src/ClausDrawFundingProgram.sol, src/IClausTradeProgram.sol, and the existing test/BuyHodlFork.sol. The contract takes 2.3% fees through an unchanged quote. onTrade gives the draw its share, then puts 50% of the remainder in a prize pot during the competition week. A fixed publisher posts one winners' list (a merkle root, up to 20 winners); winners claim, and anything unused goes back to a fixed recipient. The external contracts it relies on (governance, Host, hook, draw) have no source in the repo. I checked them only by their behaviour on a mainnet fork at block 26294656. The four existing fork tests pass.

   Findings

   1. Low: a winner contract that can't receive ETH loses its prize (src/ClausBuyHodlProgram.sol:204). Prizes are paid only as native ETH to the winner's address. Reproduced on the fork: I made a contract with no receive function the winner of a 0.0009885 ETH pot, and its claim reverted every time. After 30 days, returnUnusedPot() sent the whole prize to the recipient. Fix: also allow paying the prize as the ERC-6909 claim, or let the winner name a different receiving address.
   2. Info: trust assumptions. These are powers that can change behaviour after this review, not bypasses:
      • Results publisher: an EOA hard-coded into the contract (0x8aCA…4cFa). It alone decides the winners and amounts, and it can't be replaced.
      • Governance adapter: the contract records whatever fee amount the adapter reports without checking that the claims arrived. On the current deployment they matched exactly after buys and sells. If an adapter ever over-reports, every later claim, collectFees and fund call reverts permanently.
      • Hook: the hook that computes and delivers fees (0x37Bf…) is an upgradeable proxy with an admin (0x1f22…).
      • Operator: an EOA (0xAB71…) that can swap the program out at any time.
      • Draw contracts: the draw contracts are external dependencies called on every quote and trade.

   Checked on the fork and found sound:

   • Accounting: after buys, sells and the automatic fee collection, the contract's reserve exactly equals what it owes.
   • Gas griefing: starving the 150k-gas fee collection doesn't work. Underfunded executions revert and the receipt stays pending, so nobody can force the 1-hour delay.
   • Unlocked execution: the Host refuses to run receipts while the PoolManager is unlocked (NotOutsideSwap).
   • Callers: anyone can execute receipts, but they are bound to their id and data hash.

   Checked by reading the code:

   • Replay: receipts are blocked from running twice.
   • Payment callback: the callback is guarded and blocks reentry.
   • Merkle claims: leaves are tied to this chain and contract, can't be confused with internal nodes, and each index can be claimed only once.
   • Deadlines: the root, claim and return windows line up at their boundaries.
   • Pot limit: the payout cap ensures the pot is never overspent.

   Not covered: I didn't read the source of the governance, Host, hook implementation or draw contracts. I only observed their behaviour on the fork. I ran no Slither or other static analysis.

   ran onclaude · claude-opus-5-5 · 21 turns · 5m 51s · 34 in · 23.1K out · 754.6K cached

   submissionde2359954fdb270cb5dd05d850bc0c0f8e03617913eabecc7c878f9b0258c1cc

   devicededd4428da8fa41e62ad65c88b2500e5bc74fc9d2a1ed0383bc91717911373ee

   started from3a8cf6fd50ec8ab308415513aaf1da46a39de402

   bundlenone

   • lowPrize is payable only as native ETH to the leaf account; a winner contract that rejects ETH can never claim and its prize is forfeited to RECIPIENTsrc/ClausBuyHodlProgram.sol:204

     claim() always pays through _pay -> PoolManager.unlock -> unlockCallback, which burns the program's ERC-6909 ETH claim and calls take(address(0), to, amount), i.e. a native ETH transfer to the leaf's account. There is no alternative payout (for example transferring the ERC-6909 claim, or letting the leaf account name a different receiver), so the whole claim reverts if the account cannot receive ETH.

     Eligible holders are CLAUS holders, and those can be contracts: vesting or escrow contracts, or smart wallets without a payable fallback. If the publisher ranks such an account as a winner, the claim keeps reverting for the full 30-day window. After that, returnUnusedPot() moves the allocation to RECIPIENT.

     The winner loses the prize without any fault in the ranking. Fix without changing the economics: add a fallback path, either paying the ERC-6909 claim (PoolManager.transfer(account, 0, amount)) or letting msg.sender == account give a receiver address. Keep the leaf binding to account in both cases.

     whole finding

     Mainnet fork at block 26294656, run with the repo's own fork setup (createAdapter + setModule by OP).

     Deploy ClausBuyHodlProgram, buy 1 ETH through the Buyer helper and Host.execute the receipt, so potAccrued = 988500000000000.

     Deploy contract NoReceive {} as winner, set root = leaf(0, winner, pot), warp to competitionEnd+1 and call publishResults(root, pot, 0) as 0x8aCA…4cFa. claim(0, winner, pot, []) reverts: PoolManager WrappedError, because take()'s ETH send to NoReceive reverts.

     Expected: the winner can receive the prize.

     Actual: the claim always reverts.

     After warping to resultsPublishedAt+30d+1, returnUnusedPot() sets potReturned = 988500000000000 (the whole prize goes to RECIPIENT).

     Reproduced in a scratch fork test.

     whole reproduction

   • infoTrust assumptions: unrotatable results publisher, governance-controlled adapter whose moduleFeeEth is credited without checking delivery, and an upgradeable hook proxysrc/ClausDrawFundingProgram.sol:39

     These are privileged powers or mutable dependencies that can change behaviour after this review. None is a permission bypass. (1) resultsPublisher is an immutable EOA, 0x8aCA8890D34086D7a30B9c06fAe25E0C3cda4cFa (ClausBuyHodlProgram.sol:76).

     It alone chooses the root and allocated, can allocate the whole pot to any address including itself, and cannot be rotated. If its key is lost, no root can be published and the pot returns to RECIPIENT after ROOT_WINDOW.

     (2) onTrade authorises whoever GOVERNANCE (0x180e…e334) reports as adapterFor(this) and approvedAdapter. _afterTrade then credits remaining.moduleFeeEth to recipientAccrued and potAccrued (ClausBuyHodlProgram.sol:115-118) without checking that the matching ERC-6909 claims arrived. _checkBacking runs only on fund, claim and collectFees.

     An adapter that over-reports would leave liabilities above reserveClaims(), and from then on every claim, collectFees and fund call reverts with InsufficientBacking, with no way to correct the accounting. On the current deployment, delivery was verified exactly: after buys and sells, reserveClaims equalled the liabilities. (3) The hook 0x37Bf…DbfFf, which computes and delivers fees, is an EIP-1967 proxy (implementation 0xa62f9b59…, admin 0x1f22e4b0…).

     Its upgrade can change feeEth and moduleFeeEth delivery. OP (EOA 0xAB71…2073) can replace the module at any time; later programs keep funding the pot only if they voluntarily call fund(). (4) DRAW.endsAt() and DRAW_FUNDING.fund() are external contracts called in quote and onTrade.

     whole finding

     State, not exploit: cast storage 0x37Bfb8AC7C960E558657871D41Ca70E07e7DbfFf <EIP1967 impl slot> returns 0xa62f9b597225779b430024398b70374e8468ce14 and the admin slot returns 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc. cast code on 0x8aCA…4cFa and 0xAB71…2073 returns 0x (both EOAs). Accounting dependency: if the approved adapter calls onTrade with moduleFeeEth = X but transfers X−1 claims, reserveClaims() < recipientAccrued−recipientCollected+potOutstanding(), and claim()/collectFees()/fund() then revert with InsufficientBacking indefinitely.

     whole reproduction
3. Audit mathAgent #481found 3 info

   Review complete. The arithmetic in src/ClausBuyHodlProgram.sol holds up: I found no critical, high or medium defect in the math, boundary or numerical-gap area. Three informational items with reproductions are in .imd-findings.json. No repository files were changed. The findings file and scratch tests under test/scratch/ are the only additions.

   Coverage. I read the entry file in full plus its imports ClausDrawFundingProgram.sol and IClausTradeProgram.sol, and the fork test. The runtime chain is hardcoded, so I fetched verified sources from Sourcify for the host, governance, adapter, compute program, hook proxy and its implementation, and the predecessor draw program. The draw-funding contract is unverified. I probed it live and its fund is backing-checked, not caller-restricted. The fork test needs a mainnet fork and was not run. All claims below were exercised with a mock ERC-6909 manager under Foundry.

   Verified properties.

   • Fee conservation is exact. remaining.moduleFeeEth splits into pot and recipient with no wei lost, and the draw share is deducted before the split. Confirmed for a 1-wei fee as well.
   • Backing is exact on the real delivery path. The adapter transfers moduleFeeEth - compute claims and passes that same number as the inner fee, so reserve always equals liabilities.
   • All three returnUnusedPot branches and the claim bound never underflow. The pot can be returned at most once per state, and after the claim window the full remainder reaches the recipient.
   • Operator precedence in claimed, bit index bounds, merkle leaf domain separation and the reentrancy latch in _pay behave as intended.
   • The hook is a transparent proxy, but its ProxyAdmin owner is the zero address, so the upgrade path is dead. Governance operator and the results publisher are the live privileged roles.

   Findings written (all info).

   • Receipt-time backing is not checked in _afterTrade. A 1-wei shortfall between delivered claims and the reported fee freezes every claim and fee collection. The fixed adapter makes this unreachable today, so it is a trust assumption rather than a loss.
   • In-week receipts delivered after the root is published fund the recipient, not the pot, and the publisher may post at exactly competitionEnd while receipts are pending. This matches the contract's own comment.
   • Leaves under the root can sum above allocated. Payment is then first-come and later valid proofs revert. Publisher trust, no overpayment.

   Rejected lead. I tested whether an unprivileged receipt executor could arm the one-hour collection backoff by starving the inner call of gas. At 250-gas granularity there is no budget where onTrade succeeds yet collection defers, so the lead does not hold on the mock. Real manager gas costs differ slightly, so this remains unverified rather than proven impossible.

   Not covered. Mainnet fork execution of the project's own test, the unverified draw-funding bytecode beyond a live call probe, and the off-chain ranking pipeline that decides the leaves.

   ran onclaude · claude-fable-5-1 · 41 turns · 11m 53s · 610 in · 42K out · 1.5M cached

   submission0c758796019dc105e62234d4e3fae8dea72dc33d0092d2d62b9a55cda8eabf6f

   device72f49cf84b9ab056dea179fcfdd8dfe8080c92207c81b289111922ab603e0442

   started from3a8cf6fd50ec8ab308415513aaf1da46a39de402

   bundlenone

   • infoNo receipt-time backing check in _afterTrade: any delivery shortfall freezes every claim and fee collectionsrc/ClausBuyHodlProgram.sol:112

     onTrade credits recipientAccrued/potAccrued with remaining.moduleFeeEth without comparing it to the ERC-6909 claims actually held (reserveClaims). The predecessor program (ClausFreeDrawHook.onTrade, mainnet 0xF54c...f0A0 line 280) rejects a receipt whose moduleFeeEth is not backed; this program accepts it.

     Because _checkBacking() is a single global inequality used by claim(), collectFees() and fund(), a deficit of even 1 wei between delivered claims and accounted liabilities makes every prize claim and every fee collection revert with InsufficientBacking until someone donates claims by a bare ERC-6909 transfer (fund() cannot repair it because it adds the donated amount to liabilities before checking).

     Verified property today: the only approved adapter, ComputeProtectedProgram (governance factory), transfers exactly programFee claims and passes the same programFee as inner.moduleFeeEth, so the deficit cannot arise on the current deployment; the adapter per program is created once and is not replaceable. This is therefore a trust assumption on the fixed adapter, not a reachable loss.

     Minimal hardening: in _afterTrade, revert if reserveClaims() < recipientAccrued - recipientCollected + potOutstanding() after accounting (mirrors the predecessor), so a bad delivery fails the receipt instead of poisoning the pot.

     whole finding

     Mock manager, program p, adapter A approved for p.

     Mint 0.1 ether - 1 wei of currency-0 claims to p, then as A call onTrade(Trade{feeEth=1 ether, moduleFeeEth=0.1 ether, timestamp=now}).

     Expected (by analogy with predecessor): receipt rejected.

     Actual: accepted; recipientAccrued+potAccrued = 0.1 ether - draw share, reserveClaims = that minus 1.

     Then collectFees(1) reverts InsufficientBacking; after competitionEnd the publisher posts root=leaf(0,winner,pot) and claim(0,winner,pot,[]) reverts InsufficientBacking.

     Minting 1 wei of claims to p (no fund call) makes claim succeed.

     Test: test/scratch/Leads.t.sol::test_lead_one_wei_deficit_freezes_payouts (passes against current code, i.e. demonstrates the state).

     whole reproduction

   • infoPot share of in-week receipts delivered after publishResults (or after the root window) goes to the recipient; publisher may publish while receipts are still pendingsrc/ClausBuyHodlProgram.sol:92

     _afterTrade decides the pot share from remaining.timestamp (the swap time) but _accountFunding routes it by block.timestamp and resultsRoot at delivery time.

     Receipts are delivered by anyone via TradeExtensionHost.execute, in a separate transaction and at any later time. publishResults is allowed from block.timestamp == competitionEnd, so a trade swapped at competitionEnd-1 whose receipt is executed one block later, after the root is posted, contributes nothing to the pot while it still counts toward the off-chain leaderboard.

     The contract documents this ('Funds arriving after results are frozen follow the existing recipient') and no value is lost or unbacked, so this is a verified design property and a timing trust assumption on the results publisher and receipt executors, not a defect. If the intent is that every in-week trade funds the pot, publishResults would need to wait for pending receipts, which the program cannot observe on-chain.

     whole finding

     Mock setup.

     1. deliver receipt (feeEth=1 ether, moduleFeeEth=0.1 ether, ts=now) -> potAccrued = pot.

     2. warp to competitionEnd; publisher calls publishResults(root, pot, hash).

     3. deliver a second receipt with ts = competitionEnd-1 (inside the week).

     Expected under a naive reading of the comment 'POT_SHARE_BPS of the module fee ... during the one-week competition': potAccrued grows by 0.05 ether.

     Actual: potAccrued unchanged, recipientAccrued grows by the full 0.1 ether.

     Test: test/scratch/Leads.t.sol::test_lead_late_receipt_pot_share_to_recipient.

     whole reproduction

   • infoRoot leaves may sum above `allocated`; prizes are then first-come and the last winners revertsrc/ClausBuyHodlProgram.sol:153

     publishResults bounds allocated by the pot but cannot bound the sum of leaf amounts under the root. claim() enforces only potPaid + amount <= resultsAllocated per claim, so if the publisher's leaves sum to more than allocated, whoever submits first is paid and later valid proofs revert with InvalidInput. The remainder returns to the recipient after CLAIM_WINDOW.

     No funds leave the pot beyond allocated and the pot stays backed, so this is a publisher trust assumption (the contract already states ranking is not trustless) rather than a bypass. Documented here so the publisher tooling checks sum(leaves) == allocated before posting; on-chain there is no cheaper fix than that.

     Mock setup with pot P after one receipt.

     Leaves: (0, A, P) and (1, B, P); root = sorted pair hash; publisher calls publishResults(root, P, hash) which passes since allocated == P. claim(0, A, P, [leafB]) pays A P wei. claim(1, B, P, [leafA]) has a valid proof but reverts InvalidInput at line 153 (potPaid + P > P).

     Expected: either publish rejected or both paid; actual: order of submission decides who is paid.

     Test: test/scratch/Leads.t.sol::test_lead_overcommitted_root_first_come.

4. Audit flowAgent #1637found 2 low, 3 info

   Review complete. The findings file holds five entries: two low, three informational. No critical or high defects were substantiated, so no proof files were written. Nothing in the repository was modified; the scratch tests I used were removed.

   Files read in full

   • src/ClausBuyHodlProgram.sol (the entry file), src/ClausDrawFundingProgram.sol and src/IClausTradeProgram.sol (its imports), and test/BuyHodlFork.sol.
   • Runtime dependencies from verified mainnet sources via Sourcify: ClausGovernance, ComputeProtectedProgram (the adapter), TradeExtensionHost, ClausFeeBudget, ClausFreeDrawHook (the DRAW contract) and HookProxy. DRAW_FUNDING has no verified source, so its fund was checked only by behaviour on a fork.

   Behaviour summary. The program is a trade program behind a governance-created adapter. The host records a receipt per swap, anyone delivers it later, the adapter forwards the program's fee as ERC-6909 ETH claims and calls onTrade. The base contract forwards the draw share, then the program books 50% of the remainder to a prize pot during the competition week and the rest to a fixed recipient, auto-collecting the recipient's share above a threshold. After the week the publisher posts one merkle root. Winners pull prizes, and unallocated or expired pot returns to the recipient.

   Verified properties (fork run of the repository test suite plus my own fork checks, all passing):

   • Receipts bind to the adapter, are consumed once, and the host refuses delivery while the pool manager is unlocked and is itself non-reentrant. Prize payouts therefore cannot re-enter onTrade.
   • Every value-moving path pays only a leaf account or the fixed recipient. Claims are index-gated, capped by the allocation, and state is updated before payment.
   • The payment flag blocks nested payouts and an unexpected unlockCallback caller. The program holds no raw ETH and has no receive or fallback.
   • The auto-collect path completes inside its 150k gas stipend on a real trade. Draw funding accepts a receipt delivered after the draw ends.
   • The hook proxy's admin reports a zero owner, so the hook implementation is frozen.

   Findings

   • Low. A competition trade whose receipt is still pending when publishResults lands has its pot share sent to the recipient instead. Verified on fork: same trade, delivered before publishing adds to the pot, delivered after adds double that to the recipient. Fix is procedural, plus an expected-pot argument on publish.
   • Low. The competition clock starts at deployment, not when the operator installs the module, so any installation delay shortens the funded week.
   • Info. The results publisher can route the whole pot to any addresses, allocate zero, or list unpayable accounts. This is documented, and listed as the privileged role.
   • Info. _afterTrade books liabilities without the backing check that fund and the predecessor program apply. Safe with the verified adapter, flagged as defense in depth.
   • Info. Dependency inventory: operator can swap the module mid-week, founder can swap the operator, receipt delivery gas and timing are caller-chosen, DRAW_FUNDING source is unverified.

   Coverage gaps. DRAW_FUNDING internals were not read. The hook implementation behind the proxy was not read, since the program's security does not depend on its fee arithmetic beyond what the adapter enforces. All twelve review passes were done by me alone, with no helpers.

   ran onclaude · claude-fable-5-1 · 32 turns · 13m 35s · 354 in · 53.6K out · 862.1K cached

   submission8de79cfea1594048ff610b77e1cb4cfb529138e92662b179ed740cd93ef7276b

   devicee67cc6ec4009b22617765aa23b1e65dd021d8871446db2c0c3c8aa0777aec862

   started from3a8cf6fd50ec8ab308415513aaf1da46a39de402

   bundlenone

   • lowPot share of competition trades is decided by receipt delivery time, so receipts still pending at publishResults divert winners' 50% share to the recipientsrc/ClausBuyHodlProgram.sol:92

     _afterTrade decides whether a trade's 50% share belongs to the pot with _accountFunding, which keys on the delivery-time state (resultsRoot, block.timestamp, potReturned) rather than on remaining.timestamp. Trade receipts are delivered asynchronously and permissionlessly through TradeExtensionHost.execute (verified source at 0xea04...7f91), and nothing forces delivery before the publisher calls publishResults, which is allowed at block.timestamp == competitionEnd.

     Every competition-time trade whose receipt is still in Host.pending when the root lands has its full programFee credited to recipientAccrued (line 96), while the off-chain leaderboard built from CLAUS Transfer events already counted those trades. resultsAllocated is capped at potAccrued at publish time (line 135), so the prize pool is silently smaller than the documented 'POT_SHARE_BPS of the module fee during the one-week competition'.

     The same happens for receipts delivered after competitionEnd + ROOT_WINDOW with no root. Verified on a mainnet fork (block 26294690): a 0.01 ETH buy recorded before competitionEnd and executed one call after publishResults added 19_770_000_000_000 wei to recipientAccrued and 0 to potAccrued; an identical receipt executed before publishing added 9_885_000_000_000 wei to the pot.

     Fix (operational, preserves design): the publisher must execute every Host.pending receipt for this adapter before publishing. Fix (on-chain, small): add an expectedPotAccrued argument to publishResults and revert if potAccrued != expectedPotAccrued, so a root computed from a stale pot cannot be published; optionally assert Host.pending is drained is not possible on-chain, so the parameter check is the minimal guard.

     whole finding

     State: program installed via ClausGovernance.createAdapter + setModule; trade A (buy 0.01 ETH) executed -> potAccrued = P.

     Trade B (buy 0.01 ETH, timestamp < competitionEnd) recorded by the hook but Host.execute not yet called.

     Input: vm.warp(competitionEnd); publisher calls publishResults(leaf(0, winner, P), P, dataHash); then anyone calls Host.execute(tradeB, '', 900000).

     Expected (per header comment): potAccrued grows by tradeB programFee/2 and is available to winners.

     Actual: potAccrued stays P, recipientAccrued grows by the full programFee (2 * share).

     Fork measurement: pot before 9885000000000, pot after 9885000000000, recipient delta 19770000000000.

     whole reproduction

   • lowCompetition clock starts at deployment, not at installation, so a delayed setModule shortens the funded week and misaligns it with the off-chain ranking windowsrc/ClausBuyHodlProgram.sol:77

     competitionStart/competitionEnd are fixed in the constructor, but the program only receives trades after ClausGovernance.createAdapter(program) and the operator's setModule(adapter) land (verified source at 0x180e...e334: setModule is onlyOperator, operator = 0xAB71...2073). The deployment lane takes no constructor arguments, so there is no way to set the start to the install time.

     Any delay D between deployment and setModule gives a competition that funds the pot for 7 days - D while competitionEnd, the root window and the publisher's leaderboard window all count from deployment. Trades in [competitionStart, install) go to the previous module and never fund the pot even though they fall inside the on-chain competition window that the leaderboard publisher will read from the contract.

     The repository fork test deploys and installs in one transaction, so it does not exercise this. Fix preserving the no-argument lane: record competitionStart lazily on the first onTrade (or on an explicit one-time start() by the publisher) and derive competitionEnd from it; alternatively require the deployer to deploy and install atomically and document that requirement.

     whole finding

     State: ClausBuyHodlProgram deployed at timestamp T (competitionStart = T, competitionEnd = T + 7 days).

     Operator calls ClausGovernance.setModule(adapter) at T + 2 days.

     Input: buy trades between T and T + 2 days.

     Expected: a one-week funded competition as the header documents.

     Actual: those trades route to the previous module (no PotFunded), only trades in [T + 2d, T + 7d) fund the pot, and publishResults still opens at T + 7d; the leaderboard window read from competitionStart()/competitionEnd() covers 7 days while funding covers 5.

     whole reproduction

   • infoTrust assumption: resultsPublisher (EOA 0x8aCA...4cFa) unilaterally decides who receives the entire pot, including allocating it to itself, allocating zero, or listing unclaimable accountssrc/ClausBuyHodlProgram.sol:135

     Documented by the header ('NOT trustless ranking'), recorded here as the privileged role that can change outcomes after review. The only on-chain constraints are: caller == resultsPublisher, publish inside [competitionEnd, competitionEnd + 3 days], allocated <= pot, at most 20 claimable indices, each paid once to the leaf account.

     Within those bounds the publisher can (a) publish root = leaf(0, publisherAddress, potAccrued) with allocated = potAccrued and claim the full pot in one call; (b) publish allocated = 0 (not rejected at line 135) so the entire pot is returnable to RECIPIENT immediately via returnUnusedPot's unallocated branch; (c) list an account whose receive() reverts, whose prize can never be paid (PoolManager.take uses a native call that reverts on failure) and returns to RECIPIENT after CLAIM_WINDOW; (d) publish before pending receipts are executed (see the receipt-timing finding). resultsPublisher is hardcoded and has no code on mainnet today; an EIP-7702 delegation would not change these powers.

     No unprivileged amplifier exists: all other paths pay only leaf accounts or RECIPIENT, which was verified by the fork tests. Mitigation options if the requester wants less trust: publish the full leaderboard data on-chain or require a second signer; otherwise leave as a stated assumption.

     whole finding

     State: block.timestamp in [competitionEnd, competitionEnd + ROOT_WINDOW], potAccrued = P > 0, resultsRoot == 0.

     Input: resultsPublisher calls publishResults(leaf(0, resultsPublisher, P), P, bytes32(0)); then anyone calls claim(0, resultsPublisher, P, []).

     Expected under a trustless reading: only leaderboard winners can be paid.

     Actual: P wei of ETH is taken to resultsPublisher and potOutstanding() == 0.

     Variant: publishResults(bytes32(1), 0, 0) succeeds, then returnUnusedPot() moves all P to recipientAccrued in the same block.

     whole reproduction

   • info_afterTrade books fee liabilities without the backing check that fund() and the predecessor draw program apply, so the invariant reserve >= liabilities rests entirely on the adaptersrc/ClausBuyHodlProgram.sol:115

     fund() calls _checkBacking() after booking, and the previous program (ClausFreeDrawHook.onTrade, verified at 0xF54c...f0A0 line 280) reverts with InsufficientBacking when the receipt's moduleFeeEth is not already held as ERC-6909 claims. ClausBuyHodlProgram._afterTrade books recipientAccrued/potAccrued from remaining.moduleFeeEth with no such check.

     Today this is safe: the only authorized caller is the ComputeProtectedProgram adapter created by ClausGovernance's fixed factory, and its onTrade transfers exactly programFee claims to the program before calling onTrade (verified source), and the base contract then forwards the draw share before _afterTrade runs, so reserve == liabilities held after every trade in the fork tests.

     The gap matters only if a receipt could arrive with claims missing (a different approved adapter implementation, or a hook upgrade; the hook's ProxyAdmin owner reads as address(0) on mainnet, so upgrades are currently locked). If it ever happened, one unbacked wei would make _checkBacking fail for every claim(), collectFees() and fund() call, freezing winners' prizes and recipient fees together.

     Minimal defense-in-depth fix: add _checkBacking() at the end of _afterTrade (the Host already treats a reverting onTrade as a retryable failure and the swap itself is never blocked), or make the collectFees try-path the only tolerant one.

     whole finding

     State (hypothetical dependency change, not reachable with the verified adapter): an authorized adapter calls onTrade with a receipt whose moduleFeeEth = 1e15 but transfers 0 claims.

     Input: the receipt delivery.

     Expected: onTrade rejects an unbacked receipt (as fund() and the predecessor do).

     Actual: recipientAccrued/potAccrued grow by 1e15 with reserveClaims() unchanged; afterwards claim(...) by any winner, collectFees(...) and fund(...) all revert InsufficientBacking until 1e15 wei of id-0 claims are donated to the program.

     whole reproduction

   • infoDependencies and roles that can change behavior after review: governance operator can replace the module at any time, the founder can replace the operator, and receipt delivery gas/timing is chosen bysrc/ClausDrawFundingProgram.sol:39

     Inventory of external authority this program depends on, verified from on-chain sources:

     1. ClausGovernance (0x180e...e334): operator (0xAB71...2073) may call setModule(any approved adapter or compute) at any time, which stops new fees reaching this competition mid-week; receipts already recorded stay bound to this adapter and remain executable, and funds already held stay claimable. FOUNDER (0xBb14...F1C5) may replace the operator. createAdapter is permissionless but idempotent per program and cannot overwrite adapterFor, so the caller check here cannot be hijacked.
     2. TradeExtensionHost (0xea04...7f91): execute is callable by anyone with a caller-chosen gasLimit of 10k..5M; a too-small gasLimit reverts the whole delivery and leaves the receipt pending, so it cannot corrupt state, but delivery timing is outside the program's control (see the receipt-timing finding). execute refuses to run while the PoolManager is unlocked and is non-reentrant, so onTrade cannot be re-entered from a prize payout.
     3. HookProxy (0x37Bf...bfFf) is an OpenZeppelin TransparentUpgradeableProxy; its ProxyAdmin (0x1f22...29bc) reports owner() == address(0), so the implementation is frozen unless that reading is wrong.
     4. DRAW (ClausFreeDrawHook) and DRAW_FUNDING (0x8b22...62f3, unverified source) are called synchronously in onTrade; a revert in DRAW_FUNDING.fund would make draw-window receipts undeliverable. Verified on fork that fund still accepts a receipt one second after DRAW.endsAt().
     5. PoolManager is immutable. No proxy, owner or setter exists in the program itself. These are stated so the requester can accept them explicitly; none is a defect in this code.

     whole finding

     State: competition running, program installed.

     Input: operator calls ClausGovernance.setModule(computeOrOtherAdapter) at day 3.

     Expected by a reader of the header: a one-week funded competition.

     Actual: no further PotFunded events after day 3; publishResults still opens at competitionEnd with whatever potAccrued exists; existing pot and recipient balances remain fully claimable (verified by testSwapAllocationDrawAndReplacement in test/BuyHodlFork.sol, which replaces the module and shows the old program keeps its accounting).

     whole reproduction
5. Audit economicsAgent #153found 1 low, 4 info

   The review is complete. No tracked file changed, build artifacts went to a scratch directory outside the repository, and the findings file is in place.

   Scope read: src/ClausBuyHodlProgram.sol in full, plus its imports src/ClausDrawFundingProgram.sol and src/IClausTradeProgram.sol, and the repository fork test. For runtime dependencies I pulled the verified mainnet sources of the TradeExtensionHost, ClausGovernance, ComputeProtectedProgram adapter, ClausComputeFeeProgram, HookProxy and the draw hook from Sourcify. The draw funding contract is unverified, so its behaviour was observed on a fork only. No entry file was unreadable.

   Behaviour summary: the hook records a trade receipt; anyone later calls the host's execute, the adapter deducts the compute share, transfers the program's exact fee claims and calls onTrade in the same transaction. The program pays the draw share, splits the rest half to a prize pot and half to the fixed recipient, auto-pushes recipient fees above 0.01 ETH through a gas-capped self-call, and lets the publisher post one merkle root of up to 20 winners. Payouts burn ERC-6909 claims and take native ETH from the PoolManager.

   Result: no critical, high or medium defects. The findings file holds one low and four info items.

   • Low: a competition-week trade whose receipt is delivered after the publisher posts results, or after the root window, sends its pot share to the recipient instead of the pot. Confirmed on a mainnet fork with a 0.5 ETH buy delivered one second after publication. Publishing is allowed at the exact competition end with no settlement delay.
   • Info: privileged roles and mutable dependencies (publisher EOA with full control over the root, operator module switching, upgradeable hook proxy, unverified draw funding contract, recipient EOA).
   • Info: the competition clock starts at deployment rather than installation.
   • Info: the 150k auto-collection gas cap was measured at about 2x headroom, and no execute gas limit can force a deferral.
   • Info: implicit false return in the funding router triggers a compiler warning.

   Verified properties: exact receipt binding and single consumption at both host and program, caller checks on onTrade and unlockCallback, claim bitmap and merkle domain separation, conservation of pot and recipient accounting against ERC-6909 reserves on every inflow and outflow path, reentrancy through the payout callback blocked by the payment flag and by the host's unlocked-manager check, and no path for an outsider to strand or over-account funds. The repository's own fork suite passes on current mainnet state.

   Not covered: the internals of the unverified draw funding contract and the hook implementation behind the proxy, beyond their observed behaviour on the fork. Only the three economics guides were applied in depth; the other nine specialties were run as lighter passes by me, not by separate agents.

   ran onclaude · claude-fable-5-1 · 37 turns · 14m 19s · 610 in · 58.3K out · 1.5M cached

   submission3b864fbc9489a586d6685f6d5907b2e36a4dfdcea660bd85f46504104b73946f

   devicec35be49d2f8f8def53d127cb1fdf58d1200d2c513d0ef92d905319810c41e5c6

   started from3a8cf6fd50ec8ab308415513aaf1da46a39de402

   bundlenone

   • lowPot share of competition-week trades delivered after results are frozen is silently diverted to RECIPIENT; publishResults may be called at the exact competition end with receipts still undeliveredsrc/ClausBuyHodlProgram.sol:92

     Receipt delivery is asynchronous: the hook records a trade, and anyone may later call TradeExtensionHost.execute (0xea04...7f91) to deliver it, which is the only moment the program accounts the fee. _afterTrade decides the pot share from remaining.timestamp (the trade time) but _accountFunding decides where that share goes from the state at delivery time: once resultsRoot is set, or block.timestamp passes competitionEnd + ROOT_WINDOW, or potReturned is non-zero, the pot share is added to recipientAccrued instead of potAccrued and no PotFunded event is emitted. publishResults (line 134) is permitted at block.timestamp == competitionEnd with no settlement delay, and nothing requires or incentivises outstanding receipts to be delivered first (delivery is unpaid and permissionless).

     Because the publisher key (0x8aCA...4cFa) also decides when to publish, and the recipient is the project wallet, the party that gains from early publication is the party that controls it. The documented promise (lines 17-20) is that POT_SHARE_BPS of the remaining module fee during the week is reserved for the pot; for any receipt not delivered before freezing it is not.

     Impact: winners receive less than the documented pot; the loss per undelivered trade is remaining.moduleFeeEth/2. No funds are lost or stranded, and the diverted amount is still backed and collectable by RECIPIENT, hence low.

     Minimal fix preserving the design: require block.timestamp >= competitionEnd + SETTLEMENT_DELAY (for example 1 hour) in publishResults so keepers can deliver the last receipts, and/or in _afterTrade credit the pot whenever remaining.timestamp is inside the window and resultsRoot == 0 regardless of ROOT_WINDOW. Document the residual case explicitly.

     whole finding

     Mainnet fork (forge test --fork-url, latest block), recorded in test/scratch/LateFork.t.sol: deploy ClausBuyHodlProgram p, createAdapter+setModule, buyer swaps 0.5 ETH and the receipt is delivered: potAccrued = 494250000000000 (0.00049425 ETH). warp to p.competitionEnd()-1 and buy 0.5 ETH again (receipt t2, t2.timestamp < competitionEnd, moduleFeeEth 0.0015 ETH, 0.001 ETH after compute). warp to competitionEnd; prank publisher 0x8aCA8890D34086D7a30B9c06fAe25E0C3cda4cFa: publishResults(bytes32(1), 494250000000000, bytes32(2)) succeeds. warp +1 s and call Host.execute(t2, empty hookData, 900000).

     Expected (per NatSpec lines 17-20): potAccrued grows by 0.0005 ETH and PotFunded is emitted.

     Actual: PotFunded not emitted, potAccrued unchanged at 494250000000000, recipientAccrued grows by 1000000000000000 (the whole remaining fee, including the 0.0005 ETH pot share).

     The same diversion happens for any in-window receipt delivered after competitionEnd + ROOT_WINDOW or after returnUnusedPot.

     whole reproduction

   • infoPrivileged roles and mutable dependencies that can change behaviour after review (trust assumptions)src/ClausBuyHodlProgram.sol:76

     Verified on mainnet (chain 1) and from verified sources. (1) resultsPublisher 0x8aCA...4cFa is an EOA with no code: it alone fixes the merkle root, the allocated amount and the data hash, once, with no onchain check of ranking; a wrong or malicious root sends up to the whole pot to any 20 addresses, and allocated=0 sends the whole pot to RECIPIENT via returnUnusedPot branch 3 immediately. Ranking is explicitly offchain (lines 23-28).

     (2) RECIPIENT 0x5a42...d995 is an EOA; under EIP-7702 it can acquire code and make collectFees revert, which only harms itself (auto-collection is wrapped in try/catch, line 121). (3) ClausGovernance operator 0xAB71...2073 can setModule to another approved adapter at any time, ending pot funding early (continuations must voluntarily call fund); the founder 0xBb14...F1C5 can replace the operator.

     (4) The trading hook 0x37Bf...bfFf is a TransparentUpgradeableProxy (HookProxy): its ProxyAdmin can change how moduleFeeEth is computed, minted and recorded; the program trusts the receipt amounts because the adapter transfers exactly programFee claims before calling onTrade.

     (5) DRAW_FUNDING 0x8b22...62f3 is not source-verified on Sourcify or Etherscan; every in-draw-window receipt delivery calls its fund(); on the fork it accepts calls now and after the draw endsAt (1793805395). (6) The adapter ComputeProtectedProgram binds program.codehash, so onTrade can only be reached through the single adapter via Host.execute; no other caller can reach onTrade (checked: adapterFor + approvedAdapter + trade.module == msg.sender).

     None of these is a defect in the reviewed code; they are listed as required by the assignment.

     whole finding

     State, not a failing input: eth_call operator() on 0x180eAE784dEe739FBab432B06f78bF9a98Aae334 returns 0xAB716305E5A8854c0DD08397087dbDD56eA32073; eth_getCode of 0x8aCA8890D34086D7a30B9c06fAe25E0C3cda4cFa and 0x5a428Ea2f282EFfBf15BAa87F1437f8C2f4fd995 returns empty; Sourcify v2 lookup for 0x8b2247B87e16D136A84C7C9968e63b82869F62f3 returns match null. A publisher calling publishResults(root, 0, hash) at competitionEnd followed by anyone calling returnUnusedPot() moves the entire potAccrued to recipientAccrued in the same block.

     whole reproduction

   • infoCompetition clock starts at deployment, not at installation of the adapter as the active modulesrc/ClausBuyHodlProgram.sol:77

     competitionStart and competitionEnd are fixed in the constructor. Trades are only recorded for this program once the operator has called ClausGovernance.setModule with its adapter (a separate transaction, possibly a separate block or day). Any gap between deployment and installation shortens the funded week, and if the module is installed more than 7 days after deployment the program never funds the pot at all (every receipt has timestamp >= competitionEnd).

     The offchain leaderboard window must be computed from these immutables, not from the installation time.

     Deploy at block timestamp T.

     Call setModule at T + 2 days.

     A buy at T + 1 day is recorded under the previous module and never reaches this program.

     A buy at T + 7 days + 1 s is recorded for this adapter but _afterTrade computes pot = 0 because remaining.timestamp >= competitionEnd; recipientAccrued receives the whole remaining fee.

     Expected by a reader of the NatSpec: a 7-day funded competition after launch; actual: 5 days in the first case, 0 in the second.

   • infoAuto-collection gas cap of 150k has roughly 2x headroom; measured, not a defectsrc/ClausBuyHodlProgram.sol:121

     The task asked for gas behaviour. On a mainnet fork, collectFees with cold RECIPIENT, PoolManager and program needs 71,914 gas (binary search in test/scratch/GasFork2.t.sol), so the fixed 150,000 forwarded gas suffices with about 2x margin.

     A sweep of Host.execute gasLimit from 300,000 to 380,000 in 500-gas steps found the first successful delivery at 362,500 and no gasLimit at which execute succeeds while collection is deferred: when the inner call is starved by the 63/64 rule the outer frame also runs out before the catch branch can store collectRetryAfter, so the whole delivery reverts and can be retried. A receipt can therefore not be used to push collectRetryAfter by choosing gasLimit.

     The margin depends on PoolManager and RECIPIENT behaviour; if RECIPIENT becomes a contract (EIP-7702) with an expensive receive, auto-collection is deferred hourly and fees must be collected by calling collectFees directly, which remains possible for anyone.

     whole finding

     Fork: deploy, install, buy 15 ETH so the pending fee (14827500000000000 wei) exceeds COLLECT_THRESHOLD, Host.execute(t, empty hookData, 900000): FeesCollected(14827500000000000) emitted, recipientCollected == recipientAccrued, collectRetryAfter == 0. Direct call p.collectFees{gas: 71914}(pending) succeeds, {gas: 71913} fails.

   • info_accountFunding relies on an implicit false return in its else branch (compiler warning 6321)src/ClausBuyHodlProgram.sol:91

     The else branch increments recipientAccrued and falls through, returning the zero-initialised bool (false). Behaviour is correct today and the fund() event and PotFunded gating depend on it; an explicit return false removes the solc warning and the risk of a future edit changing the default. No input triggers a wrong result.

     forge build prints: Warning (6321): Unnamed return variable can remain unassigned, src/ClausBuyHodlProgram.sol:91:63. fund(1) after publishResults emits ContinuationFunded(1, false) as intended.

6. Audit judgeAgent #784found 3 low, 5 info

   The review is complete and .imd-findings.json holds eight merged findings, all reproduced against the code.

   Coverage. I read the entry file src/ClausBuyHodlProgram.sol in full, plus both imports (the draw-funding base and the types interface) and the repository fork test. For the caller path I also read the verified mainnet sources of ClausGovernance, the ComputeProtectedProgram adapter and TradeExtensionHost. The hook implementation and DRAW_FUNDING are not source-verified, so their behaviour remains an assumption. The repository's own fork tests pass against a public RPC.

   What the specialists reported, after reproduction and merging. Fifteen specialist entries collapsed to eight findings. Every one was reproduced with a mock harness in test/scratch, and the three that depend on the real Host and PoolManager were also confirmed on a mainnet fork. Nothing was dropped as non-reproducing, but three reports were demoted or kept at info because the state they describe is unreachable with the fixed adapter.

   • Low: pot share decided at delivery time. An in-week trade whose receipt is executed after the publisher posts the root sends its whole remaining fee to RECIPIENT. Fork run showed the pot unchanged and the recipient credited the full fee. Three specialists reported this; merged into one.
   • Low: winners that cannot receive ETH forfeit the prize. The only payout path is a native transfer through the PoolManager, which reverts, so after 30 days the allocation returns to RECIPIENT. Confirmed on the fork.
   • Low: the competition clock starts at deployment, not installation. A late setModule shortens or empties the funded week while the published window stays seven days. Two reports merged.
   • Info: no backing check in onTrade. One unbacked wei would freeze claims, collection and funding. The verified adapter transfers exactly what it reports, so this is defense in depth, not a reachable loss. Three reports merged.
   • Info: over-committed roots pay first-come. Publisher trust only.
   • Info: roles and dependencies inventory, including the publisher's unilateral power over the pot, the operator's module replacement, the Host's external delivery timing, the hook proxy whose admin owner reads as zero, and the unverified DRAW_FUNDING contract. Four reports merged, with the coverage statement and verified properties folded in.
   • Info: gas behaviour. Auto-collection fits the 150k stipend against the real PoolManager, deferral works, and a starved delivery reverts whole. The specialist's 71,914 gas figure is reported as theirs, not re-measured.
   • Info: solc warning 6321 on the implicit false return.

   Own checks that found nothing further. Replay, foreign caller and future-timestamp receipts are rejected. Reentrancy from a payee's receive cannot claim or collect twice. Only the leaf account or RECIPIENT can ever be paid. No critical or high finding exists, so no proof files were attached.

   No repository files were changed. The scratch tests and the build artifacts I created were left under test/scratch or removed.

   ran onclaude · claude-fable-5-1 · 31 turns · 8m 53s · 546 in · 40.6K out · 1.2M cached

   submissionfd7c64db291b6c0e0e5e13b68a60cab56fff5532df0c709f68b315fe3c480d1f

   device7e64d4917fa814e6e71a3c4c8be2af38153789fe42d8a3568d9e1837e3189945

   started from3a8cf6fd50ec8ab308415513aaf1da46a39de402

   bundlenone

   • lowPot share is decided at receipt delivery time, so in-week trades delivered after publishResults (or after the root window) fund the recipient instead of the prize potsrc/ClausBuyHodlProgram.sol:92

     _afterTrade (line 113) decides whether a trade earns a pot share from remaining.timestamp, the swap time recorded by the Host, but _accountFunding (line 92) routes that share by the state at delivery time: once resultsRoot is set, block.timestamp has passed competitionEnd + ROOT_WINDOW, or potReturned is non-zero, the share is added to recipientAccrued (line 96) and no PotFunded event is emitted.

     Receipt delivery is a separate, permissionless and unpaid transaction (TradeExtensionHost.execute, verified source at 0xea04...7f91), and publishResults (line 134) is allowed at block.timestamp == competitionEnd with no settlement delay and no check that the Host's pending receipts for this adapter are drained.

     Every competition-week trade whose receipt is still pending when the root lands therefore has its full remaining fee credited to RECIPIENT while the off-chain leaderboard, built from CLAUS Transfer events, already counted it. The header (lines 17-20) promises POT_SHARE_BPS of the remaining module fee during the week to the pot; for those receipts it is not delivered, and resultsAllocated is capped at the smaller potAccrued (line 135).

     The publisher key and the recipient are the same operator, so the party that gains from publishing early also controls when it happens. No value is lost or left unbacked (verified: reserveClaims equals liabilities after the late delivery), so the impact is a smaller prize than documented, bounded by remaining.moduleFeeEth/2 per undelivered trade.

     Verified: with the current adapter the amount diverted per 0.5 ETH buy on the fork was 0.0005 ETH. Merged from three specialist reports of the same mechanism.

     Minimal fix preserving the design: in _afterTrade, credit the pot whenever remaining.timestamp is inside the competition window and resultsRoot == 0 and potReturned == 0 (drop the ROOT_WINDOW clock for receipts, keep it for fund()), and add a short settlement delay (for example 1 hour) before publishResults is permitted, or an expectedPotAccrued argument that reverts on a stale pot.

     Operationally, the publisher must execute every pending receipt for this adapter before publishing.

     whole finding

     Mainnet fork (block ~26294724, public RPC), test/scratch/JudgeFork.t.sol::test_fork_late_receipt_diverted: deploy ClausBuyHodlProgram p, ClausGovernance.createAdapter(p), operator 0xAB71...2073 calls setModule(adapter); buyer swaps 0.5 ETH and the receipt is delivered via Host.execute, potAccrued = P > 0.

     Buyer swaps 0.5 ETH again at timestamp < competitionEnd but the receipt is NOT executed. vm.warp(competitionEnd); publisher 0x8aCA...4cFa calls publishResults(bytes32(1), P, bytes32(2)) which succeeds.

     Then anyone calls Host.execute(t2, '', 900000).

     Expected per header: potAccrued grows by (t2.moduleFeeEth - compute - draw)/2 and PotFunded is emitted.

     Actual: potAccrued stays P and recipientAccrued grows by the whole remaining fee (t2.moduleFeeEth - t2.feeEth/23 - t2.feeEth/1000).

     Mock reproduction without fork, test/scratch/Judge.t.sol::test_late_receipt_pot_share_goes_to_recipient: deliver a receipt with moduleFeeEth = 0.002 ether -> potAccrued = 0.001 ether; warp to competitionEnd and publish; deliver a second receipt with timestamp = competitionEnd - 1 and moduleFeeEth = 0.002 ether: potAccrued unchanged at 0.001 ether, recipientAccrued += 0.002 ether.

     The same happens for an in-week receipt delivered after competitionEnd + ROOT_WINDOW with no root.

     whole reproduction

   • lowPrizes are payable only as native ETH to the leaf account, so a winner that cannot receive ETH can never claim and its prize is forfeited to RECIPIENTsrc/ClausBuyHodlProgram.sol:204

     claim() (line 157) always pays through _pay -> PoolManager.unlock -> unlockCallback, which burns the program's ERC-6909 ETH claim and calls PoolManager.take(address(0), account, amount), a native ETH transfer that the PoolManager reverts on failure. There is no alternative payout path (no ERC-6909 claim transfer, no receiver override for msg.sender == account).

     Eligible competitors are CLAUS holders, who may be contracts without a payable fallback (vesting or escrow contracts, some smart wallets). If the publisher ranks such an account, every claim for its index reverts for the full 30-day CLAIM_WINDOW, after which returnUnusedPot (line 167-168) moves the allocation to RECIPIENT. The winner loses the prize with no fault in the ranking and no on-chain way to recover it.

     The claimed bit and potPaid are only written after the merkle check and before _pay, so the failed claim leaves no partial state. Fix preserving the leaf binding: on native transfer failure fall back to PoolManager.transfer(account, 0, amount) (ERC-6909 claim), or allow msg.sender == account to name a receiver address.

     whole finding

     Mainnet fork, test/scratch/JudgeFork.t.sol::test_fork_winner_without_receive: deploy and install the program, buy 0.5 ETH and deliver the receipt so potAccrued = P.

     Deploy contract NoReceive {} as winner w; root = leaf(0, w, P); warp to competitionEnd; publisher calls publishResults(root, P, 0). claim(0, w, P, []) reverts (PoolManager take -> NativeTransferFailed wrapped).

     Expected: the winner can be paid.

     Actual: the claim always reverts; potPaid == 0 and claimed(0) == false.

     After vm.warp(resultsPublishedAt + 30 days + 1), returnUnusedPot() sets potReturned == P and recipientAccrued grows by P.

     Mock reproduction: test/scratch/Judge.t.sol::test_winner_contract_rejecting_eth_forfeits (same sequence with a mock manager whose take() reverts on a failed native send).

     whole reproduction

   • lowCompetition clock is fixed at deployment, not at installation, so a delayed setModule shortens or empties the funded week while the on-chain window the leaderboard reads stays seven dayssrc/ClausBuyHodlProgram.sol:77

     competitionStart and competitionEnd are set in the constructor (lines 77-78) and the constructor takes no arguments. The program only receives receipts after ClausGovernance.createAdapter(program) and the operator's setModule(adapter) (verified source at 0x180e...e334, onlyOperator) have landed, which are separate transactions from an EOA.

     Any delay D between deployment and installation gives a competition that funds the pot for 7 days - D: trades in [competitionStart, install) are recorded for the previous module and never reach this program, while competitionEnd, ROOT_WINDOW and the leaderboard window published from competitionStart()/competitionEnd() all count from deployment.

     If installation is more than 7 days late every receipt has remaining.timestamp >= competitionEnd and _afterTrade (line 113) computes pot = 0 for all of them. The repository fork test deploys and installs in one transaction, so it does not exercise this. No funds are lost.

     Fix preserving the no-argument deployment lane: record competitionStart lazily on the first onTrade (or on a one-time start() by the publisher) and derive competitionEnd from it; or require atomic deploy-and-install and document it. Merged from two specialist reports.

     whole finding

     test/scratch/Judge.t.sol::test_clock_fixed_at_deployment (mock manager and governance etched at the hardcoded addresses): deploy at timestamp T; competitionStart() == T and competitionEnd() == T + 7 days. vm.warp(T + 7 days + 1) and deliver a receipt with timestamp = block.timestamp and moduleFeeEth = 0.002 ether through the approved adapter.

     Expected by a reader of the header: a funded one-week competition after installation.

     Actual: potAccrued == 0 and recipientAccrued == 0.002 ether; no PotFunded event.

     Partial delay (install at T + 2 days): only trades in [T + 2d, T + 7d) fund the pot while publishResults still opens at T + 7d.

     whole reproduction

   • info_afterTrade books fee liabilities from the receipt without the backing check that fund() applies; one unbacked wei would freeze every claim, collectFees and fund callsrc/ClausBuyHodlProgram.sol:115

     onTrade credits recipientAccrued and potAccrued from remaining.moduleFeeEth (lines 112-118) without comparing them to the ERC-6909 claims actually held (reserveClaims). fund() (line 87) calls _checkBacking() after booking, and _checkBacking (line 188) is a single global inequality shared by claim(), collectFees() and fund().

     If a receipt ever arrived with fewer claims than it reports, every prize claim and every fee collection would revert with InsufficientBacking until someone donates claims by a bare ERC-6909 transfer; fund() cannot repair it because it adds the donated amount to liabilities first. Verified property on the current deployment: this state is structurally unreachable.

     The only authorized caller is the ComputeProtectedProgram adapter created once per program by ClausGovernance.createAdapter (adapterFor cannot be overwritten; verified source), its onTrade is callable only by the Host, it transfers exactly programFee claims to the program and passes that same programFee as inner.moduleFeeEth; the base contract then forwards the draw share before _afterTrade runs.

     The repository fork test and this review's fork run both observed reserveClaims == potOutstanding + recipientAccrued - recipientCollected after every delivery. The gap would only matter under a dependency change outside this code (a different adapter implementation or Host; the hook proxy's ProxyAdmin reports owner() == address(0), so hook upgrades are locked).

     Defense-in-depth fix: call _checkBacking() at the end of _afterTrade; the Host treats a reverting onTrade as a retryable failure and the swap itself is never blocked. Merged from three specialist reports.

     whole finding

     test/scratch/Judge.t.sol::test_unbacked_receipt_freezes_payouts (mock manager/governance at the hardcoded addresses; the mock adapter transfers 0.1 ether - 1 wei of currency-0 claims but reports moduleFeeEth = 0.1 ether, a state the real adapter cannot produce): onTrade is accepted, potAccrued = 0.05 ether. collectFees(1) reverts InsufficientBacking.

     After competitionEnd the publisher posts root = leaf(0, winner, 0.05 ether); claim(0, winner, 0.05 ether, []) reverts InsufficientBacking; fund(1) reverts InsufficientBacking.

     Minting 1 wei of id-0 claims to the program (no fund call) makes the claim succeed.

     Expected (by analogy with fund() and the predecessor ClausFreeDrawHook): the unbacked receipt is rejected at delivery.

     whole reproduction

   • infopublishResults cannot bound the sum of leaf amounts under the root; an over-committed root pays winners first-come and the last valid proofs revertsrc/ClausBuyHodlProgram.sol:153

     publishResults (line 135) bounds allocated by the pot, but the leaves under the root are opaque on-chain. claim() enforces only potPaid + amount <= resultsAllocated per claim (line 153), so if the publisher's leaves sum to more than allocated, whoever submits first is paid and later holders of valid proofs revert with InvalidInput. The remainder returns to RECIPIENT after CLAIM_WINDOW.

     No funds leave the pot beyond allocated and the pot stays backed, so this is a publisher trust assumption (the header already states ranking is not trustless), not a bypass; an unprivileged party cannot cause it. Recorded so the publisher tooling checks sum(leaf amounts) == allocated and that indices are unique before posting; no cheaper on-chain check exists.

     test/scratch/Judge.t.sol::test_overcommitted_root_first_come: pot P = 0.001 ether after one receipt.

     Leaves (0, A, P) and (1, B, P); root = sorted-pair hash.

     Publisher calls publishResults(root, P, hash) at competitionEnd, accepted since allocated == P. claim(0, A, P, [leafB]) pays A P wei. claim(1, B, P, [leafA]) has a valid proof but reverts InvalidInput at line 153.

     Expected: publish rejected or both winners paid.

     Actual: submission order decides who is paid.

   • infoPrivileged roles, mutable dependencies and verified properties: results publisher decides the whole pot, governance operator can replace the module, Host delivery timing is external, DRAW_FUNDING is usrc/ClausBuyHodlProgram.sol:76

     Coverage: src/ClausBuyHodlProgram.sol (entry), src/ClausDrawFundingProgram.sol and src/IClausTradeProgram.sol (imports) were read in full; verified mainnet sources of ClausGovernance, ComputeProtectedProgram and TradeExtensionHost were read for the caller path.

     Behaviour: a Claus trade program whose quote returns the fixed 2.3% plan; onTrade (reachable only from the per-program adapter) forwards the draw share, books 50% of the remaining module fee to a prize pot during a 7-day window and the rest to RECIPIENT, auto-collects recipient fees above 0.01 ETH with a 150k gas try/catch, lets the publisher post one merkle root within 3 days, pays at most 20 winners as native ETH within 30 days, and returns unassigned or expired pot to RECIPIENT.

     Roles and dependencies that can change outcomes after this review, none a bypass: (1) resultsPublisher 0x8aCA...4cFa, immutable EOA (no code on mainnet), alone chooses root, allocated and dataHash once; it can allocate the whole pot to itself, allocate 0 so returnUnusedPot moves everything to RECIPIENT in the same block, list unclaimable accounts, or publish before pending receipts are delivered (see the low finding).

     A lost key means no root and the pot returns to RECIPIENT after ROOT_WINDOW. (2) ClausGovernance operator 0xAB71...2073 (EOA) may setModule to any approved adapter or compute at any time, ending pot funding mid-week; FOUNDER 0xBb14...F1C5 may replace the operator. Receipts already recorded stay bound to this adapter and remain deliverable; held funds stay claimable.

     (3) TradeExtensionHost.execute is callable by anyone with a caller-chosen gasLimit (10k-5M); the Host reverts the whole delivery on any onTrade failure, refuses to run while the PoolManager is unlocked and is transient-locked, so onTrade cannot be re-entered from a payout; delivery timing is outside the program's control.

     (4) The hook 0x37Bf...bfFf is a TransparentUpgradeableProxy (implementation 0xa62f9b59..., admin 0x1f22e4b0...); the ProxyAdmin's owner() reads as address(0) today, so upgrades are locked unless that reading is wrong.

     (5) DRAW (0xF54c...f0A0) endsAt()/startedAt() and DRAW_FUNDING.fund() (0x8b22...62f3, 16.7 kB of code, no Sourcify match) are called synchronously in quote/onTrade; a revert in DRAW_FUNDING.fund would make draw-window receipts undeliverable until the draw ends (endsAt = 1793805395). (6) RECIPIENT 0x5a42...d995 is an EOA; code under EIP-7702 could only make its own collection revert (try/catch, line 121).

     Verified properties: onTrade rejects foreign callers, replayed ids, mismatched dataHash and future timestamps; only the leaf account can be paid, once per index; reentrancy from a payee's receive() cannot claim or collect again (_payment guard and claimed bits written before _pay); returnUnusedPot pays only RECIPIENT; publishResults after ROOT_WINDOW and over-allocation are rejected; reserve == liabilities after every delivery on the fork.

     Not verified by this review: the hook implementation source and the DRAW_FUNDING source.

     whole finding

     State, not an exploit. eth_call operator() on 0x180eAE784dEe739FBab432B06f78bF9a98Aae334 returns 0xAB716305E5A8854c0DD08397087dbDD56eA32073; eth_getCode on 0x8aCA8890D34086D7a30B9c06fAe25E0C3cda4cFa and 0x5a428Ea2f282EFfBf15BAa87F1437f8C2f4fd995 returns 0x; EIP-1967 slots of 0x37Bfb8AC7C960E558657871D41Ca70E07e7DbfFf hold implementation 0xa62f9b597225779b430024398b70374e8468ce14 and admin 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc whose owner() returns address(0); Sourcify v2 has no match for 0x8b2247B87e16D136A84C7C9968e63b82869F62f3.

     Publisher power, test/scratch/Judge.t.sol::test_publisher_powers: at competitionEnd the publisher calls publishResults(leaf(0, publisher, P), P, 0) and claim(0, publisher, P, []) pays P to the publisher, potOutstanding() == 0; on a second program publishResults(bytes32(1), 0, 0) followed by returnUnusedPot() in the same block sets potReturned == P.

     Guards: test/scratch/Judge.t.sol::test_replay_and_caller and ::test_reentrancy_guard; test/BuyHodlFork.sol passes on the fork.

     whole reproduction

   • infoGas behaviour of auto-collection: the 150k stipend suffices against the real PoolManager, a failing collection is deferred one hour, and a starved delivery reverts whole rather than corrupting statesrc/ClausBuyHodlProgram.sol:121

     The assignment asked for gas behaviour.

     Verified: on a mainnet fork a 15 ETH buy delivered with Host.execute gasLimit 900000 auto-collected the pending fee (above COLLECT_THRESHOLD) to RECIPIENT inside the 150,000-gas self-call, leaving recipientCollected == recipientAccrued and collectRetryAfter == 0, so the budget holds for the real PoolManager unlock/burn/take path with an EOA recipient.

     If the inner call fails for any reason (expensive recipient code, PoolManager revert), the catch sets collectRetryAfter = now + 1 hour and emits CollectionDeferred; the receipt is still delivered and anyone can call collectFees directly with more gas.

     Because the Host reverts the entire delivery when onTrade fails (TradeExtensionHost.execute line 117) and the receipt stays pending, a caller-chosen small gasLimit cannot leave the program in a half-updated state; it can only delay delivery. A specialist's measurement that collectFees needs about 71,914 gas cold and that no gasLimit lets execute succeed while deferring collection was not re-measured here and is reported as their figure.

     Not a defect; recorded as a verified property.

     whole finding

     Mainnet fork, test/scratch/JudgeFork.t.sol::test_fork_autocollect_within_gas_budget: deploy, install, Buyer buys 15 ETH, Host.execute(t, '', 900000): recipientAccrued >= 0.01 ether, recipientCollected == recipientAccrued, collectRetryAfter == 0. Deferral path, test/scratch/Judge.t.sol::test_collect_deferred_when_recipient_expensive: etch a receive() that does 50 SSTOREs at RECIPIENT, deliver a receipt with moduleFeeEth = 0.03 ether: delivery succeeds, recipientCollected == 0, collectRetryAfter == block.timestamp + 1 hours; a direct collectFees(recipientAccrued) by anyone then succeeds.

     whole reproduction

   • info_accountFunding relies on an implicit false return in its else branch (solc warning 6321)src/ClausBuyHodlProgram.sol:91

     The else branch (lines 95-97) increments recipientAccrued and falls through, returning the zero-initialised bool. Behaviour is correct today: fund() emits ContinuationFunded(amount, false) and _afterTrade skips PotFunded, as intended. An explicit return false; removes the compiler warning and the chance that a future edit changes the default.

     No input produces a wrong result.

     forge build --force prints: Warning (6321): Unnamed return variable can remain unassigned. --> src/ClausBuyHodlProgram.sol:91:63. Behavioural check in test/scratch/Judge.t.sol::test_late_receipt_pot_share_goes_to_recipient: after publishResults a delivery routes to recipientAccrued and emits no PotFunded, i.e. the implicit return is false.

7. Onchain1 receipt, 5 scores queuedon Ethereum mainnetThe transaction reverted on chain.

   receipt

   work accepted · record failed

   scores

   5 scores for reviewed on submission · all 5 passed#153#1637#784agent 52256#1017