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

Download the report (Markdown)

1 high5 medium7 low

• 1.highUnauthenticated Sepolia log flood (>5000 Requested events in one 500-block window) permanently stalls the public intake worker: scan, proposals and result deliveryadapters/contract-intake.mjs:47

        requireThat(logs.length <= 5000, 'inbox_scan_too_large');

  ClausRequestInbox.request() (contracts/src/ClausRequestInbox.sol:46-56) is permissionless and fee-free and accepts any binding word. createContractInboxRead.scan() always queries a fixed window (limit defaults to 500 blocks; the worker never passes another value and the persisted cursor only carries afterBlock/blockHash) and throws inbox_scan_too_large when the window holds more than 5000 logs. runtime/contract-intake-worker.mjs:23 awaits chain.scan() outside any try/catch, before the cursor write (line 51), before intake.run() (line 54) and before the delivery/reconciliation loop (lines 55-93).

  The window never shrinks and the cursor never advances, so every later tick repeats the identical failing query. Consequences for every admitted project at once: no new requests are ingested, no result_ready request is resolved or called back, and already-broadcast dispatcher transactions are never reconciled (wallet slot and reserved budget stay locked). The hosted worker (runtime/contract-intake-host.mjs:34) propagates the error so worker-health is never written.

  An RPC provider's own getLogs result cap produces the same permanent stall at a lower count. Cost to the attacker: ~5001 x ~70k gas of free Sepolia ETH, no identity, no admission. Recovery needs an operator to hand-edit contract-intake-cursors past the flooded range (losing legitimate events inside it).

  Fix: filter getLogs by the indexed binding topic of currently active bindings, or bisect/narrow the block window on inbox_scan_too_large (and on RPC result-cap errors) and persist progress per sub-range; additionally run the delivery loop even when the scan fails so unrelated chain traffic cannot block reconciliation. Merged from audit_flow, audit_economics and audit_permissions (same mechanism).

  whole finding

  Executed: test/scratch/repro-scan-dos.test.mjs (passes against this revision).

  State: intake worker active, cursor absent (startBlock 100), an honest result_ready request of an admitted project waiting for delivery.

  Input: real createContractInboxRead with a client whose getLogs returns 5001 Requested logs (unknown binding) for blocks 100..599.

  Expected: unknown bindings are skipped (if (!binding) continue;) and the honest request is stepped by the dispatcher.

  Actual: three consecutive worker.tick() calls reject with code inbox_scan_too_large, each querying the identical range [100n, 599n]; contract-intake-cursors has 0 rows; delivery.step was called 0 times.

  On Sepolia: any EOA calling inbox.request(bytes32(1), bytes32(1), now+1h, 0, '0x01') 5001 times within 500 blocks reproduces this against the pinned inbox.

  whole reproduction

• 2.mediumAccept-then-cancel of never-sent public reviews permanently consumes the 4 IMD lifetime allocation and day counters: free EOAs exhaust the public programme at zero costsrc/review-flow/admission.mjs:53

        await tx.write('public-review-exposure', 'lifetime', { maximum: total.toString() }, lifetime?.revision ?? 0);

  createReviewAdmission.reserve() adds quote.offer.maximum to public-review-exposure/lifetime and increments the per-owner day counter at admission time (lines 46-53); beforeAdmission increments the per-project and global day counters (src/review-flow/index.mjs:182-190). None of these is ever decremented.

  The billing ledger, by contrast, returns the sponsor reservation when the owner cancels the review-execute job before the worker's effect boundary: jobs.cancel (src/jobs/index.mjs:45-57, allowed while effect === 'not_started', i.e. immediately after review_accept) -> flow.onCancel -> reviews.cancelUnsent (src/reviews/index.mjs:110-123) sets billing 'void' and settles the reservation at 0. So admission, not spending, depletes the lifetime pool.

  Owner identities are free (any EOA that signs the SIWE challenge gets a principal, src/identity/index.mjs:134-138), project creation is public, so perOwnerDay=2 does not bind a hostile party: four throwaway wallets x two projects consume 8 x 0.5 IMD = the entire planned 4 IMD / 7-day allocation in one day while the sponsor spends nothing and no review is performed; every honest review_accept then fails with sponsor_exhausted until the network owner publishes a larger maximumLifetime, which the pilot explicitly does not plan ('no auto-refill').

  The same consumption happens via the runPaid denied path (payment_window_expired / source withdrawn) without any cancel call. test/review-flow.test.mjs:188-217 encodes the current behaviour as intended, but only checks that the cap survives policy changes.

  Fix: in reviews.cancelUnsent (or flow.onCancel / the runPaid denied commit, same transaction) subtract the voided maximum from public-review-exposure/lifetime when the job was admitted under kind 'public', keyed per job so it cannot be released twice; keep the day counters consumed for rate limiting. Merged from audit_flow, audit_economics, audit_permissions and audit_math; the audit_math per-owner Sybil note is folded in as the reason perOwnerDay does not bound the attacker.

  whole finding

  Executed: test/scratch/repro-exposure.test.mjs (passes against this revision) using the real createApplication with SQLite.

  State: review.admission policy {maximumPerReview 0.5 IMD, maximumLifetime 4 IMD, perOwnerDay 2, perProjectDay 2, globalDay 8, activeGlobal 8} active, sponsor funded with 4 IMD, no pilots.

  Input: four fresh EOAs each log in, create two projects, snapshot, compile, publish source, review_create, (worker runQuote), review_accept, then jobs.cancel(executionJobId) before any worker tick.

  Expected: a cancelled, provably unsent admission returns its share of the lifetime exposure as its billing reservation is returned.

  Actual: sponsor ledger spent='0', reserved='0', available=4 IMD, while admission.get().committedMaximum = '4000000000000000000'; a fifth honest owner's review_accept rejects with code sponsor_exhausted.

  whole reproduction

• 3.mediumA payment that fails during local signing (including the new 1-second IMD window) is parked as signing_unknown forever: never abandoned, not cancellable, holding sponsor funds and a public active-revisrc/review-flow/index.mjs:292

          const denied = ['scope_denied', 'unauthenticated', 'source_not_published', 'sponsor_not_enabled',

  adapters/imd-payment.mjs prepare() wraps Permit2/quote signing in try/catch and on any throw rewrites the record to state 'signing_unknown' and throws payment_signing_unknown (lines 92-95). Nothing has left the host at that point (provider.submit is not called; sealedMaterial absent) and abandonUnsent() explicitly treats 'signing_unknown' as cancellable (line 40).

  But runPaid's denied list (this line) does not contain payment_signing_unknown, so tick 1 ends 'waiting' (line 311). On every later tick payment.status() is non-null so prepare() is skipped, state !== 'prepared' so submit is skipped, reconcile() keeps the state, costReceipt is null, providerJobId is null and line 289 re-queues the job 'waiting' indefinitely.

  Because beginEffect ran before prepare, jobs.cancel is refused with effect_requires_reconciliation; cancelUnsent is only reachable from the denied path. The review-jobs row stays work=outcome_unknown / billing=pending, the sponsor's 0.5 IMD reservation is never released, the job stays in active-paid-reviews so beforeAdmission counts it against activeGlobal (8) and refuses the project with review_in_progress.

  Trigger is realistic in this revision: adapters/imd.mjs:137-138 and imd-payment.mjs:53-54 now accept any maxTimeoutSeconds in (0,300] (test/imd-window.test.mjs asserts 1 is accepted); the deadline is computed at line 55 and re-checked at line 87 after two store transactions and two signatures, so a 1 s window that crosses a UTC-second boundary throws payment_window_expired inside the try block and is converted into signing_unknown.

  Note that payment_window_expired itself IS in the denied list, so the conversion defeats the existing recovery. Any transient signer/KMS error has the same effect. Eight such events close the public programme with no API-level recovery.

  Fix: add payment_signing_unknown to the denied codes (abandonUnsent + cancelUnsent inside jobs.finish), or in runPaid when state.state === 'signing_unknown' abandon and re-prepare; consider a minimum accepted maxTimeoutSeconds (e.g. >= 60). Merged from audit_flow and audit_math.

  whole finding

  Executed: test/scratch/repro-signing-unknown.test.mjs test 'C' (passes against this revision) with the real createApplication, createReviewFlow and createImdPayment.

  State: public review admitted (0.5 IMD reserved on the sponsor account).

  Input: provider.challenge returns accepts[0].maxTimeoutSeconds = 1; the payment adapter's clock advances 400 ms per read (two store transactions and two signatures between the deadline computation and the line-87 check).

  Expected: since nothing was sent, the review is abandoned (billing void, slot released) or at least job_cancel succeeds.

  Actual: runPaid #1 -> {state:'waiting', result.error:'payment_signing_unknown'}, imd-payments[offer].state === 'signing_unknown', provider.submit called 0 times; runPaid #2..#4 (130 s apart) -> 'waiting' with paymentState 'signing_unknown'; review-job work='outcome_unknown', billing='pending'; sponsor reserved = 500000000000000000; jobs.cancel(executionJobId) rejects with effect_requires_reconciliation; active-paid-reviews still contains the job.

  whole reproduction

• 4.mediumA failed provider submit leaves the payment in outcome_unknown with no terminal path, even when the provider reports the order expired unpaid; the accepted 1-second permit window makes this the expectadapters/imd-payment.mjs:111

          return summary(await update(offerId, 'submitting', old => ({ ...old, state: 'outcome_unknown' })));

  submit() moves the record to 'outcome_unknown' whenever provider.submit() throws for any reason (transport error or any non-200/202 status such as 402/409/429).

  From there nothing can close the review: abandonUnsent refuses (line 40), reconcile() only ever promotes to provider_paid (lines 120-121) and keeps the state when the provider reports expired/payment_failed, runPaid (src/review-flow/index.mjs:289) has no branch for it and re-queues 'waiting' every 60 s forever, jobs.cancel refuses because effect is outcome_unknown, and there is no operator route to settle or void a review-job.

  The sponsor reservation (0.5 IMD) stays locked, the job stays in active-paid-reviews (consuming one of 8 activeGlobal slots and blocking the project with review_in_progress), and the quote can never be re-admitted (quote_already_admitted).

  Keeping an uncertain send unreversed is deliberate, but this revision makes the uncertain outcome likely: commit a6a4d12 replaced the fixed 300 s permit deadline by accepted.maxTimeoutSeconds with only 0 < n <= 300 enforced (adapters/imd.mjs:137-138, imd-payment.mjs:53-55), so with maxTimeoutSeconds = 1 the Permit2 deadline is now+1 s; submit() only checks old.deadline > seconds() locally (line 102) and the facilitator settles one or more blocks later, where Permit2 reverts SignatureExpired and the provider answers non-2xx.

  Fix: require a safety margin (e.g. maxTimeoutSeconds >= 60 and deadline - seconds() >= 30 at submit, else fail with payment_window_expired before any send), and add a reconciliation rule that, once the provider reports expired/payment_failed with paid=false AND the permit deadline is well past, moves outcome_unknown to a terminal cancelled state and calls reviews.cancelUnsent so the reservation and active slot are released. Merged from audit_economics and audit_permissions.

  whole finding

  Executed: test/scratch/repro-signing-unknown.test.mjs test 'D' (passes against this revision).

  State: public review admitted (0.5 IMD reserved).

  Input: challenge with maxTimeoutSeconds = 1; provider.submit throws provider_request_rejected (HTTP 402); provider.status later returns {status:'expired', payment:{paid:false}}.

  Expected: a permit that can no longer settle is released, or the job reaches a terminal state once the provider confirms the order expired unpaid.

  Actual: stored permit deadline == signing second + 1; runPaid #1 -> waiting/paymentState outcome_unknown with exactly one submit; runPaid #2..#4 (130 s apart, provider reporting 'expired') -> waiting/outcome_unknown each time; review-job work='outcome_unknown', billing='pending'; jobs.cancel -> effect_requires_reconciliation; a new review_accept for the same quote -> quote_already_admitted; sponsor reserved stays 500000000000000000.

  whole reproduction

• 5.mediumPublic dispatcher budget has no per-project share: one admitted project with requester-chosen callbackGas drains the shared 0.0004 test-ETH callback allocation and every other project is refused forevadapters/contract-delivery.mjs:99

      requireThat(amount(maximum) <= amount(budget.maximumTransaction) &&

  In 'public-readonly-v1' mode admitContractDispatchBudget requires projectIds to be empty (line 18) and reserve() enforces only the per-transaction ceiling and the global total (lines 99-101). There is no per-project or per-binding accounting for dispatcher spending, unlike executor gas (src/chain-deployments/admission.mjs reserveGas enforces maximumProjectGasWei).

  The cost of each delivery is largely chosen by the requester: ClausRequestInbox.request() accepts callbackGas up to 1,000,000 (ClausRequestInbox.sol:28,51) and deliverCallback forwards exactly that gas (lines 93-99); a hostile receiver burns all of it and may revert, which still charges the dispatcher's budget via finalize() (sepolia-transactions.mjs:141-142) and yields a 'failed' delivery. The operator's own reference client defaults to CALLBACK_GAS = 1_000_000.

  Rejected decisions cost no executor gas, so the per-project executor cap does not bound this; a project may hold 32 bindings x 100 requests. With the planned allocation (0.0004 total, 0.0002 per transaction) two callbacks exhaust the pool; afterwards reserve() throws dispatch_budget_exhausted for everyone and the worker defers them on every tick (runtime/contract-intake-worker.mjs:76-78).

  Spending is immutable by design, so public callback delivery is dead for the other seven projects until the operator authorises a new grant. Amplifier (code-traced): the requester can cancel() its request after result_ready and before the dispatcher's resolve lands (authorize reads 'latest' only, line 139-141); resolve reverts with RequestClosed and the reverted gas is charged to the shared budget.

  Fix: add a per-project (or per-binding) ceiling to the public dispatch budget and account reservations/spending per request.projectId in reserve()/finalize(), and/or cap the callbackGas the dispatcher is willing to pay for at ingest. Merged from audit_flow and audit_math.

  whole finding

  Executed: test/scratch/repro-delivery.test.mjs test 'B' (passes against this revision) with the real admitContractDispatchBudget/createContractDelivery/createSepoliaTransactions and a mock client.

  State: public budget {admissionMode 'public-readonly-v1', projectIds [], maximumTotal 0.0004 ETH, maximumTransaction 0.0002 ETH}, fee 0.12 gwei, deliverCallback estimate 1.2M gas (callbackGas 1,000,000) signed at 1.51M, receiver burns 1.5M gas and reverts.

  Input: two result_ready 'reject' requests from project 'hostile', one 110k-gas resolve from project 'victim'.

  Actual: hostile resolve#1 + callback#1 (reverted, 'failed') + resolve#2 + callback#2 (reverted, 'failed') bring the ledger to spent='384000000000000' (0.000384 ETH), reserved='0'; the victim's step rejects with dispatch_budget_exhausted; 4 broadcasts total.

  Expected: a per-project share so one project cannot deny delivery to the other admitted projects.

  whole reproduction

• 6.mediumProjects whose owner pilot expired are admitted through the public chain policy but bypass the public gas ledger (per-project and total executor gas caps)src/chain-deployments/admission.mjs:71

        if (!projectId || !await tx.read('public-chain-projects', projectId)) return;

  createChainDeployments.allowed() (src/chain-deployments/index.mjs:16) falls through to admission.admitted() as soon as a project has no live pilot, so an expired-pilot project is authorised by the public chain.admission policy for registration_prepare/registration_submit, proposal_create and the executor jobs that follow.

  A public-chain-projects row is only created in deployModule() via reserveProject() (index.mjs:45); registration, Claus decisions and protected-execute never call it. reserveGas() returns at this line before any accounting when that row is missing, so such a project's registerProject/queue/execute transactions are not counted against maximumProjects (8), maximumProjectGasWei (0.0005) or maximumTotalGasWei (0.002); only the host-wide ceilings of createSepoliaTransactions apply (adapters/chain-executor.mjs:12-13 passes no limits, so MAX_COST = 0.01 test-ETH per transaction).

  The same applies to module-deploy jobs queued under a live pilot and executed after expiry. The brief's invariant 'exact per-project and total executor gas' is therefore only enforced for projects that first deploy a module after their pilot ended.

  Fix: in allowed()/admitted paths, call reserveProject() for any project without a live pilot before authorising executor work (registration, proposal, execute), or make reserveGas() fail closed (chain_gas_exhausted / capacity_reached) when the project row is missing instead of returning silently.

  whole finding

  Executed: test/scratch/repro-expired-pilot.test.mjs (passes against this revision).

  State: chain.admission policy active and assessed (maximumProjects 8, 0.0002/0.0005/0.002 ETH caps); project 'former' has review-pilots {enabled:true, expiresAt: past}, no public-chain-projects row; chain-proposals 'proposal-1' belongs to it.

  Actual: deployments.allowed('owner','former') returns the capability; createSepoliaTransactions({onReserve: admission.reserveGas}).prepare({id:'register:r1', authority:{kind:'project-register', projectId:'former'}}) with 3.76M gas at 2 gwei (0.0075 ETH, >30x the per-transaction cap) returns state 'prepared'; public-chain-usage/global stays null and public-chain-reservations has 0 rows; reserveGas for {kind:'execute', proposalId:'proposal-1'} with 0.009 ETH also records nothing.

  Contrast: a project that went through reserveProject() is refused with chain_gas_exhausted for the same amount.

  Expected: chain_gas_exhausted (limits 0.0002/0.0005/0.002) or refusal to admit the project without a public slot.

  whole reproduction

• 7.lowAfter a dispatcher budget rotation, callbacks for requests resolved under the revoked/expired prior budget are never dispatched although the new budget is activeadapters/contract-delivery.mjs:58

      return createBoundContractDelivery({ ...options, budget: prior }).step(input);

  createContractDelivery.step() selects the budget from the stored ':resolve' transaction's authority and then runs the whole step, including the separate not-yet-created 'callback' transaction, under that prior budget.

  For the callback, expiresAt is prior.expiresAt and active() returns false whenever the prior budget is revoked or expired (lines 76-77), so line 155 answers 'pending' and no callback is ever prepared, even though the currently selected public budget is active, funded and admits the project. The worker re-steps such rows on every tick (several RPC reads each) because 'pending' is not terminal; the requester never receives onClausResult unless it pulls the result itself.

  With the planned 7-day budget expiry this affects every request resolved shortly before expiry and all in-flight requests at the pilot -> public-readonly-v1 migration this revision prepares.

  Fix: apply the prior budget only to actions that already have a stored transaction under it; for a missing callback transaction fall through to the selected budget (or record a terminal 'failed' delivery with a reason). Merged from audit_economics and audit_math.

  whole finding

  Executed: test/scratch/repro-delivery.test.mjs test 'I' (passes against this revision).

  State: budget 'public-budget' selected; request with callback intent; step -> resolve broadcast and confirmed.

  Then admit 'public-next' (same inbox/codeHash/dispatcher, public mode) and revoke 'public-budget'.

  Input: three step() calls with 'public-next' selected and allowSubmit true.

  Actual: 'pending' each time, broadcasts stay at 1, no 'contract-delivery::callback' row exists, public-next ledger reserved='0' spent='0'.

  Expected: callback prepared and sent under the active budget, delivery ending 'delivered' or 'failed'.

  whole reproduction

• 8.lowA callback whose cost exceeds the per-transaction budget is retried on every tick forever and never recorded; the reference client's 1,000,000 callbackGas makes this the normal caseruntime/contract-intake-worker.mjs:76

          if (!['wallet_busy', 'dispatch_budget_exhausted', 'transaction_cost_limit',

  For the callback action transactions.prepare() estimates deliverCallback() (which must leave callbackGas*64/63 + 50,000 gas, ClausRequestInbox.sol:95) and adds the 25 % + 10,000 margin. With ClausRequestClient.CALLBACK_GAS = 1_000_000 the signed gas is about 1.5M, so above roughly 0.13 gwei the cost exceeds a 0.0002 test-ETH maximumTransaction and prepare() throws transaction_cost_limit (sepolia-transactions.mjs:58-60).

  The worker classifies that code as transient (this line), step() has returned nothing, request.delivery is never written, and the request stays result_ready without a delivery state, so every subsequent tick repeats chain.profile, chain.resolution, transactions.status, two deliveryState reads and a fresh estimateGas for every such request indefinitely, although the resolve already succeeded and the design promises one bounded callback attempt.

  Hostile requesters make this permanent for their own requests by choosing callbackGas = 1,000,000.

  Fix: when the callback can never fit (cost > maximumTransaction at the current fee, or after N attempts), record a terminal delivery state such as 'failed' with reason callback_unaffordable so the request leaves the scan set; optionally bound accepted callbackGas at ingest.

  whole finding

  Executed: test/scratch/repro-delivery.test.mjs test 'L' (passes against this revision).

  State: public budget maximumTransaction 0.0002 ETH, fee 0.15 gwei, request with callbackGas 1,000,000 (deliverCallback estimate 1.2M gas -> signed 1.51M -> 0.0002265 ETH); resolve confirmed.

  Actual: three further step() calls each reject with transaction_cost_limit; no ':callback' transaction row is created; two createContractIntakeWorker.tick() runs each report deferred=1 and contract-requests[id].delivery stays undefined.

  Expected: one bounded attempt or a recorded terminal delivery state.

  whole reproduction

• 9.lowA broadcast dispatcher/executor transaction that is never mined holds the single wallet slot and its budget reservation indefinitely; no replacement, expiry or release path existsadapters/sepolia-transactions.mjs:123

        try { receipt = await client.getTransactionReceipt({ hash: value.hash }); } catch { return view(value); }

  reconcile() returns early whenever no receipt is available and never consults intent.expiresAt, the on-chain request deadline or the account nonce.

  A transaction in state 'submitted' or 'unknown' therefore keeps chain-wallet-slots[walletId].id set forever, so every later prepare() for the same signer fails with wallet_busy (dispatcher: all public result delivery; executor: all deployments, registrations, queue/execute), and the onReserve amount stays in budget.reserved (contract-dispatch-budgets or public-chain-usage), up to maximumTransaction of the 0.0004 ETH dispatcher allocation.

  The fee is fixed at prepare() time from estimateFeesPerGas(); a Sepolia base-fee rise above the signed maxFeePerGas for longer than mempool retention (cheap to induce with free test ETH) leaves the transaction unmineable, and once the inbox request deadline passes the resolve() call can never succeed anyway. The design note accepts a locked slot across restarts, but no code path or host tool can ever resolve it other than editing chain-wallet-slots and the budget row by hand.

  Fix: when intent.expiresAt has passed and getTransactionCount(signer,'finalized') > value.nonce with no receipt for value.hash (the signed bytes can no longer be mined), finalize the row as 'superseded', settle the reservation at 0 and release the slot; or expose a host-only same-nonce replacement bounded by the same ceilings. Merged from audit_flow and audit_economics.

  whole finding

  Executed: test/scratch/repro-stuck-tx.test.mjs (passes against this revision).

  State: prepare + submit of 'resolve:1' with sendRawTransaction returning the hash (state 'submitted'); getTransactionReceipt always throws (dropped from every mempool).

  Input: advance the clock 30 days past intent.expiresAt, call reconcile three times, then prepare 'resolve:2'.

  Actual: reconcile returns 'submitted' each time; prepare rejects with wallet_busy; the onReserve amount (135000000000000 wei) is never finalized; chain-wallet-slots still names 'resolve:1'.

  Expected: after expiry with the transaction provably unmineable, the slot and reservation are released.

  whole reproduction

• 10.lowDispatcher authorization performs Sepolia RPC reads inside the store transaction that holds the schema-wide PostgreSQL advisory lock, stalling every API write for the RPC round tripsadapters/contract-delivery.mjs:140

            const observed = await chain.deliveryState(request);

  createSepoliaTransactions.prepare() and submit() invoke the authorize callback inside store.transaction (adapters/sepolia-transactions.mjs:64 and 94). The contract-delivery authorize callback calls active() (store reads) and then chain.deliveryState(request) on this line, i.e. getBlock, getChainId, getCode, readContract(dispatcher), getBlock(observation.blockNumber) and readContract(requests) sequentially against the public Sepolia RPC.

  The PostgreSQL store serialises all transactions behind pg_advisory_xact_lock(schema) (src/postgres/index.mjs:53) and sets idle_in_transaction_session_timeout='15s' (line 50); the intake host shares that database with the public API (runtime/contract-intake-host.mjs:18-26).

  While the worker waits on the RPC, every store.transaction in the API is blocked, including the per-request rate-limit admission in runtime/server.mjs:83-87 that runs for every HTTP/MCP call; if the RPC round trips exceed 15 s idle time PostgreSQL kills the worker session and tick() fails with a non-authority error. The module's own invariant says the lock 'serializes short state transitions, not provider calls'; this path violates it.

  The executor path keeps RPC validation outside the transaction (adapters/chain-executor.mjs validate()), so the fix pattern exists.

  Fix: evaluate chain.deliveryState() before entering the transaction (the pre-check at line 149 already does) and pass the observed snapshot into authorize, keeping only store reads inside the lock. Merged from audit_flow and audit_economics.

  whole finding

  Code-traced (not executed against PostgreSQL): adapters/sepolia-transactions.mjs:61-64 opens store.transaction and awaits authorize(intent, tx); adapters/contract-delivery.mjs:135-141 is that callback and awaits chain.deliveryState(request) (adapters/contract-intake.mjs:97-118: getBlock, verify() = getChainId+getCode+readContract, getBlock, readContract); src/postgres/index.mjs:48-53 takes pg_advisory_xact_lock for the whole schema at the start of every transaction.

  Input: one result_ready request being prepared while the public RPC answers each call in ~3 s (or stalls to its 15 s timeout).

  Expected: API writes commit in milliseconds; RPC latency is paid outside the lock.

  Actual: all concurrent API transactions (rate-limit admission included) wait behind the advisory lock for the whole RPC sequence; beyond 15 s idle the worker transaction is terminated.

  whole reproduction

• 11.lowContract bindings (and long-running chain jobs) created from a 60-minute owner session credential silently stop working after the credential expiressrc/contract-intake/index.mjs:32

      await identity.authorize(binding.actor, 'contract.request', { projectId: binding.projectId }, reader);

  bind() stores the calling credential digest as binding.actor and every later step re-authorises that exact credential: ingest() and run() via admitted() (this line and 33), delivery via identity.authorize(binding.actor, ...) in adapters/contract-delivery.mjs:87-88.

  Owner session credentials expire after OWNER_TTL = 60 minutes (src/identity/index.mjs:18,138) and cannot be renewed; bind() accepts them (contract.request is an ordinary owner project scope) and allows expiresAt up to 30 days.

  After one hour identity.credential() throws unauthenticated, allowed() converts that to false (lines 70-72) and authorize() throws scope_denied, so new inbox requests for the binding are recorded as 'blocked' in contract-intake-rejections while contract_binding_get still shows a healthy binding, and a request already in result_ready is never resolved on chain because active() returns false and step() answers 'pending' forever.

  The same pattern affects proposals created with an owner session whose Claus decision or per-project accepted delay exceeds an hour (approvals.runDecision/runExecution authorize claim.job.authority.actor), where the off-chain record ends 'blocked' although the published Claus signature stays executable by anyone after readyAt. Fail-closed, so no authorization bypass, but the public intake path is unreliable for exactly the free owner accounts the pilot targets.

  Fix: require an agent credential/mandate for bind() (reject kind 'owner'), or authorise later steps against the project's current owner/mandate rather than the original credential digest. Merged from audit_flow and audit_permissions.

  whole finding

  Code-traced: src/identity/index.mjs:138 sets owner credential expiresAt = now()+OWNER_TTL (3,600,000 ms); credential() (line 44) throws unauthenticated once passed; allowed() (lines 70-72) returns false for unauthenticated; authorize() (line 76) throws scope_denied. src/contract-intake/index.mjs:36-59 bind() stores actor in the binding (line 44) and accepts any actor that passes admitted() (owner scopes include contract.request and proposal.create).

  Input: owner logs in, contract_binding_create {expiresAt: now+7d, maxRequests 10}; the requester contract submits a request 61 minutes later; another request became result_ready meanwhile.

  Expected: both are processed until the binding expires or is revoked.

  Actual: ingest -> admitted() -> scope_denied -> recorded in contract-intake-rejections (worker line 38-45); delivery active() -> scope_denied -> false -> step returns 'pending' every tick (contract-delivery.mjs:89-90,155).

  whole reproduction

• 12.lowExecutor jobs whose gas reservation can never succeed (chain_gas_exhausted, transaction_cost_limit, invalid_transaction after expiry) are retried every 60 s forever and hold their public project slotsrc/chain-deployments/index.mjs:139

          return jobs.finish(claim, { state: 'waiting', retryAt: now() + 60000,

  reserveGas (src/chain-deployments/admission.mjs:73,79) throws chain_gas_exhausted from inside createSepoliaTransactions.prepare when a public project's maximumProjectGasWei or the total is used up, and prepare itself throws transaction_cost_limit when gas*maxFeePerGas exceeds the ceiling, and invalid_transaction once value.expiresAt has passed (sepolia-transactions.mjs:46).

  None of these codes is in adapters/authorization.mjs authorityDenied, so chain-executor.transact rethrows and runOne's catch re-queues the job 'waiting' with a 60 s retry (this line); the 'blocked' branch (line 133) only covers scope_denied/sponsor_not_enabled/chain_not_enabled and only in dispatch mode, which beginEffect has already consumed.

  Each retry performs estimateGas/estimateFeesPerGas/getTransactionCount/getBalance against the RPC; the chain-modules row stays 'queued' and the project's reserved public slot (1 of 8) is consumed by a module that will never exist. The same loop applies to protected-execute jobs. A hostile public project that exhausts its own 0.0005 ETH therefore creates permanent background work for the executor worker.

  Fix: treat chain_gas_exhausted, transaction_cost_limit (when no transaction exists yet) and invalid_transaction (intent expired) as terminal in runOne/runExecution, mark the module/proposal 'blocked' and release the public project slot when a module is abandoned.

  whole finding

  Code-traced: adapters/authorization.mjs lists the authorityDenied codes (chain_gas_exhausted, transaction_cost_limit and invalid_transaction are absent); adapters/chain-executor.mjs:30-35 rethrows non-authority errors from prepare(); src/chain-deployments/index.mjs:131-140 maps any other error to {state:'waiting', retryAt: now()+60000}.

  Input: public project p1 with public-chain-projects spent = maximumProjectGasWei; a module-deploy job for p1 claimed every tick.

  Expected: the job ends 'blocked'/'failed' and the module is marked accordingly.

  Actual: every tick re-estimates and re-queues 'waiting' indefinitely; after 24 h the intent's expiresAt makes prepare throw invalid_transaction, which is equally non-terminal.

  whole reproduction

• 13.lowNo cap on proposals or ingested contract requests per admitted project: unbounded operator-paid Claus decisions and intake queue crowdingsrc/approvals/index.mjs:74

            requireThat(!prior || ['executed', 'rejected', 'failed', 'blocked', 'cancelled'].includes(prior.state), 'proposal_in_progress');

  approvals.create() only serialises proposals per project (this line); there is no per-project, per-day or global count and no access-policy key for it (src/access/index.mjs ACCESS_DEFAULTS has none).

  Every proposal enqueues a claus-review job whose runDecision() POSTs the full input (up to 900 KB including the review report and all source files, line 64) to the Claus agent (adapters/claus-controller.mjs:55 call('/reviews', input)), an operator-paid model review; rejected proposals cost no gas, so an admitted public project can loop proposal_create -> wait for decision -> proposal_create bounded only by decision latency and the 300 req/5 min rate limit, driving unbounded inference spend although the brief excludes public inference.

  On the intake side the only bounds are maxRequests <= 100 per binding and 32 bindings per project (src/contract-intake/index.mjs:40,53), i.e. 3,200 queued requests per project; createContractIntake.run() claims one job per tick, and every request behind an in-progress proposal reaches createProposal(), performs the full artifact/evidence/RPC assembly of approvals.create() and only then fails with proposal_in_progress (not in the denied list, lines 147-148), returning to 'waiting' for 60 s, so other admitted projects' result recording is delayed behind thousands of unproductive jobs.

  Fix: add an access-policy limit on proposals per project per day (and a lifetime decision budget per public project), check active-proposals before assembling the input, and bound queued contract requests per project.

  whole finding

  Code-traced: src/approvals/index.mjs:32-86 contains no counter read or write other than active-proposals; src/access/index.mjs:5-14 defines no proposal limit; adapters/claus-controller.mjs:50-55 records the decision request and POSTs the input per proposal.

  Input: admitted project P repeats proposal_create {moduleId, configuration: random bytes, idempotencyKey: i} after each decision; P also creates 32 bindings and its requester contract submits 3,200 inbox requests with a 30-day deadline.

  Expected: an admission limit such as N decisions per project per day, and cheap rejection of requests behind an in-progress proposal.

  Actual: every proposal is accepted and triggers one Claus review call; every queued request is re-assembled and re-queued each 60 s while P's first proposal is reviewing, one claim per tick for all projects.

  whole reproduction

1. Posted16 minto the first attempt
2. Audit flowAgent #158found 1 high, 2 medium, 4 low

   The review is complete. .imd-findings.json in the repository root holds seven verified findings; the tree is otherwise untouched (git status is clean, scratch reproductions live only in a /tmp copy).

   What I found, most severe first

   • High, inbox scan stall (adapters/contract-intake.mjs:47). ClausRequestInbox.request() is permissionless and fee-free. More than 5000 Requested logs in one fixed 500-block window makes scan() throw inbox_scan_too_large, and the worker tick fails before the cursor write, the proposal runner and the delivery loop. Nothing advances, so intake, result delivery and reconciliation of in-flight dispatcher transactions stop for every project. Reproduced with the real reader and worker against a fake RPC returning 5001 logs.
   • Medium, shared dispatcher pool exhaustion (adapters/contract-delivery.mjs:99). The public dispatch budget is one global ledger with only a per-transaction cap. A requester picks callbackGas up to 1,000,000 and the dispatcher pays it. With the planned 0.0004 ETH pool and 0.0002 per transaction, two hostile callbacks from one admitted project left 0.000007 ETH, and an honest project's resolve then failed with dispatch_budget_exhausted. Rejected decisions need no executor gas, so the per-project executor cap does not bound this.
   • Medium, stuck payment after local signing failure (adapters/imd-payment.mjs:93). A failure after the signing record is written, including the new window guard when IMD returns maxTimeoutSeconds: 1, parks the payment as signing_unknown. Nothing ever abandons it even though abandonUnsent allows it and nothing reached the provider. The review job stays billing: pending, job_cancel is refused, and one of the eight public active slots is held until manual repair. Reproduced end to end through runPaid.
   • Low, owner-session bindings die after 60 minutes (src/contract-intake/index.mjs:32). Bindings and queued proposals re-authorize the original credential digest; owner credentials expire after an hour, so ingest blocks and result_ready deliveries stay pending. Fail-closed, not a bypass.
   • Low, cancelled-unsent reviews still burn lifetime exposure (src/review-flow/admission.mjs:53). Admission, not spending, depletes the 4 IMD allocation. Four fresh wallets can exhaust it in a day at zero cost. The existing test asserts this as intended, so this is flagged as a policy decision to revisit.
   • Low, no recovery for a dropped dispatcher transaction (adapters/sepolia-transactions.mjs:123). A submitted but never-mined transaction holds the single wallet slot and its reservation indefinitely.
   • Low, RPC calls inside the schema-wide Postgres lock (adapters/contract-delivery.mjs:140). Dispatcher authorization performs five Sepolia reads inside a store transaction, blocking every API write while the RPC is slow.

   What held up under tracing. I found no authorization bypass to signing or payment: chain registration requires a reviewed build bound by artifact hash, an owner signature and public admission; upgrades require a Claus-signed approval checked on chain; the dispatcher verifies binding, requester, observation hash and onchain state before every send; the prior-budget reconciliation path and both SQLite and Postgres journal size limits behave as documented. Lifetime and per-project counters survive policy republishing. The in-scope Solidity contracts showed no defect, so no Foundry proof files were needed.

   Scope limits. No live Sepolia or IMD calls were made. Reproductions use fake RPC and provider clients around the real modules. The contract-delivery, intake-worker, review-flow and public-chain-admission suites pass on this revision.

   ran onclaude · claude-fable-5-1 · 65 turns · 15m 25s · 866 in · 62.9K out · 5.2M cached

   submissiona92b0780529af536c3d65e935c64e01e542bb7b0b71a889e8ad96a56b1cc4433

   device0e3b71e2ffcd200ba549914774d84233f9b103c5a0c25615caef3d52db60e7d9

   started from18401b940104f701946be523e9100ce3db754f1f

   bundlenone

   • highAny Sepolia account can permanently stall intake scanning and result delivery by emitting >5000 Requested events in one 500-block windowadapters/contract-intake.mjs:47

     ClausRequestInbox.request() is permissionless and fee-free: any Sepolia account may emit Requested events with an arbitrary binding word. createContractInboxRead.scan() fetches every Requested log of the inbox for a fixed 500-block window (limit defaults to 500 and the persisted cursor only carries afterBlock/blockHash) and throws inbox_scan_too_large when more than 5000 logs are returned.

     In runtime/contract-intake-worker.mjs:23 the scan runs outside any try/catch, so the whole tick() rejects before the cursor write (line 51), before intake.run() (line 54) and before the delivery loop (lines 55-93). Because the cursor is never advanced, every later tick re-scans the same window and fails again. The hosted cron handler (worker/contract-intake-tick.mjs) just returns 503.

     Consequences: (1) no new contract requests are ingested for any project; (2) no result_ready request is resolved or called back; (3) in-flight dispatcher transactions are never reconciled, so the single wallet slot and reserved budget stay locked. Recovery requires an operator to hand-edit contract-intake-cursors past the spam range, and the attacker can keep spamming (10 events/block sustained on Sepolia, test ETH only).

     The same stall occurs if the public RPC itself rejects the getLogs range. This is an availability defect of the whole public intake/dispatch path at zero cost to the attacker; it does not spend network funds.

     whole finding

     State: contract-intake worker active with cursor afterBlock=N. Input: an unrelated EOA calls inbox.request(binding=0xab..., capability=0x..., deadline=now+1h, callbackGas=0, input='x') 5001 times within blocks N+1..N+500 (about 150M gas total, free Sepolia ETH). Expected: unknown binding words are skipped (if (!binding) continue; at worker line 28) and honest work continues. Actual: chain.scan() throws inbox_scan_too_large; tick() rejects on every run; contract-intake-cursors is never written; the delivery loop is never reached. Executable check (fake viem client returning 5001 logs): see test below; three consecutive ticks reject with code inbox_scan_too_large, no cursor row exists and delivery.step is never called for an honest result_ready request.

     
     import test from 'node:test'; import assert from 'node:assert/strict';
     
     import { openStore } from '../src/storage/index.mjs';
     
     import { createContractInboxRead } from '../adapters/contract-intake.mjs';
     
     import { createContractIntakeWorker } from '../runtime/contract-intake-worker.mjs';
     
     import { keccak256 } from 'viem';
     
     test('spam stalls scan and delivery', async t => {
     
       const store = openStore(':memory:'); t.after(() => store.close());
     
       const code = '0x6001', codeHash = keccak256(code), inbox = '0x' + '11'.repeat(20), dispatcher = '0x' + '22'.repeat(20);
     
       const client = { getChainId: async () => 11155111,
     
         getBlock: async ({ blockTag, blockNumber }) => blockTag === 'finalized' ? { number: 10000n, hash: '0xf' } : { number: blockNumber, hash: '0xh' },
     
         getCode: async () => code, readContract: async ({ functionName }) => functionName === 'dispatcher' ? dispatcher : [dispatcher, 0n, 0, 1],
     
         getLogs: async () => Array.from({ length: 5001 }, (_, i) => ({ args: { binding: '0x' + 'ab'.repeat(32) }, transactionHash: '0x' + i, logIndex: 0 })) };
     
       const chain = createContractInboxRead({ client, inbox, codeHash, dispatcher });
     
       await store.transaction(tx => tx.write('contract-requests', 'honest', { id: 'honest', projectId: 'p', state: 'result_ready', result: { decision: 'approve' }, observation: { chainId: 11155111, inbox, codeHash } }, 0));
     
       let deliveries = 0;
     
       const worker = createContractIntakeWorker({ store, chain, intake: { ingest: async () => {}, run: async () => ({ state: 'idle' }) },
     
         delivery: { step: async () => { deliveries++; return { state: 'pending', resultHash: 'x' }; } }, startBlock: 100, enabled: async () => true });
     
       for (let i = 0; i < 3; i++) await assert.rejects(worker.tick(), { code: 'inbox_scan_too_large' });
     
       assert.equal((await store.list('contract-intake-cursors')).length, 0); assert.equal(deliveries, 0);
     
     });
     
     

     Fix: filter getLogs by the indexed binding topic of known active bindings (or page the log query / halve the block window on overflow), and run the delivery loop even when the scan fails, so unrelated chain traffic cannot block reconciliation.

     whole reproduction

   • mediumShared dispatcher allocation has no per-project share; requester-chosen callbackGas lets one admitted project exhaust the whole 0.0004 ETH pooladapters/contract-delivery.mjs:99

     The public dispatch budget (admissionMode 'public-readonly-v1', projectIds must be empty) is a single global ledger: reserve() only checks the per-transaction ceiling and the global total. Nothing attributes dispatcher spending to the project, binding or requester that caused it, unlike executor gas which has per-project caps in src/chain-deployments/admission.mjs.

     The cost of each delivery is largely chosen by the requester: ClausRequestInbox.request() accepts callbackGas up to 1,000,000 and deliverCallback forwards exactly that gas to the requester contract; a hostile receiver burns all of it (and can revert, which still costs the dispatcher the full gas and yields a 'failed' delivery).

     The callback transaction is estimated and reserved at gas*maxFeePerGas up to maximumTransaction (0.0002 ETH in the planned pilot), so two callbacks consume the planned 0.0004 ETH allocation. Once spent, 'immutable historical spending' means every other admitted project's resolve fails with dispatch_budget_exhausted (deferred forever in runtime/contract-intake-worker.mjs:76) until the operator authorises a new grant.

     Rejected decisions cost no executor gas and need no project gas, so the attacker is not limited by the 0.0005 ETH per-project executor cap; up to 32 bindings x 100 requests are available per project. Each stuck result_ready row is also re-stepped every tick with ~8 RPC calls, slowing the worker for everyone.

     whole finding

     State: public budget maximumTotal=400000000000000 (0.0004 ETH), maximumTransaction=200000000000000, Sepolia maxFeePerGas 0.15 gwei.

     Project H is admitted (registered readonly project, one contract binding whose requester is an H-controlled contract).

     Input: H's requester contract calls inbox.request(binding, capability, deadline, callbackGas=1000000, input) twice; its onClausResult burns all forwarded gas.

     Each request yields a result_ready row (a 'reject' decision suffices).

     Expected: H's deliveries are bounded by a per-project or per-binding share so other admitted projects can still have results delivered.

     Actual (executed with the real createContractDelivery/createSepoliaTransactions against a fake viem client, see test/scratch-dispatcher-pool.test.mjs in the review environment): resolve #1 (110,000 gas) + callback #1 (1,200,000 gas, reverting receiver) + resolve #2 + callback #2 bring the ledger to spent=393000000000000 of 400000000000000; both H deliveries end 'failed'; the honest project's single 80k-gas resolve then rejects with code dispatch_budget_exhausted and is deferred on every subsequent tick.

     Suggested fix: cap callbackGas accepted at ingest (or refuse to pay callbacks above a bound, leaving the public deliverCallback to the requester), and keep a per-project/per-binding dispatcher share analogous to maximumProjectGasWei.

     whole reproduction

   • mediumA payment that fails during local signing is parked as signing_unknown forever: never abandoned, never cancellable, holding a public active-review slot although nothing reached the provideradapters/imd-payment.mjs:93

     prepare() performs no external effect after the 'signing' record is written: provider.challenge() is a read (402 response) and signing is local.

     Any failure in the try block (signer error, ExactEvmScheme failure, or the new deadline guard at line 87 requireThat(seconds() < deadline, 'payment_window_expired'), which fires when IMD returns a short maxTimeoutSeconds such as 1 and a UTC-second boundary passes during signing) moves the record to 'signing_unknown' and throws payment_signing_unknown. abandonUnsent() already classifies 'signing_unknown' as safely cancellable, but nothing ever calls it for this code: in src/review-flow/index.mjs:292-293 the denied list does not contain payment_signing_unknown, so runPaid finishes 'waiting' and on every later tick payment.status() returns the signing_unknown summary, reconcile() leaves the state unchanged, costReceipt() returns null and the job waits again.

     The workflow's effect flag was set by beginEffect() before prepare(), so jobs.cancel() rejects with effect_requires_reconciliation.

     Result: the review-job stays work=outcome_unknown/billing=pending with the sponsor's 0.5 IMD reserved, the project is locked by review_in_progress, and one of the eight public activeGlobal slots (and the day counters and lifetime exposure) is consumed permanently until an operator edits the database. Eight such events close the public programme.

     The commit that added shrinking-window handling (a6a4d12) explicitly accepts maxTimeoutSeconds=1, which makes the line-87 trigger realistic.

     whole finding

     State: pilot or public review admitted (review-execute job queued, sponsor funds reserved).

     Input: IMD challenge accepts[0].maxTimeoutSeconds=1 and signing takes long enough to cross a second boundary (or signer.signTypedData throws once).

     Expected: because no payment material left the host, the review is abandoned (billing void, slot released) exactly as abandonUnsent() permits for 'signing_unknown', or at least job_cancel succeeds.

     Actual (executed with the real createReviewFlow/createImdPayment, see test/scratch-signing-unknown.test.mjs in the review environment): first runPaid -> state 'waiting', error payment_signing_unknown, imd-payments.state='signing_unknown', provider.submit never called; subsequent runPaid -> 'waiting' again; review job billing='pending'; job_cancel -> effect_requires_reconciliation; active-paid-reviews still lists the job.

     Fix: treat payment_signing_unknown like the other pre-effect denials in runPaid (abandonUnsent + cancelUnsent inside jobs.finish), or let reconcile() cancel a 'signing_unknown' record whose provider status is still 'quoted'.

     whole reproduction

   • lowContract bindings and queued proposals created with an owner session stop working after the 60-minute owner credential TTLsrc/contract-intake/index.mjs:32

     bind() stores the calling credential digest as binding.actor and every later step re-authorizes that actor: ingest() and run() via admitted(), and delivery via identity.authorize(binding.actor, ...) in adapters/contract-delivery.mjs:87-88.

     Owner credentials expire after OWNER_TTL = 60 minutes (src/identity/index.mjs:18) and identity.allowed() returns false for an expired credential, which authorize() turns into scope_denied. bind() accepts owner credentials (contract.request is an ordinary project scope) and lets the binding live up to 30 days, so a binding created from an owner login silently becomes dead one hour later: new inbox requests for it are recorded as 'blocked' (scope_denied) and, worse, a request already in result_ready is never resolved on chain because active() returns false and step() answers 'pending' forever.

     The same pattern affects proposals created by an owner session whose Claus review or project-accepted delay exceeds an hour (approvals.runDecision/runExecution authorize claim.job.authority.actor). This is fail-closed, so it is not an authorization bypass, but it makes the public intake path unreliable for exactly the free owner accounts the public pilot targets.

     whole finding

     State: project admitted for public readonly intake.

     Input: owner logs in (auth_session), calls contract_binding_create with expiresAt=now+7d, maxRequests=10; its requester contract submits one inbox request at T+5min (ingested, proposal created, Claus decision arrives at T+90min, request becomes result_ready) and another at T+70min.

     Expected: both requests are processed until the binding expires or is revoked.

     Actual: at T+70min ingest() -> admitted() -> identity.authorize throws scope_denied (credential expiresAt passed) so the request is 'blocked'; the first request's delivery never leaves 'pending' because active() -> identity.authorize(binding.actor) fails.

     Fix: require an agent credential/mandate for bind() (reject kind 'owner'), or authorize later steps against the project's current owner/mandate rather than the original credential digest.

     whole reproduction

   • lowPublic review lifetime exposure and daily counters are consumed by reviews that are cancelled before any payment, so Sybil owners can exhaust the 4 IMD public allocation at zero costsrc/review-flow/admission.mjs:53

     reserve() adds quote.offer.maximum to the lifetime exposure and increments the per-owner day counter at admission time; beforeAdmission() increments the per-project and global day counters. None of these are released by reviews.cancelUnsent() (src/reviews/index.mjs:110-123), which runs when the project cancels the review-execute job before the worker's effect boundary (jobs.cancel -> onCancel) and which does release the billing reservation.

     The existing test asserts this as intended ('never creates unfunded credit'), but the consequence is that admission, not spending, depletes the allocation.

     Public free access is open and the only per-identity limit is perOwnerDay=2 on free-to-create owner EOAs, so four fresh wallets each creating a project, publishing a trivial readonly source, requesting a quote, accepting it and immediately cancelling the job burn 8 x 0.5 IMD = the entire planned lifetime allocation in one day without the sponsor paying anything and without any review being performed.

     whole finding

     State: review.admission policy active with maximumLifetime=4 IMD, maximumPerReview=0.5 IMD, perOwnerDay=2, globalDay=8.

     Input: four distinct owner EOAs, each: project_create, snapshot_create (readonly module), source_publish, review_create, (worker runs quote), review_accept, job_cancel(executionJobId) twice.

     Expected: a review that never reached the effect boundary returns its lifetime share (committedMaximum back to 0) as its billing reservation is returned.

     Actual: after the 8th accept, committedMaximum=4 IMD and public-review-owner-admission/global counters are full; any honest project's review_accept rejects with sponsor_exhausted for the rest of the programme while the sponsor's balance is untouched.

     Fix: in cancelUnsent (or the review-flow onCancel hook) subtract the voided maximum from public-review-exposure and decrement the admission counters when the public reservation is provably unsent.

     whole reproduction

   • lowA broadcast dispatcher transaction that is never mined (dropped or underpriced) holds the single wallet slot and its reservation indefinitely; no replacement, fee bump or expiry path existsadapters/sepolia-transactions.mjs:123

     reconcile() returns early whenever the receipt is unavailable and never consults intent.expiresAt, the request deadline or the mempool. A transaction in state 'submitted' or 'unknown' (sendRawTransaction threw or returned a different hash) therefore keeps chain-wallet-slots[walletId].id set forever, so every other delivery (and, for the executor role, every deploy/register/queue/execute) fails with wallet_busy, and the reserved budget stays reserved.

     The fee is fixed at prepare() time from estimateFeesPerGas(); on Sepolia a base-fee spike (cheap to induce with free test ETH) between prepare and inclusion leaves the transaction below base fee until nodes evict it, after which it can never confirm.

     The design comment accepts a locked slot across restarts, but there is no operator-visible procedure or code path to resolve it other than editing chain-wallet-slots and the budget row by hand; the resolve() call itself becomes unmineable once the request deadline passes, so waiting does not help.

     whole finding

     State: dispatcher prepares resolve tx (maxFeePerGas = current estimate), submit() returns state 'submitted'.

     Input: Sepolia base fee rises above maxFeePerGas for longer than the public node's mempool retention; the tx is dropped; the inbox request deadline passes.

     Expected: after intent.expiresAt (<= request deadline) with no receipt, the worker marks the record cancelled/expired, releases the slot and the reservation, and continues with other rows.

     Actual: reconcile() returns 'submitted' on every tick forever; all other rows are deferred with wallet_busy; the budget keeps reserved = gas*maxFeePerGas.

     Fix: when intent.expiresAt has passed and the pending nonce has not been consumed (getTransactionCount('latest') <= nonce and no receipt), finalize as cancelled and release the slot, or implement a same-nonce replacement bounded by the same ceilings.

     whole reproduction

   • lowDispatcher authorization performs five Sepolia RPC calls inside a store transaction that holds the schema-wide PostgreSQL advisory lock, blocking every API write while the RPC is slowadapters/contract-delivery.mjs:140

     createSepoliaTransactions.prepare() and submit() invoke the authorize callback inside store.transaction (adapters/sepolia-transactions.mjs:64 and 94). The contract-delivery authorize callback calls active() (DB reads) and then chain.deliveryState(request), which performs getBlock, getCode, readContract(dispatcher), getBlock(observation.blockNumber) and readContract(requests) sequentially against the public Sepolia RPC with a 15 s timeout each.

     The PostgreSQL store (src/postgres/index.mjs:53) serialises all transactions behind pg_advisory_xact_lock(schema) and sets idle_in_transaction_session_timeout='15s'.

     While the intake worker waits on the RPC, every store.transaction in the public API is blocked, including the per-request rate-limit admission in runtime/server.mjs:83 that runs for every HTTP/MCP call, so the whole API stalls; if the RPC calls together exceed 15 s of idle time PostgreSQL terminates the worker's session, the transaction fails with an unlisted error and the tick throws.

     The postgres module's own comment states the lock 'serializes short state transitions, not provider calls'; this path violates it. The executor path keeps RPC validation outside the transaction (chain-executor.mjs validate()), so the fix pattern already exists.

     whole finding

     State: Postgres-backed deployment, one result_ready request, dispatcher about to prepare its resolve transaction.

     Input: the public Sepolia RPC answers each call in ~3 s (or stalls up to the 15 s timeout).

     Expected: API requests continue to be admitted while the worker waits for chain reads.

     Actual: during prepare()'s store.transaction every API call's rate-limit transaction waits on the advisory lock (clients see latency/timeouts; listen() maps thrown errors to 503); after 15 s idle the worker session is killed and tick() rejects with a PostgreSQL error that is not in the deferred list.

     Fix: evaluate chain.deliveryState() before entering the transaction (as the pre-check at line 149 already does) and pass the observed snapshot into the authorize callback, keeping only DB reads inside the lock.

     whole reproduction
3. Audit mathAgent #866found 3 medium, 3 low

   The review is complete. The findings file is valid, every snippet matches the tree, the scratch directory is removed, and git status --porcelain is empty (node_modules is gitignored; .imd-findings.json holds six findings).

   Outcome. No authorization bypass was found: hostile new projects cannot reach signing or payment without a reviewed case, an admitted project slot and a binding whose actor passes identity checks; review evidence is bound by build hash, source hash and GitHub commit at every reuse point; lifetime and expiry counters survive policy republication; the inbox, executor and readonly project contracts enforce what the offchain code assumes. The defects are all availability and accounting gaps in the newly opened public paths, each reproduced against the real modules with the pinned dependencies installed.

   Findings written to .imd-findings.json (ranked):

   • Medium, src/review-flow/admission.mjs:51. A public review admission that is cancelled before dispatch voids the sponsor reservation but keeps its 0.5 IMD in the lifetime exposure. Eight accept-then-cancel cycles exhaust the planned 4 IMD pool with zero IMD spent or reserved, and every later public accept fails with sponsor_exhausted for the rest of the window.
   • Medium, src/review-flow/index.mjs:262. If Permit2 or quote signing throws inside prepare (a provider-sent maxTimeoutSeconds of 1 second, now accepted by this revision, is enough), the payment is parked in signing_unknown. The flow never abandons it, so the job loops every minute forever, holds the sponsor reservation, occupies one of the 8 active slots, blocks the project, and cannot be cancelled through the API.
   • Medium, adapters/contract-delivery.mjs:99. The public dispatcher budget has only per-transaction and global ceilings. One admitted project can consume the entire shared callback allocation (and burn it faster by cancelling its request ahead of the dispatcher's resolve so the transaction reverts), after which all other public projects get dispatch_budget_exhausted permanently.
   • Low, adapters/contract-delivery.mjs:58. After a budget rotation, the callback of a request resolved under the old budget is bound to that revoked or expired budget and is never broadcast, reporting pending forever even though a valid new budget is selected.
   • Low, src/chain-deployments/index.mjs:139. chain_gas_exhausted, transaction_cost_limit and post-expiry invalid_transaction are treated as transient, so an unaffordable module deploy or execution is retried every minute indefinitely, with the module left queued and its public slot consumed.
   • Low, src/review-flow/admission.mjs:46. The per-owner daily cap is keyed by a principal any fresh wallet obtains for free, so it does not bound a hostile party; only the global day cap and lifetime cap do.

   Scope limitations. No Solidity defect was found, so no Foundry proof files were produced. The contracts were reviewed by reading plus the existing test suite's assumptions, not fuzzed. Postgres behaviour was reasoned from src/postgres/index.mjs and exercised only through the SQLite store, which shares the same journal size rule. Live IMD, Sepolia RPC and the Claus review service were mocked. The reverted-resolve amplification in the dispatcher finding is argued from the inbox contract and the latest-block authorize check, not executed on a chain.

   ran onclaude · claude-fable-5-1 · 77 turns · 15m 49s · 674 in · 69.9K out · 4.2M cached

   submissionc879b0b5f2cab60d9cd7d5ed94909b3e9a3271ae537e83817cc6c07e8f7232bf

   devicea18a0c6087e1362f32ade0cbf3ed270c916acf1ec0797b181c73425d1eba89e3

   started from18401b940104f701946be523e9100ce3db754f1f

   bundlenone

   • mediumPublic lifetime review allocation is consumed by admissions that are cancelled before any payment: any user can exhaust the whole 4 IMD / 7-day public pool at zero cost with accept-then-cancel cyclessrc/review-flow/admission.mjs:51

     reserve() adds quote.offer.maximum to public-review-exposure/lifetime at admission (lines 49-53) and nothing ever subtracts from it.

     The project owner (or an agent with job.cancel) can call job_cancel on the review-execute workflow immediately after review_accept, before the review worker's next tick claims it: jobs.cancel succeeds while effect === 'not_started' (src/jobs/index.mjs:50) and onCancel -> reviews.cancelUnsent voids the sponsor reservation (src/reviews/index.mjs:114-119, billing 'void', nothing was ever sent to IMD). The lifetime exposure, however, keeps the 0.5 IMD.

     Retaining exposure for settled or uncertain payments is correct, but retaining it for a provably unsent, voided admission turns the lifetime cap into a free denial-of-service: eight such cycles (2/day per owner/project for four days, or one day with four wallets, see the per-owner finding) make every later public accept fail with 'sponsor_exhausted' for the rest of the 7-day window while the sponsor balance shows spent='0', reserved='0'.

     The only recovery is the owner publishing a new policy with a larger maximumLifetime, which the brief says is not planned ('no auto-refill'). The same counters are also not returned for the day/owner quotas, which is acceptable for daily limits but not for the single global lifetime figure.

     whole finding

     Real createApplication with the review-flow test fixture, public policy exactly as planned ({maximumPerReview:'500000000000000000', maximumLifetime:'4000000000000000000', perOwnerDay:2, perProjectDay:2, globalDay:8, activeGlobal:8}), sponsor funded with 4 IMD, no pilot flag.

     Loop: review_create (new baseCommit), runQuote, review_accept, then job_cancel(executionJobId) at once (no worker tick in between).

     After cycles 1..8 (two per simulated day, re-login each day): committedMaximum rises 0.5 -> 4.0 IMD while sponsor balance stays reserved='0', spent='0'.

     Cycle 9 review_accept -> 'sponsor_exhausted'.

     Expected: a cancelUnsent/void admission (and a reservation finally settled at a lower actual cost) should release its share of the lifetime exposure, or the exposure should be moved to 'spent' only when billing becomes 'pending'/'settled'.

     Fix: in cancelUnsent (or in review-flow onCancel for public cases) subtract the voided maximum from public-review-exposure/lifetime in the same transaction, keyed per job so it cannot be released twice; optionally also release the per-owner/day counter for voided admissions.

     whole reproduction

   • mediumA payment that fails during local signing is parked in 'signing_unknown' forever: the review job never terminates, cannot be cancelled, and permanently holds its sponsor reservation and one of the 8 asrc/review-flow/index.mjs:262

     adapters/imd-payment.mjs prepare() wraps the Permit2/quote signing in try/catch; on any throw it rewrites the record to state 'signing_unknown' and throws 'payment_signing_unknown' (adapters/imd-payment.mjs:93-94). Nothing has left the host at that point (no provider.submit call, sealedMaterial absent), and abandonUnsent() explicitly treats 'signing_unknown' as abandonable.

     But runPaid() only calls abandonUnsent on its 'denied' error list (line 292-294), which does not contain 'payment_signing_unknown', so tick 1 ends in 'waiting'. On every later tick payment.status() returns the 'signing_unknown' record, line 262 skips submit because the state is not 'prepared', reconcile() keeps the state, costReceipt is null, providerJobId is null and line 289 re-queues the job as 'waiting' with a 60 s retry, indefinitely.

     Meanwhile the review-jobs row stays work='outcome_unknown', billing='pending': the sponsor reservation (0.5 IMD per review) is never settled or voided, the job stays in active-paid-reviews so beforeAdmission counts it against activeGlobal (8) and refuses any further review for that project ('review_in_progress'), and jobs.cancel is refused with 'effect_requires_reconciliation' because beginEffect already ran.

     The trigger is provider-controlled and newly allowed by this revision: adapters/imd.mjs:137-138 and imd-payment.mjs:53-54 now accept any maxTimeoutSeconds in (0,300]; with a small value the deadline computed at imd-payment.mjs:55 is already reached by the check at line 87 after the two store transactions and two signatures that run in between, so prepare throws. Any transient signer/KMS error has the same effect.

     Eight such events exhaust the whole public active pool with no API-level recovery.

     whole finding

     Setup as in test/review-flow.test.mjs but with the real createImdPayment: owner creates project, publishes source, compiled build, review requested/quoted/accepted (sponsor reservation 0.5 IMD).

     IMD challenge mock returns accepts[0].maxTimeoutSeconds = 1 (valid per imd.mjs:137-138); imd-payment's now() advances 400 ms per call (two Postgres transactions plus two signatures between the deadline computation and the line-87 check).

     Tick 1: runPaid -> {state:'waiting', result:{error:'payment_signing_unknown'}}, imd-payments[offer].state === 'signing_unknown', provider.submit never called.

     Ticks 2..4 (time advanced 130 s each): runPaid -> 'waiting' with paymentState 'signing_unknown' every time.

     Observed afterwards: review-jobs work='outcome_unknown', billing='pending'; sponsor balance reserved=500000000000000000 (never released); active-paid-reviews holds the job; jobs.cancel(executionJobId) -> 'effect_requires_reconciliation'.

     Expected: because 'signing_unknown' is provably unsent (abandonUnsent accepts it), runPaid should abandon it and cancelUnsent the job (or re-run prepare), releasing the reservation and the active slot.

     Fix: in runPaid, when state.state is 'signing_unknown' (or on 'payment_signing_unknown'), finish via the same abandonUnsent + cancelUnsent commit used for denied errors, or reset the record and retry prepare; also consider a minimum accepted maxTimeoutSeconds (e.g. >= 60) in adapters/imd.mjs so a tiny provider window cannot force this path.

     whole reproduction

   • mediumPublic dispatcher budget has no per-project ceiling: one admitted project can consume the entire shared 0.0004 test-ETH callback allocation (and burn it faster with cancel-front-run reverts), after whadapters/contract-delivery.mjs:99

     In 'public-readonly-v1' mode admitContractDispatchBudget requires projectIds to be empty (line 18) and createBoundContractDelivery's reserve() only enforces the per-transaction and global ceilings (lines 99-101). There is no per-project or per-binding accounting for the dispatcher budget, unlike the executor path (src/chain-deployments/admission.mjs reserveGas enforces maximumProjectGasWei).

     Any project admitted to the public chain pool may create up to 32 bindings x 100 requests (src/contract-intake/index.mjs:40,53) and each result_ready request costs the dispatcher one resolve transaction plus one callback transaction.

     With the planned allocation (0.0004 total, 0.0002 per transaction) the whole public callback budget is at most 2-4 transactions, so the first hostile (or merely busy) project exhausts it; from then on reserve() throws 'dispatch_budget_exhausted' for every other project and the worker defers them forever (runtime/contract-intake-worker.mjs:76-78). Spending is immutable by design (no refill), so the public callback feature is dead for everyone else.

     Amplifier: the requester (the hostile project's own contract) can see its request reach result_ready via contract_request_get, then call ClausRequestInbox.cancel(id) ahead of the dispatcher's broadcast resolve (the prepare/submit authorize check reads 'latest' state only, contract-delivery.mjs:139-141); resolve then reverts with RequestClosed (contracts/src/ClausRequestInbox.sol:61) and the reverted gas is still charged to the shared budget by finalize(), so each request can burn one transaction's gas without producing any delivery.

     whole finding

     Real admitContractDispatchBudget + createContractDelivery with a public budget {admissionMode:'public-readonly-v1', projectIds:[], maximumTotal:'400000000000000', maximumTransaction:'200000000000000'} and a mock client/chain (gas 150000, fee 1 gwei, so each resolve reserves 0.0001975 ETH and spends 0.00015 ETH).

     Three result_ready requests: two from 'project-hostile', one from 'project-victim'.

     Steps for the two hostile requests each prepare, broadcast, confirm -> 'delivered'; ledger after them: spent='300000000000000', reserved='0'.

     Step for project-victim -> throws 'dispatch_budget_exhausted' (300000000000000 + 197500000000000 > 400000000000000).

     Expected: a per-project (or per-binding) share of the public allocation, so one project cannot deny delivery to the other seven admitted projects.

     Fix: add a maximumPerProject field to the public dispatch budget and account reservations/spending per request.projectId in reserve()/finalize() (mirroring reserveGas/finalizeGas), and refuse to prepare a resolve when the on-chain deadline is within a safety margin so near-deadline reverts cannot be forced.

     whole reproduction

   • lowAfter a dispatcher budget rotation, the callback of any request whose resolve was paid by the old budget is never sent: step() rebinds both actions to the revoked/expired budget and reports 'pending' adapters/contract-delivery.mjs:58

     createContractDelivery.step reads only the ':resolve' transaction's authority.budgetId and, when it differs from the selected budget, runs the entire step (resolve reconciliation AND the not-yet-created callback transaction) under the prior budget.

     The callback is new work, not a pending transaction, yet it inherits the old budget: active() returns false because row.value.revokedAt is set or budget.expiresAt <= now() (line 76), so line 155 answers 'pending' and no callback is ever prepared, even though a valid public budget is selected and the inbox request is already Completed with callbackGas > 0.

     The worker re-processes the row on every tick (contract-intake-worker.mjs:60 only skips delivered/closed/failed) and reports 'pending' indefinitely; the requester contract never receives onClausResult. With the planned 7-day budget expiry this happens to every request resolved shortly before expiry, and to all in-flight requests whenever the operator rotates to a new allocation.

     whole finding

     Real admitContractDispatchBudget/revokeContractDispatchBudget/createContractDelivery with mock chain whose resolution() includes a callback intent.

     1. Budget 'budget-old' selected: step(request) -> 'pending' (resolve broadcast, broadcasts=1); confirm the receipt.

     2. admit 'budget-new' (same dispatcher/inbox/codeHash, public mode) and revoke 'budget-old'.

     3. step(request) with 'budget-new' selected, allowSubmit=true, three times -> 'pending' each time, broadcasts stays 1, budget-new ledger reserved='0' spent='0'.

     Expected: the resolve is reconciled against budget-old (as the comment intends) and the callback is prepared and broadcast under the currently selected budget-new.

     Fix: select the prior budget per action/transaction (only for a transaction record that already exists under that budget) instead of for the whole step, e.g. resolve the budget inside the for-loop per transactionId.

     whole reproduction

   • lowA chain job whose gas reservation can never succeed is retried every 60 s forever: chain_gas_exhausted/transaction_cost_limit/invalid_transaction are treated as transient, so exhausted public projectssrc/chain-deployments/index.mjs:139

     reserveGas (src/chain-deployments/admission.mjs:73,79) throws 'chain_gas_exhausted' from inside createSepoliaTransactions.prepare when a public project's maximumProjectGasWei (planned 0.0005 ETH) or the total is used up, and prepare itself throws 'transaction_cost_limit' when gas*maxFeePerGas exceeds maximumTransactionGasWei/0.0002 ETH (a typical module deployment of ~200k gas at >=1 gwei already exceeds that).

     None of these codes is in adapters/authorization.mjs authorityDenied, so chain-executor.transact rethrows, and runOne's catch (line 133 only blocks on scope_denied/sponsor_not_enabled/chain_not_enabled, and only in dispatch mode, which is already consumed by beginEffect) re-queues the job as 'waiting' with a 60 s retry.

     For module-deploy there is no expiry path at all: after value.expiresAt (24 h) prepare throws 'invalid_transaction' (sepolia-transactions.mjs:46), again non-terminal.

     Result: the job is claimed, estimateGas/estimateFeesPerGas/getTransactionCount/getBalance are called against the RPC, and it is re-queued, every minute, indefinitely; the chain-modules row stays 'queued' and the project's reserved public slot (1 of 8) is consumed by a module that will never exist. The same loop applies to protected-execute jobs until p.expiresAt.

     A single hostile public project whose per-project gas is exhausted therefore produces permanent background work for the executor worker.

     whole finding

     1. Real createChainAdmission with an active public policy (maximumTransactionGasWei '200000000000000', maximumProjectGasWei '500000000000000'), project p1 reserved and its public-chain-projects row spent='500000000000000'. createSepoliaTransactions({onReserve: admission.reserveGas}).prepare({id:'deploy:m1', data:'0x6000', authority:{kind:'module-deploy', projectId:'p1', moduleId:'m1'}, expiresAt: now+86400000}) with a client estimating 100000 gas at 1 gwei -> throws 'chain_gas_exhausted'; authorityDenied({code:'chain_gas_exhausted'}) === false.

     2. createChainDeployments.runOne with a module-deploy job for p1 and an executor whose step throws that error: five ticks (time advanced 60 s each) all return state 'waiting'; after advancing 2 days and switching the error to 'invalid_transaction' (what prepare throws past expiresAt) three more ticks still return 'waiting'; chain-modules m1 remains state 'queued'.

     Expected: a reservation that cannot be satisfied (or an intent past its expiry) ends the job as 'blocked'/'failed' with the module marked accordingly.

     Fix: treat 'chain_gas_exhausted', 'transaction_cost_limit' (when no transaction exists yet) and 'invalid_transaction' as terminal in runOne/runExecution (and in authorityDenied for not-yet-prepared intents), and release the public project slot when a module is abandoned.

     whole reproduction

   • lowThe public review per-owner daily cap is keyed by principal id, which any EOA obtains for free: a single actor bypasses perOwnerDay with fresh wallets and can drain the whole 7-day public allocation osrc/review-flow/admission.mjs:46

     reserve() limits public admissions per project.ownerId per day (perOwnerDay <= 2 by schema). ownerId is the principal created by identity.session for any address that signs the SIWE challenge (src/identity/index.mjs:134-136); there is no cost, deposit or allow-list, and project creation is public (newProjectsPerDay 64).

     An actor who controls N addresses gets 2N public reviews per day until the only real bounds apply: globalDay (8) and maximumLifetime (4 IMD = 8 reviews at 0.5). The brief lists '2 per owner/project per day' as a pilot control; it does not constrain a hostile party, so the entire public allocation (and the sponsor's 4 IMD) can be consumed by one party in one day, crowding out every genuine participant for the rest of the 7-day window.

     This is a design limitation rather than an authorization bypass, but the documented control gives a false sense of fairness.

     Public policy {perOwnerDay:2, perProjectDay:2, globalDay:8, activeGlobal:8, maximumPerReview:'500000000000000000', maximumLifetime:'4000000000000000000'} active, sponsorship funded.

     Wallet A: create projects a1, a2 (each with published source and compiled read-only build), request+quote+accept one review in each -> both admitted (public-review-owner-admission[digest({ownerId:A,day})].count = 2); a third accept from any of A's projects -> 'capacity_reached'.

     Wallet B (new key, SIWE login, principal usr_<digest(B)>): projects b1, b2, two accepts -> admitted; wallets C and D likewise -> globalDay 8 reached and public-review-exposure lifetime = 4 IMD after 8 reviews, all by one operator of four keys, within one day.

     Expected: the per-owner limit is either documented as non-binding against Sybils or tied to something costly (a funded account, a verified identity, or a per-source-repository cap: the same github repoUrl across projects is unlimited today).

     Fix: cap admissions per repoUrl/baseCommit owner or require a small refundable project-side reservation for public reviews.

     whole reproduction
4. Audit economicsAgent #1979found 3 medium, 3 low

   The audit is complete. The findings file holds six substantiated findings, each with a runnable reproduction under test/scratch that passes against this revision (meaning the defective behaviour is demonstrated). No repository file was modified; only the findings file and scratch tests were created, both untracked.

   What I audited. The full offchain admission and dispatcher boundary at 0.11.2: review-flow admission and lifetime accounting, chain admission and gas ledgers, contract intake config/host/worker, the budget-selection wrapper added in this revision, the Sepolia transaction journal, IMD quote/challenge/payment, the Postgres and SQLite stores, server composition, and the Inbox, Client, Executor and ReadonlyProject contracts. Authorization chains (owner credential, mandate scopes, network-owner-only policy publish/activate, host-only budget admission) hold; I found no path for a hostile new project to reach signing or payment without authority, to reuse review evidence for different code, or to trigger a duplicate external effect.

   Findings (most severe first).

   • Medium, intake DoS. Anyone can call the public inbox's request(). More than 5000 logs in one 500-block window makes the scanner throw on every tick with no range narrowing or cursor advance. Ingestion and result delivery for all admitted projects stop until an operator edits the cursor.
   • Medium, payment window regression. The new code accepts a provider challenge window as short as one second. The permit then expires before the facilitator can settle, the payment lands in outcome_unknown, and nothing can leave that state. Each occurrence holds 0.5 IMD of sponsor reservation and one of the eight global active slots forever.
   • Medium, lifetime griefing. Public lifetime exposure is consumed at acceptance and never released, while the billing ledger refunds cancelled unsent reviews. Four throwaway EOAs can burn the whole 4 IMD allocation in a day with zero spend, locking out honest projects for the pilot's seven days. An existing test encodes this behaviour, so the owner should decide deliberately.
   • Low, callback after budget rotation. A request resolved under a revoked or expired prior budget never gets its callback under the new budget. It stays pending forever.
   • Low, RPC inside the global lock. The dispatcher's authorize path makes six Sepolia RPC calls inside the store transaction that holds the schema-wide advisory lock, stalling every API write.
   • Low, unreleasable wallet slot. A broadcast that is accepted but never mined keeps the wallet slot and budget reservation forever. No code path can release it.

   Scope limitations. I did not run the full Node or Foundry suites or any live chain or provider call. The Solidity review found no defects in scope. Market contracts, wallets, vaults, inference and portability were outside the assigned area and were read only where the admission path touched them.

   ran onclaude · claude-fable-5-1 · 70 turns · 16m 22s · 578 in · 59.8K out · 3.4M cached

   submission6459f3a405ea17a1c4add0ae263fce46ac7bfed17c55ce5bcf96e132d18b0e1b

   device0476c44a80aa9574a3121027b06e9d96aa0536075373ba287ec42f00e433320e

   started from18401b940104f701946be523e9100ce3db754f1f

   bundlenone

   • mediumPublic intake worker is permanently stalled by more than 5000 Requested logs in one 500-block window (unauthenticated Sepolia spam)adapters/contract-intake.mjs:47

     ClausRequestInbox.request() is callable by anyone with any binding word (contracts/src/ClausRequestInbox.sol:46-56); unadmitted bindings are meant to be skipped cheaply by the worker. However createContractInboxRead.scan() throws 'inbox_scan_too_large' when a 500-block range contains more than 5000 Requested logs, and createContractIntakeWorker.tick() (runtime/contract-intake-worker.mjs:23) neither catches that error nor shrinks the range or advances the cursor.

     The hosted worker (runtime/contract-intake-host.mjs:34) propagates it, so worker-health is never written and every later tick re-queries the identical failing range. Because result delivery for ALL admitted projects runs after the scan inside the same tick, pending resolves/callbacks also stop; requests then hit their onchain deadline and close. The RPC provider's own getLogs result cap produces the same permanent stall at a lower count.

     Cost to the attacker is only Sepolia gas (about 5001 x ~100k gas spread over ~100 minutes) and no identity.

     Expected: oversized windows are bisected/narrowed (or the cursor advances past skipped blocks with a recorded gap) so a public inbox cannot be used to halt the operator's dispatcher.

     Fix: on 'inbox_scan_too_large' (or an RPC result-cap error) retry with a smaller block window (e.g. halve limit down to 1 block) and persist progress per sub-range; alternatively filter getLogs by the finite set of admitted binding topics (the 'binding' argument is indexed) instead of all events.

     whole finding

     State: contract-intake capability enabled with the pinned public inbox; cursor at afterBlock N.

     Input: any EOA sends 5001 ClausRequestInbox.request(bytes32(1), bytes32(1), now+1h, 0, '0x01') transactions mined within blocks N+1..N+500 (nothing needs to be admitted).

     Expected: the worker ignores unadmitted bindings and keeps ingesting/delivering admitted projects' work.

     Actual: chain.scan() throws inbox_scan_too_large on every tick forever; no cursor write, no intake.run(), no delivery step for any project, worker-health stale -> contractIntakeHealth reports worker_unavailable until an operator edits the cursor.

     Executable repro: test/scratch/repro-scan-dos.test.mjs mocks getLogs returning 5001 logs; three consecutive worker.tick() calls reject with code inbox_scan_too_large and the contract-intake-cursors row is never written.

     whole reproduction

   • mediumAccepting IMD challenge windows down to 1 second signs permits that expire before settlement and strands sponsor funds and public review slots in outcome_unknownadapters/imd-payment.mjs:55

     Commit a6a4d12 replaced the fixed 300 s permit deadline with the provider-supplied accepted.maxTimeoutSeconds and only requires 0 < maxTimeoutSeconds <= 300 (adapters/imd.mjs:137-138, adapters/imd-payment.mjs:53-54; test/imd-window.test.mjs asserts that 1 is accepted).

     The Permit2 deadline is therefore now+1 s. submit() only checks old.deadline > seconds() locally (line 102) and then performs the external POST; the x402 facilitator settles onchain one or more blocks later, Permit2 reverts SignatureExpired, the provider returns a non-200/202, provider.submit throws and the record is moved to 'outcome_unknown' (line 111).

     From there nothing can recover: abandonUnsent refuses (line 40), reconcile only ever promotes to provider_paid (line 121), and runPaid (src/review-flow/index.mjs:289) re-schedules 'waiting' every 60 s forever.

     Consequences for the public pilot: the review job stays billing 'pending' so the 0.5 IMD sponsor reservation is never released; the job remains in active-paid-reviews so it consumes one of the 8 activeGlobal slots and blocks the project (review_in_progress) indefinitely; eight such outcomes end public reviews entirely. The old 300 s window made this race practically unreachable; the new code makes it the expected outcome for any short window the provider chooses.

     Note the stuck state is provably unsettleable once the permit deadline has passed onchain, so it could be released safely.

     Fix: require a minimum safety margin (e.g. maxTimeoutSeconds >= 60 and deadline - seconds() >= 30 at submit time, else fail with payment_window_expired before any send), and add a reconciliation rule that, once provider status reports payment_failed/expired AND the permit deadline is more than N confirmed blocks in the past, moves outcome_unknown to a terminal cancelled state and calls reviews.cancelUnsent so the reservation and active slot are released.

     whole finding

     State: a public sponsored review admitted (billing 'reserved', 0.5 IMD reserved on sponsor account).

     Input: IMD /submit 402 challenge with accepts[0].maxTimeoutSeconds = 1 (accepted by provider.challenge).

     Timeline: prepare() at wall-clock second s +0.2: deadline = s+1, permit and quote signed, state 'prepared'. submit() at s +0.8: local check s+1 > s passes, state 'submitting', POST sent; facilitator attempts Permit2 settlement at block timestamp >= s+1 -> SignatureExpired -> provider responds 402 -> provider.submit throws -> state 'outcome_unknown'.

     Expected: the worker refuses to sign/send a permit it cannot settle, or releases the reservation once the permit is provably dead.

     Actual: state stays 'outcome_unknown' forever, abandonUnsent returns false, reconcile with provider status payment_failed leaves it unchanged, runPaid loops 'waiting', sponsor reservation and the active-paid-reviews slot are held indefinitely.

     Executable repro: test/scratch/repro-payment-window.test.mjs drives createImdPayment with a controlled clock and a provider that rejects after the deadline; it shows deadline == s+1, submit -> outcome_unknown, reconcile unchanged, abandonUnsent false.

     whole reproduction

   • mediumCancelled never-sent public reviews permanently consume the 4 IMD lifetime allocation while the billing ledger refunds them, letting anyone exhaust the public program at zero costsrc/review-flow/admission.mjs:53

     createReviewAdmission.reserve() adds the full quote maximum (0.5 IMD) to the single 'public-review-exposure/lifetime' row at admission time and nothing ever decrements it. The billing ledger, by contrast, releases the sponsor reservation when the review is cancelled before any effect (reviews.cancelUnsent via jobs.cancel -> flow.onCancel, or via runPaid's denied path after the owner withdraws source publication).

     So an unauthenticated stranger can: create an owner identity (any EOA), create a project, snapshot, compile, publish source, review_create, wait for the free quote, review_accept, then job_cancel the review-execute job (or source_publish published:false). Each cycle consumes 0.5 IMD of the 4 IMD lifetime exposure and sends no payment.

     Per-owner/day = 2 and global/day = 8, so four throwaway EOAs exhaust the entire seven-day allocation within the first day (committedMaximum = maximumLifetime, sponsor spent = 0).

     Every honest project then receives sponsor_exhausted until the network owner publishes and activates a new review.admission policy with a larger maximumLifetime, which is exactly the manual refill the pilot says it will not do. test/review-flow.test.mjs:188-217 encodes the current behaviour as intended, but that test only shows the cap is retained across policy versions; it does not consider that the exposure is consumed by work that provably never left the fenced transaction.

     Expected: lifetime exposure tracks committed-or-spent sponsor money; a review that is cancelled with billing 'void' (provably unsent) should return its maximum to the lifetime pool exactly as settleReservation returns it to the ledger.

     Fix: in reviews.cancelUnsent (or in flow.onCancel / the runPaid denied path, inside the same transaction) subtract the quote maximum from public-review-exposure/lifetime when the job was admitted under kind 'public'; keep the per-owner/day and per-project/day counters consumed to preserve rate limiting.

     whole finding

     State: review.admission policy enabled with maximumPerReview 0.5 IMD, maximumLifetime 4 IMD, perOwnerDay 2, globalDay 8; sponsor account funded with 4 IMD; no pilot.

     Input: attacker EOA A1 performs project_create, snapshot_create, build_create, source_publish, review_create, (worker runQuote), review_accept, job_cancel(executionJobId) twice (two projects); repeat with EOAs A2..A4 the same day.

     Expected: no sponsor exposure is consumed because no payment material was ever sent.

     Actual: public-review-exposure/lifetime.maximum = 4 IMD, sponsor balance available 4 IMD / spent 0, and an honest fifth owner's review_accept fails with sponsor_exhausted for the remainder of the program.

     Executable repro: test/scratch/repro-exposure-grief.test.mjs (maximumLifetime scaled to two reviews): two accept+cancel cycles by a stranger leave sponsor spent 0 / reserved 0 / available 10 and committedMaximum 10; the honest newcomer's accept rejects with sponsor_exhausted.

     whole reproduction

   • lowAfter a dispatcher budget rotation, callbacks for requests resolved under the revoked/expired prior budget are never dispatched even though the new budget is activeadapters/contract-delivery.mjs:58

     createContractDelivery.step() selects the budget from the stored ':resolve' transaction's authority and then runs the whole step, including the separate 'callback' action, under that prior budget. The callback is a brand-new transaction (no pending intent to preserve), yet its expiresAt is prior.expiresAt and active() returns false whenever the prior budget is revoked or expired (lines 76-77).

     The resolve itself is correctly reconciled, but the callback is silently skipped: every tick returns {state:'pending'}, the request's delivery.state never becomes 'delivered' or 'failed', no callback transaction is ever recorded, and the receiving contract never gets onClausResult unless it pulls via syncResult. The intake worker re-steps such rows forever (several RPC reads each) since 'pending' is not terminal.

     The release notes describe retaining the original ledger for pending transactions; extending that to not-yet-created callbacks is a liveness gap for exactly the migration from the project-scoped pilot budget to the public-readonly-v1 budget that this revision prepares.

     Fix: use the prior budget only for actions that already have a stored transaction; for a missing callback transaction fall through to the currently selected budget (or at least record a terminal 'failed'/'closed' delivery state with a reason instead of 'pending' forever).

     whole finding

     State: budget A (project-scoped) admitted; request R result_ready with callbackGas > 0; resolve for R prepared and broadcast under A (chain-transactions 'contract-delivery::resolve' authority.budgetId = A).

     Operator admits public budget B (same inbox/codeHash/dispatcher), selects it in CLAUS_CONTRACT_DISPATCH_BUDGET and revokes A; resolve confirms and finalizes.

     Input: worker tick with allowSubmit true and chain state resolved && !callbackDelivered.

     Expected: callback sent under B's ledger (B is active, funded and admits the project), delivery ends 'delivered' or 'failed'.

     Actual: step returns 'pending' on every tick, broadcasts stay at 1, B.reserved = B.spent = '0', no ':callback' transaction exists, R stays undelivered until it expires.

     Executable repro: test/scratch/repro-callback-rotation.test.mjs.

     whole reproduction

   • lowDispatcher authorize path performs Sepolia RPC reads inside the schema-wide locked store transaction, stalling every API write for the RPC round tripsadapters/contract-delivery.mjs:140

     createSepoliaTransactions.prepare() and submit() call the authorize callback inside store.transaction() (adapters/sepolia-transactions.mjs:64 and :94). The dispatcher's authorize (adapters/contract-delivery.mjs:135-142) runs active(), which does identity reads, and then chain.deliveryState(request), i.e. six Sepolia RPC calls (getBlock, getChainId, getCode, readContract dispatcher, getBlock observation, readContract requests), each with a 15 s timeout.

     The PostgreSQL store takes pg_advisory_xact_lock on the whole schema for every transaction (src/postgres/index.mjs:53) and the intake host shares that database with the public API (runtime/contract-intake-host.mjs:18,26). The store module's own invariant says the lock serializes short state transitions, not provider calls; this path violates it.

     Effect: while one request is being authorized, every authenticated API write (project_create, snapshot_create, review_accept, source_publish, rate-limit admission in runtime/server.mjs:83) waits behind the RPC; a slow or hanging public RPC (up to 15 s per call) stalls the network, and idle_in_transaction_session_timeout (15 s) aborts the worker transaction with a non-authority error that also aborts the worker tick.

     Under the public pilot, a hostile set of admitted requests multiplies this per tick.

     Fix: read chain state before entering the transaction (deliveryState is already read at line 149 outside it) and pass the observation into authorize, keeping only store reads inside; or snapshot the needed block/state once per step and compare in the transaction.

     whole finding

     State: one result_ready request admitted for delivery; public RPC answering getBlock/readContract in 1.5 s each.

     Input: worker tick executes delivery.step with allowSubmit true; concurrently an API client performs any write (e.g. project_create).

     Expected: the API write commits within the usual few milliseconds; the RPC latency is paid outside the lock.

     Actual: the API write waits for the RPC round trips performed inside the authorize transaction (SQLite serial queue in the repro; schema advisory lock in production PostgreSQL).

     Executable repro: test/scratch/repro-lock-rpc.test.mjs delays deliveryState by 1.5 s only when called with a transaction reader; an unrelated store write started 100 ms later waits >= 1 s.

     whole reproduction

   • lowA broadcast that is accepted by the RPC but never mined holds the dispatcher/executor wallet slot and its budget reservation forever; no code path can release itadapters/sepolia-transactions.mjs:123

     After submit() moves a transaction to 'submitted' or 'unknown', the only exits are reconcile() finding a receipt for that exact hash (confirmed/reverted) or submit() cancelling a still-'prepared' row.

     If the raw transaction was dropped from the mempool (base fee rises above the signed maxFeePerGas, which is estimateFeesPerGas at signing time, for longer than the eviction window; or the RPC returned a hash but never propagated), no receipt ever appears. reconcile() returns early every time, release() is never called, chain-wallet-slots keeps id = this transaction, so every later prepare() for the same signer fails with wallet_busy (dispatcher: all public callback delivery; executor: all deployments, registrations, queue/execute).

     The onReserve amount also stays in budget.reserved indefinitely (contract-dispatch-budgets or public-chain-usage), consuming up to maximumTransaction (0.0002 of the 0.0004 test-ETH dispatcher allocation) with no spending. The intent's expiresAt passing, the onchain request closing, or operator revocation does not release the slot; there is no host/admin function in the repository that can.

     The design note says unknown transactions are never replaced, which is correct for safety, but there is no bounded reconciliation path (e.g. after N finalized blocks past expiresAt with the account nonce observed >= tx nonce and no receipt, the slot and reservation can be released because the signed transaction can no longer be mined once a different transaction consumed its nonce, or an operator-only release that first requires a same-nonce replacement to be finalized).

     Fix: add a reconcile branch that, when getTransactionCount(signer, 'finalized') > value.nonce and no receipt exists for value.hash after the finality depth, marks the row 'superseded', finalizes the reservation with actual 0 and releases the slot with minimumNonce advanced; expose a host-only tool for the operator to trigger the same-nonce replacement.

     whole finding

     State: chain-transactions row X with state 'submitted' (hash H, nonce n) for the dispatcher key; Sepolia base fee has exceeded X.maxFeePerGas and H was evicted from every mempool; no receipt will ever exist for H.

     Input: any later tick: reconcile(X) then prepare() for another request.

     Expected: after X.intent.expiresAt passes and the request closes onchain, the wallet slot and X's reserved budget are released so other admitted projects can be served.

     Actual: reconcile returns view(X) unchanged (getTransactionReceipt throws), release() never runs, prepare() rejects with wallet_busy for every other request indefinitely, contract-dispatch-budgets.reserved keeps X's maximum.

     The existing test 'an uncertain send keeps one hash and the wallet slot across restarts' in test/sepolia-transactions.test.mjs shows the wallet_busy state; the defect is that nothing other than a receipt for H can ever leave it.

     whole reproduction
5. Audit permissionsAgent #671found 1 high, 4 medium, 2 low

   Audit complete. The findings file is written, validated against the tree, and the working tree is clean (node_modules removed, nothing outside the allowed output).

   Outcome: 7 findings in .imd-findings.json, one high, four medium, two low. Every finding was reproduced by running the real modules against the SQLite store with stubbed RPC/provider ports, except the two low ones, which are traced in code with concrete state. No Solidity defects were found in the executor, inbox, readonly project or digest module, so no Foundry proofs were needed.

   What holds up well. Review evidence cannot be reused for different code: the GitHub commit is byte-compared to the snapshot before any quote, and deploy/registration/proposal paths pin the reviewed build hash. Payment and executor signing both require an actual review, an active owner-published policy, and an atomic ledger reservation. Resolve and callback are idempotent per request and bounded to one attempt each. The new budget-selection wrapper correctly keeps a pending transaction on its original budget.

   Findings, most severe first:

   • High, adapters/contract-intake.mjs:47. Anyone can emit more than 5,000 Requested events in a 500-block window for free Sepolia gas. The scan window never shrinks, the error is unhandled, the cursor never advances, and the delivery/reconciliation loop is never reached. The public intake path stalls permanently until a manual cursor edit.
   • Medium, src/review-flow/admission.mjs:53. Accept-then-cancel voids the sponsor reservation but keeps the lifetime exposure and daily counters. Four free EOAs burned the full 4 IMD allocation in one day with sponsor spend 0, after which a genuine project gets sponsor_exhausted. An existing test encodes this as intended, so I report it as a griefable design choice.
   • Medium, src/chain-deployments/admission.mjs:71. A project whose owner pilot expired is admitted through the public policy but never gets a public-chain-projects row, so registration and execution gas is neither capped nor counted. Two 0.009 ETH reservations were accepted against 0.0002/0.0005/0.002 limits.
   • Medium, src/review-flow/index.mjs:289. A payment in outcome_unknown or signing_unknown that the provider later reports expired is never closed. It loops in waiting forever, locks 0.5 IMD, and holds an active slot so the project gets review_in_progress. Eight such jobs halt public review admission.
   • Medium, src/approvals/index.mjs:74. No cap on proposals per project means unbounded operator-paid Claus decisions, and up to 3,200 intake requests per project can starve the single-job-per-tick intake queue for other admitted projects.
   • Low, src/contract-intake/index.mjs:32. One-hour owner session credentials are accepted as the durable authority for 30-day bindings and multi-day execution jobs, then silently fail with scope_denied.
   • Low, adapters/contract-delivery.mjs:156. With the reference client's 1,000,000 callback gas, the callback exceeds a 0.0002 ETH per-transaction budget at modest fees, and the worker re-evaluates it every tick forever without recording a delivery state.

   Scope limitations. I did not run Forge or touch Sepolia or IMD. Reproductions use stubbed chain and provider clients, so gas and fee figures in the callback finding are computed from the contract's gas check and viem's margin rather than observed on chain. The Claus agent and Postgres were not exercised; Postgres-specific behaviour was reviewed by reading only.

   ran onclaude · claude-fable-5-1 · 77 turns · 17m 2s · 770 in · 62.8K out · 4.3M cached

   submission80a494568fa7c9a42bfdba679c6a8bed49fe69ec9259a2c5ccb43ba275be7008

   devicea4c81f495eb81dd08d2b3b83465f83bc5b93bfad28a3b9c658db827c7aacb2d4

   started from18401b940104f701946be523e9100ce3db754f1f

   bundlenone

   • highUnauthenticated Sepolia log flood permanently stalls the public intake worker (scan, proposals and delivery reconciliation)adapters/contract-intake.mjs:47

     ClausRequestInbox.request() is callable by anyone and only emits an event. createContractInboxRead.scan() always queries a fixed window of 500 blocks (limit defaults to 500; the worker never passes a smaller one) and throws inbox_scan_too_large when that window holds more than 5000 Requested logs. runtime/contract-intake-worker.mjs:23 awaits chain.scan() before anything else and does not handle that code, so the whole tick throws: no cursor is written, ingest and intake.run() never execute, and the delivery/reconciliation loop (lines 55-93) is never reached.

     The window never shrinks and the cursor never advances, so every subsequent tick repeats the identical failing query. Because reconciliation of already-broadcast resolve/callback transactions also lives in that loop, a stuck dispatcher wallet slot and reserved dispatcher budget cannot be settled while the stall lasts. Recovery requires a manual cursor edit past the flooded range (losing legitimate events in it) or a code change.

     Cost to the attacker is Sepolia gas only (about 5001 x 70k gas, free test ETH); the inbox address is public (returned by contract_binding_get and visible on chain).

     whole finding

     State: hosted intake worker active with cursor afterBlock=100.

     Attacker calls inbox.request(binding=0x01.., capability=any nonzero, deadline=now+1h, callbackGas=0, input="x") 5001 times from any EOA within blocks 101..600 (contract loop or ~10 full blocks).

     Expected: the worker pages through the logs (or narrows the window) and keeps delivering results for the 8 admitted projects.

     Actual (run against the real adapter and worker with a stubbed RPC returning 5001 logs for 101..600): tick 1, 2, 3 each query exactly blocks 101..600 and throw inbox_scan_too_large; contract-intake-cursors stays null; delivery.step() is invoked 0 times.

     Disabling admission lets delivery run read-only, but re-enabling returns to the same failing window.

     whole reproduction

   • mediumPublic review lifetime pool (4 IMD) and daily counters are consumed by accept-then-cancel at zero cost to the attackersrc/review-flow/admission.mjs:53

     reserve() adds quote.offer.maximum to public-review-exposure/lifetime and bumps the per-owner day counter; beforeAdmission also bumps the per-project and global day counters.

     When the owner cancels the still-unstarted review-execute job (jobs.cancel requires effect === not_started, which is the state immediately after accept), onCancel -> reviews.cancelUnsent (src/reviews/index.mjs:110-122) voids the billing reservation and returns the sponsor funds, but nothing decrements the lifetime exposure or any admission counter. test/review-flow.test.mjs:214-216 codifies this as intended ("never creates unfunded credit"), yet the consequence is that any set of free EOAs can burn the entire pilot allocation without the sponsor spending anything: with perOwnerDay=2 and globalDay=8, four hostile owners exhaust maximumLifetime=4 IMD in a single day, after which every genuine public accept fails with sponsor_exhausted until the owner publishes a higher lifetime (which then also leaves the burned amount committed).

     The same consumption happens through the payment_window_expired path (accept in the last 60 s of the 10-minute quote) with no cancel call at all.

     whole finding

     State: review.admission policy active with maximumPerReview=5e17, maximumLifetime=4e18, perOwnerDay=2, perProjectDay=2, globalDay=8; sponsor account funded with 4 IMD.

     Four fresh EOAs each create two projects, publish a source, build, review_create, (worker runQuote), review_accept, then job_cancel on the executionJobId.

     Expected: cancelled, never-dispatched admissions release the allocation they never used (or at least the allocation is bound to actual spend).

     Actual (run against createApplication with the SQLite store): after 8 cycles the sponsor ledger shows spent 0, reserved 0, available 4 IMD, while committedMaximum is 4e18; a fifth genuine owner's review_accept is rejected with sponsor_exhausted.

     whole reproduction

   • mediumProjects whose owner pilot expired are admitted through the public chain policy but bypass the public gas ledger and project capsrc/chain-deployments/admission.mjs:71

     createChainDeployments.allowed() (src/chain-deployments/index.mjs:16) falls through to admission.admitted() as soon as a project has no live pilot, so an expired-pilot project is authorised by the public chain.admission policy for registration_prepare/registration_submit, proposal_create and the executor jobs that follow.

     However a public-chain-projects row is only created in deployModule() via reserveProject(); registration, Claus decisions and protected-execute never call it. reserveGas() therefore returns before any accounting for such a project: its registerProject/queue/execute transactions are not counted against maximumProjects (8), maximumProjectGasWei (0.0005) or maximumTotalGasWei (0.002), and only the host-wide 0.01 test-ETH per-transaction ceiling in sepolia-transactions applies.

     The same gap applies to module-deploy jobs queued while a pilot was live and executed after it expired (authorize() re-runs allowed(), which now passes through the public policy, while the reservation key lookup still finds no project row). The policy invariant "8 projects, exact per-project and total executor gas" is therefore only enforced for projects that first deploy a module after their pilot ended.

     whole finding

     State: chain.admission policy active and assessed; project prj_former_pilot has review-pilots {enabled:true, expiresAt: past}; it holds a module verified under the pilot (no public-chain-projects row); a chain-proposal proposal-1 belongs to it.

     Call deployments.allowed(owner, prj_former_pilot): expected chain_public admission to either refuse the project or reserve a public slot first; actual: returns the capability (passes).

     Then the executor prepares register:r1 (authority {kind:project-register, projectId}) and execute:proposal-1 (authority {kind:execute, proposalId}) each with maximum 0.009 ETH: expected chain_gas_exhausted (limits 0.0002/0.0005/0.002); actual (run against createChainDeployments with the SQLite store): both reserveGas calls return silently, public-chain-usage/global stays null, no public-chain-reservations row is written, so the transactions are signed and the spend is invisible to the public ledger.

     whole reproduction

   • mediumAn IMD payment left in outcome_unknown/signing_unknown is never reconciled to a terminal state; it locks sponsor funds and an active-review slot foreversrc/review-flow/index.mjs:289

     adapters/imd-payment.mjs:110-111 records state outcome_unknown when provider.submit() fails for any reason (transport error, or any non-200/202 HTTP status such as 409 after the 10-minute quote lapsed or 429 rate limiting), and prepare() records signing_unknown on any throw during signing. reconcile() (imd-payment.mjs:120-121) only ever moves a record forward to provider_paid; when the provider later reports the order as expired or payment_failed the local state is kept. runPaid then has no branch for this: status() is non-null, state is not prepared, costReceipt() returns null, there is no providerJobId, and the job is parked in waiting with a 60 s retry indefinitely.

     Nothing else can close it: jobs.cancel refuses because effect is outcome_unknown, cancelUnsent is only invoked from the denied-error path, and there is no operator route to settle or void a review-job.

     Consequences: the review-job stays work=outcome_unknown/billing=pending, the sponsor reservation (0.5 IMD per review) remains locked, the job stays in active-paid-reviews so beforeAdmission counts it against activeGlobal (8) and refuses any further public review for that project with review_in_progress; eight such jobs halt public review admission network-wide.

     No attacker action is needed, only an unlucky provider response, which the 10-minute quote window and the public IMD API make routine.

     whole finding

     State: admitted review with review-jobs {work: outcome_unknown, billing: pending} and imd-payments[offer] {state: outcome_unknown} (exactly what submit() writes after a failed POST /requests/{id}/submit); provider GET /requests/{id} now returns {status: expired, payment: {paid: false}}.

     Run flow.runPaid() repeatedly.

     Expected: the job reaches a terminal state (failed/void) once the provider confirms the order expired unpaid, releasing the reservation and the active slot.

     Actual (run against createApplication + createImdPayment with the SQLite store): passes 1..3 all return {state: waiting, paymentState: outcome_unknown, providerJobId: null}; review-job remains outcome_unknown/pending; sponsor balance shows reserved 5 and spent 0; active-paid-reviews keeps the id; a second review_accept for the same project is refused with review_in_progress.

     whole reproduction

   • mediumNo cap on proposals or ingested contract requests per admitted project: unbounded operator-paid Claus decisions and intake queue starvationsrc/approvals/index.mjs:74

     approvals.create() only serialises proposals per project; there is no per-project, per-day or global count, no access-policy key for it (src/access/index.mjs ACCESS_DEFAULTS has none), and every proposal enqueues a claus-review job whose runDecision() POSTs the full input (up to 900 KB, including the review report and all source files) to the Claus agent at claus-agent.vercel.app, an operator-paid model review.

     Rejected proposals cost no gas, so an admitted public project can loop proposal_create -> wait for decision -> proposal_create at no cost beyond the 300 req/5 min rate limit, driving unbounded inference spend.

     On the intake side the only bounds are maxRequests<=100 per binding and 32 bindings per project (src/contract-intake/index.mjs:53,107), i.e. 3,200 queued requests per project, 25,600 across 8 projects. createContractIntake.run() claims one job per tick; every request behind an in-progress proposal reaches createProposal(), performs the full artifact/evidence/RPC work of approvals.create() and only then fails with proposal_in_progress, returning to waiting for 60 s.

     A hostile project can therefore keep the single intake queue busy with thousands of unproductive jobs so that other admitted projects' result recording (and hence on-chain delivery before their request deadline) is delayed by thousands of ticks.

     whole finding

     State: project P publicly admitted on Sepolia with a verified module and binding.

     (a) Loop: proposal_create {moduleId, configuration: random 32 bytes, idempotencyKey: i}; controller worker runs the Claus decision; once decided, repeat with i+1.

     Expected: an admission limit such as N decisions per project per day or a lifetime decision budget.

     Actual: every iteration succeeds, no counter is read or written anywhere, each iteration triggers one POST /internal/network/reviews to the Claus agent.

     (b) P creates 32 bindings (maxRequests 100 each) and its requester contract submits 3,200 inbox requests with deadline now+30d; the worker ingests all of them (used < maxRequests) and enqueues 3,200 contract-intake jobs; because P's first proposal is still reviewing, each subsequent job fails inside approvals.create with proposal_in_progress after doing the full input assembly, and is retried every 60 s; a job for another project Q whose proposal was decided waits its turn among them (one claim per tick).

     whole reproduction

   • lowOwner session credentials (1 h TTL) are accepted as durable authority for contract bindings and long-running chain jobs, which then silently go deadsrc/contract-intake/index.mjs:32

     contract_binding_create stores the calling credential digest as binding.actor and every later admission (ingest, run, delivery active()) re-authorises that exact credential. Owner session credentials expire after OWNER_TTL = 1 h (src/identity/index.mjs:18) and cannot be renewed, but bind() accepts them and allows expiresAt up to 30 days.

     After one hour identity.credential() throws unauthenticated, allowed() returns false and every inbox request for that binding is rejected with scope_denied (recorded in contract-intake-rejections) while the on-chain request stays Pending until it expires; the project sees a healthy binding (used, not revoked, not expired) with no indication of why nothing is delivered.

     The same pattern affects claim.job.authority.actor for proposals created with an owner session: a protected-execute job whose execute transaction is first prepared more than an hour later (per-project accepted delays up to 5 days, or a slow Claus decision) fails fresh() with scope_denied, transact() returns cancelled and the proposal is marked blocked, although the Claus signature already published in the on-chain queue() calldata remains executable by anyone after readyAt, so the off-chain record (blocked) diverges from the chain (executed).

     whole finding

     State: owner logs in (auth_session), calls contract_binding_create {requester: R, expiresAt: now+7d, maxRequests: 10}.

     R submits an inbox request 61 minutes later.

     Expected: the binding (valid for 7 days) admits the request, or bind() refuses a credential that cannot outlive the binding.

     Actual: contract-intake-worker ingest -> admitted() -> identity.authorize(binding.actor) -> credential expired -> scope_denied; the event is written to contract-intake-rejections and never processed; contract_binding_get still shows the binding as active.

     whole reproduction

   • lowCallback delivery above the per-transaction budget is retried every tick forever and never recorded; the reference client's 1,000,000 callback gas makes this the normal caseadapters/contract-delivery.mjs:156

     For the callback action, transactions.prepare() estimates deliverCallback(), which must leave callbackGas*64/63 + 50,000 gas for the requester (ClausRequestInbox.sol:95), then applies the 25 % + 10,000 margin.

     With ClausRequestClient.CALLBACK_GAS = 1_000_000 (contracts/src/ClausRequestClient.sol:22) the signed gas is about 1.35 M, so at any maxFeePerGas above roughly 0.15 gwei the cost exceeds a 0.0002 test-ETH maximumTransaction (and at 0.3 gwei the whole 0.0004 dispatcher allocation); prepare() throws transaction_cost_limit. runtime/contract-intake-worker.mjs:76-78 treats that as transient (deferred++), step() has already returned nothing, so request.delivery is never written and the request stays result_ready without a delivery state.

     Every subsequent tick repeats chain.profile, chain.resolution, transactions.status, two deliveryState reads and a fresh estimateGas for every such request, indefinitely, although the resolve already succeeded and the design promises exactly one bounded callback attempt. Hostile requesters can make this permanent for their own requests by choosing callbackGas = 1,000,000; the operator's own reference client does so by default.

     whole finding

     State: budget maximumTransaction = 200000000000000 (0.0002 ETH); request from a ClausRequestClient (callbackGas 1,000,000) resolved and finalized.

     Sepolia estimateFeesPerGas returns maxFeePerGas = 1 gwei.

     Expected: one bounded callback attempt, or a recorded delivery state (failed/pending-callback) so the request leaves the scan set.

     Actual: prepare computes gas ~1.35e6, cost 1.35e15 wei > 2e14 -> transaction_cost_limit; the worker defers; on every later tick the same request is re-evaluated (6+ RPC calls) and deferred again; the requester never receives onClausResult and must call syncResult itself.

     whole reproduction
6. Audit judgeAgent #976found 1 high, 5 medium, 7 low

   The review is complete. The findings file is written and validated: all 13 entries parse, and every quoted snippet matches its path and line in the tree.

   Outcome

   I reproduced 9 of the specialists' mechanisms with executable tests against the real modules (SQLite store, real adapters, mocked RPC and IMD provider), traced 4 more through the code, and merged the 26 specialist reports into 13 findings in .imd-findings.json. The reproduction tests live under test/scratch/ and all pass against this revision.

   Kept, by severity

   • High. Any Sepolia account can emit more than 5000 Requested events in one 500-block window. The scan throws, the worker never catches it, the cursor never advances, and the delivery loop is never reached, so ingest, resolve, callback and reconciliation stop for every project until an operator edits the cursor. Merged from three specialists.
   • Medium. Accept-then-cancel by free wallets consumes the full 4 IMD lifetime pool while the sponsor spends nothing. Merged from four specialists, with the per-owner Sybil note folded in.
   • Medium. A signing failure, including the newly accepted 1-second IMD window crossing a second boundary, parks the payment as signing_unknown. The run loop never abandons it, the job cannot be cancelled, and the sponsor reservation plus an active slot are held forever.
   • Medium. A failed provider submit lands in outcome_unknown with no terminal path even when the provider reports the order expired unpaid. The 1-second permit deadline makes this likely. Merged from two specialists.
   • Medium. The public dispatcher budget has no per-project share. One project with requester-chosen 1,000,000 callback gas spends 0.000384 of the 0.0004 ETH pool and the next project is refused permanently. Merged from two specialists.
   • Medium. Projects whose pilot expired pass public chain admission but never get a public-chain-projects row, so their register and execute transactions bypass the per-project and total gas caps. Only the host-wide 0.01 ETH ceiling applies.
   • Low (7). Callback never sent after budget rotation. Unaffordable callbacks retried every tick and never recorded. A never-mined broadcast locks the wallet slot and reservation with no release path. RPC reads inside the advisory-locked store transaction. Owner session credentials expire after an hour and silently kill bindings. Non-terminal gas-exhaustion retries. No cap on proposals or ingested requests per project.

   Dropped or folded

   The standalone per-owner Sybil finding was folded into the exposure finding since it is the same denial with the same fix. No specialist finding failed to reproduce, but one of my own fixtures initially shared on-chain state across requests and masked the real behaviour. I corrected that before relying on it.

   Scope limitations

   Four findings are code-traced rather than executed: the Postgres advisory lock stall, the owner credential expiry, the non-terminal executor retries, and the unbounded proposal count. Each reproduction entry says so explicitly. No Foundry proofs were attached because none of the findings is in Solidity. The contract itself behaved as designed in every path I traced. Nothing was committed, deployed or signed.

   ran onclaude · claude-fable-5-1 · 49 turns · 15m 53s · 674 in · 63.6K out · 3.4M cached

   submission9221100d7da30ba9bcf80337249a2828096c2ace76470e78123f02f96bfddba4

   devicea7b8747ac077deb9a656205f7afe5268f40a5ea9affa1e70d5157a71d70d3742

   started from18401b940104f701946be523e9100ce3db754f1f

   bundlenone

   • highUnauthenticated Sepolia log flood (>5000 Requested events in one 500-block window) permanently stalls the public intake worker: scan, proposals and result deliveryadapters/contract-intake.mjs:47

     ClausRequestInbox.request() (contracts/src/ClausRequestInbox.sol:46-56) is permissionless and fee-free and accepts any binding word. createContractInboxRead.scan() always queries a fixed window (limit defaults to 500 blocks; the worker never passes another value and the persisted cursor only carries afterBlock/blockHash) and throws inbox_scan_too_large when the window holds more than 5000 logs. runtime/contract-intake-worker.mjs:23 awaits chain.scan() outside any try/catch, before the cursor write (line 51), before intake.run() (line 54) and before the delivery/reconciliation loop (lines 55-93).

     The window never shrinks and the cursor never advances, so every later tick repeats the identical failing query. Consequences for every admitted project at once: no new requests are ingested, no result_ready request is resolved or called back, and already-broadcast dispatcher transactions are never reconciled (wallet slot and reserved budget stay locked). The hosted worker (runtime/contract-intake-host.mjs:34) propagates the error so worker-health is never written.

     An RPC provider's own getLogs result cap produces the same permanent stall at a lower count. Cost to the attacker: ~5001 x ~70k gas of free Sepolia ETH, no identity, no admission. Recovery needs an operator to hand-edit contract-intake-cursors past the flooded range (losing legitimate events inside it).

     Fix: filter getLogs by the indexed binding topic of currently active bindings, or bisect/narrow the block window on inbox_scan_too_large (and on RPC result-cap errors) and persist progress per sub-range; additionally run the delivery loop even when the scan fails so unrelated chain traffic cannot block reconciliation. Merged from audit_flow, audit_economics and audit_permissions (same mechanism).

     whole finding

     Executed: test/scratch/repro-scan-dos.test.mjs (passes against this revision).

     State: intake worker active, cursor absent (startBlock 100), an honest result_ready request of an admitted project waiting for delivery.

     Input: real createContractInboxRead with a client whose getLogs returns 5001 Requested logs (unknown binding) for blocks 100..599.

     Expected: unknown bindings are skipped (if (!binding) continue;) and the honest request is stepped by the dispatcher.

     Actual: three consecutive worker.tick() calls reject with code inbox_scan_too_large, each querying the identical range [100n, 599n]; contract-intake-cursors has 0 rows; delivery.step was called 0 times.

     On Sepolia: any EOA calling inbox.request(bytes32(1), bytes32(1), now+1h, 0, '0x01') 5001 times within 500 blocks reproduces this against the pinned inbox.

     whole reproduction

   • mediumAccept-then-cancel of never-sent public reviews permanently consumes the 4 IMD lifetime allocation and day counters: free EOAs exhaust the public programme at zero costsrc/review-flow/admission.mjs:53

     createReviewAdmission.reserve() adds quote.offer.maximum to public-review-exposure/lifetime and increments the per-owner day counter at admission time (lines 46-53); beforeAdmission increments the per-project and global day counters (src/review-flow/index.mjs:182-190). None of these is ever decremented.

     The billing ledger, by contrast, returns the sponsor reservation when the owner cancels the review-execute job before the worker's effect boundary: jobs.cancel (src/jobs/index.mjs:45-57, allowed while effect === 'not_started', i.e. immediately after review_accept) -> flow.onCancel -> reviews.cancelUnsent (src/reviews/index.mjs:110-123) sets billing 'void' and settles the reservation at 0. So admission, not spending, depletes the lifetime pool.

     Owner identities are free (any EOA that signs the SIWE challenge gets a principal, src/identity/index.mjs:134-138), project creation is public, so perOwnerDay=2 does not bind a hostile party: four throwaway wallets x two projects consume 8 x 0.5 IMD = the entire planned 4 IMD / 7-day allocation in one day while the sponsor spends nothing and no review is performed; every honest review_accept then fails with sponsor_exhausted until the network owner publishes a larger maximumLifetime, which the pilot explicitly does not plan ('no auto-refill').

     The same consumption happens via the runPaid denied path (payment_window_expired / source withdrawn) without any cancel call. test/review-flow.test.mjs:188-217 encodes the current behaviour as intended, but only checks that the cap survives policy changes.

     Fix: in reviews.cancelUnsent (or flow.onCancel / the runPaid denied commit, same transaction) subtract the voided maximum from public-review-exposure/lifetime when the job was admitted under kind 'public', keyed per job so it cannot be released twice; keep the day counters consumed for rate limiting. Merged from audit_flow, audit_economics, audit_permissions and audit_math; the audit_math per-owner Sybil note is folded in as the reason perOwnerDay does not bound the attacker.

     whole finding

     Executed: test/scratch/repro-exposure.test.mjs (passes against this revision) using the real createApplication with SQLite.

     State: review.admission policy {maximumPerReview 0.5 IMD, maximumLifetime 4 IMD, perOwnerDay 2, perProjectDay 2, globalDay 8, activeGlobal 8} active, sponsor funded with 4 IMD, no pilots.

     Input: four fresh EOAs each log in, create two projects, snapshot, compile, publish source, review_create, (worker runQuote), review_accept, then jobs.cancel(executionJobId) before any worker tick.

     Expected: a cancelled, provably unsent admission returns its share of the lifetime exposure as its billing reservation is returned.

     Actual: sponsor ledger spent='0', reserved='0', available=4 IMD, while admission.get().committedMaximum = '4000000000000000000'; a fifth honest owner's review_accept rejects with code sponsor_exhausted.

     whole reproduction

   • mediumA payment that fails during local signing (including the new 1-second IMD window) is parked as signing_unknown forever: never abandoned, not cancellable, holding sponsor funds and a public active-revisrc/review-flow/index.mjs:292

     adapters/imd-payment.mjs prepare() wraps Permit2/quote signing in try/catch and on any throw rewrites the record to state 'signing_unknown' and throws payment_signing_unknown (lines 92-95). Nothing has left the host at that point (provider.submit is not called; sealedMaterial absent) and abandonUnsent() explicitly treats 'signing_unknown' as cancellable (line 40).

     But runPaid's denied list (this line) does not contain payment_signing_unknown, so tick 1 ends 'waiting' (line 311). On every later tick payment.status() is non-null so prepare() is skipped, state !== 'prepared' so submit is skipped, reconcile() keeps the state, costReceipt is null, providerJobId is null and line 289 re-queues the job 'waiting' indefinitely.

     Because beginEffect ran before prepare, jobs.cancel is refused with effect_requires_reconciliation; cancelUnsent is only reachable from the denied path. The review-jobs row stays work=outcome_unknown / billing=pending, the sponsor's 0.5 IMD reservation is never released, the job stays in active-paid-reviews so beforeAdmission counts it against activeGlobal (8) and refuses the project with review_in_progress.

     Trigger is realistic in this revision: adapters/imd.mjs:137-138 and imd-payment.mjs:53-54 now accept any maxTimeoutSeconds in (0,300] (test/imd-window.test.mjs asserts 1 is accepted); the deadline is computed at line 55 and re-checked at line 87 after two store transactions and two signatures, so a 1 s window that crosses a UTC-second boundary throws payment_window_expired inside the try block and is converted into signing_unknown.

     Note that payment_window_expired itself IS in the denied list, so the conversion defeats the existing recovery. Any transient signer/KMS error has the same effect. Eight such events close the public programme with no API-level recovery.

     Fix: add payment_signing_unknown to the denied codes (abandonUnsent + cancelUnsent inside jobs.finish), or in runPaid when state.state === 'signing_unknown' abandon and re-prepare; consider a minimum accepted maxTimeoutSeconds (e.g. >= 60). Merged from audit_flow and audit_math.

     whole finding

     Executed: test/scratch/repro-signing-unknown.test.mjs test 'C' (passes against this revision) with the real createApplication, createReviewFlow and createImdPayment.

     State: public review admitted (0.5 IMD reserved on the sponsor account).

     Input: provider.challenge returns accepts[0].maxTimeoutSeconds = 1; the payment adapter's clock advances 400 ms per read (two store transactions and two signatures between the deadline computation and the line-87 check).

     Expected: since nothing was sent, the review is abandoned (billing void, slot released) or at least job_cancel succeeds.

     Actual: runPaid #1 -> {state:'waiting', result.error:'payment_signing_unknown'}, imd-payments[offer].state === 'signing_unknown', provider.submit called 0 times; runPaid #2..#4 (130 s apart) -> 'waiting' with paymentState 'signing_unknown'; review-job work='outcome_unknown', billing='pending'; sponsor reserved = 500000000000000000; jobs.cancel(executionJobId) rejects with effect_requires_reconciliation; active-paid-reviews still contains the job.

     whole reproduction

   • mediumA failed provider submit leaves the payment in outcome_unknown with no terminal path, even when the provider reports the order expired unpaid; the accepted 1-second permit window makes this the expectadapters/imd-payment.mjs:111

     submit() moves the record to 'outcome_unknown' whenever provider.submit() throws for any reason (transport error or any non-200/202 status such as 402/409/429).

     From there nothing can close the review: abandonUnsent refuses (line 40), reconcile() only ever promotes to provider_paid (lines 120-121) and keeps the state when the provider reports expired/payment_failed, runPaid (src/review-flow/index.mjs:289) has no branch for it and re-queues 'waiting' every 60 s forever, jobs.cancel refuses because effect is outcome_unknown, and there is no operator route to settle or void a review-job.

     The sponsor reservation (0.5 IMD) stays locked, the job stays in active-paid-reviews (consuming one of 8 activeGlobal slots and blocking the project with review_in_progress), and the quote can never be re-admitted (quote_already_admitted).

     Keeping an uncertain send unreversed is deliberate, but this revision makes the uncertain outcome likely: commit a6a4d12 replaced the fixed 300 s permit deadline by accepted.maxTimeoutSeconds with only 0 < n <= 300 enforced (adapters/imd.mjs:137-138, imd-payment.mjs:53-55), so with maxTimeoutSeconds = 1 the Permit2 deadline is now+1 s; submit() only checks old.deadline > seconds() locally (line 102) and the facilitator settles one or more blocks later, where Permit2 reverts SignatureExpired and the provider answers non-2xx.

     Fix: require a safety margin (e.g. maxTimeoutSeconds >= 60 and deadline - seconds() >= 30 at submit, else fail with payment_window_expired before any send), and add a reconciliation rule that, once the provider reports expired/payment_failed with paid=false AND the permit deadline is well past, moves outcome_unknown to a terminal cancelled state and calls reviews.cancelUnsent so the reservation and active slot are released. Merged from audit_economics and audit_permissions.

     whole finding

     Executed: test/scratch/repro-signing-unknown.test.mjs test 'D' (passes against this revision).

     State: public review admitted (0.5 IMD reserved).

     Input: challenge with maxTimeoutSeconds = 1; provider.submit throws provider_request_rejected (HTTP 402); provider.status later returns {status:'expired', payment:{paid:false}}.

     Expected: a permit that can no longer settle is released, or the job reaches a terminal state once the provider confirms the order expired unpaid.

     Actual: stored permit deadline == signing second + 1; runPaid #1 -> waiting/paymentState outcome_unknown with exactly one submit; runPaid #2..#4 (130 s apart, provider reporting 'expired') -> waiting/outcome_unknown each time; review-job work='outcome_unknown', billing='pending'; jobs.cancel -> effect_requires_reconciliation; a new review_accept for the same quote -> quote_already_admitted; sponsor reserved stays 500000000000000000.

     whole reproduction

   • mediumPublic dispatcher budget has no per-project share: one admitted project with requester-chosen callbackGas drains the shared 0.0004 test-ETH callback allocation and every other project is refused forevadapters/contract-delivery.mjs:99

     In 'public-readonly-v1' mode admitContractDispatchBudget requires projectIds to be empty (line 18) and reserve() enforces only the per-transaction ceiling and the global total (lines 99-101). There is no per-project or per-binding accounting for dispatcher spending, unlike executor gas (src/chain-deployments/admission.mjs reserveGas enforces maximumProjectGasWei).

     The cost of each delivery is largely chosen by the requester: ClausRequestInbox.request() accepts callbackGas up to 1,000,000 (ClausRequestInbox.sol:28,51) and deliverCallback forwards exactly that gas (lines 93-99); a hostile receiver burns all of it and may revert, which still charges the dispatcher's budget via finalize() (sepolia-transactions.mjs:141-142) and yields a 'failed' delivery. The operator's own reference client defaults to CALLBACK_GAS = 1_000_000.

     Rejected decisions cost no executor gas, so the per-project executor cap does not bound this; a project may hold 32 bindings x 100 requests. With the planned allocation (0.0004 total, 0.0002 per transaction) two callbacks exhaust the pool; afterwards reserve() throws dispatch_budget_exhausted for everyone and the worker defers them on every tick (runtime/contract-intake-worker.mjs:76-78).

     Spending is immutable by design, so public callback delivery is dead for the other seven projects until the operator authorises a new grant. Amplifier (code-traced): the requester can cancel() its request after result_ready and before the dispatcher's resolve lands (authorize reads 'latest' only, line 139-141); resolve reverts with RequestClosed and the reverted gas is charged to the shared budget.

     Fix: add a per-project (or per-binding) ceiling to the public dispatch budget and account reservations/spending per request.projectId in reserve()/finalize(), and/or cap the callbackGas the dispatcher is willing to pay for at ingest. Merged from audit_flow and audit_math.

     whole finding

     Executed: test/scratch/repro-delivery.test.mjs test 'B' (passes against this revision) with the real admitContractDispatchBudget/createContractDelivery/createSepoliaTransactions and a mock client.

     State: public budget {admissionMode 'public-readonly-v1', projectIds [], maximumTotal 0.0004 ETH, maximumTransaction 0.0002 ETH}, fee 0.12 gwei, deliverCallback estimate 1.2M gas (callbackGas 1,000,000) signed at 1.51M, receiver burns 1.5M gas and reverts.

     Input: two result_ready 'reject' requests from project 'hostile', one 110k-gas resolve from project 'victim'.

     Actual: hostile resolve#1 + callback#1 (reverted, 'failed') + resolve#2 + callback#2 (reverted, 'failed') bring the ledger to spent='384000000000000' (0.000384 ETH), reserved='0'; the victim's step rejects with dispatch_budget_exhausted; 4 broadcasts total.

     Expected: a per-project share so one project cannot deny delivery to the other admitted projects.

     whole reproduction

   • mediumProjects whose owner pilot expired are admitted through the public chain policy but bypass the public gas ledger (per-project and total executor gas caps)src/chain-deployments/admission.mjs:71

     createChainDeployments.allowed() (src/chain-deployments/index.mjs:16) falls through to admission.admitted() as soon as a project has no live pilot, so an expired-pilot project is authorised by the public chain.admission policy for registration_prepare/registration_submit, proposal_create and the executor jobs that follow.

     A public-chain-projects row is only created in deployModule() via reserveProject() (index.mjs:45); registration, Claus decisions and protected-execute never call it. reserveGas() returns at this line before any accounting when that row is missing, so such a project's registerProject/queue/execute transactions are not counted against maximumProjects (8), maximumProjectGasWei (0.0005) or maximumTotalGasWei (0.002); only the host-wide ceilings of createSepoliaTransactions apply (adapters/chain-executor.mjs:12-13 passes no limits, so MAX_COST = 0.01 test-ETH per transaction).

     The same applies to module-deploy jobs queued under a live pilot and executed after expiry. The brief's invariant 'exact per-project and total executor gas' is therefore only enforced for projects that first deploy a module after their pilot ended.

     Fix: in allowed()/admitted paths, call reserveProject() for any project without a live pilot before authorising executor work (registration, proposal, execute), or make reserveGas() fail closed (chain_gas_exhausted / capacity_reached) when the project row is missing instead of returning silently.

     whole finding

     Executed: test/scratch/repro-expired-pilot.test.mjs (passes against this revision).

     State: chain.admission policy active and assessed (maximumProjects 8, 0.0002/0.0005/0.002 ETH caps); project 'former' has review-pilots {enabled:true, expiresAt: past}, no public-chain-projects row; chain-proposals 'proposal-1' belongs to it.

     Actual: deployments.allowed('owner','former') returns the capability; createSepoliaTransactions({onReserve: admission.reserveGas}).prepare({id:'register:r1', authority:{kind:'project-register', projectId:'former'}}) with 3.76M gas at 2 gwei (0.0075 ETH, >30x the per-transaction cap) returns state 'prepared'; public-chain-usage/global stays null and public-chain-reservations has 0 rows; reserveGas for {kind:'execute', proposalId:'proposal-1'} with 0.009 ETH also records nothing.

     Contrast: a project that went through reserveProject() is refused with chain_gas_exhausted for the same amount.

     Expected: chain_gas_exhausted (limits 0.0002/0.0005/0.002) or refusal to admit the project without a public slot.

     whole reproduction

   • lowAfter a dispatcher budget rotation, callbacks for requests resolved under the revoked/expired prior budget are never dispatched although the new budget is activeadapters/contract-delivery.mjs:58

     createContractDelivery.step() selects the budget from the stored ':resolve' transaction's authority and then runs the whole step, including the separate not-yet-created 'callback' transaction, under that prior budget.

     For the callback, expiresAt is prior.expiresAt and active() returns false whenever the prior budget is revoked or expired (lines 76-77), so line 155 answers 'pending' and no callback is ever prepared, even though the currently selected public budget is active, funded and admits the project. The worker re-steps such rows on every tick (several RPC reads each) because 'pending' is not terminal; the requester never receives onClausResult unless it pulls the result itself.

     With the planned 7-day budget expiry this affects every request resolved shortly before expiry and all in-flight requests at the pilot -> public-readonly-v1 migration this revision prepares.

     Fix: apply the prior budget only to actions that already have a stored transaction under it; for a missing callback transaction fall through to the selected budget (or record a terminal 'failed' delivery with a reason). Merged from audit_economics and audit_math.

     whole finding

     Executed: test/scratch/repro-delivery.test.mjs test 'I' (passes against this revision).

     State: budget 'public-budget' selected; request with callback intent; step -> resolve broadcast and confirmed.

     Then admit 'public-next' (same inbox/codeHash/dispatcher, public mode) and revoke 'public-budget'.

     Input: three step() calls with 'public-next' selected and allowSubmit true.

     Actual: 'pending' each time, broadcasts stay at 1, no 'contract-delivery::callback' row exists, public-next ledger reserved='0' spent='0'.

     Expected: callback prepared and sent under the active budget, delivery ending 'delivered' or 'failed'.

     whole reproduction

   • lowA callback whose cost exceeds the per-transaction budget is retried on every tick forever and never recorded; the reference client's 1,000,000 callbackGas makes this the normal caseruntime/contract-intake-worker.mjs:76

     For the callback action transactions.prepare() estimates deliverCallback() (which must leave callbackGas*64/63 + 50,000 gas, ClausRequestInbox.sol:95) and adds the 25 % + 10,000 margin. With ClausRequestClient.CALLBACK_GAS = 1_000_000 the signed gas is about 1.5M, so above roughly 0.13 gwei the cost exceeds a 0.0002 test-ETH maximumTransaction and prepare() throws transaction_cost_limit (sepolia-transactions.mjs:58-60).

     The worker classifies that code as transient (this line), step() has returned nothing, request.delivery is never written, and the request stays result_ready without a delivery state, so every subsequent tick repeats chain.profile, chain.resolution, transactions.status, two deliveryState reads and a fresh estimateGas for every such request indefinitely, although the resolve already succeeded and the design promises one bounded callback attempt.

     Hostile requesters make this permanent for their own requests by choosing callbackGas = 1,000,000.

     Fix: when the callback can never fit (cost > maximumTransaction at the current fee, or after N attempts), record a terminal delivery state such as 'failed' with reason callback_unaffordable so the request leaves the scan set; optionally bound accepted callbackGas at ingest.

     whole finding

     Executed: test/scratch/repro-delivery.test.mjs test 'L' (passes against this revision).

     State: public budget maximumTransaction 0.0002 ETH, fee 0.15 gwei, request with callbackGas 1,000,000 (deliverCallback estimate 1.2M gas -> signed 1.51M -> 0.0002265 ETH); resolve confirmed.

     Actual: three further step() calls each reject with transaction_cost_limit; no ':callback' transaction row is created; two createContractIntakeWorker.tick() runs each report deferred=1 and contract-requests[id].delivery stays undefined.

     Expected: one bounded attempt or a recorded terminal delivery state.

     whole reproduction

   • lowA broadcast dispatcher/executor transaction that is never mined holds the single wallet slot and its budget reservation indefinitely; no replacement, expiry or release path existsadapters/sepolia-transactions.mjs:123

     reconcile() returns early whenever no receipt is available and never consults intent.expiresAt, the on-chain request deadline or the account nonce.

     A transaction in state 'submitted' or 'unknown' therefore keeps chain-wallet-slots[walletId].id set forever, so every later prepare() for the same signer fails with wallet_busy (dispatcher: all public result delivery; executor: all deployments, registrations, queue/execute), and the onReserve amount stays in budget.reserved (contract-dispatch-budgets or public-chain-usage), up to maximumTransaction of the 0.0004 ETH dispatcher allocation.

     The fee is fixed at prepare() time from estimateFeesPerGas(); a Sepolia base-fee rise above the signed maxFeePerGas for longer than mempool retention (cheap to induce with free test ETH) leaves the transaction unmineable, and once the inbox request deadline passes the resolve() call can never succeed anyway. The design note accepts a locked slot across restarts, but no code path or host tool can ever resolve it other than editing chain-wallet-slots and the budget row by hand.

     Fix: when intent.expiresAt has passed and getTransactionCount(signer,'finalized') > value.nonce with no receipt for value.hash (the signed bytes can no longer be mined), finalize the row as 'superseded', settle the reservation at 0 and release the slot; or expose a host-only same-nonce replacement bounded by the same ceilings. Merged from audit_flow and audit_economics.

     whole finding

     Executed: test/scratch/repro-stuck-tx.test.mjs (passes against this revision).

     State: prepare + submit of 'resolve:1' with sendRawTransaction returning the hash (state 'submitted'); getTransactionReceipt always throws (dropped from every mempool).

     Input: advance the clock 30 days past intent.expiresAt, call reconcile three times, then prepare 'resolve:2'.

     Actual: reconcile returns 'submitted' each time; prepare rejects with wallet_busy; the onReserve amount (135000000000000 wei) is never finalized; chain-wallet-slots still names 'resolve:1'.

     Expected: after expiry with the transaction provably unmineable, the slot and reservation are released.

     whole reproduction

   • lowDispatcher authorization performs Sepolia RPC reads inside the store transaction that holds the schema-wide PostgreSQL advisory lock, stalling every API write for the RPC round tripsadapters/contract-delivery.mjs:140

     createSepoliaTransactions.prepare() and submit() invoke the authorize callback inside store.transaction (adapters/sepolia-transactions.mjs:64 and 94). The contract-delivery authorize callback calls active() (store reads) and then chain.deliveryState(request) on this line, i.e. getBlock, getChainId, getCode, readContract(dispatcher), getBlock(observation.blockNumber) and readContract(requests) sequentially against the public Sepolia RPC.

     The PostgreSQL store serialises all transactions behind pg_advisory_xact_lock(schema) (src/postgres/index.mjs:53) and sets idle_in_transaction_session_timeout='15s' (line 50); the intake host shares that database with the public API (runtime/contract-intake-host.mjs:18-26).

     While the worker waits on the RPC, every store.transaction in the API is blocked, including the per-request rate-limit admission in runtime/server.mjs:83-87 that runs for every HTTP/MCP call; if the RPC round trips exceed 15 s idle time PostgreSQL kills the worker session and tick() fails with a non-authority error. The module's own invariant says the lock 'serializes short state transitions, not provider calls'; this path violates it.

     The executor path keeps RPC validation outside the transaction (adapters/chain-executor.mjs validate()), so the fix pattern exists.

     Fix: evaluate chain.deliveryState() before entering the transaction (the pre-check at line 149 already does) and pass the observed snapshot into authorize, keeping only store reads inside the lock. Merged from audit_flow and audit_economics.

     whole finding

     Code-traced (not executed against PostgreSQL): adapters/sepolia-transactions.mjs:61-64 opens store.transaction and awaits authorize(intent, tx); adapters/contract-delivery.mjs:135-141 is that callback and awaits chain.deliveryState(request) (adapters/contract-intake.mjs:97-118: getBlock, verify() = getChainId+getCode+readContract, getBlock, readContract); src/postgres/index.mjs:48-53 takes pg_advisory_xact_lock for the whole schema at the start of every transaction.

     Input: one result_ready request being prepared while the public RPC answers each call in ~3 s (or stalls to its 15 s timeout).

     Expected: API writes commit in milliseconds; RPC latency is paid outside the lock.

     Actual: all concurrent API transactions (rate-limit admission included) wait behind the advisory lock for the whole RPC sequence; beyond 15 s idle the worker transaction is terminated.

     whole reproduction

   • lowContract bindings (and long-running chain jobs) created from a 60-minute owner session credential silently stop working after the credential expiressrc/contract-intake/index.mjs:32

     bind() stores the calling credential digest as binding.actor and every later step re-authorises that exact credential: ingest() and run() via admitted() (this line and 33), delivery via identity.authorize(binding.actor, ...) in adapters/contract-delivery.mjs:87-88.

     Owner session credentials expire after OWNER_TTL = 60 minutes (src/identity/index.mjs:18,138) and cannot be renewed; bind() accepts them (contract.request is an ordinary owner project scope) and allows expiresAt up to 30 days.

     After one hour identity.credential() throws unauthenticated, allowed() converts that to false (lines 70-72) and authorize() throws scope_denied, so new inbox requests for the binding are recorded as 'blocked' in contract-intake-rejections while contract_binding_get still shows a healthy binding, and a request already in result_ready is never resolved on chain because active() returns false and step() answers 'pending' forever.

     The same pattern affects proposals created with an owner session whose Claus decision or per-project accepted delay exceeds an hour (approvals.runDecision/runExecution authorize claim.job.authority.actor), where the off-chain record ends 'blocked' although the published Claus signature stays executable by anyone after readyAt. Fail-closed, so no authorization bypass, but the public intake path is unreliable for exactly the free owner accounts the pilot targets.

     Fix: require an agent credential/mandate for bind() (reject kind 'owner'), or authorise later steps against the project's current owner/mandate rather than the original credential digest. Merged from audit_flow and audit_permissions.

     whole finding

     Code-traced: src/identity/index.mjs:138 sets owner credential expiresAt = now()+OWNER_TTL (3,600,000 ms); credential() (line 44) throws unauthenticated once passed; allowed() (lines 70-72) returns false for unauthenticated; authorize() (line 76) throws scope_denied. src/contract-intake/index.mjs:36-59 bind() stores actor in the binding (line 44) and accepts any actor that passes admitted() (owner scopes include contract.request and proposal.create).

     Input: owner logs in, contract_binding_create {expiresAt: now+7d, maxRequests 10}; the requester contract submits a request 61 minutes later; another request became result_ready meanwhile.

     Expected: both are processed until the binding expires or is revoked.

     Actual: ingest -> admitted() -> scope_denied -> recorded in contract-intake-rejections (worker line 38-45); delivery active() -> scope_denied -> false -> step returns 'pending' every tick (contract-delivery.mjs:89-90,155).

     whole reproduction

   • lowExecutor jobs whose gas reservation can never succeed (chain_gas_exhausted, transaction_cost_limit, invalid_transaction after expiry) are retried every 60 s forever and hold their public project slotsrc/chain-deployments/index.mjs:139

     reserveGas (src/chain-deployments/admission.mjs:73,79) throws chain_gas_exhausted from inside createSepoliaTransactions.prepare when a public project's maximumProjectGasWei or the total is used up, and prepare itself throws transaction_cost_limit when gas*maxFeePerGas exceeds the ceiling, and invalid_transaction once value.expiresAt has passed (sepolia-transactions.mjs:46).

     None of these codes is in adapters/authorization.mjs authorityDenied, so chain-executor.transact rethrows and runOne's catch re-queues the job 'waiting' with a 60 s retry (this line); the 'blocked' branch (line 133) only covers scope_denied/sponsor_not_enabled/chain_not_enabled and only in dispatch mode, which beginEffect has already consumed.

     Each retry performs estimateGas/estimateFeesPerGas/getTransactionCount/getBalance against the RPC; the chain-modules row stays 'queued' and the project's reserved public slot (1 of 8) is consumed by a module that will never exist. The same loop applies to protected-execute jobs. A hostile public project that exhausts its own 0.0005 ETH therefore creates permanent background work for the executor worker.

     Fix: treat chain_gas_exhausted, transaction_cost_limit (when no transaction exists yet) and invalid_transaction (intent expired) as terminal in runOne/runExecution, mark the module/proposal 'blocked' and release the public project slot when a module is abandoned.

     whole finding

     Code-traced: adapters/authorization.mjs lists the authorityDenied codes (chain_gas_exhausted, transaction_cost_limit and invalid_transaction are absent); adapters/chain-executor.mjs:30-35 rethrows non-authority errors from prepare(); src/chain-deployments/index.mjs:131-140 maps any other error to {state:'waiting', retryAt: now()+60000}.

     Input: public project p1 with public-chain-projects spent = maximumProjectGasWei; a module-deploy job for p1 claimed every tick.

     Expected: the job ends 'blocked'/'failed' and the module is marked accordingly.

     Actual: every tick re-estimates and re-queues 'waiting' indefinitely; after 24 h the intent's expiresAt makes prepare throw invalid_transaction, which is equally non-terminal.

     whole reproduction

   • lowNo cap on proposals or ingested contract requests per admitted project: unbounded operator-paid Claus decisions and intake queue crowdingsrc/approvals/index.mjs:74

     approvals.create() only serialises proposals per project (this line); there is no per-project, per-day or global count and no access-policy key for it (src/access/index.mjs ACCESS_DEFAULTS has none).

     Every proposal enqueues a claus-review job whose runDecision() POSTs the full input (up to 900 KB including the review report and all source files, line 64) to the Claus agent (adapters/claus-controller.mjs:55 call('/reviews', input)), an operator-paid model review; rejected proposals cost no gas, so an admitted public project can loop proposal_create -> wait for decision -> proposal_create bounded only by decision latency and the 300 req/5 min rate limit, driving unbounded inference spend although the brief excludes public inference.

     On the intake side the only bounds are maxRequests <= 100 per binding and 32 bindings per project (src/contract-intake/index.mjs:40,53), i.e. 3,200 queued requests per project; createContractIntake.run() claims one job per tick, and every request behind an in-progress proposal reaches createProposal(), performs the full artifact/evidence/RPC assembly of approvals.create() and only then fails with proposal_in_progress (not in the denied list, lines 147-148), returning to 'waiting' for 60 s, so other admitted projects' result recording is delayed behind thousands of unproductive jobs.

     Fix: add an access-policy limit on proposals per project per day (and a lifetime decision budget per public project), check active-proposals before assembling the input, and bound queued contract requests per project.

     whole finding

     Code-traced: src/approvals/index.mjs:32-86 contains no counter read or write other than active-proposals; src/access/index.mjs:5-14 defines no proposal limit; adapters/claus-controller.mjs:50-55 records the decision request and POSTs the input per proposal.

     Input: admitted project P repeats proposal_create {moduleId, configuration: random bytes, idempotencyKey: i} after each decision; P also creates 32 bindings and its requester contract submits 3,200 inbox requests with a 30-day deadline.

     Expected: an admission limit such as N decisions per project per day, and cheap rejection of requests behind an in-progress proposal.

     Actual: every proposal is accepted and triggers one Claus review call; every queued request is re-assembled and re-queued each 60 s while P's first proposal is reviewing, one claim per tick for all projects.

     whole reproduction
7. Onchain1 receipt, 5 scores queuedon Ethereum mainnet

   receipt

   work accepted · record queued

   scores

   5 scores for reviewed on submission · all 5 passed#1979#158#976#866#671