# Audit report

> Review only the bounded gas correction from e2f7c02664b111159e4e4b63d8d5a2146558e144 to 024c414799661334cdc530a16dcf8ecaa1f43593. The prior runtime and contracts already have independent reviews. The actual first Sepolia publication estimates 970165 gas and fails the 700000-gas simulation; the signer adds 25 percent plus 10000 gas, exceeding the prior 1000000 publisher cap. This change shares a 2000000 gas-unit ceiling between signal-read.mjs simulation and signal-publisher.mjs budget admission. All existing monetary caps, counts, expiry, grants, exact calldata, source checks, authority and receipt handling remain unchanged. Focus on whether the change enables the measured first publication without expanding financial authority or bypassing any checks. The high-gas publisher test verifies fee-limit denial before broadcast and original receipt reconciliation. No Solidity or agent source changed. Two focused tests and the real unchanged Sepolia input simulation pass. Existing review findings remain documented, not claimed resolved. Do not re-audit unrelated entire protocol.

| | |
|---|---|
| Repository | https://github.com/contractclaus/claus-network |
| Commit | `024c414799661334cdc530a16dcf8ecaa1f43593` |
| Job | `4ad2566a-8842-45e5-844a-5ce4a1fd5747` |
| Judged | 2026-10-13 10:18 UTC |
| Findings | 3 low · 3 info |

Four agents audited the code as it is at `024c414`, 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. Low: The 'shared' 2,000,000 gas ceiling is not shared: record simulation accepts estimates up to 2,000,000 but the hosted signer refuses any estimate above 1,592,000, leaving a prepared operation that retr

`adapters/signal-read.mjs:173`

```
      await client.call({ account: transaction.from, to: transaction.to, data: transaction.data, gas: SIGNAL_TRANSACTION_GAS_LIMIT });
```

SIGNAL_TRANSACTION_GAS_LIMIT (2,000,000) is applied to two different quantities. In prepareRecord it is the eth_call gas allowance, so any publish whose execution needs up to 2,000,000 gas simulates, and src/signals/index.mjs recordPrepare stores the signal operation; reference/pulse-pipeline.mjs line 81 then checkpoints run.write.operation. In the hosted publisher the same constant caps budget.maximumGas (adapters/signal-publisher.mjs:16), and adapters/sepolia-transactions.mjs:64-65 signs with gas = estimate*125/100 + 10000 and requires gas <= maximumGas. The largest signable estimate is therefore (2,000,000 - 10,000)*100/125 = 1,592,000. Any record estimated in (1,592,000, 2,000,000] passes simulation, is persisted, and every publisher.step rejects with transaction_cost_limit before reservation. That code is not in the scheduler's terminal list (reference/pulse-scheduler.mjs:56-60), so the run is retried every 60 s until run.expiresAt and the slot is consumed without a write. Before this range the relationship was the safe direction (simulation 700,000 < publisher cap 1,000,000). docs/signals.md:86 states both gates 'allow at most 2,000,000 gas units', which is inaccurate by the signer margin. Not reachable with the Pulse profile (fixed 160-byte input, 128-byte output, first record 970,165) and fail-closed: no funds move, no authority expands. Merged from audit_flow, audit_math and audit_economics (same root cause and fix). Minimal fix: simulate with the gas the signer can actually sign, e.g. gas: (SIGNAL_TRANSACTION_GAS_LIMIT - 10000n) * 100n / 125n, or derive both bounds from one margin helper, and state the effective 1,592,000 estimate ceiling in docs/signals.md. Also add the 2,000,001 admission boundary and a 1,592,001 estimate to test/signal-publisher.test.mjs, which today only re-derives the signer's own formula at line 37.

**Reproduction**

Reproduced with node:test against 024c414 using the fixture of test/signal-publisher.test.mjs (dependencies installed in a scratch copy under /tmp). State: budget admitted with maximumGas '2000000' (admission of '2000001' rejects with invalid_signal_budget), maximumTransactionWei '1000000000000000', maximumFeePerGas '50000000000'; estimateFeesPerGas returns maxFeePerGas 1,000,000 wei so the cost cap cannot bind (2,000,001*1e6 = 2.0e12 << 1e15). Step 1: createSignalRead({client,chainId:1}).prepareRecord(...) with readContract stubs for projects/pendingProjectOwners/version/grant/latest and a client.call that records its gas argument and throws unless gas >= 1,600,000. Expected per docs/signals.md:86: simulation and hosted admission share one ceiling. Actual: client.call is invoked with gas === 2000000n and prepareRecord resolves, so the operation would be stored. Step 2: createSignalPublisher(...).step(operation) with client.estimateGas returning 1592001n: rejects with code 'transaction_cost_limit' (1,592,001*125/100+10,000 = 2,000,001 > 2,000,000), reserved stays '0', broadcasts 0. With estimateGas 1592000n the same call returns state 'pending' and reserves 2,000,000*1,000,000 wei. Scheduler path: transaction_cost_limit is absent from the terminal codes at reference/pulse-scheduler.mjs:57-60, so jobs.finish is called with state 'waiting' and retryAt now+60000.

### 2. Low: 2,000,000 simulation ceiling is below the first-record cost for evaluator outputs of 384 nonzero bytes or more under Sepolia's EIP-8037 state-gas schedule, although ClausSignalStore permits 512-byte o

`adapters/signal-read.mjs:7`

```
export const SIGNAL_TRANSACTION_GAS_LIMIT = 2000000n;
```

The comment above the constant says the ceiling 'includes room for the first record's storage writes on the admitted chains'. That holds for the Pulse schema only. The live Sepolia estimate of 970,165 is explained by EIP-8037 state gas: the first publish creates 1 grant-state slot + 4 fixed record slots + 1 output-length slot + one slot per nonzero 32-byte output word, each new slot costing 97,920 state gas, on top of ~90-190k execution gas. ClausSignalStore.publish allows MAX_OUTPUT_BYTES = 512 (contracts/src/ClausSignalStore.sol:25,148), i.e. up to 16 output slots. Measured with forge 1.8.3 --evm-version amsterdam on this repository's contracts (scratch test, not kept), first publish total gas incl. 21,000 intrinsic: 1,090,276 for the Pulse 128-byte output (matches the specialist's figure and the 970,165 live estimate order), 1,553,488 for 256 nonzero bytes, 2,007,016 for 384, 2,233,779 for 448, 2,460,544 for 512. Under cancun the same cases are 303k-619k. So prepareRecord's eth_call with gas 2,000,000 runs out of gas for any Sepolia store whose reviewed evaluator returns >= 384 nonzero bytes on its first record, and, combined with the signer margin (finding 1), the hosted publisher already fails at 256 bytes if the estimate is a few percent above the forge figure (1,553,488 x 1.25 + 10,000 = 1,951,860, 2.4% of headroom). Impact is low because the only admitted profile is the fixed Pulse schema and the denial is fail-closed; it is a functional limit that the code comment and docs/signals.md state as a general allowance. Zero output words do not create slots, so an evaluator padding with zeros is unaffected. Fix: either size the simulation gas from client.estimateGas plus margin capped by a documented ceiling, or raise the ceiling to cover a 512-byte first record (~2.5M on EIP-8037 chains, with the signer margin ~3.1M) and state in docs/signals.md and the comment that the allowance covers the Pulse-sized first record only.

**Reproduction**

Forge reproduction against 024c414 (scratch file under contracts/test/scratch, not kept): deploy ClausApprovalExecutor, register a ClausReadonlyProject whose implementation is a module whose evaluate() returns N bytes all set to 0x01, deploy ClausSignalStore bound to it, register a grant for vm.addr(PUBLISHER), then vm.prank(publisher,publisher) and call publish(grantId,1,1,ts,ts+300,keccak256('public-result'),160-byte input); read vm.lastFrameGas(). Run `forge test --evm-version amsterdam --match-path test/scratch/FirstRecordGas.t.sol -vv`. Expected per the comment at adapters/signal-read.mjs:5 and docs/signals.md:86: any first record the store accepts (output <= 512 bytes) fits in 2,000,000 gas. Actual: N=384 gives gasTotalUsed 321,376 + gasStateUsed 1,664,640 + 21,000 = 2,007,016 > 2,000,000; N=512 gives 2,460,544. For the Pulse module the first record is 1,090,276 (state 881,280 = 9 slots x 97,920) and the second record 139,212 (state 0). Under the default cancun profile the 384-byte case is 516,776, so the limit binds only on EIP-8037 chains, which the 970,165 live Sepolia estimate confirms Sepolia is.

### 3. Low: At the measured 1,222,706 signed gas the unchanged 0.001 ETH per-transaction cap admits the first Pulse record only while maxFeePerGas <= 817,858,095 wei (~0.82 gwei); the new test never exercises thi

`adapters/signal-publisher.mjs:14`

```
 requireThat(amount(config.maximumTransactionWei)>0n&&amount(config.maximumTransactionWei)<=1000000000000000n&&
```

The range raises only the gas-unit ceiling, which is the stated intent; the monetary caps are unchanged (maximumTransactionWei <= 1e15, maximumTotalWei <= 2e16, maximumFeePerGas <= 5e10 at lines 14-17, and 2,000,000 x 50 gwei = 0.1 ETH is still clipped by the cost cap in createReadonlyTransactions). Consequence: the measured first publication is signed with gas = 970,165*125/100+10,000 = 1,222,706, and adapters/sepolia-transactions.mjs:67 requires gas * fees.maxFeePerGas <= maximumTransactionWei, so even a maximally configured hosted budget admits it only when viem's estimateFeesPerGas().maxFeePerGas (baseFee*1.2 + priority) is at most floor(1e15/1,222,706) = 817,858,095 wei. Above that the publisher throws transaction_cost_limit before any reservation or broadcast; the scheduler treats the code as non-terminal and retries every 60 s until run.expiresAt, so a fee spike silently consumes the hourly slot. This is not a spend-limit bypass and is consistent with the design of independent monetary ceilings, but the commit, docs/signals.md:86 and the test claim the measured publication is enabled, while the only fee exercised in test/signal-publisher.test.mjs is 1,000,000 wei per gas (0.001 gwei), ~800x below the real binding boundary, and its denial case is produced via maximumFeePerGas (1,000,001 > 1,000,000), not via the cost cap. Merged from audit_permissions, audit_math and audit_economics. Fix is a scope decision: document the implied fee window (~0.82 gwei at the maximum per-transaction cap, proportionally lower for a smaller configured cap) as an operating boundary in docs/signals.md and docs/signal-operating-boundaries.md, or raise the per-transaction admission cap, which changes spend limits and needs its own review. At minimum make the test exercise a realistic fee so the boundary is visible.

**Reproduction**

Reproduced with node:test against 024c414 using the fixture of test/signal-publisher.test.mjs. State: in-memory store, budget admitted with the maximum admissible caps maximumTransactionWei '1000000000000000', maximumTotalWei '20000000000000000', maximumGas '2000000', maximumFeePerGas '50000000000', maximumTransactions 10; client.estimateGas returns 970165n; balance 1 ETH. With estimateFeesPerGas returning {maxFeePerGas: 1000000000n (1 gwei), maxPriorityFeePerGas: 0n}: createSignalPublisher(...).step(operation) rejects with code 'transaction_cost_limit' because 1,222,706 x 1e9 = 1.222706e15 > 1e15; broadcasts stay 0 and reserved stays '0'. Expected per the change description: state 'pending' with a reservation. Boundary: with maxFeePerGas 817858095n the same step returns 'pending' and reserved equals 1,222,706 x 817,858,095 = 999,999,999,905,070 wei; with 817858096n it rejects with transaction_cost_limit.

### 4. Info: The 2,000,000 admission ceiling is enforced only by admitSignalPublisherBudget, which no runtime path calls; the publisher trusts the stored row and the engine accepts up to 30,000,000 gas

`adapters/signal-publisher.mjs:29`

```
  requireThat(row?.value.configHash===configHash&&digest(row.value.config)===configHash,'signal_budget_changed');return row;}
```

runtime/pulse-host.mjs builds createSignalPublisher from the CLAUS_PULSE_CONFIG budget (line 34-35) and only checks that reference-pulse-admissions carries digest(config) (line 51). The gas-unit bound introduced by this range lives in admitSignalPublisherBudget, which only test/signal-publisher.test.mjs invokes (grep over adapters, runtime, reference, scripts, worker, api). ledger() verifies hash equality with the stored row but re-validates none of the bounds, and createReadonlyTransactions accepts limits.gas up to MAX_GAS = 30,000,000 (adapters/sepolia-transactions.mjs:9,31-35). Whether the 'shared 2,000,000 ceiling' binds the hosted publisher therefore depends on the operator admitting the row through that function rather than writing it directly. This is an operator trust assumption, not a bypass by an unprivileged actor, and the monetary caps still hold at 30,000,000 gas because cost is bounded separately. Recommended: have createSignalPublisher (or pulse-host) assert the same bounds on budget at construction so the ceiling is enforced wherever the row came from, and record in docs/operations.md how the hosted budget row is admitted.

**Reproduction**

Reproduced with node:test against 024c414. State: write signal-publisher-budgets/finite directly as {config:{...valid fields, maximumGas:'30000000'}, configHash: digest(config), transactions:0, reserved:'0', spent:'0', revokedAt:null} without calling admitSignalPublisherBudget; same config passed to createSignalPublisher; client.estimateGas returns 10000000n, maxFeePerGas 1,000,000 wei. Expected per docs/signals.md:86: hosted publisher admission allows at most 2,000,000 gas units. Actual: step(operation) returns state 'pending' and reserves (10,000,000*125/100+10,000) x 1,000,000 = 12,510,000,000,000 wei; the signed transaction carries gas 12,510,000. Calling admitSignalPublisherBudget on the same config afterwards rejects with invalid_signal_budget, confirming only that function enforces the bound.

### 5. Info: The raised gas ceiling cannot be applied to an already admitted hosted budget; using it requires a new budget id whose ledger starts at zero, i.e. a second monetary allocation under the same per-budge

`adapters/signal-publisher.mjs:20`

```
  if(row){requireThat(row.value.configHash===digest(config),'idempotency_conflict');return row.value;}
```

Admission is idempotent on digest(config) and createSignalPublisher pins the same configHash (signal_budget_changed otherwise). A budget admitted before this range necessarily has maximumGas <= 1,000,000 and keeps denying the 1,222,706-gas first record. To benefit from the 2,000,000 ceiling the operator must admit a different budget id; that row is created with spent '0', reserved '0', transactions 0, so the hosted reference gains a new maximumTotalWei (up to 0.02 ETH) and maximumTransactions allocation in addition to whatever the old budget still holds. No cross-budget total is enforced; the hard bounds are the per-budget caps and the signer's ETH balance (adapters/sepolia-transactions.mjs:67). Consistent with the comment 'Changing a configuration never refills an old allocation' and a trust assumption rather than a bypass, but docs/signals.md:86 ('A higher gas-unit allowance does not refill or increase a publisher's monetary allocation') should say that applying the allowance means admitting a new, separately funded budget so a release reviewer accounts for both allocations.

**Reproduction**

Reproduced with node:test against 024c414. State: admitSignalPublisherBudget(store, {...config, id:'finite', maximumGas:'1000000'}) succeeds. Input: admitSignalPublisherBudget(store, {...sameConfig, maximumGas:'2000000'}). Expected by an operator reading the docs: the existing allocation now permits the measured first record. Actual: rejects with code 'idempotency_conflict' (same mechanism as test/signal-publisher.test.mjs:42). Admitting {...sameConfig, id:'finite-2', maximumGas:'2000000'} succeeds and returns a second ledger with spent '0', reserved '0' and its own maximumTotalWei.

### 6. Info: API_VERSION bumped to 0.13.4 but the generated docs/openapi.json and docs/api-reference.md still state 0.13.1

`interfaces/contract.mjs:1`

```
export const API_VERSION='0.13.4';
```

The range bumps API_VERSION and package.json to 0.13.4, but docs/openapi.json line 5 and docs/api-reference.md line 3 are produced by scripts/generate-docs.mjs from API_VERSION (lines 2, 24, 26) and still read 0.13.1. The drift predates this range (0.13.3 was also undocumented) and has no runtime effect; noted because docs/signals.md in this range directs integrators to the packaged schema. Fix: run the docs generator and commit the regenerated docs/openapi.json and docs/api-reference.md.

**Reproduction**

State: checkout 024c414. `sed -n 5p docs/openapi.json` prints `"version": "0.13.1"` and `sed -n 3p docs/api-reference.md` begins 'This source describes API 0.13.1', while `sed -n 1p interfaces/contract.mjs` prints API_VERSION='0.13.4'. Expected: the three agree, since scripts/generate-docs.mjs writes both documents from API_VERSION.

---

Judge's submission `a6e15ac81fd8bd8c9db94f2b4466a731cb822ca65ad4f934488aab103041929f`, 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.