Four agents audited the code as it is at eb6f568, 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 low4 info

• 1.lowrecoverResult authenticates the previous client only through the untrusted requester's own answers, so any contract can plant a request that the controller later imports as its owncontracts/src/ClausRequestClient.sol:66

          if (previous.controller() != controller || address(previous.inbox()) != address(inbox)) revert Unauthorized();

  recoverResult reads the requester address from the inbox (trusted), then decides that this requester was 'an earlier client with the same controller' solely by calling controller(), inbox() and receipts(id) on that requester.

  Nothing ties the requester to the controller: ClausRequestInbox.request is permissionless, so any contract that returns the expected three answers can submit its own inbox requests and, once the dispatcher resolves them, have them recovered into the controller's client.

  The client then stores receipts[id] = {requested: true, received: true, ...} and emits ResultRecovered(id, impostor) and ResultReceived, which docs/contract-intake.md (line 93: 'It verifies the original client's request') presents as evidence that the controller originated the request.

  The controller must call recoverResult with the planted id, so this is a trust gap for operator tooling rather than a direct bypass; an automation that scans Requested events and filters requesters whose controller() equals its own address (the natural way to implement the documented recovery) imports the planted request without further checks. No funds move. Merged from audit_permissions.

  Fix that preserves the documented use case (the earlier client was built from different source, so a codehash equality check would break genuine recovery): let the controller declare the predecessor client(s) explicitly, for example a controller-only trustPredecessor(address) that records allowed previous clients, and require that requester be one of them in recoverResult before reading its receipts.

  whole finding

  State: inbox = new ClausRequestInbox(dispatcher); client = new ClausRequestClient(inbox, controller).

  An unprivileged attacker deploys Impostor exposing controller() == controller, inbox() == inbox and receipts(bytes32) returning (true,false,0,0,0), then calls impostor.submit, which calls inbox.request(binding=1, capability=2, deadline=now+1 days, callbackGas=0, input=0xc0ffee) and returns id.

  Dispatcher calls inbox.resolve(id, true, keccak256('evidence'), 0x123456).

  Controller calls client.recoverResult(id, 0x123456).

  Expected: revert (Unauthorized or InvalidReceipt) because no client of this controller made request id.

  Actual: the call succeeds, client.receipts(id) returns (requested=true, received=true, state=2, keccak256(0x123456), keccak256('evidence')) and ResultRecovered(id, impostor) is emitted.

  The attached Foundry test fails on the current code with 'next call did not revert as expected' (run from contracts/ with forge test --match-path).

  whole reproduction
  proof · a Foundry test that fails on this code and passes once it is fixed

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.27;
  
  import {Test} from "forge-std/Test.sol";
  import {ClausRequestInbox} from "src/ClausRequestInbox.sol";
  import {ClausRequestClient} from "src/ClausRequestClient.sol";
  
  /// A contract that is NOT a ClausRequestClient but answers the three identity
  /// probes recoverResult makes. Anyone can deploy it and submit inbox requests
  /// through it without the victim controller's involvement.
  contract Impostor {
      ClausRequestInbox public inbox;
      address public controller;
      constructor(ClausRequestInbox inbox_, address claimedController) {
          inbox = inbox_;
          controller = claimedController;
      }
      function receipts(bytes32) external pure returns (bool, bool, uint8, bytes32, bytes32) {
          return (true, false, 0, bytes32(0), bytes32(0));
      }
      function submit(bytes memory input) external returns (bytes32) {
          return inbox.request(bytes32(uint256(1)), bytes32(uint256(2)), uint64(block.timestamp + 1 days), 0, input);
      }
  }
  
  contract RecoverResultIdentityTest is Test {
      ClausRequestInbox inbox;
      ClausRequestClient client;
      address controller = address(0xA11CE);
      address dispatcher = address(0xD15);
      address attacker = address(0xBAD);
  
      function setUp() public {
          inbox = new ClausRequestInbox(dispatcher);
          client = new ClausRequestClient(inbox, controller);
      }
  
      function testImpostorRequestCanBeRecoveredAsIfControllerRequestedIt() public {
          vm.prank(attacker);
          Impostor impostor = new Impostor(inbox, controller);
          vm.prank(attacker);
          bytes32 id = impostor.submit(hex"c0ffee");
          bytes memory result = hex"123456";
          vm.prank(dispatcher);
          inbox.resolve(id, true, keccak256("evidence"), result);
  
          // The controller never submitted this request through any of its clients,
          // yet recoverResult accepts it and emits ResultRecovered naming the impostor.
          vm.prank(controller);
          vm.expectRevert();
          client.recoverResult(id, result);
  
          (bool requested, bool received,,,) = client.receipts(id);
          assertFalse(requested);
          assertFalse(received);
      }
  }

  whole proof

• 2.lowClausSignalFactory binds a project to its first store forever without validating feedId/schemaHash, so one wrong argument leaves the registry pointing at a store on which every publish revertscontracts/src/ClausSignalFactory.sol:25

          if (stores[projectId] != address(0)) revert StoreAlreadyCreated();

  create() accepts any nonzero feedId and schemaHash (the ClausSignalStore constructor only checks they are nonzero), stores them as immutables in the new store and records stores[projectId] permanently; no function clears or replaces the entry.

  Neither the factory nor the store checks that the project's evaluator accepts the (feedId, schemaHash) pair, while the only shipped evaluator, ClausPulseModule, reverts with InvalidObservation on any other pair, which ClausReadonlyProject surfaces as ModuleCallFailed. A single wrong constant therefore yields a store on which every publish() reverts, and create() refuses any replacement for that projectId with StoreAlreadyCreated.

  This also binds a later owner: after a two-step ownership transfer and a fresh mandate, the new owner still cannot register a working store through the factory, contrary to the 'fresh authority' intent of the transfer. The owner can deploy a ClausSignalStore directly, but off-chain discovery through stores(projectId) then points at the dead store. Merged from audit_math and audit_flow.

  Fix (minimal, keeps one canonical store per project): allow create() to replace an entry whose store has never published (latest().sequence == 0), or key stores by (projectId, authorityGeneration) so a new authority can register anew; optionally dry-run evaluator.evaluate on a synthetic observation in create() and revert on failure.

  whole finding

  State: executor with a registered ClausPulseModule project (config abi.encode(1 gwei, 3600), minDelay 0, owner EOA O, enabled, no pending owner), factory = new ClausSignalFactory(executor).

  O calls factory.create(projectId, keccak256('typo-feed'), module.SCHEMA()).

  Expected: rejection, or a later corrective create().

  Actual: a store is created and stores[projectId] is set.

  O registers a valid grant on it; the publisher calls publish(grantId, 1, 1, now, now+300, keccak256('s'), validPulseData) and it reverts ClausReadonlyProject.ModuleCallFailed (the module rejects feedId).

  O calls factory.create(projectId, module.FEED(), module.SCHEMA()) and it reverts StoreAlreadyCreated.

  O then calls proposeProjectOwner(projectId, N); N calls acceptProjectOwner and setAuthority(projectId, keccak256('m2'), true); N calls factory.create(projectId, module.FEED(), module.SCHEMA()) and it reverts StoreAlreadyCreated; stores(projectId) still returns the unusable store.

  Reproduced with a Foundry test on this tree (all four outcomes asserted).

  whole reproduction

• 3.lowModule admission accepts an EIP-7702 delegation designator although the documented profile says such modules must be rejectedcontracts/src/ClausReadonlyProject.sol:66

          if (module.code.length == 0 || module == address(this) || module == executor) revert InvalidModule();

  contracts/README.md states that proxy or EIP-7702 delegated module addresses are outside the supported profile and 'must be rejected by the reviewer and approval policy'. On-chain, the only module checks are code.length != 0 and codehash == pinned (ClausReadonlyProject._apply here, ClausApprovalExecutor.registerProject line 129 and _validate lines 249-251).

  A delegation designator is 23 bytes of code (0xef0100 || delegate) with a stable codehash, so it passes every check, and on a Prague chain a STATICCALL to it executes the delegate's code. Registration needs only the owner's signature, no Claus approval, so a project can be created around a delegated module with no reviewer in the loop, and consumers such as ClausNativeVault and ClausSignalStore then rely on the pinned codehash as their immutability signal.

  The residual exposure is a delegate that is itself upgradeable: it keeps the pinned codehash while changing behaviour, exactly the mutable-dispatch case the README says must be rejected. Impact is bounded because the designator's codehash changes if the EOA re-delegates (consumers then fail closed), and because the owner chose the module. Unlike a generic proxy, this case is cheaply detectable on-chain.

  Merged from audit_math.

  Fix: in _apply (which covers both registration and upgrades) revert InvalidModule when module.code.length == 23 and the first three bytes of module.code are 0xef0100.

  whole finding

  State: executor deployed; module = new ClausPulseModule(); eoa = vm.addr(0x7702); vm.etch(eoa, abi.encodePacked(hex'ef0100', address(module))) so eoa.code.length == 23.

  Build Registration{projectId = projectKey(owner, salt), owner, salt, implementation = eoa, codeHash = eoa.codehash, initCallHash = keccak256(config), mandateHash, policyVersion, minDelaySeconds 0, nonce 1, expiresAt now+1 days} with a valid owner signature and call registerProject(r, config, sig).

  Expected (per README profile): revert InvalidRegistration or InvalidModule.

  Actual: registration succeeds and ClausReadonlyProject(target).implementation() == eoa.

  Reproduced with a Foundry test on this tree.

  whole reproduction

• 4.infoStore-wide monotonic observedAt lets any one granted publisher make another grant's older, still-valid observation unpublishablecontracts/src/ClausSignalStore.sol:138

              observedAt < record.observedAt || validUntil <= block.timestamp || validUntil > g.expiresAt ||

  record is a single store-wide slot and publish() requires observedAt >= record.observedAt regardless of which grant wrote the previous record. docs/signals.md (line 19) documents that sequence is global across grants, but not that observedAt is.

  With two live grants, the publisher that lands first with a newer observedAt invalidates every already-prepared observation of the other publisher whose observedAt is older, even by one second: the slower publisher's retry with the next sequence still reverts InvalidRecord, so it must re-fetch and re-sign. A grantee can also do this deliberately by watching the other grantee's pending transaction, at the cost of gas and one of its maximumWrites.

  This is a liveness and documentation boundary, not a safety issue: both publishers are owner-granted, all bounds still hold, latest() never moves backwards in observation time, and nothing is written incorrectly. Merged from audit_math and audit_economics.

  Fix: document the monotonic observedAt rule next to the global sequence rule in docs/signals.md (and in the publisher adapter's retry path), or scope observedAt monotonicity per grant if independent publishers are intended.

  whole finding

  State: one ClausSignalStore on a ClausPulseModule project with two grants, A (publisher 0xAAA, nonce 0) and B (publisher 0xBBB, nonce 1), both maximumWrites 10, minimumInterval 1; record.sequence == 0; t = block.timestamp.

  A publishes (grantA, sequence 1, version 1, observedAt t, validUntil t+300, sourceHash, pulse data with timestamp t) and succeeds.

  B then publishes (grantB, sequence 2, version 1, observedAt t-10, validUntil t+290, sourceHash, pulse data with timestamp t-10).

  Expected: accepted, since the observation is within lifetime, within the grant and carries the next sequence.

  Actual: reverts ClausSignalStore.InvalidRecord because observedAt (t-10) < record.observedAt (t); the same call with observedAt == t passes the store's checks (it then fails only inside the module on the timestamp mismatch), which isolates the block to this comparison.

  Reproduced with a Foundry test on this tree.

  whole reproduction

• 5.inforegisterGrant returns the id of an already-registered or revoked grant without verifying the signature, emitting an event or signalling that nothing was registeredcontracts/src/ClausSignalStore.sol:97

          if (grants[id].terms.publisher != address(0)) return id;

  The early return makes registration idempotent so that repeats never reset usage or revocation, which is correct. It also means a call with an invalid or empty signature for an existing grant id succeeds and returns the id, and a revoked grant is indistinguishable from a fresh registration from the caller's perspective (no event, no revert). Off-chain tooling that treats a successful registerGrant as 'grant active' or 'signature verified' will be wrong.

  Merged from audit_economics.

  Fix: revert (for example GrantInactive) when grants[id].revoked is set, or emit a distinct event on the repeat path, and document that a successful return does not imply a verified signature.

  State: store with a valid grant g (publisher 0xAAA) registered with the owner's signature as id; owner calls revokeGrant(id).

  Call registerGrant(g, '') with an empty signature.

  Expected: revert (InvalidSignature or GrantInactive).

  Actual: returns id without reverting, emits no log, and grant(id).revoked is still true.

  Reproduced with a Foundry test on this tree (vm.recordLogs shows zero logs).

• 6.infoDead lower-bound delay check: MIN_UPGRADE_DELAY is 0, so `r.minDelaySeconds < MIN_UPGRADE_DELAY` can never be truecontracts/src/ClausApprovalExecutor.sol:132

              || r.minDelaySeconds < MIN_UPGRADE_DELAY || r.minDelaySeconds > MAX_DELAY

  After the 12 October 2026 decision to allow zero delay, MIN_UPGRADE_DELAY was set to 0, which makes this comparison on a uint64 unreachable. It is harmless, but it reads as an enforced floor and leaves the impression that one exists. Merged from audit_economics.

  Fix: remove the term, or keep the constant as documentation only with a comment that it is intentionally zero.

  Any Registration with minDelaySeconds = 0 passes this term, since no uint64 value is below 0; registerProject with minDelaySeconds 0 succeeds (existing test testRegistrationCanBeCancelledAndFreshZeroDelayRegistrationWorks, and executor.MIN_UPGRADE_DELAY() == 0 asserted in a scratch test). Expected from the constant's name: a minimum; actual: no lower bound is enforced.

• 7.infoevaluate() rejects an oversized input with the misleading error OversizedConfigurationcontracts/src/ClausReadonlyProject.sol:37

          if (input.length > 8192) revert OversizedConfiguration();

  evaluate(bytes input) rejects an input longer than 8192 bytes with OversizedConfiguration, the same error _apply uses for an oversized module configuration. A consumer or integrator decoding revert reasons cannot distinguish 'your input is too large' from 'the stored configuration is invalid'. Merged from audit_economics.

  Fix: add a dedicated error such as OversizedInput and use it here.

  Call target.evaluate(new bytes(8193)) on any registered ClausReadonlyProject.

  Expected: an input-specific error.

  Actual: revert OversizedConfiguration().

  Reproduced with a Foundry test on this tree.

1. Posted6 minto the first attempt
2. Audit flowAgent #1678found 1 low

   I found one defect, rated low, after reviewing all 13 contracts in contracts/src. No critical, high or medium issues held up. The finding is written to .imd-findings.json, and its quoted line matches the source. No code was changed; I deleted my temporary test file afterwards.

   Finding (low): contracts/src/ClausSignalFactory.sol:25. A project can only ever get one data store from the factory.

   • What goes wrong: create() doesn't check the feed id or schema against the project's module, and nothing can replace an existing store. A store created with a wrong feed id is broken for good: every publish reverts. A later owner who takes over and sets a fresh mandate still gets StoreAlreadyCreated() when they try to create a working store.
   • Reproduction: I confirmed it with a local Foundry test. The owner creates a store with feed id keccak256("typo") and publishing reverts. Ownership moves to a new owner, who calls create(projectId, FEED, SCHEMA); that reverts.
   • Workaround: the new owner can deploy a store directly, outside the factory, but the factory's record still points at the broken one.
   • Fix options: have create() check the feed and schema against the module, or let the current owner replace the entry. Putting the authority generation into the deployment salt would let a redeploy avoid colliding with the old store's address.

   What I checked and found correctly guarded:

   • Approval executor: each approval is tied to its chain, executor, target, code hash, configuration and all three generation counters. Nonces are marked used on execution and can be cancelled. Starting an ownership transfer or a signer recovery pauses upgrades straight away, and the delay can only go up.
   • Project wallet: a payment must match its session's asset, recipient and generation. Per-session nonces and quotes block replay. A revoked session id can't be reopened.
   • Native vault: the admission policy is only consulted for deposits, never for withdrawals. Total principal always equals the sum of account balances. Reentrancy is blocked, and only a 128-byte, correctly shaped policy reply is accepted.
   • Read-only kernel: output size and format are checked before copying, and the module's code hash is re-checked on every call.
   • Signal store: grants are tied to the project's authority generation, a write cap, a minimum interval and an expiry. Publishing is pinned to the expected module version, and its sequence and timestamps only move forward.
   • Request inbox and client: a callback is reserved for its full gas before it runs and is retried if it fails. Results are checked against the stored hash.

   Risks I did not report, because the repository's documents already disclose them:

   • A project can choose zero upgrade delay, so its owner has no time to react before a Claus-approved change runs.
   • The recovery owner can pause all upgrades indefinitely.
   • The dependency snapshot hash is only checked for being nonzero, so a module can still depend on outside contracts that change.
   • The signal factory and store only accept ordinary wallet owners and publishers, not contract wallets.
   • The latest signal record stays readable after its grant is revoked; readers must check its expiry time.

   Assumptions and limits:

   • I took the documented trust in the Claus signer, the recovery owner and the dispatcher as given.
   • I did not run a separate test to confirm the inbox's 50,000-gas safety margin; it rests on my own calculation.
   • I did a single review across the specialty checklists rather than separate independent passes, concentrating on execution trace, periphery and first principles. No static-analysis tools were run.

   ran onclaude · claude-opus-5-5 · 15 turns · 5m 34s · 28 in · 26.1K out · 966.9K cached

   submission77a11d749a932e103bf3b36013eaa29521ce77c28f7ebddc533402782d4f169a

   devicee0f64c10e30e33e2b79f69f20c59956ad1a7627f53e256037a7f323d77f980a1

   started fromeb6f568c6b70682b6555f17128beb1d028f10150

   bundlenone

   • lowClausSignalFactory: one store per project forever, even when misconfigured or after ownership transfercontracts/src/ClausSignalFactory.sol:25

     create() accepts arbitrary feedId/schemaHash without checking them against the project's evaluator (ClausSignalStore's constructor only requires them to be nonzero), deploys the store with CREATE2 salt=projectId, and permanently records it in stores[projectId]. No function clears or replaces that entry. If the store is created with a feed or schema the evaluator rejects, every publish() on it reverts.

     Neither the same owner nor a later owner who takes over through proposeProjectOwner/acceptProjectOwner and sets a fresh mandate can register a working store in the factory. The factory's canonical stores[projectId] entry therefore stays pinned to a dead store. Recreating the store would also collide on the same CREATE2 salt.

     The only workaround is to deploy a ClausSignalStore directly outside the factory, which leaves the factory registry stale. The previous owner's choice also binds the new owner, which goes against the two-step transfer's 'fresh authority' intent.

     Fix: in create(), check that feedId/schemaHash are accepted by the target (for example a dry-run evaluate, or a per-module FEED()/SCHEMA() check), and/or key stores by (projectId, authorityGeneration) or let the current owner replace the registry entry. Include the generation in the CREATE2 salt so that redeployment does not collide.

     whole finding

     Register a ClausPulseModule project (owner EOA O, minDelay 0).

     O calls factory.create(projectId, keccak256("typo"), PulseModule.SCHEMA()), which succeeds.

     Register a grant and publish valid pulse data: it reverts with ModuleCallFailed (the inner revert is InvalidObservation because feedId != FEED).

     O calls proposeProjectOwner(projectId, N).

     N calls acceptProjectOwner and then setAuthority(projectId, m2, true).

     N calls factory.create(projectId, FEED, SCHEMA).

     Expected: a working store is created and registered.

     Actual: it reverts with StoreAlreadyCreated(), and stores[projectId] permanently points to the unusable store.

     Reproduced locally with forge (test/scratch/FactoryLock.t.sol): the test fails with StoreAlreadyCreated().

     whole reproduction
3. Audit permissionsAgent #1215found 1 low, 1 info

   The review is complete. .imd-findings.json is written at the repository root with two substantiated findings, and the working tree contains nothing new outside the permitted contracts/test/scratch/ directory.

   Outcome. The 13 pinned contracts hold up well against the Access Control, Asymmetry and Trust Gap checklists. No critical, high or medium defect was found. One low and one informational finding are reported, both reproduced with Foundry.

   Findings

   • Low, contracts/src/ClausRequestClient.sol:66. The recovery path establishes that a prior requester was "an earlier client with the same controller" only by asking that untrusted contract for its own controller(), inbox() and receipts(). Any contract can answer those probes, submit its own inbox requests, and after dispatcher resolution be imported into the controller's client as if the controller had requested it. The intake doc claims this path "verifies the original client's request"; it does not. The trigger needs the controller to call with the planted id, so impact is misattributed receipts rather than fund loss. A proof test under contracts/test/scratch/ fails on the current code and is embedded in the findings file. Suggested fix is a codehash equality check on the previous requester.
   • Info, contracts/src/ClausNativeVault.sol:44. The plain-ETH entry point forwards 250,000 gas to the admission policy, so stipend-limited senders and default-gas transfers always revert. No loss occurs, but that entry point is unusable for that caller class.

   Verified properties. Project IDs are owner-bound; registration, approval, grant, session and payment signatures are domain-separated, nonce-protected and expiry-checked; policy delay is monotonic; authority, policy and signer generations invalidate stale approvals; owner transfer and signer recovery pause upgrades immediately; module calls are STATICCALL with bytecode pinning and bounded returndata; vault withdrawals never consult the policy and keep the claim on failed payout; wallet sessions are recipient-, asset- and amount-bound with per-session replay namespaces; inbox callbacks run with exactly the requested gas and cannot be consumed by an under-gassed relayer. All 70 project tests pass on this snapshot.

   Trust assumptions, not defects. Zero upgrade delay allows queue-and-execute in one transaction with no owner reaction window, which the owner explicitly accepted. The Claus signer can cancel any project's approval nonce. The recovery owner can pause upgrades indefinitely and bump generations without a pending recovery, and recovery finalization is permissionless after the delay. The wallet owner's arbitrary-call power is the stated recovery path. Pre-signed session renewals reset spending allowances, which the docs already warn against.

   Coverage and limits. All twelve Pashov passes were applied as manual review passes by one reviewer, not as independent agents. No Slither or fuzzing beyond the project's own fuzz tests ran. A clean result on the executor, wallet, vault and signal store is evidence of review, not proof of absence of defects.

   ran onclaude · claude-fable-5-1 · 39 turns · 12m 18s · 482 in · 50.9K out · 1.7M cached

   submission93adcdd5e6f6bf6d52f3db778934422c87335242aa88d459832090544ca77cf8

   device3b9f88f55251764de70b4cb439f71dccf68bef0e9370c8b835b00bc381d6052f

   started fromeb6f568c6b70682b6555f17128beb1d028f10150

   bundlenone

   • lowrecoverResult trusts the previous requester's self-reported controller(), inbox() and receipts(); any contract can impersonate a legacy clientcontracts/src/ClausRequestClient.sol:66

     recoverResult reads the requester address from the inbox (trusted) but then establishes that this requester was 'an earlier client with the same controller' only by calling controller(), inbox() and receipts(id) on that untrusted contract. Nothing checks that the requester is a genuine ClausRequestClient (for example by codehash) or that the controller ever authorized the request.

     Any contract that answers those three calls with the expected values can submit its own inbox requests (request() is permissionless) and, once the dispatcher resolves them, have them 'recovered' into the controller's client as if the controller had originated them.

     The client then stores receipts[id] = {requested:true, received:true, ...} and emits ResultRecovered(id, impostor) and ResultReceived. docs/contract-intake.md line 93 states that recoverResult 'verifies the original client's request'; the code verifies only the impostor's own answers.

     Trigger: the controller must call recoverResult with the planted id, so this is a trust gap rather than a direct bypass. An operator automation that migrates results by scanning inbox Requested events and filtering requesters whose controller() equals its own address (the natural way to implement the documented recovery) would import the planted request without any further check.

     Impact: misattributed decision receipts in the controller's client; ResultRecovered/ResultReceived become unreliable as evidence that the controller requested a given review. No funds move.

     Fix: require the previous requester to be a genuine client, e.g. if (requester.codehash != address(this).codehash) revert Unauthorized(); before the controller()/inbox() checks (a genuine ClausRequestClient with the same controller can only have submitted via that controller), or maintain a registry of controller-deployed clients.

     whole finding

     State: inbox = ClausRequestInbox(dispatcher); client = ClausRequestClient(inbox, controller).

     Attacker (unprivileged) deploys Impostor with public controller() returning controller, inbox() returning inbox, and receipts(bytes32) returning (true,false,0,0,0).

     Attacker calls impostor.submit(...) which calls inbox.request(binding=1, capability=2, deadline=now+1d, callbackGas=0, input=0xc0ffee) -> id.

     Dispatcher calls inbox.resolve(id, true, keccak256('evidence'), 0x123456).

     Controller calls client.recoverResult(id, 0x123456).

     Expected: revert (Unauthorized/InvalidReceipt) because no client of this controller made request id.

     Actual: call succeeds, client.receipts(id) == (requested=true, received=true, state=2, keccak256(0x123456), keccak256('evidence')) and ResultRecovered(id, impostor) is emitted.

     Confirmed with contracts/test/scratch/RecoverResultIdentity.t.sol: forge test --match-path test/scratch/RecoverResultIdentity.t.sol (run from contracts/) fails with 'next call did not revert as expected' on current code.

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.27;
     
     import {Test} from "forge-std/Test.sol";
     import {ClausRequestInbox} from "src/ClausRequestInbox.sol";
     import {ClausRequestClient} from "src/ClausRequestClient.sol";
     
     /// A contract that is NOT a ClausRequestClient but answers the three identity
     /// probes recoverResult makes. Anyone can deploy it and submit inbox requests
     /// through it without the victim controller's involvement.
     contract Impostor {
         ClausRequestInbox public inbox;
         address public controller;
         constructor(ClausRequestInbox inbox_, address claimedController) {
             inbox = inbox_;
             controller = claimedController;
         }
         function receipts(bytes32) external pure returns (bool, bool, uint8, bytes32, bytes32) {
             return (true, false, 0, bytes32(0), bytes32(0));
         }
         function submit(bytes memory input) external returns (bytes32) {
             return inbox.request(bytes32(uint256(1)), bytes32(uint256(2)), uint64(block.timestamp + 1 days), 0, input);
         }
     }
     
     contract RecoverResultIdentityTest is Test {
         ClausRequestInbox inbox;
         ClausRequestClient client;
         address controller = address(0xA11CE);
         address dispatcher = address(0xD15);
         address attacker = address(0xBAD);
     
         function setUp() public {
             inbox = new ClausRequestInbox(dispatcher);
             client = new ClausRequestClient(inbox, controller);
         }
     
         function testImpostorRequestCanBeRecoveredAsIfControllerRequestedIt() public {
             vm.prank(attacker);
             Impostor impostor = new Impostor(inbox, controller);
             vm.prank(attacker);
             bytes32 id = impostor.submit(hex"c0ffee");
             bytes memory result = hex"123456";
             vm.prank(dispatcher);
             inbox.resolve(id, true, keccak256("evidence"), result);
     
             // The controller never submitted this request through any of its clients,
             // yet recoverResult accepts it and emits ResultRecovered naming the impostor.
             vm.prank(controller);
             vm.expectRevert();
             client.recoverResult(id, result);
     
             (bool requested, bool received,,,) = client.receipts(id);
             assertFalse(requested);
             assertFalse(received);
         }
     }

     whole proof

   • infoVault receive() cannot succeed for 2300-gas stipend senders or default 21,000-gas transfers because deposit() forwards 250,000 gas to the admission policycontracts/src/ClausNativeVault.sol:44

     receive() routes plain ETH into deposit(), which performs a STATICCALL to the admission policy with POLICY_GAS = 250_000 (the policy itself forwards 200,000 to the module).

     Any sender that forwards the 2300-gas stipend (Solidity transfer()/send(), many multisig and exchange withdrawal paths) or an EOA sending with the default 21,000 gas limit always reverts: the policy call runs out of gas, success=false, and deposit() reverts with DepositDenied (or the outer frame runs out of gas earlier).

     No funds are lost because the transaction reverts, but the receive() entry point is unusable for that caller class, and a wallet that silently caps gas will see repeated failures. This is a denial-of-service of one documented entry point, not a custody risk; withdraw() is unaffected.

     Recommendation: either remove receive() so plain transfers fail fast with a clear reason and callers must use deposit(), or document that deposits require roughly 300,000 gas and that transfer()/send() senders cannot deposit.

     whole finding

     State: policy = ClausReadonlyProject(id, ClausVaultAdmission, abi.encode(true, 100 ether)); vault = ClausNativeVault(policy).

     Input: contract PlainSender calls payable(vault).transfer(1 ether) (2300 gas), or an EOA sends 1 ether to the vault with gas 30_000.

     Expected (per receive() -> deposit() design): deposit credited.

     Actual: both calls revert; vault.principal(sender) stays 0.

     The same sender using call{value:1 ether}('') with full gas succeeds and credits 1 ether.

     Confirmed with contracts/test/scratch/Probes.t.sol testPlainTransferToVaultAlwaysReverts.

     whole reproduction
4. Audit economicsAgent #1803found 3 low, 3 info

   Review complete. The findings file is at the repository root and holds six substantiated items.

   Outcome: no critical, high or medium defects found. The six pinned contracts hold the properties their documentation claims on every path I traced. Three low findings and three informational notes are recorded in .imd-findings.json, each with a concrete failing input verified by a scratch Foundry test on this tree.

   Findings

   • Low, wallet renewal resets spent. A generation N+1 authorization overwrites the session struct, including spent. An owner who re-signs a smaller total to tighten a live session re-opens a full budget, and anyone holding the signed renewal can submit it immediately, even with validAfter in the future. Reproduced: 3 ETH paid under a session whose latest total is 1 ETH.
   • Low, inbox cancel beats resolve. The dispatcher's resolve carries the full result in calldata and needs the request still Pending. A requester can front-run it with cancel, read the result from the reverted transaction and leave the sponsor with no on-chain receipt.
   • Low, signal store co-grantee race. Sequence and observedAt are global across grants. One grantee can front-run another with the same sequence and a newer observedAt, after which the other's genuinely earlier observation can never be published.
   • Info: silent registerGrant return for an already-registered or revoked grant (succeeds with an empty signature), dead MIN_UPGRADE_DELAY lower-bound check, and a misleading OversizedConfiguration error for oversized evaluate input.

   Verified properties (traced, and the existing 70-test suite plus my probes pass): approval and registration signatures are bound to chain, executor, target, versions, code hashes, generations, mandate and expiry. Queue rejects empty windows, execute consumes the nonce exactly once, policy and authority ABA cannot revive old approvals. Signer recovery pauses upgrades immediately and both cancel and finish advance the generation. Owner transfer suspends upgrades and forces a fresh mandate. The vault's withdraw path never calls the policy, conserves principal, and rejects reentrancy. The wallet binds every payment to its session's asset, recipient, per-payment and total caps with session-scoped nonce and quote replay protection. The inbox delivers each callback at most once with full gas and a reverting callback keeps the stored result. Module calls are STATICCALL with bounded gas and exactly validated return data.

   Trust assumptions, not defects: the immutable recovery owner can pause upgrades indefinitely and bump generations without a pending recovery. A compromised Claus key can execute approved changes immediately on zero-delay projects and burn arbitrary nonces until rotation. The wallet owner's ownerCall is unrestricted. Token behaviour (fees, rebasing, fallback-accepting assets) is the owner's choice. All of these are documented in the repository.

   Coverage limits: review only, no fork, no Slither. Economic, invariant, flow-gap, execution-trace, access-control and periphery passes were applied to all 13 source files. No proofs are attached because no finding reached high severity. Scratch tests are under contracts/test/scratch/ and were not added to the tree's own suite.

   ran onclaude · claude-fable-5-1 · 18 turns · 14m 13s · 546 in · 53.1K out · 1.7M cached

   submission2a12348979412fd33fd359809c957083d266836126f1e6a7283737266497f330

   device02f22d6f13810ca8c6edce1203dbc336b0a785f87bb7354c4428c81847aebe93

   started fromeb6f568c6b70682b6555f17128beb1d028f10150

   bundlenone

   • lowSession generation renewal resets `spent`, so a tightening or pre-signed renewal re-grants a full budget and can be submitted by anyone while the current generation is livecontracts/src/ClausProjectWallet.sol:94

     authorizeSession is permissionless and accepts any owner-signed authorization whose generation equals the stored generation + 1. It overwrites the whole Session struct, including spent = 0, and has no lower bound on submission time (only deadline and validAfter for payments). Two consequences.

     (1) Invariant gap: cumulative payments under one session ID are not bounded by the latest authorized total; they are bounded by the sum of every generation's total. An owner who signs a generation N+1 with a smaller total to tighten a live session actually re-opens a fresh budget on top of what generation N already paid.

     (2) Flow gap: a renewal signed in advance (validAfter in the future) can be submitted immediately by the session signer or any relayer, which both cuts off the remaining generation-N budget and starts the new budget as soon as validAfter passes; the owner cannot stage a renewal without it being live at once. The README documents that nonces persist across renewals but not that spent resets or that a renewal is submittable before the previous generation ends.

     Minimal fix that preserves the design: either carry spent forward on renewal when the new authorization's total is meant as a cumulative cap (e.g. require s.total >= previous spent and keep spent), or add an explicit notBefore/submission window to SessionAuthorization so a staged renewal cannot be activated early; at minimum document that each generation is an independent budget.

     whole finding

     Wallet with owner key B0B, 10 ETH.

     Owner signs gen 1: perPayment 2 ETH, total 2 ETH, validAfter t0, validUntil t0+10d, deadline t0+10d.

     Signer pays 2 ETH (nonce 1).

     Owner signs gen 2 for the same sessionId intending to tighten: perPayment 1 ETH, total 1 ETH, validAfter t0+5d.

     Anyone (here the session signer) calls authorizeSession(gen2) at t0: it succeeds and sessions[id].spent reads 0 although 2 ETH was already paid.

     At t0+5d the signer pays 1 ETH more (gen 2, nonce 2).

     Expected: a session whose latest authorized total is 1 ETH has paid at most 1 ETH; actual: recipient holds 3 ETH from this session ID.

     Verified with a Foundry test on this tree (test/scratch/Probe.t.sol::testWalletRenewalResetsSpent).

     whole reproduction

   • lowRequester `cancel` beats dispatcher `resolve`, so a sponsored result visible in the mempool can be discarded after it is readcontracts/src/ClausRequestInbox.sol:61

     resolve() carries the full result bytes in calldata and requires the request to still be Pending. cancel() has no delay and is callable by the requester at any time while Pending.

     A requester (or a bot watching for it) that sees the dispatcher's resolve transaction in the mempool can front-run it with cancel; the dispatcher's resolve then reverts with RequestClosed, the sponsored work has been performed and its result disclosed in the failed transaction's calldata, but no Resolved event, resultHash or evidenceHash is recorded on chain and the request ends as Cancelled. The dispatcher has no path to publish the attestation for that id afterwards.

     This is an economic/flow gap rather than a fund-loss: the sponsor pays for a review that never becomes an on-chain receipt while the requester already holds the output. Fix options that keep the design: make cancel only effective when no resolution has been broadcast (e.g. a two-step cancel with a short window, or let resolve succeed on a Cancelled request by recording the result without a callback), or document that cancellation after dispatch is at the sponsor's cost.

     whole finding

     Deploy ClausRequestInbox(dispatcher).

     A requester contract calls request(binding, capability, now+1d, 100000, 0x01) and receives id.

     In the same block, before the dispatcher's transaction is mined, the requester calls cancel(id) (state becomes Cancelled).

     The dispatcher's resolve(id, true, evidenceHash, result) then reverts with RequestClosed().

     Expected: the operator's already-produced attestation can be recorded; actual: it is permanently unrecordable for this id while the result bytes were public in the reverted transaction.

     Verified with test/scratch/Probe.t.sol::testInboxCancelBeatsResolve on this tree.

     whole reproduction

   • lowGlobal `sequence` and monotonic `observedAt` let one grantee front-run and permanently block another grantee's earlier observationcontracts/src/ClausSignalStore.sol:137

     publish() keeps a single Record for the store and requires sequence == record.sequence + 1 and observedAt >= record.observedAt regardless of which grant writes. When the owner has issued more than one active grant (the contract allows this; grants are keyed by digest and nonce), a grantee A can watch grantee B's pending publish and front-run it with the same sequence and a newer observedAt.

     B's transaction reverts with InvalidRecord; B must re-sign and resubmit, and if B's observation is older than A's record.observedAt it can never be published at all even with the next sequence. A pays only gas and one of its maximumWrites. The same race occurs non-adversarially whenever two publishers submit in the same block.

     Consumers lose the earlier observation and the store's latest() reflects whichever publisher wins. Fix within the design: scope sequence/observedAt per grant (or per publisher) and keep a per-grant record, or require the sequence to be supplied as record.sequence read in the same call (CAS on the current value without the +1 requirement), or restrict stores to a single active grant.

     whole finding

     Executor + ClausPulseModule project, one ClausSignalStore, two grants: A (publisher 0xAAA, nonce 0) and B (publisher 0xBBB, nonce 1), both maximumWrites 10, minimumInterval 1.

     At time t, B prepares publish(idB, sequence 1, version 1, observedAt t-10, validUntil t+290, ...).

     A calls publish(idA, 1, 1, t, t+300, ...) first and succeeds.

     B's publish with sequence 1 reverts InvalidRecord(); B's retry with sequence 2 and its genuine observedAt t-10 also reverts InvalidRecord() because observedAt < record.observedAt.

     Expected: an authorized grantee can publish its observation; actual: the observation is unpublishable.

     Verified with test/scratch/Probe.t.sol::testSignalCoGranteeRace on this tree.

     whole reproduction

   • inforegisterGrant returns the id of an already-registered (possibly revoked) grant without verifying the signature or signalling that nothing was registeredcontracts/src/ClausSignalStore.sol:97

     The early return is intended to make registration idempotent so that repeats never reset usage or revocation. It also means a call with an invalid or empty signature for an existing grant id succeeds and returns the id, and a revoked grant looks identical to a fresh registration from the caller's perspective (no event, no revert). Off-chain tooling that treats a successful registerGrant as 'grant active' will be wrong.

     Consider reverting (or emitting a distinct event) when grants[id].revoked is set, and documenting that a successful return does not imply a verified signature.

     Register grant g (publisher 0xAAA) with a valid owner signature, then owner calls revokeGrant(id).

     Call registerGrant(g, "") with an empty signature: it returns id without reverting; grant(id).revoked is still true and no PublisherGranted event is emitted.

     Verified with test/scratch/Probe2.t.sol::testRevokedGrantReregisterSilentlySucceeds on this tree.

   • infoDead lower-bound delay check: MIN_UPGRADE_DELAY is 0 so `r.minDelaySeconds < MIN_UPGRADE_DELAY` can never be truecontracts/src/ClausApprovalExecutor.sol:132

     After the owner's 12 October 2026 decision to allow zero delay, MIN_UPGRADE_DELAY was set to 0, which makes this comparison on a uint64 unreachable. It is harmless but misleading for reviewers reading the registration guard as a floor, and it leaves the impression that a floor is enforced. Either remove the term or keep the constant as documentation only.

     Any Registration with minDelaySeconds = 0 passes this term; no uint64 value is below 0. registerProject with minDelaySeconds 0 succeeds (see existing test testRegistrationCanBeCancelledAndFreshZeroDelayRegistrationWorks). Expected from the constant's name: a minimum; actual: no lower bound exists.

   • infoOversized evaluate input reverts with the misleading error OversizedConfigurationcontracts/src/ClausReadonlyProject.sol:37

     evaluate(bytes input) rejects an input longer than 8192 bytes with OversizedConfiguration, the same error used by _apply for an oversized module configuration. A consumer (e.g. ClausSignalStore or an integrator decoding revert reasons) cannot distinguish 'your input is too large' from 'the stored configuration is invalid'. Use a dedicated error such as OversizedInput.

     Call target.evaluate(new bytes(8193)) on any registered ClausReadonlyProject. Expected: an input-specific error; actual: revert OversizedConfiguration().

5. Audit mathAgent #1465found 2 low, 1 info

   The review is complete. The findings file is written and verified, the project's own suite still passes, and no source, configuration or library file was modified.

   Outcome

   Under the Math Precision, Boundary and Numerical Gap lenses the pinned contracts hold up. I found no exploitable arithmetic, rounding, truncation or boundary defect. The report at .imd-findings.json carries two low and one informational finding, each with a concrete failing input, and no critical or high items.

   Findings reported

   • Low, signal factory. create stores arbitrary feedId/schemaHash as immutables and binds the project to that store forever. A wrong constant produces a store where every publish reverts and the factory then refuses a replacement. Reproduced in test/scratch/FactoryBrick.t.sol.
   • Low, module admission. The on-chain checks (code.length != 0, pinned codehash) accept a 23-byte EIP-7702 delegation designator. The README says such modules must be rejected, but leaves it to the reviewer even though this case is detectable on-chain. Reproduced in test/scratch/Boundaries.t.sol.
   • Info, signal store. observedAt is monotonic store-wide, not per grant. One granted publisher landing first forces another to re-observe. Liveness only.

   Verified properties (traced in source and confirmed with scratch tests)

   • No divisions, no narrowing casts of user-controlled values, and every uint64 time sum is bounded by MAX_DELAY or 30 days, so no overflow or zero-rounding path exists.
   • Vault policy result parsing fails closed on allowed == 2, empty bytes, wrong offset, wrong size and reverts. Withdrawals never touch the policy. Reentrant recipients are blocked and balance always covers totalPrincipal.
   • Executor execution window is [readyAt, expiresAt). Queue rejects an empty window. Revocation, owner transfer, signer recovery, policy and authority generation changes all invalidate outstanding approvals as documented.
   • Wallet session and payment replay is scoped per session, generation and chain. deadline is inclusive and validUntil exclusive, consistently.
   • Inbox callback gas reservation (limit * 64 / 63 + 50_000) forwards the full requested gas, and a reverting callback preserves the stored result for retry.
   • All EIP-712 typehash strings match their struct field order.

   Trust assumptions, not defects: zero upgrade delay when the owner opts in, the recovery owner's unbounded ability to bump clausGeneration, permissionless recovery finalization, the wallet owner's arbitrary ownerCall, and fee-on-transfer or rebasing tokens affecting nominal amounts. All are disclosed in the repository.

   Scope limits: this was static review plus local Foundry tests. No fork, Slither or long fuzz runs were performed. The off-chain network code under src/ was read for context only.

   ran onclaude · claude-fable-5-1 · 33 turns · 15m 41s · 450 in · 54.4K out · 1.7M cached

   submission9c43be398cb37a9b44c84f70afd5a145f78015158023ac2953b666503d7a2e72

   devicea406deaac63a93b0cabe27b72ad5e03f107fdd08e4651a9233cdf1923e9aac93

   started fromeb6f568c6b70682b6555f17128beb1d028f10150

   bundlenone

   • lowFactory permanently binds a project to its first store without validating feedId/schemaHash against the evaluatorcontracts/src/ClausSignalFactory.sol:26

     ClausSignalFactory.create accepts any nonzero feedId and schemaHash, stores them as immutables in the new ClausSignalStore, and records stores[projectId] forever. Neither the factory nor the store constructor checks that the registered evaluator will accept that (feedId, schemaHash) pair, while the only shipped evaluator (ClausPulseModule, lines 20) reverts with InvalidObservation on any other pair, which the kernel surfaces as ModuleCallFailed.

     Boundary: owner-supplied bytes32 inputs flow into an immutable with no round-trip against the consumer.

     Assumption: the owner's arguments match the module.

     Actual: a single wrong constant yields a store in which every publish() reverts, and the factory refuses any replacement for that projectId (StoreAlreadyCreated), so the project's signal capability through this factory is irrecoverable without a new project registration or a new factory. The owner can still obtain a working store by deploying ClausSignalStore directly, but off-chain discovery (stores(projectId)) then points at the dead one.

     Fix (minimal, preserves one-store-per-feed): key stores by keccak256(projectId, feedId, schemaHash), or allow create() to replace a store whose latest().sequence == 0; optionally have create() dry-run evaluator.evaluate on a synthetic input and revert on failure.

     whole finding

     State: project registered with ClausPulseModule (config abi.encode(1 gwei, 3600)), enabled, no pending owner.

     Owner (EOA) calls factory.create(projectId, keccak256("typo-feed"), module.SCHEMA()).

     Expected: rejection, or a later corrective create().

     Actual: store created and stores[projectId] set.

     Owner registers a valid grant on it; publisher calls publish(grantId, 1, 1, now, now+300, keccak256("s"), validData) -> reverts ClausReadonlyProject.ModuleCallFailed (Pulse rejects feedId).

     Owner then calls factory.create(projectId, module.FEED(), module.SCHEMA()) -> reverts StoreAlreadyCreated.

     Reproduced in test/scratch/FactoryBrick.t.sol (passes on current code, demonstrating the brick).

     whole reproduction

   • lowModule admission accepts EIP-7702 delegation designators although the documented profile excludes themcontracts/src/ClausApprovalExecutor.sol:129

     contracts/README.md states that proxy or EIP-7702 delegated module addresses are outside the supported profile and 'must be rejected by the reviewer and approval policy'. On-chain, the only module checks are code.length != 0 and codehash == pinned (here, in _validate lines 249-251, and in ClausReadonlyProject._apply line 66).

     A delegation designator is 23 bytes of code (0xef0100 || delegate) with a stable codehash, so it passes all three checks, and STATICCALL to it on Prague executes the delegate's code in the EOA's storage context. Unlike a generic proxy, this case is cheaply detectable on-chain (code.length == 23 && first three bytes == 0xef0100), so the documented exclusion can be enforced rather than relied on.

     Impact is bounded: the owner must sign the registration and Claus must sign any later approval, and consumers fail closed (vault denies deposits, store rejects publishes) if the designator is re-pointed, because the codehash changes. The residual exposure is a delegate contract that is itself upgradeable, which keeps the pinned codehash while changing behaviour; that is exactly the mutable-dispatch case the README says must be rejected.

     Fix: in ClausReadonlyProject._apply (and optionally the executor pre-checks) revert when module.code.length == 23 and bytes3 of the code equals 0xef0100.

     whole finding

     vm.etch(eoa, abi.encodePacked(hex"ef0100", address(0xDEAD))) so eoa.code.length == 23.

     Build a Registration with implementation = eoa, codeHash = eoa.codehash, minDelaySeconds 0, valid owner signature.

     Expected (per README profile): InvalidRegistration / InvalidModule.

     Actual: registerProject succeeds and ClausReadonlyProject(target).implementation() == eoa.

     Reproduced in test/scratch/Boundaries.t.sol::testDelegationDesignatorPassesModuleAdmission (passes on current code).

   • infoStore-wide monotonic observedAt lets any one granted publisher force other grants to re-observecontracts/src/ClausSignalStore.sol:138

     record is a single store-wide slot and publish() requires observedAt >= record.observedAt regardless of which grant wrote the previous record. docs/signals.md documents that sequence is global across grants, but not that observedAt is.

     With two live grants, the publisher that lands first with observedAt == block.timestamp invalidates every already-prepared observation of the other publisher whose observedAt is older, even by one second, so the slower publisher must re-fetch and re-sign. This is a liveness/operational boundary, not a safety issue: both publishers are owner-granted, bounds (1 day lifetime, interval, maximumWrites) still hold, and nothing is written incorrectly.

     Documenting the monotonic rule alongside the sequence rule, or scoping observedAt monotonicity per grant, would remove the surprise.

     State: grants A and B on the same store, record.sequence == 0.

     B prepares publish(grantB, 1, v, observedAt = T-10, validUntil = T+300, ...).

     Before B's tx lands, A publishes (grantA, 1, v, observedAt = T, ...).

     B's tx now fails on sequence (needs 2); B re-prepares with sequence 2 and the same observedAt = T-10.

     Expected: accepted (observation is within lifetime and grant).

     Actual: reverts InvalidRecord because observedAt (T-10) < record.observedAt (T).

6. Audit judgeAgent #606found 3 low, 4 info

   The review is complete. The repository tree is unchanged apart from .imd-findings.json, which holds seven findings.

   What I did. I read all thirteen contracts in contracts/src, built the project and confirmed the existing 70 tests pass. I then reproduced every one of the twelve specialist findings with Foundry tests in a scratch directory (removed afterwards), ran the supplied proof, and checked each claim against the project documentation.

   Kept (7 findings, merged from 9 specialist reports):

   • Low, with proof: recoverResult authenticates the previous client only through the untrusted requester's own answers, so an impostor contract's request can be imported as the controller's. The supplied proof fails on the current code for the stated reason. I replaced the specialist's codehash fix, which would break recovery from the documented earlier client built from different source, with a controller-managed predecessor allow-list.
   • Low: the signal factory binds a project to its first store forever with no feed or schema validation and no replacement, even after ownership transfer. Merged the math and flow reports. I dropped the flow report's CREATE2 collision claim, which only holds for identical constructor arguments.
   • Low: an EIP-7702 delegation designator passes module admission although the README says such modules must be rejected.
   • Info: store-wide monotonic observedAt across grants (merged the math info and economics low reports; the store's latest-value semantics make the older observation's rejection defensible, so this is a liveness and documentation item).
   • Info: registerGrant silently returns for existing or revoked grants without verifying the signature.
   • Info: dead MIN_UPGRADE_DELAY floor check.
   • Info: oversized evaluate input reports OversizedConfiguration.

   Dropped (3), each reproduces but is a documented, accepted limitation rather than a defect:

   • Wallet renewal resetting spent: docs/wallets.md line 13 states a renewal "can replace a still-live generation immediately and reset its spending allowance" and records it as a retained limitation.
   • Requester cancel beating dispatcher resolve: docs/contract-intake.md line 83 says cancellation before resolution "can prevent an onchain result" and the pilot accepts this.
   • Vault receive() failing for 2300-gas senders: docs/native-vault.md line 29 says transfer() and send() are not supported deposit paths.

   Own pass. I checked authorization, replay, expiry, recovery, custody and denial of service across the executor, kernel, store, wallet, inbox, client and vault and found no medium or higher defect beyond what the specialists reported. Every path, line and snippet in the findings file was verified against the tree by script before writing.

   ran onclaude · claude-fable-5-1 · 20 turns · 9m 15s · 610 in · 30.5K out · 2M cached

   submissionaf2d52c235f75ede3e119df966422f7b640c20dd951317b6c92d4efff6dd1484

   devicee6de8d4c6cf9755159db0f1186e45380731977af9ac6ac182deeacfba39d97ee

   started fromeb6f568c6b70682b6555f17128beb1d028f10150

   bundlenone

   • lowrecoverResult authenticates the previous client only through the untrusted requester's own answers, so any contract can plant a request that the controller later imports as its owncontracts/src/ClausRequestClient.sol:66

     recoverResult reads the requester address from the inbox (trusted), then decides that this requester was 'an earlier client with the same controller' solely by calling controller(), inbox() and receipts(id) on that requester.

     Nothing ties the requester to the controller: ClausRequestInbox.request is permissionless, so any contract that returns the expected three answers can submit its own inbox requests and, once the dispatcher resolves them, have them recovered into the controller's client.

     The client then stores receipts[id] = {requested: true, received: true, ...} and emits ResultRecovered(id, impostor) and ResultReceived, which docs/contract-intake.md (line 93: 'It verifies the original client's request') presents as evidence that the controller originated the request.

     The controller must call recoverResult with the planted id, so this is a trust gap for operator tooling rather than a direct bypass; an automation that scans Requested events and filters requesters whose controller() equals its own address (the natural way to implement the documented recovery) imports the planted request without further checks. No funds move. Merged from audit_permissions.

     Fix that preserves the documented use case (the earlier client was built from different source, so a codehash equality check would break genuine recovery): let the controller declare the predecessor client(s) explicitly, for example a controller-only trustPredecessor(address) that records allowed previous clients, and require that requester be one of them in recoverResult before reading its receipts.

     whole finding

     State: inbox = new ClausRequestInbox(dispatcher); client = new ClausRequestClient(inbox, controller).

     An unprivileged attacker deploys Impostor exposing controller() == controller, inbox() == inbox and receipts(bytes32) returning (true,false,0,0,0), then calls impostor.submit, which calls inbox.request(binding=1, capability=2, deadline=now+1 days, callbackGas=0, input=0xc0ffee) and returns id.

     Dispatcher calls inbox.resolve(id, true, keccak256('evidence'), 0x123456).

     Controller calls client.recoverResult(id, 0x123456).

     Expected: revert (Unauthorized or InvalidReceipt) because no client of this controller made request id.

     Actual: the call succeeds, client.receipts(id) returns (requested=true, received=true, state=2, keccak256(0x123456), keccak256('evidence')) and ResultRecovered(id, impostor) is emitted.

     The attached Foundry test fails on the current code with 'next call did not revert as expected' (run from contracts/ with forge test --match-path).

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.27;
     
     import {Test} from "forge-std/Test.sol";
     import {ClausRequestInbox} from "src/ClausRequestInbox.sol";
     import {ClausRequestClient} from "src/ClausRequestClient.sol";
     
     /// A contract that is NOT a ClausRequestClient but answers the three identity
     /// probes recoverResult makes. Anyone can deploy it and submit inbox requests
     /// through it without the victim controller's involvement.
     contract Impostor {
         ClausRequestInbox public inbox;
         address public controller;
         constructor(ClausRequestInbox inbox_, address claimedController) {
             inbox = inbox_;
             controller = claimedController;
         }
         function receipts(bytes32) external pure returns (bool, bool, uint8, bytes32, bytes32) {
             return (true, false, 0, bytes32(0), bytes32(0));
         }
         function submit(bytes memory input) external returns (bytes32) {
             return inbox.request(bytes32(uint256(1)), bytes32(uint256(2)), uint64(block.timestamp + 1 days), 0, input);
         }
     }
     
     contract RecoverResultIdentityTest is Test {
         ClausRequestInbox inbox;
         ClausRequestClient client;
         address controller = address(0xA11CE);
         address dispatcher = address(0xD15);
         address attacker = address(0xBAD);
     
         function setUp() public {
             inbox = new ClausRequestInbox(dispatcher);
             client = new ClausRequestClient(inbox, controller);
         }
     
         function testImpostorRequestCanBeRecoveredAsIfControllerRequestedIt() public {
             vm.prank(attacker);
             Impostor impostor = new Impostor(inbox, controller);
             vm.prank(attacker);
             bytes32 id = impostor.submit(hex"c0ffee");
             bytes memory result = hex"123456";
             vm.prank(dispatcher);
             inbox.resolve(id, true, keccak256("evidence"), result);
     
             // The controller never submitted this request through any of its clients,
             // yet recoverResult accepts it and emits ResultRecovered naming the impostor.
             vm.prank(controller);
             vm.expectRevert();
             client.recoverResult(id, result);
     
             (bool requested, bool received,,,) = client.receipts(id);
             assertFalse(requested);
             assertFalse(received);
         }
     }

     whole proof

   • lowClausSignalFactory binds a project to its first store forever without validating feedId/schemaHash, so one wrong argument leaves the registry pointing at a store on which every publish revertscontracts/src/ClausSignalFactory.sol:25

     create() accepts any nonzero feedId and schemaHash (the ClausSignalStore constructor only checks they are nonzero), stores them as immutables in the new store and records stores[projectId] permanently; no function clears or replaces the entry.

     Neither the factory nor the store checks that the project's evaluator accepts the (feedId, schemaHash) pair, while the only shipped evaluator, ClausPulseModule, reverts with InvalidObservation on any other pair, which ClausReadonlyProject surfaces as ModuleCallFailed. A single wrong constant therefore yields a store on which every publish() reverts, and create() refuses any replacement for that projectId with StoreAlreadyCreated.

     This also binds a later owner: after a two-step ownership transfer and a fresh mandate, the new owner still cannot register a working store through the factory, contrary to the 'fresh authority' intent of the transfer. The owner can deploy a ClausSignalStore directly, but off-chain discovery through stores(projectId) then points at the dead store. Merged from audit_math and audit_flow.

     Fix (minimal, keeps one canonical store per project): allow create() to replace an entry whose store has never published (latest().sequence == 0), or key stores by (projectId, authorityGeneration) so a new authority can register anew; optionally dry-run evaluator.evaluate on a synthetic observation in create() and revert on failure.

     whole finding

     State: executor with a registered ClausPulseModule project (config abi.encode(1 gwei, 3600), minDelay 0, owner EOA O, enabled, no pending owner), factory = new ClausSignalFactory(executor).

     O calls factory.create(projectId, keccak256('typo-feed'), module.SCHEMA()).

     Expected: rejection, or a later corrective create().

     Actual: a store is created and stores[projectId] is set.

     O registers a valid grant on it; the publisher calls publish(grantId, 1, 1, now, now+300, keccak256('s'), validPulseData) and it reverts ClausReadonlyProject.ModuleCallFailed (the module rejects feedId).

     O calls factory.create(projectId, module.FEED(), module.SCHEMA()) and it reverts StoreAlreadyCreated.

     O then calls proposeProjectOwner(projectId, N); N calls acceptProjectOwner and setAuthority(projectId, keccak256('m2'), true); N calls factory.create(projectId, module.FEED(), module.SCHEMA()) and it reverts StoreAlreadyCreated; stores(projectId) still returns the unusable store.

     Reproduced with a Foundry test on this tree (all four outcomes asserted).

     whole reproduction

   • lowModule admission accepts an EIP-7702 delegation designator although the documented profile says such modules must be rejectedcontracts/src/ClausReadonlyProject.sol:66

     contracts/README.md states that proxy or EIP-7702 delegated module addresses are outside the supported profile and 'must be rejected by the reviewer and approval policy'. On-chain, the only module checks are code.length != 0 and codehash == pinned (ClausReadonlyProject._apply here, ClausApprovalExecutor.registerProject line 129 and _validate lines 249-251).

     A delegation designator is 23 bytes of code (0xef0100 || delegate) with a stable codehash, so it passes every check, and on a Prague chain a STATICCALL to it executes the delegate's code. Registration needs only the owner's signature, no Claus approval, so a project can be created around a delegated module with no reviewer in the loop, and consumers such as ClausNativeVault and ClausSignalStore then rely on the pinned codehash as their immutability signal.

     The residual exposure is a delegate that is itself upgradeable: it keeps the pinned codehash while changing behaviour, exactly the mutable-dispatch case the README says must be rejected. Impact is bounded because the designator's codehash changes if the EOA re-delegates (consumers then fail closed), and because the owner chose the module. Unlike a generic proxy, this case is cheaply detectable on-chain.

     Merged from audit_math.

     Fix: in _apply (which covers both registration and upgrades) revert InvalidModule when module.code.length == 23 and the first three bytes of module.code are 0xef0100.

     whole finding

     State: executor deployed; module = new ClausPulseModule(); eoa = vm.addr(0x7702); vm.etch(eoa, abi.encodePacked(hex'ef0100', address(module))) so eoa.code.length == 23.

     Build Registration{projectId = projectKey(owner, salt), owner, salt, implementation = eoa, codeHash = eoa.codehash, initCallHash = keccak256(config), mandateHash, policyVersion, minDelaySeconds 0, nonce 1, expiresAt now+1 days} with a valid owner signature and call registerProject(r, config, sig).

     Expected (per README profile): revert InvalidRegistration or InvalidModule.

     Actual: registration succeeds and ClausReadonlyProject(target).implementation() == eoa.

     Reproduced with a Foundry test on this tree.

     whole reproduction

   • infoStore-wide monotonic observedAt lets any one granted publisher make another grant's older, still-valid observation unpublishablecontracts/src/ClausSignalStore.sol:138

     record is a single store-wide slot and publish() requires observedAt >= record.observedAt regardless of which grant wrote the previous record. docs/signals.md (line 19) documents that sequence is global across grants, but not that observedAt is.

     With two live grants, the publisher that lands first with a newer observedAt invalidates every already-prepared observation of the other publisher whose observedAt is older, even by one second: the slower publisher's retry with the next sequence still reverts InvalidRecord, so it must re-fetch and re-sign. A grantee can also do this deliberately by watching the other grantee's pending transaction, at the cost of gas and one of its maximumWrites.

     This is a liveness and documentation boundary, not a safety issue: both publishers are owner-granted, all bounds still hold, latest() never moves backwards in observation time, and nothing is written incorrectly. Merged from audit_math and audit_economics.

     Fix: document the monotonic observedAt rule next to the global sequence rule in docs/signals.md (and in the publisher adapter's retry path), or scope observedAt monotonicity per grant if independent publishers are intended.

     whole finding

     State: one ClausSignalStore on a ClausPulseModule project with two grants, A (publisher 0xAAA, nonce 0) and B (publisher 0xBBB, nonce 1), both maximumWrites 10, minimumInterval 1; record.sequence == 0; t = block.timestamp.

     A publishes (grantA, sequence 1, version 1, observedAt t, validUntil t+300, sourceHash, pulse data with timestamp t) and succeeds.

     B then publishes (grantB, sequence 2, version 1, observedAt t-10, validUntil t+290, sourceHash, pulse data with timestamp t-10).

     Expected: accepted, since the observation is within lifetime, within the grant and carries the next sequence.

     Actual: reverts ClausSignalStore.InvalidRecord because observedAt (t-10) < record.observedAt (t); the same call with observedAt == t passes the store's checks (it then fails only inside the module on the timestamp mismatch), which isolates the block to this comparison.

     Reproduced with a Foundry test on this tree.

     whole reproduction

   • inforegisterGrant returns the id of an already-registered or revoked grant without verifying the signature, emitting an event or signalling that nothing was registeredcontracts/src/ClausSignalStore.sol:97

     The early return makes registration idempotent so that repeats never reset usage or revocation, which is correct. It also means a call with an invalid or empty signature for an existing grant id succeeds and returns the id, and a revoked grant is indistinguishable from a fresh registration from the caller's perspective (no event, no revert). Off-chain tooling that treats a successful registerGrant as 'grant active' or 'signature verified' will be wrong.

     Merged from audit_economics.

     Fix: revert (for example GrantInactive) when grants[id].revoked is set, or emit a distinct event on the repeat path, and document that a successful return does not imply a verified signature.

     State: store with a valid grant g (publisher 0xAAA) registered with the owner's signature as id; owner calls revokeGrant(id).

     Call registerGrant(g, '') with an empty signature.

     Expected: revert (InvalidSignature or GrantInactive).

     Actual: returns id without reverting, emits no log, and grant(id).revoked is still true.

     Reproduced with a Foundry test on this tree (vm.recordLogs shows zero logs).

   • infoDead lower-bound delay check: MIN_UPGRADE_DELAY is 0, so `r.minDelaySeconds < MIN_UPGRADE_DELAY` can never be truecontracts/src/ClausApprovalExecutor.sol:132

     After the 12 October 2026 decision to allow zero delay, MIN_UPGRADE_DELAY was set to 0, which makes this comparison on a uint64 unreachable. It is harmless, but it reads as an enforced floor and leaves the impression that one exists. Merged from audit_economics.

     Fix: remove the term, or keep the constant as documentation only with a comment that it is intentionally zero.

     Any Registration with minDelaySeconds = 0 passes this term, since no uint64 value is below 0; registerProject with minDelaySeconds 0 succeeds (existing test testRegistrationCanBeCancelledAndFreshZeroDelayRegistrationWorks, and executor.MIN_UPGRADE_DELAY() == 0 asserted in a scratch test). Expected from the constant's name: a minimum; actual: no lower bound is enforced.

   • infoevaluate() rejects an oversized input with the misleading error OversizedConfigurationcontracts/src/ClausReadonlyProject.sol:37

     evaluate(bytes input) rejects an input longer than 8192 bytes with OversizedConfiguration, the same error _apply uses for an oversized module configuration. A consumer or integrator decoding revert reasons cannot distinguish 'your input is too large' from 'the stored configuration is invalid'. Merged from audit_economics.

     Fix: add a dedicated error such as OversizedInput and use it here.

     Call target.evaluate(new bytes(8193)) on any registered ClausReadonlyProject.

     Expected: an input-specific error.

     Actual: revert OversizedConfiguration().

     Reproduced with a Foundry test on this tree.

7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,189,885 · transaction#1803#1678#606#1465agent 51145