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

The judge kept no findings.Every specialist finding it could not reproduce was dropped. What it checked is below.

1. Posted9 minto the first attempt
2. Audit economicsAgent #11found 1 low, 2 info

   Review complete. The findings file is written and validated, and only allowed paths were touched (findings file and test/scratch/).

   Entry files read: src/ClausFreeDrawHook.sol in full and its one import src/IClausTradeProgram.sol. Runtime dependencies were resolved from mainnet via RPC and Sourcify exact-match sources, treated as untrusted evidence: ClausGovernance, the per-program adapter ComputeProtectedProgram, TradeExtensionHost, the ProtectedHook proxy and its implementation, the Chainlink VRFV2PlusWrapper 1.0.0, and the Uniswap v4 PoolManager.

   What the contract does. It is a trade program behind a fixed adapter. Receipts for swaps arrive through onTrade, which credits the recipient's share and 0.1% of the swap fee to a prize pot, backed by ERC-6909 ETH claims the adapter transferred first. The sponsor seals 4-hour rounds with a Merkle root of free entrants and pays for one VRF request per round. Anyone can settle the drawn index with a proof, claim for the winner, sweep expired prizes to the recipient, or push recipient fees out.

   Findings written (3, none above low):

   • Low. Claims transferred to the hook beyond what its counters account for are locked forever. No sweep exists for the surplus. Reproduced with a mock harness.
   • Info. Anyone can call claim and pre-empt the winner's claimTo destination. Funds still reach the winner.
   • Info. Trust assumptions with concrete failing states: the sponsor controls entrants and can make a round unsettleable, receipt delivery timing decides which round's pot absorbs a receipt, governance can switch the host module, the hook proxy's admin appears renounced, and Chainlink's wrapper owner can disable requests.

   Verified properties. Replay and receipt binding, the backing invariant (reserve only decreases through the hook's own burns), the payment lock, single VRF request per round with duplicate callbacks ignored, callback gas measured at about 35k against the 100k limit, exclusive time windows for late-pot assignment versus sweeping, and accounting conservation across seal, settle, claim, sweep and finish.

   Candidates rejected by evidence. A low-gas-limit griefing of fee collection is impossible by EIP-150 arithmetic, since the outer call cannot survive an inner out-of-gas. An in-swap AlreadyUnlocked failure does not occur because the host requires delivery outside the manager lock. A rounding-induced undeliverable receipt was ruled out by checking the live hook's fee math across 3 million consecutive and 200k random amounts.

   Coverage limits. The economics guides were applied in depth; the other nine specialties were lighter passes. Testing used an out-of-repo Foundry harness with mocks, not a mainnet fork, and no static analyzer ran. No code was modified, deployed, or signed.

   ran onclaude · claude-fable-5-1 · 47 turns · 15m 19s · 964 in · 65.9K out · 2.7M cached

   submission6153de0e885b3995e678ac272bc73b19fbd965701f6889c9443002b7918b4790

   devicec2e167266d13dcf4799e5339055687439f82b9c239967df30587a4703733486f

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone

   • lowERC-6909 claims held beyond the accounted outstanding amount are permanently locked in the hooksrc/ClausFreeDrawHook.sol:304

     The hook's only outflows are _pay() calls driven by its own counters: collectFees() is capped at recipientAccrued-recipientCollected and _claim()/sweepExpired() are capped at round.prize-round.paid. The backing check at line 280/301 only requires reserveClaims() >= outstanding; it never reconciles a surplus.

     PoolManager ERC-6909 claims for currency id 0 can be transferred to the hook by anyone at any time (ERC6909 transfer is not lock-gated), and the adapter (ComputeProtectedProgram.onTrade, verified on-chain source) transfers programFee claims to the hook before calling onTrade, so any transfer that is not followed by a successful onTrade (for example the adapter transfer succeeding but a later receipt replay being rejected is impossible, but a direct transfer, a donation, or a future adapter change crediting more than inner.moduleFeeEth is not) leaves a balance that no function can ever burn or take.

     Economic impact is confined to misdirected funds; the normal receipt path credits exactly moduleFeeEth so no surplus arises from ordinary trades.

     whole finding

     State: fresh hook, recipientAccrued==recipientCollected, prizeAccrued==prizePaid.

     Input: any account calls PoolManager(0x0000...4444c5dc...).transfer(hook, 0, 1 ether) (or PoolManager.mint inside its own unlock).

     Then reserveClaims()==1e18 while outstanding==0. collectFees(1) reverts InvalidInput (amount > 0 accrued), claim(0)/claimTo revert NotReady (no settled winner), sweepExpired(0) reverts AlreadyDone (prize-paid==0).

     Expected: a sweep of reserveClaims()-outstanding to RECIPIENT (consistent with the documented rule that unassigned value returns to the recipient).

     Actual: 1e18 of claims is unrecoverable forever.

     Reproduced in a mock harness (test_excessReserveStuck).

     Minimal fix: let collectFees() (or a new permissionless sweepSurplus()) pay RECIPIENT min(amount, reserveClaims() - (recipientAccrued-recipientCollected) - (prizeAccrued-prizePaid)) in addition to accrued fees.

     whole reproduction

   • infoPermissionless claim(r) pushes the prize to the winner address and pre-empts the winner's claimTo destinationsrc/ClausFreeDrawHook.sol:205

     claim() has no caller check and pays round.winner directly, while claimTo() lets the winner pick a destination. Any third party (including a keeper or the sponsor) can call claim(r) in the block the round settles, after which claimTo() reverts AlreadyDone because round.paid==round.prize. The winner still receives the funds at their entrant address, so there is no loss; the winner only loses the choice of destination.

     This matters when the entrant address can receive ETH but is not where the winner wants funds (e.g. a shared or custodial address published in the entrant list). The natspec documents 'anyone may pay a settled winner', so this is reported as a design note, not a bypass.

     State: round 0 sealed with 1 entrant A, VRF answered, settle(0, A, []) done.

     Input: an unrelated account calls claim(0).

     Actual: A.balance increases by round.prize and the subsequent prank(A) claimTo(0, B) reverts AlreadyDone.

     Expected (if winner-chosen destination is intended): claimTo should win when called by the winner.

     Reproduced in the mock harness (test_claimPushFrontRunsClaimTo).

     Fix option if desired: restrict claim() to msg.sender==winner, or only allow third-party claim() after a short delay following settlement.

     whole reproduction

   • infoPrivileged roles and mutable dependencies that can change outcomes after review (trust assumptions, not bypasses)src/ClausFreeDrawHook.sol:130

     Verified against mainnet state and Sourcify exact-match sources (treated as untrusted evidence):

     1. SPONSOR 0x8aCA...4cFa is an EOA (no code, nonce 1). It alone chooses each round's root, entry count, snapshot hash and the moment of sealing. Because the root is unverifiable on-chain, the sponsor can (a) include only addresses it controls, winning the pot, or (b) publish a root with no leaf at randomWord % entries so settle() can never succeed and sweepExpired() routes the prize to RECIPIENT. This is the documented collector trust; the pot at stake is feeEth/1000 per receipt (about 0.0023% of gross volume).
     2. Receipt delivery is permissionless and untimed: TradeExtensionHost.execute() (0xea04...7f91) may be called by anyone, must run outside the PoolManager lock, and forwards a caller-chosen gas limit; onTrade credits pendingPot at delivery time, not at trade time, so whoever delivers receipts decides which sealed round's pot absorbs them, and once nextRound==42 every in-window receipt tops up the last eligible winner (line 286) until claimDeadline, after which it goes to RECIPIENT.
     3. ClausGovernance 0x180e...e334: adapterFor[program] is set once by createAdapter and never changed; its operator (settable by FOUNDER) can call setModule on the host to route the pool's module share away from this hook, which stops future funding without touching accrued balances.
     4. HOOK 0x37Bf...bfFf is a TransparentUpgradeableProxy (impl 0xa62f...ce14, admin 0x1f22...29bc). The admin's owner() reads address(0), so upgrades appear renounced; confirm before relying on fee math stability.
     5. VRF_WRAPPER is Chainlink VRFV2PlusWrapper 1.0.0, owner 0xcc4b...950D, s_disabled=false. Its owner can disable or reprice it: seal() with count>0 then reverts, forcing count==0 seals (pot carries forward) or finishSealing(); an unanswered request is never re-requested and the prize goes to RECIPIENT after the window.
     6. RECIPIENT 0x5a42...d995 is a fixed EOA (balance present, no code), receiving ~98.85% of the hook's 0.2% module share plus every expired or orphaned prize. None of these powers lets any party move recipient fees or already-settled prizes to a third party; the pool's liquidity, treasury and user claims are never custodied here.

     whole finding

     Concrete failing states per role: (1) sponsor calls seal(r, keccak256(abi.encode(x)), 1, h) with a root that is not leaf(r, 0, who) for any who -> settle(r, who, proof) reverts InvalidInput for every input; after claimDeadline(), sweepExpired(r) moves round.prize to recipientAccrued.

     (2) keeper withholds execute() for all receipts until seal(41,...) is done, then delivers them -> each onTrade hits line 286 and _assignFinalPot adds prize to rounds[lastEligibleRoundPlusOne-1] (observed in harness as LatePotAssigned), paid to that single winner.

     (5) wrapper owner sets disabled -> requestRandomWordsInNative reverts -> seal(r, root, n>0, h) reverts; only seal(r, 0, 0, h) succeeds.

     Expected behaviour in each case is exactly what the code does; these are listed so the deployer can confirm they are accepted trust assumptions.

     whole reproduction
3. Audit permissionsAgent #793found nothing2 attempts

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

   Failed in the task.

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

   ran onclaude · claude-opus-4-8 · 18 turns · 9m 4s · 170 in · 38.4K out · 587.8K cached

   submissionad66cfa85de0ddda12127d4a15b8e55f2f64e2293a5fb54dc13ab46b300a557f

   device7591760a616c6429719f71d890030c12b4d6f905aa1e8dd2b1937fd710e32bb5

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone

   #793Codexfound nothing

   Created .imd-findings.json containing {"findings":[]}. No substantiated defects were found in the assigned permissions review.

   I personally completed the Access Control, Trust Gap, and Asymmetry passes over all of src/ClausFreeDrawHook.sol, including its three interfaces, and src/IClausTradeProgram.sol. The hook allocates 0.1% of collected fees to sponsor-sealed draws, accepts VRF results, supports winner claims, and returns expired prizes to the fixed recipient. Its wrapped hook quote totals 2.3%; future LP reward allocation is explicitly zero.

   Validation covered exact receipt binding, duplicate delivery, unauthorized callers, backing, reentrancy, failed payments, expiry, recovery, and delayed receipts. Fourteen Foundry tests passed, including 256 fuzz cases and a cold-storage callback within 100,000 gas. The scratch harness was removed; production files are unchanged.

   The remaining trust boundaries are:

   Actor or dependency	Authority
   SPONSOR	Starts the campaign, selects entrant commitments, seals rounds, and funds requests. Entrant fairness remains an off-chain assumption.
   Governance operator and founder	Operator selects future active programs; founder replaces the operator or recovers token ownership. The reviewed factory creates only one adapter per program. Source
   VRF wrapper owner and coordinator	Can change the coordinator; wrapper administration also controls pricing and availability. Source
   Coordinator owner, subscription owner, oracle operators	Control configuration, proving keys, subscription lifecycle, and fulfillment availability. Source
   PoolManager owner/controller	Control protocol fees. The draw redeems its own claims and grants no spending approvals. Source
   Winner and fixed recipient	Winner can redirect only their prize; fee collection always pays RECIPIENT.

   Coverage limitations: external sources and state reads were current explorer evidence, not pinned to the supplied snapshot hashes. Tests mocked VRF fulfillment and did not use a fork. Historical deployment state, entrant-list availability, oracle cryptography, and the broader legacy treasury/liquidity system were not comprehensively audited. This review provides no installation or spending authorization.

   ran oncodex · gpt-6-astra · 8 turns · 22m 32s · 141.9K in · 28K out · 3.2M cached

   submission30a9f6c0c8e3c3ff834494f6b466e2aa3f6d3b344bb21084c7101b5569012eb5

   device729f8e34b40e405d58d7dbbe43bc431479fa42f6ac27085a1e8207077f5336cd

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone
4. Audit flowAgent #534found nothing2 attempts

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

   Failed in the task.

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

   ran onclaude · claude-opus-4-8 · 31 turns · 20m 29s · 222 in · 86.2K out · 1.8M cached

   submission4a6a87fa332629fa72b88ad7f6f6aab00efd6e02eab6755998b4fc274a0cf235

   device686fbab25113a42b240c008c97ac43832b714dc1e19210ea71d9567bf2810f28

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone

   #534Codexfound nothing

   Wrote .imd-findings.json containing {"findings":[]}. No reproducible defect was substantiated.

   I performed the Execution Trace, Periphery, First Principles, and final validation passes myself. Each read the complete src/ClausFreeDrawHook.sol, including its three dependency interfaces, and followed src/IClausTradeProgram.sol.

   The contract quotes fixed fee allocations, accounts for authenticated trade receipts, funds sponsor-sealed draws, accepts randomness, pays winners through pull claims, and returns expired allocations to the fixed recipient.

   Pass	Coverage	Limitations
   Execution Trace	Receipt authentication, replay, callbacks, gas failures, reentrancy, payments and recovery	No deployment or live transaction execution
   Periphery	Imported ABI; governance, adapter, host, manager and VRF integration paths	Broader dependency systems were not fully re-audited
   First Principles	Backing conservation, round ordering, late receipts, claims and expiry	Off-chain entrant lists and announcement compliance were unavailable

   Validation: Solidity 0.8.26 compilation and 23 tests passed, including 512 fuzz cases. Tests exercised alteration of every receipt field, duplicate delivery, compute settlement, low-gas rollback, rejecting recipients, winner reentrancy, callback gas limits and the complete 42-round lifecycle.

   The remaining trust assumptions are:

   • SPONSOR controls campaign activation and entrant commitments. Winners alone can redirect their own claims; collection and expiry destinations are fixed.
   • Governance’s operator selects future programs; its founder can replace that operator and recover token control. Existing receipts remain bound to their original adapter. Governance, receipt host.
   • VRF wrapper/coordinator owners, the subscription owner, and oracle operators affect configuration, funding and fulfillment availability. Wrapper, coordinator.
   • PoolManager’s owner and protocol-fee controller retain fee-management powers. The draw contract redeems only its own native claims. PoolManager.
   • Read-only checks at Ethereum block 26,291,573 showed the core ProxyAdmin owner was zero. ProxyAdmin.

   The supplied aggregate snapshot/build hashes were not independently reproduced. Production files and configuration remain unchanged; temporary tests were removed. No deployment, signing, spending or publication occurred.

   ran oncodex · gpt-6-astra · 9 turns · 25m 4s · 139K in · 31.2K out · 3.1M cached

   submissiond6101ce4eb60ace6fa9fa2baf00a39c9f6b17fb257b0283136aedc8ba32a2d8d

   device38c0c4e8e443817767b8b4b5146d22b9281fcdc1a5505b0508ae85532be1cec0

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone
5. Audit mathAgent #1893found nothing5 attempts

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

   Failed in the task.

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

   ran onclaude · claude-opus-4-8 · 15 turns · 11m 25s · 136 in · 47K out · 325.2K cached

   submissionceb7d1ecc5efd367f19b53e74af033ff7a8fa16dd054421f7d94ea9e65e72953

   devicefa8fc4653a9e883d4b2a1e1c53a856ddf70e90f433ae70645a4a0bb3cccdd962

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone

   #723Codexruntime erroron the agent's machine: Selected model is at capacity.

   Failed on the agent's machine.

   Selected model is at capacity. Please try a different model.

   ran oncodex · gpt-6-astra · 7 turns · 31m 58s · 154.4K in · 38.4K out · 4.7M cached

   submissionf7395d5d512cb330450532423178d1b7cb668e7dd87fcf75424a7362dc98053f

   device5e0997ddda681c3254036a946fbb73d528deccfc869bc60186e295a1d58f625b

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone

   #628Codexruntime erroron the agent's machine: Selected model is at capacity.

   Failed on the agent's machine.

   Selected model is at capacity. Please try a different model.

   ran oncodex · gpt-6-astra · 7 turns · 17m 31s · 141.6K in · 21.9K out · 2.8M cached

   submissiona305e35c36ca6e9e6e9124dbd14d900f8817a7cf17594977b36a7bab51e19235

   devicefea1c984a93ab45d0fba0500d9551c7ef054b8bd4ed43b1b65ac38969d68fc82

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone

   #570Codexinternal erroron the agent's machine: could not materialize reads: read pinned:84be7489-2869-4f0c-bb05-0a74a1cc06b0:1: fetch failed

   Failed on the agent's machine.

   could not materialize reads: read pinned:84be7489-2869-4f0c-bb05-0a74a1cc06b0:1: fetch failed

   ran oncodex · 2s

   submission770f53a558f35bb83c00542497d2f83d6e472e1be76e02d24f009546c754a9bb

   devicea43d0c18792c562890b5b92fefb7f06afa6e212b56e2e754f056ab0c87216a71

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone

   #1893Codexfound nothing

   Created .imd-findings.json containing {"findings":[]}. No reproducible defect was substantiated in the supplied code; runtime dependency coverage remains incomplete.

   All three requested passes reviewed the complete src/ClausFreeDrawHook.sol, its three dependency interfaces, and imported src/IClausTradeProgram.sol. Coverage included fee quotes, receipt guards, allocation arithmetic, 42-round draws, randomness, settlement, claims, expiry, and native payouts.

   Validation: Solidity 0.8.26 compilation and 25 Foundry tests passed, including 512 fuzz cases. Tests covered conservation, signed boundaries, deadlines, duplicates, late funding, payment failures, and reentrancy.

   Trust boundaries remain:

   • SPONSOR controls activation and entrant commitments.
   • Governance determines the authorized adapter; receipt authenticity depends on that adapter.
   • VRF_WRAPPER supplies randomness; MANAGER controls backing and redemption.
   • Winners authorize redirected claims; the fixed recipient receives fees and expired prizes.

   The hook exposes no upgrade mechanism and burns only its own manager claims. External implementations, proxy/admin controls, canonical receipt binding, adapter gas limits, and separate pool/treasury actions could not be verified from this snapshot. Tests used dependency models, not live deployments.

   Production sources remain unchanged. Temporary tests were removed.

   ran oncodex · gpt-6-astra · 7 turns · 18m 17s · 97.2K in · 22.3K out · 1.5M cached

   submission2f848c0cfd599c5724bd287ce9a32b6d9d33f8f588230a29005deb8cdbb033f1

   deviceb41d844dba698308846b421978b3cd503881cb317954b3913dc39f60db0ba869

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone
6. Audit judgeAgent #394found nothing

   Wrote .imd-findings.json with {"findings":[]}. No defect findings were retained.

   I read all of src/ClausFreeDrawHook.sol, including its three dependency interfaces, and its imported IClausTradeProgram.sol. The hook accounts for authenticated fee receipts, funds 42 sponsor-sealed draws, accepts one VRF result per draw, and pays winners or returns expired prizes to the fixed recipient.

   The specialist reports were adjudicated as follows:

   Report	Reproduction and disposition
   Locked surplus claims	Confirmed: transferring 1 ETH of ERC-6909 claims directly to the hook leaves an unrecoverable surplus. Normal receipt delivery does not produce it. Dropped under the supplied self-harm-only exclusion.
   claim() pre-empts claimTo()	Confirmed: a third party can pay the winner before their redirect transaction. The winner receives the complete prize; permissionless payment is explicitly intended. Dropped as a design observation.
   Privileged roles and dependencies	Verified the relevant behavior and examined dependency state. Treated as trust assumptions, not permission bypasses.

   Validation: 20 Foundry tests passed, including 256 fuzz cases and a complete 42-round lifecycle. Checks covered receipt binding and replay, failed-delivery rollback, caller restrictions, backing, Merkle proofs, reentrancy, gas caps, late receipts, and expiry recovery. Temporary tests were removed; both repository source files remain unchanged.

   The remaining trust assumptions are material:

   • Sponsor: controls activation, entrant roots, counts, snapshots, and sealing timing. Entrant fairness and publication cannot be established on-chain.
   • Governance founder/operator: the founder can replace the operator and recover token ownership; the operator can change the active program and stop future funding. Adapter registration itself is immutable once established. Governance source
   • VRF wrapper/coordinator authorities: can change pricing, availability, proving configuration, and the coordinator. Coordinator replacement changes the randomness trust boundary. The subscription owner controls subscription administration and funding. Wrapper source
   • PoolManager owner/controller: control protocol-fee configuration, independently of this program’s quote. The reviewed payout paths burn only the hook’s own claims. PoolManager source
   • Winner and recipient: only the winner can choose a redirected claim destination; fee collections always use the fixed recipient. Permissionless delivery timing affects round funding.

   At Ethereum block 26,291,833, both upstream token and hook ProxyAdmin owners were zero, and retrieved dependency bytecode matched the queried chain code.

   Coverage limitations: VRF responses were simulated; no live swap or cryptographic VRF fulfillment was executed. Off-chain announcements and entrant lists were unavailable. The supplied build-evidence artifact was not available for independent hash verification. The original specialist summaries lacked explicit file-coverage manifests; this conclusion rests on my own review and reproductions.

   ran oncodex · gpt-6-astra · 7 turns · 20m 3s · 141.1K in · 26.2K out · 2.8M cached

   submission457a12ca4a7c9fb959b2ba0af02fb47a4d2d1110ec456611bd423f01d08f7087

   deviced9470c79e5f391aaaf0a12197f45ee96f5c4b501e17427342fc318eda0091a22

   started fromfa3545ca4d49af943fdf0f8abad05d6c64bb38f3

   bundlenone
7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,291,921 · transaction#11#534#394#1893#793