# Audit report

> Independently assess only the 0.12.4 delta against baseline 2b31b6674677383e6d5bd2fb0a2e02e1a150ec8b in this repository. Reuse the original 0.12.3 report and submissions for job e340d6dd-adb4-44ef-b4de-fea90abf2620 at https://api.imd.fun/jobs/e340d6dd-adb4-44ef-b4de-fea90abf2620/submissions and report.md. Do not re-audit unrelated unchanged source. Evaluate remaining defects honestly; operator tests are not independent acceptance.
>
> Scope B remains finite sponsored reviews and noncustodial Sepolia readonly projects with real Claus decisions and bounded Inbox/callback delivery. C is preparation of the same readonly mainnet profile only, still requiring a separate exact human approval. Nothing authorizes deposits, token launches, public inference, new signer powers, automatic budget renewal or Mainnet activation. No Solidity or financial policy changes.
>
> The delta addresses all four distinct implementation findings plus historical RPC configuration:
> 1. Controller and executor require the operator to set CLAUS_SEPOLIA_RPC_URL to an archive endpoint, replacing the hardwired pruned provider. Intake can use the same endpoint. Mainnet retains its own CLAUS_MAINNET_RPC_URL and explicit archive prerequisite. Module-based history remains intentional so earlier direct relays can still be recovered. The operator tested real historical eth_getCode, eth_call returning the requested block number, and logs at 50,000 and 500,000 blocks depth on both https://gateway.tenderly.co/public/sepolia and https://sepolia.drpc.org with matching headers/results. This verifies sampled historical availability, not a permanent provider guarantee. Deployment must install the selected endpoint and verify current coverage. No unsafe fallback to latest state.
> 2. Empty registration pages that end before the selected executor existed no longer call projects() on missing code. The existing page transition check and definitive pre-module conflict remain. Regression walks an old module through a newer executor to its exact relay.
> 3. Binding target code is read at the registration receipt block and must be nonempty; a lagging/missing response remains retryable registration_state_unavailable instead of persisting an empty code hash.
> 4. Execution recovery uses a new execution:v2 cursor, preserving prior journals. Before advancing an empty page, a target version beyond proposal.fromVersion is treated as missing execution evidence, not cancellation. Finalized nonce and target-version checks use the same scan head. Real local Sepolia and chain1 runs first hide the genuine execution event and preserve the cursor, then recover the exact relayed execution even with an old skipped cursor present. Genuine owner cancellation is also checked.
> 5. Callback failures retain phase, resolutionFinalized and original transactionHash after a finalized resolve. Complete delivered/finalized remains distinct. A confirmed undelivered callback has an explicit reason. The hosted worker safely exposes the same bounded fields. No new callback attempt or budget rebinding.
>
> Existing one-attempt limits remain unchanged and are now explicit: a pause can cancel a prepared but unsent delivery; a lapsed selected allocation can terminate an untouched queued delivery. Later allocation does not automatically reopen terminal requests. The canonical API result remains readable; only the authorized dispatcher can resolve it into the Inbox, and anyone may deliver an already resolved callback. These are accepted bounded operational limits, not promised automatic recovery. Fairness, 16 lifetime registration intents, finite decision/gas limits and no replacement of uncertain transactions remain unchanged.
>
> Final source gate: 423 pass, 10 optional environment skips. Real local chain1 and Sepolia relay/missing-event/cancellation flows pass. Please give separate B and prepared-C conclusions, distinguishing code defects from required archive endpoint configuration and already documented bounded limits. A favorable result alone never authorizes Mainnet.

| | |
|---|---|
| Repository | https://github.com/contractclaus/claus-network |
| Commit | `a689ccff06648d9d979cbc661a4b3d03dac65bf4` |
| Job | `7d1c7153-8e83-40de-b701-cd268a94ecab` |
| Judged | 2026-10-12 18:47 UTC |
| Findings | 1 medium · 1 low · 2 info |

Four agents audited the code as it is at `a689ccf`, each in one area (math, permissions, economics, control flow),
and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the repository was changed or deployed.

## Findings

### 1. Medium: Execution recovery treats any target version above fromVersion as missing evidence, so a genuine owner cancellation after another valid approval upgraded the target is retried every 60 s forever and t

`adapters/chain-executor.mjs:250`

```
            requireThat(await versionAt(toBlock) <= BigInt(p.fromVersion), 'recovery_logs_inconsistent');
```

Delta item 4 adds two checks to execution recovery: validateEmpty (line 250) before an empty page is committed, and the finalized-head check (line 257) once the scan is complete. Both encode the invariant 'version(target) > proposal.fromVersion implies this approval executed, so a missing UpgradeExecuted log is lagging evidence'. That invariant only holds while this approval is the only thing that can raise the version. It is not: ClausApprovalExecutor.execute (contracts/src/ClausApprovalExecutor.sol:154-164) is permissionless after readyAt and accepts any unexpired Claus-signed approval whose fromVersion equals the current version, and cancelApproval (lines 176-182) consumes a nonce without touching the version. Two approvals for one project at the same fromVersion exist whenever an earlier queued proposal A0 became terminal in the database without being consumed onchain: its execute attempt reverted (state 'failed', line 217-218 returns terminal because the nonce is unconsumed) or its local validate failed with an authority-denied code such as proposal_stale, dependency_code_changed or executor_not_enabled (state 'blocked' via authority_or_window_closed, same lines). src/approvals/index.mjs:45 and :82 then allow a new proposal A1 at the same fromVersion, and A0's full Approval struct and Claus signature are public in the calldata of the worker's own queue() transaction. Sequence: A1 is signed and queued; anyone executes A0 (version 1 -> 2, UpgradeExecuted for A0's approvalHash); the owner calls cancelApproval(projectKey, A1.nonce). On A1's next tick line 235 sees executionNonces true, recoverChainEvent fetches the page for A1's approvalHash, it is legitimately empty, validateEmpty reads version 2 > 1 and throws recovery_logs_inconsistent before the cursor is written (adapters/chain-event-recovery.mjs:15 runs before the commit). If the page had already been committed, line 257 throws the same code at the finalized head. src/approvals/index.mjs:212 maps that code to state 'waiting' with a 60 s retry and no bound, so the same page is fetched on every tick forever. The chain-proposals row never becomes terminal, active-proposals keeps A1, and every approvals.create for the project fails with proposal_in_progress (lines 45, 82). jobs.cancel cannot clear it because the job's effect started when Claus queued A1 (src/jobs/index.mjs:50 requires effect not_started). The ApprovalCancelled(projectId, nonce) event that proves the cancellation is never consulted. Baseline 2b31b66 returned blocked/approval_cancelled here; the delta's own brief says genuine owner cancellation is checked, but it is checked only for the unchanged-version case. Impact: liveness and state accuracy only. No spend, custody, signing or authority effect; one project's upgrade path is locked until an operator edits the database, and the worker burns one RPC page per minute per stuck job. Preconditions need the project owner's own cancelApproval plus a permissionless relay of a stale approval, so it is not an outsider attack, but both actions are legitimate and documented. This is a code defect in the delta, not an archive-endpoint matter: it reproduces on a perfect archive RPC. Minimal fix that preserves the intended protection: when the nonce is consumed and the version exceeds fromVersion, query ApprovalCancelled with args {projectId} over the same finalized range and match the nonce (and/or UpgradeExecuted for the projectId without the approvalHash filter); a found ApprovalCancelled for this nonce is terminal approval_cancelled, a found UpgradeExecuted for another approvalHash explains the version step so the page may be committed, and only the absence of both remains recovery_logs_inconsistent. Merged from four specialist reports (audit_math, audit_economics, audit_flow, audit_permissions) describing the same mechanism at lines 250/257.

**Reproduction**

Worker level: test/scratch/judge-exec-cancel.test.mjs (node --test test/scratch/judge-exec-cancel.test.mjs). State: in-memory store with network-capabilities 'chain' enabled (profile claus-readonly-v1, chainId 11155111, executor 0xee..ee, approvalSigner = a generated key, executorPayer = signer); claus-signed-approvals 'proposal-A' holding a real EIP-712 Approval signature from that key over approvalMessage(p, evidenceHash) with p.fromVersion 1, nonce '12345'; chain-bindings 'project'; artifacts.get returns evidence.chain.blockNumber 100; no chain-transactions rows. Mock RPC: finalized head 200; getLogs always [] (no UpgradeExecuted for A's approvalHash); getCode '0x1234'; executionNonces true; target version() 1n below block 150 and 2n from 150 and at latest. Expected: execution.step returns {state:'blocked', error:'approval_cancelled'} (the control case in the same file, version fixed at 1n, returns exactly that on the first call). Actual on a689ccf: three consecutive execution.step calls reject with code 'recovery_logs_inconsistent', store.list('chain-event-recovery') stays [], getLogs is called with exactly ['UpgradeExecuted', 100n, 200n] on every call and never for 'ApprovalCancelled'. Contract level: test/scratch/JudgeStaleApproval.t.sol (cd contracts && FOUNDRY_TEST=../test/scratch forge test --match-path '*JudgeStaleApproval*'): on the real ClausApprovalExecutor two Claus-signed approvals with fromVersion 1 and nonces 1 and 2 are both queued; after 1 hour an arbitrary address executes the first (version becomes 2); the owner calls cancelApproval(ID, 2); executionNonces(ID, 2) is true, version stays 2, and execute of the second reverts InvalidApproval, so no UpgradeExecuted for its hash can ever exist. That is the exact chain state the worker mock encodes. Reachability of the stale approval: chain.validateProposal (adapters/chain-read.mjs:122-126) throws proposal_stale / dependency_code_changed, both in adapters/authorization.mjs authorityDenied, so a queued A0 whose dependency snapshot drifts before execute is returned as blocked at chain-executor.mjs:217-218 with its nonce unconsumed and its signature public.

### 2. Low: The intake signing host silently falls back to the pruned public Sepolia endpoint when CLAUS_SEPOLIA_RPC_URL is unset, although its event cursor and receipt-pinned Inbox reads need the same historical

`runtime/contract-intake-config.mjs:14`

```
  const rpcUrl = env.CLAUS_SEPOLIA_RPC_URL ?? 'https://ethereum-sepolia-rpc.publicnode.com';
```

Delta item 1 makes the controller and executor refuse to start without an explicit https CLAUS_SEPOLIA_RPC_URL (runtime/chain-worker.mjs:28-29, historical_rpc_required), and docs/operations.md (Historical RPC requirement section) states that the intake host 'uses the same Sepolia setting for its original event cursor' and that the endpoint must serve historical logs, eth_call and eth_getCode. The intake host does not enforce this: contractIntakePorts defaults to https://ethereum-sepolia-rpc.publicnode.com, and runtime/contract-intake-host.mjs:15 calls it with no further check, so a hosted intake deployment that omits the variable starts normally on the provider the 0.12.3 judge measured as pruned. The intake path is not latest-only: scan() (adapters/contract-intake.mjs:54-57) fetches Requested logs from pin.startBlock or the stored cursor forward, and observe() pins getCode, dispatcher() and requests(id) to each request's receipt block (lines 25-31, 91, 105). Measured today (2026-10-12, head 11,900,735) the default endpoint answers eth_getCode at block 11,880,702 (about 20,000 blocks deep) with error -32000 'historical state ... is not available' while the same call at 11,895,830 (about 5,000 deep) succeeds. So an intake host without the variable whose startBlock or cursor is more than roughly 10,000 blocks (about 1.4 days) behind head, or that ingests a Requested event that old, fails every tick: scan() or ingest() throws, runtime/contract-intake-worker.mjs records scanError and never saves the cursor, and no later request on that inbox is admitted until an operator notices. The hosted health row still reports state 'active', so contractIntakeHealth keeps answering public_readonly. This is a configuration-default defect in the delta (the requirement was enforced in one host and defaulted away in the other), not an archive-provider guarantee question and not a spend or authority issue. Fix: require CLAUS_SEPOLIA_RPC_URL with the same https check and historical_rpc_required code in contractIntakePorts, or at least in createHostedContractIntakeWorker, and drop the publicnode default; optionally map pruned-history RPC errors to a named scanError so the health row is diagnosable. Merged from four specialist reports (audit_math, audit_economics, audit_flow, audit_permissions).

**Reproduction**

test/scratch/judge-config.test.mjs, first two tests (node --test test/scratch/judge-config.test.mjs). Input: contractIntakePorts({ CLAUS_CONTRACT_INTAKE_PROFILE: JSON.stringify(validPin) }) with no CLAUS_SEPOLIA_RPC_URL. Expected: the same historical_rpc_required refusal that createChainWorker('executor', {}) gives (second test, passes). Actual: ports.enabled === true and ports.client.transport.url === 'https://ethereum-sepolia-rpc.publicnode.com'. Live boundary measured on 2026-10-12 at head 0xb5973f: curl -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x01a8d2e011dcb3fa65395e0343e1ab73d562b0f6","0xb548fe"]}' https://ethereum-sepolia-rpc.publicnode.com returns {"error":{"code":-32000,"message":"historical state 7fc5f85d... is not available"}}; the same call at 0xb58396 returns a result.

### 3. Info: A scheme-less CLAUS_SEPOLIA_RPC_URL escapes the new configuration guards as a Node TypeError (ERR_INVALID_URL) instead of the documented historical_rpc_required / invalid_sepolia_rpc codes

`runtime/chain-worker.mjs:29`

```
    new URL(env.CLAUS_SEPOLIA_RPC_URL).protocol === 'https:', 'historical_rpc_required');
```

The guard evaluates new URL(value) before comparing the protocol, so a value that is a string but not a parsable URL (for example 'sepolia.drpc.org' or 'gateway.tenderly.co/public/sepolia', plausible copy-paste forms of the two endpoints the operator tested) throws TypeError [ERR_INVALID_URL] out of createChainWorker rather than the 'historical_rpc_required' code that test/chain-recovery-guards.test.mjs asserts for the empty and http:// cases. The identical construction is at runtime/contract-intake-config.mjs:15 ('invalid_sepolia_rpc'). The worker still fails closed, so there is no safety impact; only release tooling or code matching on error.code sees an unexpected exception. Fix: guard with URL.canParse(value) && new URL(value).protocol === 'https:' so every malformed value yields the documented code. From audit_math, reproduced.

**Reproduction**

test/scratch/judge-config.test.mjs, third test. Input: createChainWorker('executor', { CLAUS_SEPOLIA_RPC_URL: 'sepolia.drpc.org' }) and contractIntakePorts({ CLAUS_CONTRACT_INTAKE_PROFILE: validPin, CLAUS_SEPOLIA_RPC_URL: 'sepolia.drpc.org' }). Expected: rejection with code 'historical_rpc_required' (respectively 'invalid_sepolia_rpc'). Actual: both throw TypeError: Invalid URL with code 'ERR_INVALID_URL'.

### 4. Info: Required archive coverage is neither probed nor diagnosed by the code: a pruned or lagging endpoint produces an unbounded 60-second retry loop whose only trace is a raw numeric RPC error code in the j

`src/chain-deployments/index.mjs:190`

```
          result: { error: error.code ?? 'chain_execution_unavailable' } });
```

Classification note for the B and prepared-C conclusions, not a delta defect. 0.12.4 resolves the prior Finding 1 by configuration: the chain hosts require an https CLAUS_SEPOLIA_RPC_URL and docs/operations.md tells the operator to verify historical eth_getLogs, eth_call and eth_getCode coverage before activation. The code checks only the URL scheme. It does not probe historical coverage at startup and does not map provider pruning errors (code 4444 'pruned history unavailable' or -32000 'historical state ... is not available') to a named state. Such errors fall through to this line (and src/approvals/index.mjs:212 for executions), are stored as result.error 4444 / -32000, and retry every 60 s with no bound while worker-health shows 'waiting'. Every receipt-pinned and page-end read added by 0.12.3 and 0.12.4 (projects()/getCode at relay receipt and page ends, version()/executionNonces at page ends and the finalized head, target code at the registration receipt) therefore depends entirely on the operator's endpoint selection. The operator's sampled checks at 50,000 and 500,000 blocks depth on two providers show availability on the day of the test, not a guarantee, exactly as the brief says. The same applies to the prepared-C CLAUS_MAINNET_RPC_URL prerequisite. This is an accepted operational prerequisite; it is recorded so the acceptance conclusion is read with it. Optional hardening: at worker start, read executor code and one projects() value at the oldest retained module receipt block and refuse to start with a coded error on failure; map 4444/-32000 to a named job error so a misconfigured endpoint is visible in worker-health. From audit_permissions, reproduced.

**Reproduction**

test/scratch/judge-pruned-rpc.test.mjs (node --test test/scratch/judge-pruned-rpc.test.mjs). State: registration job for a module with receipt block 80, head 30,000, mock RPC that throws Error code 4444 for any getLogs/getCode/readContract request below head-10,000. Expected: a diagnosable coded state naming the endpoint problem. Actual: three consecutive deployment.step calls reject with code 4444 and chain-event-recovery stays empty; the runner at this line is outside its blocked list for that code, so it records { state: 'waiting', retryAt: now()+60000, result: { error: 4444 } } and re-queues indefinitely.

---

Judge's submission `87a0fc814de3fe54507e120310525dc39e35b974d94d199e28ad4bc70983ee4c`, accepted on the IdentityMD network. Acceptance means the report met the job's checks;
it is not a guarantee that the code has no other defects.