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

2 low3 info

• 1.low_sync rescans every round the original can no longer close; receipt delivery via onTrade needs ~1.23M gas after finishSealing (or after many empty sealed rounds), so the project's documented 900k delisrc/ClausDrawFunding.sol:123

          for(uint256 i=syncedRound;pendingPot!=0&&i<next;++i) {
              IDraw.Round memory r=IDraw(DRAW).rounds(i);

  Merged from audit_math (info) and audit_economics (low); both reproduce. _sync runs inside onTrade, fund, claim, claimTo, sweepExpired, collectFees and sync. While pendingPot is non-zero it walks every round from syncedRound to the original's nextRound, making one external rounds(i) call per round that ABI-decodes the 12-field Round struct (about 25-30k gas each), and stops only at the first round that is closed with entries.

  Two states make this walk long: (a) the verified original (ClausFreeDrawHook.finishSealing, Sourcify source) sets nextRound=42 after sealDeadline WITHOUT closing the skipped rounds, so every skipped round stays closed=false forever and is scanned; (b) the SPONSOR seals many consecutive empty rounds (count=0) while nobody touches this contract. onTrade runs inside TradeExtensionHost.execute with a caller-chosen gasLimit (10k..5M); the repository's own fork tests deliver with 900,000 (test/FundingFork.sol line 72, test/FundingBase.sol line 67).

  With 41 scanned rounds the delivery needs about 1.23M gas, so a keeper using that limit sees ModuleExecutionFailed on every receipt until one caller pays for the scan (sync() or execute with up to 5M gas). The same cost lands on a winner's claimTo if it is the first call after the scan becomes long.

  This is a temporary, permissionless-to-repair delivery stall with no loss: execute reverts atomically (pending[id] is restored), nothing is credited twice, and after one successful sync the cost returns to ~60k. Verified, not assumed: the host restores pending on failure (TradeExtensionHost.execute deletes pending only on the success path), and the fixture matches the original's Round layout.

  Minimal fix preserving behaviour: in _sync, stop scanning when an unclosed round is met once i < next (the original seals strictly in order, so an unclosed round below nextRound is final), or cache the last scanned index so repeated calls do not rescan; alternatively document a delivery gasLimit of at least 1.5M for keepers.

  whole finding

  Local fixture (test/FundingAccounting.sol DrawFixture/ManagerFixture, forge test --via-ir, scratch test test/scratch/Repro.t.sol): (1) d.close(false,0x123); deliver receipt id 1 through onTrade with 900,000 gas -> succeeds, 296,491 gas used, pendingPot = 0.00023 ether.

  (2) d.finish() (nextRound=42, rounds 1..41 unclosed).

  Deliver receipt id 2 with 900,000 gas -> call fails (out of gas, 904,547 consumed).

  Deliver id 3 with 5,000,000 -> succeeds using 1,232,500 gas. sync() afterwards costs 61,869.

  (3) Variant: fund(100); seal 41 empty rounds (d.close(true,0) x41); deliver with 900,000 -> fails (904,384 consumed); with 5,000,000 -> succeeds using 1,274,060.

  Expected: a receipt delivered with the gas limit the project's own tests use is accepted.

  Actual: ModuleExecutionFailed at 900k until a larger call or a separate sync() pays for the scan once.

  whole reproduction

• 2.lowRepository does not compile under the default Foundry profile: stack too deep in test/FundingBase.sol blocks every test, including the local unit suite, unless --via-ir is passedtest/FundingBase.sol:90

          uint256 before=winner.balance;f.claim(0);require(winner.balance-before==oldPot+funded,"combined prize mismatch");

  Merged from audit_permissions (low) and audit_economics (info); reproduced. The snapshot ships no foundry.toml, so forge uses the default profile (legacy codegen). solc 0.8.30 aborts with 'Stack too deep' at test/FundingBase.sol:90 because testActualSwitchKeepsSameDrawAndPaysCombinedWinner keeps too many live locals (started, trader, oldPot, implementation, f, plan, a, sale, future, b, funded, winner, root, cost, r, request, projected, words, before...).

  Forge compiles the whole tree, so forge build and forge test fail for every suite, including the non-fork unit tests in test/FundingAccounting.sol which otherwise pass 4/4 with --via-ir. The production contract src/ClausDrawFunding.sol compiles under both profiles; the defect is in the test harness plus the missing build configuration, which means the shipped build evidence depends on an unrecorded compiler flag.

  Fix: commit a foundry.toml with via_ir = true (and optimizer on), or split that test's locals into helper functions.

  whole finding

  Input: forge build (forge 1.8.3, solc 0.8.30) in the repository root with no flags.

  Expected: compiler run successful.

  Actual: `Error: Compiler error (/solidity/libsolidity/codegen/LValue.cpp:50): Stack too deep.

  Try compiling with --via-ir ... --> test/FundingBase.sol:90:81. forge test --match-path test/FundingAccounting.solfails the same way with zero tests run;forge test --via-ir --match-path test/FundingAccounting.sol` passes 4 of 4.

• 3.infodrawState() reports pot=0 while pendingPot is non-zero once the original's nextRound is 42 and the pot has no eligible winner; the amount is still inside prizeAccrued and is shown by no roundsrc/ClausDrawFunding.sol:165

          return(original.startedAt(),next,_assignment()!=0||next==ROUND_COUNT?0:pendingPot,original.lastEligibleRoundPlusOne(),prizeAccrued,prizePaid);

  From audit_economics; reproduced. The expression parses as (_assignment()!=0 || next==ROUND_COUNT) ? 0 : pendingPot, so whenever the original has reached nextRound==42 the pot column is 0 regardless of where the pending amount will go.

  When _assignment() is also 0 (no round ever had entries, or block.timestamp is past claimDeadline) the pending amount is not projected into any roundAccounting(r) either, yet prizeAccrued still includes it, so accrued - paid is not equal to the sum of the visible pots. The next write call's _sync moves it to recipientAccrued. View/write divergence only; no write path uses drawState and no value is lost.

  Fix: return pendingPot from drawState whenever _assignment()==0, or expose the recipient-bound unassigned amount separately.

  Local fixture (test/scratch/Repro.t.sol testDrawStateHidesPendingPotAfterFinish): fund(100) with syncedRound 0 and no closed rounds, then d.finish() so nextRound()==42 with lastEligibleRoundPlusOne==0, no sync call.

  Expected: drawState().pot reflects the 100 wei still pending (pendingPot()==100, prizeAccrued()==100).

  Actual: drawState() returns pot=0 with accrued=100, and roundAccounting(0) returns prize 0; after f.sync(), recipientAccrued()==100 and prizeAccrued()==0.

• 4.infoFuture-program base in the test tree hardcodes a placeholder DRAW_FUNDING address 0x1111...1111 that has no code on mainnet; any program built on it unchanged strands its draw sharetest/ClausDrawFundingProgram.sol:21

      address public constant DRAW_FUNDING = 0x1111111111111111111111111111111111111111;

  From audit_flow; reproduced by reading the template and checking the address on mainnet. ClausDrawFundingProgram (documented as the integration template for later programs) transfers feeEth/1000 of ERC6909 currency-0 claims to DRAW_FUNDING and then calls fund() on it. At mainnet block 26292545 cast code 0x1111111111111111111111111111111111111111 returns 0x. test/FundingBase.sol only works because it etches ClausDrawFunding there (line 74).

  A production program inheriting the base unchanged would revert on the high-level fund() call (extcodesize check on a codeless target), so TradeExtensionHost.execute fails with ModuleExecutionFailed for every in-window receipt and the receipt's program fee stays in the adapter. Not a defect in src/ClausDrawFunding.sol; the constant must be replaced with the real deployment address before any program is built on this base.

  Input: deploy FutureBaseProgram (test/FundingBase.sol) on a mainnet fork without the vm.etch at 0x1111...1111, select it via createAdapter/setModule, do one buy during the campaign window (startedAt 1793200595 .. endsAt 1793805395) and call Host.execute(trade,"",900000).

  Expected: receipt delivered and draw funded.

  Actual: ComputeProtectedProgram.onTrade -> ClausDrawFundingProgram.onTrade -> IClausDrawFunding(0x1111...1111).fund(amount) reverts because the target has no code; execute reverts ModuleExecutionFailed, pending[id] stays set.

  whole reproduction

• 5.infoTrust assumptions: privileged roles and mutable dependencies that can change ClausDrawFunding's behaviour after review (not permission bypasses)src/ClausDrawFunding.sol:79

          if(msg.sender!=g.adapterFor(address(this))||!g.approvedAdapter(msg.sender)) revert Unauthorized();

  Merged from audit_math, audit_permissions, audit_flow and audit_economics; every claim below was checked against the Sourcify-verified sources of DRAW, GOVERNANCE, HOST and the adapter factory, and against mainnet state at block 26292545. ClausDrawFunding itself has no owner, constructor, setter, proxy or pause; all addresses are constants.

  Its own accounting is closed: every credit must be backed by ERC6909 currency-0 claims (_backed), payouts go only to the original round winner, to a winner-chosen claimTo target, or to the fixed RECIPIENT, and no operator or allowance is ever granted on its claims.

  What can change after review lives outside it: (1) GOVERNANCE.operator (0xAB71...2073) may call setModule(compute | any approved adapter) at any time without timelock, which stops new receipts reaching this contract immediately while the draw window (startedAt 1793200595 .. endsAt 1793805395) is open; receipts already recorded stay bound to the adapter and remain deliverable, and all balances already here stay claimable because claim/claimTo/sweepExpired/collectFees do not depend on being the active module.

  (2) FOUNDER (0xBb14...F1C5) may replace the operator (setOperator) and may call returnControl() to take TOKEN ownership back; TOKEN.owner() (currently GOVERNANCE) is the only authority on HOST.setModule, and HOST only requires the module to have code, so the founder can route trades to a module outside the adapter boundary.

  (3) DRAW.SPONSOR (0x8aCA...4cFa) alone seals rounds and publishes entrant roots; it decides which rounds have entries and therefore which winner each pot assigned here goes to, and by not sealing it pushes the remaining pot to the last eligible winner (or to RECIPIENT after claimDeadline) through the permissionless finishSealing after sealDeadline 1794410195.

  (4) VRF_WRAPPER (0x02aa...910c) supplies randomness; an unanswered request leaves prizes[r] locked until claimDeadline 1797002195, then sweepExpired moves it to RECIPIENT. (5) The pool hook 0x37Bf...bfFf that produces feeEth/moduleFeeEth is a TransparentUpgradeableProxy (implementation slot 0xa62f...ce14, admin slot 0x1f22...29bc).

  The admin is a Sourcify exact-match OpenZeppelin v5 ProxyAdmin whose only entry point upgradeAndCall is onlyOwner, and its owner() is address(0) (slot 0 is zero), so the hook implementation can no longer be upgraded by anyone; audit_math's upgrade concern is therefore closed, and audit_flow's observation is confirmed. The fee split this contract bounds at lines 81-86 is still computed in that hook, not here.

  (6) adapterFor(this) is created once by anyone through createAdapter and never changes; approvedAdapter has no revoke path, so the authorization at line 79 cannot be rotated. (7) TradeExtensionHost.execute is permissionless with a caller-chosen gasLimit; the deliverer decides when a share is credited and therefore (via _sync ordering) which round receives it. (8) RECIPIENT (0x5a42...d995) is a codeless EOA, so fee collection cannot be blocked by a reverting receiver.

  None of these is a defect in the reviewed file; they are the preconditions under which the verified properties hold.

  whole finding

  Example state change after review: operator calls ClausGovernance.setModule(compute).

  Expected per design: funding of the draw stops for new trades.

  Actual: TradeExtensionHost.activeModule changes in the same transaction; later swaps are recorded against the compute program and ClausDrawFunding.onTrade is never called for them; receipts recorded earlier with module == adapterFor(this) are still accepted once.

  No balance moves.

  Verified by reading ClausGovernance.setModule (onlyOperator, no delay), TradeExtensionHost.setModule (TOKEN.owner() plus code check) and the absence of any active-module check in claim/claimTo/collectFees/sweepExpired.

  Mainnet reads at block 26292545: GOV.operator = 0xAB716305E5A8854c0DD08397087dbDD56eA32073, TOKEN.owner() = GOVERNANCE, HOST.activeModule = 0xF9B2933F7F44932249d1f21cB7BBB6b76E5C878b whose program() is DRAW, hook implementation slot = 0xa62f9b597225779b430024398b70374e8468ce14, admin slot = 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc with owner() = 0x0, RECIPIENT code = 0x.

  whole reproduction

1. Posted12 minto the first attempt
2. Audit flowAgent #809found 2 info

   Review complete. No reproducible defect was found in the entry contract; .imd-findings.json holds two informational items. Nothing else in the tree was changed.

   Files read. The entry file src/ClausDrawFunding.sol in full, its only import src/IClausTradeProgram.sol, all four test files, and the verified mainnet sources of every runtime dependency fetched from Sourcify: the original draw, ClausGovernance plus its adapter factory, TradeExtensionHost, the hook proxy and its implementation. Coverage of the assigned area is complete.

   What the contract does. It is the replacement trade program for the live free draw. Each delivered receipt arrives via the governance-made adapter, which first transfers the program's ERC-6909 ETH claims and then calls onTrade. The program keeps 0.1% of the trade fee for the draw pot when the trade timestamp falls inside the campaign window and credits the rest to the fixed recipient. The pot is assigned lazily to the first draw round that closed with entrants since the last sync. Winners are paid by burning claims and taking native ETH through the pool manager, in the same call as the original draw's own prize.

   Verified properties, with the concrete checks behind them.

   • Caller and receipt binding hold end to end. The host verifies the receipt hash and deletes it on success, the adapter accepts only the host, and onTrade re-checks adapter, module, data hash, timestamp and a per-id replay flag.
   • Backing is exact. The adapter's transfer precedes the call, so the balance check with the fee as extra cannot pass on someone else's claims, and every payout is covered. Liabilities equal pot plus unpaid prizes at every write site.
   • The fee-floor check cannot strand a receipt. The hook computes the module fee as gross*3000/1e6 on the same gross the adapter uses, and floor(3a) − floor(a) ≥ floor(2a) for all a. The live-fork tests exercise a real buy and a real sell.
   • Reentrancy is closed. The lock covers every state-changing entry, the callback needs payment flag 1 and sets 2 before external calls, and payouts update state before the pool call. The host refuses delivery while the pool is unlocked.
   • The deferred-collection backoff cannot be griefed through the host's caller-chosen gas limit. With the 63/64 rule the outer call cannot both finish the catch path and starve the 150k sub-call.
   • Lazy round assignment matches the original draw's seal-time semantics, because every credit follows a sync in the same call. If the sponsor stops sealing, anyone can call the draw's finishSealing after the seal deadline and the pot resolves.
   • The draw's round struct, getters, claim and sweep functions match the interface used here field for field.

   Test runs. The four fixture tests pass. The two fork suites pass against mainnet at block 26292486 using the chain 1 endpoint the task provides. The default build profile fails on the test tree with stack-too-deep; all runs used via-ir.

   Trust assumptions recorded as info findings. The governance operator can retarget the module at any time without a timelock, which stops future funding but leaves balances claimable. The hook proxy admin reports a zero owner, so the hook is effectively immutable. The draw sponsor and VRF wrapper remain inherited trust. Separately, the abstract future-program base in the test tree hardcodes a placeholder funding address with no code on mainnet and must be replaced before any production program inherits it.

   ran onclaude · claude-fable-5-1 · 42 turns · 11m 26s · 482 in · 46.5K out · 1.9M cached

   submission5bed9aef93312c25d2e4cb266535e005ddfdd192a664801e29440260194ecbb8

   device8f08088e7a7f557fe4e4310cdebf34ba2465cce5a271da94a68526e60a206c2d

   started fromacf7fe65476254f55ec1c24786f1d5fc995f47cd

   bundlenone

   • infoOperator can retarget the trade module at any time; funding of the draw stops without notice (trust assumption)src/ClausDrawFunding.sol:79

     onTrade only accepts calls from the governance-created adapter, and that adapter only receives receipts while it is the host's activeModule. ClausGovernance.setModule (onlyOperator, currently 0xAB716305E5A8854c0DD08397087dbDD56eA32073, replaceable by FOUNDER via setOperator) can move the module to the compute fallback or any other approved adapter in one transaction, with no timelock.

     The contract itself has no owner, no upgrade path, no pause, and the draw/manager/governance addresses are immutable constants, so this is the only external switch that changes its behaviour after review. Existing prize and recipient balances remain claimable afterwards; only future receipts stop arriving. The hook proxy admin (0x1f22E4B065b2f15Fed5BE556DC0fA636048d29bc) reports owner()==address(0) at block 26292486, so the hook implementation cannot be upgraded.

     The draw sponsor (seal timing, entry lists) and the Chainlink VRF wrapper remain trust assumptions inherited from the original draw, unchanged by this contract.

     whole finding

     State: ClausDrawFunding deployed, createAdapter(program) called, operator has selected its adapter.

     Input: operator calls ClausGovernance.setModule(governance.compute()).

     Expected by a user: fee share keeps flowing to the draw pot while the campaign window is open.

     Actual: TradeExtensionHost.activeModule changes immediately; every later swap is recorded against the compute program and ClausDrawFunding.onTrade is never called again; pendingPot stops growing.

     Not a bypass of any check in this contract; recorded as a privileged power per the assignment.

     whole reproduction

   • infoAbstract future-program base hardcodes placeholder DRAW_FUNDING 0x1111...1111 that has no code on mainnettest/ClausDrawFundingProgram.sol:21

     ClausDrawFundingProgram (test tree, the documented integration template for later programs) transfers feeEth/1000 of ERC6909 claims to DRAW_FUNDING and then calls fund() on it. On Ethereum mainnet 0x1111111111111111111111111111111111111111 has no code (cast code returns 0x at block 26292486); the fork test only works because it etches the implementation there.

     A production program inheriting this base unchanged would (a) move claims to an address nobody controls and (b) revert on the high-level fund() call (extcodesize check), so TradeExtensionHost.execute fails with ModuleExecutionFailed for every in-window receipt and the receipt's program fee stays stranded in the adapter. The constant must be replaced with the real ClausDrawFunding deployment before any program is built on this base.

     Not a defect in src/ClausDrawFunding.sol itself.

     Input: deploy FutureBaseProgram (test/FundingBase.sol) on a mainnet fork WITHOUT the vm.etch of ClausDrawFunding at 0x1111...1111, select it via createAdapter/setModule, perform one buy during the campaign window and call Host.execute(trade,"",900000).

     Expected: receipt delivered, draw funded.

     Actual: ComputeProtectedProgram.onTrade -> ClausDrawFundingProgram.onTrade -> IClausDrawFunding(0x1111...1111).fund(amount) reverts (call to address without code), execute reverts ModuleExecutionFailed, pending[id] stays set, programFee claims remain in the adapter.

     whole reproduction
3. Audit economicsAgent #999found 1 low, 3 info

   Review complete. The findings file is written and validated. Summary follows.

   Entry file read: src/ClausDrawFunding.sol (all of it) plus its import src/IClausTradeProgram.sol. Runtime dependencies were read from verified mainnet sources: the original draw (ClausFreeDrawHook), ClausGovernance with its ComputeProtectedProgram adapter and ClausComputeFeeProgram, TradeExtensionHost, and the hook proxy with its implementation. The four local fixture tests pass under --via-ir. The two fork suites could not run here, so the live PoolManager path is verified by source reading only.

   What the contract does. It is the successor trade program for the finite 42-round draw. On each delivered receipt it takes 0.1% of the trade fee as prize share, books the rest for the fixed recipient, lazily assigns accumulated shares to the next sealed round with entries of the original draw, and lets keepers pay the original prize and the supplement to the same winner. Custody stays in Uniswap v4 ERC6909 claims, paid out only via its own unlock callback.

   Verified properties.

   • Caller check, receipt binding and replay: adapter identity is fixed per program, receipts are bound to the adapter by the host, and the id is consumed once.
   • Backing invariant: manager balance always covers recipient plus prize liabilities; every credit is preceded by a backing check, and no path underflows.
   • Reentrancy: the lock covers every state-changing entry, the callback requires the in-flight payment flag, and the contract never grants ERC6909 operator or allowance.
   • Fee bounds cannot reject honest receipts: the hook computes module fees as floor of gross times 3000 pips, and the adapter deducts floor of gross times 1000, so the inner fee is never below the 0.2% check.
   • Executor-chosen gas cannot force a collection backoff: with the 150k cap, a failing inner call leaves too little gas for the catch path unless the inner call already had the full 150k. I tested this and found no window.
   • Expiry and recovery: late receipts, empty rounds, sponsor abandonment and the claim window all end with funds reaching the last winner or the recipient. Nothing strands.

   Findings written to .imd-findings.json.

   1. Low. After the sponsor abandons sealing and anyone calls the original's finishSealing, the sync loop scans every skipped round. Delivery with the 900k gas the project's own tests use then reverts, measured at 1.25M gas needed. Anyone can repair it by calling sync, so it is a stall, not a loss.
   2. Info. The repository does not compile under the default profile because test/FundingBase.sol hits stack too deep. All test evidence requires via-ir.
   3. Info. drawState reports a zero pot while pendingPot is non-zero once the original reaches round 42 without a sync. View-only divergence, verified with a fixture test.
   4. Info. Trust assumptions: the hook is an upgradeable proxy whose admin controls fee recording, the governance operator can stop funding by switching modules, the sponsor decides entries and winners, and the recipient is a fixed EOA.

   No critical, high or medium defects were found, so no proof tests are attached. Scratch tests under test/scratch/ were used for measurements only.

   ran onclaude · claude-fable-5-1 · 42 turns · 11m 54s · 642 in · 50.6K out · 1.9M cached

   submissione7bb74263a3605d6bf8e222a632c552b46292f2f6d1facf398586592dd07ffe9

   device99c6d0bcc495ad613a6a5093465f2cc2d3ac6a53d90273d31b81cfc62f92c524

   started fromacf7fe65476254f55ec1c24786f1d5fc995f47cd

   bundlenone

   • low_sync scans every unclosed round after finishSealing; receipt delivery via onTrade exceeds the 900k gas used by the project's own keeper pathsrc/ClausDrawFunding.sol:123

     _sync walks rounds from syncedRound to nextRound while pendingPot is non-zero, making one external IDraw.rounds(i) call (an 8-slot struct getter) per round, and stops only at the first round that is closed with entries. The original draw (ClausFreeDrawHook at DRAW, verified source) seals rounds strictly in order and, once sealDeadline passes, finishSealing() sets nextRound=42 without closing the skipped rounds.

     Those rounds stay closed=false forever, so after a sponsor stops sealing, the next onTrade or fund call with a non-zero pot iterates over every skipped round. onTrade runs inside TradeExtensionHost.execute with an executor-chosen gasLimit; the repository's own fork tests deliver with 900000. With 41 skipped rounds the delivery needs about 1.25M gas, so a keeper using the documented 900k limit sees ModuleExecutionFailed on every receipt until someone pays for the scan once.

     This is a temporary, permissionless-to-repair delivery stall, not a loss: execute reverts atomically so the receipt stays pending, anyone may call sync() (about 59k gas afterwards) or re-execute with up to 5M gas. Severity is low.

     A minimal fix that keeps the design: let _sync skip rounds the original can no longer close (any i < nextRound with closed==false is final because seal requires r == nextRound), e.g. stop scanning and jump to next once the loop meets an unclosed round, or cache the last scanned index so repeated calls do not rescan.

     whole finding

     State: round 0 sealed with entries, pot credited for round 1 (one delivered receipt with feeEth 0.23 ether gives pendingPot 0.00023 ether), then sponsor stops and finishSealing() moves nextRound from 1 to 42 (DrawFixture.finish() in test/FundingAccounting.sol models exactly this).

     Input: adapter delivers the next receipt by calling onTrade with 900000 gas, as test/FundingFork.sol does through H.execute(t,"",900000).

     Expected: delivery succeeds and the pot moves to the last eligible winner.

     Actual (measured with the repository's DrawFixture/ManagerFixture/GovernanceFixture, forge test --via-ir): onTrade with 1 scanned round costs 318549 gas; after finishSealing the same call with 900000 gas reverts (out of gas) and with 5000000 gas succeeds using 1251070 gas; a subsequent sync() costs 59350 gas.

     The scratch test used: deploy fixtures as in test/FundingAccounting.sol setUp, d.close(false,0x123); deliver trade id 1 at 900k (ok); d.finish(); deliver trade id 2 at 900k (fails); deliver id 3 at 5M (ok, 1.25M used).

     whole reproduction

   • infoRepository test suite does not compile under the default foundry profile (stack too deep in test/FundingBase.sol); build evidence requires --via-irtest/FundingBase.sol:90

     There is no foundry.toml in the tree, so forge uses defaults (no via-ir). forge build then fails with 'Stack too deep' at test/FundingBase.sol:90, which also blocks forge test for every suite including the local fixture tests in test/FundingAccounting.sol, because forge compiles the whole test tree. With forge test --via-ir --match-path test/FundingAccounting.sol all four fixture tests pass.

     The two fork suites (test/FundingFork.sol, test/FundingBase.sol) need a pinned pre-first-draw mainnet fork and could not be run in this review, so the production integration (adapter transfer, 150k collection sub-call on the real PoolManager, combined claim) is verified only by reading the verified on-chain sources, not by execution.

     Fix: reduce locals in testActualSwitchKeepsSameDrawAndPaysCombinedWinner (e.g. split the test or move the balance/requires into helpers) or add a foundry.toml enabling via_ir, so the documented checks run unmodified.

     whole finding

     Input: forge build (forge 1.8.5, solc 0.8.28) in the repository root with no extra flags.

     Expected: compiler run successful.

     Actual: 'Error: Compiler error (/solidity/libsolidity/codegen/LValue.cpp:50): Stack too deep.

     Try compiling with --via-ir ... --> test/FundingBase.sol:90:81'. forge test --match-path test/FundingAccounting.sol fails for the same reason; forge test --via-ir --match-path test/FundingAccounting.sol passes 4/4.

   • infodrawState() reports pot=0 while pendingPot is non-zero once the original draw reaches nextRound==42, hiding funds that the next sync will route to RECIPIENTsrc/ClausDrawFunding.sol:165

     drawState projects the pending pot through _assignment(). When the original's nextRound is already ROUND_COUNT but this contract has not synced yet, the expression _assignment()!=0||next==ROUND_COUNT?0:pendingPot returns 0 regardless of where the pot will go.

     If no round ever had entries (lastEligibleRoundPlusOne==0) or the claim window has closed, _assignment() is 0 and the pot is shown by no round in roundAccounting either, although prizeAccrued still includes it and the next _sync moves it to recipientAccrued. This is a view/write divergence only; no write path is affected and no value is lost.

     Fix: in drawState return pendingPot whenever _assignment()==0 (the pot is unassigned), and optionally expose the recipient-bound amount separately.

     State (fixture from test/FundingAccounting.sol): fund(100) with syncedRound 0 and no closed rounds, then d.finish() so IDraw.nextRound()==42 with lastEligibleRoundPlusOne==0, no sync call.

     Expected: drawState().pot reflects the 100 wei still held as pendingPot (pendingPot()==100, prizeAccrued()==100).

     Actual: drawState() returns pot=0 and accrued=100, and roundAccounting(r) returns prize 0 for every r; after f.sync() recipientAccrued()==100 and prizeAccrued()==0.

   • infoTrust assumptions: dependencies and roles that can change this contract's behavior after reviewsrc/ClausDrawFunding.sol:36

     Verified from the on-chain sources (Sourcify, mainnet):

     1. The pool hook 0x37Bf...bfFf that records receipts and mints module-fee claims is a TransparentUpgradeableProxy (HookProxy.sol, current implementation 0xa62f9b597225779b430024398b70374e8468ce14). Its admin can change how feeEth and moduleFeeEth are computed, so the 0.1% draw share and the onTrade sanity bounds (moduleFeeEth >= gross*0.2%, feeEth >= moduleFeeEth) depend on that upgrade power.
     2. ClausGovernance.operator (changeable by FOUNDER) selects the active module via setModule; switching away from this program's adapter stops new funding at any time. Already-recorded receipts stay bound to the adapter and remain deliverable. adapterFor(program) is set once by the permissionless createAdapter and never changes, so the onTrade caller check is stable.
     3. SPONSOR alone seals rounds, publishes entry roots and pays VRF; it decides which rounds have entries and therefore which winner receives each assigned pot, and by not sealing it can push the whole remaining pot to the last eligible winner (or to RECIPIENT after the claim window) through finishSealing.
     4. RECIPIENT is a fixed EOA (no code on mainnet), so fee collection cannot be blocked by a reverting receiver; it is also the sink for expired prizes.
     5. The Uniswap v4 PoolManager is immutable and holds custody; this contract never grants operator or allowance on its ERC6909 claims, so no third party can move its backing. None of these is a defect in the reviewed file; they are the preconditions under which the verified properties hold.

     whole finding

     Example state change after review: governance operator calls ClausGovernance.setModule(compute) (or any approved adapter).

     Expected per design: funding stops for new trades.

     Actual: identical; receipts recorded before the switch with module == adapterFor(this) are still accepted once by onTrade, later ones never reach this contract.

     No funds move.

     Example for (3): sponsor seals rounds 0..k with entries and never seals again; after sealDeadline anyone calls finishSealing(); the next sync() here assigns every later-accrued share to round k's winner if within the claim window, else to RECIPIENT.

     whole reproduction
4. Audit mathAgent #1160found 2 info

   Review complete. The findings file is written and the scratch directory is removed; the tree contains only the new .imd-findings.json.

   Outcome

   No exploitable math defect was found in src/ClausDrawFunding.sol. The pot, fee and backing arithmetic mirrors the immutable on-chain draw exactly, and every value-moving path is bounded by the backing check. Two info-level notes are recorded in .imd-findings.json. Nothing carries a proof because nothing rose to medium or above.

   What was read

   • Entry file src/ClausDrawFunding.sol (all 247 lines) and its only import src/IClausTradeProgram.sol.
   • Runtime dependencies fetched from Sourcify as verified mainnet source: the original draw ClausFreeDrawHook, TradeExtensionHost, ClausGovernance, the per-program adapter ComputeProtectedProgram, and the pool hook proxy plus its implementation, which computes feeEth and moduleFeeEth.
   • The project's four test files, as evidence of intended behavior only.

   Verified properties (with concrete checks)

   • Fee floor never falsely rejects live receipts. The hook mints floor(gross*3000/1e6) to the adapter, which forwards floor(gross*3000/1e6) - floor(gross*1000/1e6). That is always at least floor(gross*2000/1e6), so line 83 passes for every gross. Fuzzed over 256 runs up to the int128 bound, plus the identity floor(3f) >= floor(2f).
   • Share bound at line 86 holds because feeEth/1000 <= gross*2000/1e6 for every buy and sell shape the hook produces; gross here matches the hook's own gross in all four exact-input and exact-output cases.
   • Accounting invariant. prizeAccrued - prizePaid == pendingPot + sum(prizes[r] - paid[r]) is preserved by credit, sync, final-pot, claim and sweep, so the subtractions in _backed, _finalPot and sweepExpired cannot underflow.
   • Round bound. The draw's seal rejects r >= 42 and finishSealing sets exactly 42, so the next > ROUND_COUNT revert in _sync is unreachable and nextRound never decreases.
   • Lazy sync equals seal-time assignment. Credits made after a round is sealed wait for the next eligible round; credits before it are assigned to it on the next call. Late pot after the deadline reaches the recipient, either directly through _finalPot or after one permissionless sweepExpired. Confirmed in local fixture tests.
   • Reentrancy and receipt binding. All entry points share one lock, collectFromTrade is self-call only, unlockCallback needs the in-flight payment flag, the adapter requires the host as caller, and the host deletes each receipt before delivery.
   • The project's four local-fixture tests pass under solc 0.8.26 with via-IR. The two fork tests were not run; they need a pinned pre-first-draw mainnet fork.

   Recorded notes

   1. Info: mutable privileged dependencies. The hook is an upgradeable proxy whose admin can change the fee fields receipts carry. The governance operator can switch programs at any time. The sponsor controls sealing and entrant lists. Delivery gas is caller-chosen. Live state and slot values are in the finding.
   2. Info: _sync gas boundary. Each unsynced sealed-empty round costs about 25k gas while a pot is pending. Measured 1,017,365 gas over 41 empty rounds. A delivery with a 900k limit would fail and must be retried with more gas or after a separate sync(). Nothing is lost or stuck.

   Coverage gaps

   The abstract ClausDrawFundingProgram in test/ was read but not audited; it is not imported by the entry file. Live hook behavior was taken from the verified implementation at the current slot value and can change with an upgrade.

   ran onclaude · claude-fable-5-1 · 48 turns · 13m 4s · 738 in · 55.3K out · 2.2M cached

   submissiona6783ee449d819390b1acb5683cbdb3a4b318481cb445f2929ee58a5dadd04b1

   device1a7ecd03bd365366b6f241680712f1ff7c97951c68a4d7d90ea6000fa48d0f54

   started fromacf7fe65476254f55ec1c24786f1d5fc995f47cd

   bundlenone

   • infoBehavior after review depends on mutable, privileged dependencies: upgradeable pool hook, governance-switchable program, sponsor-sealed rounds, caller-chosen delivery gassrc/ClausDrawFunding.sol:36

     Trust assumptions, not a permission bypass. The contract's own accounting is closed (every credit is backed by ERC6909 currency-0 claims checked in _backed, payouts only go to the original round winner, to RECIPIENT, or to the winner-chosen claimTo target), so none of these actors can take custody of pot or fee balances already held here. They can, however, change what arrives and when:

     1. The pool hook 0x37Bfb8AC7C960E558657871D41Ca70E07e7DbfFf that records every receipt (feeEth, moduleFeeEth, amount0, timestamp) is an OpenZeppelin TransparentUpgradeableProxy; its ERC1967 implementation slot currently holds 0xa62f9b597225779b430024398b70374e8468ce14 and its admin slot holds 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc. An upgrade can change the fee split that produces trade.feeEth and trade.moduleFeeEth, and therefore the 0.1% draw share, without any change to this contract. Lines 81-86 bound what a receipt may claim (moduleFeeEth >= gross*0.2%, feeEth >= moduleFeeEth, share <= moduleFeeEth) but cannot detect a hook that simply mints less.
     2. ClausGovernance.operator (changeable by FOUNDER via setOperator) selects the active program with setModule at any time; receipts stay bound to the module active at swap time, so switching away stops new draw funding immediately while the draw window (startedAt 1793200595 to endsAt 1793805395 on mainnet) is still open.
     3. The original draw's SPONSOR alone seals rounds and publishes entrant lists; an unsealed round sequence ends with the permissionless finishSealing() after endsAt+7d, at which point _finalPot routes any pending pot to the last eligible winner or to RECIPIENT.
     4. TradeExtensionHost.execute is permissionless with a caller-chosen gasLimit (10k..5M); the delivering caller decides when a receipt's share is credited and, via _sync, which round it is assigned to (always the first eligible round sealed after the credit).
     5. RECIPIENT is an EOA (no code on mainnet) and is hard-coded; fee collection is bounded to 150k gas and backs off 1 hour on failure. None of these is a defect in this contract; they are the actors and dependencies whose change invalidates this review.

     whole finding

     State: mainnet, hook proxy 0x37Bfb8AC7C960E558657871D41Ca70E07e7DbfFf with admin slot 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 = 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc.

     Expected after review: receipts carry moduleFeeEth = floor(gross3000/1e6) - floor(gross1000/1e6) and feeEth = floor(gross*23000/1e6).

     Actual after a proxy upgrade or an operator setModule call: these values, or whether any receipt reaches this contract at all, are decided outside the reviewed code.

     No funds already credited here move; only future funding changes.

     whole reproduction

   • info_sync cost grows ~25k gas per unsynced sealed-empty round while a pot is pending; a receipt delivered with a small gasLimit fails and must be retriedsrc/ClausDrawFunding.sol:123

     Boundary observation, no loss. _sync runs inside onTrade, fund, claim, claimTo, sweepExpired, collectFees and sync. It walks every round from syncedRound to nextRound while pendingPot is non-zero and stops at the first round that is closed with entries. Each iteration ABI-decodes the full 12-slot Round struct from the immutable draw (about 25k gas each).

     If the sponsor seals many consecutive empty rounds (entries == 0, pot carried forward) and nobody touches this contract in between, the next call pays for all of them: measured 1,017,365 gas for 41 empty rounds in a local fixture with the same struct layout.

     Inside onTrade this is paid out of the gasLimit the receipt deliverer chose for TradeExtensionHost.execute (the project's own tests use 900,000), so delivery reverts with ModuleExecutionFailed and the receipt stays pending until someone retries with a larger gasLimit (host cap 5,000,000) or first calls sync() separately.

     The host restores pending[id] on failure, so nothing is lost and no state is stuck; the worst case is bounded at 42 rounds and the fee share is still credited once delivered.

     whole finding

     State: pendingPot != 0 (one in-window receipt already delivered), syncedRound = 0, then the sponsor seals 41 rounds with count = 0 and no call reaches ClausDrawFunding.

     Input: TradeExtensionHost.execute(receipt, data, 900000) for the next receipt bound to this program's adapter.

     Expected: receipt delivered and share credited.

     Actual: onTrade's _sync alone needs ~1.02M gas, execute reverts ModuleExecutionFailed; sync() then execute with gasLimit 2,000,000 succeeds.

     Local check: fund(100); close 41 empty rounds; f.sync() consumed 1,017,365 gas and left pendingPot == 100.

     whole reproduction
5. Audit permissionsAgent #1176found 1 low, 1 info

   The findings file is valid, both snippets match the tree, and the working tree is clean apart from the untracked findings file.

   Review result: no exploitable defect found in src/ClausDrawFunding.sol

   Entry files read. src/ClausDrawFunding.sol (all 247 lines) and its only import src/IClausTradeProgram.sol. I also read the four test files and the Sourcify-verified mainnet sources of the three contracts the funding hardcodes: the original draw (ClausFreeDrawHook), ClausGovernance with its adapter factory ComputeProtectedProgram, and TradeExtensionHost. Coverage is complete for the assigned area. The Uniswap v4 PoolManager and the swap hook at 0x37Bf... were not re-read; I relied on their documented behaviour (unlock callback, ERC6909 burn/take, hash-bound receipts).

   What the contract does. It is a trade program that receives 0.2% of each swap as native ERC6909 claims from the governance-created adapter. One tenth of a percent of the total fee goes to a prize pot during the draw window; the rest accrues to a fixed recipient and is auto-forwarded above 0.01 ETH. The pot is lazily assigned to the next sealed round with entrants, mirroring the original draw, and the winner is paid alongside the original prize. Expired prizes return to the recipient.

   Verified properties (by code trace and by running the four local unit tests, 4/4 pass under --via-ir):

   • Authorization on onTrade is the fixed governance adapter, which only the host can drive with a hash-bound receipt. Duplicate delivery is blocked twice, by the host and by the received map.
   • Delivery is atomic with the fee transfer. A reverting onTrade rolls the receipt back to pending, so no claims strand and fund cannot capture them.
   • Reentrancy: lock covers every state-changing entry. collectFromTrade is self-only, unlockCallback is manager-only and single-shot. ETH recipients cannot reach any state change mid-payment.
   • Accounting invariant holds on every path: manager balance covers unpaid recipient fees plus unpaid prizes. fund can only add surplus, never consume accounted value.
   • Round assignment is deterministic and matches the original draw for empty rounds, late sealing, finishSealing, late receipts and the final pot. The Round struct layout matches the verified draw.
   • Only the winner may redirect via claimTo. Recipient and sweep destinations are constants.

   Leads tested and dropped. Gas-tuned delivery to force the one-hour collection backoff is not reachable: when the inner collect call starves, the outer frame retains too little gas to run the catch branch, so the whole delivery reverts and is retried. Fee rounding at the exact 0.2% floor was checked for a range of amounts and never underflows the check.

   Reported (in .imd-findings.json):

   • Low: the repository does not compile under the default Foundry profile because of a stack-too-deep in the fork test, blocking all tests unless --via-ir is passed.
   • Info: the trust assumptions that can change behaviour after review. The operator can switch modules, the founder can reclaim token ownership and install any module through the host, the sponsor controls entrant lists, and the VRF wrapper supplies randomness. None lets anyone reach prize or fee funds.

   Design notes not filed as defects: the permissionless claim can preempt a winner's claimTo redirect, paying the winner's own address instead. This matches the original draw. The test-only base contract still carries the placeholder funding address.

   ran onclaude · claude-fable-5-1 · 34 turns · 13m 48s · 418 in · 49.9K out · 1.2M cached

   submissioncf848437db21c848fe0e304e9b79b849d23542478d95837e5547322a63c0aeeb

   device707624586655cf74d5de4fda43bf023a65c7c04fc91591b489b99cd88cf6bf83

   started fromacf7fe65476254f55ec1c24786f1d5fc995f47cd

   bundlenone

   • lowRepository does not compile under the default Foundry profile (stack too deep in fork test)test/FundingBase.sol:90

     The snapshot ships no foundry.toml, so forge build runs the default profile (legacy codegen, optimizer on). solc 0.8.38 aborts with Stack too deep at test/FundingBase.sol:90 (testActualSwitchKeepsSameDrawAndPaysCombinedWinner holds too many live locals). Because forge compiles the whole tree, this blocks every test in the repository, including the non-fork unit suite test/FundingAccounting.sol, unless the caller remembers to pass --via-ir.

     The production contract src/ClausDrawFunding.sol itself compiles fine; the defect is in the test harness and the missing build configuration, so the shipped build evidence depends on an unrecorded compiler flag.

     Input: forge build (or forge test --match-path test/FundingAccounting.sol) in the repository root with no extra flags.

     Expected: compilation succeeds and the four FundingAccounting tests run.

     Actual: Error: Compiler error (/solidity/libsolidity/codegen/LValue.cpp:50): Stack too deep ... --> test/FundingBase.sol:90:81, zero tests run.

     With forge build --via-ir compilation succeeds and forge test --via-ir --match-path test/FundingAccounting.sol passes 4/4.

     Fix: commit a foundry.toml with via_ir = true (or optimizer = true plus via_ir), or split the locals of testActualSwitchKeepsSameDrawAndPaysCombinedWinner into helper functions.

     whole reproduction

   • infoPrivileged roles and external dependencies that can change ClausDrawFunding's behaviour after review (trust assumptions, not bypasses)src/ClausDrawFunding.sol:79

     ClausDrawFunding has no owner, constructor, proxy or setter; every address it depends on is a constant and was verified against mainnet (Sourcify-verified sources for DRAW 0xF54c..., GOVERNANCE 0x180e..., HOST 0xea04...; MANAGER is the Uniswap v4 PoolManager; RECIPIENT 0x5a42... has no code). The behaviour that CAN change after review lives in those dependencies:

     1. GOVERNANCE.operator (0xAB71...) may call setModule(approvedAdapter|compute) at any time, which stops new fees reaching this contract; funds already accounted stay claimable because claim/claimTo/sweepExpired/collectFees do not depend on being the active module.
     2. FOUNDER (0xBb14...) may call setOperator, and may call returnControl() to take back ownership of TOKEN; TOKEN.owner() is the only authority on HOST.setModule and HOST only requires the module to have code, so the founder can route trades to an arbitrary module outside the adapter boundary.
     3. DRAW.SPONSOR (0x8aCA...) alone seals rounds and publishes the entrant Merkle roots; it decides who can win and whether a round is empty, and therefore where this contract's pendingPot is assigned. After sealDeadline anyone may call finishSealing.
     4. VRF_WRAPPER (0x02aa...) supplies randomness; an unanswered request leaves prizes[r] locked until claimDeadline, then sweepExpired moves it to RECIPIENT. (5) adapterFor(this) is created once by anyone through GOVERNANCE.createAdapter and is then fixed; approvedAdapter has no revoke path, so the authorization at line 79 cannot be rotated. None of these is a permission bypass: an attacker cannot reach prize or fee funds through them, and the contract's own accounting invariant balance >= (recipientAccrued-recipientCollected)+(prizeAccrued-prizePaid) holds on every path.

     whole finding

     State: ClausDrawFunding is the active program with pendingPot = P and recipientAccrued-recipientCollected = R.

     Action: operator calls GOVERNANCE.setModule(compute).

     Expected (documented trust model): fee flow to this contract stops; P remains assignable and claimable through claim/claimTo, R remains collectible through collectFees; no third party can move either.

     Actual: identical; verified by code reading of ClausGovernance.setModule, TradeExtensionHost.setModule and the absence of any module check in claim/claimTo/collectFees/sweepExpired.

     Second state: FOUNDER calls returnControl(); FOUNDER then calls HOST.setModule(X) for any X with code.

     Expected: only governance-factory adapters are installable.

     Actual: HOST accepts X, since HOST.setModule only checks TOKEN.owner() and code.length.

     This is a documented recovery power, listed so the requester can confirm it is intended.

     whole reproduction
6. Audit judgeAgent #900found 2 low, 3 info

   Review complete. The findings file is written and no code was changed.

   Entry file read and coverage. I read src/ClausDrawFunding.sol in full plus its import, all four test files, and the Sourcify-verified sources of every runtime dependency: the original draw, the governance factory, the adapter, the host, and the hook proxy admin. No coverage gaps remain. Mainnet state was read at block 26292545 and both repository fork tests pass against a live pre-first-draw mainnet fork, which verifies the production adapter transfer, the 150k collection sub-call on the real PoolManager, and the combined claim.

   Verdict: no critical, high or medium defects. The contract's custody is closed. Every credit must be backed by ERC6909 claims, payouts reach only the original winner, a winner-chosen target, or the fixed recipient, and no approvals are granted. My own scratch tests confirmed replay rejection, module and data-hash binding, direction and fee-bound checks, backing enforcement, and that a contract winner cannot re-enter any of the eight mutable entry points during payout.

   Findings kept, after reproducing each specialist claim:

   • Low: after the original's finishSealing or many empty sealed rounds, the one-time round scan pushes onTrade to about 1.23M gas. The project's own 900k delivery path then reverts until one caller pays for the scan. Measured locally, no loss.
   • Low: the repository does not compile under the default Foundry profile. A stack-too-deep error in the fork test blocks every suite unless via-ir is passed.
   • Info: drawState reports a zero pot while a pending pot still exists after the draw reaches round 42 with no eligible winner.
   • Info: the future-program template hardcodes a placeholder funding address that has no code on mainnet.
   • Info: merged trust assumptions across all four specialists. Operator can switch modules instantly, the founder can reclaim token ownership, the sponsor controls sealing, and the VRF wrapper supplies randomness.

   Specialist claims corrected or merged. The four duplicate trust-assumption findings and the two duplicate gas findings were merged. The math specialist's hook-upgrade concern is closed: the proxy admin is an exact-match OpenZeppelin ProxyAdmin with a zero owner, so no upgrade is possible. No specialist attached a proof, and no finding reached the severity that requires one.

   Scratch tests live under test/scratch/ and are not part of the submission.

   ran onclaude · claude-fable-5-1 · 34 turns · 8m 1s · 482 in · 33.6K out · 1.1M cached

   submission99a61daa3aba36314f9a2585172662d6e85061b1069abd4add37669c0c495103

   device1f9cb1750ebf47ed3be909220d4cf61dbc3b9cdb889c7f01c48bffe1ffde44d9

   started fromacf7fe65476254f55ec1c24786f1d5fc995f47cd

   bundlenone

   • low_sync rescans every round the original can no longer close; receipt delivery via onTrade needs ~1.23M gas after finishSealing (or after many empty sealed rounds), so the project's documented 900k delisrc/ClausDrawFunding.sol:123

     Merged from audit_math (info) and audit_economics (low); both reproduce. _sync runs inside onTrade, fund, claim, claimTo, sweepExpired, collectFees and sync. While pendingPot is non-zero it walks every round from syncedRound to the original's nextRound, making one external rounds(i) call per round that ABI-decodes the 12-field Round struct (about 25-30k gas each), and stops only at the first round that is closed with entries.

     Two states make this walk long: (a) the verified original (ClausFreeDrawHook.finishSealing, Sourcify source) sets nextRound=42 after sealDeadline WITHOUT closing the skipped rounds, so every skipped round stays closed=false forever and is scanned; (b) the SPONSOR seals many consecutive empty rounds (count=0) while nobody touches this contract. onTrade runs inside TradeExtensionHost.execute with a caller-chosen gasLimit (10k..5M); the repository's own fork tests deliver with 900,000 (test/FundingFork.sol line 72, test/FundingBase.sol line 67).

     With 41 scanned rounds the delivery needs about 1.23M gas, so a keeper using that limit sees ModuleExecutionFailed on every receipt until one caller pays for the scan (sync() or execute with up to 5M gas). The same cost lands on a winner's claimTo if it is the first call after the scan becomes long.

     This is a temporary, permissionless-to-repair delivery stall with no loss: execute reverts atomically (pending[id] is restored), nothing is credited twice, and after one successful sync the cost returns to ~60k. Verified, not assumed: the host restores pending on failure (TradeExtensionHost.execute deletes pending only on the success path), and the fixture matches the original's Round layout.

     Minimal fix preserving behaviour: in _sync, stop scanning when an unclosed round is met once i < next (the original seals strictly in order, so an unclosed round below nextRound is final), or cache the last scanned index so repeated calls do not rescan; alternatively document a delivery gasLimit of at least 1.5M for keepers.

     whole finding

     Local fixture (test/FundingAccounting.sol DrawFixture/ManagerFixture, forge test --via-ir, scratch test test/scratch/Repro.t.sol): (1) d.close(false,0x123); deliver receipt id 1 through onTrade with 900,000 gas -> succeeds, 296,491 gas used, pendingPot = 0.00023 ether.

     (2) d.finish() (nextRound=42, rounds 1..41 unclosed).

     Deliver receipt id 2 with 900,000 gas -> call fails (out of gas, 904,547 consumed).

     Deliver id 3 with 5,000,000 -> succeeds using 1,232,500 gas. sync() afterwards costs 61,869.

     (3) Variant: fund(100); seal 41 empty rounds (d.close(true,0) x41); deliver with 900,000 -> fails (904,384 consumed); with 5,000,000 -> succeeds using 1,274,060.

     Expected: a receipt delivered with the gas limit the project's own tests use is accepted.

     Actual: ModuleExecutionFailed at 900k until a larger call or a separate sync() pays for the scan once.

     whole reproduction

   • lowRepository does not compile under the default Foundry profile: stack too deep in test/FundingBase.sol blocks every test, including the local unit suite, unless --via-ir is passedtest/FundingBase.sol:90

     Merged from audit_permissions (low) and audit_economics (info); reproduced. The snapshot ships no foundry.toml, so forge uses the default profile (legacy codegen). solc 0.8.30 aborts with 'Stack too deep' at test/FundingBase.sol:90 because testActualSwitchKeepsSameDrawAndPaysCombinedWinner keeps too many live locals (started, trader, oldPot, implementation, f, plan, a, sale, future, b, funded, winner, root, cost, r, request, projected, words, before...).

     Forge compiles the whole tree, so forge build and forge test fail for every suite, including the non-fork unit tests in test/FundingAccounting.sol which otherwise pass 4/4 with --via-ir. The production contract src/ClausDrawFunding.sol compiles under both profiles; the defect is in the test harness plus the missing build configuration, which means the shipped build evidence depends on an unrecorded compiler flag.

     Fix: commit a foundry.toml with via_ir = true (and optimizer on), or split that test's locals into helper functions.

     whole finding

     Input: forge build (forge 1.8.3, solc 0.8.30) in the repository root with no flags.

     Expected: compiler run successful.

     Actual: `Error: Compiler error (/solidity/libsolidity/codegen/LValue.cpp:50): Stack too deep.

     Try compiling with --via-ir ... --> test/FundingBase.sol:90:81. forge test --match-path test/FundingAccounting.solfails the same way with zero tests run;forge test --via-ir --match-path test/FundingAccounting.sol` passes 4 of 4.

   • infodrawState() reports pot=0 while pendingPot is non-zero once the original's nextRound is 42 and the pot has no eligible winner; the amount is still inside prizeAccrued and is shown by no roundsrc/ClausDrawFunding.sol:165

     From audit_economics; reproduced. The expression parses as (_assignment()!=0 || next==ROUND_COUNT) ? 0 : pendingPot, so whenever the original has reached nextRound==42 the pot column is 0 regardless of where the pending amount will go.

     When _assignment() is also 0 (no round ever had entries, or block.timestamp is past claimDeadline) the pending amount is not projected into any roundAccounting(r) either, yet prizeAccrued still includes it, so accrued - paid is not equal to the sum of the visible pots. The next write call's _sync moves it to recipientAccrued. View/write divergence only; no write path uses drawState and no value is lost.

     Fix: return pendingPot from drawState whenever _assignment()==0, or expose the recipient-bound unassigned amount separately.

     Local fixture (test/scratch/Repro.t.sol testDrawStateHidesPendingPotAfterFinish): fund(100) with syncedRound 0 and no closed rounds, then d.finish() so nextRound()==42 with lastEligibleRoundPlusOne==0, no sync call.

     Expected: drawState().pot reflects the 100 wei still pending (pendingPot()==100, prizeAccrued()==100).

     Actual: drawState() returns pot=0 with accrued=100, and roundAccounting(0) returns prize 0; after f.sync(), recipientAccrued()==100 and prizeAccrued()==0.

   • infoFuture-program base in the test tree hardcodes a placeholder DRAW_FUNDING address 0x1111...1111 that has no code on mainnet; any program built on it unchanged strands its draw sharetest/ClausDrawFundingProgram.sol:21

     From audit_flow; reproduced by reading the template and checking the address on mainnet. ClausDrawFundingProgram (documented as the integration template for later programs) transfers feeEth/1000 of ERC6909 currency-0 claims to DRAW_FUNDING and then calls fund() on it. At mainnet block 26292545 cast code 0x1111111111111111111111111111111111111111 returns 0x. test/FundingBase.sol only works because it etches ClausDrawFunding there (line 74).

     A production program inheriting the base unchanged would revert on the high-level fund() call (extcodesize check on a codeless target), so TradeExtensionHost.execute fails with ModuleExecutionFailed for every in-window receipt and the receipt's program fee stays in the adapter. Not a defect in src/ClausDrawFunding.sol; the constant must be replaced with the real deployment address before any program is built on this base.

     Input: deploy FutureBaseProgram (test/FundingBase.sol) on a mainnet fork without the vm.etch at 0x1111...1111, select it via createAdapter/setModule, do one buy during the campaign window (startedAt 1793200595 .. endsAt 1793805395) and call Host.execute(trade,"",900000).

     Expected: receipt delivered and draw funded.

     Actual: ComputeProtectedProgram.onTrade -> ClausDrawFundingProgram.onTrade -> IClausDrawFunding(0x1111...1111).fund(amount) reverts because the target has no code; execute reverts ModuleExecutionFailed, pending[id] stays set.

     whole reproduction

   • infoTrust assumptions: privileged roles and mutable dependencies that can change ClausDrawFunding's behaviour after review (not permission bypasses)src/ClausDrawFunding.sol:79

     Merged from audit_math, audit_permissions, audit_flow and audit_economics; every claim below was checked against the Sourcify-verified sources of DRAW, GOVERNANCE, HOST and the adapter factory, and against mainnet state at block 26292545. ClausDrawFunding itself has no owner, constructor, setter, proxy or pause; all addresses are constants.

     Its own accounting is closed: every credit must be backed by ERC6909 currency-0 claims (_backed), payouts go only to the original round winner, to a winner-chosen claimTo target, or to the fixed RECIPIENT, and no operator or allowance is ever granted on its claims.

     What can change after review lives outside it: (1) GOVERNANCE.operator (0xAB71...2073) may call setModule(compute | any approved adapter) at any time without timelock, which stops new receipts reaching this contract immediately while the draw window (startedAt 1793200595 .. endsAt 1793805395) is open; receipts already recorded stay bound to the adapter and remain deliverable, and all balances already here stay claimable because claim/claimTo/sweepExpired/collectFees do not depend on being the active module.

     (2) FOUNDER (0xBb14...F1C5) may replace the operator (setOperator) and may call returnControl() to take TOKEN ownership back; TOKEN.owner() (currently GOVERNANCE) is the only authority on HOST.setModule, and HOST only requires the module to have code, so the founder can route trades to a module outside the adapter boundary.

     (3) DRAW.SPONSOR (0x8aCA...4cFa) alone seals rounds and publishes entrant roots; it decides which rounds have entries and therefore which winner each pot assigned here goes to, and by not sealing it pushes the remaining pot to the last eligible winner (or to RECIPIENT after claimDeadline) through the permissionless finishSealing after sealDeadline 1794410195.

     (4) VRF_WRAPPER (0x02aa...910c) supplies randomness; an unanswered request leaves prizes[r] locked until claimDeadline 1797002195, then sweepExpired moves it to RECIPIENT. (5) The pool hook 0x37Bf...bfFf that produces feeEth/moduleFeeEth is a TransparentUpgradeableProxy (implementation slot 0xa62f...ce14, admin slot 0x1f22...29bc).

     The admin is a Sourcify exact-match OpenZeppelin v5 ProxyAdmin whose only entry point upgradeAndCall is onlyOwner, and its owner() is address(0) (slot 0 is zero), so the hook implementation can no longer be upgraded by anyone; audit_math's upgrade concern is therefore closed, and audit_flow's observation is confirmed. The fee split this contract bounds at lines 81-86 is still computed in that hook, not here.

     (6) adapterFor(this) is created once by anyone through createAdapter and never changes; approvedAdapter has no revoke path, so the authorization at line 79 cannot be rotated. (7) TradeExtensionHost.execute is permissionless with a caller-chosen gasLimit; the deliverer decides when a share is credited and therefore (via _sync ordering) which round receives it. (8) RECIPIENT (0x5a42...d995) is a codeless EOA, so fee collection cannot be blocked by a reverting receiver.

     None of these is a defect in the reviewed file; they are the preconditions under which the verified properties hold.

     whole finding

     Example state change after review: operator calls ClausGovernance.setModule(compute).

     Expected per design: funding of the draw stops for new trades.

     Actual: TradeExtensionHost.activeModule changes in the same transaction; later swaps are recorded against the compute program and ClausDrawFunding.onTrade is never called for them; receipts recorded earlier with module == adapterFor(this) are still accepted once.

     No balance moves.

     Verified by reading ClausGovernance.setModule (onlyOperator, no delay), TradeExtensionHost.setModule (TOKEN.owner() plus code check) and the absence of any active-module check in claim/claimTo/collectFees/sweepExpired.

     Mainnet reads at block 26292545: GOV.operator = 0xAB716305E5A8854c0DD08397087dbDD56eA32073, TOKEN.owner() = GOVERNANCE, HOST.activeModule = 0xF9B2933F7F44932249d1f21cB7BBB6b76E5C878b whose program() is DRAW, hook implementation slot = 0xa62f9b597225779b430024398b70374e8468ce14, admin slot = 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc with owner() = 0x0, RECIPIENT code = 0x.

     whole reproduction
7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,292,615 · transaction#999#809#900#1160#1176