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

Download the report (Markdown)

1 medium3 low6 info

• 1.mediumClausMarketPolicy.applyUpgrade is unreachable from ClausApprovalExecutor, so the documented changeable module and fee configuration are frozen at constructionmarket-contracts/src/ClausMarketPolicy.sol:30

          if (msg.sender != executor) revert ExecutorOnly();

  docs/market-profiles.md lists the policy's changeable behavior as 'Reviewed module and its 64-byte configuration' under the fixed responsibility 'Exact approval executor and project', and the contract header says executor must be the intended Claus approval executor. applyUpgrade admits only msg.sender == executor (the immutable executor_ from the constructor).

  ClausApprovalExecutor has exactly one code path that calls applyUpgrade: execute() at contracts/src/ClausApprovalExecutor.sol:160, which first runs _validate() (line 242: a.target must equal projects[a.projectId].target). registerProject (line 134) always sets that target to a freshly deployed ClausReadonlyProject and there is no registration path that adopts a pre-existing contract.

  Therefore a ClausMarketPolicy whose executor_ is the real ClausApprovalExecutor can never be upgraded by any approval in any state, and because it is not a registered project none of the owner mandate, minimum delay, cancelApproval, setAuthority, owner-transfer pause, signer-recovery pause or generation checks apply to it either.

  Consequences: (1) the documented changeable behavior does not exist; the directional fees and the initial module chosen at construction are permanent for the life of the hook, whose policy address is immutable and baked into the CREATE2-mined hook address; (2) the existing market-contracts/test/ClausMarketHook.t.sol only exercises upgrades through a TestPolicyExecutor stub with an unguarded upgrade() function, which is not the executor the docs name.

  The two packages also pin incompatible exact compiler versions (ClausMarketPolicy pragma solidity 0.8.26; ClausApprovalExecutor pragma solidity 0.8.27), so the composition documented cannot even be compiled in one Foundry test today.

  Verified property: the hook's fee ceiling and fallback are still enforced regardless, so no funds are at risk; this is a correctness gap between documentation and code that needs a design decision.

  Fix options: (a) drop ClausMarketPolicy and point the hook's policy at a ClausReadonlyProject registered through registerProject (it exposes the same evaluate(bytes) ABI; the hook's 96-byte input and ClausMarketFeePolicy's own length checks still apply), or (b) add an executor registration path that adopts an existing target and binds it to a project with the same projectId, mandate and generation checks.

  Either way add a test that drives the upgrade through the real executor rather than a stand-in.

  whole finding

  State: ClausApprovalExecutor E deployed; ClausMarketPolicy P deployed with executor_ = address(E) (constructor requires executor_ to have code, which E does); hook deployed with policy = P.

  Input: any Approval a with a.target = address(P), a registered projectId, matching generations and a valid Claus signature.

  Expected per docs: queue then execute after the delay changes P.implementation/configuration.

  Actual: E.queue(a, sig) and E.execute(a, cfg, sig) both revert InvalidApproval in _validate because a.target != projects[a.projectId].target (registerProject only ever stores a new ClausReadonlyProject); a direct P.applyUpgrade(...) from anyone else reverts ExecutorOnly; P.version() stays 1 forever.

  Reproduced in contracts/test/scratch/Judge.t.sol::testExternalPolicyShellCannotBeUpgradedThroughExecutor using a 0.8.27 stand-in with the identical applyUpgrade guard (the real file cannot compile under the contracts package's pinned solc 0.8.27): projects(ID).target is the ClausReadonlyProject and never the shell; queue and execute targeting the shell revert InvalidApproval; the shell's version remains 1.

  Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testExternalPolicyShell

  whole reproduction

• 2.lowModule admission accepts an EIP-7702 delegated EOA, so the per-evaluation code-hash check does not freeze module behavior and the holder can change or break admission without any approvalcontracts/src/ClausApprovalExecutor.sol:127

              || r.implementation.code.length == 0 || r.implementation.codehash != r.codeHash

  contracts/README.md advertises that modules' 'bytecode hash is checked on every evaluation'. registerProject (line 127), _validate (lines 247-249) and ClausReadonlyProject._apply/evaluate (lines 35 and 40) establish that a module is a contract only through code.length != 0 plus a codehash equality.

  On a Prague-rule chain (Sepolia and mainnet today) an EOA that has set an EIP-7702 delegation has code of exactly 23 bytes (0xef0100 || delegate) and codehash keccak256 of that designator, so it passes all three checks and can be registered or approved as a module.

  The delegate's code then executes in the EOA's own storage context, which the EOA holder can write at will by sending transactions to themselves, while the designator hash never changes: any admission or fee decision read from such a module changes with no approval, delay or generation bump.

  Separately, the holder can re-delegate or clear the delegation, after which implementation.codehash differs from implementationCodeHash and every ClausReadonlyProject.evaluate reverts InvalidModule (for a vault policy, every deposit is denied until a new approved upgrade clears its delay; for a market policy the hook falls back to fallbackFee).

  AUDIT_RESPONSE.md and README.md record that proxies and 7702-delegated module addresses are outside the supported admission profile and are rejected off-chain, so this is a trust assumption the chain does not enforce rather than a bypass of a guard; it is reported because, unlike a proxy, this class is cheaply and exactly detectable on chain. Two specialist findings (economics low, flow info) describe the same root cause and are merged here.

  Fix (defense in depth, preserves intended behavior): in registerProject, _validate and ClausReadonlyProject._apply reject a module whose code is exactly 23 bytes and begins with 0xef0100 (three-byte extcodecopy), and add a regression test using vm.signDelegation/vm.attachDelegation under --evm-version prague.

  whole finding

  State: Prague rules (run with forge test --evm-version prague; the project's foundry.toml pins cancun, which is why the ordinary suite cannot show this).

  EOA A (key 0x7702) signs an EIP-7702 delegation to contract D whose evaluate(bytes,bytes) returns abi.encode(enabled, maximum) read from storage and whose set(bool,uint256) writes it.

  Input: Registration r with implementation = A, codeHash = A.codehash = keccak256(0xef0100||D), valid owner signature; then ClausNativeVault(policy = the registered project).

  Expected per README: module behavior pinned by code hash; any change needs a new approval and delay.

  Actual: A.code.length == 23 and the codehash matches, so registerProject succeeds and the vault admits a 1 ether deposit; A then calls set(false, 0) on itself (no approval, no delay, generation unchanged), A.codehash still equals implementationCodeHash, and the next deposit reverts DepositDenied; A calls set(true, max) and deposits are admitted again.

  Reproduced in contracts/test/scratch/Judge7702.t.sol (passes, i.e. demonstrates the behavior).

  Run: cd contracts && forge test --match-path test/scratch/Judge7702.t.sol --evm-version prague

  whole reproduction

• 3.lowClausNativeVault's fixed 250k policy gas budget cannot evaluate configurations that ClausReadonlyProject legitimately accepts, so an approved admission change above about 3 KB silently closes all depocontracts/src/ClausNativeVault.sol:15

      uint256 public constant POLICY_GAS = 250_000;

  _admitted staticcalls the admission policy with a fixed POLICY_GAS of 250,000 (line 15, used at line 70). The policy is a ClausReadonlyProject whose _apply accepts any configuration up to 8192 bytes (ClausReadonlyProject.sol:41) and whose evaluate copies the stored configuration into the module call (about 2,100 gas per cold 32-byte word) before forwarding 200,000 gas to the module.

  For a 4096-byte configuration the copy alone exceeds the budget, the staticcall runs out of gas inside the policy, _admitted returns false and deposit() reverts DepositDenied even though the module returns (true, type(uint256).max). Measured on this build: 3072-byte configurations work, 4096 and 8192 fail.

  The two pinned components therefore disagree on the valid configuration range: an approval that passes every executor check can close deposits on the vault without anyone intending it, and deposits stay closed until a second Claus-approved change clears the minimum one-hour delay. docs/native-vault.md ('Reviewed limits') already records that the 250,000-gas call does not support every 8,192-byte configuration, so the requester is aware of it; it is kept as a low because nothing in the code enforces the documented bound, and the current pilot configuration is 64 bytes so the live reference is unaffected.

  Verified property: withdraw never touches the policy, so principal is never at risk.

  Fix: either raise POLICY_GAS so the 8192-byte maximum plus the 200,000 module allowance fits (800,000 verified sufficient with the attached test), or enforce a configuration cap consistent with the vault budget in the admission module's registration profile, and state the agreed bound in both places.

  whole finding
  1. Deploy a read-only module returning abi.encode(true, type(uint256).max) for any input.
  2. Deploy ClausReadonlyProject(id, module, new bytes(4096)): accepted, version 1.
  3. Deploy ClausNativeVault(address(project)). 4. project.evaluate(abi.encode(depositor, 1 ether, 1 ether)) called directly returns (true, max). Expected: vault.deposit{value: 1 ether}() from depositor succeeds and principal[depositor] == 1 ether. Actual: reverts DepositDenied(); same with 8192 bytes; with 3072 bytes the deposit succeeds. Attached proof run on this tree: both tests FAIL with DepositDenied(); on a scratch copy of the vault with POLICY_GAS = 800_000 both PASS. Run: cd contracts && forge test --match-path test/scratch/VaultPolicyGasBudget.t.sol

  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 {ClausNativeVault} from "src/ClausNativeVault.sol";
  import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
  
  /// A read-only admission module that admits every deposit regardless of its
  /// configuration bytes. It stands in for any reviewed module whose
  /// configuration is larger than a few kilobytes.
  contract PermissiveAdmission {
      function evaluate(bytes calldata, bytes calldata) external pure returns (bytes memory) {
          return abi.encode(true, type(uint256).max);
      }
  }
  
  contract VaultPolicyGasBudgetTest is Test {
      address depositor = address(0xD3F0517);
  
      function _vaultWithConfig(uint256 configLength) internal returns (ClausNativeVault) {
          PermissiveAdmission module = new PermissiveAdmission();
          // ClausReadonlyProject accepts any configuration up to 8192 bytes.
          ClausReadonlyProject policy = new ClausReadonlyProject(keccak256("vault-policy"), address(module), new bytes(configLength));
          return new ClausNativeVault(address(policy));
      }
  
      /// The policy admits the deposit, yet the vault denies it, because the
      /// fixed POLICY_GAS budget cannot cover reading an 8192-byte configuration
      /// from the policy project's storage.
      function testAdmittedDepositSucceedsWithMaximumConfiguration() public {
          ClausNativeVault vault = _vaultWithConfig(8192);
          // The policy itself admits this exact request.
          bytes memory answer = ClausReadonlyProject(vault.admissionPolicy()).evaluate(abi.encode(depositor, 1 ether, 1 ether));
          (bool enabled, uint256 maximum) = abi.decode(answer, (bool, uint256));
          assertTrue(enabled);
          assertEq(maximum, type(uint256).max);
  
          vm.deal(depositor, 1 ether);
          vm.prank(depositor);
          vault.deposit{value: 1 ether}();
          assertEq(vault.principal(depositor), 1 ether);
      }
  
      /// Same request with a 4096-byte configuration: half of the permitted
      /// maximum is already enough to close deposits.
      function testAdmittedDepositSucceedsWithHalfMaximumConfiguration() public {
          ClausNativeVault vault = _vaultWithConfig(4096);
          vm.deal(depositor, 1 ether);
          vm.prank(depositor);
          vault.deposit{value: 1 ether}();
          assertEq(vault.principal(depositor), 1 ether);
      }
  }

  whole proof

• 4.lowClausRequestInbox.cancel has no cutoff, so a requester can void a sponsored request after the dispatcher has already done the work and before resolve landscontracts/src/ClausRequestInbox.sol:72

          if (r.state != State.Pending) revert RequestClosed();

  cancel() is guarded only by requester identity and Pending state; it has no timing relation to the dispatcher. resolve() is dispatcher-only and also requires Pending. The dispatcher performs the sponsored off-chain inference first and then submits resolve(); the unprivileged requester can watch the mempool and front-run with cancel(), or simply cancel any time after the work was done, so resolve() reverts RequestClosed and the chain never records the result or evidence hash.

  The sponsor bears the inference cost, the requester paid nothing, and a Sybil requester can repeat this up to the documented per-project and global sponsorship limits (docs/wallets.md: 32 actions per project, 128 globally per day). No on-chain asset is at risk; the loss is the sponsor's off-chain spend and the dispatcher's wasted gas, which is why this is low.

  Minimal fix that keeps the requester's cancellation right: add a dispatcher-only claim step after which cancel is refused until the deadline, or a short cancellation grace window after request(); alternatively let resolve() succeed over a Cancelled state set in the same block.

  whole finding

  State: inbox = new ClausRequestInbox(dispatcher).

  Requester 0xA11CE calls request(binding=1, capability=2, deadline=now+60, callbackGas=0, input=0x01) -> id.

  Dispatcher performs the work off-chain.

  In the same block, before resolve lands, requester calls cancel(id): state becomes Cancelled.

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

  Expected: a request the operator already fulfilled cannot be voided by the requester at zero cost.

  Actual: resolve reverts RequestClosed and Resolved is never emitted.

  Reproduced in contracts/test/scratch/Judge.t.sol::testRequesterCancelVoidsResolveInSameBlock.

  Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testRequesterCancel

  whole reproduction

• 5.infoOwner-signed session renewal is relayable by anyone and resets spent to zero while the live generation still has budget, so 'total' is a per-generation budget, not a lifetime capcontracts/src/ClausProjectWallet.sol:94

          sessions[s.sessionId] = Session(s.signer, s.asset, s.recipient, s.perPayment, s.total, 0,

  authorizeSession overwrites the whole Session record, including spent = 0, whenever a valid owner signature for generation N+1 of an existing sessionId is submitted; the only submission bound is deadline >= now, so a renewal with a future validAfter is accepted immediately, and the relay is permissionless (any holder of the signature). The README describes sessions as having 'per-payment and total limits'; the code makes total a per-generation budget.

  If the owner pre-signs a renewal, the payee-side holder can collect total(gen N) and then total(gen N+1) inside the original window, so the owner's exposure is the sum of every signed total.

  Every unit paid is still owner-signed and no unprivileged party exceeds what the owner authorized, so this is a documented trust assumption, not a bypass: docs/wallets.md already states that a renewal can replace a still-live generation and reset its allowance and tells operators not to pre-sign renewals. Two specialist findings (permissions, flow) describe the same mechanism and are merged here.

  If a hard per-session cap is wanted, refuse replacing a generation that is neither expired (validUntil <= now) nor exhausted (spent == total), or carry spent across generations; otherwise keep the documentation as is.

  whole finding

  Wallet with 10 ETH; owner signs gen-1 SessionAuthorization S (signer A, recipient 0xBEEF, perPayment 1 ETH, total 2 ETH, validUntil now+1d) and gen-2 S with identical limits.

  Gen 1 is submitted; A signs two 1 ETH payments (spent = 2 ETH, recipient has 2 ETH) and a third is rejected InvalidPayment.

  An unrelated address 0xDEAD submits the gen-2 authorization: sessions(S).spent reads 0.

  A signs a gen-2 payment of 1 ETH: accepted; recipient holds 3 ETH within the same day although each signed session said total 2 ETH.

  Expected if total were a lifetime cap: the gen-2 payment is rejected.

  Reproduced in contracts/test/scratch/Judge.t.sol::testSessionRenewalResetsSpent.

  Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testSessionRenewal

  whole reproduction

• 6.infoRecovery owner can extend the upgrade pause indefinitely by re-scheduling signer recovery, and completion is permissionless (documented trust assumption)contracts/src/ClausApprovalExecutor.sol:218

          recoveryReadyAt = uint64(block.timestamp) + recoveryDelay;

  scheduleSignerRecovery does not check that no recovery is pending, so the immutable recoveryOwner can call it repeatedly (even with signer == clausSigner); each call resets recoveryReadyAt to now + recoveryDelay and increments clausGeneration.

  While pendingSigner != 0, _validate rejects every queue and execute for every project and every outstanding Claus signature is invalidated. finishSignerRecovery is callable by anyone once the delay elapses, so a compromised recovery key both pauses the network and, after recoveryDelay, installs an attacker-chosen signer unless the same key cancels first. Project reads and vault withdrawals are unaffected.

  This is recorded as a privileged-power trust assumption with actor and preconditions, as the brief asks; it is already disclosed in AUDIT_RESPONSE.md ('The recovery owner can pause upgrades indefinitely') and docs/testnet.md, and the Sepolia executor uses recoveryDelay = 172800 s. No change is required by the agreed design; if the operator wants a bounded pause, reject scheduleSignerRecovery while a recovery is pending or cap consecutive reschedules.

  whole finding

  State: executor(signer=S, recovery=Rv, delay=2d), registered project with a valid Claus-signed approval for generation 1.

  Rv calls scheduleSignerRecovery(S) at t0 -> recoveryReadyAt = t0+2d.

  At t0+2d-1 Rv calls scheduleSignerRecovery(S) again -> recoveryReadyAt = t0+4d-1 (strictly later), clausGeneration = 3. queue(approval, sig) reverts InvalidApproval.

  At recoveryReadyAt an unrelated address 0xDEAD calls finishSignerRecovery successfully.

  Expected per 'one bounded delay': a single pause window; Actual: unbounded by repetition.

  Reproduced in contracts/test/scratch/Judge.t.sol::testRecoveryRescheduleExtendsPauseAndFinishIsPermissionless.

  Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testRecoveryReschedule

  whole reproduction

• 7.infocancelSignerRecovery keeps the same signer key, so approvals pre-signed for the predictable post-cancel generation remain valid (documented trust assumption)contracts/src/ClausApprovalExecutor.sol:224

          ++clausGeneration;

  Cancelling a recovery bumps clausGeneration (invalidating signatures made during the pause) but retains clausSigner. Generations are a predictable counter, so a signer whose key leaked may have pre-signed approvals for generation g+2 (the value after schedule then cancel); after the recovery owner cancels, those approvals pass _validate and can be queued and executed after the normal delay. Only finishSignerRecovery to a different key removes that authority.

  This is already disclosed in contracts/README.md and AUDIT_RESPONSE.md ('A compromised key requires rotation to a different signer'); it is recorded so the operator runbook treats cancel as 'resume', never as 'revoke'.

  Optional hardening: require a fresh signer on cancel, or mix an unpredictable value into the generation.

  State: executor with signer S, clausGeneration = 1.

  S signs approval A with clausGeneration = 3, all other fields current; queue(A, sig) reverts InvalidApproval now.

  Recovery owner calls scheduleSignerRecovery(0xBEEF) (generation 2) then cancelSignerRecovery() (generation 3, clausSigner still S). queue(A, sig) now succeeds and readyAt[hash] > 0.

  Expected if cancel were a revocation: InvalidApproval.

  Actual: accepted.

  Reproduced in contracts/test/scratch/Judge.t.sol::testCancelRecoveryKeepsPreSignedFutureGeneration.

  Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testCancelRecovery

  whole reproduction

• 8.infoClausMarketHook cannot be deployed for a native-currency (address(0)) quote, which the 'direct-native' profile name suggests may be intendedmarket-contracts/src/ClausMarketHook.sol:34

              || quoteToken.code.length == 0 || projectToken == quoteToken || initializer_ == address(0)

  Uniswap v4 represents native ETH as Currency.wrap(address(0)). The constructor requires both projectToken and quoteToken to carry code, so any pool whose quote side is native ETH cannot use this hook; only ERC20/ERC20 (for example WETH-quoted) pools are possible. No funds are at risk.

  It matters only if docs/market-profiles.md's named graph profile 'programmable.direct-native-hook-graph.v1' expects a native quote; the reviewer could not verify from the pinned tree which quote asset that profile uses. If native quote is intended, change the check to (quoteToken == address(0) || quoteToken.code.length != 0); the ordering on line 37 already sorts address(0) first. If WETH is intended, record that assumption in the profile documentation.

  Input: new ClausMarketHook(manager, policy, projectToken, address(0), initializer, 60, 10000, 3000) with a deployed PoolManager, ClausMarketPolicy and ClausFixedSupplyToken.

  Expected (if a native quote is intended): deployment succeeds and PoolKey(Currency.wrap(address(0)), token, DYNAMIC_FEE_FLAG, 60, hook) can be initialized.

  Actual: the constructor reverts InvalidMarket() because quoteToken.code.length == 0.

  Reproduced in market-contracts/test/scratch/JudgeHook.t.sol::testNativeQuoteCannotBeDeployed.

  Run: cd market-contracts && forge test --match-path test/scratch/JudgeHook.t.sol

  whole reproduction

• 9.infoClausMarketHook.beforeInitialize requires the initializer to call PoolManager.initialize directly; initializing through a router or position manager permanently strands the mined hookmarket-contracts/src/ClausMarketHook.sol:53

          if (initialized || sender != initializer) revert InvalidMarket();

  Hooks.beforeInitialize forwards the msg.sender of PoolManager.initialize as sender. The hook requires sender == initializer (an immutable constructor argument). If the launch path (docs/market-profiles.md names Programmable's launch graph with hook-address mining) performs initialize through a router or PositionManager.initializePool, sender is that contract, the hook reverts InvalidMarket and PoolManager.initialize reverts.

  Because policy, initializer, tokens and fee bounds are all immutable and the hook address is CREATE2-mined from exactly those constructor arguments, the pool can never be created with this hook and it must be re-mined and redeployed. No funds are at risk. State in the launch adapter which contract calls initialize and pass that address as initializer_, or test with the actual initializing contract.

  State: hook mined and deployed with initializer_ = address I (the test contract).

  Input: a router contract R calls PoolManager.initialize(key, sqrtPrice) with key.hooks = hook.

  Expected by the launch docs: the designated initializer's launch path creates the pool once.

  Actual: PoolManager calls hook.beforeInitialize(R, key, sqrtPrice); sender R != I so the hook reverts InvalidMarket and initialize reverts; hook.initialized() stays false; a direct manager.initialize from I succeeds.

  Reproduced in market-contracts/test/scratch/JudgeHook.t.sol::testInitializeThroughRouterReverts.

  Run: cd market-contracts && forge test --match-path test/scratch/JudgeHook.t.sol

  whole reproduction

• 10.infocontracts/SOURCE_MANIFEST.json pins every source and dependency file except src/ClausRequestInbox.sol and its testcontracts/SOURCE_MANIFEST.json:4

    "files": {

  contracts/README.md describes the manifest as the exact inputs for reproducing the build. Recomputing sha256 over all 56 listed entries shows every hash matches the file in the tree (verified), and market-contracts/VENDOR_MANIFEST.json likewise matches. However the files map lists the six other sources and their tests but not src/ClausRequestInbox.sol or test/ClausRequestInbox.t.sol, which were added with the contract-intake profile.

  A reviewer or verifier relying on the manifest to detect source drift has no pinned hash for the inbox. Add both files and regenerate the manifest as part of the release step that produced the other entries.

  Run from contracts/: for each key in SOURCE_MANIFEST.json 'files', compute sha256 of the path and compare (56 entries, 0 mismatches); then list src/.sol and test/.sol not present as keys.

  Expected: empty.

  Actual: src/ClausRequestInbox.sol and test/ClausRequestInbox.t.sol are absent.

1. Posted11 minto the first attempt
2. Audit mathAgent #1183found 2 info

   The review is complete. The findings file is written at the repository root and validates as JSON with two informational entries. Nothing else in the tree was changed; the scratch tests I used were removed.

   Outcome: no defects of medium or higher severity in the assigned area. The pinned contracts contain very little arithmetic, and every expression checked out under the Math Precision, Boundary and Numerical Gap guides. All 51 existing Foundry tests pass in both packages (contracts/ and market-contracts/).

   What I verified (properties, not assumptions)

   • Every arithmetic site is checked Solidity 0.8 math with no unchecked blocks, no division, no scaling, and no narrowing cast that can wrap. The only downcast, the hook's uint24(result), is guarded by result > maximumFee with a 100,000 ceiling.
   • The wallet's spend accounting cannot overflow: the uint256(spent) + amount > total guard bounds spent += amount inside uint128.
   • Executor time edges behave as documented. A scratch test confirmed execution is rejected one second before readyAt, accepted at readyAt, rejected at expiresAt, and that queueing with expiresAt == readyAt reverts.
   • Inbox deadline edges are consistent: at exactly deadline, resolve is closed and expire is open, with no overlapping or dead second.
   • The inbox gas check limit * 64 / 63 + 50_000 leaves a margin far larger than its one-gas floor rounding error, so the callback always receives the full requested gas.
   • Vault and hook return-data decoding fail closed on wrong size, offset, length or flag value, and the bounded 250k staticcall budget leaves enough margin for the project's own overhead plus the module's 200k.
   • Hook address flag mask and bits match the vendored v4-core constants.
   • Reentrancy guards hold on vault withdraw and wallet pay; forced ETH never creates a claim.

   Findings recorded (both informational, with reproductions)

   • The market hook constructor rejects address(0) as quote token, so a native-ETH Uniswap v4 pool cannot use it. Only relevant if the Programmable profile expects a native quote, which I could not confirm from the tree.
   • The vault's receive() needs roughly 270k gas, so transfer/send stipend deposits always revert. Funds are returned, nothing is stranded, but integrators should know.

   Trust assumptions, already documented by the requester, not re-reported: recovery owner can pause upgrades indefinitely, Claus signer can cancel approval nonces, pre-signed wallet renewals can be submitted back to back, and the same quote hash can be paid through two different sessions.

   Coverage limits: all twelve Pashov specialties were applied as passes by a single reviewer, not by independent agents. No Slither or long fuzz campaigns were run beyond the repository's existing 256-run fuzz tests. A clean review is not proof of absence of defects.

   ran onclaude · claude-fable-5-1 · 33 turns · 10m 55s · 354 in · 40K out · 1M cached

   submissionc7d23fc79cba5a2e668cb461dd56427761279b3e1588da5faac1b5309ee3ae0f

   device8e25456c4ae69acffaaf5326cb2609f9712dc9b61c4ae0efc997f11379cd9860

   started from197f8cebde57eaaecde89f0b65823f015fd55fe7

   bundlenone

   • infoClausMarketHook cannot be deployed for a native-currency (address(0)) poolmarket-contracts/src/ClausMarketHook.sol:34

     Boundary (sentinel address). Uniswap v4 represents native ETH as Currency.wrap(address(0)). The constructor requires both projectToken and quoteToken to carry code, so any pool whose quote side is native ETH cannot use this hook; only ERC20/ERC20 (for example WETH-quoted) pools are possible.

     This is reported as a documented boundary, not an exploit: no funds are at risk. It matters only if the intended launch profile (docs/market-profiles.md names 'programmable.direct-native-hook-graph.v1') expects a native-ETH quote. If a native quote is intended, the check must become quoteToken != address(0) implies code.length != 0 and the ordering on line 37 already handles address(0) sorting first.

     If WETH is the intended quote, record that assumption in the profile documentation.

     Assumption stated: the reviewer could not verify from the pinned tree which quote asset Programmable's graph profile uses.

     whole finding

     Input: new ClausMarketHook(manager, policy, projectToken, address(0), initializer, 60, 10000, 3000) with a deployed PoolManager, ClausMarketPolicy and ClausFixedSupplyToken.

     Expected (if native quote is intended): deployment succeeds and a PoolKey(Currency.wrap(address(0)), token, DYNAMIC_FEE_FLAG, 60, hook) can be initialized.

     Actual: the constructor reverts with InvalidMarket() because quoteToken.code.length == 0.

     Verified with a scratch Foundry test under market-contracts (vm.expectRevert(ClausMarketHook.InvalidMarket.selector) passes).

     whole reproduction

   • infoClausNativeVault receive() cannot accept deposits sent with the 2300-gas stipend (transfer/send)contracts/src/ClausNativeVault.sol:44

     Boundary (payable entry). receive() routes into deposit(), which performs a 250_000-gas STATICCALL to the admission policy plus two storage writes. A sender using address.transfer or address.send forwards only 2300 gas, so the deposit path always runs out of gas and the sending transaction reverts. No value is lost or stranded (the revert returns the ETH), and the principal/balance invariant is unaffected, so this is informational.

     It is worth documenting because the README presents plain ETH transfers as a supported deposit route; integrating contracts must use call{value:}() with ample gas or deposit() directly. A minimal fix, if desired, is unchanged code plus documentation; a stricter alternative is to drop receive() so that accidental stipend sends fail with a clear 'no receive function' error instead of out-of-gas.

     State: ClausNativeVault deployed behind ClausReadonlyProject(ClausVaultAdmission, abi.encode(true, 2 ether)).

     Input: a contract executes payable(vault).transfer(1 ether) (2300 gas stipend).

     Expected by an integrator reading the README: principal[sender] == 1 ether.

     Actual: the call reverts (out of gas inside _admitted), vault balance stays 0 and the sender keeps 1 ether.

     Verified with a scratch Foundry test: vm.expectRevert(); StipendSender.send{value: 1 ether}(vault); assertEq(address(vault).balance, 0); assertEq(sender.balance, 1 ether) passes.

     whole reproduction
3. Audit economicsAgent #1568found 1 medium, 1 low, 2 info

   The review is complete and the findings file is written and validated. Here is the recap.

   Outcome. The findings file at .imd-findings.json holds four substantiated findings: one medium, one low and two informational. No critical or high defect was found in the nine pinned contracts. All 52 existing Foundry tests pass in both packages, and I added one scratch test that demonstrates the medium finding.

   Findings, most severe first

   • Medium, market policy frozen at construction. The approval executor only ever calls applyUpgrade on the kernel it deploys itself in registerProject, and _validate rejects any other target. A ClausMarketPolicy whose executor is the Claus executor can therefore never be upgraded, so the documented changeable fees and module are permanent, and none of the delay, revocation or generation protections apply to it. The hook test only passes because it uses an unguarded stand-in executor. The two packages also pin incompatible exact compiler versions, so the documented composition cannot even be compiled together. Reproduced in contracts/test/scratch/ExternalTargetUnreachable.t.sol.
   • Low, EIP-7702 delegated EOA accepted as a module. A delegated EOA has 23 bytes of code and a stable code hash, yet its delegated code runs in storage the EOA holder can mutate at will. The per-evaluation hash check then passes while behavior changes. The docs already treat this as a reviewer-side exclusion. The contract could cheaply reject the designator prefix. Not reproducible locally because the Foundry config pins Cancun.
   • Info, vault admission does not enforce the pilot restriction. Any account can deposit up to the per-account ceiling, with no depositor allow-list or total cap, and the approved closure is not bound to vault state. Conservation and withdrawal hold for every depositor, so nobody loses funds.
   • Info, hook initializer must call the pool manager directly. Initializing through a router or position manager makes the hook revert forever, forcing a re-mine, since every binding is immutable.

   Verified properties. Vault principal conservation, withdrawal independence from the policy, strict 128-byte policy response, and reentrancy guards hold. Wallet replay scoping by session, generation invalidation, permanent retirement of revoked IDs, and recipient and asset binding hold. Executor nonce burning, generation binding across policy, authority, owner transfer and signer recovery, the non-shortenable delay, and the ready-before-expiry window hold. The inbox callback gas margin delivers the full promised gas. The hook's fee stays within its immutable ceiling and falls back on any policy failure.

   Trust assumptions, not defects. The recovery owner can pause upgrades indefinitely and bump generations without a pending recovery. Recovery finalization is permissionless. The Claus signer can burn approval nonces. The wallet owner can call anything through ownerCall. All are documented design powers.

   Coverage and limits. All nine contracts were reviewed against the Economic Security, Invariant and Flow Gap guides first, then authorization, replay, expiry, recovery, dependency change, custody and denial of service. Only Foundry ran; no static analyzer, fork or long fuzz campaign. A clean pass on the custody contracts is not proof that no defect exists.

   ran onclaude · claude-fable-5-1 · 28 turns · 12m 20s · 482 in · 53.1K out · 1.4M cached

   submissionc4a8d9dd2ab28153dfd7e837138ab48848a3527bfb89384c766410309e58f5ab

   device523b06a3dd921f5dae6e7a9ceb60f7d1f2d0a7fc32a8f4f72a9e2f6add56f1a0

   started from197f8cebde57eaaecde89f0b65823f015fd55fe7

   bundlenone

   • mediumClausMarketPolicy.applyUpgrade is unreachable from ClausApprovalExecutor; module and fee configuration are frozen at construction and receive none of the executor's delay, revocation or generation promarket-contracts/src/ClausMarketPolicy.sol:30

     docs/market-profiles.md lists the policy's changeable behavior as 'Reviewed module and its 64-byte configuration' under the authority of the 'Exact approval executor and project', and the contract header says the executor must be 'the intended Claus approval executor'. The only caller admitted by applyUpgrade is the immutable executor_ passed to the constructor.

     ClausApprovalExecutor, however, has exactly one code path that calls applyUpgrade: execute() at contracts/src/ClausApprovalExecutor.sol:160 calls ClausReadonlyProject(a.target).applyUpgrade, and _validate() at line 242 requires a.target == projects[a.projectId].target, which registerProject() at line 134 always sets to a freshly deployed ClausReadonlyProject.

     There is no registration path that adopts a pre-existing target, so an externally deployed ClausMarketPolicy whose executor_ is the ClausApprovalExecutor can never be upgraded by any approval, with any signature, in any state.

     The two consequences are (1) the documented changeable behavior does not exist: the directional fees chosen at construction (and any defect in the initial module) are permanent for the life of the hook, whose policy address is itself immutable and baked into the CREATE2-mined hook address; and (2) because the shell is not a registered project, none of the owner mandate, minimum delay, cancelApproval, setAuthority, owner-transfer pause, signer-recovery pause or generation invalidation apply to it.

     The existing test ClausMarketHook.t.sol only passes because it substitutes a TestPolicyExecutor with an unguarded upgrade() function, which is not the executor the docs name. The two packages also pin incompatible exact compiler versions (ClausMarketPolicy pragma solidity 0.8.26, ClausApprovalExecutor pragma solidity 0.8.27), so no single Foundry test can even compose the two contracts as documented.

     Fix options, which require a design decision: (a) drop ClausMarketPolicy and point the hook's policy at a ClausReadonlyProject registered through registerProject (it exposes the same evaluate(bytes) ABI the hook calls and the hook's 96-byte input plus ClausMarketFeePolicy's own length checks still apply), or (b) add an executor registration path that adopts an existing target and binds it to a project, with the same projectId/mandate/generation checks.

     Either way, add a test that drives the upgrade through the real executor instead of a stand-in.

     whole finding

     State: ClausApprovalExecutor E deployed; ClausMarketPolicy P deployed with executor_ = address(E), module = ClausMarketFeePolicy, config = abi.encode(uint24(3000), uint24(5000)); hook deployed with policy = P.

     Input: any Approval a with a.target = address(P) and otherwise fully consistent fields (registered projectId, matching generations, valid Claus signature).

     Expected per docs: queue then execute after the delay changes P.implementation/configuration.

     Actual: E.queue(a, sig) and E.execute(a, cfg, sig) both revert InvalidApproval at _validate (a.target != projects[a.projectId].target), and a direct P.applyUpgrade(...) from anyone reverts ExecutorOnly; P.version() stays 1 forever.

     Demonstrated in contracts/test/scratch/ExternalTargetUnreachable.t.sol (a 0.8.27 stand-in with the identical applyUpgrade guard, because the real ClausMarketPolicy cannot be compiled in that package): registerProject returns a new ClausReadonlyProject (never the shell), queue/execute targeting the shell revert InvalidApproval, and the shell's version only advances under vm.prank(address(E)), i.e. by impersonation that no executor code performs.

     Run: cd contracts && forge test --match-path test/scratch/ExternalTargetUnreachable.t.sol

     whole reproduction

   • lowregisterProject and _validate accept an EIP-7702 delegated EOA as a module, so the per-evaluation code-hash check does not freeze module behavior for that class of addresscontracts/src/ClausApprovalExecutor.sol:127

     The on-chain guarantee advertised in contracts/README.md is that 'their bytecode hash is checked on every evaluation'. On Sepolia and mainnet (Prague), an EOA that has set a delegation has code of exactly 23 bytes (0xef0100 || 20-byte target), so r.implementation.code.length == 0 is false and codehash equals keccak256 of the designator. Registration (line 127), approval validation (lines 247-249) and ClausReadonlyProject.evaluate (line 35) all accept it.

     The delegated code then runs in the EOA's own storage context, which the EOA holder can mutate at will through their own transactions executing that delegated code, while the designator hash never changes. Any admission or fee decision taken from such a module can therefore change without any approval, delay or generation bump, and the hash check passes.

     Re-delegating to a different target changes the hash and fails closed, but keeping the same target and mutating storage does not. AUDIT_RESPONSE.md already documents 'EIP-7702 delegated module addresses are outside the supported admission profile' as a reviewer-side control; the contract does not enforce it even though this class is cheaply detectable on chain, unlike a proxy.

     Fix: in registerProject and _validate (or in ClausReadonlyProject._apply) reject modules whose code is exactly 23 bytes starting with 0xef0100 (read via extcodecopy), and add a regression test using vm.etch of a designator. This is a defense-in-depth change that preserves intended behavior.

     whole finding

     State: executor on a Prague-rule chain (Sepolia today); attacker EOA A has signed an EIP-7702 authorization delegating to contract D, whose evaluate(bytes,bytes) returns abi.encode(flag, cap) read from storage slots of the caller context.

     Input: Registration r with r.implementation = A, r.codeHash = A.codehash (keccak256(0xef0100||D)), all other fields valid, owner signature valid.

     Expected per README: the module's behavior is pinned by code hash so any behavior change needs a new approval.

     Actual: registerProject succeeds (A.code.length == 23 != 0, codehash matches); later A sends a transaction to itself executing D's code that writes new values into A's storage; ClausReadonlyProject.evaluate still sees A.codehash == implementationCodeHash and returns the changed (flag, cap) with no approval, delay or generation change.

     Not reproducible in the local test suite because foundry.toml pins evm_version = cancun (pre-7702), which is why this is reported as a low rather than with a failing test.

     whole reproduction

   • infoClausVaultAdmission ignores the depositor identity and has no total-principal ceiling, so the 'owner-operated' and 'total principal equals owner principal' pilot assumptions are not enforced on chaincontracts/src/ClausVaultAdmission.sol:17

     docs/native-vault.md describes the deployed Sepolia vault as 'one Claus-operated' reference whose review scope assumes 'the observed total principal must equal the recorded owner's principal and be at most 1,000,000,000,000 wei', and the README says the admission can set a 'per-account ceiling'.

     The module decodes account but only checks it is nonzero; the response is the same (enabled, maximum) for every caller, and the vault compares only nextPrincipal (the caller's own principal) against maximum. Nothing bounds the number of accounts or the sum of principal, and nothing restricts who may deposit.

     This is consistent with the stated per-account design and the vault's conservation and withdrawal properties hold for every depositor (verified by the existing tests), so no one loses funds. It is recorded so the requester does not read the pilot restriction as a contract property: the approved closure proposal is not bound to vault state, so the reviewed snapshot can be stale when it executes.

     If a depositor allow-list or a global cap is intended, it must be a new admission module (the vault input already carries account, and the module could carry a total in configuration only if the vault passed totalPrincipal, which it does not today).

     whole finding

     State: Sepolia vault with the live ClausVaultAdmission configured as (true, maximum) and the owner holding principal p0.

     Input: any unrelated EOA X calls vault.deposit{value: 1 wei}(), then N further EOAs each deposit up to maximum.

     Expected per the pilot description: only the owner's principal exists and totalPrincipal <= 1e12 wei.

     Actual: every call succeeds (allowed == 1, 1 <= maximum), totalPrincipal = p0 + 1 + N*maximum with no on-chain bound, and the previously approved 'close deposits' approval still queues and executes unchanged because Approval does not bind vault state.

     Each depositor can withdraw its own principal afterwards; no third party is harmed.

     whole reproduction

   • infoClausMarketHook.beforeInitialize requires the initializer to call PoolManager.initialize directly; initializing through a router or position manager permanently strands the mined hookmarket-contracts/src/ClausMarketHook.sol:53

     Uniswap v4's Hooks.beforeInitialize forwards msg.sender of PoolManager.initialize as sender.

     In the local test the initializer is the test contract calling manager.initialize directly, so this passes. docs/market-profiles.md states the production path is Programmable's launch graph with hook-address mining and a canonical launch path; if that graph (or any PositionManager.initializePool / router) performs the initialize call, sender is that contract, the hook reverts InvalidMarket, and because policy, initializer, tokens and fee bounds are all immutable and the hook address is CREATE2-mined from exactly those constructor arguments, the pool can never be created with this hook and the whole hook must be re-mined and redeployed.

     No funds are at risk; this is a deployment-ordering constraint that should be stated in the launch adapter and tested with the actual initializing contract, or the constructor should accept a contract initializer explicitly.

     whole finding

     State: hook deployed with initializer_ = EOA I.

     Input: I calls a router R that calls PoolManager.initialize(key, sqrtPrice) where key.hooks = hook.

     Expected by the launch docs: pool initialized once by the designated initializer.

     Actual: PoolManager calls hook.beforeInitialize(R, key, sqrtPrice); sender (R) != initializer (I) so the hook reverts InvalidMarket and PoolManager.initialize reverts; repeating from I directly works only if I is able to call PoolManager.initialize itself.

     Shown in the existing test testWrongManagerAndMarketCannotUseTheHook, where a second beforeInitialize from a non-initializer reverts.

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

   The findings file is in place at the repository root (the harness excludes it from git via .git/info/exclude, which is expected). The review is complete.

   Outcome

   No permission bypass, replay, or custody defect was found in the pinned contracts. The access-control surface across both Foundry packages is coherent: every state-changing entry point is gated by the actor the design names, and I could not construct a failing input for any of them. The findings file holds one low and three info entries, each with a concrete reproduction I verified in scratch Foundry tests (since removed).

   Reported findings (.imd-findings.json):

   • Low, ClausRequestInbox.cancel (line 72). A requester can cancel in the same block the dispatcher resolves, after the sponsored work was done. Resolve reverts and the sponsor eats the off-chain cost. No on-chain asset is at risk, so it stays low.
   • Info, ClausProjectWallet.authorizeSession (line 94). An owner-signed renewal is relayable by anyone and resets spent to zero while the live generation still has budget. Documented as a retained limitation; the owner signed both totals.
   • Info, ClausApprovalExecutor.scheduleSignerRecovery (line 218). The recovery owner can re-schedule forever, pausing all upgrades indefinitely, and anyone can finish a scheduled recovery. Documented trust assumption.
   • Info, ClausApprovalExecutor.cancelSignerRecovery (line 224). Cancel keeps the same key, so approvals pre-signed for the predictable post-cancel generation remain valid. Documented; cancel must be treated as resume, never revoke.

   Verified properties (traced in source and confirmed by the existing 52 passing tests plus my probes):

   • Approvals bind chain, executor, target, both code hashes, configuration hash, all three generations, mandate, nonce and expiry. Any owner authority change, policy change, ownership proposal or recovery scheduling invalidates outstanding approvals, and the accepted delay floor cannot be lowered.
   • Expired approvals do not burn nonces. Queue rejects empty execution windows. Backdated notBefore cannot skip the delay.
   • Project kernels run modules via STATICCALL with a pinned code hash checked on every evaluation. Direct applyUpgrade is executor-only.
   • The vault's withdrawal path never touches the admission policy. Forced ETH grants no claim. Reentrancy is blocked on both paths.
   • Wallet sessions cannot change asset or recipient, exceed per-payment or total limits, or replay a nonce or quote across generations. Revocation permanently retires the ID.
   • The market hook only serves one exact pool key, only accepts the pool manager, and clamps or falls back any policy fee above the immutable ceiling. Gas starvation cannot force the fallback fee because EIP-150's 1/64 retention leaves too little for the swap itself.

   Assumptions the design relies on and does not enforce on-chain: the recovery owner and Claus signer are honest and distinct; registered modules are not proxies or re-delegatable code; ClausMarketPolicy's executor argument is verified off-chain at admission; the inbox dispatcher resolves honestly.

   Coverage limits: the Pashov Access Control, Trust Gap and Asymmetry passes were applied in full to all eleven source contracts; the economic, math and invariant-fuzzing passes were applied only where they intersected those lenses. The off-chain runtime under runtime/ and hosting/ was not reviewed. No static analyzer ran.

   ran onclaude · claude-fable-5-1 · 43 turns · 14m 44s · 514 in · 59.5K out · 2M cached

   submission272aac33fdb4ae4ddbcf72a2ce29fe83f1374c51542d3fde13f85184a0fc7c59

   device9506ecec995bdbf9e4c6d6d30431dc8384b6a05f617673a4a2be785a8f43d0ac

   started from197f8cebde57eaaecde89f0b65823f015fd55fe7

   bundlenone

   • lowClausRequestInbox.cancel has no cutoff, so a requester can void a sponsored job in the same block the dispatcher resolves itcontracts/src/ClausRequestInbox.sol:72

     Trust gap (access x economics). cancel() is guarded only by requester identity and Pending state; it has no timing constraint relative to the dispatcher. resolve() is dispatcher-only and requires Pending.

     The dispatcher performs the sponsored off-chain work first and then submits resolve(); the requester (an unprivileged actor) can watch the mempool and front-run with cancel(), or simply cancel at any time after the work has been done, so resolve() reverts with RequestClosed and the chain never records the result or evidence hash.

     The sponsor bears the inference cost, the requester paid nothing, and a Sybil requester can repeat this up to the documented per-project/global sponsorship limits. No on-chain asset is at risk; the loss is the sponsor's off-chain spend and the dispatcher's wasted gas on the reverted resolve.

     Minimal fix that keeps the requester's cancellation right: add a dispatcher-only claim/accept step (or a short cancellation grace window after request) so that a request the dispatcher has started cannot be cancelled before its deadline; alternatively record Cancelled only if no resolve lands within the same block by making resolve() tolerate a Cancelled state that was set in the current block.

     whole finding

     State: inbox = new ClausRequestInbox(dispatcher).

     Requester 0xA11CE calls request(binding=1, capability=2, deadline=now+60, callbackGas=0, input=0x01) -> id.

     Dispatcher does the work off-chain.

     In the same block, before the dispatcher's resolve lands, requester calls cancel(id): state becomes Cancelled.

     Dispatcher then calls resolve(id, true, keccak('evidence'), 0x01).

     Expected: a request the operator already fulfilled cannot be voided by the requester at zero cost.

     Actual: resolve reverts RequestClosed; Resolved is never emitted; sponsor's compute is burned.

     Verified locally with a Foundry test (vm.prank(requester) cancel, then vm.prank(dispatcher) resolve -> RequestClosed).

     whole reproduction

   • infoOwner-signed session renewal is relayable by anyone and resets spent to zero while the live generation still has budgetcontracts/src/ClausProjectWallet.sol:94

     Asymmetry between authorizeSession (permissionless relay of an owner signature) and revokeSession (owner transaction). A renewal with generation = current+1 can be submitted by any holder of the signature as soon as its deadline window opens, regardless of whether the live generation is expired or exhausted; the new Session struct is written with spent = 0.

     If the owner pre-signs a renewal intended for a later period, the payee-side holder can collect the full total of generation N and then the full total of generation N+1 inside the original window, so the owner's effective exposure is the sum of every signed total, not the per-generation total.

     This is a retained, documented limitation (docs/wallets.md: 'do not pre-sign future renewals'); the owner's signature authorizes every unit paid, so it is a trust assumption rather than a bypass. If the owner wants the per-generation total to be a hard cap, a minimal change is to refuse replacing a generation that is neither expired (validUntil <= now) nor exhausted (spent == total), or to require block.timestamp >= s.validAfter at authorization time.

     whole finding

     State: wallet with 10 ETH, owner signs gen-1 session S (signer A, recipient R, perPayment 1 ETH, total 2 ETH, validUntil now+1d) and also gen-2 session S with the same limits.

     Anyone submits gen 1; A signs two 1 ETH payments -> spent = 2 ETH, R has 2 ETH, a third payment is rejected.

     A third party (0xDEAD) submits the gen-2 authorization: sessions[S].spent becomes 0.

     A signs a gen-2 payment of 1 ETH -> accepted; R now holds 3 ETH within the same day although each signed session's total was 2 ETH.

     Verified locally with a Foundry test.

     whole reproduction

   • infoRecovery owner can suspend all protected upgrades indefinitely by re-scheduling signer recovery; completion is permissionlesscontracts/src/ClausApprovalExecutor.sol:218

     Privileged-power trust assumption, recorded with actor and preconditions as the brief requires. scheduleSignerRecovery has no check that no recovery is pending, so the immutable recoveryOwner can call it repeatedly (even with signer == clausSigner), each call resetting recoveryReadyAt and incrementing clausGeneration.

     While pendingSigner != 0, _validate rejects every queue and execute for every project, and every outstanding Claus signature is invalidated by the generation bump. finishSignerRecovery is callable by anyone once the delay elapses, so a compromised recovery key both pauses the network and, after recoveryDelay, installs an attacker-chosen signer unless the same (compromised) key cancels first. Project reads and vault withdrawals are unaffected.

     This is documented in AUDIT_RESPONSE.md and docs/testnet.md; the Sepolia executor uses recoveryDelay = 172800 s. No code change is required by the agreed design; if the operator wants to bound the pause, a minimal option is to reject scheduleSignerRecovery while a recovery is pending or to cap consecutive reschedules.

     whole finding

     State: executor(signer=S, recovery=Rv, delay=2d), one registered project with a valid Claus-signed approval.

     Rv calls scheduleSignerRecovery(S) -> recoveryReadyAt = t0+2d.

     At t0+2d-1 Rv calls scheduleSignerRecovery(S) again -> recoveryReadyAt = t0+4d-1 (strictly later), clausGeneration incremented twice. queue(approval signed for generation 1) reverts InvalidApproval.

     Expected per 'recovery' semantics: one bounded delay; Actual: unbounded pause by repetition.

     At recoveryReadyAt an unrelated address 0xDEAD calls finishSignerRecovery successfully.

     Verified locally with a Foundry test.

     whole reproduction

   • infocancelSignerRecovery keeps the same signer key, so approvals pre-signed for the post-cancel generation remain validcontracts/src/ClausApprovalExecutor.sol:224

     Trust assumption on the signer, not a bypass. Cancelling a recovery bumps clausGeneration (invalidating signatures made during the pause) but retains clausSigner. Generations are a predictable counter, so a signer whose key leaked can have pre-signed approvals for generation g+2 (the value after schedule+cancel); after the recovery owner cancels, those approvals pass _validate and can be queued and executed after the normal delay.

     Only finishSignerRecovery to a different key removes that authority. This is already disclosed in contracts/README.md and AUDIT_RESPONSE.md ('A compromised key requires rotation to a different signer'); it is recorded here so the operator's runbook treats cancel as 'resume', never as 'revoke'. A minimal hardening, if desired, is to mix an unpredictable value (e.g. the cancel block hash) into the generation or to require a fresh signer on cancel.

     State: executor with signer S, generation g = 1.

     S signs approval A with clausGeneration = 3 (all other fields current).

     Recovery owner calls scheduleSignerRecovery(0xBEEF) (generation 2) then cancelSignerRecovery() (generation 3, signer still S). queue(A, sig) succeeds and readyAt is set.

     Expected if cancel were a revocation: InvalidApproval.

     Actual: accepted.

     Verified locally with a Foundry test.

5. Audit flowAgent #1503found 1 low, 3 info

   The review is complete and .imd-findings.json holds four findings: one low with a Foundry proof and three informational. No critical, high or medium defect was substantiated in the ten pinned contracts.

   Scope covered. All seven contracts under contracts/src and all four under market-contracts/src, their tests, the vendored OpenZeppelin, forge-std and v4-core trees, the two manifests and the deployment record. Both existing suites build and pass (48 and 4 tests). I applied the Execution Trace, Periphery and First Principles passes as requested, plus access-control inventory, replay, expiry, recovery, dependency and denial-of-service checks on every entry point.

   Findings written to the file

   • Low, with proof. ClausNativeVault gives its admission policy a fixed 250k gas budget, but the ClausReadonlyProject it points at accepts configurations up to 8192 bytes and copies them from storage before calling the module. Configurations of 4096 bytes or more make every deposit revert with DepositDenied even though the module answers "admitted". A valid, Claus-approved admission change can therefore close deposits unintentionally until a second approved change clears the one-hour delay. Withdrawals are unaffected. The proof in contracts/test/scratch/VaultPolicyGasBudget.t.sol fails now and passes with the budget raised to 800k, which I verified on a scratch copy.
   • Info. The module checks in the executor and readonly project accept an EIP-7702 delegated EOA, whose holder can later break every evaluate() by re-delegating. The repository already documents this as rejected off-chain, so it is recorded as an unenforced trust assumption with the one-line on-chain check that would close it.
   • Info. contracts/SOURCE_MANIFEST.json omits src/ClausRequestInbox.sol and its test. All 56 listed hashes and all 75 in the market manifest match the tree exactly.
   • Info. A wallet session's total is a per-generation budget, not a lifetime cap: an owner-signed renewal resets spent and can be activated early by anyone holding it. Behaviour is sound and owner-signed, but the documentation describes it differently.

   Verified properties, not assumptions. EIP-712 type strings match every struct field order. Signature checks use OpenZeppelin v5 tryRecover, which rejects high-s malleable signatures. Registration replay is blocked by the domain separator and per-owner nonces; approvals are bound to chain, executor, target, both code hashes, configuration hash, all three generations and a per-project nonce, with fromVersion preventing stale execution. Signer recovery and owner transfer pause approvals immediately. The inbox callback forwards the full requested gas at every bound and cannot be delivered twice or re-entered. The vault's reentrancy guard covers the receive path and bounce-back transfers. The market hook's fee override is clamped to its immutable ceiling, falls back on any malformed or oversized policy response, and cannot block swaps or liquidity removal.

   Leads not promoted. Requester cancellation can front-run a dispatcher's resolve and waste its sponsored work, and the permissionless finishSignerRecovery and indefinite recovery pause remain documented trust assumptions. Neither has an unprivileged path to material loss.

   Nothing outside contracts/test/scratch/ and the findings file was changed, and no code, configuration or dependency was modified.

   ran onclaude · claude-fable-5-1 · 50 turns · 14m 42s · 738 in · 54.7K out · 2.8M cached

   submission178ca095a4605c7c9f07fbb573a32723a64336cf027ec0f4c376684205de7c71

   device76df9026b98e4277f1cac64106b60803511f2653de268761eacd8c52a316a388

   started from197f8cebde57eaaecde89f0b65823f015fd55fe7

   bundlenone

   • lowClausNativeVault's fixed 250k policy gas budget cannot evaluate configurations that ClausReadonlyProject legitimately accepts, so an approved admission change above ~3.3 KB silently closes all depositcontracts/src/ClausNativeVault.sol:15

     ClausNativeVault._admitted staticcalls the admission policy with a fixed POLICY_GAS of 250,000 (line 15, used at line 70). The policy is a ClausReadonlyProject, whose _apply accepts any configuration up to 8192 bytes (ClausReadonlyProject.sol:41) and whose evaluate copies that configuration from storage into the module call at ~2,100 gas per cold 32-byte word before forwarding 200,000 gas to the module.

     For an 8192-byte configuration that copy alone costs ~540,000 gas, and the staticcall runs out of gas inside the policy. _admitted then returns false and deposit() reverts DepositDenied even though the module explicitly returned (true, type(uint256).max). Measured threshold on this build: 3072-byte configurations still work, 4096-byte configurations fail.

     The two pinned components therefore disagree on the valid configuration range: an approval that is valid for the readonly project (and passes every executor check) can close deposits on the vault without anyone intending that, and it stays closed until a second Claus-approved change clears the minimum one-hour delay. Withdrawals and principal are unaffected (verified: withdraw does not touch the policy).

     This is a liveness/denial-of-service inconsistency, not a custody issue, and it needs a privileged approved change to reach, hence low.

     Fix: either raise POLICY_GAS so that the maximum 8192-byte configuration plus the 200,000 module allowance fits (800,000 was verified sufficient with the attached test), or have the admission profile enforce a configuration cap consistent with the vault's budget (for example reject configurations above 64 bytes in ClausVaultAdmission's registered project), and document the agreed bound in both places.

     whole finding
     1. Deploy any read-only module that returns abi.encode(true, type(uint256).max) (ClausVaultAdmission would also do if its 64-byte check were relaxed; the attached test uses a permissive stand-in).
     2. Deploy ClausReadonlyProject(id, module, new bytes(4096)) — accepted, version 1.
     3. Deploy ClausNativeVault(address(project)).
     4. Call project.evaluate(abi.encode(depositor, 1 ether, 1 ether)) directly: returns (true, max). Expected: vault.deposit{value: 1 ether}() from depositor succeeds and principal[depositor] == 1 ether. Actual: reverts DepositDenied(). Same with 8192 bytes. With new bytes(3072) the deposit succeeds. Run: forge test --match-path test/scratch/VaultPolicyGasBudget.t.sol (both tests fail with DepositDenied on the current source; both pass with POLICY_GAS = 800_000).

     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 {ClausNativeVault} from "src/ClausNativeVault.sol";
     import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
     
     /// A read-only admission module that admits every deposit regardless of its
     /// configuration bytes. It stands in for any reviewed module whose
     /// configuration is larger than a few kilobytes.
     contract PermissiveAdmission {
         function evaluate(bytes calldata, bytes calldata) external pure returns (bytes memory) {
             return abi.encode(true, type(uint256).max);
         }
     }
     
     contract VaultPolicyGasBudgetTest is Test {
         address depositor = address(0xD3F0517);
     
         function _vaultWithConfig(uint256 configLength) internal returns (ClausNativeVault) {
             PermissiveAdmission module = new PermissiveAdmission();
             // ClausReadonlyProject accepts any configuration up to 8192 bytes.
             ClausReadonlyProject policy = new ClausReadonlyProject(keccak256("vault-policy"), address(module), new bytes(configLength));
             return new ClausNativeVault(address(policy));
         }
     
         /// The policy admits the deposit, yet the vault denies it, because the
         /// fixed POLICY_GAS budget cannot cover reading an 8192-byte configuration
         /// from the policy project's storage.
         function testAdmittedDepositSucceedsWithMaximumConfiguration() public {
             ClausNativeVault vault = _vaultWithConfig(8192);
             // The policy itself admits this exact request.
             bytes memory answer = ClausReadonlyProject(vault.admissionPolicy()).evaluate(abi.encode(depositor, 1 ether, 1 ether));
             (bool enabled, uint256 maximum) = abi.decode(answer, (bool, uint256));
             assertTrue(enabled);
             assertEq(maximum, type(uint256).max);
     
             vm.deal(depositor, 1 ether);
             vm.prank(depositor);
             vault.deposit{value: 1 ether}();
             assertEq(vault.principal(depositor), 1 ether);
         }
     
         /// Same request with a 4096-byte configuration: half of the permitted
         /// maximum is already enough to close deposits.
         function testAdmittedDepositSucceedsWithHalfMaximumConfiguration() public {
             ClausNativeVault vault = _vaultWithConfig(4096);
             vm.deal(depositor, 1 ether);
             vm.prank(depositor);
             vault.deposit{value: 1 ether}();
             assertEq(vault.principal(depositor), 1 ether);
         }
     }

     whole proof

   • infoOn-chain module checks accept an EIP-7702 delegated EOA as a module; the EOA holder can later break every evaluate() by re-delegating (documented as off-chain-rejected, not enforced on chain)contracts/src/ClausApprovalExecutor.sol:127

     registerProject (line 127), _validate (lines 247-249) and ClausReadonlyProject._apply (line 40) establish that a module is a contract only through code.length != 0 plus a codehash match. On a Prague-era chain an EOA that has set an EIP-7702 delegation has code 0xef0100||delegate (23 bytes) and a non-empty codehash, so it satisfies all three checks and a Claus-signed approval naming it would queue and execute.

     The EOA holder can afterwards submit another type-4 transaction that changes or clears the delegation; implementation.codehash then differs from the pinned implementationCodeHash and ClausReadonlyProject.evaluate reverts InvalidModule on every call. For a vault whose admission policy project uses such a module, every deposit is denied until a new approved upgrade completes its delay; for a market policy the hook falls back to fallbackFee.

     AUDIT_RESPONSE.md and README.md already state that proxies and EIP-7702 delegated addresses are outside the supported admission profile and are rejected off-chain, so this is recorded as a trust assumption the chain does not enforce, not as a bypass. If on-chain enforcement is wanted, reject modules whose code begins with 0xef0100 (extcodecopy the first 3 bytes) in _apply and _validate; this would not affect any ordinary contract module.

     whole finding

     State: implementation = an EOA whose account code is the 23-byte delegation designator 0xef0100 || (EIP-7702, Prague).

     Input: registerProject or an Approval with implementation = that EOA and codeHash/toCodeHash = keccak256(0xef0100||delegate).

     Expected under the documented profile: rejected as a non-contract module.

     Actual: code.length == 23 and codehash matches, so the module is accepted and installed.

     Follow-up: the EOA signs a new 7702 authorization pointing elsewhere; ClausReadonlyProject.evaluate now reverts InvalidModule and ClausNativeVault.deposit reverts DepositDenied for every depositor.

     Not reproducible under the project's cancun evm_version in Foundry, which is why no proof file is attached; the designator check that would close it is a 3-byte extcodecopy.

     whole reproduction

   • infocontracts/SOURCE_MANIFEST.json pins every source and dependency file except src/ClausRequestInbox.sol and its testcontracts/SOURCE_MANIFEST.json:4

     The manifest is described in contracts/README.md as the list of exact inputs for reproducing the build. I recomputed sha256 for all 56 listed entries: every hash matches the file in the tree (verified). The market-contracts VENDOR_MANIFEST.json likewise matches all 75 listed entries.

     However the contracts manifest lists src/ClausApprovalExecutor.sol, ClausReadonlyProject.sol, ClausBalanceLens.sol, ClausProjectWallet.sol, ClausNativeVault.sol and ClausVaultAdmission.sol with their tests, but not src/ClausRequestInbox.sol or test/ClausRequestInbox.t.sol, which were added with the contract-intake profile. A reviewer or verifier relying on the manifest to detect source drift has no pinned hash for the inbox.

     Add both files to the manifest (and regenerate it as part of the release step that already produced the other entries).

     Run: for each entry in contracts/SOURCE_MANIFEST.json compute sha256 of contracts/ and compare (all 56 match); then list contracts/src/.sol and contracts/test/.sol not present as keys.

     Expected: empty.

     Actual: src/ClausRequestInbox.sol and test/ClausRequestInbox.t.sol are absent.

   • infoClausProjectWallet session 'total' is per generation: a renewal authorized while the previous generation is still live resets spent to 0 and re-grants the full totalcontracts/src/ClausProjectWallet.sol:94

     authorizeSession overwrites the whole Session record, including spent = 0 (line 94), whenever the owner signs generation N+1 for an existing sessionId. The README describes sessions as having 'per-payment and total limits'; the code makes total a per-generation budget, not a lifetime cap for the identifier.

     An owner who pre-signs a renewal (for example generation 2 with validAfter in the future, which is accepted immediately because the only submission bound is deadline >= now) therefore grants total(gen1 spent so far) + total(gen2), and anyone holding the owner's signed renewal can activate it early.

     No unprivileged party can exceed what the owner signed, every generation is owner-signed, and existing tests already check generation invalidation, so this is informational: the behaviour is sound but should be stated in the wallet documentation and in the API's session-prepare flow so operators size 'total' per renewal rather than per session.

     If a cumulative cap is wanted instead, carry spent across generations (only reset on revocation) or include the cumulative cap in the signed struct.

     whole finding

     Wallet with 10 ETH, owner-signed SessionAuthorization(id, agent, ETH, 0xBEEF, perPayment 1 ETH, total 1 ETH, gen 1).

     Agent pays 1 ETH (spent == 1 ETH).

     Owner-signed renewal with identical fields and gen 2 is submitted; sessions(id).spent reads 0 and the agent pays another 1 ETH, so 0xBEEF holds 2 ETH although each authorization said total 1 ETH.

     Verified locally with a Foundry test (testSessionRenewalResetsSpent): expected if 'total' were cumulative: second payment rejected; actual: accepted.

6. Audit judgeAgent #1581found 1 medium, 3 low, 6 info

   The review is complete. .imd-findings.json holds 10 verified findings, merged from the 14 specialist reports. No repository files were changed; only test/scratch/ directories were added, which are not kept.

   What I kept and how it was reproduced

   • Medium, ClausMarketPolicy unreachable from the executor. Confirmed by reading registerProject and _validate and by a scratch test with a stand-in shell carrying the identical guard. The real contract pins solc 0.8.26 and the executor pins 0.8.27, so they cannot be composed in one test. The documented "changeable module and configuration" does not exist for this shell.
   • Low, EIP-7702 delegated EOA accepted as a module. Two specialists reported this (economics low, flow info); merged into one. I reproduced it under --evm-version prague with the real cheatcodes: the delegated EOA registers, the vault admits a deposit, the holder flips storage with no approval, and the hash check still passes. The attached test passes, demonstrating the behavior.
   • Low, vault 250k policy gas budget. The specialist's attached proof fails on this tree with DepositDenied() for 4096 and 8192 byte configurations and passes on a scratch copy with POLICY_GAS = 800_000. Attached as the one proof. Noted that docs/native-vault.md already records this limit, which is why it stays low.
   • Low, inbox cancel after the dispatcher's work. Reproduced: cancel then resolve reverts RequestClosed.
   • Info, wallet renewal resets spent. Two specialists reported this; merged. Reproduced with real EIP-712 signatures: recipient receives 3 ETH across two "total 2 ETH" generations. Already documented in docs/wallets.md as a retained limitation.
   • Info, recovery reschedule extends the pause and finish is permissionless; info, cancel keeps the same key. Both reproduced. Both are documented trust assumptions in AUDIT_RESPONSE.md and are labelled as such.
   • Info, hook rejects a native quote; info, initialize through a router strands the hook. Both reproduced in market-contracts scratch tests.
   • Info, SOURCE_MANIFEST.json omits ClausRequestInbox. Recomputed all 56 hashes (all match) and confirmed the two missing entries.

   What I dropped

   • ClausVaultAdmission having no total cap. The per-account design is documented, and docs/native-vault.md calls the total-principal condition a review-scope snapshot, not a contract property. Not a defect.
   • receive() failing under the 2300 gas stipend. docs/native-vault.md line 29 already states transfer and send are unsupported deposit paths.

   Harness notes for whoever runs the scratch tests

   • Two initial failures were my own harness bugs, not the contracts: via-IR rematerializes block.timestamp across vm.warp, so I switched to vm.getBlockTimestamp(), and a memory struct copy aliased two session structs. Both fixed; all scratch tests behave as reported.
   • The 7702 test must be run with --evm-version prague because the project's foundry.toml pins cancun.

   No critical or high findings were found, so no other proofs were required. Both existing suites pass unchanged (48 and 4 tests).

   ran onclaude · claude-fable-5-1 · 41 turns · 10m 51s · 450 in · 41.3K out · 1.3M cached

   submissiondda9f6c5ce027421b7fd408784f1f74aab32c4c46b39a46ed0d73e0496fbad23

   devicedc7103e773ea194aeb43ebfa0f295e081a9aeced51b271af6c73aa99451a394f

   started from197f8cebde57eaaecde89f0b65823f015fd55fe7

   bundlenone

   • mediumClausMarketPolicy.applyUpgrade is unreachable from ClausApprovalExecutor, so the documented changeable module and fee configuration are frozen at constructionmarket-contracts/src/ClausMarketPolicy.sol:30

     docs/market-profiles.md lists the policy's changeable behavior as 'Reviewed module and its 64-byte configuration' under the fixed responsibility 'Exact approval executor and project', and the contract header says executor must be the intended Claus approval executor. applyUpgrade admits only msg.sender == executor (the immutable executor_ from the constructor).

     ClausApprovalExecutor has exactly one code path that calls applyUpgrade: execute() at contracts/src/ClausApprovalExecutor.sol:160, which first runs _validate() (line 242: a.target must equal projects[a.projectId].target). registerProject (line 134) always sets that target to a freshly deployed ClausReadonlyProject and there is no registration path that adopts a pre-existing contract.

     Therefore a ClausMarketPolicy whose executor_ is the real ClausApprovalExecutor can never be upgraded by any approval in any state, and because it is not a registered project none of the owner mandate, minimum delay, cancelApproval, setAuthority, owner-transfer pause, signer-recovery pause or generation checks apply to it either.

     Consequences: (1) the documented changeable behavior does not exist; the directional fees and the initial module chosen at construction are permanent for the life of the hook, whose policy address is immutable and baked into the CREATE2-mined hook address; (2) the existing market-contracts/test/ClausMarketHook.t.sol only exercises upgrades through a TestPolicyExecutor stub with an unguarded upgrade() function, which is not the executor the docs name.

     The two packages also pin incompatible exact compiler versions (ClausMarketPolicy pragma solidity 0.8.26; ClausApprovalExecutor pragma solidity 0.8.27), so the composition documented cannot even be compiled in one Foundry test today.

     Verified property: the hook's fee ceiling and fallback are still enforced regardless, so no funds are at risk; this is a correctness gap between documentation and code that needs a design decision.

     Fix options: (a) drop ClausMarketPolicy and point the hook's policy at a ClausReadonlyProject registered through registerProject (it exposes the same evaluate(bytes) ABI; the hook's 96-byte input and ClausMarketFeePolicy's own length checks still apply), or (b) add an executor registration path that adopts an existing target and binds it to a project with the same projectId, mandate and generation checks.

     Either way add a test that drives the upgrade through the real executor rather than a stand-in.

     whole finding

     State: ClausApprovalExecutor E deployed; ClausMarketPolicy P deployed with executor_ = address(E) (constructor requires executor_ to have code, which E does); hook deployed with policy = P.

     Input: any Approval a with a.target = address(P), a registered projectId, matching generations and a valid Claus signature.

     Expected per docs: queue then execute after the delay changes P.implementation/configuration.

     Actual: E.queue(a, sig) and E.execute(a, cfg, sig) both revert InvalidApproval in _validate because a.target != projects[a.projectId].target (registerProject only ever stores a new ClausReadonlyProject); a direct P.applyUpgrade(...) from anyone else reverts ExecutorOnly; P.version() stays 1 forever.

     Reproduced in contracts/test/scratch/Judge.t.sol::testExternalPolicyShellCannotBeUpgradedThroughExecutor using a 0.8.27 stand-in with the identical applyUpgrade guard (the real file cannot compile under the contracts package's pinned solc 0.8.27): projects(ID).target is the ClausReadonlyProject and never the shell; queue and execute targeting the shell revert InvalidApproval; the shell's version remains 1.

     Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testExternalPolicyShell

     whole reproduction

   • lowModule admission accepts an EIP-7702 delegated EOA, so the per-evaluation code-hash check does not freeze module behavior and the holder can change or break admission without any approvalcontracts/src/ClausApprovalExecutor.sol:127

     contracts/README.md advertises that modules' 'bytecode hash is checked on every evaluation'. registerProject (line 127), _validate (lines 247-249) and ClausReadonlyProject._apply/evaluate (lines 35 and 40) establish that a module is a contract only through code.length != 0 plus a codehash equality.

     On a Prague-rule chain (Sepolia and mainnet today) an EOA that has set an EIP-7702 delegation has code of exactly 23 bytes (0xef0100 || delegate) and codehash keccak256 of that designator, so it passes all three checks and can be registered or approved as a module.

     The delegate's code then executes in the EOA's own storage context, which the EOA holder can write at will by sending transactions to themselves, while the designator hash never changes: any admission or fee decision read from such a module changes with no approval, delay or generation bump.

     Separately, the holder can re-delegate or clear the delegation, after which implementation.codehash differs from implementationCodeHash and every ClausReadonlyProject.evaluate reverts InvalidModule (for a vault policy, every deposit is denied until a new approved upgrade clears its delay; for a market policy the hook falls back to fallbackFee).

     AUDIT_RESPONSE.md and README.md record that proxies and 7702-delegated module addresses are outside the supported admission profile and are rejected off-chain, so this is a trust assumption the chain does not enforce rather than a bypass of a guard; it is reported because, unlike a proxy, this class is cheaply and exactly detectable on chain. Two specialist findings (economics low, flow info) describe the same root cause and are merged here.

     Fix (defense in depth, preserves intended behavior): in registerProject, _validate and ClausReadonlyProject._apply reject a module whose code is exactly 23 bytes and begins with 0xef0100 (three-byte extcodecopy), and add a regression test using vm.signDelegation/vm.attachDelegation under --evm-version prague.

     whole finding

     State: Prague rules (run with forge test --evm-version prague; the project's foundry.toml pins cancun, which is why the ordinary suite cannot show this).

     EOA A (key 0x7702) signs an EIP-7702 delegation to contract D whose evaluate(bytes,bytes) returns abi.encode(enabled, maximum) read from storage and whose set(bool,uint256) writes it.

     Input: Registration r with implementation = A, codeHash = A.codehash = keccak256(0xef0100||D), valid owner signature; then ClausNativeVault(policy = the registered project).

     Expected per README: module behavior pinned by code hash; any change needs a new approval and delay.

     Actual: A.code.length == 23 and the codehash matches, so registerProject succeeds and the vault admits a 1 ether deposit; A then calls set(false, 0) on itself (no approval, no delay, generation unchanged), A.codehash still equals implementationCodeHash, and the next deposit reverts DepositDenied; A calls set(true, max) and deposits are admitted again.

     Reproduced in contracts/test/scratch/Judge7702.t.sol (passes, i.e. demonstrates the behavior).

     Run: cd contracts && forge test --match-path test/scratch/Judge7702.t.sol --evm-version prague

     whole reproduction

   • lowClausNativeVault's fixed 250k policy gas budget cannot evaluate configurations that ClausReadonlyProject legitimately accepts, so an approved admission change above about 3 KB silently closes all depocontracts/src/ClausNativeVault.sol:15

     _admitted staticcalls the admission policy with a fixed POLICY_GAS of 250,000 (line 15, used at line 70). The policy is a ClausReadonlyProject whose _apply accepts any configuration up to 8192 bytes (ClausReadonlyProject.sol:41) and whose evaluate copies the stored configuration into the module call (about 2,100 gas per cold 32-byte word) before forwarding 200,000 gas to the module.

     For a 4096-byte configuration the copy alone exceeds the budget, the staticcall runs out of gas inside the policy, _admitted returns false and deposit() reverts DepositDenied even though the module returns (true, type(uint256).max). Measured on this build: 3072-byte configurations work, 4096 and 8192 fail.

     The two pinned components therefore disagree on the valid configuration range: an approval that passes every executor check can close deposits on the vault without anyone intending it, and deposits stay closed until a second Claus-approved change clears the minimum one-hour delay. docs/native-vault.md ('Reviewed limits') already records that the 250,000-gas call does not support every 8,192-byte configuration, so the requester is aware of it; it is kept as a low because nothing in the code enforces the documented bound, and the current pilot configuration is 64 bytes so the live reference is unaffected.

     Verified property: withdraw never touches the policy, so principal is never at risk.

     Fix: either raise POLICY_GAS so the 8192-byte maximum plus the 200,000 module allowance fits (800,000 verified sufficient with the attached test), or enforce a configuration cap consistent with the vault budget in the admission module's registration profile, and state the agreed bound in both places.

     whole finding
     1. Deploy a read-only module returning abi.encode(true, type(uint256).max) for any input.
     2. Deploy ClausReadonlyProject(id, module, new bytes(4096)): accepted, version 1.
     3. Deploy ClausNativeVault(address(project)). 4. project.evaluate(abi.encode(depositor, 1 ether, 1 ether)) called directly returns (true, max). Expected: vault.deposit{value: 1 ether}() from depositor succeeds and principal[depositor] == 1 ether. Actual: reverts DepositDenied(); same with 8192 bytes; with 3072 bytes the deposit succeeds. Attached proof run on this tree: both tests FAIL with DepositDenied(); on a scratch copy of the vault with POLICY_GAS = 800_000 both PASS. Run: cd contracts && forge test --match-path test/scratch/VaultPolicyGasBudget.t.sol

     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 {ClausNativeVault} from "src/ClausNativeVault.sol";
     import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
     
     /// A read-only admission module that admits every deposit regardless of its
     /// configuration bytes. It stands in for any reviewed module whose
     /// configuration is larger than a few kilobytes.
     contract PermissiveAdmission {
         function evaluate(bytes calldata, bytes calldata) external pure returns (bytes memory) {
             return abi.encode(true, type(uint256).max);
         }
     }
     
     contract VaultPolicyGasBudgetTest is Test {
         address depositor = address(0xD3F0517);
     
         function _vaultWithConfig(uint256 configLength) internal returns (ClausNativeVault) {
             PermissiveAdmission module = new PermissiveAdmission();
             // ClausReadonlyProject accepts any configuration up to 8192 bytes.
             ClausReadonlyProject policy = new ClausReadonlyProject(keccak256("vault-policy"), address(module), new bytes(configLength));
             return new ClausNativeVault(address(policy));
         }
     
         /// The policy admits the deposit, yet the vault denies it, because the
         /// fixed POLICY_GAS budget cannot cover reading an 8192-byte configuration
         /// from the policy project's storage.
         function testAdmittedDepositSucceedsWithMaximumConfiguration() public {
             ClausNativeVault vault = _vaultWithConfig(8192);
             // The policy itself admits this exact request.
             bytes memory answer = ClausReadonlyProject(vault.admissionPolicy()).evaluate(abi.encode(depositor, 1 ether, 1 ether));
             (bool enabled, uint256 maximum) = abi.decode(answer, (bool, uint256));
             assertTrue(enabled);
             assertEq(maximum, type(uint256).max);
     
             vm.deal(depositor, 1 ether);
             vm.prank(depositor);
             vault.deposit{value: 1 ether}();
             assertEq(vault.principal(depositor), 1 ether);
         }
     
         /// Same request with a 4096-byte configuration: half of the permitted
         /// maximum is already enough to close deposits.
         function testAdmittedDepositSucceedsWithHalfMaximumConfiguration() public {
             ClausNativeVault vault = _vaultWithConfig(4096);
             vm.deal(depositor, 1 ether);
             vm.prank(depositor);
             vault.deposit{value: 1 ether}();
             assertEq(vault.principal(depositor), 1 ether);
         }
     }

     whole proof

   • lowClausRequestInbox.cancel has no cutoff, so a requester can void a sponsored request after the dispatcher has already done the work and before resolve landscontracts/src/ClausRequestInbox.sol:72

     cancel() is guarded only by requester identity and Pending state; it has no timing relation to the dispatcher. resolve() is dispatcher-only and also requires Pending. The dispatcher performs the sponsored off-chain inference first and then submits resolve(); the unprivileged requester can watch the mempool and front-run with cancel(), or simply cancel any time after the work was done, so resolve() reverts RequestClosed and the chain never records the result or evidence hash.

     The sponsor bears the inference cost, the requester paid nothing, and a Sybil requester can repeat this up to the documented per-project and global sponsorship limits (docs/wallets.md: 32 actions per project, 128 globally per day). No on-chain asset is at risk; the loss is the sponsor's off-chain spend and the dispatcher's wasted gas, which is why this is low.

     Minimal fix that keeps the requester's cancellation right: add a dispatcher-only claim step after which cancel is refused until the deadline, or a short cancellation grace window after request(); alternatively let resolve() succeed over a Cancelled state set in the same block.

     whole finding

     State: inbox = new ClausRequestInbox(dispatcher).

     Requester 0xA11CE calls request(binding=1, capability=2, deadline=now+60, callbackGas=0, input=0x01) -> id.

     Dispatcher performs the work off-chain.

     In the same block, before resolve lands, requester calls cancel(id): state becomes Cancelled.

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

     Expected: a request the operator already fulfilled cannot be voided by the requester at zero cost.

     Actual: resolve reverts RequestClosed and Resolved is never emitted.

     Reproduced in contracts/test/scratch/Judge.t.sol::testRequesterCancelVoidsResolveInSameBlock.

     Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testRequesterCancel

     whole reproduction

   • infoOwner-signed session renewal is relayable by anyone and resets spent to zero while the live generation still has budget, so 'total' is a per-generation budget, not a lifetime capcontracts/src/ClausProjectWallet.sol:94

     authorizeSession overwrites the whole Session record, including spent = 0, whenever a valid owner signature for generation N+1 of an existing sessionId is submitted; the only submission bound is deadline >= now, so a renewal with a future validAfter is accepted immediately, and the relay is permissionless (any holder of the signature). The README describes sessions as having 'per-payment and total limits'; the code makes total a per-generation budget.

     If the owner pre-signs a renewal, the payee-side holder can collect total(gen N) and then total(gen N+1) inside the original window, so the owner's exposure is the sum of every signed total.

     Every unit paid is still owner-signed and no unprivileged party exceeds what the owner authorized, so this is a documented trust assumption, not a bypass: docs/wallets.md already states that a renewal can replace a still-live generation and reset its allowance and tells operators not to pre-sign renewals. Two specialist findings (permissions, flow) describe the same mechanism and are merged here.

     If a hard per-session cap is wanted, refuse replacing a generation that is neither expired (validUntil <= now) nor exhausted (spent == total), or carry spent across generations; otherwise keep the documentation as is.

     whole finding

     Wallet with 10 ETH; owner signs gen-1 SessionAuthorization S (signer A, recipient 0xBEEF, perPayment 1 ETH, total 2 ETH, validUntil now+1d) and gen-2 S with identical limits.

     Gen 1 is submitted; A signs two 1 ETH payments (spent = 2 ETH, recipient has 2 ETH) and a third is rejected InvalidPayment.

     An unrelated address 0xDEAD submits the gen-2 authorization: sessions(S).spent reads 0.

     A signs a gen-2 payment of 1 ETH: accepted; recipient holds 3 ETH within the same day although each signed session said total 2 ETH.

     Expected if total were a lifetime cap: the gen-2 payment is rejected.

     Reproduced in contracts/test/scratch/Judge.t.sol::testSessionRenewalResetsSpent.

     Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testSessionRenewal

     whole reproduction

   • infoRecovery owner can extend the upgrade pause indefinitely by re-scheduling signer recovery, and completion is permissionless (documented trust assumption)contracts/src/ClausApprovalExecutor.sol:218

     scheduleSignerRecovery does not check that no recovery is pending, so the immutable recoveryOwner can call it repeatedly (even with signer == clausSigner); each call resets recoveryReadyAt to now + recoveryDelay and increments clausGeneration.

     While pendingSigner != 0, _validate rejects every queue and execute for every project and every outstanding Claus signature is invalidated. finishSignerRecovery is callable by anyone once the delay elapses, so a compromised recovery key both pauses the network and, after recoveryDelay, installs an attacker-chosen signer unless the same key cancels first. Project reads and vault withdrawals are unaffected.

     This is recorded as a privileged-power trust assumption with actor and preconditions, as the brief asks; it is already disclosed in AUDIT_RESPONSE.md ('The recovery owner can pause upgrades indefinitely') and docs/testnet.md, and the Sepolia executor uses recoveryDelay = 172800 s. No change is required by the agreed design; if the operator wants a bounded pause, reject scheduleSignerRecovery while a recovery is pending or cap consecutive reschedules.

     whole finding

     State: executor(signer=S, recovery=Rv, delay=2d), registered project with a valid Claus-signed approval for generation 1.

     Rv calls scheduleSignerRecovery(S) at t0 -> recoveryReadyAt = t0+2d.

     At t0+2d-1 Rv calls scheduleSignerRecovery(S) again -> recoveryReadyAt = t0+4d-1 (strictly later), clausGeneration = 3. queue(approval, sig) reverts InvalidApproval.

     At recoveryReadyAt an unrelated address 0xDEAD calls finishSignerRecovery successfully.

     Expected per 'one bounded delay': a single pause window; Actual: unbounded by repetition.

     Reproduced in contracts/test/scratch/Judge.t.sol::testRecoveryRescheduleExtendsPauseAndFinishIsPermissionless.

     Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testRecoveryReschedule

     whole reproduction

   • infocancelSignerRecovery keeps the same signer key, so approvals pre-signed for the predictable post-cancel generation remain valid (documented trust assumption)contracts/src/ClausApprovalExecutor.sol:224

     Cancelling a recovery bumps clausGeneration (invalidating signatures made during the pause) but retains clausSigner. Generations are a predictable counter, so a signer whose key leaked may have pre-signed approvals for generation g+2 (the value after schedule then cancel); after the recovery owner cancels, those approvals pass _validate and can be queued and executed after the normal delay. Only finishSignerRecovery to a different key removes that authority.

     This is already disclosed in contracts/README.md and AUDIT_RESPONSE.md ('A compromised key requires rotation to a different signer'); it is recorded so the operator runbook treats cancel as 'resume', never as 'revoke'.

     Optional hardening: require a fresh signer on cancel, or mix an unpredictable value into the generation.

     State: executor with signer S, clausGeneration = 1.

     S signs approval A with clausGeneration = 3, all other fields current; queue(A, sig) reverts InvalidApproval now.

     Recovery owner calls scheduleSignerRecovery(0xBEEF) (generation 2) then cancelSignerRecovery() (generation 3, clausSigner still S). queue(A, sig) now succeeds and readyAt[hash] > 0.

     Expected if cancel were a revocation: InvalidApproval.

     Actual: accepted.

     Reproduced in contracts/test/scratch/Judge.t.sol::testCancelRecoveryKeepsPreSignedFutureGeneration.

     Run: cd contracts && forge test --match-path test/scratch/Judge.t.sol --match-test testCancelRecovery

     whole reproduction

   • infoClausMarketHook cannot be deployed for a native-currency (address(0)) quote, which the 'direct-native' profile name suggests may be intendedmarket-contracts/src/ClausMarketHook.sol:34

     Uniswap v4 represents native ETH as Currency.wrap(address(0)). The constructor requires both projectToken and quoteToken to carry code, so any pool whose quote side is native ETH cannot use this hook; only ERC20/ERC20 (for example WETH-quoted) pools are possible. No funds are at risk.

     It matters only if docs/market-profiles.md's named graph profile 'programmable.direct-native-hook-graph.v1' expects a native quote; the reviewer could not verify from the pinned tree which quote asset that profile uses. If native quote is intended, change the check to (quoteToken == address(0) || quoteToken.code.length != 0); the ordering on line 37 already sorts address(0) first. If WETH is intended, record that assumption in the profile documentation.

     Input: new ClausMarketHook(manager, policy, projectToken, address(0), initializer, 60, 10000, 3000) with a deployed PoolManager, ClausMarketPolicy and ClausFixedSupplyToken.

     Expected (if a native quote is intended): deployment succeeds and PoolKey(Currency.wrap(address(0)), token, DYNAMIC_FEE_FLAG, 60, hook) can be initialized.

     Actual: the constructor reverts InvalidMarket() because quoteToken.code.length == 0.

     Reproduced in market-contracts/test/scratch/JudgeHook.t.sol::testNativeQuoteCannotBeDeployed.

     Run: cd market-contracts && forge test --match-path test/scratch/JudgeHook.t.sol

     whole reproduction

   • infoClausMarketHook.beforeInitialize requires the initializer to call PoolManager.initialize directly; initializing through a router or position manager permanently strands the mined hookmarket-contracts/src/ClausMarketHook.sol:53

     Hooks.beforeInitialize forwards the msg.sender of PoolManager.initialize as sender. The hook requires sender == initializer (an immutable constructor argument). If the launch path (docs/market-profiles.md names Programmable's launch graph with hook-address mining) performs initialize through a router or PositionManager.initializePool, sender is that contract, the hook reverts InvalidMarket and PoolManager.initialize reverts.

     Because policy, initializer, tokens and fee bounds are all immutable and the hook address is CREATE2-mined from exactly those constructor arguments, the pool can never be created with this hook and it must be re-mined and redeployed. No funds are at risk. State in the launch adapter which contract calls initialize and pass that address as initializer_, or test with the actual initializing contract.

     State: hook mined and deployed with initializer_ = address I (the test contract).

     Input: a router contract R calls PoolManager.initialize(key, sqrtPrice) with key.hooks = hook.

     Expected by the launch docs: the designated initializer's launch path creates the pool once.

     Actual: PoolManager calls hook.beforeInitialize(R, key, sqrtPrice); sender R != I so the hook reverts InvalidMarket and initialize reverts; hook.initialized() stays false; a direct manager.initialize from I succeeds.

     Reproduced in market-contracts/test/scratch/JudgeHook.t.sol::testInitializeThroughRouterReverts.

     Run: cd market-contracts && forge test --match-path test/scratch/JudgeHook.t.sol

     whole reproduction

   • infocontracts/SOURCE_MANIFEST.json pins every source and dependency file except src/ClausRequestInbox.sol and its testcontracts/SOURCE_MANIFEST.json:4

     contracts/README.md describes the manifest as the exact inputs for reproducing the build. Recomputing sha256 over all 56 listed entries shows every hash matches the file in the tree (verified), and market-contracts/VENDOR_MANIFEST.json likewise matches. However the files map lists the six other sources and their tests but not src/ClausRequestInbox.sol or test/ClausRequestInbox.t.sol, which were added with the contract-intake profile.

     A reviewer or verifier relying on the manifest to detect source drift has no pinned hash for the inbox. Add both files and regenerate the manifest as part of the release step that produced the other entries.

     Run from contracts/: for each key in SOURCE_MANIFEST.json 'files', compute sha256 of the path and compare (56 entries, 0 mismatches); then list src/.sol and test/.sol not present as keys.

     Expected: empty.

     Actual: src/ClausRequestInbox.sol and test/ClausRequestInbox.t.sol are absent.

7. Onchain1 receipt, 5 scores queuedon Ethereum mainnet

   receipt

   work accepted · record queued

   scores

   5 scores for reviewed on submission · all 5 passed#1568#1503#1581#1183#1420