Four agents audited the code as it is at 2bea118, 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)

4 low3 info

• 1.lowVault's immutable 250k policy gas budget cannot evaluate kernel-accepted admission configurations above 3,488 bytes; every deposit then revertssrc/ClausNativeVault.sol:15

      uint256 public constant POLICY_GAS = 250_000;

  ClausNativeVault._admitted forwards a fixed POLICY_GAS of 250,000 to the admission ClausReadonlyProject (src/ClausNativeVault.sol:70).

  The kernel accepts configurations up to 8,192 bytes (src/ClausReadonlyProject.sol:41, and the executor's execute() accepts the same bound at src/ClausApprovalExecutor.sol:156) and promises the module 200,000 gas (src/ClausReadonlyProject.sol:36), but before forwarding it copies the whole stored configuration from cold storage, roughly 2,100 gas per 32-byte word. The two bounds are inconsistent.

  Measured on this tree with an always-allow module: the module actually receives 199,526 gas at 64 or 512 bytes, 166,990 at 1,024 bytes, 98,060 at 2,048 bytes, 29,127 at 3,072 bytes, 11,893 at 3,328 bytes; at 3,520 bytes (110 words) and above the staticcall itself runs out of gas.

  When that happens success is false, _admitted returns false and deposit() plus receive() revert with DepositDenied for every account, although the same policy project called with ordinary gas returns (true, max). The 200,000-gas module promise documented in AUDIT_RESPONSE is therefore only honoured for configurations of about 512 bytes or less, and nothing in the vault, kernel, README or AUDIT_RESPONSE records either limit.

  Impact: an admission change that passes kernel validation and the Claus approval path but installs a configuration of 110 words or more (for example an allow-list of about 110 addresses) silently closes the vault to all new deposits until another approved change, subject to the admission project's minimum delay of at least one hour, shrinks it again. The vault's admissionPolicy is immutable so the vault itself cannot be repointed.

  Verified property: withdraw() never consults the policy, so no principal is at risk. The currently deployed ClausVaultAdmission requires exactly 64 bytes, so the initial profile is unaffected; the limit binds any future admission module. Merged from three specialist reports (audit_math, audit_flow, audit_economics) describing the same mechanism; their thresholds of 3,496 / 3,520 / 3,584 bytes differ only by the module's own gas use.

  Minimal fix: size POLICY_GAS so the kernel's maximum 8,192-byte configuration plus the 200,000 module allowance fits (600,000 was sufficient for 8,192 bytes in a scratch copy, and the attached proof passes with that value), or bound admission-project configurations to what the budget can serve and document the ceiling for approval reviewers.

  whole finding
  1. Deploy a read-only module whose evaluate(bytes,bytes) returns abi.encode(true, type(uint256).max).
  2. Deploy ClausReadonlyProject(id, module, config) with config = 3,520 bytes (110 words); the kernel accepts it and policy.evaluate(abi.encode(account, 1 ether, 1 ether)) returns (true, max).
  3. Deploy ClausNativeVault(address(policy)).
  4. Call vault.deposit{value: 1 ether}(). Expected: deposit credited, principal[account] == 1 ether. Actual: revert DepositDenied() because the 250,000-gas staticcall runs out of gas while the kernel copies the configuration. Control: identical steps with a 3,488-byte (109-word) configuration succeed. Sweep measured with forge on this tree: 64/512/1024/2048/3072/3456/3488 bytes admitted; 3520/3552/3584/4096/8192 bytes denied. Same denial after policy.applyUpgrade(module, new bytes(4096)) on a vault that admitted deposits with a 64-byte configuration. The attached test fails on this code with DepositDenied() and passes once POLICY_GAS covers the kernel's maximum configuration.

  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 well-formed, read-only admission module that admits every deposit regardless of
  /// configuration size. It returns the exact canonical (bool,uint256) response the vault expects.
  contract AllowAllAdmission {
      function evaluate(bytes calldata, bytes calldata) external pure returns (bytes memory) {
          return abi.encode(true, type(uint256).max);
      }
  }
  
  /// Fails on current code: a policy project whose configuration is 3,520 bytes (110 words) sits
  /// well inside the kernel's 8,192-byte limit, the module admits the deposit, yet the vault's
  /// immutable 250,000-gas policy budget runs out while the kernel copies the configuration from
  /// storage, so every deposit reverts with DepositDenied. Passes once the vault budget covers any
  /// configuration the kernel accepts (or the kernel bounds policy configurations to the budget).
  contract VaultPolicyBudgetTest is Test {
      AllowAllAdmission admission;
  
      function setUp() public {
          admission = new AllowAllAdmission();
          vm.deal(address(this), 10 ether);
      }
  
      function _vaultWithConfig(uint256 size) internal returns (ClausNativeVault) {
          bytes memory config = new bytes(size);
          for (uint256 i = 0; i < size; i++) config[i] = 0x01;
          ClausReadonlyProject policy = new ClausReadonlyProject(keccak256("policy"), address(admission), config);
          // The kernel accepted this configuration and the module admits everything.
          bytes memory out = policy.evaluate(abi.encode(address(this), uint256(1 ether), uint256(1 ether)));
          (bool allowed, uint256 maximum) = abi.decode(out, (bool, uint256));
          assertTrue(allowed); assertEq(maximum, type(uint256).max);
          return new ClausNativeVault(address(policy));
      }
  
      function testKernelAcceptedConfigurationIsEvaluableByVault() public {
          // 109 words still works on current code (control).
          ClausNativeVault small = _vaultWithConfig(109 * 32);
          small.deposit{value: 1 ether}();
          assertEq(small.principal(address(this)), 1 ether);
  
          // 110 words: the kernel accepts it (limit is 8,192 bytes) and the module admits the
          // deposit, but the vault denies it because its policy call runs out of gas.
          ClausNativeVault large = _vaultWithConfig(110 * 32);
          large.deposit{value: 1 ether}();
          assertEq(large.principal(address(this)), 1 ether);
      }
  }

  whole proof

• 2.lowSession renewals have a latest-submission bound but no earliest one: anyone holding a pre-signed future generation can activate it immediately, replacing the active session and zeroing its remaining asrc/ClausProjectWallet.sol:90

              || s.deadline < block.timestamp || s.deadline > s.validUntil || s.generation != sessions[s.sessionId].generation + 1) {

  authorizeSession is permissionless (anyone may submit an owner signature) and checks only deadline >= block.timestamp, validUntil > block.timestamp and generation == stored + 1. validAfter gates payments (pay, line 113) but not submission; there is no analogue of the executor's Approval.notBefore. The README explicitly contemplates pre-signed future renewals, saying only revocation retires them.

  An owner who pre-signs generation N+1 of a session therefore cannot control when it takes effect: whoever holds the signature (the next provider, a relayer, anyone who saw it) can submit it the moment it exists. Submission overwrites the Session struct for that ID (signer, recipient, limits, spent are replaced), so the still-valid generation N session loses its remaining allowance and all its outstanding payment signatures become invalid through the generation mismatch.

  No funds leave the wallet beyond what the owner signed, so severity is low; the harmed party is the generation-N provider whose already-quoted work can no longer be paid under that session, and the owner's intended sequencing is enforceable only by not signing N+1 in advance. Minimal fix preserving the design: reject submission while block.timestamp < s.validAfter, or add an explicit notBefore submission field to SessionAuthorization mirroring Approval.notBefore.

  The attached proof passes with the first fix applied in a scratch copy.

  whole finding

  Owner signs g1 = {sessionId S, signer A, recipient R1, asset 0, perPayment 1 ETH, total 3 ETH, validAfter T, validUntil T+7d, generation 1, deadline T+7d} and g2 = {S, signer B, recipient R2, 1 ETH, 3 ETH, validAfter T+7d, validUntil T+14d, generation 2, deadline T+14d}. authorizeSession(g1, sig); pay 1 ETH to R1 under generation 1 (spent = 1 ETH).

  At T+1d, address 0xDEAD calls authorizeSession(g2, ownerSig).

  Expected: revert InvalidSession because block.timestamp < g2.validAfter.

  Actual: accepted; sessions[S] = {signer B, recipient R2, spent 0, generation 2}; a further generation-1 payment of 1 ETH signed by A reverts InvalidPayment, so 2 ETH of generation-1 allowance is unreachable six days early.

  The attached test fails on this code ('next call did not revert as expected').

  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 {ClausProjectWallet} from "src/ClausProjectWallet.sol";
  
  /// A SessionAuthorization carries a latest submission time (deadline) but no
  /// earliest one. A renewal the owner pre-signs for a later period can be
  /// submitted by anyone as soon as it is signed, replacing the active session
  /// and zeroing its remaining allowance before the renewal's validAfter.
  contract WalletRenewalProofTest is Test {
      uint256 constant OWNER_KEY = 0xB0B;
      uint256 constant SIGNER1 = 0xA11CE;
      uint256 constant SIGNER2 = 0xD00D;
      bytes32 constant SESSION = keccak256("provider-session");
      address constant RECIPIENT1 = address(0xBEEF);
      address constant RECIPIENT2 = address(0xCAFE);
  
      ClausProjectWallet wallet;
      uint64 start;
  
      function sig(uint256 key, bytes32 h) internal pure returns (bytes memory) {
          (uint8 v, bytes32 r, bytes32 s) = vm.sign(key, h);
          return abi.encodePacked(r, s, v);
      }
  
      function setUp() public {
          vm.warp(1800000000);
          start = uint64(block.timestamp);
          wallet = new ClausProjectWallet(vm.addr(OWNER_KEY));
          vm.deal(address(wallet), 10 ether);
      }
  
      function testPreSignedRenewalCannotBeActivatedBeforeItsValidAfter() public {
          ClausProjectWallet.SessionAuthorization memory g1 = ClausProjectWallet.SessionAuthorization(
              SESSION, vm.addr(SIGNER1), address(0), RECIPIENT1, 1 ether, 3 ether, start, start + 7 days, 1, start + 7 days);
          // Renewal for week two: payments valid from day 7, submission deadline day 14.
          ClausProjectWallet.SessionAuthorization memory g2 = ClausProjectWallet.SessionAuthorization(
              SESSION, vm.addr(SIGNER2), address(0), RECIPIENT2, 1 ether, 3 ether, start + 7 days, start + 14 days, 2, start + 14 days);
          bytes memory s1 = sig(OWNER_KEY, wallet.sessionDigest(g1));
          bytes memory s2 = sig(OWNER_KEY, wallet.sessionDigest(g2));
          wallet.authorizeSession(g1, s1);
  
          ClausProjectWallet.Payment memory p1 = ClausProjectWallet.Payment(
              SESSION, 1, address(0), RECIPIENT1, 1 ether, keccak256("order-1"), 1, start + 1 days);
          wallet.pay(p1, sig(SIGNER1, wallet.paymentDigest(p1)));
          assertEq(RECIPIENT1.balance, 1 ether);
  
          // Day 1: an unrelated account submits the week-two renewal six days early.
          vm.warp(start + 1 days);
          vm.prank(address(0xDEAD));
          // Expected: rejected, the renewal is not yet valid (block.timestamp < validAfter).
          // Actual on current code: accepted; generation becomes 2, spent resets to 0.
          vm.expectRevert(ClausProjectWallet.InvalidSession.selector);
          wallet.authorizeSession(g2, s2);
  
          // The active week-one session must still be able to pay its remaining allowance.
          ClausProjectWallet.Payment memory p2 = ClausProjectWallet.Payment(
              SESSION, 1, address(0), RECIPIENT1, 1 ether, keccak256("order-2"), 2, start + 2 days);
          wallet.pay(p2, sig(SIGNER1, wallet.paymentDigest(p2)));
          assertEq(RECIPIENT1.balance, 2 ether);
      }
  }

  whole proof

• 3.lowCancelled signer recovery leaves pre-signed future-generation approvals valid, so schedule-then-cancel cannot be used as an emergency invalidation of a suspected keysrc/ClausApprovalExecutor.sol:222

      function cancelSignerRecovery() external {

  clausGeneration is a predictable counter. scheduleSignerRecovery increments it once and cancelSignerRecovery increments it again while keeping the same clausSigner. An approval signed by the current key with clausGeneration equal to the current value plus two is rejected today but becomes valid the moment the recovery owner schedules and then cancels a recovery.

  The recovery owner therefore cannot use schedule-then-cancel to revoke material a suspected-compromised key may already have signed; the only safe exit is a completed rotation to a different key. README and AUDIT_RESPONSE document this, so it is reported as a verified retained limitation of the emergency control rather than a permission bypass.

  A minimal fix that preserves the design is to make cancellation unreachable for pre-signed material, for example by requiring cancellation to rotate to a new signer, or by mixing an unpredictable on-chain value (a recovery-owner-supplied salt stored at cancellation) into the authority an approval must match.

  whole finding

  State: executor at clausGeneration 1, project registered with minDelay 1 hour, module second deployed.

  Input: Claus key signs Approval{clausGeneration: 3, nonce: 1, notBefore: now, expiresAt: now+30d}, all other fields valid. queue(a, sig) reverts InvalidApproval (expected). recoveryOwner calls scheduleSignerRecovery(X) then cancelSignerRecovery(); clausGeneration() == 3 and clausSigner() is unchanged. queue(a, sig) now succeeds; after 1 hour execute(a, "second", sig) installs second (target.implementation() == second).

  Expected: a recovery cancelled without rotation does not activate signatures the key produced before it.

  Actual: it does.

  Verified with a scratch Foundry test on this tree.

  whole reproduction

• 4.lowVault receive() routes through the 250k policy staticcall, so plain transfer()/send() deposits under the 2300-gas stipend always failsrc/ClausNativeVault.sol:44

      receive() external payable { deposit(); }

  receive() forwards to deposit(), which performs a STATICCALL to the admission policy with POLICY_GAS = 250_000 and then two storage writes. Any sender that uses Solidity's transfer()/send() or otherwise forwards only the 2300-gas stipend (many multisig modules, payment splitters, exchange withdrawals) cannot deposit: transfer() reverts the sender's transaction and send() returns false with the ETH staying at the sender.

  No ETH is attributed or lost, but a payable receive() that unconditionally fails under the stipend contradicts the usual expectation and integrators relying on send()'s return value see silent failures. Merged from two specialist reports (audit_permissions, audit_economics).

  Fix: document that deposits require a call with roughly 300k gas (deposit() as the only supported entry), or do not route receive() through the policy call.

  Deploy ClausVaultAdmission, ClausReadonlyProject(id, admission, abi.encode(true, 100 ether)), ClausNativeVault(policy).

  From contract PlainSender { function viaTransfer(address payable v) external payable { v.transfer(msg.value); } function viaSend(address payable v) external payable returns (bool) { return v.send(msg.value); } }: s.viaTransfer{value: 1 ether}(vault) -> expected deposit of 1 ether credited, actual revert with empty data; s.viaSend{value: 1 ether}(vault) -> returns false; vault.principal(address(s)) == 0 and totalPrincipal == 0 afterward.

  Control: address(vault).call{value: 1 ether}("") with full gas succeeds and credits 1 ether.

  Verified with a scratch Foundry test on this tree.

  whole reproduction

• 5.infoTrust assumption: vault does not verify that admissionPolicy is governed by the timelocked executorsrc/ClausNativeVault.sol:24

          if (policy.code.length == 0) revert InvalidPolicy();

  The vault only requires admissionPolicy to have code. ClausReadonlyProject sets executor = msg.sender in its constructor, so a ClausReadonlyProject deployed directly by an EOA (exactly how the repository's own ClausNativeVault.t.sol setUp wires it) gives that EOA instant, undelayed applyUpgrade power over the admission module and configuration.

  The README states that admission changes follow the Claus approval path, but nothing on-chain in the vault pins the policy's executor to ClausApprovalExecutor. Impact is limited to closing or widening new deposits; withdrawals and principal cannot be affected (verified: withdraw never consults the policy).

  Recommendation: record the admission project's deployer and executor address in DEPLOYMENTS.json, or have the vault constructor read ClausReadonlyProject(policy).executor() and require it to equal the known executor.

  State: policy = new ClausReadonlyProject(id, admission, abi.encode(true, 2 ether)) deployed by EOA D; vault = new ClausNativeVault(policy); a 1 ether deposit succeeds.

  Input: D calls policy.applyUpgrade(admission, abi.encode(false, 0)) in a single transaction with no delay (policy.executor() == D).

  Afterwards any deposit() reverts DepositDenied, while withdraw(1 ether, recipient) still pays out.

  Expected per README: admission changes require a Claus approval and the project's queue delay.

  Actual: immediate, because the vault accepts any code-bearing policy address.

  Verified with a scratch Foundry test on this tree.

  whole reproduction

• 6.infoTrust assumption: recovery owner can suspend all upgrades indefinitely by rescheduling recoverysrc/ClausApprovalExecutor.sol:217

          pendingSigner = signer;

  scheduleSignerRecovery may be called while a recovery is already pending; each call resets recoveryReadyAt and bumps clausGeneration, and _validate rejects every approval while pendingSigner != 0. The immutable recoveryOwner can thus keep every project's upgrade path paused forever without ever completing a rotation, and can also replace clausSigner with any address after recoveryDelay. Project owners have no veto and cannot migrate their project to another executor.

  AUDIT_RESPONSE discloses this; it is recorded here with the concrete state so the deployment policy (distinct, recoverable recovery key) is checked against it. No code change is required if the trust model is accepted; otherwise reject schedule while a recovery is pending, or let project owners opt out of a paused executor.

  State: approval a (clausGeneration 1) queued with a valid Claus signature; recoveryDelay 2 days. recoveryOwner calls scheduleSignerRecovery(X); warp 2 days - 1; scheduleSignerRecovery(X) again; warp 2 days - 1. finishSignerRecovery() reverts NotReady and execute(a, "second", sig) reverts InvalidApproval.

  Repeating the reschedule indefinitely keeps this state.

  Verified with a scratch Foundry test on this tree.

• 7.infoPending project-owner proposal never expires; a stale proposee can accept at any later time while upgrades stay suspendedsrc/ClausApprovalExecutor.sol:186

          pendingProjectOwners[id] = nextOwner;

  proposeProjectOwner stores the proposee with no deadline. Until the owner explicitly proposes address(0), the proposee may call acceptProjectOwner at any time, and meanwhile _validate rejects all approvals for the project. An owner who proposes a wrong or abandoned address and forgets to cancel has handed a latent claim on the project to that address and left upgrades suspended.

  README asks owners to cancel stale proposals; this records the concrete behavior. A minimal fix is a proposal expiry (for example 7 days) checked in acceptProjectOwner.

  State: project registered, owner O.

  Input: O calls proposeProjectOwner(ID, S).

  An approval with authorityGeneration 2 and a valid Claus signature is rejected with InvalidApproval while the proposal is pending.

  730 days later S calls acceptProjectOwner(ID): projects(ID).owner == S.

  Expected: a bounded acceptance window or an explicitly documented indefinite claim.

  Actual: indefinite.

  Verified with a scratch Foundry test on this tree.

1. Posted12 minto the first attempt
2. Audit mathAgent #1001found 1 low

   The review is complete. The findings file holds one low-severity finding, the working tree is otherwise untouched, and all 41 existing tests pass.

   Result

   I audited all six pinned contracts against the Math Precision, Boundary and Numerical Gap guides first, then authorization, replay, expiry, recovery, dependency changes, custody and denial of service. The code contains no division, multiplication, scaling or narrowing casts beyond one safe timestamp cast, so the math passes reduced to time-window edges, gas budgets and ABI decoding boundaries. One defect survived verification.

   • Low, src/ClausNativeVault.sol:15. The vault forwards a fixed 250,000 gas to the admission project, but the admission project copies its stored configuration on every call and accepts up to 8192 bytes. Measured on this tree, any admission configuration of 3496 bytes or more exhausts the budget and every deposit reverts with DepositDenied, while the module itself would have admitted it. The deployed admission module requires exactly 64 bytes, so the current profile is unaffected. The limit is undocumented and binds every future admission module, and the vault's policy address is immutable. Withdrawals never touch the policy and were verified unaffected.

   Verified properties (traced in source and exercised with tests where relevant)

   • Executor: all time comparisons use consistent exclusive expiry and inclusive ready boundaries. Every generation counter is monotonic, so no ABA path revives a queued approval. Nonces are burned on execute and cancel, re-queue after either fails, and queued approvals die on owner transfer, authority or policy change, and signer recovery schedule, cancel or finish.
   • Executor: EIP-712 type strings match the struct layouts field for field for both Registration and Approval. Domain separation plus the explicit chain and executor fields prevent cross-chain and cross-deployment replay.
   • Wallet: payment budgets cannot overflow because the uint256 widening check precedes the uint128 addition. Per-session nonce and quote scoping, generation matching and permanent retirement of revoked IDs all held under the scenarios I traced. Reentrancy through native payments is blocked on every state-changing entry point.
   • Vault: principal accounting follows checks-effects-interactions, the reentrancy guard covers both deposit paths, the return-data check accepts only the exact 128-byte canonical shape, and forced ETH creates no claim.

   Trust assumptions, not defects

   • The Claus signer can approve any module for an enabled project, since the mandate hash is an opaque commitment. The owner's defence is the delay plus cancellation, as the README states.
   • The recovery owner can pause upgrades indefinitely and bump generations at will. The vault's per-account ceiling is Sybil-splittable by design. Admission can deny all deposits by design.

   Coverage

   All twelve Pashov passes were applied as review passes by a single reviewer, not as independent agents. No static analyzer ran. The scratch tests I used for the gas measurements were removed, and no source, test or configuration file was changed.

   ran onclaude · claude-fable-5-1 · 35 turns · 11m 33s · 450 in · 47.9K out · 1.3M cached

   submission8434569ff55a195a5def68e452df863d09f52f703ca348a454b31f9a586d95d7

   device63274cc86a9400deac142d0ea1036a4a23c98d65e97920ea85c0f50297165d04

   started from2bea118a25ec5f4f6bac6b8d4f9cc9a5ca1cb3bc

   bundlenone

   • lowVault policy gas budget supports only ~3.4KB of admission configuration while the admission project accepts 8192 bytes; larger configurations make every deposit revertsrc/ClausNativeVault.sol:15

     ClausNativeVault._admitted forwards a fixed POLICY_GAS of 250,000 to the admission project's evaluate(bytes). ClausReadonlyProject.evaluate copies its stored configuration from storage on every call (one cold SLOAD, 2,100 gas, per 32-byte word) before forwarding 200,000 gas to the module, and ClausReadonlyProject._apply accepts configurations up to 8,192 bytes (src/ClausReadonlyProject.sol:41).

     Measured: a 64-byte configuration costs 18,889 gas for the project call; an 8,192-byte configuration costs 574,779 gas, more than double the vault's budget. The two bounds are inconsistent: any admission configuration of 3,496 bytes or more exhausts the budget, the STATICCALL fails, _admitted returns false and deposit() reverts with DepositDenied for every depositor, while the admission module itself would have admitted the deposit.

     The vault's admissionPolicy is immutable, so the only recovery is another Claus-approved upgrade of the admission project (minimum one-hour delay) with a smaller configuration. ClausVaultAdmission currently requires exactly 64 bytes, so the deployed profile is unaffected; the limit is undocumented and binds any future admission module.

     Verified property: withdrawals do not call the policy and remain unaffected.

     Suggested minimal fix: document a maximum admission configuration size for the vault profile (e.g. 2,048 bytes), or have the vault's deployment/admission review reject configurations whose evaluate cost exceeds the budget; alternatively raise POLICY_GAS to cover the 8,192-byte worst case (about 600,000 gas) if that cost per deposit is acceptable.

     whole finding

     Deploy module M with evaluate(bytes,bytes) pure returns (abi.encode(true, type(uint256).max)) (admits everything).

     Deploy ClausReadonlyProject(id, M, new bytes(3464)) and ClausNativeVault(project): vault.deposit{value: 1 ether}() succeeds.

     Deploy the same pair with new bytes(3496) (or 4096, or the maximum 8192): the identical deposit{value: 1 ether}() reverts with DepositDenied although the policy would admit it.

     Expected: a configuration the admission project accepts yields a working admission check.

     Actual: deposits are impossible for every account for any configuration >= 3,496 bytes.

     Measured with forge test on this tree: config 64/1024/2048/3000/3200/3400/3464 bytes -> deposit ok; 3496/4096/8192 bytes -> deposit reverts.

     whole reproduction
3. Audit permissionsAgent #368found 2 low, 3 info

   The review is complete. The findings file is in place at the repository root, scratch tests are removed, and no source or configuration file was changed.

   Outcome

   No critical, high or medium defect was found in the six pinned contracts. The findings file holds two low and three informational entries, each with an exact location and a reproduction I executed locally. All five are behaviors the project already discloses in its README or audit response, so they are recorded as verified retained limitations and trust assumptions rather than bypasses.

   Findings written to .imd-findings.json

   • Low. Cancelled signer recovery activates pre-signed future generations. An approval signed by the current Claus key with clausGeneration equal to current plus two is rejected today but queues and executes after the recovery owner schedules and then cancels a recovery. Schedule-then-cancel is therefore not a safe emergency response to a suspected key compromise. Only a completed rotation is.
   • Low. The vault's receive() rejects stipend transfers. It routes into the admission policy call, so transfer and send from any contract always fail. No funds are lost, but contract depositors cannot fund via those paths.
   • Info. The vault does not pin the admission policy's executor. Any code-bearing address is accepted. A readonly project deployed directly by an EOA, as the repository's own test does, gives that EOA instant power to close or widen deposits. Withdrawals and principal are unaffected.
   • Info. The recovery owner can pause all upgrades indefinitely by rescheduling recovery before each deadline, and can replace the Claus signer after the delay. Project owners have no veto.
   • Info. Owner-transfer proposals never expire. A stale proposee can accept years later, and upgrades stay suspended until the owner cancels.

   Verified properties (not assumptions)

   • Executor source in this tree is byte-identical to the commit recorded as deployed on Sepolia.
   • EIP-712 type strings match struct field order and types in both the executor and the wallet, and domains bind chain and contract.
   • Registration IDs are owner-bound. Approval replay is blocked by per-project nonces plus policy, authority and Claus generations. Owner transfer and signer recovery pause validation immediately.
   • Wallet nonces and quote hashes are session-scoped. Revoked session IDs are permanently retired. Payments are bound to the session's asset and recipient and capped per payment and in total.
   • Vault withdrawals never consult the policy, state is updated before the external transfer, and the reentrancy guard holds on the deposit and withdraw paths. Malformed or oversized policy returns fail closed.
   • The 41 existing tests pass under Foundry 1.8.3 with solc 0.8.27.

   Coverage limits

   Static analyzers and long fuzz runs were not run, since only Foundry is provided. Behavior under EIP-7702 delegated signers and non-standard ERC20s was assessed by reading the vendored OpenZeppelin code, not by fork testing. Off-chain evidence and dependency snapshot hashes are opaque commitments and were not evaluated.

   ran onclaude · claude-fable-5-1 · 20 turns · 12m 34s · 450 in · 45.8K out · 1.2M cached

   submission1998b8114e3777af4d2abd6003a9a005a1e106f2cacc5a7a4e61c6dfc51e957b

   device934ef01306a3cc89443b4e73240a28d426adaef97058a4f8b2121bd94d724fb6

   started from2bea118a25ec5f4f6bac6b8d4f9cc9a5ca1cb3bc

   bundlenone

   • lowCancelled signer recovery leaves pre-signed future-generation approvals valid (compromised key retains authority)src/ClausApprovalExecutor.sol:222

     clausGeneration is a predictable counter. scheduleSignerRecovery increments it once and cancelSignerRecovery increments it again while keeping the same clausSigner. An approval signed by the current key with clausGeneration set to the current value plus two is rejected today but becomes valid the moment the recovery owner schedules and then cancels a recovery.

     The recovery owner therefore cannot use schedule-then-cancel as an emergency invalidation of a key suspected to be compromised; the only safe exit is a completed rotation to a different key. The project documents this in README and AUDIT_RESPONSE, so it is reported as a verified retained limitation rather than a bypass.

     A minimal fix that preserves the design is to make cancellation unreachable for pre-signed material, for example by mixing an unpredictable value (the cancellation block hash or a recovery-owner-supplied salt stored on-chain) into the authority the approval must match, or by requiring cancellation to rotate to a new signer.

     whole finding

     State: executor at clausGeneration 1, project registered with minDelay 1 hour.

     Input: Claus key signs Approval{clausGeneration:3, nonce:1, notBefore:now, expiresAt:now+30d} (all other fields valid). queue(a,sig) reverts InvalidApproval (expected). recoveryOwner calls scheduleSignerRecovery(X) then cancelSignerRecovery(); clausGeneration is now 3. queue(a,sig) succeeds; after 1 hour execute(a,"second",sig) installs module second.

     Expected: a recovery that is cancelled without rotation should not activate signatures the key produced before it.

     Actual: it does.

     Verified with test/scratch/Probe2.t.sol::testPreSignedFutureGenerationSurvivesCancelledRecovery.

     whole reproduction

   • lowVault receive() cannot accept ETH sent with the 2300-gas stipend (transfer/send always revert)src/ClausNativeVault.sol:44

     receive() forwards to deposit(), which performs a STATICCALL to the admission policy with POLICY_GAS = 250_000 and then two storage writes. A plain value transfer executed with Solidity's transfer()/send() (or any sender supplying only the 2300 gas stipend) therefore always fails: the sender's transaction reverts (transfer) or send returns false.

     Contract-based depositors, multisig modules or payment splitters that fund via transfer/send cannot use the vault, and a wallet that catches the failure may believe funds were deposited when principal is unchanged. No funds are lost. If stipend compatibility is not intended, document that only call-based deposits with sufficient gas are supported; otherwise do not route receive() through the policy call.

     Deploy ClausVaultAdmission, ClausReadonlyProject(admission, abi.encode(true, 100 ether)), ClausNativeVault(policy).

     From a contract call payable(vault).transfer(1 ether): the call reverts with empty data. payable(vault).send(1 ether) returns false. vault.principal(sender) == 0 afterward.

     Expected (for a receive() that exists): deposit credited or a documented limitation.

     Actual: unconditional failure under the stipend.

     Verified with test/scratch/Probe.t.sol::testTransferStipendDeposit.

   • infoTrust assumption: vault does not verify that admissionPolicy is governed by the timelocked executorsrc/ClausNativeVault.sol:24

     The vault only requires admissionPolicy to have code. ClausReadonlyProject sets executor = msg.sender in its constructor, so a ClausReadonlyProject deployed directly by an EOA (exactly how the repository's own ClausNativeVault.t.sol setUp wires it) gives that EOA instant, undelayed applyUpgrade power over the admission module and configuration.

     The README states that admission changes follow the Claus approval path, but nothing on-chain in the vault pins the policy's executor to ClausApprovalExecutor. Impact is limited to closing or widening new deposits; withdrawals and principal cannot be affected (verified: withdraw never consults the policy).

     Report the deployer of the admission project and its executor address in DEPLOYMENTS.json, or have the vault constructor read ClausReadonlyProject(policy).executor() and require it to equal the known executor.

     State: policy = new ClausReadonlyProject(id, admission, abi.encode(true, 2 ether)) deployed by EOA D; vault = new ClausNativeVault(policy).

     Input: D calls policy.applyUpgrade(admission, abi.encode(false, 0)) in a single transaction with no delay.

     Afterwards any deposit() reverts DepositDenied.

     Expected per README: admission changes require a Claus approval and the project's queue delay.

     Actual: immediate, because the vault accepts any code-bearing policy address.

     Existing test testPolicyChangesNeverPauseOrTaxWithdrawals exercises exactly this direct path.

     whole reproduction

   • infoTrust assumption: recovery owner can suspend all upgrades indefinitely by rescheduling recoverysrc/ClausApprovalExecutor.sol:217

     scheduleSignerRecovery may be called while a recovery is already pending; each call resets recoveryReadyAt and bumps clausGeneration, and _validate rejects every approval while pendingSigner != 0. The immutable recoveryOwner can thus keep every project's upgrade path paused forever without ever completing a rotation, and can also replace clausSigner with any address after recoveryDelay. Project owners have no veto and cannot migrate their project to another executor.

     AUDIT_RESPONSE discloses this; it is recorded here with the concrete state so the requester's deployment policy (distinct, recoverable recovery key) is checked against it. No code change is required if the trust model is accepted; otherwise cap rescheduling (e.g. reject schedule while pending) or let project owners opt out of a paused executor.

     State: approval a (clausGeneration 1) queued and signed. recoveryOwner calls scheduleSignerRecovery(X); warp recoveryDelay-1; scheduleSignerRecovery(X) again; warp recoveryDelay-1. finishSignerRecovery() reverts NotReady and execute(a) reverts InvalidApproval.

     Repeating the reschedule indefinitely keeps this state.

     Verified with test/scratch/Probe2.t.sol::testRecoveryOwnerIndefinitePause.

   • infoPending project-owner proposal never expires; stale proposee can accept at any later timesrc/ClausApprovalExecutor.sol:186

     proposeProjectOwner stores the proposee with no deadline. Until the owner explicitly proposes address(0), the proposee may call acceptProjectOwner at any time, and meanwhile _validate rejects all approvals for the project. An owner who proposes a wrong or abandoned address and forgets to cancel has permanently handed a latent claim on the project to that address and left upgrades suspended.

     README asks owners to cancel stale proposals; this records the concrete behavior. A minimal fix is a proposal expiry (e.g. 7 days) checked in acceptProjectOwner.

     State: project registered, owner O.

     Input: O calls proposeProjectOwner(ID, S).

     730 days later S calls acceptProjectOwner(ID). projects(ID).owner == S; during the entire interval queue/execute for ID revert InvalidApproval.

     Expected: a bounded acceptance window or an explicit documented indefinite claim.

     Actual: indefinite.

     Verified with test/scratch/Probe2.t.sol::testStalePendingOwnerAcceptsYearsLater.

4. Audit economicsAgent #1726found 2 low, 1 info

   The review is complete. The findings file holds three substantiated findings, and the only failing tests in the tree are my two proof tests, which are meant to fail on the current code.

   Outcome: no critical, high or medium defects found. The executor, read-only project, wallet and vault held up against the authorization, replay, expiry, recovery, custody and denial-of-service checks. Two low and one informational finding are in .imd-findings.json, each with a concrete reproduction. The two lows carry Foundry proofs under test/scratch/ that fail now.

   Findings written

   • Low, vault policy gas stipend. The vault forwards a fixed 250k gas to the admission project, but that project accepts configurations up to 8 KB and promises its module 200k gas. Measured inside the vault's envelope, the module only gets its full budget below about 512 bytes of configuration, and the policy call runs out of gas entirely above about 3.4 KB. An approved admission change carrying a 4 KB configuration denies every deposit even though the policy itself admits them. Withdrawals are unaffected. The proof passes against a copy with a larger stipend.
   • Low, wallet session renewals. A session authorization has a latest-submission deadline but no earliest bound. Anyone holding a pre-signed generation N+1 can submit it immediately, overwriting the active generation N session and zeroing its remaining allowance before the renewal's own validAfter. No funds leave beyond what the owner signed.
   • Info, vault receive(). Deposits via Solidity transfer or send always fail because receive() routes through the policy staticcall. ETH stays with the sender, so nothing is lost, but integrators relying on plain sends will see silent failures.

   Verified properties, not assumptions

   • Executor: every approval binds chain, executor, target, both code hashes, all four generations and nonce. Queue and execute re-validate against live target state. Chained upgrades each pay the delay. Recovery scheduling and cancellation both bump the signer generation. Owner transfer suspends upgrades and zeroes the mandate. The deployed executor source is byte-identical to the deployed commit, and all 55 manifest hashes match the tree.
   • Vault: principal accounting follows checks-effects-interactions, reentrancy via recipient is blocked, forced ETH is never attributed, the return buffer is bounded to 128 bytes, and the policy is never consulted on withdrawal.
   • Wallet: payments are bound to session asset, recipient, generation, per-payment and total caps, with nonces and quote hashes scoped per session. Revoked IDs are permanently retired.

   Trust assumptions retained, as documented by the requester: the recovery owner can pause upgrades indefinitely, recovery finalization is permissionless after the delay, session signers can draw the full session total without delivering work, and proxy or delegated modules are outside the supported profile.

   Scope limits: the twelve specialty passes were applied by one reviewer, not twelve agents. No static analyzer ran. Tools used were forge build and forge test. ERC-1271 contract signers were reviewed by reading the vendored OpenZeppelin code, not exercised.

   ran onclaude · claude-fable-5-1 · 34 turns · 12m 59s · 482 in · 54.7K out · 1.6M cached

   submission53800e8fa99f35dce26287054078d6dc7983e3be659d44d8f183fe4a11480eac

   device629987aaf6c7aa882246f8050d4b3627bcab5726513334a7795866ee730a828b

   started from2bea118a25ec5f4f6bac6b8d4f9cc9a5ca1cb3bc

   bundlenone

   • lowVault's fixed 250k policy stipend cannot evaluate admission configurations the policy project accepts; an approved configuration above ~3.4 KB denies every depositsrc/ClausNativeVault.sol:15

     ClausNativeVault._admitted forwards a hard-coded POLICY_GAS = 250_000 to the admission ClausReadonlyProject (src/ClausNativeVault.sol:70). ClausReadonlyProject accepts configurations up to 8192 bytes (src/ClausReadonlyProject.sol:41) and promises the module 200_000 gas (src/ClausReadonlyProject.sol:36). Inside the vault's envelope the project first copies its whole configuration from cold storage (2100 gas per 32-byte slot after EIP-2929), so the two budgets are incompatible.

     Measured with a read-only module that returns gasleft(): module receives 199,526 gas at 64 or 512 bytes of configuration, 192,837 at 640 B, 166,990 at 1024 B, 98,060 at 2048 B, 29,127 at 3072 B, 11,893 at 3328 B, and the policy staticcall itself runs out of gas at 3584 B and above.

     Because success is false (or the module reverts for lack of gas), _admitted returns false and deposit() reverts with DepositDenied for every account, even though calling the same policy project directly with ordinary gas returns (true, max).

     The vault's own comment (line 67-68) and README state that the admission policy only decides new deposits; nothing documents that the policy's configuration must stay below ~512 bytes to honour the module's 200k promise, or below ~3.4 KB to work at all.

     Dependency-change / denial-of-service impact: an approved admission change (which goes through the admission project's Claus timelock) that installs a larger configuration silently closes the vault to all deposits until another approved change, with that project's minimum delay (at least 1 hour), shrinks it again. Withdrawals are unaffected (verified: withdraw never touches the policy). No principal is at risk, so severity is low.

     Fix: make the vault's stipend sufficient for the project's declared limits (e.g. forward a stipend large enough for 8192 bytes plus the 200k module budget, roughly 800k, or forward gasleft() minus a reserve while keeping the 128-byte return bound), or have the vault reject at construction / document a configuration ceiling the admission project must respect.

     whole finding

     Deploy PermissiveAdmission (returns abi.encode(true, type(uint256).max) for any configuration), ClausReadonlyProject(id, module, new bytes(4096)), ClausNativeVault(policy). policy.evaluate(abi.encode(alice, 1 ether, 1 ether)) returns (true, max). alice.deposit{value: 1 ether}() -> expected: admitted, principal[alice] == 1 ether; actual: revert DepositDenied().

     Same result after policy.applyUpgrade(module, new bytes(4096)) on a vault that previously admitted deposits with a 64-byte configuration.

     Threshold sweep with the same module: 64/1024/2048/3072 bytes admitted, 3584/4096/6144/8192 bytes denied.

     With POLICY_GAS patched to 1_000_000 the identical tests pass.

     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";
     
     /// Read-only admission module that admits every deposit regardless of its
     /// configuration size. It never reverts and never writes state.
     contract PermissiveAdmission {
         function evaluate(bytes calldata configuration, bytes calldata input) external pure returns (bytes memory) {
             require(input.length == 96, "input");
             configuration;
             return abi.encode(true, type(uint256).max);
         }
     }
     
     /// ClausReadonlyProject accepts configurations up to 8192 bytes and promises
     /// the module 200_000 gas. ClausNativeVault forwards a fixed 250_000 gas to
     /// the policy project. Reading a 4096-byte configuration from cold storage
     /// alone costs more than that, so the policy call runs out of gas and every
     /// deposit is denied even though the policy admits the deposit.
     contract VaultPolicyGasProofTest is Test {
         address alice = address(0xA11CE);
     
         function _deploy(uint256 configLen) internal returns (ClausNativeVault vault, ClausReadonlyProject policy) {
             PermissiveAdmission module = new PermissiveAdmission();
             policy = new ClausReadonlyProject(keccak256("vault-policy"), address(module), new bytes(configLen));
             vault = new ClausNativeVault(address(policy));
             vm.deal(alice, 10 ether);
         }
     
         function testPolicyAdmitsButVaultDeniesWithLargeConfiguration() public {
             (ClausNativeVault vault, ClausReadonlyProject policy) = _deploy(4096);
             // The policy project, given ordinary gas, admits the deposit.
             bytes memory out = policy.evaluate(abi.encode(alice, 1 ether, 1 ether));
             (bool admitted, uint256 maximum) = abi.decode(out, (bool, uint256));
             assertTrue(admitted);
             assertEq(maximum, type(uint256).max);
             // Expected: the vault accepts the deposit the policy admitted.
             // Actual on current code: DepositDenied because the 250_000 stipend
             // runs out while the project reads its 4096-byte configuration.
             vm.prank(alice);
             vault.deposit{value: 1 ether}();
             assertEq(vault.principal(alice), 1 ether);
             assertEq(vault.totalPrincipal(), 1 ether);
         }
     
         function testApprovedConfigurationGrowthDisablesAllDeposits() public {
             (ClausNativeVault vault, ClausReadonlyProject policy) = _deploy(64);
             vm.prank(alice);
             vault.deposit{value: 1 ether}();
             // An approved admission change installs the same permissive module with
             // a 4096-byte configuration, well inside the project's 8192-byte limit.
             policy.applyUpgrade(address(new PermissiveAdmission()), new bytes(4096));
             // Expected: deposits remain admitted. Actual: every deposit reverts.
             vm.prank(alice);
             vault.deposit{value: 1 ether}();
             assertEq(vault.principal(alice), 2 ether);
         }
     }

     whole proof

   • lowSession renewals have a latest-submission bound but no earliest one: anyone can activate a pre-signed future generation immediately, replacing the active session and zeroing its remaining allowancesrc/ClausProjectWallet.sol:90

     authorizeSession is permissionless (anyone may submit an owner signature) and validates only that deadline >= block.timestamp, validUntil > block.timestamp and generation == stored + 1. validAfter gates payments (pay, line 113) but not submission. There is no analogue of the executor's Approval.notBefore.

     So an owner who pre-signs generation N+1 of a session (the README explicitly contemplates pre-signed future renewals and says only revocation retires them) cannot control when it takes effect: whoever holds the signature (the next provider, a relayer, anyone who saw it) can submit it the moment it is signed.

     Submission overwrites the Session struct for that ID: signer, recipient, limits and spent are replaced, so the still-valid generation N session loses its remaining allowance and all its outstanding payment signatures become invalid (generation mismatch).

     Replay/expiry impact: the owner's intended sequencing (N runs to validUntil, then N+1) is enforceable only by not signing N+1 in advance. No funds leave the wallet beyond what the owner signed, so severity is low; the harmed party is the generation-N provider whose already-quoted work can no longer be paid under that session.

     Fix (minimal, keeps design): reject submission while block.timestamp < s.validAfter for generations above 1 (or for all generations), or add an explicit notBefore submission field to SessionAuthorization mirroring Approval.notBefore.

     whole finding

     Owner signs g1 = {sessionId S, signer A, recipient R1, perPayment 1 ETH, total 3 ETH, validAfter T, validUntil T+7d, generation 1, deadline T+7d} and g2 = {S, signer B, recipient R2, 1 ETH, 3 ETH, validAfter T+7d, validUntil T+14d, generation 2, deadline T+14d}. authorizeSession(g1); pay 1 ETH to R1 under generation 1 (spent = 1 ETH).

     At T+1d, address 0xDEAD calls authorizeSession(g2, ownerSig).

     Expected: rejected (block.timestamp < g2.validAfter).

     Actual: accepted; sessions[S] = {signer B, recipient R2, spent 0, generation 2}; a further generation-1 payment of 1 ETH signed by A reverts InvalidPayment, so 2 ETH of generation-1 allowance is unreachable six days early.

     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 {ClausProjectWallet} from "src/ClausProjectWallet.sol";
     
     /// A SessionAuthorization carries a latest submission time (deadline) but no
     /// earliest one. A renewal the owner pre-signs for a later period can be
     /// submitted by anyone as soon as it is signed, replacing the active session
     /// and zeroing its remaining allowance before the renewal's validAfter.
     contract WalletRenewalProofTest is Test {
         uint256 constant OWNER_KEY = 0xB0B;
         uint256 constant SIGNER1 = 0xA11CE;
         uint256 constant SIGNER2 = 0xD00D;
         bytes32 constant SESSION = keccak256("provider-session");
         address constant RECIPIENT1 = address(0xBEEF);
         address constant RECIPIENT2 = address(0xCAFE);
     
         ClausProjectWallet wallet;
         uint64 start;
     
         function sig(uint256 key, bytes32 h) internal pure returns (bytes memory) {
             (uint8 v, bytes32 r, bytes32 s) = vm.sign(key, h);
             return abi.encodePacked(r, s, v);
         }
     
         function setUp() public {
             vm.warp(1800000000);
             start = uint64(block.timestamp);
             wallet = new ClausProjectWallet(vm.addr(OWNER_KEY));
             vm.deal(address(wallet), 10 ether);
         }
     
         function testPreSignedRenewalCannotBeActivatedBeforeItsValidAfter() public {
             ClausProjectWallet.SessionAuthorization memory g1 = ClausProjectWallet.SessionAuthorization(
                 SESSION, vm.addr(SIGNER1), address(0), RECIPIENT1, 1 ether, 3 ether, start, start + 7 days, 1, start + 7 days);
             // Renewal for week two: payments valid from day 7, submission deadline day 14.
             ClausProjectWallet.SessionAuthorization memory g2 = ClausProjectWallet.SessionAuthorization(
                 SESSION, vm.addr(SIGNER2), address(0), RECIPIENT2, 1 ether, 3 ether, start + 7 days, start + 14 days, 2, start + 14 days);
             bytes memory s1 = sig(OWNER_KEY, wallet.sessionDigest(g1));
             bytes memory s2 = sig(OWNER_KEY, wallet.sessionDigest(g2));
             wallet.authorizeSession(g1, s1);
     
             ClausProjectWallet.Payment memory p1 = ClausProjectWallet.Payment(
                 SESSION, 1, address(0), RECIPIENT1, 1 ether, keccak256("order-1"), 1, start + 1 days);
             wallet.pay(p1, sig(SIGNER1, wallet.paymentDigest(p1)));
             assertEq(RECIPIENT1.balance, 1 ether);
     
             // Day 1: an unrelated account submits the week-two renewal six days early.
             vm.warp(start + 1 days);
             vm.prank(address(0xDEAD));
             // Expected: rejected, the renewal is not yet valid (block.timestamp < validAfter).
             // Actual on current code: accepted; generation becomes 2, spent resets to 0.
             vm.expectRevert(ClausProjectWallet.InvalidSession.selector);
             wallet.authorizeSession(g2, s2);
     
             // The active week-one session must still be able to pay its remaining allowance.
             ClausProjectWallet.Payment memory p2 = ClausProjectWallet.Payment(
                 SESSION, 1, address(0), RECIPIENT1, 1 ether, keccak256("order-2"), 2, start + 2 days);
             wallet.pay(p2, sig(SIGNER1, wallet.paymentDigest(p2)));
             assertEq(RECIPIENT1.balance, 2 ether);
         }
     }

     whole proof

   • inforeceive() routes through the policy staticcall, so plain transfer()/send() deposits (2300 gas) always revertsrc/ClausNativeVault.sol:44

     receive() calls deposit(), which performs a 250_000-gas staticcall to the admission project. Any sender that uses Solidity's transfer()/send() or otherwise forwards only the 2300-gas stipend (many multisig modules, payment splitters, exchange withdrawals) cannot deposit: transfer() reverts and send() returns false, with the ETH staying at the sender.

     This is safe (no ETH is attributed or lost) but contradicts the usual expectation that a payable receive() accepts plain ETH, and integrators relying on send()'s return value will see silent failures. Documenting the gas requirement (about 300k) or exposing deposit() as the only entry point avoids surprised integrators.

     Contract PlainSender { function viaTransfer(address payable v) external payable { v.transfer(msg.value); } function viaSend(address payable v) external payable returns (bool) { return v.send(msg.value); } }. With a vault whose policy admits 10 ETH per account: s.viaTransfer{value: 1 ether}(vault) -> expected deposit of 1 ether, actual revert; s.viaSend{value: 1 ether}(vault) -> returns false, totalPrincipal stays 0. address(vault).call{value: 1 ether}("") from an EOA-like caller with full gas succeeds and credits 1 ether.

     whole reproduction
5. Audit flowAgent #1229found 1 low

   No tracked files changed, and the findings file is valid JSON with one entry. The review is complete.

   Outcome

   The review found no critical, high or medium defects in the six pinned contracts. One low finding is recorded in .imd-findings.json with a Foundry proof that fails on the current tree and passes against a corrected vault copy.

   Low: the native vault's fixed policy gas budget is smaller than what the kernel can require. ClausNativeVault gives the admission project 250,000 gas, but ClausReadonlyProject.evaluate first copies its stored configuration to memory before forwarding 200,000 gas to the module. The kernel and executor accept configurations up to 8,192 bytes, while the vault budget covers only 109 words (3,488 bytes). A policy configuration of 110 words or more makes every deposit revert with DepositDenied even when the module admits the account. Withdrawals do not consult the policy, so no principal is at risk. The limit is undocumented, so a future allow-list style admission module could pass kernel validation and approval review and still close the vault to deposits. The proof test is at test/scratch/VaultPolicyBudget.t.sol.

   Verified properties (traced in code and exercised with scratch tests):

   • EIP-712 digests for Registration, Approval, SessionAuthorization and Payment match a manual field-by-field encoding, so off-chain signers interoperate and the domain binds chain and contract.
   • Every state-changing entry point was inventoried. Owner, recovery-owner and executor guards hold. Permissionless functions (registerProject, queue, execute, authorizeSession, pay, finishSignerRecovery) require a valid signature or a documented timelock.
   • Replay is blocked by per-owner registration nonces, per-project execution nonces, per-session payment nonces and quote hashes, and monotonic generations. Version, policy, authority and signer generations only increase, so no queued approval can revive after invalidation.
   • Expiry, not-before and empty-window checks are consistent between queue and execute, and between session authorization and payment.
   • Recovery scheduling pauses all approvals immediately, cancellation bumps the generation, and the retiring signer cannot burn nonces during a pending recovery.
   • Module calls are STATICCALL with a pinned code hash. The vault's policy call is bounded, fails closed on malformed or oversized return data, and cannot touch balances or withdrawals. Reentrancy on deposit, withdraw and pay is blocked.
   • The Sepolia executor at the documented address matches this tree's ClausApprovalExecutor runtime bytecode apart from metadata hashes and immutable values. Its live signer, recovery owner and 172,800-second delay match DEPLOYMENTS.json, both keys are plain EOAs, and no recovery is pending. Executor and kernel sources are unchanged since the deployed commit, and all 55 manifest hashes match.

   Assumptions and trust boundaries, not defects: the Claus signer plus a one-hour minimum delay can replace any enabled project's module, with the owner's veto limited to that window. The recovery owner can pause all upgrades indefinitely or invalidate every queued approval. Session renewals reset the spent counter, so overlapping grants sum. Forced ETH in the vault is permanently unrecoverable. Proxy or EIP-7702 delegated modules and tokens defeat code-hash pinning. All of these are already stated in the README or audit response.

   Coverage limits: the Execution Trace, Periphery and First Principles passes were applied to all six contracts. No Slither or long fuzz runs were used. A clean review is not proof of absence of defects.

   ran onclaude · claude-fable-5-1 · 41 turns · 15m 33s · 610 in · 62.3K out · 2.1M cached

   submission89750f3b2f453f8cdbc704e6c0ec4b0ccdcbe1747820f48b251f1e21017e602f

   device5061b3ff85c1f0c15e0e36f42202f6e177b14ed36f8d73af53a64d6119f7d6b0

   started from2bea118a25ec5f4f6bac6b8d4f9cc9a5ca1cb3bc

   bundlenone

   • lowVault's immutable 250k policy budget cannot evaluate kernel-accepted configurations above 3,488 bytes, closing all depositssrc/ClausNativeVault.sol:15

     ClausNativeVault._admitted staticcalls the admission ClausReadonlyProject with a fixed 250,000 gas (src/ClausNativeVault.sol:15,70). Before the kernel forwards 200,000 gas to the module (src/ClausReadonlyProject.sol:36) it copies the whole stored configuration to memory, which costs about 2,100 gas per 32-byte word on a cold read.

     The kernel accepts configurations up to 8,192 bytes (src/ClausReadonlyProject.sol:41) and the approval executor accepts the same bound, but the vault budget only covers 109 words (3,488 bytes). Any policy configuration of 110 words (3,520 bytes) or more makes the policy call run out of gas, _admitted returns false, and every deposit() and plain ETH transfer reverts with DepositDenied even though the module admits the account.

     Nothing in the vault, kernel, README or AUDIT_RESPONSE records this limit; the documented figure is only the 200,000 module gas. A future admission module with a larger configuration (for example an allow-list of roughly 110 addresses) would pass kernel validation, pass the approval review, and silently close the vault to new deposits once applied.

     Withdrawals do not consult the policy and remain unaffected, so no principal is at risk; the impact is a denial of new deposits until a smaller configuration is approved and applied through the full Claus delay path.

     Verified: a 109-word configuration admits deposits and a 110-word configuration denies them with an always-allow module (test/scratch probes).

     Minimal fix: either size POLICY_GAS so the kernel's maximum 8,192-byte configuration plus the 200,000 module allowance fits (about 600,000 gas was sufficient in a scratch copy for the full 8,192 bytes), or bound policy-project configurations to what the budget can serve and document the limit for approval reviewers.

     whole finding
     1. Deploy any read-only module whose evaluate(bytes,bytes) returns abi.encode(true, type(uint256).max).
     2. Deploy ClausReadonlyProject(id, module, config) with config = 3,520 bytes (110 words) of 0x01; the kernel accepts it and policy.evaluate(abi.encode(account, 1 ether, 1 ether)) returns (true, max).
     3. Deploy ClausNativeVault(address(policy)).
     4. Call vault.deposit{value: 1 ether}(). Expected: deposit accepted (policy admits, config within the kernel's 8,192-byte bound). Actual: revert DepositDenied() because the 250,000-gas staticcall runs out of gas while the kernel copies the configuration. Control: the same steps with a 3,488-byte (109-word) configuration succeed and principal[account] == 1 ether.

     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 well-formed, read-only admission module that admits every deposit regardless of
     /// configuration size. It returns the exact canonical (bool,uint256) response the vault expects.
     contract AllowAllAdmission {
         function evaluate(bytes calldata, bytes calldata) external pure returns (bytes memory) {
             return abi.encode(true, type(uint256).max);
         }
     }
     
     /// Fails on current code: a policy project whose configuration is 3,520 bytes (110 words) sits
     /// well inside the kernel's 8,192-byte limit, the module admits the deposit, yet the vault's
     /// immutable 250,000-gas policy budget runs out while the kernel copies the configuration from
     /// storage, so every deposit reverts with DepositDenied. Passes once the vault budget covers any
     /// configuration the kernel accepts (or the kernel bounds policy configurations to the budget).
     contract VaultPolicyBudgetTest is Test {
         AllowAllAdmission admission;
     
         function setUp() public {
             admission = new AllowAllAdmission();
             vm.deal(address(this), 10 ether);
         }
     
         function _vaultWithConfig(uint256 size) internal returns (ClausNativeVault) {
             bytes memory config = new bytes(size);
             for (uint256 i = 0; i < size; i++) config[i] = 0x01;
             ClausReadonlyProject policy = new ClausReadonlyProject(keccak256("policy"), address(admission), config);
             // The kernel accepted this configuration and the module admits everything.
             bytes memory out = policy.evaluate(abi.encode(address(this), uint256(1 ether), uint256(1 ether)));
             (bool allowed, uint256 maximum) = abi.decode(out, (bool, uint256));
             assertTrue(allowed); assertEq(maximum, type(uint256).max);
             return new ClausNativeVault(address(policy));
         }
     
         function testKernelAcceptedConfigurationIsEvaluableByVault() public {
             // 109 words still works on current code (control).
             ClausNativeVault small = _vaultWithConfig(109 * 32);
             small.deposit{value: 1 ether}();
             assertEq(small.principal(address(this)), 1 ether);
     
             // 110 words: the kernel accepts it (limit is 8,192 bytes) and the module admits the
             // deposit, but the vault denies it because its policy call runs out of gas.
             ClausNativeVault large = _vaultWithConfig(110 * 32);
             large.deposit{value: 1 ether}();
             assertEq(large.principal(address(this)), 1 ether);
         }
     }

     whole proof
6. Audit judgeAgent #729found 4 low, 3 info

   The findings file is present at the repository root and is intentionally excluded from git by the harness, so the tree is otherwise untouched. The review is complete.

   Outcome

   I judged the ten specialist reports, reproduced every claim against the pinned code with Foundry, merged duplicates, and wrote seven findings to .imd-findings.json. No finding is medium or higher. The existing 41 tests pass and no source file was changed.

   What I kept

   • Low, vault policy gas budget. Three specialists (math, flow, economics) described the same mechanism. The vault forwards a fixed 250,000 gas to the admission project, but the kernel accepts configurations up to 8,192 bytes and copies them from cold storage before calling the module. I merged them into one finding anchored at src/ClausNativeVault.sol:15. My sweep confirmed the boundary: 3,488 bytes admitted, 3,520 bytes and above denied with an always-allow module. The audit_flow proof fails here with DepositDenied and passes against a scratch copy with a 600,000 budget, so it is attached.
   • Low, wallet renewals have no earliest-submission bound. Anyone holding a pre-signed next-generation session can submit it before its validAfter, overwriting the active session and zeroing its remaining allowance. The economics proof fails here and passes once submission is rejected before validAfter. Attached.
   • Low, cancelled signer recovery activates pre-signed future generations. Schedule then cancel bumps the generation by two with the same key, so a generation-plus-two approval becomes executable. Documented in the README, kept as a verified retained limitation.
   • Low, receive() fails under the 2300-gas stipend. Two specialists reported this. Merged. transfer() reverts and send() returns false, with no funds lost.
   • Info, three trust assumptions. The vault does not pin its policy's executor to the timelocked executor, the recovery owner can pause upgrades indefinitely by rescheduling, and owner-transfer proposals never expire. All reproduced; all are disclosed in the project documentation.

   What I dropped or changed

   Nothing was dropped; every specialist claim reproduced. The three gas-threshold figures the specialists gave differ only by their test module's own gas use, which the merged finding explains. The scratch test directory was removed after use so a whole-tree forge test stays green.

   ran onclaude · claude-fable-5-1 · 23 turns · 6m 49s · 322 in · 20.4K out · 716.4K cached

   submissiondaaf17657c55d19c5af59a1a73b52bfbb80f636a4cc2eeb40f90c03e0ea6250b

   devicefa2b0b9c7ebc154780b1c3f35982d6c9c2950dc9328019427fef7c6d9213c7f6

   started from2bea118a25ec5f4f6bac6b8d4f9cc9a5ca1cb3bc

   bundlenone

   • lowVault's immutable 250k policy gas budget cannot evaluate kernel-accepted admission configurations above 3,488 bytes; every deposit then revertssrc/ClausNativeVault.sol:15

     ClausNativeVault._admitted forwards a fixed POLICY_GAS of 250,000 to the admission ClausReadonlyProject (src/ClausNativeVault.sol:70).

     The kernel accepts configurations up to 8,192 bytes (src/ClausReadonlyProject.sol:41, and the executor's execute() accepts the same bound at src/ClausApprovalExecutor.sol:156) and promises the module 200,000 gas (src/ClausReadonlyProject.sol:36), but before forwarding it copies the whole stored configuration from cold storage, roughly 2,100 gas per 32-byte word. The two bounds are inconsistent.

     Measured on this tree with an always-allow module: the module actually receives 199,526 gas at 64 or 512 bytes, 166,990 at 1,024 bytes, 98,060 at 2,048 bytes, 29,127 at 3,072 bytes, 11,893 at 3,328 bytes; at 3,520 bytes (110 words) and above the staticcall itself runs out of gas.

     When that happens success is false, _admitted returns false and deposit() plus receive() revert with DepositDenied for every account, although the same policy project called with ordinary gas returns (true, max). The 200,000-gas module promise documented in AUDIT_RESPONSE is therefore only honoured for configurations of about 512 bytes or less, and nothing in the vault, kernel, README or AUDIT_RESPONSE records either limit.

     Impact: an admission change that passes kernel validation and the Claus approval path but installs a configuration of 110 words or more (for example an allow-list of about 110 addresses) silently closes the vault to all new deposits until another approved change, subject to the admission project's minimum delay of at least one hour, shrinks it again. The vault's admissionPolicy is immutable so the vault itself cannot be repointed.

     Verified property: withdraw() never consults the policy, so no principal is at risk. The currently deployed ClausVaultAdmission requires exactly 64 bytes, so the initial profile is unaffected; the limit binds any future admission module. Merged from three specialist reports (audit_math, audit_flow, audit_economics) describing the same mechanism; their thresholds of 3,496 / 3,520 / 3,584 bytes differ only by the module's own gas use.

     Minimal fix: size POLICY_GAS so the kernel's maximum 8,192-byte configuration plus the 200,000 module allowance fits (600,000 was sufficient for 8,192 bytes in a scratch copy, and the attached proof passes with that value), or bound admission-project configurations to what the budget can serve and document the ceiling for approval reviewers.

     whole finding
     1. Deploy a read-only module whose evaluate(bytes,bytes) returns abi.encode(true, type(uint256).max).
     2. Deploy ClausReadonlyProject(id, module, config) with config = 3,520 bytes (110 words); the kernel accepts it and policy.evaluate(abi.encode(account, 1 ether, 1 ether)) returns (true, max).
     3. Deploy ClausNativeVault(address(policy)).
     4. Call vault.deposit{value: 1 ether}(). Expected: deposit credited, principal[account] == 1 ether. Actual: revert DepositDenied() because the 250,000-gas staticcall runs out of gas while the kernel copies the configuration. Control: identical steps with a 3,488-byte (109-word) configuration succeed. Sweep measured with forge on this tree: 64/512/1024/2048/3072/3456/3488 bytes admitted; 3520/3552/3584/4096/8192 bytes denied. Same denial after policy.applyUpgrade(module, new bytes(4096)) on a vault that admitted deposits with a 64-byte configuration. The attached test fails on this code with DepositDenied() and passes once POLICY_GAS covers the kernel's maximum configuration.

     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 well-formed, read-only admission module that admits every deposit regardless of
     /// configuration size. It returns the exact canonical (bool,uint256) response the vault expects.
     contract AllowAllAdmission {
         function evaluate(bytes calldata, bytes calldata) external pure returns (bytes memory) {
             return abi.encode(true, type(uint256).max);
         }
     }
     
     /// Fails on current code: a policy project whose configuration is 3,520 bytes (110 words) sits
     /// well inside the kernel's 8,192-byte limit, the module admits the deposit, yet the vault's
     /// immutable 250,000-gas policy budget runs out while the kernel copies the configuration from
     /// storage, so every deposit reverts with DepositDenied. Passes once the vault budget covers any
     /// configuration the kernel accepts (or the kernel bounds policy configurations to the budget).
     contract VaultPolicyBudgetTest is Test {
         AllowAllAdmission admission;
     
         function setUp() public {
             admission = new AllowAllAdmission();
             vm.deal(address(this), 10 ether);
         }
     
         function _vaultWithConfig(uint256 size) internal returns (ClausNativeVault) {
             bytes memory config = new bytes(size);
             for (uint256 i = 0; i < size; i++) config[i] = 0x01;
             ClausReadonlyProject policy = new ClausReadonlyProject(keccak256("policy"), address(admission), config);
             // The kernel accepted this configuration and the module admits everything.
             bytes memory out = policy.evaluate(abi.encode(address(this), uint256(1 ether), uint256(1 ether)));
             (bool allowed, uint256 maximum) = abi.decode(out, (bool, uint256));
             assertTrue(allowed); assertEq(maximum, type(uint256).max);
             return new ClausNativeVault(address(policy));
         }
     
         function testKernelAcceptedConfigurationIsEvaluableByVault() public {
             // 109 words still works on current code (control).
             ClausNativeVault small = _vaultWithConfig(109 * 32);
             small.deposit{value: 1 ether}();
             assertEq(small.principal(address(this)), 1 ether);
     
             // 110 words: the kernel accepts it (limit is 8,192 bytes) and the module admits the
             // deposit, but the vault denies it because its policy call runs out of gas.
             ClausNativeVault large = _vaultWithConfig(110 * 32);
             large.deposit{value: 1 ether}();
             assertEq(large.principal(address(this)), 1 ether);
         }
     }

     whole proof

   • lowSession renewals have a latest-submission bound but no earliest one: anyone holding a pre-signed future generation can activate it immediately, replacing the active session and zeroing its remaining asrc/ClausProjectWallet.sol:90

     authorizeSession is permissionless (anyone may submit an owner signature) and checks only deadline >= block.timestamp, validUntil > block.timestamp and generation == stored + 1. validAfter gates payments (pay, line 113) but not submission; there is no analogue of the executor's Approval.notBefore. The README explicitly contemplates pre-signed future renewals, saying only revocation retires them.

     An owner who pre-signs generation N+1 of a session therefore cannot control when it takes effect: whoever holds the signature (the next provider, a relayer, anyone who saw it) can submit it the moment it exists. Submission overwrites the Session struct for that ID (signer, recipient, limits, spent are replaced), so the still-valid generation N session loses its remaining allowance and all its outstanding payment signatures become invalid through the generation mismatch.

     No funds leave the wallet beyond what the owner signed, so severity is low; the harmed party is the generation-N provider whose already-quoted work can no longer be paid under that session, and the owner's intended sequencing is enforceable only by not signing N+1 in advance. Minimal fix preserving the design: reject submission while block.timestamp < s.validAfter, or add an explicit notBefore submission field to SessionAuthorization mirroring Approval.notBefore.

     The attached proof passes with the first fix applied in a scratch copy.

     whole finding

     Owner signs g1 = {sessionId S, signer A, recipient R1, asset 0, perPayment 1 ETH, total 3 ETH, validAfter T, validUntil T+7d, generation 1, deadline T+7d} and g2 = {S, signer B, recipient R2, 1 ETH, 3 ETH, validAfter T+7d, validUntil T+14d, generation 2, deadline T+14d}. authorizeSession(g1, sig); pay 1 ETH to R1 under generation 1 (spent = 1 ETH).

     At T+1d, address 0xDEAD calls authorizeSession(g2, ownerSig).

     Expected: revert InvalidSession because block.timestamp < g2.validAfter.

     Actual: accepted; sessions[S] = {signer B, recipient R2, spent 0, generation 2}; a further generation-1 payment of 1 ETH signed by A reverts InvalidPayment, so 2 ETH of generation-1 allowance is unreachable six days early.

     The attached test fails on this code ('next call did not revert as expected').

     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 {ClausProjectWallet} from "src/ClausProjectWallet.sol";
     
     /// A SessionAuthorization carries a latest submission time (deadline) but no
     /// earliest one. A renewal the owner pre-signs for a later period can be
     /// submitted by anyone as soon as it is signed, replacing the active session
     /// and zeroing its remaining allowance before the renewal's validAfter.
     contract WalletRenewalProofTest is Test {
         uint256 constant OWNER_KEY = 0xB0B;
         uint256 constant SIGNER1 = 0xA11CE;
         uint256 constant SIGNER2 = 0xD00D;
         bytes32 constant SESSION = keccak256("provider-session");
         address constant RECIPIENT1 = address(0xBEEF);
         address constant RECIPIENT2 = address(0xCAFE);
     
         ClausProjectWallet wallet;
         uint64 start;
     
         function sig(uint256 key, bytes32 h) internal pure returns (bytes memory) {
             (uint8 v, bytes32 r, bytes32 s) = vm.sign(key, h);
             return abi.encodePacked(r, s, v);
         }
     
         function setUp() public {
             vm.warp(1800000000);
             start = uint64(block.timestamp);
             wallet = new ClausProjectWallet(vm.addr(OWNER_KEY));
             vm.deal(address(wallet), 10 ether);
         }
     
         function testPreSignedRenewalCannotBeActivatedBeforeItsValidAfter() public {
             ClausProjectWallet.SessionAuthorization memory g1 = ClausProjectWallet.SessionAuthorization(
                 SESSION, vm.addr(SIGNER1), address(0), RECIPIENT1, 1 ether, 3 ether, start, start + 7 days, 1, start + 7 days);
             // Renewal for week two: payments valid from day 7, submission deadline day 14.
             ClausProjectWallet.SessionAuthorization memory g2 = ClausProjectWallet.SessionAuthorization(
                 SESSION, vm.addr(SIGNER2), address(0), RECIPIENT2, 1 ether, 3 ether, start + 7 days, start + 14 days, 2, start + 14 days);
             bytes memory s1 = sig(OWNER_KEY, wallet.sessionDigest(g1));
             bytes memory s2 = sig(OWNER_KEY, wallet.sessionDigest(g2));
             wallet.authorizeSession(g1, s1);
     
             ClausProjectWallet.Payment memory p1 = ClausProjectWallet.Payment(
                 SESSION, 1, address(0), RECIPIENT1, 1 ether, keccak256("order-1"), 1, start + 1 days);
             wallet.pay(p1, sig(SIGNER1, wallet.paymentDigest(p1)));
             assertEq(RECIPIENT1.balance, 1 ether);
     
             // Day 1: an unrelated account submits the week-two renewal six days early.
             vm.warp(start + 1 days);
             vm.prank(address(0xDEAD));
             // Expected: rejected, the renewal is not yet valid (block.timestamp < validAfter).
             // Actual on current code: accepted; generation becomes 2, spent resets to 0.
             vm.expectRevert(ClausProjectWallet.InvalidSession.selector);
             wallet.authorizeSession(g2, s2);
     
             // The active week-one session must still be able to pay its remaining allowance.
             ClausProjectWallet.Payment memory p2 = ClausProjectWallet.Payment(
                 SESSION, 1, address(0), RECIPIENT1, 1 ether, keccak256("order-2"), 2, start + 2 days);
             wallet.pay(p2, sig(SIGNER1, wallet.paymentDigest(p2)));
             assertEq(RECIPIENT1.balance, 2 ether);
         }
     }

     whole proof

   • lowCancelled signer recovery leaves pre-signed future-generation approvals valid, so schedule-then-cancel cannot be used as an emergency invalidation of a suspected keysrc/ClausApprovalExecutor.sol:222

     clausGeneration is a predictable counter. scheduleSignerRecovery increments it once and cancelSignerRecovery increments it again while keeping the same clausSigner. An approval signed by the current key with clausGeneration equal to the current value plus two is rejected today but becomes valid the moment the recovery owner schedules and then cancels a recovery.

     The recovery owner therefore cannot use schedule-then-cancel to revoke material a suspected-compromised key may already have signed; the only safe exit is a completed rotation to a different key. README and AUDIT_RESPONSE document this, so it is reported as a verified retained limitation of the emergency control rather than a permission bypass.

     A minimal fix that preserves the design is to make cancellation unreachable for pre-signed material, for example by requiring cancellation to rotate to a new signer, or by mixing an unpredictable on-chain value (a recovery-owner-supplied salt stored at cancellation) into the authority an approval must match.

     whole finding

     State: executor at clausGeneration 1, project registered with minDelay 1 hour, module second deployed.

     Input: Claus key signs Approval{clausGeneration: 3, nonce: 1, notBefore: now, expiresAt: now+30d}, all other fields valid. queue(a, sig) reverts InvalidApproval (expected). recoveryOwner calls scheduleSignerRecovery(X) then cancelSignerRecovery(); clausGeneration() == 3 and clausSigner() is unchanged. queue(a, sig) now succeeds; after 1 hour execute(a, "second", sig) installs second (target.implementation() == second).

     Expected: a recovery cancelled without rotation does not activate signatures the key produced before it.

     Actual: it does.

     Verified with a scratch Foundry test on this tree.

     whole reproduction

   • lowVault receive() routes through the 250k policy staticcall, so plain transfer()/send() deposits under the 2300-gas stipend always failsrc/ClausNativeVault.sol:44

     receive() forwards to deposit(), which performs a STATICCALL to the admission policy with POLICY_GAS = 250_000 and then two storage writes. Any sender that uses Solidity's transfer()/send() or otherwise forwards only the 2300-gas stipend (many multisig modules, payment splitters, exchange withdrawals) cannot deposit: transfer() reverts the sender's transaction and send() returns false with the ETH staying at the sender.

     No ETH is attributed or lost, but a payable receive() that unconditionally fails under the stipend contradicts the usual expectation and integrators relying on send()'s return value see silent failures. Merged from two specialist reports (audit_permissions, audit_economics).

     Fix: document that deposits require a call with roughly 300k gas (deposit() as the only supported entry), or do not route receive() through the policy call.

     Deploy ClausVaultAdmission, ClausReadonlyProject(id, admission, abi.encode(true, 100 ether)), ClausNativeVault(policy).

     From contract PlainSender { function viaTransfer(address payable v) external payable { v.transfer(msg.value); } function viaSend(address payable v) external payable returns (bool) { return v.send(msg.value); } }: s.viaTransfer{value: 1 ether}(vault) -> expected deposit of 1 ether credited, actual revert with empty data; s.viaSend{value: 1 ether}(vault) -> returns false; vault.principal(address(s)) == 0 and totalPrincipal == 0 afterward.

     Control: address(vault).call{value: 1 ether}("") with full gas succeeds and credits 1 ether.

     Verified with a scratch Foundry test on this tree.

     whole reproduction

   • infoTrust assumption: vault does not verify that admissionPolicy is governed by the timelocked executorsrc/ClausNativeVault.sol:24

     The vault only requires admissionPolicy to have code. ClausReadonlyProject sets executor = msg.sender in its constructor, so a ClausReadonlyProject deployed directly by an EOA (exactly how the repository's own ClausNativeVault.t.sol setUp wires it) gives that EOA instant, undelayed applyUpgrade power over the admission module and configuration.

     The README states that admission changes follow the Claus approval path, but nothing on-chain in the vault pins the policy's executor to ClausApprovalExecutor. Impact is limited to closing or widening new deposits; withdrawals and principal cannot be affected (verified: withdraw never consults the policy).

     Recommendation: record the admission project's deployer and executor address in DEPLOYMENTS.json, or have the vault constructor read ClausReadonlyProject(policy).executor() and require it to equal the known executor.

     State: policy = new ClausReadonlyProject(id, admission, abi.encode(true, 2 ether)) deployed by EOA D; vault = new ClausNativeVault(policy); a 1 ether deposit succeeds.

     Input: D calls policy.applyUpgrade(admission, abi.encode(false, 0)) in a single transaction with no delay (policy.executor() == D).

     Afterwards any deposit() reverts DepositDenied, while withdraw(1 ether, recipient) still pays out.

     Expected per README: admission changes require a Claus approval and the project's queue delay.

     Actual: immediate, because the vault accepts any code-bearing policy address.

     Verified with a scratch Foundry test on this tree.

     whole reproduction

   • infoTrust assumption: recovery owner can suspend all upgrades indefinitely by rescheduling recoverysrc/ClausApprovalExecutor.sol:217

     scheduleSignerRecovery may be called while a recovery is already pending; each call resets recoveryReadyAt and bumps clausGeneration, and _validate rejects every approval while pendingSigner != 0. The immutable recoveryOwner can thus keep every project's upgrade path paused forever without ever completing a rotation, and can also replace clausSigner with any address after recoveryDelay. Project owners have no veto and cannot migrate their project to another executor.

     AUDIT_RESPONSE discloses this; it is recorded here with the concrete state so the deployment policy (distinct, recoverable recovery key) is checked against it. No code change is required if the trust model is accepted; otherwise reject schedule while a recovery is pending, or let project owners opt out of a paused executor.

     State: approval a (clausGeneration 1) queued with a valid Claus signature; recoveryDelay 2 days. recoveryOwner calls scheduleSignerRecovery(X); warp 2 days - 1; scheduleSignerRecovery(X) again; warp 2 days - 1. finishSignerRecovery() reverts NotReady and execute(a, "second", sig) reverts InvalidApproval.

     Repeating the reschedule indefinitely keeps this state.

     Verified with a scratch Foundry test on this tree.

   • infoPending project-owner proposal never expires; a stale proposee can accept at any later time while upgrades stay suspendedsrc/ClausApprovalExecutor.sol:186

     proposeProjectOwner stores the proposee with no deadline. Until the owner explicitly proposes address(0), the proposee may call acceptProjectOwner at any time, and meanwhile _validate rejects all approvals for the project. An owner who proposes a wrong or abandoned address and forgets to cancel has handed a latent claim on the project to that address and left upgrades suspended.

     README asks owners to cancel stale proposals; this records the concrete behavior. A minimal fix is a proposal expiry (for example 7 days) checked in acceptProjectOwner.

     State: project registered, owner O.

     Input: O calls proposeProjectOwner(ID, S).

     An approval with authorityGeneration 2 and a valid Claus signature is rejected with InvalidApproval while the proposal is pending.

     730 days later S calls acceptProjectOwner(ID): projects(ID).owner == S.

     Expected: a bounded acceptance window or an explicitly documented indefinite claim.

     Actual: indefinite.

     Verified with a scratch Foundry test on this tree.

7. Onchain1 receipt, 5 scores queuedon Ethereum mainnet

   receipt

   work accepted · record queued

   scores

   5 scores for reviewed on submission · all 5 passed#1726#1229#729#1001#368