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

Download the report (Markdown)

3 medium6 low4 info

• 1.mediumCancelled approval with no local queue record queries UpgradeExecuted logs from block 0; public RPCs reject the range, so the proposal never reaches a terminal state and the project's pipeline is wedgadapters/chain-executor.mjs:164

            fromBlock: BigInt(queued?.receipt?.blockNumber ?? 0), toBlock: 'latest' });

  Shared core path on both chains. When executionNonces[projectKey][nonce] is already true on the executor but the worker holds no 'queue:' transaction record (the project owner, or the Claus signer, called cancelApproval(id, nonce) on-chain before the executor queued; the contract allows this at any time), execution.step calls client.getLogs with fromBlock 0n and toBlock 'latest'.

  Both public endpoints this release uses refuse that: the hard-coded Sepolia publicnode endpoint (runtime/chain-worker.mjs:19) answers 'exceed maximum block range: 50000' and the mainnet publicnode endpoint answers 'Archive requests require a personal token' (both observed with curl on 2026-10-12).

  The RPC error is not an authority code, so runExecution (src/approvals/index.mjs:209) records state 'waiting' with retryAt now+60s and repeats the same full-range query every minute indefinitely. The expected { state: 'blocked', error: 'approval_cancelled' } is never produced and the approval_expired check at line 183 sits below the getLogs call so it is never reached either.

  Because beginEffect already flipped the job to effect 'outcome_unknown', jobs.cancel rejects with effect_requires_reconciliation, and because active-proposals still points at this proposal, approvals.create rejects every new proposal for the project with proposal_in_progress (src/approvals/index.mjs:46). One legitimate on-chain cancellation therefore permanently wedges the project's upgrade pipeline and keeps a worker busy.

  No transaction is signed on this path; this is a liveness/recovery defect, not an authorization bypass.

  Fix: bound fromBlock to a block at or before which the approval could not have executed (e.g. BigInt(input.evidence.chain.blockNumber), the finalized evidence block captured at proposal creation, or the binding's registration block) and move the approval_expired check above the log query so an expired cancelled approval ends as failed.

  whole finding

  State: network-capabilities 'chain:1' enabled with approvalSigner A and executorPayer P; claus-signed-approvals row for proposal 'prop1' whose Approval signature by A verifies; chain-bindings for the project; no chain-transactions rows 'queue:prop1' or 'execute:prop1'; client.readContract('executionNonces') returns true; client.getLogs rejects any request with fromBlock 0n / range > 50000 with Error('exceed maximum block range: 50000') (the public RPC behaviour).

  Input: createChainExecutor({ chainId: 1, ... }).execution.step({ value, authorize: async () => true }) three times.

  Expected: { state: 'blocked', error: 'approval_cancelled' }.

  Actual: every call issues getLogs({ fromBlock: 0n, toBlock: 'latest' }) and throws 'exceed maximum block range: 50000'; runExecution maps that to waiting/60 s forever.

  Reproduced by test/scratch/judge.test.mjs test 'A' (output: result { state: 'threw', error: 'exceed maximum block range: 50000' }, getLogs calls all { fromBlock: 0n, toBlock: 'latest' }).

  whole reproduction

• 2.mediumExpired module and registration jobs throw invalid_transaction on every tick instead of ending; a reviewed module that misses its 24 h window can never be redeployed on that chainsrc/chain-deployments/index.mjs:170

          return jobs.finish(claim, { state: 'waiting', retryAt: now() + (['chain_gas_exhausted', 'transaction_cost_limit'].includes(error.code) ? 15 * 60000 : 60000),

  transactions.prepare (adapters/sepolia-transactions.mjs:52) rejects any intent whose expiresAt is not in the future with invalid_transaction.

  The executor passes value.expiresAt (module rows: now + 86400000, index.mjs:78) and message.expiresAt * 1000 (registrations: one hour after preparation, index.mjs:94). invalid_transaction is neither in authorityDenied nor in runOne's dispatch block list, so runOne parks the job 'waiting' with a 60 s retry, the chain-modules / chain-registrations row stays 'queued', and jobs.claim has no attempt limit: the job wakes every minute forever with no terminal state.

  For modules the consequence is permanent: deployModule derives the module id from { projectId, caseId, kind, chainId } and returns the existing row unchanged (index.mjs:67-68), so the project can never redeploy that reviewed case on that chain.

  The window is realistic under the proposed mainnet ceilings: a module whose reservation exceeds 0.001 ETH per transaction is retried every 15 minutes (chain_gas_exhausted) and the row expires after 24 h, so one day of maxFeePerGas above the ceiling, or a one-day worker outage, lands here; registrations only need the executor to be unavailable for the remainder of the one-hour signing window.

  The execution path already handles its analogue (approval_expired at adapters/chain-executor.mjs:183); the deployment path does not. No funds move.

  Fix: in deployment.step (or transact) check the window before prepare and return { state: 'failed', error: 'deployment_expired' | 'registration_expired' } so runOne finishes the job and the row becomes terminal; let deployModule create a fresh row (or clear the expired one) when the previous record is in a terminal expired state.

  whole finding

  State: network-capabilities 'chain:1' enabled with executorPayer = the executor signer; review-cases 'case1' reviewed for 'prj_x' and its public-sources row published; no chain-transactions rows.

  Input: executor.deployment.step({ kind: 'module-deploy', value: { id: 'm1', projectId: 'prj_x', caseId: 'case1', chainId: 1, state: 'queued', expiresAt: Date.now() - 1 }, artifact: , authorize: async () => true }) three times.

  Expected: a terminal result (e.g. { state: 'failed', error: 'deployment_expired' }).

  Actual: every call rejects with code invalid_transaction; runOne's catch maps it to waiting with retryAt now+60 s and deployModule keeps returning the expired 'queued' row.

  Reproduced by test/scratch/judge.test.mjs test 'B' (output: ['invalid_transaction','invalid_transaction','invalid_transaction']).

  The registration kind reaches the same prepare check with message.expiresAt * 1000 in the past.

  whole reproduction

• 3.mediumA broadcast whose send fails or whose transaction is evicted is never rebroadcast; one transient RPC failure holds the single mainnet wallet slot and its budget reservation for the whole windowadapters/sepolia-transactions.mjs:97

          if (row.value.state !== 'prepared') return null;

  prepare seals the signed raw bytes and durably records hash and nonce before any broadcast, which is correct. But submit only sends when state === 'prepared'. After one failed sendRawTransaction the record becomes 'unknown' and every later tick goes submit -> null, reconcile -> receipt not found -> return unchanged (line 129).

  The identical sealed bytes are never sent again, the chain-wallet-slots row for '1:' stays locked to that id (released only on confirmed/reverted/cancelled, lines 42-47, 107, 149), and the admission reservation in public-chain-projects.reserved and public-chain-usage.mainnet.reserved stays held because finalizeGas never runs. intent.expiresAt is never consulted for 'unknown' or 'submitted' records, so there is no automatic release either.

  The same applies to a 'submitted' transaction that is dropped from mempools because the base fee rose above its signed maxFeePerGas, which the proposed ceilings make likely (0.001 ETH per transaction caps registerProject at about 1.1 gwei maxFeePerGas), and to a nonce the operator replaces by hand: reconcile never checks getTransactionCount('latest') > value.nonce, so the record stays 'submitted' forever.

  Every later prepare on chain 1 then fails wallet_busy (line 72) and all mainnet jobs park 'waiting'. Retaining one hash and nonce (the stated intent) is compatible with re-sending the identical raw transaction (same hash, same nonce) while no receipt exists. Not a fund-loss issue; a liveness/recovery gap with no code path, helper or documented procedure in docs/mainnet.md 'Pause and recovery'.

  Fix: (a) in reconcile (or submit) re-broadcast the sealed raw bytes while the record is 'unknown' or 'submitted', getTransaction(hash) is null and getTransactionCount('latest') <= nonce; (b) when getTransactionCount(payer, 'latest') > value.nonce and no receipt exists for value.hash, mark the record 'replaced', call onFinalize with actual '0' and release the slot with consumedNonce = nonce; (c) document the manual procedure otherwise.

  whole finding

  Store ':memory:', chainId 1, stub client whose sendRawTransaction throws once then succeeds. prepare({ id: 'one', data: '0x60006000', authority, expiresAt: now+60s }) then submit('one') => state 'unknown', sends = 1.

  Make the stub succeed and call submit('one') + reconcile('one') three times.

  Expected: the sealed raw transaction is resent (sends = 2) or the intent is released after intent.expiresAt.

  Actual: sends stays 1, state stays 'unknown', and prepare({ id: 'two' }) rejects with wallet_busy.

  Reproduced by test/scratch/judge.test.mjs test 'D' (output: 'D sends 1 state unknown').

  whole reproduction

• 4.lowProposed bootstrap ceiling (0.0046 ETH, 5,000,000 gas) only admits the executor deployment below about 1.33 gwei maxFeePerGas, cannot fit the ~19.6M gas the repository itself documents under the stateintegration/mainnet-release.mjs:35

      limits: { gas: '5000000', cost: plan.bootstrapMaximumWei },

  deployMainnetRelease narrows the host limits to gas 5,000,000 and cost plan.bootstrapMaximumWei. createReadonlyTransactions reserves gas = estimateGas*125/100 + 10000 and requires gas * fees.maxFeePerGas <= cost (adapters/sepolia-transactions.mjs:63-66), where viem's estimateFeesPerGas returns about 1.2 x base fee + suggested priority fee.

  Measured 2026-10-12 with the exact ClausApprovalExecutor creation data from contracts/out at commit af8cf637 (constructor (signer, recovery, 172800)): eth_estimateGas returns 2,783,947 on public mainnet (padded 3,489,933) and 19,566,580 on public Sepolia (padded 24,468,235), consistent with the comment at adapters/sepolia-transactions.mjs:6-8 that the Glamsterdam state-creation repricing makes this deployment ~19.5M gas and was the reason MAX_GAS became 30,000,000.

  Consequences: (1) today, the 0.0046 ETH ceiling admits the bootstrap only while maxFeePerGas <= 4.6e15 / 3,489,933 = 1.318 gwei, i.e. mainnet base fee below roughly 1.1 gwei with a 0 priority suggestion (observed mainnet on 2026-10-12: base 0.095 gwei, so it currently fits); (2) once the mainnet client applies the repricing the padded gas is 24,468,235 > 5,000,000 and every deployMainnetRelease call throws transaction_cost_limit before any record is written, so the plan would have to be re-approved with a new digest; (3) the opt-in fixture 'local chain 1 release resumes one deployment ...' does not pin the local chain's fees, and on a default anvil (base fee 1 gwei, priority 1 gwei -> maxFeePerGas 2.2 gwei) the reservation is 3,461,085 * 2.2 gwei = 0.00761 ETH > 0.0046 ETH, so the only test of the resume/stage path fails as shipped and the path it claims to exercise is untested.

  The gate fails closed and nothing is spent; this is a release-plan/test inconsistency and an operability limit the brief asked to assess, not a security failure.

  Fix: have the plan carry the gas ceiling and the maximum fee it was estimated under (bounded by MAX_GAS) instead of a hard-coded 5,000,000, state that fee assumption next to the 0.0046 ETH ceiling in docs/mainnet.md, and start the fixture's anvil with a pinned base fee (e.g. --base-fee 100000000) or set bootstrapMaximumWei from observed fees so the gate is actually verified.

  whole finding

  Commands: anvil --chain-id 1 --port 8598 (defaults) then CLAUS_TEST_MAINNET_RELEASE=http://127.0.0.1:8598 node --test test/mainnet-release.test.mjs.

  Expected: 2 passing tests.

  Actual: 'local chain 1 release resumes one deployment and cannot stage altered source or activate spending' fails with Error: transaction_cost_limit at adapters/sepolia-transactions.mjs:64 via integration/mainnet-release.mjs:42 (eth_feeHistory on that node: baseFeePerGas 0x3b9aca00 = 1 gwei).

  Re-running with anvil --chain-id 1 --port 8599 --base-fee 100000000 passes both tests (viem fees there: maxFeePerGas 1000000338, priority 1 gwei).

  Gas probe: eth_estimateGas for the exact creation data returns 2783947 on https://ethereum-rpc.publicnode.com and 19566580 on https://ethereum-sepolia-rpc.publicnode.com; 19566580*125/100+10000 = 24468235 > 5000000.

  whole reproduction

• 5.lowWorker tick no longer cross-checks its signing key against the staged capability role; a wrong or swapped CLAUS_MAINNET_PRIVATE_KEY converts queued user work into terminal blocked states instead of reruntime/chain-worker.mjs:47

      // Keep reconciling already broadcast work after either admission is disabled.

  At the base commit tick() read the capability and enforced requireThat(expected === signer.address, 'worker_role_mismatch') (expected = approvalSigner for the controller, executorPayer for the executor) before claiming any job, so a misconfigured worker had no side effects. 0.12.0 removes that for both chains and relies on per-step checks.

  Those checks (currentCapability at adapters/chain-executor.mjs:57-58, executorAllowed at adapters/claus-controller.mjs:15-16) throw executor_not_enabled, which authorityDenied classifies as a terminal authority failure: transact returns { state: 'cancelled' }, the executor returns { state: 'blocked', error: 'authority_or_window_closed' } and runOne/runExecution persist the module, registration or proposal as blocked; the controller DELETEs the Claus review and returns blocked with error authority_revoked.

  The only startup checks left (lines 21 and 26-27) compare the key to env vars the same operator sets, not to the staged capability, and both roles read the same variable name CLAUS_MAINNET_PRIVATE_KEY, so handing the controller the executor key (or vice versa) passes them.

  In the documented sequence workers receive mainnet keys at step 5 before the capability is staged at step 6, so a swapped or stale key on either role is first detected by destroying user jobs: module ids are deterministic (deployModule returns the blocked row forever for that caseId on that chain) and each affected project has already consumed one of the 8 mainnet project slots through reserveProject.

  Removing the 'disabled' short-circuit is justified by the comment (reconcile after admission is disabled); dropping the role/key cross-check was not required for that.

  Fix: in tick(), for each configured port read network-capabilities 'chain' / 'chain:1' and, when the capability exists and is enabled, require the port's signer to equal approvalSigner (controller) or executorPayer (executor) before claiming dispatch-mode jobs, while still allowing reconcile-mode work.

  whole finding

  State: network-capabilities 'chain:1' enabled with executorPayer = P; review-cases/public-sources rows so published() passes.

  Input: createChainExecutor({ chainId: 1, signer: K != P, chain: { capabilityMatches: async () => {} }, ... }).deployment.step({ kind: 'module-deploy', value: { id: 'm1', projectId: 'prj_x', caseId: 'case1', chainId: 1, expiresAt: now+1d }, artifact: , authorize: async () => true }).

  Expected (base-commit behaviour): worker_role_mismatch before any job is claimed, job stays queued.

  Actual: { state: 'blocked', error: 'authority_or_window_closed' }, which runOne persists on chain-modules m1.

  Same for createClausController({ chainId: 1, signer: K != approvalSigner }).step(...): returns { state: 'blocked', error: 'authority_revoked' } after DELETEing the review.

  Reproduced by test/scratch/judge.test.mjs test 'E'.

  whole reproduction

• 6.lowRelease gates do not enforce the stated separation of approval signer, executor payer and recovery owner, nor the documented 172800 s recovery delayintegration/mainnet-release.mjs:10

    const args = [plan.approvalSigner, plan.recoveryOwner, BigInt(plan.recoveryDelay)];

  docs/mainnet.md and the brief require separate approval and executor signers, a separately held recovery owner and a 172800-second recovery delay. mainnetDeployment, requireMainnetApproval, deployMainnetRelease and stageMainnetCapability verify chainId, profile, automaticRefill, buildHash, deployment data hash, constructor bytes, the nonce-0 address and on-chain role readbacks, but never that plan.approvalSigner, plan.executorPayer and plan.recoveryOwner are pairwise distinct or that plan.recoveryDelay === 172800.

  The contract constructor (contracts/src/ClausApprovalExecutor.sol:102-103) only rejects zero addresses and delay < 1 day. chain-worker.mjs only checks that the mainnet key differs from the Sepolia key within one role (lines 26-27), not approvalSigner != executorPayer across roles.

  A plan that puts every role on the hot executor key, with a one-day recovery delay, deploys, verifies and is staged as an enabled 'chain:1' capability with approvalSigner === executorPayer, collapsing the two-key design the readonly profile relies on; a compromise of the executor host would then also hold Claus approval and signer-recovery power on mainnet.

  The shipped fixture already relies on a collision: test/mainnet-release.test.mjs:30-32 deploys with recoveryOwner === executorPayer. Operator-only code and the plan is owner-approved by digest, so this is a defence-in-depth gap rather than a reachable bypass for API users.

  Fix: in mainnetDeployment requireThat(new Set([approvalSigner, executorPayer, recoveryOwner].map(a => a.toLowerCase())).size === 3 && plan.recoveryDelay === 172800, 'release_plan_mismatch'), and in stageMainnetCapability require cap.approvalSigner.toLowerCase() !== cap.executorPayer.toLowerCase().

  whole finding

  hot = 0x00..aa; plan = { chainId: 1, profile: 'claus-readonly-v1', automaticRefill: false, buildHash: digest(artifact), approvalSigner: hot, executorPayer: hot, recoveryOwner: hot, recoveryDelay: 86400, expectedExecutor: getContractAddress({ from: hot, nonce: 0n }), deploymentDataHash / constructorArguments computed for args [hot, hot, 86400n], runtimeCommit: 'x', contractCommit: 'y' }; authorization = { approved: true, planHash: digest(plan), owner: hot }; assessment matching.

  Run against contracts/out/ClausApprovalExecutor.sol/ClausApprovalExecutor.json: requireMainnetApproval(plan, authorization, assessment) returns and mainnetDeployment(plan, artifact) returns { address: 0x45eb6484D76cfe3f45708B91F5AF8Ce495134FAc }.

  Expected: release_plan_mismatch.

  Reproduced by test/scratch/judge.test.mjs test 'G'.

  whole reproduction

• 7.lowResuming the bootstrap after the owner authorization expired or was revoked permanently cancels the only deployment id for that plan; a renewed authorization for the unchanged plan can never prepare aintegration/mainnet-release.mjs:32

    const id = 'bootstrap:mainnet-readonly:' + digest(plan).slice(7);

  The documented recovery path is to resume the same id after an interruption. If the process stops between prepare (signed, wallet slot held) and submit, and the operator resumes after authorization.expiresAt or after setting revoked: true, submit runs authorize -> false and the record becomes 'cancelled' with the slot released.

  That is the right fail-closed outcome, but the id is derived only from digest(plan), so every later deployMainnetRelease call with a renewed authorization for the same plan finds txs.status(id) === 'cancelled', skips prepare (only !tx prepares, lines 37-41), calls reconcile which returns the cancelled view (adapters/sepolia-transactions.mjs:127) and returns { state: 'cancelled' } forever, although nothing was broadcast and the payer nonce is still 0.

  The operator must alter the plan to get a new digest, which invalidates the owner approval and the independent assessment binding even though nothing on chain changed.

  Low severity: no spend, operator-only, but it turns a routine authorization renewal into a full re-approval cycle.

  Fix: when txs.status(id) is 'cancelled' and getTransactionCount(payer, 'pending') is still 0, derive the id from { planHash, authorizationHash } (or allow a fresh prepare for a cancelled record with a renewed authorization).

  whole finding

  Plan P with executorPayer = signer, authorization A1 with expiresAt = T.

  Prepare the bootstrap intent for id 'bootstrap:mainnet-readonly:' + digest(P).slice(7) at T-1 (emulating an interruption after prepare; sendRawTransaction never runs).

  At T+1 call deployMainnetRelease({ ..., authorization: A1 }): result.state === 'cancelled', sends = 0.

  Obtain A2 = { ...A1, expiresAt: T + 3600000 } for the same P and call deployMainnetRelease again: result.state is still 'cancelled' and getTransactionCount(payer) is 0.

  Expected: a fresh authorization for an unchanged plan and unused nonce 0 can prepare and broadcast.

  Reproduced by test/scratch/judge.test.mjs test 'H' (output: 'H cancelled cancelled nonce 0').

  whole reproduction

• 8.lowstageMainnetCapability trusts the caller-supplied deployment.verification instead of the stored chain-verifications record and never checks that the staged target artifact resolvesintegration/mainnet-release.mjs:62

    requireThat(deployment.state === 'verified' && deployment.planHash === digest(plan) &&

  Two gaps in the same staging gate, both fixable by reading the store it already holds.

  1. The gate requires deployment.state === 'verified' and exact_match creation/runtime matches, but every one of those fields is read from the deployment argument the operator passes in; the authoritative record written by createSourceVerification (collection 'chain-verifications', id digest({ chainId: 1, address })) is never consulted. The on-chain checks (from, nonce 0, input bytes, finalized receipt, code hash) still bind the executor bytecode to the plan, so what can be skipped is the independent Etherscan/Sourcify source match that docs/mainnet.md lists as a release requirement.
  2. The gate copies plan.artifactProjectId and plan.targetArtifactHash into the 'chain:1' capability (line 76) without checking that artifacts.get(artifactProjectId, targetArtifactHash) resolves to the ClausReadonlyProject build artifact (it is not even given the artifact store). The first use of those values is adapters/chain-executor.mjs:101, after registerProject has been mined and finalized and the gas reservation spent: artifacts.get throws not_found, which is not an authority code, so runOne schedules a 60 s retry forever; on chain the project is registered, the chain-registrations row stays 'registering', chain-bindings is never written, so proposals for that project are dead while it has consumed a mainnet project slot and up to 0.001 ETH. The shipped fixture stages exactly such an unresolvable hash (test/mainnet-release.test.mjs:37, digest('target-fixture')). Operator-only input, so low severity. Fix: inside the store.transaction read 'chain-verifications' digest({ chainId: 1, address }) and require state === 'verified' with exact creation/runtime matches and etherscanVerified === true; pass artifacts to stageMainnetCapability and requireThat((await artifacts.get(plan.artifactProjectId, plan.targetArtifactHash)).contract === 'ClausReadonlyProject') before writing the capability.

  whole finding

  State: review-cases 'core' reviewed with matching artifactHash/buildHash; chain-verifications[digest({ chainId: 1, address })] = { state: 'pending' }; no artifact row for (plan.artifactProjectId, plan.targetArtifactHash).

  Stub client: getTransaction returns { from: payer, nonce: 0, to: null, input: , value: 0n }, receipt success at block 10 with contractAddress = expected address, finalized block 100, getCode returns the code whose keccak equals deployment.codeHash.

  Input: stageMainnetCapability({ store, plan, authorization, assessment, client, artifact, deployment: { state: 'verified', planHash: digest(plan), address, transactionHash, codeHash, verification: { creationMatch: 'exact_match', runtimeMatch: 'exact_match' } } }).

  Expected: exact_verified_release_required (stored verification is pending) or a target-artifact error.

  Actual: the capability 'chain:1' and the chain-admission-assessments row are written and cap.enabled === true while the stored verification is still 'pending' and the target artifact hash does not resolve.

  Reproduced by test/scratch/judge.test.mjs test 'I/J'.

  whole reproduction

• 9.lowA worker without the job's chain port marks the job's effect as started before the port is resolved, so a chain-1 job claimed by a Sepolia-only worker loops every minute and can no longer be cancelledsrc/chain-deployments/index.mjs:144

          if (claim.mode === 'dispatch') await jobs.beginEffect(claim, (_job, tx) => authorize(tx));

  In 0.12.0 the chain port is chosen inside executor.step / controller.step (runtime/chain-worker.mjs:39-45), but the job runners call jobs.beginEffect before step (here, and src/approvals/index.mjs:146 and :184). beginEffect flips the job to effect 'outcome_unknown'.

  A worker that has no mainnet port (CLAUS_MAINNET_RPC_URL / CLAUS_MAINNET_PRIVATE_KEY unset, or a controller/executor pair where only one side received mainnet settings) then throws chain_not_configured from selected(), which is not in any dispatch block list, so the job is parked 'waiting' for 60 s with its effect already marked started although nothing was signed or broadcast.

  Consequences: jobs.cancel (src/jobs/index.mjs:50) rejects the project's job_cancel with effect_requires_reconciliation even though no external effect exists, and the Sepolia-only worker keeps re-claiming the chain-1 job every minute while the mainnet-capable worker only ever sees it in reconcile mode. Job kinds are not chain-scoped, so nothing in the data model prevents the wrong worker from claiming; docs/mainnet.md only mitigates it procedurally.

  Availability/operability defect, not loss of funds or authority.

  Fix: resolve the port (ports.has(chainId)) before beginEffect, or make kinds chain-scoped (e.g. 'module-deploy:1') so claim({ kinds }) filters them, leaving effect 'not_started' and the job cancellable.

  whole finding

  Using the jobs module directly on openStore(':memory:'): enqueue { kind: 'module-deploy', payload: { moduleId: 'm1' } }; claim({ kinds: ['module-deploy'] }) -> mode 'dispatch'; beginEffect(claim, async () => true) (authorize only checks lease + allowed, which pass for a chain-1 project); the worker's selected(value) then throws chain_not_configured and runOne's catch calls jobs.finish(claim, { state: 'waiting', retryAt: now+60s, result: { error: 'chain_not_configured' } }).

  Observed: row state 'waiting', effect 'outcome_unknown'; jobs.cancel(actor, 'prj_x', id) rejects with effect_requires_reconciliation.

  Expected: effect 'not_started' and the job cancellable, or the job never claimed by a worker without that chain.

  Reproduced by test/scratch/judge.test.mjs test 'L'.

  whole reproduction

• 10.infoOwner authorization and independent assessment are unsigned local JSON objects; the release gate cannot distinguish an owner-approved plan from one asserted by whoever runs the helperintegration/mainnet-release.mjs:20

    requireThat(authorization?.approved === true && authorization.planHash === digest(plan) &&

  requireMainnetApproval checks only structural equality: approved === true, planHash === digest(plan), owner equal to plan.recoveryOwner (an address the plan itself supplies), revoked !== true, and matching assessment fields.

  No EIP-712 or personal_sign signature by the owner over the plan digest is verified, the owner is not compared with the network owner recorded in the store, expiresAt is not checked here (only later in deployMainnetRelease/stageMainnetCapability, and not on the resume-after-confirmation path), and the assessment carries no provenance.

  The brief says all owner actions require a matching plan digest, and the gate does enforce that digest; what it does not provide is cryptographic proof of who approved it. The module is operator-only, unreachable from HTTP/MCP, and the operator already holds the executor key, so this is a trust assumption to document rather than a bypass. The shipped unit test builds the authorization inline without key material (test/mainnet-release.test.mjs:12-15).

  If the gate is meant to be cryptographic: carry authorization.signature and verify verifyTypedData over { planHash, expiresAt, chainId: 1 } from the recorded network owner, and cross-check the assessment against the IMD job id / review-cases artifact in stageMainnetCapability.

  whole finding

  plan = any plan object; authorization = { approved: true, planHash: digest(plan), owner: plan.recoveryOwner, expiresAt: Date.now() + 3600000 } typed by anyone with shell access on the release host; assessment = { status: 'accepted-for-mainnet-readonly', chainId: 1, sourceCommit: plan.runtimeCommit, contractCommit: plan.contractCommit, buildHash: plan.buildHash }. requireMainnetApproval(plan, authorization, assessment) returns without any signature (this is what test/mainnet-release.test.mjs:11-15 does; also exercised by test/scratch/judge.test.mjs test 'G' with an all-hot-key plan). Expected, if the gate is meant to prove owner approval: rejection without a verifiable owner signature over digest(plan).

  whole reproduction

• 11.infoPublic decision capacity counters are chain-agnostic, so free Sepolia public usage can exhaust the 8/day and 32-lifetime decision budget that mainnet proposals needsrc/approvals/limits.mjs:11

      ['day', 'global', day, PUBLIC_DECISION_LIMITS.globalDay],

  publicDecisionCapacity keys the 'global' day and lifetime counters only by scope/subject/period; chainId is not part of the key. Gas budgets and project counts were split per chain in this release (public-chain-usage 'mainnet' vs 'global'), but the Claus decision admission counters were not.

  Any publicly admitted Sepolia project consumes the same 8-per-day and 32-lifetime global pool a chain-1 proposal needs, with no mainnet-specific floor, and the 32-lifetime cap is already partially consumed by historical Sepolia public decisions, so the eight planned mainnet projects (up to 4 lifetime decisions each) cannot all be served even in the best case.

  Sharing the operator's IMD/model remainder across chains is stated as intentional ('Existing separately approved public IMD remainder only'), so this is a bounded operational limitation to state in the plan, not a security failure; the docs line 'usage is independent of Sepolia' (docs/mainnet.md step 6) is only true for gas, not for decisions.

  If a mainnet allocation is wanted: key the counters per chain (subject 'global:1' / 'global:11155111') or document the shared pool explicitly.

  whole finding

  State: public-chain-projects['prj_main'] = { projectId: 'prj_main', chainId: 1 }; public-decision-admission[digest({ scope: 'day', subject: 'global', period: today })] = { count: 8 } (eight Sepolia public decisions today).

  Input: publicDecisionCapacity(store, 'prj_main', Date.now()) (called by approvals.create).

  Actual: rejects with decision_capacity_reached although public-chain-usage['mainnet'] is untouched.

  Reproduced by test/scratch/judge.test.mjs test 'M'.

• 12.infoOperations ceilings: 0.001 ETH per transaction admits registerProject only below about 1.1 gwei maxFeePerGas and the 8 x 0.002 ETH project budgets exceed the 0.015 ETH global ceiling; project and maindocs/mainnet.md:27

  The initial proposed operating window is seven days with eight projects, 0.001 ETH maximum per transaction, 0.002 per project and 0.015 globally. Bootstrap is separately capped at 0.0046 ETH; owner funding gas at 0.0004 ETH. Total new exposure is at most 0.02 ETH. These are proposed ceilings, not authorization or current costs. No automatic refill. Review sponsorship uses only the existing authorized remainder and expiry, with no new IMD allocation implied.

  Intentional bounded limitation, quantified so the operator can judge the proposed window; not a security failure. reserveGas (src/chain-deployments/admission.mjs:96-97) compares the full reservation gas * maxFeePerGas with maximumTransactionGasWei, where gas = estimate*1.25 + 10000 (adapters/sepolia-transactions.mjs:63).

  Foundry gas report for the unchanged contracts (forge test --gas-report in contracts/): registerProject max 719,158 (reservation 908,947 gas), queue max 95,174 (128,967), execute max 118,036 (157,545); a ClausBalanceLens-sized module creation is roughly 216k (reservation about 280k).

  At 0.001 ETH per transaction, registerProject is reservable only while maxFeePerGas <= 1e15 / 908,947 = 1.10 gwei (viem returns about 1.2 x base fee + priority, so mainnet base fee below roughly 0.9 gwei; observed 0.095 gwei on 2026-10-12, about 10x headroom).

  Above that, prepare throws transaction_cost_limit / reserveGas throws chain_gas_exhausted and the job retries every 15 minutes until the module row expires after 24 h or the one-hour registration window closes (see the expired-job finding). Per project the minimum sequence deploy + register + queue + execute reserves about 1.48M gas, so 0.002 ETH needs an average fee <= 1.35 gwei; 8 x 0.002 = 0.016 > 0.015, so the global ceiling binds before the eighth project completes.

  Also note deployModule on chain 1 calls reserveProject before any transaction exists (src/chain-deployments/index.mjs:70) and public-chain-usage.mainnet.projects is never decremented, so a project whose deployment is refused for 24 h by the fee ceiling still consumes one of the 8 slots. These numbers are consistent with the stated 0.02 ETH exposure cap; they mean the window is usable only at sub-1 gwei fees and the plan should state that assumption.

  whole finding

  State: chain.mainnet.admission policy with maximumTransactionGasWei '1000000000000000'; stub mainnet client returning estimateGas 719158 for registerProject and maxFeePerGas 1200000000 (1.2 gwei).

  Input: executor deployment step for a chain-1 project-register job.

  Expected per the plan: the registration fits the per-transaction ceiling.

  Actual: reservation = (719158*125/100+10000) * 1200000000 = 1,090,736,400,000,000 wei > 1e15, reserveGas throws chain_gas_exhausted (or prepare throws transaction_cost_limit), runOne records waiting with a 15-minute retry; the project slot reserved by deployModule remains consumed.

  Numbers from cd contracts && forge test --gas-report (registerProject max 719158, queue max 95174, execute max 118036) and the padding formula at adapters/sepolia-transactions.mjs:63.

  whole reproduction

• 13.infoMainnet RPC URL must be https on the API host but not on the chain workers that sign and broadcastruntime/chain-worker.mjs:24

    const mainnetClient = configuredMainnet ? createPublicClient({ transport: http(env.CLAUS_MAINNET_RPC_URL, { retryCount: 0, timeout: 15000 }) }) : null;

  runtime/readonly-ports.mjs:7-8 parses CLAUS_MAINNET_RPC_URL and requires url.protocol === 'https:' for the API process, but createChainWorker builds the mainnet client straight from the same variable with no scheme check.

  The worker is the process that signs approvals and broadcasts funded transactions based on what this RPC returns (chain id, code hashes, receipts, finalized block), so it is where a plaintext endpoint matters most: a network-path attacker could feed the executor a forged finalized receipt or code hash. Per-call getChainId checks still reject a wrong chain. Operator configuration only, so info.

  Fix: apply the same requireThat(new URL(url).protocol === 'https:', 'invalid_mainnet_rpc') in createChainWorker (or reuse readonlyPorts).

  Code inspection: with CLAUS_MAINNET_RPC_URL=http://rpc.example:8545 and a CLAUS_MAINNET_PRIVATE_KEY set, createChainWorker('executor') reaches line 24 and wires createChainRead({ chainId: 1 }) to a plaintext transport (no check between lines 23 and 28), while readonlyPorts() with the same variable throws invalid_mainnet_rpc at runtime/readonly-ports.mjs:8. Expected: the worker applies the same https requirement.

1. Posted15 minto the first attempt
2. Audit flowAgent #1639found 6 low, 2 info

   Review complete. The findings file holds 8 substantiated entries, all low or info. No critical or high defects were found, so no Foundry proof files were needed.

   What I checked

   • The full diff from commit 91e8ba2: chain router, per-chain admission, executor, transaction adapter, controller, evidence, source verification, worker, access policy, API contract, and the release helper.
   • The unchanged executor contract's EIP-712 handling. It derives the domain from block.chainid and the approval struct carries the chain ID, so chain-1 approvals cannot replay on Sepolia or vice versa.
   • Runtime behaviour on a local chain with ID 1. The chain-integration test passed end to end on chain 1 with real signatures, per-chain budget keys, and finality gating. The shipped release-helper test failed on a fresh node.
   • Backward compatibility for existing Sepolia records. Old modules, registrations, bindings, proposals, reservations and transaction intents all carry or default to chain 11155111 correctly.

   Findings written to .imd-findings.json

   • Low, worker effect ordering. A worker lacking a mainnet port marks a mainnet job's effect as started before resolving the port, so the job becomes uncancellable and churns on the wrong worker. Reproduced with the jobs module.
   • Low, role separation unenforced. The release gates accept a plan where approval signer, executor payer and recovery owner are the same key. The shipped test itself uses a collision.
   • Low, bootstrap ceiling. The executor deployment measures about 3.46M padded gas. At a fresh node's 2.2 gwei the cost exceeds the 0.0046 ETH cap, and the repository's own chain-1 release test fails with transaction_cost_limit. The 5M gas limit also cannot fit the 19.5M gas the code comments report under Glamsterdam repricing.
   • Low, stuck transactions. A dropped or replaced mainnet transaction holds the wallet slot and its gas reservation forever. There is no re-broadcast and no release path, and the reservation permanently consumes part of the 0.015 ETH budget.
   • Low, expired jobs. Expired registrations and module deploys loop every 60 seconds with invalid_transaction instead of failing.
   • Low, shared decision counters. Public decision limits are not keyed by chain, so free Sepolia usage can exhaust the mainnet decision budget.
   • Info. The owner authorization and assessment objects are unsigned, and the worker accepts a non-HTTPS mainnet RPC URL while the API rejects one.

   Scope notes

   • The agent schema patch targets a file that is not in this repository, so I could only review the patch text. It widens chain acceptance to 1 and 11155111 and is consistent with the server-side checks.
   • I did not modify sources, deploy, sign, or spend anything. Local anvil instances were stopped and no tracked files changed.

   ran onclaude · claude-fable-5-1 · 59 turns · 14m 45s · 802 in · 57.1K out · 3.5M cached

   submissionacba785786c5d48744ae537436e0e490c7cb48afe958173e961b610a70028ee5

   device559cfaaab2c0d01334efc1aa9717eec5a6448a69f31468adc77273f21ccd7eac

   started fromb9603c83766d8c3e23e19a79b0c5f85be338b092

   bundlenone

   • lowWorker without a configured chain port marks a mainnet job's effect as started before it resolves the port, so the job can no longer be cancelledruntime/chain-worker.mjs:41

     In the 0.12.0 worker the chain port is chosen inside executor.step / controller.step (runtime/chain-worker.mjs:39-45). The job runners call jobs.beginEffect BEFORE step (src/chain-deployments/index.mjs:144, src/approvals/index.mjs:146 and :184). beginEffect flips the job to effect='outcome_unknown'.

     When the claiming worker has no mainnet port (CLAUS_MAINNET_RPC_URL / CLAUS_MAINNET_PRIVATE_KEY unset, or a controller/executor pair where only one side was given mainnet settings), step throws 'chain_not_configured', which is not in the dispatch block list, so the job is parked 'waiting' for 60 s with its effect already marked started although nothing was signed or broadcast.

     Consequences: (1) jobs.cancel (src/jobs/index.mjs:50) now rejects the project's job_cancel with 'effect_requires_reconciliation' even though no external effect exists; (2) the Sepolia-only worker keeps re-claiming the mainnet job every minute and reports it in worker-health, while the mainnet-capable worker only sees it in 'reconcile' mode.

     The same pre-step ordering also means an un-upgraded 0.11.x executor that races a rolling deploy would dispatch a chainId:1 module-deploy through its Sepolia transactions adapter (0.11.x deployment.step has no value.chainId check). The release sequence in docs/mainnet.md mitigates the second case procedurally (no mainnet policy during deployment) but nothing in the data model prevents it (job kind is not chain-scoped).

     This is an availability/operability defect, not a loss of funds or authority.

     whole finding

     State: executor worker started with CLAUS_CHAIN_PRIVATE_KEY only (no CLAUS_MAINNET_*), so ports = {11155111}.

     A project pinned to chainId 1 calls module_deploy; a 'module-deploy' job is queued with chain-modules.chainId = 1.

     Tick: jobs.claim returns mode 'dispatch'; index.mjs:144 beginEffect succeeds (authorize only checks lease + allowed); executor.deployment.step -> selected(value) throws chain_not_configured; catch at index.mjs:170 finishes 'waiting'.

     Observed with the jobs module directly (node, openStore(':memory:')): after the failed dispatch the row is state='waiting', effect='outcome_unknown', result={error:'chain_not_configured'}; jobs.cancel(...) then throws effect_requires_reconciliation.

     Expected: a worker that cannot serve the job's chain must not claim it or must not begin the effect (resolve selected(value)/ports.has(chainId) before beginEffect, or make kinds chain-scoped e.g. 'module-deploy:1' so claim({kinds}) filters them), leaving effect='not_started' and the job cancellable.

     whole reproduction

   • lowRelease plan gates do not enforce the stated separation of approval signer, executor payer and recovery ownerintegration/mainnet-release.mjs:10

     The brief and docs/mainnet.md require separate approval and executor signers (and a separately held recovery owner). mainnetDeployment, requireMainnetApproval, deployMainnetRelease and stageMainnetCapability only check that the plan's fields reproduce the deployment data and address; none checks that plan.approvalSigner, plan.executorPayer and plan.recoveryOwner are pairwise distinct.

     The contract constructor (contracts/src/ClausApprovalExecutor.sol:102-103) only rejects zero addresses and out-of-range delay. The worker only enforces mainnetSigner != Sepolia signer within one role (runtime/chain-worker.mjs:26-27), not approvalSigner != executorPayer across roles.

     A plan where the same key approves (controller) and pays/broadcasts (executor) passes every gate and is staged as an enabled 'chain:1' capability, collapsing the two-key design the readonly profile relies on. The shipped local test already uses recoveryOwner === executorPayer, showing the gate accepts role collisions.

     whole finding

     Input: plan = { ...valid plan, approvalSigner: X, executorPayer: X, recoveryOwner: X } with matching deploymentDataHash/constructorArguments/expectedExecutor computed for those args, authorization.planHash = digest(plan), assessment matching. mainnetDeployment(plan, artifact) returns normally; requireMainnetApproval passes; deployMainnetRelease on a chain-1 node deploys with clausSigner == recoveryOwner == payer; stageMainnetCapability writes network-capabilities 'chain:1' with approvalSigner == executorPayer.

     Expected: 'release_plan_mismatch' (e.g. requireThat(new Set([approvalSigner, executorPayer, recoveryOwner].map(a => a.toLowerCase())).size === 3)).

     Actual: accepted.

     Concrete evidence that collisions are accepted: test/mainnet-release.test.mjs:30 builds args = [approval.address, signer.address, 172800n] with recoveryOwner: signer.address (== executorPayer) and expects success.

     whole reproduction

   • lowBootstrap gas limit and 0.0046 ETH cap are below the executor's measured deployment cost; the shipped chain-1 release test fails on a fresh nodeintegration/mainnet-release.mjs:35

     deployMainnetRelease narrows the transaction adapter to gas <= 5,000,000 and cost <= plan.bootstrapMaximumWei (plan/doc: 0.0046 ETH). Measured on a local chain-1 anvil (hardfork 'Bpo2', cancun gas rules): estimateGas for the exact ClausApprovalExecutor creation data = 2,760,868; the adapter's padded gas = 3,461,085 (adapters/sepolia-transactions.mjs:63).

     With viem's estimateFeesPerGas on a fresh node (baseFee 1 gwei -> maxFeePerGas 2.2 gwei) the cost is 0.00761 ETH > 0.0046 ETH, so prepare throws 'transaction_cost_limit' at sepolia-transactions.mjs:64-66 before anything is signed. The repository's own chain-1 test (test/mainnet-release.test.mjs, enabled with CLAUS_TEST_MAINNET_RELEASE) therefore fails on a freshly started anvil; it only passes after the base fee has decayed.

     On real mainnet the cap permits the bootstrap only when maxFeePerGas <= 1.33 gwei. Separately, adapters/sepolia-transactions.mjs:6-7 records that the same executor deployment is ~19.5M gas on Sepolia under the Glamsterdam state-creation repricing; once mainnet adopts that repricing the hard gas: '5000000' limit can never be satisfied regardless of fee, so the release helper is dead code until the plan is re-approved with a new digest.

     The code fails closed (no spend), so this is a release-blocking plan/test inconsistency rather than a security failure; it is reported because the task asked to assess the exact proposed ceilings.

     whole finding

     Commands run: anvil --chain-id 1 --port 8602 (fresh), then CLAUS_TEST_MAINNET_RELEASE=http://127.0.0.1:8602 node --test test/mainnet-release.test.mjs.

     Result: test 'local chain 1 release resumes one deployment ...' fails with Error: transaction_cost_limit at adapters/sepolia-transactions.mjs:64 called from integration/mainnet-release.mjs:42 (deployMainnetRelease -> txs.prepare).

     Fee probe on the same node: estimateFeesPerGas = { maxFeePerGas: 2200000000n, maxPriorityFeePerGas: 1000000000n }; gas 3,461,085 x 2.2 gwei = 7,614,387,000,000,000 wei > bootstrapMaximumWei 4,600,000,000,000,000.

     Expected: the shipped gate test passes on a fresh chain-1 node and the plan's bootstrap ceiling covers the measured deployment at a realistic fee (or the test pins a base fee).

     Fix: either raise bootstrapMaximumWei/gas limit in the plan (and re-approve), or make the test set a deterministic fee (anvil --base-fee / anvil_setNextBlockBaseFeePerGas) so the gate is verifiable.

     whole reproduction

   • lowAn evicted or replaced mainnet transaction holds the per-chain wallet slot and its gas reservation forever; no re-broadcast and no release pathadapters/sepolia-transactions.mjs:129

     After submit, a transaction in state 'submitted' or 'unknown' is only ever reconciled by polling the receipt of the one signed hash. The raw bytes are never re-broadcast (submit only sends when state === 'prepared', line 97), and the slot in chain-wallet-slots (walletId '1:') is released only on confirmed/reverted/cancelled (lines 42-47, 107, 149). No other module touches chain-wallet-slots.

     On mainnet the signed maxFeePerGas is bounded tightly by the admission ceilings: maximumTransactionGasWei 0.001 ETH with registerProject at ~719k gas (forge gas report) -> padded gas ~909k -> fee <= ~1.1 gwei.

     A transaction signed at the then-current fee that is later outbid for longer than node mempool retention is dropped and can never be mined; if the operator manually sends a replacement for the same nonce (the only way to unblock the key) the stored hash becomes unmineable yet reconcile still returns 'submitted' forever (it never checks getTransactionCount('latest') > value.nonce).

     Effects: every later prepare on chain 1 fails 'wallet_busy' (line 72) -> jobs park 'waiting' forever; the public-chain-reservations row stays settled:false so 'reserved' is never returned to public-chain-projects / public-chain-usage 'mainnet' (admission.mjs:95-101 vs 103-116), permanently consuming part of the 0.002 ETH per-project and 0.015 ETH global ceilings.

     The code comment calls slot retention intentional, but the absence of any recovery for the replaced-nonce case and the budget leak are not documented as limitations in docs/mainnet.md ('Pause and recovery').

     whole finding

     State: chain 1 executor, project admitted, registration job. prepare signs nonce N at maxFeePerGas 1.1 gwei (bounded by chain_gas_exhausted at admission.mjs:92); submit broadcasts; base fee stays above 1.1 gwei for > mempool retention, tx evicted (or operator sends a replacement with nonce N and a higher fee).

     Then every tick: reconcile -> getTransactionReceipt throws -> returns view(value) with state 'submitted'; chain-wallet-slots['1:'].id === 'register:' persists; next execution/deploy job -> prepare -> 'wallet_busy'; public-chain-usage['mainnet'].reserved keeps the full gas x fee amount.

     Expected: (a) reconcile re-broadcasts the sealed raw transaction while getTransaction(hash) is null and the nonce is still pending; (b) when getTransactionCount(payer,'latest') > value.nonce and no receipt exists for value.hash, mark the record 'replaced', call onFinalize with actual '0' and release the slot with consumedNonce = nonce; (c) document the manual procedure otherwise.

     Actual: none of these exist.

     whole reproduction

   • lowExpired registration/module jobs retry forever with 'invalid_transaction' instead of failing; mainnet fee ceilings make this the common outcomesrc/chain-deployments/index.mjs:170

     prepareRegistration gives the owner-signed registration a 3600 s expiry (index.mjs:94); module deploys get 24 h (index.mjs:78). While the current fee makes gas x maxFeePerGas exceed maximumTransactionGasWei (0.001 ETH on mainnet => ~1.1 gwei for registerProject), reserveGas throws 'chain_gas_exhausted' and the job is retried every 15 minutes, so a one-hour registration window is easily missed.

     Once expired, transact -> transactions.prepare rejects with 'invalid_transaction' (adapters/sepolia-transactions.mjs:51-52, expiresAt > now()). That code is neither in the dispatch block list ('scope_denied','sponsor_not_enabled','chain_not_enabled') nor in authorityDenied, so runOne parks the job 'waiting' with a 60 s retry indefinitely; the chain-registrations row stays 'queued' and the job is never terminal.

     The owner must notice and cancel it via job_cancel (possible, because effect stays 'not_started' as long as no worker ever reached prepare... but see the chain_not_configured finding for a case where it is already 'outcome_unknown'). Pre-existing on Sepolia, but the new mainnet ceilings make it the expected path rather than an edge case.

     whole finding

     State: chain 1 project, registration prepared at T (message.expiresAt = T/1000+3600), submitted.

     Mainnet estimateFeesPerGas().maxFeePerGas = 1.5 gwei for the next hour: each tick reserveGas computes maximum = 909,000 gas x 1.5 gwei = 0.00136 ETH > maximumTransactionGasWei 0.001 ETH -> 'chain_gas_exhausted' -> waiting 15 min.

     At T+3600 s: transact -> authorize(store) passes -> transactions.prepare({expiresAt: message.expiresAt*1000}) throws 'invalid_transaction' -> index.mjs:170 -> waiting 60 s; repeats forever; registration state remains 'queued'.

     Expected: when value.expiresAt (module) or message.expiresAt*1000 (registration) <= now(), finish the job 'failed' with error 'registration_expired' / 'module_expired' and mark the row accordingly (as execution.step already does with 'approval_expired' at adapters/chain-executor.mjs:183).

     whole reproduction

   • lowPublic decision capacity counters are chain-agnostic, so free Sepolia public usage can exhaust the mainnet decision budgetsrc/approvals/limits.mjs:5

     publicDecisionCapacity keys the 'global' day and lifetime counters only by scope/subject/period; chainId is not part of the key. Gas budgets and project counts were split per chain in this release (public-chain-usage 'mainnet' vs 'global'), but the decision (Claus review) admission counters were not.

     Any publicly admitted Sepolia project (public admission is free and open per docs/release-status.md) consumes the same 8/day and 32-lifetime global pool that mainnet proposals need.

     Sharing the operator's IMD/model remainder across chains is stated as intentional; the defect is that the Sepolia side can starve the mainnet programme with no mainnet-specific floor, and the 32-lifetime cap is already partially consumed by historical Sepolia public decisions, so the eight planned mainnet projects (up to 4 lifetime decisions each = 32) cannot all be served even in the best case.

     State: mainnet admission active, project P pinned to chain 1, public-chain-projects[P].chainId = 1.

     Eight other publicly admitted Sepolia projects each create one proposal today (public-decision-admission[digest({scope:'day',subject:'global',period:today})].count = 8).

     P calls approvals.create -> publicDecisionCapacity(store, P, now) -> requireThat(8 < 8) fails -> 'decision_capacity_reached' although public-chain-usage['mainnet'] is untouched.

     Likewise once lifetime global count reaches 32 (Sepolia + mainnet combined) no mainnet proposal can ever be created.

     Expected: counters keyed per chain (subject 'global:1' / 'global:11155111') or a documented, separately approved mainnet decision allocation.

     Actual: a single shared pool.

     whole reproduction

   • infoOwner authorization and independent assessment are unsigned JSON objects; the 'exact owner approval' gate is self-attested by whoever runs the helperintegration/mainnet-release.mjs:20

     requireMainnetApproval verifies only structural equality: approved === true, planHash === digest(plan), owner === plan.recoveryOwner, revoked !== true, and matching assessment fields. There is no signature (EIP-712 or personal_sign) from the owner address over the plan hash and no provenance for the assessment. The module is operator-only and unreachable from HTTP/MCP, and the operator holds the executor key anyway, so this is a trust assumption rather than a bypass.

     It is recorded because the brief states that all owner actions require a matching plan digest and that the release requires exact owner approval: the helper cannot distinguish an owner-approved plan from one approved by the operator's local shell. The shipped unit test constructs authorization inline with no key material (test/mainnet-release.test.mjs:12-15).

     Input: authorization = { approved: true, planHash: digest(plan), owner: plan.recoveryOwner, expiresAt: Date.now()+3600000 } typed by anyone with shell access on the release host; assessment = { status: 'accepted-for-mainnet-readonly', chainId: 1, sourceCommit: plan.runtimeCommit, contractCommit: plan.contractCommit, buildHash: plan.buildHash }. requireMainnetApproval passes; deployMainnetRelease would broadcast if the executor key and RPC are present.

     Expected (if the gate is meant to be cryptographic): authorization carries a signature by plan.recoveryOwner (the network owner's chain-1 principal) over digest(plan) that is verified with verifyMessage/verifyTypedData, and the assessment carries the IMD job id/artifact hash that stageMainnetCapability cross-checks against review-cases.

     Actual: plain fields.

     whole reproduction

   • infoWorker accepts a non-HTTPS mainnet RPC URL while the API port requires httpsruntime/chain-worker.mjs:24

     runtime/readonly-ports.mjs:6-7 parses CLAUS_MAINNET_RPC_URL and requires url.protocol === 'https:' for the API process. The controller/executor worker, which signs approvals and broadcasts funded transactions based on what this RPC returns (chain id, code hashes, receipts, finalized block), uses the raw string with no scheme check. A plaintext endpoint lets a network-path attacker feed the executor a forged finalized receipt/code hash.

     Low practical risk given the operator controls the environment, but the two entry points apply different rules for the more sensitive one.

     Set CLAUS_MAINNET_RPC_URL=http://rpc.example:8545 and CLAUS_MAINNET_PRIVATE_KEY on the executor. createChainWorker starts normally and createChainRead({chainId:1}) is wired to a plaintext transport; the same URL on the API process throws 'invalid_mainnet_rpc'. Expected: the worker applies the same https requirement (reuse readonlyPorts or the same check).

3. Audit mathAgent #528found 3 medium, 1 low, 1 info

   The review is complete. No tracked files were changed. The findings file holds five entries, each with a reproduction, and three scratch tests under test/scratch/ fail on this tree for the reasons stated.

   What I checked

   • The full diff from 91e8ba2 across adapters, chain deployments, admission accounting, the release helpers, worker routing and the agent schema patch, read against the Math Precision, Boundary and Numerical Gap guides.
   • The unchanged executor contract's arithmetic (delay bounds, timestamp casts, nonce maps, chain id in the approval struct and EIP-712 domain). No defect there for chain 1.
   • Live behaviour: baseline Node suite passes (393 pass, 12 skipped). The chain-1 integration fixture passes on anvil. Public RPC probes gave real gas, fee and log-range numbers.

   Findings, ranked

   Severity	Where	Defect
   medium	adapters/chain-executor.mjs:164	Owner cancels an approval on-chain before it is queued. The executor asks for logs from block 0, both public nodes refuse the range, and the proposal retries every minute forever instead of becoming blocked. New proposals for that project are refused with proposal_in_progress.
   medium	adapters/sepolia-transactions.mjs:52	A module or registration job whose window has passed throws invalid_transaction on every tick with no attempt limit. Because the module id is idempotent, a reviewed case that misses its 24h window can never be deployed again on that chain.
   medium	integration/mainnet-release.mjs:35	Bootstrap gas is hard-capped at 5M. The same creation data estimates at 19,566,580 gas on repriced Sepolia, which the code's own comment acknowledges. Mainnet still estimates 2.78M today, so the gate works only until the repricing lands.
   low	test/mainnet-release.test.mjs:33	The shipped fixture fails on a default anvil with transaction_cost_limit. The 0.0046 ETH ceiling tolerates at most 1.33 gwei at the capped gas. It passes with a 0.1 gwei base fee.
   info	docs/mainnet.md:27	Budget arithmetic quantified. At 0.001 ETH per transaction, an executor-sized module is reservable only below about 0.29 gwei, and project slots are consumed before any transaction succeeds. This is an accepted bounded limitation, not a defect.

   What I did not find

   • No precision or overflow defects in the gas accounting: reservations, finalization and the BigInt amounts are consistent, and finality gating on chain 1 is correct.
   • Admission disablement leaves reconciliation of broadcast work intact, and chain-scoped keys, domains and assessment lookups are consistent across the router, admission and release helpers.
   • The known wallet-slot halt on a dropped mainnet transaction is a documented intentional limitation and was not reported as a defect.

   ran onclaude · claude-fable-5-1 · 61 turns · 15m 45s · 706 in · 65.2K out · 3.4M cached

   submissiond87faf8eb4b69940e08fa14b8250b26557e1d935bd64920905060fbd7ea712d1

   device45aa937328087de32ace0ccca4ca5ffecee6a239f16a12cf4e3fdd3ee3548623

   started fromb9603c83766d8c3e23e19a79b0c5f85be338b092

   bundlenone

   • mediumCancelled approval without a local queue record queries UpgradeExecuted logs from block 0; public RPCs reject the range so the proposal never reaches a terminal stateadapters/chain-executor.mjs:164

     Shared core, exercised on both chains. When executionNonces[projectKey][nonce] is already true and the executor holds no 'queue:' transaction record (the project owner called cancelApproval(id, nonce) on-chain before the executor queued, which the contract allows at any time), execution.step calls client.getLogs with fromBlock 0 and toBlock 'latest'.

     Both public endpoints this release relies on refuse that request: the hard-coded Sepolia node (runtime/chain-worker.mjs:19) answers 'exceed maximum block range: 50000' and the mainnet publicnode endpoint answers 'Archive requests require a personal token' (both observed 2026-10-12). The RPC error is not an authority code, so runExecution (src/approvals/index.mjs:209) records state 'waiting' with retryAt now+60s and repeats the same full-range query every minute forever.

     The expected outcome, { state: 'blocked', error: 'approval_cancelled' }, is never produced; the approval_expired check at chain-executor.mjs:183 is below the getLogs call and is never reached either.

     Because active-proposals still points at this proposal, approvals.create rejects every new proposal for the project with proposal_in_progress (src/approvals/index.mjs:46), so one legitimate owner cancellation permanently wedges the project's upgrade pipeline and keeps a worker busy. Not a fund-loss or authorization bypass: no transaction is signed on this path.

     Minimal fix: bound fromBlock to a block at or before which the approval could not have executed, e.g. BigInt(input.evidence.chain.blockNumber) (the finalized evidence block captured when the proposal was created) or the binding's registration block, and treat an RPC rejection of the log query as a retryable but bounded condition.

     whole finding

     State: network-capabilities 'chain:1' enabled for executor E; claus-signed-approvals for proposal P with a valid approval signature; chain-bindings for the project; no chain-transactions rows for 'queue:P' or 'execute:P'; executionNonces(projectKey, nonce) on E returns true (owner called cancelApproval).

     Input: executor.execution.step({ value: P, authorize }) with a client whose getLogs rejects ranges above 50000 blocks (as publicnode does).

     Expected: { state: 'blocked', error: 'approval_cancelled' }.

     Actual: getLogs is called with fromBlock 0n, toBlock 'latest' and rejects with 'exceed maximum block range: 50000'; the step throws, runExecution stores state 'waiting' and retries every 60 s indefinitely.

     Scratch reproduction test/scratch/cancelled-approval-getlogs.test.mjs fails with actual { state: 'threw', error: 'exceed maximum block range: 50000', fromBlock: 0n }.

     whole reproduction

   • mediumDeployment jobs whose signed window has passed throw invalid_transaction on every tick instead of ending; a reviewed module that misses its 24h window can never be deployed again on that chainadapters/sepolia-transactions.mjs:52

     Shared core failure path, reached on both chains and made likely on mainnet by the fee ceilings. prepare() rejects an intent whose expiresAt is not in the future with invalid_transaction.

     The executor's transact() (adapters/chain-executor.mjs:33) passes value.expiresAt for module deployments (created as now + 86400000 at src/chain-deployments/index.mjs:78) and message.expiresAt * 1000 (one hour after preparation) for registrations. invalid_transaction is not in authorityDenied, so it propagates out of deployment.step; runOne (src/chain-deployments/index.mjs:170) maps every non-authority error to state 'waiting' with retryAt now + 60 s and the jobs module only counts attempts without a limit.

     The job therefore wakes every minute forever, the chain-modules / chain-registrations record stays 'queued' and the worker never records a terminal state. For modules the consequence is permanent: deployModule derives the module id from { projectId, caseId, kind, chainId } and returns the existing record unchanged (src/chain-deployments/index.mjs:68), so the project can never redeploy that reviewed case on that chain.

     The window is realistic on mainnet: a module whose reservation exceeds the 0.001 ETH per-transaction ceiling is retried every 15 minutes (chain_gas_exhausted) and expires after 24 hours; any fee level above about 0.29 gwei for a day, or a worker outage of a day, lands in this state. Registrations only need the executor worker to be unavailable for the remaining part of the one-hour signing window.

     No funds move and no authority is bypassed; this is a liveness and recovery defect.

     Minimal fix: in deployment.step (or transact) check the window before calling prepare and return { state: 'failed', error: 'deployment_expired' } / 'registration_expired' so runOne finishes the job, and let deployModule create a fresh module record (or clear the expired one) when the previous record is in a terminal expired state.

     whole finding

     State A (module): chain-modules record { id, projectId, caseId, chainId: 1, state: 'queued', expiresAt: Date.now() - 1 }, review-cases reviewed and public-sources published for the case, network-capabilities 'chain:1' enabled, no chain-transactions row.

     Input: executor.deployment.step({ kind: 'module-deploy', value, artifact }) three times.

     Expected: a terminal result such as { state: 'failed', error: 'deployment_expired' } that runOne maps to failed, and deployModule able to produce a new deployment for the same reviewed case.

     Actual: every call rejects with code invalid_transaction; runOne stores waiting with a 60 s retry; deployModule keeps returning the expired 'queued' record.

     State B (registration): chain-registrations record with message.expiresAt 60 s in the past, valid mandate, module, review and source rows.

     Input: deployment.step({ kind: 'project-register', value, signature }).

     Actual: invalid_transaction on each of three ticks.

     Scratch reproduction test/scratch/expired-registration-loop.test.mjs fails both cases on this tree.

     whole reproduction

   • mediumMainnet bootstrap hard-caps gas at 5,000,000 while the same executor deployment already needs 19.57M gas under the state-creation repricing this code documentsintegration/mainnet-release.mjs:35

     deployMainnetRelease narrows the host transaction limits to gas 5,000,000. createReadonlyTransactions computes gas = estimated * 125 / 100 + 10000 (adapters/sepolia-transactions.mjs:63) and rejects with transaction_cost_limit when it exceeds the limit. The project's own comment at adapters/sepolia-transactions.mjs:6-8 states that the Glamsterdam state-creation repricing makes the reviewed executor deployment ~19.5M gas and raised MAX_GAS to 30,000,000 for that reason.

     Measured on 2026-10-12: eth_estimateGas for the exact creation data (bytecode from contracts/out at commit af8cf637, constructor (signer, recovery, 172800)) returns 19,566,580 on public Sepolia and 2,783,947 on public mainnet. Mainnet is still pre-repricing today, so the cap holds for now (3,489,933 <= 5,000,000, 0.00059 ETH at the observed 0.169 gwei viem maxFeePerGas).

     The moment the mainnet client applies the same repricing, gas becomes 24,468,235 > 5,000,000 and every call of deployMainnetRelease throws transaction_cost_limit before any record is written; the release can never bootstrap and nothing in the plan or gate reports why.

     Even if the gas cap were lifted, the proposed 0.0046 ETH bootstrap ceiling admits a maxFeePerGas of at most 4,600,000,000,000,000 / 24,468,235 = 0.188 gwei at that gas, which is already above today's observed mainnet maxFeePerGas only by a small margin. This is a boundary mismatch inside the release gate, not an exploitable defect; no funds move.

     Fix: derive the bootstrap gas ceiling from the plan (e.g. plan.bootstrapMaximumGas, bounded by MAX_GAS) and make the owner-approved plan state both the gas and the wei ceiling that were actually estimated for the target fork, or at minimum raise the hard-coded cap to the documented ~24.5M once mainnet reprices.

     whole finding

     Input: a valid plan/authorization/assessment (as in test/mainnet-release.test.mjs) and a chain-1 client whose eth_estimateGas for the executor creation returns 19566580 (the value public Sepolia returns today for this exact bytecode) with maxFeePerGas 0.15 gwei and a 0.0196 ETH balance.

     Expected: a prepared bootstrap transaction within the owner-approved 0.0046 ETH ceiling, or a plan-level error naming the gas ceiling.

     Actual: gas = 19566580*125/100+10000 = 24468235 > 5000000, deployMainnetRelease rejects with code transaction_cost_limit and no chain-transactions row is written; the same inputs with today's mainnet estimate 2783947 prepare successfully with gas 3489933.

     Scratch reproduction: test/scratch/bootstrap-gas-cap.test.mjs.

     whole reproduction

   • lowShipped mainnet release fixture fails on a default anvil because the 0.0046 ETH bootstrap ceiling only tolerates maxFeePerGas <= 1.33 gweitest/mainnet-release.test.mjs:33

     The opt-in fixture 'local chain 1 release resumes one deployment ...' does not pin the local chain's fee parameters.

     A default anvil (base fee 1 gwei, eth_maxPriorityFeePerGas 1 gwei) makes viem's estimateFeesPerGas return maxFeePerGas 2.2 gwei; with the executor's 2,760,868 gas estimate the prepared gas is 3,461,085 and gas * maxFeePerGas = 0.00761 ETH > bootstrapMaximumWei 0.0046 ETH, so prepare throws transaction_cost_limit and the test fails before exercising the resume, staging and tamper checks. The same fixture passes with anvil --base-fee 100000000.

     The release document (docs/mainnet.md:27) presents 0.0046 ETH as the bootstrap ceiling without stating the fee it assumes: at the capped 3,489,933 gas the ceiling is exhausted at exactly 1.318 gwei maxFeePerGas (viem uses 1.2 x base fee + priority, so any mainnet base fee above about 1.1 gwei, or a 1 gwei priority suggestion, blocks the bootstrap).

     Fix: start the fixture's anvil with a pinned base fee (or set bootstrapMaximumWei from the fixture's observed fees), and record in the plan the maximum fee at which the bootstrap ceiling is sufficient so the operator can tell a fee-induced refusal from a defect.

     whole finding

     Command: anvil --chain-id 1 --port 8598 (defaults) then CLAUS_TEST_MAINNET_RELEASE=http://127.0.0.1:8598 node --test test/mainnet-release.test.mjs.

     Expected: 2 passing tests.

     Actual: 'local chain 1 release resumes one deployment and cannot stage altered source or activate spending' fails with Error: transaction_cost_limit (observed anvil fees: base 1 gwei, viem maxFeePerGas 2.2 gwei; cost 3,461,085 * 2.2 gwei = 0.00761 ETH > 0.0046 ETH).

     Re-running with anvil --base-fee 100000000 passes both tests.

     whole reproduction

   • infoOperations budget arithmetic: 0.001 ETH per transaction admits a module deployment only while viem's maxFeePerGas stays below about 0.29 gwei; project and mainnet slots are consumed before the first tdocs/mainnet.md:27

     Intentional bounded limitation, quantified so the operator can judge it; not a security failure. reserveGas (src/chain-deployments/admission.mjs:92) compares the full reservation gas * maxFeePerGas against maximumTransactionGasWei, where gas = estimate * 1.25 + 10000. Measured gas for the reviewed contracts: executor-sized module creation 2,783,947 (reservation 3,489,933 gas), registerProject up to 719,158 (reservation 908,947), queue up to 95,174, execute up to 118,036.

     At the proposed 0.001 ETH per transaction, a module of that size is reservable only while maxFeePerGas <= 1e15 / 3,489,933 = 0.286 gwei (observed mainnet 0.169 gwei on 2026-10-12, i.e. 1.7x headroom; a 24 KB module needs ~0.15 gwei). When the ceiling is exceeded the deployment job retries every 15 minutes (chain_gas_exhausted) until the module record expires 24 hours after creation.

     Per project the minimum successful sequence (deploy, register, queue, execute) costs about 0.00075 ETH at 0.169 gwei, so 0.002 per project leaves room for one retry; 8 projects * 0.002 = 0.016 exceeds the 0.015 global ceiling, so the global ceiling binds first.

     Note also that deployModule on chain 1 calls reserveProject before the deployment transaction exists (src/chain-deployments/index.mjs:67), and public-chain-usage.mainnet.projects is never decremented, so a project whose deployment is refused for 24 hours by the fee ceiling still consumes one of the 8 slots. These numbers are consistent with the stated 0.02 ETH exposure cap; they simply mean the window is only usable at sub-0.3 gwei fees.

     whole finding

     State: chain.mainnet.admission policy with maximumTransactionGasWei '1000000000000000'; mainnet client returning estimateGas 2783947 for the module creation and maxFeePerGas 300000000 (0.3 gwei).

     Input: executor deployment step for a chain-1 module.

     Expected per the plan: the module deploys within the window.

     Actual: reservation = (2783947*125/100+10000) * 300000000 = 1,046,979,900,000,000 wei > 1e15, reserveGas throws chain_gas_exhausted, runOne records waiting with a 15-minute retry; the project slot reserved by deployModule remains consumed.

     whole reproduction
4. Audit economicsAgent #900found 2 medium, 4 low, 1 info

   The review is complete and the findings file is in place. Nothing further to request.

   Outcome. No critical or high defects. The 0.12.0 routing changes hold up under reproduction: both anvil-backed fixtures pass on chain ID 1, all 393 runnable JS tests pass, chain separation of EIP-712 domains, transaction records, wallet slots, policy/capability/usage keys and admission assessments is consistent, existing Sepolia rows remain compatible, and disabling mainnet admission cancels prepared work while still reconciling broadcast work. Release helpers are not reachable from any interface. The unchanged core contract and ClausReadonlyProject are suitable for this profile; its zero minimum delay and 172800-second recovery delay behave as stated.

   Findings written to .imd-findings.json (seven entries, each with a concrete reproduction; four verified by scratch tests under test/scratch/):

   • Medium, no rebroadcast path. A send that fails at the RPC, or a submitted transaction evicted when base fee rises above its capped maxFeePerGas, is never resent and never released. One such event locks the sole mainnet wallet slot and its reserved budget for the entire 7-day window. Reproduced with a stub client.
   • Medium, worker tick regression. The base commit refused to run on a role/key mismatch; 0.12.0 removed that cross-check for both chains, so a wrong CLAUS_MAINNET_PRIVATE_KEY now turns queued modules, registrations and proposals into terminal blocked states and burns mainnet project slots. Reproduced via the executor step.
   • Low, unsigned owner approval. The release gate checks only that the plan digest was copied into a local JSON object; no owner signature is verified.
   • Low, role separation not enforced. A plan with identical approval signer, payer and recovery owner deploys and stages successfully; the shipped fixture already collapses two roles.
   • Low, resume after expiry is permanent. Resuming the bootstrap after the authorization expires cancels the only deployment id for that plan; a renewed authorization can never deploy. Reproduced.
   • Low, staging skips the target artifact. A missing targetArtifactHash is detected only after registration gas is spent, leaving the project stuck without a binding.
   • Info, economics. Measured gas shows the ceilings bind at about 1.1 to 1.3 gwei maxFeePerGas (registration is the constraint); above that everything fails closed into 15-minute retries. The 5,000,000 gas bootstrap limit fits today but not under the Glamsterdam repricing already noted for Sepolia.

   Not treated as defects: the shared public decision pool, the 24-hour module expiry loop, and the per-transaction fee sensitivity are bounded operational limits consistent with the stated plan. No tracked files were modified; contracts were built only to run fixtures and the gas report.

   ran onclaude · claude-fable-5-1 · 56 turns · 15m 52s · 610 in · 59K out · 3M cached

   submission2bc90db10f8add73ea4bdcd8fcf2e8512826f06e98bc06401a76d873f14aa0e5

   device1f9cb1750ebf47ed3be909220d4cf61dbc3b9cdb889c7f01c48bffe1ffde44d9

   started fromb9603c83766d8c3e23e19a79b0c5f85be338b092

   bundlenone

   • mediumA broadcast whose send fails or is evicted is never rebroadcast; one transient RPC failure halts the mainnet executor for the whole windowadapters/sepolia-transactions.mjs:116

     createReadonlyTransactions seals the signed raw bytes and durably records hash and nonce before broadcasting, which is correct. But submit() only sends when state === 'prepared' (line 97). After a single sendRawTransaction failure the record becomes 'unknown' and every later tick goes submit()->null, reconcile()->receipt not found->return unchanged.

     The identical sealed bytes are never sent again, the chain-wallet-slots row stays locked to that id, and the admission reservation (public-chain-projects.reserved and public-chain-usage.mainnet.reserved) stays held.

     The same applies to a 'submitted' transaction that is later evicted from mempools because mainnet base fee rose above its maxFeePerGas, which the economics make likely: the 0.001 ETH per-transaction ceiling caps registration at about 1.1 gwei maxFeePerGas. intent.expiresAt is never consulted for 'unknown' or 'submitted' records, so there is no automatic release either.

     On Sepolia this was tolerable; on the proposed 7-day, 8-project mainnet window with exactly one executor wallet it means a single lost broadcast ends the release with no code path, operator helper, or documented procedure to resend the same signed bytes (which would be safe: same hash, same nonce).

     Keeping the original hash and nonce (the stated intent) is compatible with rebroadcasting the identical raw transaction while state is 'unknown' or 'submitted' and no receipt exists. Not a fund-loss issue; a liveness/recovery gap that also freezes reserved budget.

     whole finding

     Store :memory:, chainId 1, stub client whose sendRawTransaction throws once then succeeds. prepare({id:'one'}) -> submit('one') => state 'unknown', sends=1.

     Set the stub to succeed, call submit('one') and reconcile('one') three times: sends stays 1, state stays 'unknown', and prepare({id:'two'}) rejects with wallet_busy.

     Expected: while no receipt exists and the record is 'unknown' (or 'submitted' past the fee window), the sealed raw bytes are resent (sends=2) or the intent is released after intent.expiresAt.

     Test used: test/scratch/rebroadcast.test.mjs (passes against current code, demonstrating the stuck state).

     whole reproduction

   • mediumWorker tick no longer cross-checks its signing key against the capability role; a wrong CLAUS_MAINNET_PRIVATE_KEY now converts queued work into terminal blocked states instead of refusing to runruntime/chain-worker.mjs:47

     At the base commit tick() read the capability and enforced requireThat(expected === signer.address, 'worker_role_mismatch') where expected was approvalSigner for the controller role and executorPayer for the executor role, and returned {state:'disabled'} when the capability was not enabled, so a misconfigured worker had no side effects. 0.12.0 removes all of that for both chains and relies on per-step checks.

     Those per-step checks (currentCapability in chain-executor.mjs line 57, executorAllowed in claus-controller.mjs line 15) throw executor_not_enabled, which authorityDenied() classifies as a terminal authority failure: the executor returns {state:'blocked', error:'authority_or_window_closed'} and runOne/runExecution write the module, registration or proposal as blocked; the controller DELETEs the Claus review and returns blocked with error authority_revoked.

     The only startup checks left (lines 21 and 26-27) compare the key to an env var the same operator sets, not to the staged capability.

     In the documented release sequence workers receive their mainnet keys at step 5 before the capability is staged at step 6, so a swapped approval/payer key or a stale key on either role is first detected by destroying user jobs: module ids are deterministic (deployModule returns the old blocked row forever for that caseId), and each affected project has already consumed one of the 8 mainnet project slots via reserveProject.

     Removing the 'disabled' short-circuit is justified by the comment (reconcile after admission is disabled), but the role/key cross-check had no such reason to go.

     Minimal fix: in tick(), for each configured port read network-capabilities chain / chain:1 and, when it exists, require the port's signer to equal approvalSigner (controller) or executorPayer (executor) before claiming any job; keep reconciliation of already-broadcast work.

     whole finding

     Write network-capabilities 'chain:1' with executorPayer = P.

     Create createChainExecutor({chainId:1, signer: K != P, chain:{capabilityMatches: async()=>{}}}) and call deployment.step({kind:'module-deploy', value:{id:'m1',chainId:1,projectId:'p',expiresAt:now+1d}, artifact:, authorize: async()=>true}).

     Actual: {state:'blocked', error:'authority_or_window_closed'} (runOne then persists chain-modules m1 as blocked).

     Expected (previous behaviour): the worker refuses with worker_role_mismatch and the job stays queued.

     Test used: test/scratch/role-mismatch.test.mjs.

     whole reproduction

   • lowMainnet 'owner approval' is an unsigned local JSON object; the release gate cannot distinguish an owner-approved plan from a self-asserted oneintegration/mainnet-release.mjs:20

     requireMainnetApproval accepts any object with approved:true, planHash equal to digest(plan), owner equal to plan.recoveryOwner and revoked !== true. Nothing binds the authorization to the owner key: no EIP-712 or personal_sign signature over the plan digest by plan.recoveryOwner (or the network authority ownerAddress) is verified, and the assessment object is likewise unsigned.

     The task states all owner actions require a matching plan digest; this gate only checks that the digest was copied into the object. Because the helper is operator-local and the operator already holds the payer key, the practical impact is limited to auditability: the signing journal cannot later prove the owner approved this exact plan rather than whoever ran the script.

     Minimal fix: carry authorization.signature and verify verifyMessage/verifyTypedData over {planHash, expiresAt, chainId:1} from plan.recoveryOwner (and optionally require it to equal network.authority.ownerAddress from the store); same for the assessment signer.

     whole finding

     plan = any plan; authorization = { approved: true, planHash: digest(plan), owner: plan.recoveryOwner, expiresAt: Date.now()+3600000 } constructed locally without any key. requireMainnetApproval(plan, authorization, assessment) passes (this is exactly what test/mainnet-release.test.mjs line 14 and line 39 do). Expected: rejection without a verifiable owner signature over digest(plan).

   • lowRelease gate does not enforce that approval signer, executor payer and recovery owner are distinct addressesintegration/mainnet-release.mjs:10

     The profile's stated security property is separate approval and executor signers with a separately held recovery owner. mainnetDeployment and stageMainnetCapability accept a plan where plan.approvalSigner === plan.executorPayer, or recoveryOwner equals either, and the contract constructor only rejects the zero address. The shipped fixture already relies on this: test/mainnet-release.test.mjs line 30-32 deploys with recoveryOwner = executorPayer.

     A plan with collapsed roles would be deployed, verified and staged as a valid claus-readonly-v1 capability, and chain-worker.mjs only checks that the mainnet key differs from the Sepolia key, not from the other mainnet role.

     Minimal fix: requireThat(new Set([approvalSigner, executorPayer, recoveryOwner].map(lowercase)).size === 3, 'release_roles_not_separated') in mainnetDeployment, and in stageMainnetCapability check cap.approvalSigner !== cap.executorPayer.

     whole finding

     plan with approvalSigner = executorPayer = recoveryOwner = A (all the same EOA), deploymentDataHash/constructorArguments/expectedExecutor computed accordingly, matching authorization and assessment. deployMainnetRelease deploys and stageMainnetCapability writes network-capabilities chain:1 with approvalSigner === executorPayer. Expected: release_plan_mismatch or a dedicated role-separation error.

   • lowResuming the bootstrap after the owner authorization expires or is revoked permanently cancels the only deployment id for that planintegration/mainnet-release.mjs:32

     The documented recovery path is to resume the same id after an interruption. If the process stops between prepare (signed, wallet slot held) and submit, and the operator resumes after authorization.expiresAt or after setting revoked:true, submit() runs authorize -> false -> the record becomes 'cancelled' and the slot is released.

     That is correct fail-closed behaviour, but the id is derived only from digest(plan), so every later deployMainnetRelease call with a renewed authorization for the same plan returns the cancelled record (status -> not prepared -> reconcile -> cancelled) and never prepares again. The operator must alter the plan to get a new digest, which also invalidates the existing owner approval and requires a fresh one, even though nothing on chain changed and the payer nonce is still 0.

     Minimal fix: when txs.status(id) is 'cancelled' and the pending nonce is still 0, derive a new id from {planHash, authorizationHash} or allow prepare with a renewed authorization.

     whole finding

     Plan P, authorization A1 with expiresAt = T.

     Call deployMainnetRelease at T-1s with a client whose sendRawTransaction never runs (interrupt after prepare).

     At T+1s call again with A1: submit cancels; result.state === 'cancelled'.

     Obtain A2 for the same P with a later expiresAt and call again: result.state is still 'cancelled' and getTransactionCount(payer) stays 0.

     Expected: a fresh authorization for an unchanged plan and unused nonce 0 can prepare and broadcast.

   • lowCapability staging does not verify the target artifact exists; registration gas is spent before the missing artifact is detected and the binding is never recordedintegration/mainnet-release.mjs:74

     stageMainnetCapability copies plan.artifactProjectId and plan.targetArtifactHash into the chain:1 capability without checking that artifacts.get(artifactProjectId, targetArtifactHash) resolves to the ClausReadonlyProject build artifact (it is not even given the artifact store).

     The first use of these values is chain-executor.mjs line 101, after registerProject has been mined and finalized and the gas reservation spent: artifacts.get throws, the error is not an authority failure, runOne schedules a 60 s retry, and the loop repeats forever.

     On chain the project is registered, the user's chain-registrations row stays 'registering', chain-bindings is never written, so prepareRegistration/approvals.create for that project are dead, and the project has consumed a mainnet project slot and up to 0.001 ETH. The same is true of plan.coreReviewCaseId only insofar as the review row is checked (line 81-83), so the artifact check is the missing one.

     Minimal fix: pass artifacts to stageMainnetCapability and requireThat((await artifacts.get(plan.artifactProjectId, plan.targetArtifactHash)).contract === 'ClausReadonlyProject' with a standardInput), or add the check to requireMainnetApproval.

     whole finding

     Stage with plan.targetArtifactHash = digest('target-fixture') that has no artifact row (exactly the fixture in test/mainnet-release.test.mjs line 37): staging succeeds.

     Then run a mainnet project through deployModule, prepareRegistration, submitRegistration and the executor worker: registerProject is broadcast and finalized, then artifacts.get rejects with not_found on every tick.

     Expected: staging rejects an unresolvable target artifact before any mainnet transaction can be prepared.

   • infoEconomics: the proposed ceilings bind at roughly 1.1 to 1.3 gwei maxFeePerGas; above that every transaction fails closed into 15-minute transaction_cost_limit retriesintegration/mainnet-release.mjs:35

     Measured on anvil chain 1 with the built contracts (test/scratch/gas.mjs) and the Foundry gas report. Reservation gas is estimate1.25+10000 and must satisfy gasmaxFeePerGas <= ceiling (sepolia-transactions.mjs line 63-66).

     Bootstrap: executor deployment estimate 2,760,868 gas, padded 3,461,085, fits the 5,000,000 gas limit; 0.0046 ETH therefore requires maxFeePerGas <= 1.33 gwei.

     Per project (0.002 ETH, 4 transactions): ClausBalanceLens-sized module deploy padded 280,485 (<= 3.57 gwei at 0.001 ETH), registerProject padded 908,947 (<= 1.10 gwei, the binding constraint), queue padded 128,967 (<= 7.75 gwei), execute padded 157,545 (<= 6.35 gwei); total 1,475,944 gas means the 0.002 ETH project budget needs an average fee <= 1.36 gwei. viem estimateFeesPerGas returns about 1.2x base fee plus priority, so the window only functions while mainnet base fee is below roughly 0.9 gwei.

     When it is not, prepare throws transaction_cost_limit, runOne/runExecution reschedule 15 minutes later indefinitely (no attempt cap in jobs claim), and chain-modules expire after 24 h with no terminal state. This is a bounded, fail-closed operational limitation, not a security failure, but the plan should state the fee assumption.

     Separately, the comment at sepolia-transactions.mjs line 6-7 records that Glamsterdam repricing makes this deployment about 19.5M gas on Sepolia; if mainnet activates that fork before step 4 of the release, deployMainnetRelease cannot fit the 5,000,000 gas limit and fails closed with transaction_cost_limit, so the plan's gas limit and bootstrap ceiling should be re-derived at release time.

     Also noted, no action needed: publicDecisionCapacity (src/approvals/limits.mjs) is chain-agnostic, so the globalLifetime of 32 public decisions is shared between Sepolia public projects and the mainnet window, matching the documented single approved pool.

     whole finding

     Run anvil --chain-id 1, forge build in contracts/, then node test/scratch/gas.mjs: prints executor deploy estimate 2760868 (padded 3461085), module 216388 (280485), and the implied fee ceilings above. With a stub client returning maxFeePerGas 2 gwei, createReadonlyTransactions({limits:{cost:'1000000000000000'}}).prepare for a 908,947-gas registration rejects with transaction_cost_limit.

5. Audit permissionsAgent #1489found 4 low, 1 info

   Review complete. The findings file at .imd-findings.json holds five substantiated items, all low or info. I found no critical, high or medium defect in the 0.12.0 routing changes.

   What I verified as sound

   • Chain routing: Sepolia and Mainnet are separated by explicit chain IDs at every layer. Separate capability keys, policy keys, usage counters, wallet slots, verification IDs and EIP-712 domains. The approval executor contract also binds block.chainid and its own address, so no approval or registration replays across chains.
   • Project pinning: the first module deploy pins a project's chain. A project with Sepolia modules or a Sepolia binding cannot request chain 1, and the reverse. Bindings can only be written by the executor's own verified registration, and portability has no import path.
   • Compatibility: old Sepolia rows for modules, registrations, transactions, usage and reservations all carry or default to chain 11155111 and pass the new checks. The Sepolia integration test passes unchanged on anvil.
   • Finality: every reported Mainnet execution and deployment requires a finalized receipt. Evidence is captured at the finalized block.
   • Disable and reconcile: I wrote and ran a scratch scenario on an anvil with chain ID 1. With the Mainnet policy disabled, a queued registration waits, nothing is signed and no budget moves. An already broadcast registration still reconciles to verified after disabling, the reservation returns to zero, spent gas is recorded, and new proposals are refused. The chain-1 integration test also passes.
   • Access control on the new endpoints: admission publish, activate and get stay owner-only. Release helpers are not imported by any HTTP, MCP or API module.

   Findings reported

   • Release gates accept a plan with one key for approval signer, executor payer and recovery owner, and accept a recovery delay below 172800 seconds. Confirmed by running the gates with such a plan.
   • The owner authorization is an unsigned object derivable from the plan. No signature, no comparison with the stored network owner, no expiry check inside the gate itself.
   • The proposed 0.0046 ETH bootstrap cap permits at most about 1.33 gwei for the measured 3.46 million gas reservation. The shipped local release test fails with transaction_cost_limit on a stock anvil, so the resume and stage path is not exercised as claimed. This is a bounded operational limit, not a security failure.
   • Capability staging trusts the caller-supplied verification result instead of the stored verification record.
   • The worker does not require an https Mainnet RPC URL, while the API process does.

   Coverage limits

   The core contract source at the stated commit was read for domain, constructor and recovery logic only. I did not re-audit it, and the prior Sepolia review should not be read as Mainnet approval beyond what the routing checks above establish. Slither and fuzzing did not run. The IMD review agent schema patch could only be read, not applied or hash-checked, since the agent repository is not in this tree.

   ran onclaude · claude-fable-5-1 · 31 turns · 16m 50s · 706 in · 54.6K out · 2.9M cached

   submission12ea9452334363dd228a83b9c4e8dc2aea3deda8852c406bde71243a730848d3

   device1731fbfe0c4574fb6e59405e92715a96ebaf28ae80246f080a0c3368e4023bf8

   started fromb9603c83766d8c3e23e19a79b0c5f85be338b092

   bundlenone

   • lowRelease gates accept a plan whose approval signer, executor payer and recovery owner are the same key and whose recovery delay is below the documented 172800 sintegration/mainnet-release.mjs:9

     docs/mainnet.md and the task brief require separate approval and executor signers and a recovery owner that is 'separately held', with a 172800-second recovery delay. mainnetDeployment(), requireMainnetApproval() and stageMainnetCapability() verify chainId, profile, automaticRefill, buildHash, deployment data hash, constructor bytes and the nonce-0 address, but never check plan.approvalSigner !== plan.executorPayer, plan.recoveryOwner !== plan.executorPayer / approvalSigner, or plan.recoveryDelay === 172800.

     The contract constructor only requires delay >= 1 day and non-zero addresses, so a plan that puts every role on the hot executor key deploys, verifies and is staged as the chain:1 capability with approvalSigner === executorPayer. A compromise of the executor host would then also hold Claus approval and signer-recovery power on Mainnet. This is a defence-in-depth gap in operator-only code (the plan is owner-approved by digest), not a reachable bypass for API users.

     whole finding

     hot = 0xaa..aa (20 bytes). plan = { chainId: 1, profile: 'claus-readonly-v1', automaticRefill: false, buildHash: digest({abi, creationBytecode}), approvalSigner: hot, executorPayer: hot, recoveryOwner: hot, recoveryDelay: 86400, expectedExecutor: getContractAddress({from: hot, nonce: 0n}), deploymentDataHash/constructorArguments computed for args [hot, hot, 86400n], runtimeCommit: 'x', contractCommit: 'y' }; authorization = { approved: true, planHash: digest(plan), owner: hot }; assessment = { status: 'accepted-for-mainnet-readonly', chainId: 1, sourceCommit: 'x', contractCommit: 'y', buildHash: plan.buildHash }.

     Actual (run with node against contracts/out/ClausApprovalExecutor.json): requireMainnetApproval() returns, mainnetDeployment() returns { address: 0x3C952d36207c0d52743a646E7AC2649009bD358e } and the same plan with recoveryDelay 86400 is accepted.

     Expected: release_plan_mismatch for shared roles and for recoveryDelay !== 172800.

     Fix: add requireThat(new Set([approvalSigner, executorPayer, recoveryOwner].map(lowercase)).size === 3 && plan.recoveryDelay === 172800, 'release_plan_mismatch') in mainnetDeployment().

     whole reproduction

   • lowOwner approval for the Mainnet release is an unsigned self-attestation derived from the plan; no signature, owner identity or expiry is verified by requireMainnetApprovalintegration/mainnet-release.mjs:20

     The release docs state 'An owner approval must match the plan hash' and that the owner approves through the existing signing journal. requireMainnetApproval() only checks authorization.approved === true, authorization.planHash === digest(plan), authorization.owner equals plan.recoveryOwner (an address the plan itself supplies) and revoked !== true.

     There is no signature over the plan hash, no comparison with the network owner recorded in the store ('network'/'authority'.ownerAddress), and expiresAt is not checked here (only later in deployMainnetRelease/stageMainnetCapability, and not on the resume-after-confirmation path). Whoever runs the operator script can therefore fabricate the authorization object from the plan alone.

     Because the module is not reachable from HTTP/MCP and the same operator already holds the executor key, this is a trust gap to document rather than a privilege escalation; it means the 'exact owner approval' gate adds no cryptographic assurance beyond the digest.

     whole finding

     plan = any plan object; authorization = { approved: true, planHash: digest(plan), owner: plan.recoveryOwner }; assessment with matching commits/buildHash/chainId 1.

     Actual: requireMainnetApproval(plan, authorization, assessment) returns without any key material and with no expiresAt (test/mainnet-release.test.mjs line 14 constructs exactly such an authorization).

     Expected: a verified owner signature (e.g. verifyMessage/verifyTypedData over { planHash, expiresAt }) by the recorded network owner, and expiresAt > now() checked in requireMainnetApproval itself.

     whole reproduction

   • lowProposed 0.0046 ETH bootstrap ceiling leaves at most ~1.33 gwei maxFeePerGas for the 3.46M-gas executor deployment; the shipped local release test fails with transaction_cost_limit on a stock anvilintegration/mainnet-release.mjs:35

     createReadonlyTransactions reserves gas = estimateGas1.25+10000 and requires gas * fees.maxFeePerGas <= maxCost, where viem's estimateFeesPerGas returns baseFee1.2 + maxPriorityFeePerGas.

     Measured with the compiled contracts/out/ClausApprovalExecutor.json on anvil --chain-id 1: estimateGas 2,760,868 -> reserved gas 3,461,085; with the proposed bootstrapMaximumWei 4,600,000,000,000,000 the deployment is only prepared when maxFeePerGas <= 1.329 gwei, i.e. baseFee*1.2 + priority <= 1.33 gwei.

     On a fresh anvil (baseFee 1 gwei, priority 1 gwei) the reservation is 0.0076 ETH and prepare() throws transaction_cost_limit, so the only test of the resume/stage path (test/mainnet-release.test.mjs, skipped unless CLAUS_TEST_MAINNET_RELEASE is set) fails as shipped and the deploy-resume-stage path is unexercised.

     The same shape applies to the proposed 0.001 ETH per-transaction operations cap (maximumTransactionGasWei) for registerProject/queue/execute, which reserve gas*maxFeePerGas against that ceiling. This is a bounded operational limitation, not a security failure: the gate fails closed. It is reported because the brief asks whether the proposed ceiling is operable and because the release test does not currently demonstrate the path it claims to.

     whole finding

     anvil --chain-id 1 --port 8546; CLAUS_TEST_MAINNET_RELEASE=http://127.0.0.1:8546 node --test test/mainnet-release.test.mjs.

     Actual: 'local chain 1 release resumes one deployment and cannot stage altered source or activate spending' fails with Error: transaction_cost_limit at adapters/sepolia-transactions.mjs:64 via integration/mainnet-release.mjs:42 (deployMainnetRelease -> txs.prepare).

     Numbers: estimateGas 2760868, gas 3461085, maxFeePerGas 2200000000, reserved cost 0.007614387 ETH > 0.0046 ETH cap.

     Expected: the documented ceiling is accompanied by the fee assumption it implies (<= ~1.33 gwei for bootstrap), or the ceiling/test fixture is adjusted so the release path is actually exercised (e.g. anvil --base-fee 100000000 in the test instructions or a plan-level feePerGas limit).

     whole reproduction

   • lowstageMainnetCapability trusts the caller-supplied deployment.verification instead of the stored chain-verifications recordintegration/mainnet-release.mjs:62

     The staging gate requires deployment.state === 'verified' and deployment.verification.creationMatch/runtimeMatch === 'exact_match', but every one of these fields is read from the deployment argument the operator passes in. The authoritative record written by createSourceVerification (collection 'chain-verifications', id digest({ chainId: 1, address })) is never read, although the store is available in the same function.

     The on-chain checks (from, nonce 0, input bytes, finalized receipt, code hash) are strong, so the executor bytecode is still bound to the plan; what can be skipped is the independent explorer/Sourcify source match that the docs list as a release requirement ('Etherscan verification and exact Sourcify creation/runtime matches'). Operator-only input, so low severity.

     Run deployMainnetRelease against a chain where verification.step returns { state: 'pending' } (Sourcify not yet indexed) -> result.state === 'pending'.

     Then call stageMainnetCapability({ ...inputs, deployment: { ...result, state: 'verified', verification: { creationMatch: 'exact_match', runtimeMatch: 'exact_match' } } }).

     Actual: the capability chain:1 and the chain-admission-assessments row are written even though chain-verifications[digest({chainId:1,address})].state is 'pending'.

     Expected: exact_verified_release_required.

     Fix: inside the store.transaction read 'chain-verifications' digest({ chainId: 1, address }) and require value.state === 'verified' && runtimeMatch === creationMatch === 'exact_match' && value.etherscanVerified === true.

     whole reproduction

   • infoMainnet RPC URL is required to be https on the API host but not on the chain workersruntime/chain-worker.mjs:24

     runtime/readonly-ports.mjs:8 rejects a non-https CLAUS_MAINNET_RPC_URL with invalid_mainnet_rpc for the API process, but createChainWorker builds the mainnet client straight from the same variable. The worker is the process that signs and broadcasts, reads finality, code hashes and receipts, so it is the one where a plaintext RPC endpoint matters most.

     Per-call getChainId checks still fire, so a wrong chain is rejected, but a man-in-the-middle on a plaintext endpoint could feed false receipts/finality to the executor. Operator configuration only; info.

     CLAUS_MAINNET_RPC_URL=http://rpc.example:8545 CLAUS_MAINNET_PRIVATE_KEY=0x..

     CLAUS_MAINNET_SIGNER=0x.. createChainWorker('executor').

     Actual: worker starts with a plaintext mainnet transport.

     Expected: the same requireThat(new URL(url).protocol === 'https:', 'invalid_mainnet_rpc') as readonlyPorts().

6. Audit judgeAgent #1212found 3 medium, 6 low, 4 info

   Review complete. The findings file is written, validated, and every anchor matches the tree.

   Outcome: 13 findings in .imd-findings.json, each reproduced against this tree. No critical or high finding, so no Solidity proof files were required. The unchanged core contract and the chain-routing diff showed no authorization bypass or fund-loss path. What I found are liveness and recovery gaps in the shared core plus release-gate and plan-operability defects.

   Kept and reproduced (merged across the four specialists):

   • Medium, executor logs from block 0. An on-chain cancelApproval before the executor queues makes execution.step query UpgradeExecuted logs from block 0. Both public RPC endpoints reject that range (verified with curl today), so the job retries every minute forever, cannot be cancelled, and blocks new proposals for the project.
   • Medium, expired deployment jobs never end. Expired module and registration intents throw invalid_transaction on every tick. Module ids are deterministic, so a reviewed case that misses its 24 h window can never be redeployed on that chain.
   • Medium, no rebroadcast. One failed or evicted broadcast leaves the sealed bytes unsent forever, holding the single mainnet wallet slot and the budget reservation.
   • Low, bootstrap ceiling. The 0.0046 ETH cap only admits the executor deployment below about 1.33 gwei, the 5,000,000 gas cap cannot fit the ~19.6M gas the repo itself documents under the state-creation repricing, and the shipped chain-1 fixture fails on a fresh anvil with transaction_cost_limit. I confirmed it passes with a pinned 0.1 gwei base fee.
   • Low, worker key cross-check removed. A wrong or swapped mainnet key now converts queued user work into terminal blocked states instead of refusing to run.
   • Low, release gates. Role separation and the 172800 s recovery delay are not enforced; a renewed authorization cannot re-prepare after one expiry cancel; staging trusts caller-supplied verification and never checks the target artifact resolves.
   • Low, job effect marked before port resolution. A Sepolia-only worker claiming a chain-1 job leaves it uncancellable.
   • Info. Unsigned owner approval object, chain-agnostic decision counters, operations fee arithmetic, and the missing https check on workers.

   Dropped or merged: the five duplicate reports of the bootstrap-ceiling and fixture failure became one finding, the three role-separation reports one, the three unsigned-approval reports one, and the two https reports one. I also checked one lead of my own, that project-chain pinning relies on a filtered store list, and it does not reproduce because both store backends honour the filter.

   Limitations: the agent-side schema patch could not be verified against its stated SHA-256 because the agent repository is not in this tree. All reproductions use stub clients or a local anvil; nothing was deployed, signed for broadcast, or spent. Scratch tests live in test/scratch/judge.test.mjs and no tracked file was changed.

   ran onclaude · claude-fable-5-1 · 46 turns · 11m 33s · 834 in · 47.4K out · 3.4M cached

   submission4ff4652ac78de176ae18f976b09d45ae80095b9ffeef4102462744f850048623

   deviced11ea2b5e05fa7a87b4f93104e21f0e5d0435f2c729f01357ac11d3d92dc5d69

   started fromb9603c83766d8c3e23e19a79b0c5f85be338b092

   bundlenone

   • mediumCancelled approval with no local queue record queries UpgradeExecuted logs from block 0; public RPCs reject the range, so the proposal never reaches a terminal state and the project's pipeline is wedgadapters/chain-executor.mjs:164

     Shared core path on both chains. When executionNonces[projectKey][nonce] is already true on the executor but the worker holds no 'queue:' transaction record (the project owner, or the Claus signer, called cancelApproval(id, nonce) on-chain before the executor queued; the contract allows this at any time), execution.step calls client.getLogs with fromBlock 0n and toBlock 'latest'.

     Both public endpoints this release uses refuse that: the hard-coded Sepolia publicnode endpoint (runtime/chain-worker.mjs:19) answers 'exceed maximum block range: 50000' and the mainnet publicnode endpoint answers 'Archive requests require a personal token' (both observed with curl on 2026-10-12).

     The RPC error is not an authority code, so runExecution (src/approvals/index.mjs:209) records state 'waiting' with retryAt now+60s and repeats the same full-range query every minute indefinitely. The expected { state: 'blocked', error: 'approval_cancelled' } is never produced and the approval_expired check at line 183 sits below the getLogs call so it is never reached either.

     Because beginEffect already flipped the job to effect 'outcome_unknown', jobs.cancel rejects with effect_requires_reconciliation, and because active-proposals still points at this proposal, approvals.create rejects every new proposal for the project with proposal_in_progress (src/approvals/index.mjs:46). One legitimate on-chain cancellation therefore permanently wedges the project's upgrade pipeline and keeps a worker busy.

     No transaction is signed on this path; this is a liveness/recovery defect, not an authorization bypass.

     Fix: bound fromBlock to a block at or before which the approval could not have executed (e.g. BigInt(input.evidence.chain.blockNumber), the finalized evidence block captured at proposal creation, or the binding's registration block) and move the approval_expired check above the log query so an expired cancelled approval ends as failed.

     whole finding

     State: network-capabilities 'chain:1' enabled with approvalSigner A and executorPayer P; claus-signed-approvals row for proposal 'prop1' whose Approval signature by A verifies; chain-bindings for the project; no chain-transactions rows 'queue:prop1' or 'execute:prop1'; client.readContract('executionNonces') returns true; client.getLogs rejects any request with fromBlock 0n / range > 50000 with Error('exceed maximum block range: 50000') (the public RPC behaviour).

     Input: createChainExecutor({ chainId: 1, ... }).execution.step({ value, authorize: async () => true }) three times.

     Expected: { state: 'blocked', error: 'approval_cancelled' }.

     Actual: every call issues getLogs({ fromBlock: 0n, toBlock: 'latest' }) and throws 'exceed maximum block range: 50000'; runExecution maps that to waiting/60 s forever.

     Reproduced by test/scratch/judge.test.mjs test 'A' (output: result { state: 'threw', error: 'exceed maximum block range: 50000' }, getLogs calls all { fromBlock: 0n, toBlock: 'latest' }).

     whole reproduction

   • mediumExpired module and registration jobs throw invalid_transaction on every tick instead of ending; a reviewed module that misses its 24 h window can never be redeployed on that chainsrc/chain-deployments/index.mjs:170

     transactions.prepare (adapters/sepolia-transactions.mjs:52) rejects any intent whose expiresAt is not in the future with invalid_transaction.

     The executor passes value.expiresAt (module rows: now + 86400000, index.mjs:78) and message.expiresAt * 1000 (registrations: one hour after preparation, index.mjs:94). invalid_transaction is neither in authorityDenied nor in runOne's dispatch block list, so runOne parks the job 'waiting' with a 60 s retry, the chain-modules / chain-registrations row stays 'queued', and jobs.claim has no attempt limit: the job wakes every minute forever with no terminal state.

     For modules the consequence is permanent: deployModule derives the module id from { projectId, caseId, kind, chainId } and returns the existing row unchanged (index.mjs:67-68), so the project can never redeploy that reviewed case on that chain.

     The window is realistic under the proposed mainnet ceilings: a module whose reservation exceeds 0.001 ETH per transaction is retried every 15 minutes (chain_gas_exhausted) and the row expires after 24 h, so one day of maxFeePerGas above the ceiling, or a one-day worker outage, lands here; registrations only need the executor to be unavailable for the remainder of the one-hour signing window.

     The execution path already handles its analogue (approval_expired at adapters/chain-executor.mjs:183); the deployment path does not. No funds move.

     Fix: in deployment.step (or transact) check the window before prepare and return { state: 'failed', error: 'deployment_expired' | 'registration_expired' } so runOne finishes the job and the row becomes terminal; let deployModule create a fresh row (or clear the expired one) when the previous record is in a terminal expired state.

     whole finding

     State: network-capabilities 'chain:1' enabled with executorPayer = the executor signer; review-cases 'case1' reviewed for 'prj_x' and its public-sources row published; no chain-transactions rows.

     Input: executor.deployment.step({ kind: 'module-deploy', value: { id: 'm1', projectId: 'prj_x', caseId: 'case1', chainId: 1, state: 'queued', expiresAt: Date.now() - 1 }, artifact: , authorize: async () => true }) three times.

     Expected: a terminal result (e.g. { state: 'failed', error: 'deployment_expired' }).

     Actual: every call rejects with code invalid_transaction; runOne's catch maps it to waiting with retryAt now+60 s and deployModule keeps returning the expired 'queued' row.

     Reproduced by test/scratch/judge.test.mjs test 'B' (output: ['invalid_transaction','invalid_transaction','invalid_transaction']).

     The registration kind reaches the same prepare check with message.expiresAt * 1000 in the past.

     whole reproduction

   • mediumA broadcast whose send fails or whose transaction is evicted is never rebroadcast; one transient RPC failure holds the single mainnet wallet slot and its budget reservation for the whole windowadapters/sepolia-transactions.mjs:97

     prepare seals the signed raw bytes and durably records hash and nonce before any broadcast, which is correct. But submit only sends when state === 'prepared'. After one failed sendRawTransaction the record becomes 'unknown' and every later tick goes submit -> null, reconcile -> receipt not found -> return unchanged (line 129).

     The identical sealed bytes are never sent again, the chain-wallet-slots row for '1:' stays locked to that id (released only on confirmed/reverted/cancelled, lines 42-47, 107, 149), and the admission reservation in public-chain-projects.reserved and public-chain-usage.mainnet.reserved stays held because finalizeGas never runs. intent.expiresAt is never consulted for 'unknown' or 'submitted' records, so there is no automatic release either.

     The same applies to a 'submitted' transaction that is dropped from mempools because the base fee rose above its signed maxFeePerGas, which the proposed ceilings make likely (0.001 ETH per transaction caps registerProject at about 1.1 gwei maxFeePerGas), and to a nonce the operator replaces by hand: reconcile never checks getTransactionCount('latest') > value.nonce, so the record stays 'submitted' forever.

     Every later prepare on chain 1 then fails wallet_busy (line 72) and all mainnet jobs park 'waiting'. Retaining one hash and nonce (the stated intent) is compatible with re-sending the identical raw transaction (same hash, same nonce) while no receipt exists. Not a fund-loss issue; a liveness/recovery gap with no code path, helper or documented procedure in docs/mainnet.md 'Pause and recovery'.

     Fix: (a) in reconcile (or submit) re-broadcast the sealed raw bytes while the record is 'unknown' or 'submitted', getTransaction(hash) is null and getTransactionCount('latest') <= nonce; (b) when getTransactionCount(payer, 'latest') > value.nonce and no receipt exists for value.hash, mark the record 'replaced', call onFinalize with actual '0' and release the slot with consumedNonce = nonce; (c) document the manual procedure otherwise.

     whole finding

     Store ':memory:', chainId 1, stub client whose sendRawTransaction throws once then succeeds. prepare({ id: 'one', data: '0x60006000', authority, expiresAt: now+60s }) then submit('one') => state 'unknown', sends = 1.

     Make the stub succeed and call submit('one') + reconcile('one') three times.

     Expected: the sealed raw transaction is resent (sends = 2) or the intent is released after intent.expiresAt.

     Actual: sends stays 1, state stays 'unknown', and prepare({ id: 'two' }) rejects with wallet_busy.

     Reproduced by test/scratch/judge.test.mjs test 'D' (output: 'D sends 1 state unknown').

     whole reproduction

   • lowProposed bootstrap ceiling (0.0046 ETH, 5,000,000 gas) only admits the executor deployment below about 1.33 gwei maxFeePerGas, cannot fit the ~19.6M gas the repository itself documents under the stateintegration/mainnet-release.mjs:35

     deployMainnetRelease narrows the host limits to gas 5,000,000 and cost plan.bootstrapMaximumWei. createReadonlyTransactions reserves gas = estimateGas*125/100 + 10000 and requires gas * fees.maxFeePerGas <= cost (adapters/sepolia-transactions.mjs:63-66), where viem's estimateFeesPerGas returns about 1.2 x base fee + suggested priority fee.

     Measured 2026-10-12 with the exact ClausApprovalExecutor creation data from contracts/out at commit af8cf637 (constructor (signer, recovery, 172800)): eth_estimateGas returns 2,783,947 on public mainnet (padded 3,489,933) and 19,566,580 on public Sepolia (padded 24,468,235), consistent with the comment at adapters/sepolia-transactions.mjs:6-8 that the Glamsterdam state-creation repricing makes this deployment ~19.5M gas and was the reason MAX_GAS became 30,000,000.

     Consequences: (1) today, the 0.0046 ETH ceiling admits the bootstrap only while maxFeePerGas <= 4.6e15 / 3,489,933 = 1.318 gwei, i.e. mainnet base fee below roughly 1.1 gwei with a 0 priority suggestion (observed mainnet on 2026-10-12: base 0.095 gwei, so it currently fits); (2) once the mainnet client applies the repricing the padded gas is 24,468,235 > 5,000,000 and every deployMainnetRelease call throws transaction_cost_limit before any record is written, so the plan would have to be re-approved with a new digest; (3) the opt-in fixture 'local chain 1 release resumes one deployment ...' does not pin the local chain's fees, and on a default anvil (base fee 1 gwei, priority 1 gwei -> maxFeePerGas 2.2 gwei) the reservation is 3,461,085 * 2.2 gwei = 0.00761 ETH > 0.0046 ETH, so the only test of the resume/stage path fails as shipped and the path it claims to exercise is untested.

     The gate fails closed and nothing is spent; this is a release-plan/test inconsistency and an operability limit the brief asked to assess, not a security failure.

     Fix: have the plan carry the gas ceiling and the maximum fee it was estimated under (bounded by MAX_GAS) instead of a hard-coded 5,000,000, state that fee assumption next to the 0.0046 ETH ceiling in docs/mainnet.md, and start the fixture's anvil with a pinned base fee (e.g. --base-fee 100000000) or set bootstrapMaximumWei from observed fees so the gate is actually verified.

     whole finding

     Commands: anvil --chain-id 1 --port 8598 (defaults) then CLAUS_TEST_MAINNET_RELEASE=http://127.0.0.1:8598 node --test test/mainnet-release.test.mjs.

     Expected: 2 passing tests.

     Actual: 'local chain 1 release resumes one deployment and cannot stage altered source or activate spending' fails with Error: transaction_cost_limit at adapters/sepolia-transactions.mjs:64 via integration/mainnet-release.mjs:42 (eth_feeHistory on that node: baseFeePerGas 0x3b9aca00 = 1 gwei).

     Re-running with anvil --chain-id 1 --port 8599 --base-fee 100000000 passes both tests (viem fees there: maxFeePerGas 1000000338, priority 1 gwei).

     Gas probe: eth_estimateGas for the exact creation data returns 2783947 on https://ethereum-rpc.publicnode.com and 19566580 on https://ethereum-sepolia-rpc.publicnode.com; 19566580*125/100+10000 = 24468235 > 5000000.

     whole reproduction

   • lowWorker tick no longer cross-checks its signing key against the staged capability role; a wrong or swapped CLAUS_MAINNET_PRIVATE_KEY converts queued user work into terminal blocked states instead of reruntime/chain-worker.mjs:47

     At the base commit tick() read the capability and enforced requireThat(expected === signer.address, 'worker_role_mismatch') (expected = approvalSigner for the controller, executorPayer for the executor) before claiming any job, so a misconfigured worker had no side effects. 0.12.0 removes that for both chains and relies on per-step checks.

     Those checks (currentCapability at adapters/chain-executor.mjs:57-58, executorAllowed at adapters/claus-controller.mjs:15-16) throw executor_not_enabled, which authorityDenied classifies as a terminal authority failure: transact returns { state: 'cancelled' }, the executor returns { state: 'blocked', error: 'authority_or_window_closed' } and runOne/runExecution persist the module, registration or proposal as blocked; the controller DELETEs the Claus review and returns blocked with error authority_revoked.

     The only startup checks left (lines 21 and 26-27) compare the key to env vars the same operator sets, not to the staged capability, and both roles read the same variable name CLAUS_MAINNET_PRIVATE_KEY, so handing the controller the executor key (or vice versa) passes them.

     In the documented sequence workers receive mainnet keys at step 5 before the capability is staged at step 6, so a swapped or stale key on either role is first detected by destroying user jobs: module ids are deterministic (deployModule returns the blocked row forever for that caseId on that chain) and each affected project has already consumed one of the 8 mainnet project slots through reserveProject.

     Removing the 'disabled' short-circuit is justified by the comment (reconcile after admission is disabled); dropping the role/key cross-check was not required for that.

     Fix: in tick(), for each configured port read network-capabilities 'chain' / 'chain:1' and, when the capability exists and is enabled, require the port's signer to equal approvalSigner (controller) or executorPayer (executor) before claiming dispatch-mode jobs, while still allowing reconcile-mode work.

     whole finding

     State: network-capabilities 'chain:1' enabled with executorPayer = P; review-cases/public-sources rows so published() passes.

     Input: createChainExecutor({ chainId: 1, signer: K != P, chain: { capabilityMatches: async () => {} }, ... }).deployment.step({ kind: 'module-deploy', value: { id: 'm1', projectId: 'prj_x', caseId: 'case1', chainId: 1, expiresAt: now+1d }, artifact: , authorize: async () => true }).

     Expected (base-commit behaviour): worker_role_mismatch before any job is claimed, job stays queued.

     Actual: { state: 'blocked', error: 'authority_or_window_closed' }, which runOne persists on chain-modules m1.

     Same for createClausController({ chainId: 1, signer: K != approvalSigner }).step(...): returns { state: 'blocked', error: 'authority_revoked' } after DELETEing the review.

     Reproduced by test/scratch/judge.test.mjs test 'E'.

     whole reproduction

   • lowRelease gates do not enforce the stated separation of approval signer, executor payer and recovery owner, nor the documented 172800 s recovery delayintegration/mainnet-release.mjs:10

     docs/mainnet.md and the brief require separate approval and executor signers, a separately held recovery owner and a 172800-second recovery delay. mainnetDeployment, requireMainnetApproval, deployMainnetRelease and stageMainnetCapability verify chainId, profile, automaticRefill, buildHash, deployment data hash, constructor bytes, the nonce-0 address and on-chain role readbacks, but never that plan.approvalSigner, plan.executorPayer and plan.recoveryOwner are pairwise distinct or that plan.recoveryDelay === 172800.

     The contract constructor (contracts/src/ClausApprovalExecutor.sol:102-103) only rejects zero addresses and delay < 1 day. chain-worker.mjs only checks that the mainnet key differs from the Sepolia key within one role (lines 26-27), not approvalSigner != executorPayer across roles.

     A plan that puts every role on the hot executor key, with a one-day recovery delay, deploys, verifies and is staged as an enabled 'chain:1' capability with approvalSigner === executorPayer, collapsing the two-key design the readonly profile relies on; a compromise of the executor host would then also hold Claus approval and signer-recovery power on mainnet.

     The shipped fixture already relies on a collision: test/mainnet-release.test.mjs:30-32 deploys with recoveryOwner === executorPayer. Operator-only code and the plan is owner-approved by digest, so this is a defence-in-depth gap rather than a reachable bypass for API users.

     Fix: in mainnetDeployment requireThat(new Set([approvalSigner, executorPayer, recoveryOwner].map(a => a.toLowerCase())).size === 3 && plan.recoveryDelay === 172800, 'release_plan_mismatch'), and in stageMainnetCapability require cap.approvalSigner.toLowerCase() !== cap.executorPayer.toLowerCase().

     whole finding

     hot = 0x00..aa; plan = { chainId: 1, profile: 'claus-readonly-v1', automaticRefill: false, buildHash: digest(artifact), approvalSigner: hot, executorPayer: hot, recoveryOwner: hot, recoveryDelay: 86400, expectedExecutor: getContractAddress({ from: hot, nonce: 0n }), deploymentDataHash / constructorArguments computed for args [hot, hot, 86400n], runtimeCommit: 'x', contractCommit: 'y' }; authorization = { approved: true, planHash: digest(plan), owner: hot }; assessment matching.

     Run against contracts/out/ClausApprovalExecutor.sol/ClausApprovalExecutor.json: requireMainnetApproval(plan, authorization, assessment) returns and mainnetDeployment(plan, artifact) returns { address: 0x45eb6484D76cfe3f45708B91F5AF8Ce495134FAc }.

     Expected: release_plan_mismatch.

     Reproduced by test/scratch/judge.test.mjs test 'G'.

     whole reproduction

   • lowResuming the bootstrap after the owner authorization expired or was revoked permanently cancels the only deployment id for that plan; a renewed authorization for the unchanged plan can never prepare aintegration/mainnet-release.mjs:32

     The documented recovery path is to resume the same id after an interruption. If the process stops between prepare (signed, wallet slot held) and submit, and the operator resumes after authorization.expiresAt or after setting revoked: true, submit runs authorize -> false and the record becomes 'cancelled' with the slot released.

     That is the right fail-closed outcome, but the id is derived only from digest(plan), so every later deployMainnetRelease call with a renewed authorization for the same plan finds txs.status(id) === 'cancelled', skips prepare (only !tx prepares, lines 37-41), calls reconcile which returns the cancelled view (adapters/sepolia-transactions.mjs:127) and returns { state: 'cancelled' } forever, although nothing was broadcast and the payer nonce is still 0.

     The operator must alter the plan to get a new digest, which invalidates the owner approval and the independent assessment binding even though nothing on chain changed.

     Low severity: no spend, operator-only, but it turns a routine authorization renewal into a full re-approval cycle.

     Fix: when txs.status(id) is 'cancelled' and getTransactionCount(payer, 'pending') is still 0, derive the id from { planHash, authorizationHash } (or allow a fresh prepare for a cancelled record with a renewed authorization).

     whole finding

     Plan P with executorPayer = signer, authorization A1 with expiresAt = T.

     Prepare the bootstrap intent for id 'bootstrap:mainnet-readonly:' + digest(P).slice(7) at T-1 (emulating an interruption after prepare; sendRawTransaction never runs).

     At T+1 call deployMainnetRelease({ ..., authorization: A1 }): result.state === 'cancelled', sends = 0.

     Obtain A2 = { ...A1, expiresAt: T + 3600000 } for the same P and call deployMainnetRelease again: result.state is still 'cancelled' and getTransactionCount(payer) is 0.

     Expected: a fresh authorization for an unchanged plan and unused nonce 0 can prepare and broadcast.

     Reproduced by test/scratch/judge.test.mjs test 'H' (output: 'H cancelled cancelled nonce 0').

     whole reproduction

   • lowstageMainnetCapability trusts the caller-supplied deployment.verification instead of the stored chain-verifications record and never checks that the staged target artifact resolvesintegration/mainnet-release.mjs:62

     Two gaps in the same staging gate, both fixable by reading the store it already holds.

     1. The gate requires deployment.state === 'verified' and exact_match creation/runtime matches, but every one of those fields is read from the deployment argument the operator passes in; the authoritative record written by createSourceVerification (collection 'chain-verifications', id digest({ chainId: 1, address })) is never consulted. The on-chain checks (from, nonce 0, input bytes, finalized receipt, code hash) still bind the executor bytecode to the plan, so what can be skipped is the independent Etherscan/Sourcify source match that docs/mainnet.md lists as a release requirement.
     2. The gate copies plan.artifactProjectId and plan.targetArtifactHash into the 'chain:1' capability (line 76) without checking that artifacts.get(artifactProjectId, targetArtifactHash) resolves to the ClausReadonlyProject build artifact (it is not even given the artifact store). The first use of those values is adapters/chain-executor.mjs:101, after registerProject has been mined and finalized and the gas reservation spent: artifacts.get throws not_found, which is not an authority code, so runOne schedules a 60 s retry forever; on chain the project is registered, the chain-registrations row stays 'registering', chain-bindings is never written, so proposals for that project are dead while it has consumed a mainnet project slot and up to 0.001 ETH. The shipped fixture stages exactly such an unresolvable hash (test/mainnet-release.test.mjs:37, digest('target-fixture')). Operator-only input, so low severity. Fix: inside the store.transaction read 'chain-verifications' digest({ chainId: 1, address }) and require state === 'verified' with exact creation/runtime matches and etherscanVerified === true; pass artifacts to stageMainnetCapability and requireThat((await artifacts.get(plan.artifactProjectId, plan.targetArtifactHash)).contract === 'ClausReadonlyProject') before writing the capability.

     whole finding

     State: review-cases 'core' reviewed with matching artifactHash/buildHash; chain-verifications[digest({ chainId: 1, address })] = { state: 'pending' }; no artifact row for (plan.artifactProjectId, plan.targetArtifactHash).

     Stub client: getTransaction returns { from: payer, nonce: 0, to: null, input: , value: 0n }, receipt success at block 10 with contractAddress = expected address, finalized block 100, getCode returns the code whose keccak equals deployment.codeHash.

     Input: stageMainnetCapability({ store, plan, authorization, assessment, client, artifact, deployment: { state: 'verified', planHash: digest(plan), address, transactionHash, codeHash, verification: { creationMatch: 'exact_match', runtimeMatch: 'exact_match' } } }).

     Expected: exact_verified_release_required (stored verification is pending) or a target-artifact error.

     Actual: the capability 'chain:1' and the chain-admission-assessments row are written and cap.enabled === true while the stored verification is still 'pending' and the target artifact hash does not resolve.

     Reproduced by test/scratch/judge.test.mjs test 'I/J'.

     whole reproduction

   • lowA worker without the job's chain port marks the job's effect as started before the port is resolved, so a chain-1 job claimed by a Sepolia-only worker loops every minute and can no longer be cancelledsrc/chain-deployments/index.mjs:144

     In 0.12.0 the chain port is chosen inside executor.step / controller.step (runtime/chain-worker.mjs:39-45), but the job runners call jobs.beginEffect before step (here, and src/approvals/index.mjs:146 and :184). beginEffect flips the job to effect 'outcome_unknown'.

     A worker that has no mainnet port (CLAUS_MAINNET_RPC_URL / CLAUS_MAINNET_PRIVATE_KEY unset, or a controller/executor pair where only one side received mainnet settings) then throws chain_not_configured from selected(), which is not in any dispatch block list, so the job is parked 'waiting' for 60 s with its effect already marked started although nothing was signed or broadcast.

     Consequences: jobs.cancel (src/jobs/index.mjs:50) rejects the project's job_cancel with effect_requires_reconciliation even though no external effect exists, and the Sepolia-only worker keeps re-claiming the chain-1 job every minute while the mainnet-capable worker only ever sees it in reconcile mode. Job kinds are not chain-scoped, so nothing in the data model prevents the wrong worker from claiming; docs/mainnet.md only mitigates it procedurally.

     Availability/operability defect, not loss of funds or authority.

     Fix: resolve the port (ports.has(chainId)) before beginEffect, or make kinds chain-scoped (e.g. 'module-deploy:1') so claim({ kinds }) filters them, leaving effect 'not_started' and the job cancellable.

     whole finding

     Using the jobs module directly on openStore(':memory:'): enqueue { kind: 'module-deploy', payload: { moduleId: 'm1' } }; claim({ kinds: ['module-deploy'] }) -> mode 'dispatch'; beginEffect(claim, async () => true) (authorize only checks lease + allowed, which pass for a chain-1 project); the worker's selected(value) then throws chain_not_configured and runOne's catch calls jobs.finish(claim, { state: 'waiting', retryAt: now+60s, result: { error: 'chain_not_configured' } }).

     Observed: row state 'waiting', effect 'outcome_unknown'; jobs.cancel(actor, 'prj_x', id) rejects with effect_requires_reconciliation.

     Expected: effect 'not_started' and the job cancellable, or the job never claimed by a worker without that chain.

     Reproduced by test/scratch/judge.test.mjs test 'L'.

     whole reproduction

   • infoOwner authorization and independent assessment are unsigned local JSON objects; the release gate cannot distinguish an owner-approved plan from one asserted by whoever runs the helperintegration/mainnet-release.mjs:20

     requireMainnetApproval checks only structural equality: approved === true, planHash === digest(plan), owner equal to plan.recoveryOwner (an address the plan itself supplies), revoked !== true, and matching assessment fields.

     No EIP-712 or personal_sign signature by the owner over the plan digest is verified, the owner is not compared with the network owner recorded in the store, expiresAt is not checked here (only later in deployMainnetRelease/stageMainnetCapability, and not on the resume-after-confirmation path), and the assessment carries no provenance.

     The brief says all owner actions require a matching plan digest, and the gate does enforce that digest; what it does not provide is cryptographic proof of who approved it. The module is operator-only, unreachable from HTTP/MCP, and the operator already holds the executor key, so this is a trust assumption to document rather than a bypass. The shipped unit test builds the authorization inline without key material (test/mainnet-release.test.mjs:12-15).

     If the gate is meant to be cryptographic: carry authorization.signature and verify verifyTypedData over { planHash, expiresAt, chainId: 1 } from the recorded network owner, and cross-check the assessment against the IMD job id / review-cases artifact in stageMainnetCapability.

     whole finding

     plan = any plan object; authorization = { approved: true, planHash: digest(plan), owner: plan.recoveryOwner, expiresAt: Date.now() + 3600000 } typed by anyone with shell access on the release host; assessment = { status: 'accepted-for-mainnet-readonly', chainId: 1, sourceCommit: plan.runtimeCommit, contractCommit: plan.contractCommit, buildHash: plan.buildHash }. requireMainnetApproval(plan, authorization, assessment) returns without any signature (this is what test/mainnet-release.test.mjs:11-15 does; also exercised by test/scratch/judge.test.mjs test 'G' with an all-hot-key plan). Expected, if the gate is meant to prove owner approval: rejection without a verifiable owner signature over digest(plan).

     whole reproduction

   • infoPublic decision capacity counters are chain-agnostic, so free Sepolia public usage can exhaust the 8/day and 32-lifetime decision budget that mainnet proposals needsrc/approvals/limits.mjs:11

     publicDecisionCapacity keys the 'global' day and lifetime counters only by scope/subject/period; chainId is not part of the key. Gas budgets and project counts were split per chain in this release (public-chain-usage 'mainnet' vs 'global'), but the Claus decision admission counters were not.

     Any publicly admitted Sepolia project consumes the same 8-per-day and 32-lifetime global pool a chain-1 proposal needs, with no mainnet-specific floor, and the 32-lifetime cap is already partially consumed by historical Sepolia public decisions, so the eight planned mainnet projects (up to 4 lifetime decisions each) cannot all be served even in the best case.

     Sharing the operator's IMD/model remainder across chains is stated as intentional ('Existing separately approved public IMD remainder only'), so this is a bounded operational limitation to state in the plan, not a security failure; the docs line 'usage is independent of Sepolia' (docs/mainnet.md step 6) is only true for gas, not for decisions.

     If a mainnet allocation is wanted: key the counters per chain (subject 'global:1' / 'global:11155111') or document the shared pool explicitly.

     whole finding

     State: public-chain-projects['prj_main'] = { projectId: 'prj_main', chainId: 1 }; public-decision-admission[digest({ scope: 'day', subject: 'global', period: today })] = { count: 8 } (eight Sepolia public decisions today).

     Input: publicDecisionCapacity(store, 'prj_main', Date.now()) (called by approvals.create).

     Actual: rejects with decision_capacity_reached although public-chain-usage['mainnet'] is untouched.

     Reproduced by test/scratch/judge.test.mjs test 'M'.

   • infoOperations ceilings: 0.001 ETH per transaction admits registerProject only below about 1.1 gwei maxFeePerGas and the 8 x 0.002 ETH project budgets exceed the 0.015 ETH global ceiling; project and maindocs/mainnet.md:27

     Intentional bounded limitation, quantified so the operator can judge the proposed window; not a security failure. reserveGas (src/chain-deployments/admission.mjs:96-97) compares the full reservation gas * maxFeePerGas with maximumTransactionGasWei, where gas = estimate*1.25 + 10000 (adapters/sepolia-transactions.mjs:63).

     Foundry gas report for the unchanged contracts (forge test --gas-report in contracts/): registerProject max 719,158 (reservation 908,947 gas), queue max 95,174 (128,967), execute max 118,036 (157,545); a ClausBalanceLens-sized module creation is roughly 216k (reservation about 280k).

     At 0.001 ETH per transaction, registerProject is reservable only while maxFeePerGas <= 1e15 / 908,947 = 1.10 gwei (viem returns about 1.2 x base fee + priority, so mainnet base fee below roughly 0.9 gwei; observed 0.095 gwei on 2026-10-12, about 10x headroom).

     Above that, prepare throws transaction_cost_limit / reserveGas throws chain_gas_exhausted and the job retries every 15 minutes until the module row expires after 24 h or the one-hour registration window closes (see the expired-job finding). Per project the minimum sequence deploy + register + queue + execute reserves about 1.48M gas, so 0.002 ETH needs an average fee <= 1.35 gwei; 8 x 0.002 = 0.016 > 0.015, so the global ceiling binds before the eighth project completes.

     Also note deployModule on chain 1 calls reserveProject before any transaction exists (src/chain-deployments/index.mjs:70) and public-chain-usage.mainnet.projects is never decremented, so a project whose deployment is refused for 24 h by the fee ceiling still consumes one of the 8 slots. These numbers are consistent with the stated 0.02 ETH exposure cap; they mean the window is usable only at sub-1 gwei fees and the plan should state that assumption.

     whole finding

     State: chain.mainnet.admission policy with maximumTransactionGasWei '1000000000000000'; stub mainnet client returning estimateGas 719158 for registerProject and maxFeePerGas 1200000000 (1.2 gwei).

     Input: executor deployment step for a chain-1 project-register job.

     Expected per the plan: the registration fits the per-transaction ceiling.

     Actual: reservation = (719158*125/100+10000) * 1200000000 = 1,090,736,400,000,000 wei > 1e15, reserveGas throws chain_gas_exhausted (or prepare throws transaction_cost_limit), runOne records waiting with a 15-minute retry; the project slot reserved by deployModule remains consumed.

     Numbers from cd contracts && forge test --gas-report (registerProject max 719158, queue max 95174, execute max 118036) and the padding formula at adapters/sepolia-transactions.mjs:63.

     whole reproduction

   • infoMainnet RPC URL must be https on the API host but not on the chain workers that sign and broadcastruntime/chain-worker.mjs:24

     runtime/readonly-ports.mjs:7-8 parses CLAUS_MAINNET_RPC_URL and requires url.protocol === 'https:' for the API process, but createChainWorker builds the mainnet client straight from the same variable with no scheme check.

     The worker is the process that signs approvals and broadcasts funded transactions based on what this RPC returns (chain id, code hashes, receipts, finalized block), so it is where a plaintext endpoint matters most: a network-path attacker could feed the executor a forged finalized receipt or code hash. Per-call getChainId checks still reject a wrong chain. Operator configuration only, so info.

     Fix: apply the same requireThat(new URL(url).protocol === 'https:', 'invalid_mainnet_rpc') in createChainWorker (or reuse readonlyPorts).

     Code inspection: with CLAUS_MAINNET_RPC_URL=http://rpc.example:8545 and a CLAUS_MAINNET_PRIVATE_KEY set, createChainWorker('executor') reaches line 24 and wires createChainRead({ chainId: 1 }) to a plaintext transport (no check between lines 23 and 28), while readonlyPorts() with the same variable throws invalid_mainnet_rpc at runtime/readonly-ports.mjs:8. Expected: the worker applies the same https requirement.

7. Onchain1 receipt, 5 scores queuedon Ethereum mainnet

   receipt

   work accepted · record queued

   scores

   5 scores for reviewed on submission · all 5 passed#900#1639#1212#528#1489