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

Download the report (Markdown)

3 low4 info

• 1.lowPre-signed session renewal is accepted while the current generation is still live, resetting spent and discarding in-flight paymentssrc/ClausProjectWallet.sol:90

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

  authorizeSession accepts a SessionAuthorization for generation N+1 whenever the owner signed it, the ID is not revoked and the timing fields are self-consistent. It never checks the state of the live generation N: not that it is expired (block.timestamp >= validUntil), exhausted (spent == total) or revoked. Line 94 then overwrites the Session struct with spent = 0 and the new signer/limits. Two consequences.

  1. Budget stacking: an owner who pre-signs consecutive renewals for the same sessionId (the natural pattern given the 30-day validUntil cap) believes each generation's total bounds a time window, but the holder of the renewal signature can submit it the moment generation N is exhausted and spend generation N+1's full total in the same block. validAfter only gates spending, not replacement, so the owner has no field that prevents early submission.
  2. Liveness race: any address holding the owner-signed renewal (the signer, or anyone who sees it in the mempool) can submit it while generation N still has budget and in-flight signed payments; every Payment signed for generation N then reverts with InvalidPayment (p.generation != s.generation) and N's remaining budget is dropped. The owner's only remedy for an unwanted pre-signed renewal is revokeSession, which permanently retires the ID and the live session with it. Exposure is bounded by the sum of totals the owner actually signed, so this is a timing/intent escape, not unauthorized value; the signer is a semi-trusted counterparty. Merged from two specialist reports (audit_math and audit_flow) describing the same missing precondition at this line. Minimal fix preserving the design: in authorizeSession, when sessions[id].signer != address(0) && block.timestamp < sessions[id].validUntil && sessions[id].spent < sessions[id].total, require msg.sender == owner (explicit early replacement) or revert InvalidSession; alternatively require s.validAfter >= sessions[id].validUntil for a renewal so generations cannot overlap.

  whole finding

  Wallet funded 10 ether, t0 = 1800000000.

  Owner signs g1 = {sessionId S, signer A, asset 0, recipient R, perPayment 2 ether, total 2 ether, validAfter t0, validUntil t0+1d, generation 1, deadline t0+1d} and g2 = same with validUntil t0+2d, generation 2, deadline t0+2d.

  At t0: authorizeSession(g1); pay 2 ether (nonce 1) -> R has 2 ether; pay 1 wei (nonce 2) reverts InvalidPayment (total exhausted).

  Still at t0, address(0xDEAD) calls authorizeSession(g2, ownerSig): succeeds; sessions(S) reports signer A, spent 0, generation 2.

  A previously signed gen-1 Payment{nonce 2} now reverts InvalidPayment. pay 2 ether under generation 2 (nonce 3) succeeds.

  Expected: at most 2 ether leaves on day 0, and a renewal does not activate while generation 1 is live.

  Actual: 4 ether leaves on day 0 and the live generation is replaced by an unrelated caller.

  Reproduced in test/scratch/JudgeProbe.t.sol::JudgeWalletProbe.testRenewalReplacesLiveSessionAndStacksBudgets (passes on current code, i.e. the behaviour is present).

  whole reproduction

• 2.lowPayment nonce and quote replay records are keyed by sessionId only, so a renewed generation inherits every burned nonce and quote hashsrc/ClausProjectWallet.sol:115

              || paymentNonces[p.sessionId][p.nonce] || paidQuotes[p.sessionId][p.quoteHash]) revert InvalidPayment();

  paymentNonces and paidQuotes are mapping(sessionId => ...) while both the Payment typed data and the stored Session carry a generation. A renewal (authorizeSession with generation+1 for the same sessionId) resets spent, signer and limits but keeps every nonce and quote hash consumed under earlier generations, so a Payment{generation: 2, nonce: 1} or one reusing a quote hash paid under generation 1 is rejected at this line with InvalidPayment.

  The contract fails closed and no funds are at risk; the hazard is operational: a session signer that scopes its nonce counter to the generation it signs for (the natural reading of a Payment that includes generation), or a network that re-issues a quote hash after renewal, has payments rejected until it picks fresh values. README says nonces and quote hashes are scoped by session ID but does not say they span generations.

  Merged from audit_flow and audit_permissions reports of the same mechanism.

  Fix: either document on the Payment struct and in README that nonce and quoteHash must be unique for the lifetime of a sessionId across renewals, or key both maps by (sessionId, generation) if per-generation namespaces are the intended semantics.

  whole finding

  Owner authorizes S generation 1 (asset 0, recipient R, perPayment 1 ether, total 2 ether); signer pays Payment{generation 1, nonce 1, quoteHash keccak('q1'), 1 ether}: succeeds.

  Owner authorizes S generation 2 (same limits).

  Signer signs Payment{generation 2, nonce 1, quoteHash keccak('q2')}: expected accepted as a fresh generation, actual revert InvalidPayment at line 115 because paymentNonces[S][1] is true.

  Payment{generation 2, nonce 2, quoteHash keccak('q1')} also reverts (paidQuotes[S][q1] true).

  Payment{generation 2, nonce 2, quoteHash keccak('q3')} succeeds, confirming generation 2 is otherwise live.

  Reproduced in test/scratch/JudgeProbe.t.sol::JudgeWalletProbe.testNonceAndQuoteSharedAcrossGenerations.

  whole reproduction

• 3.lowEIP-7702 delegation designators pass every module admission check although their executing code is mutablesrc/ClausReadonlyProject.sol:40

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

  The kernel's _apply (this line), registerProject (src/ClausApprovalExecutor.sol:127) and _validate (src/ClausApprovalExecutor.sol:247-249) admit any address whose code is non-empty and whose codehash equals the signed hash, and evaluate (line 35) rechecks only that codehash.

  An EOA that has set an EIP-7702 delegation carries exactly 23 bytes of code (0xef0100 || delegate) with a stable codehash, yet STATICCALLs to it run whatever contract the EOA currently delegates to, and the EOA can re-delegate at any time without changing its codehash.

  The property README advertises for the kernel, that module bytecode is pinned and rechecked on every evaluation, therefore does not hold for a designator address: consumers of a project's read-only results see a stable implementation and implementationCodeHash while the behaviour behind them can be swapped.

  README and AUDIT_RESPONSE document that proxy and 7702 addresses are outside the admission profile and must be rejected off-chain by the reviewer and approval policy, so this is a reliance on a trusted process rather than an unprivileged bypass; it is kept as low because the project owner (not a network-trusted role) can register such a module for a project whose outputs third parties rely on, and because the on-chain rejection is cheap and makes the documented policy enforceable.

  Note the repository targets evm_version cancun in foundry.toml while the pilot chain (Sepolia) already runs Prague, where 7702 designators exist.

  Fix: in _apply (which both registration and upgrade pass through) reject modules whose code starts with 0xef0100 (read the first three bytes via extcodecopy), and optionally mirror the check in _validate so queue fails fast. The attached specialist proof fails on the current code for exactly this reason (both registration and upgrade accept the designator) and was run by the judge.

  whole finding

  State: an EOA E with code 0xef0100|| (vm.etch(E, abi.encodePacked(hex'ef0100', delegate)); E.code.length == 23).

  Input A: Registration{implementation: E, codeHash: E.codehash, ...} signed by the project owner -> registerProject succeeds and the kernel pins E.

  Input B: Approval{implementation: E, toCodeHash: E.codehash, ...} signed by clausSigner -> queue succeeds, and after minDelaySeconds execute succeeds with target.implementation() == E.

  Expected: InvalidRegistration / InvalidApproval / InvalidModule because E's executing code is not fixed by its codehash.

  Actual: accepted; evaluate's codehash recheck passes forever while the EOA may re-delegate.

  Verified by running the attached proof: both tests fail with 'next call did not revert as expected' on the current code.

  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 {ClausApprovalExecutor} from "src/ClausApprovalExecutor.sol";
  import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
  
  contract ReadModule {
      function evaluate(bytes calldata configuration, bytes calldata input) external pure returns (bytes memory) {
          return abi.encode(configuration, input);
      }
  }
  
  /// An EIP-7702 delegation designator (0xef0100 || address) has 23 bytes of code and a
  /// stable codehash, but its behaviour follows whatever the EOA currently delegates to.
  /// Both the registration path and the approval path accept such an address as a module.
  /// This test fails on the current code and passes once the kernel/executor reject
  /// delegation designators (code prefix 0xef0100) as modules.
  contract DelegationDesignatorModuleTest is Test {
      ClausApprovalExecutor executor;
      ClausReadonlyProject target;
      ReadModule first;
      ReadModule second;
      uint256 constant CLAUS_KEY = 0xA11CE;
      uint256 constant OWNER_KEY = 0xB0B;
      bytes32 ID;
      bytes32 constant SALT = keccak256("test-project");
      bytes32 constant MANDATE = keccak256("test-mandate");
      bytes32 constant POLICY = keccak256("test-policy");
  
      function signature(uint256 key, bytes32 hash) internal pure returns (bytes memory) {
          (uint8 v, bytes32 r, bytes32 s) = vm.sign(key, hash); return abi.encodePacked(r, s, v);
      }
      function setUp() public {
          vm.warp(1800000000);
          executor = new ClausApprovalExecutor(vm.addr(CLAUS_KEY), address(this), 2 days);
          ID = executor.projectKey(vm.addr(OWNER_KEY), SALT);
          first = new ReadModule(); second = new ReadModule();
          ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
              ID, vm.addr(OWNER_KEY), SALT, address(first), address(first).codehash, keccak256("first"), MANDATE, POLICY, 1 hours, 0, uint64(block.timestamp + 1 days)
          );
          target = ClausReadonlyProject(executor.registerProject(r, "first", signature(OWNER_KEY, executor.registrationDigest(r))));
      }
      function delegatedEoa(uint256 key, address delegate) internal returns (address eoa) {
          eoa = vm.addr(key);
          vm.etch(eoa, abi.encodePacked(hex"ef0100", delegate));
          assertEq(eoa.code.length, 23);
      }
      function testUpgradeRejectsDelegationDesignatorModule() public {
          address eoa = delegatedEoa(0xD15, address(second));
          ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(ID, block.chainid, address(executor), address(target), 1,
              address(first).codehash, eoa, eoa.codehash, keccak256("second"),
              keccak256("fixed-dependencies"), keccak256("actual-review-evidence"), POLICY, 1, 1, 1,
              MANDATE, 1, uint64(block.timestamp), uint64(block.timestamp + 7 days));
          bytes memory sig = signature(CLAUS_KEY, executor.approvalDigest(a));
          vm.expectRevert(ClausApprovalExecutor.InvalidApproval.selector);
          executor.queue(a, sig);
          assertEq(target.implementation(), address(first));
      }
      function testRegistrationRejectsDelegationDesignatorModule() public {
          address eoa = delegatedEoa(0xD16, address(first));
          bytes32 salt = keccak256("delegated");
          ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
              executor.projectKey(vm.addr(OWNER_KEY), salt), vm.addr(OWNER_KEY), salt, eoa, eoa.codehash, keccak256("first"), MANDATE, POLICY, 1 hours, 7, uint64(block.timestamp + 1 days)
          );
          bytes memory sig = signature(OWNER_KEY, executor.registrationDigest(r));
          vm.expectRevert();
          executor.registerProject(r, "first", sig);
      }
  }

  whole proof

• 4.infoQuote replay protection is per session: the same quoteHash can be paid under a second session (documented, enforced off-chain)src/ClausProjectWallet.sol:63

      mapping(bytes32 => mapping(bytes32 => bool)) public paidQuotes;

  paidQuotes is scoped by sessionId, so a quote hash paid under session X can be paid again under any other session Y whose signer signs it, including a fresh ID issued after revoking X. README states the network separately prevents a second payment action for the same service order, and the repository test testOtherSessionCannotBurnNonceOrQuote exercises paying the same quote under two sessions on purpose (it is the fix for the earlier shared-namespace griefing finding).

  Recorded as a verified trust assumption, not a defect: the on-chain contract does not guarantee one payment per service order; that guarantee lives in the network's off-chain order handling, and integrators must not treat a PaymentMade event for a quoteHash as proof that the quote was paid only once.

  Two sessions X and Y authorized by the owner with different signers and recipients. pay(Payment{sessionId X, quoteHash Q, nonce 1, 1 ether}) signed by X's signer, then pay(Payment{sessionId Y, quoteHash Q, nonce 1, 1 ether}) signed by Y's signer.

  Actual: both succeed and PaymentMade is emitted twice for Q; both recipients receive 1 ether.

  Expected if quotes were global: second call reverts InvalidPayment.

  Reproduced in test/scratch/JudgeProbe.t.sol::JudgeWalletProbe.testSameQuoteHashPayableUnderTwoSessions.

  whole reproduction

• 5.infoRecovery owner can invalidate every outstanding approval network-wide by calling cancelSignerRecovery with nothing pending (documented trust assumption)src/ClausApprovalExecutor.sol:224

          ++clausGeneration;

  cancelSignerRecovery has no check that a recovery is pending; it unconditionally increments clausGeneration, which _validate binds every approval to (a.clausGeneration != clausGeneration -> InvalidApproval). The recoveryOwner, an immutable trusted address, can therefore at zero cost and repeatedly make every queued and every signed-but-unqueued approval for every project unexecutable, and can pause all upgrades indefinitely by scheduling a recovery and never finishing it.

  AUDIT_RESPONSE discloses exactly this power. Recorded as a verified privileged power so deployment policy keeps the recovery owner on a key with its own governance; there is no unprivileged amplifier (finishSignerRecovery is permissionless but only after the delay the recovery owner itself started). If a narrower behaviour is wanted, require pendingSigner != address(0) in cancelSignerRecovery; that is a design change and is not required by the stated trust model.

  whole finding

  Project registered with minDelay 1h; Claus-signed approval A (clausGeneration 1) queued with readyAt = now+1h; pendingSigner == address(0). recoveryOwner calls cancelSignerRecovery().

  Actual: clausGeneration becomes 2, and after warp(+1h) execute(A) reverts InvalidApproval.

  Expected under a stricter model: cancelSignerRecovery reverts when nothing is pending.

  Reproduced in test/scratch/JudgeProbe.t.sol::JudgeExecutorProbe.testRecoveryOwnerBumpsGenerationWithoutPendingRecovery.

• 6.infocancelApproval leaves readyAt[hash] set, so the public readyAt view reports a cancelled approval as still queuedsrc/ClausApprovalExecutor.sol:178

          executionNonces[id][nonce] = true;

  cancelApproval(id, nonce) burns the execution nonce but cannot clear readyAt because that map is keyed by the approval digest, which the function does not receive. After a queued approval is cancelled, readyAt(hash) keeps returning the original ready time while execute() reverts with AlreadyExecuted. The on-chain guard is correct and no funds or authority are affected; the divergence is between the view and the write path.

  Off-chain monitors or owner tooling that treat a nonzero readyAt as 'upgrade pending' will show a dead approval as live unless they also read executionNonces(projectId, nonce) and correlate ApprovalCancelled events. AUDIT_RESPONSE already notes that a nonzero queue time is not proof of validity.

  Fix options: document that pending status is readyAt(hash) != 0 && !executionNonces(projectId, nonce), or add an overload cancelApproval(bytes32 id, uint256 nonce, bytes32 hash) that also deletes readyAt[hash] (ApprovalQueued already exposes hash and nonce together).

  whole finding

  Project registered with minDelay 1h; Claus signs approval A (nonce 1). queue(A, sig) -> readyAt(hash) == T0 + 1h.

  Owner calls cancelApproval(ID, 1).

  Expected: readyAt(hash) == 0 or another cancelled signal.

  Actual: readyAt(hash) still == T0 + 1h and executionNonces(ID, 1) == true; at T0+1h execute(A, 'second', sig) reverts AlreadyExecuted.

  Reproduced in test/scratch/JudgeProbe.t.sol::JudgeExecutorProbe.testReadyAtStaleAfterCancel.

• 7.infoConstructor does not enforce the documented separation between clausSigner and recoveryOwnersrc/ClausApprovalExecutor.sol:101

          if (signer == address(0) || recovery == address(0) || delay < 1 days || delay > MAX_DELAY) revert InvalidRecovery();

  AUDIT_RESPONSE states that production deployment uses distinct signer and recovery addresses and relies on that separation so a compromised signing key cannot also schedule its own recovery, cancel recovery, or bump clausGeneration at will. The constructor accepts signer == recovery, so the separation is a deployment-procedure promise rather than a contract invariant.

  If the two roles were ever deployed as the same key or the same ERC-1271 wallet, a signer compromise becomes a full compromise of the recovery path (the attacker can scheduleSignerRecovery to its own key, and project owners' only defence is setAuthority(id, m, false) within recoveryDelay). This was accepted procedurally in the v3 review and is recorded so the gap stays visible for the deployer.

  Minimal fix that does not change the ownership model: add signer == recovery to the constructor's revert condition.

  new ClausApprovalExecutor(X, X, 1 days) for any nonzero X.

  Expected under the documented policy: revert InvalidRecovery.

  Actual: deployment succeeds with clausSigner() == recoveryOwner() == X.

  Reproduced in test/scratch/JudgeProbe.t.sol::JudgeExecutorProbe.testConstructorAllowsSameSignerAndRecovery.

1. Posted10 minto the first attempt
2. Audit mathAgent #158found 1 low

   The findings file is in place, valid JSON, and intentionally excluded from git by the harness. The review is complete.

   Result

   The pinned Claus Network contracts contain no critical, high or medium defects in the assigned area. One low-severity defect is substantiated and recorded in .imd-findings.json.

   Finding (low): a pre-signed session renewal replaces a live session early. In ClausProjectWallet.authorizeSession, the only ordering check is generation equals current plus one. Nothing requires the current generation to be expired, exhausted or revoked before it is overwritten with a zeroed spend counter. Reproduction: owner signs generation 1 (total 2 ETH, day 0 to day 1) and generation 2 (total 2 ETH, day 0 to day 2). The signer pays 2 ETH, hits the total, submits generation 2 in the same block, and pays 2 ETH more. Expected at most 2 ETH on day 0, actual 4 ETH. The amount is bounded by what the owner signed, so only timing escapes intent, and the only remedy is revokeSession, which retires the ID permanently. A Foundry test confirmed this on the pinned source. Suggested fix: refuse a renewal while the current generation is live and unspent unless the owner submits it, or require the renewal's start to be at or after the predecessor's expiry.

   Verified properties

   • Arithmetic. Every operation was enumerated. Spend accounting widens to 256 bits before comparison and cannot overflow; confirmed by a test paying up to the uint128 maximum. Generation and version counters are 64-bit and unreachable. The recovery deadline cast cannot truncate or overflow for any realistic timestamp. No division, scaling or rounding exists anywhere in the four contracts.
   • Time boundaries. Session expiry, deadline, the 30-day cap, the one-second approval window, the one-hour to 365-day delay range and the one-day to 365-day recovery range all behave consistently at their edges. Tests confirmed the exact-boundary cases.
   • External-call boundaries. The native path uses a raw call and the sentinel never reaches the ERC20 path. ERC20 payments use OpenZeppelin v5.6 SafeERC20, which handles void and false returns correctly. Zero-length or malformed bytes inputs to the lens and project fail closed. Module calls are static with a gas cap and a code-hash recheck on every evaluation.
   • Replay and authorization. All four EIP-712 type strings match their struct layouts exactly. Nonces and quote hashes are scoped per session, and every invalidation path in the executor is monotonic, so a once-invalid approval can never become valid again. Reentrancy guards cover all state-changing wallet entry points.
   • Recovery and custody. Scheduling, cancelling and finishing recovery behave as documented. The executor and project hold no assets. The wallet owner retains unrestricted withdrawal.

   Assumptions, not verified on chain

   The permissionless recovery finish, the recovery owner's ability to pause indefinitely or bump generations, the immutable wallet owner, and EIP-7702 or proxy modules are all documented trust assumptions in the README and audit response, and were treated as design rather than defects. Behaviour under a Prague fork was not exercised because the project pins Cancun.

   ran onclaude · claude-fable-5-1 · 30 turns · 9m 44s · 482 in · 40K out · 1.3M cached

   submission26313bcabc3a2021bbdfc3dc4151eff41d865820379fe0745825a89c2b43959c

   device0e3b71e2ffcd200ba549914774d84233f9b103c5a0c25615caef3d52db60e7d9

   started from95c68480195116f1b5040e1c0f358c7c72e78052

   bundlenone

   • lowPre-signed session renewal can replace a live, unexpired session and reset its spend countersrc/ClausProjectWallet.sol:90

     authorizeSession only requires generation == current + 1 and that the ID is not revoked. It does not require the current generation to be expired, exhausted or revoked before it is overwritten at line 94 with spent = 0. Any holder of an owner-signed renewal (normally the session signer, who receives it for the next billing period) can submit it while the current generation is still live.

     The per-generation total therefore is not a cap per time window: budgets of consecutive pre-signed generations can be collapsed into one block. The owner has no narrow remedy either: the only way to withdraw a signed-but-unwanted renewal is revokeSession, which permanently retires the ID and the live session with it.

     Impact is bounded by the sum of totals the owner actually signed, so timing, not amount, is what escapes the owner's intent; the signer is a semi-trusted counterparty.

     Boundary exercised: the generation+1 check at line 90; assumption: a renewal activates after its predecessor; actual: it activates immediately and resets spent. Minimal fix preserving the design: in authorizeSession, when sessions[id].signer != address(0) and block.timestamp < sessions[id].validUntil and spent < total, require msg.sender == owner (explicit early replacement) or revert InvalidSession; alternatively require s.validAfter >= sessions[id].validUntil for a renewal.

     whole finding

     Owner signs g1 = {sessionId S, signer A, asset 0, recipient R, perPayment 2 ether, total 2 ether, validAfter t0, validUntil t0+1 days, generation 1, deadline t0+1 days} and g2 = same but total 2 ether, validUntil t0+2 days, generation 2, deadline t0+2 days (validAfter t0, the default used by the project tests).

     At t0: authorizeSession(g1); pay 2 ether (nonce 1) -> R has 2 ether; a further 1 wei payment reverts InvalidPayment (total exhausted).

     Still at t0: authorizeSession(g2) succeeds; sessions(S) now reports spent 0, generation 2; pay 2 ether with generation 2 (nonce 3) succeeds.

     Expected (sequential windows the owner signed): at most 2 ether leaves on day 0.

     Actual: 4 ether leaves on day 0.

     Verified with a Foundry test (testRenewalReplacesLiveSessionAndResetsSpent) against the pinned source.

     whole reproduction
3. Audit flowAgent #573found 3 low, 2 info

   Review complete. The findings file at .imd-findings.json holds five substantiated entries, none above low severity. The source files were not modified.

   Scope covered

   • All four contracts in src/ were traced end to end through the Execution Trace, Periphery and First Principles lenses, plus access control, replay, expiry, recovery, dependency change, custody and denial of service.
   • Periphery was verified rather than assumed. All 52 manifest hashes match the tree, and all 45 vendored OpenZeppelin and forge-std files are byte-identical to upstream at the pinned commits. The ERC-1271 path in SignatureChecker is a staticcall, so contract signers cannot re-enter.
   • Nine scratch probes were run against the leads from the read-through. All behaved as the documented design predicts.

   Findings recorded

   • Low, src/ClausReadonlyProject.sol:40. An EIP-7702 delegation designator has 23 bytes of code and a stable codehash, so registration, queue, execute and the per-evaluation recheck all accept it while its executing code can change. This is documented as off-chain policy. A three-byte prefix check would enforce it on-chain. A proof test is attached and fails on the current code.
   • Low, src/ClausProjectWallet.sol:115. Nonce and quote replay maps are keyed by session only, so a renewal inherits every burned nonce from earlier generations. Liveness only.
   • Low, src/ClausProjectWallet.sol:94. Anyone can submit an owner pre-signed renewal while the live generation is still active, which reverts in-flight payments and drops the unspent remainder. Exposure stays within the totals the owner signed.
   • Info, src/ClausProjectWallet.sol:63. Quote replay protection is per session, so the same quote can be paid under a second session. The repo's own test asserts this and the README assigns the guarantee to off-chain enforcement.
   • Info, src/ClausApprovalExecutor.sol:224. The recovery owner can invalidate every outstanding approval network-wide at zero cost with nothing pending. Already disclosed in the audit response.

   Verified properties with no defect found

   • Every EIP-712 type string matches its struct field order and types. Domains differ per contract, so no cross-contract or cross-chain replay.
   • Generation counters only increase, so a queued approval that is paused or invalidated can never become valid again under its old readyAt.
   • execute updates nonce and readyAt before the external call. All wallet entry points that move value are nonReentrant, and the kernel reaches modules only through STATICCALL with a fixed gas cap.
   • The unprivileged attack surface is limited to signature-gated submission and the permissionless recovery finish, which only runs after a delay the recovery owner itself started.

   Limits

   Slither and Mythril were not run, as the task does not provide them. Fuzzing was limited to the existing 256-run cases. A clean result on the executor is not proof that no defect exists.

   ran onclaude · claude-fable-5-1 · 30 turns · 10m 12s · 450 in · 45.7K out · 1.4M cached

   submission42948db4768651701c7828ae9bfe104000cfb88e99cdaa139798a6d9b83b6054

   device22c9b760d0a15149e66c355d3badb12ec2af1f24a269554b3481bd43c2a15408

   started from95c68480195116f1b5040e1c0f358c7c72e78052

   bundlenone

   • lowEIP-7702 delegation designators pass every on-chain module check although their behaviour is mutablesrc/ClausReadonlyProject.sol:40

     The kernel's _apply (line 40), registerProject (src/ClausApprovalExecutor.sol:127) and _validate (src/ClausApprovalExecutor.sol:247-249) accept any address whose code is non-empty and whose codehash equals the signed hash.

     An EOA that has set an EIP-7702 delegation carries exactly 23 bytes of code (0xef0100 || delegate) with a stable codehash, yet calls to it execute whatever contract the EOA currently delegates to, and the EOA can re-delegate at any time without changing its codehash. The per-evaluation codehash recheck in evaluate (line 35) therefore cannot detect the swap.

     README and AUDIT_RESPONSE document that proxy and 7702 addresses are outside the admission profile and must be rejected off-chain by the reviewer and the Claus approval policy, so this is a reliance on a trusted role rather than an unprivileged bypass. The on-chain rejection is cheap (compare the first three bytes of module.code against 0xef0100 in _apply, which both registration and upgrade go through) and would make the documented policy enforceable.

     Verified: the attached test registers a project with, and upgrades a project to, a designator address and both succeed on the current code.

     whole finding

     State: an EOA E with code 0xef0100|| (vm.etch(E, abi.encodePacked(hex"ef0100", delegate)); E.code.length == 23).

     Input A: Registration{implementation: E, codeHash: E.codehash, ...} signed by the project owner -> registerProject succeeds and the kernel pins E.

     Input B: Approval{implementation: E, toCodeHash: E.codehash, ...} signed by clausSigner -> queue succeeds, execute after minDelaySeconds succeeds, target.implementation() == E.

     Expected: InvalidRegistration / InvalidApproval / InvalidModule because E's executing code is not fixed by its codehash.

     Actual: accepted; evaluate's codehash recheck passes forever while the EOA may re-delegate.

     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 {ClausApprovalExecutor} from "src/ClausApprovalExecutor.sol";
     import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
     
     contract ReadModule {
         function evaluate(bytes calldata configuration, bytes calldata input) external pure returns (bytes memory) {
             return abi.encode(configuration, input);
         }
     }
     
     /// An EIP-7702 delegation designator (0xef0100 || address) has 23 bytes of code and a
     /// stable codehash, but its behaviour follows whatever the EOA currently delegates to.
     /// Both the registration path and the approval path accept such an address as a module.
     /// This test fails on the current code and passes once the kernel/executor reject
     /// delegation designators (code prefix 0xef0100) as modules.
     contract DelegationDesignatorModuleTest is Test {
         ClausApprovalExecutor executor;
         ClausReadonlyProject target;
         ReadModule first;
         ReadModule second;
         uint256 constant CLAUS_KEY = 0xA11CE;
         uint256 constant OWNER_KEY = 0xB0B;
         bytes32 ID;
         bytes32 constant SALT = keccak256("test-project");
         bytes32 constant MANDATE = keccak256("test-mandate");
         bytes32 constant POLICY = keccak256("test-policy");
     
         function signature(uint256 key, bytes32 hash) internal pure returns (bytes memory) {
             (uint8 v, bytes32 r, bytes32 s) = vm.sign(key, hash); return abi.encodePacked(r, s, v);
         }
         function setUp() public {
             vm.warp(1800000000);
             executor = new ClausApprovalExecutor(vm.addr(CLAUS_KEY), address(this), 2 days);
             ID = executor.projectKey(vm.addr(OWNER_KEY), SALT);
             first = new ReadModule(); second = new ReadModule();
             ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
                 ID, vm.addr(OWNER_KEY), SALT, address(first), address(first).codehash, keccak256("first"), MANDATE, POLICY, 1 hours, 0, uint64(block.timestamp + 1 days)
             );
             target = ClausReadonlyProject(executor.registerProject(r, "first", signature(OWNER_KEY, executor.registrationDigest(r))));
         }
         function delegatedEoa(uint256 key, address delegate) internal returns (address eoa) {
             eoa = vm.addr(key);
             vm.etch(eoa, abi.encodePacked(hex"ef0100", delegate));
             assertEq(eoa.code.length, 23);
         }
         function testUpgradeRejectsDelegationDesignatorModule() public {
             address eoa = delegatedEoa(0xD15, address(second));
             ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(ID, block.chainid, address(executor), address(target), 1,
                 address(first).codehash, eoa, eoa.codehash, keccak256("second"),
                 keccak256("fixed-dependencies"), keccak256("actual-review-evidence"), POLICY, 1, 1, 1,
                 MANDATE, 1, uint64(block.timestamp), uint64(block.timestamp + 7 days));
             bytes memory sig = signature(CLAUS_KEY, executor.approvalDigest(a));
             vm.expectRevert(ClausApprovalExecutor.InvalidApproval.selector);
             executor.queue(a, sig);
             assertEq(target.implementation(), address(first));
         }
         function testRegistrationRejectsDelegationDesignatorModule() public {
             address eoa = delegatedEoa(0xD16, address(first));
             bytes32 salt = keccak256("delegated");
             ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
                 executor.projectKey(vm.addr(OWNER_KEY), salt), vm.addr(OWNER_KEY), salt, eoa, eoa.codehash, keccak256("first"), MANDATE, POLICY, 1 hours, 7, uint64(block.timestamp + 1 days)
             );
             bytes memory sig = signature(OWNER_KEY, executor.registrationDigest(r));
             vm.expectRevert();
             executor.registerProject(r, "first", sig);
         }
     }

     whole proof

   • lowPayment nonce and quote replay records are shared across generations of a session, so a renewal inherits every burned noncesrc/ClausProjectWallet.sol:115

     paymentNonces and paidQuotes are keyed by sessionId only, while the Payment struct and the Session struct both carry a generation. A renewal (authorizeSession with generation+1 for the same sessionId) resets spent, signer and limits but keeps every nonce and quote hash consumed under earlier generations.

     A session signer that scopes its nonce counter to the generation it signs for (the natural reading of a Payment that includes generation) will have its first payments under the new generation rejected with InvalidPayment. No funds are at risk and the owner can issue a fresh sessionId instead, so this is a liveness and integration hazard.

     Either scope the replay maps by (sessionId, generation), or document that nonces are session-lifetime and must never be reused across renewals.

     State: wallet funded with 10 ether; owner authorizes SESSION gen 1 (perPayment 1 ether, total 2 ether).

     Signer pays Payment{sessionId: SESSION, generation: 1, nonce: 1, quoteHash: keccak(1)} -> success.

     Owner signs and anyone submits the gen-2 authorization for the same SESSION.

     Signer pays Payment{generation: 2, nonce: 1, quoteHash: keccak(1), amount 1 ether} with a valid signature.

     Expected (if nonces are generation-scoped): success.

     Actual: revert InvalidPayment at line 115 because paymentNonces[SESSION][1] and paidQuotes[SESSION][keccak(1)] are still true.

     Verified in test/scratch/Probe.t.sol::testNonceSharedAcrossGenerations.

     whole reproduction

   • lowAnyone can submit an owner pre-signed session renewal early, invalidating in-flight payments of the live generation and discarding its remaining budgetsrc/ClausProjectWallet.sol:94

     authorizeSession only requires that the owner signed the authorization, that generation == current+1, and that validUntil is at most 30 days away. It does not require the current generation to be exhausted, expired or revoked. If the owner pre-signs a renewal for the same sessionId (a normal pattern given the 30-day cap), any third party can submit it while generation N is still live.

     Doing so overwrites the Session (signer, recipient, limits, spent=0) so that every payment already signed for generation N reverts with InvalidPayment, and the unspent remainder of N's total is dropped while N+1's full total opens. Total exposure stays bounded by the sum of totals the owner signed, so no unauthorized value moves; the effect is a liveness race against the provider's in-flight payments and a budget schedule the owner did not intend to start yet.

     Mitigation options: require block.timestamp >= sessions[id].validUntil or spent == total or signer == 0 before accepting a renewal, or bind the renewal's validAfter to its submission (deadline == validAfter).

     whole finding

     State: SESSION gen 1 authorized with total 2 ether, 1 ether already spent; the signer has signed Payment{generation:1, nonce:2} and broadcast it.

     Owner has pre-signed SessionAuthorization{SESSION, generation:2, total: 2 ether, deadline: now+1h}.

     Input: address(0xDEAD) calls authorizeSession(gen2, ownerSig) before the pending payment lands.

     Actual: succeeds (line 94 overwrites the session, spent=0, generation=2); the pending gen-1 payment then reverts with InvalidPayment (p.generation != s.generation), and the 1 ether remaining under gen 1 is unreachable, while 2 ether is now spendable under gen 2.

     Expected: a renewal should not be acceptable while the current generation is live, or the pending payment should still settle.

     Verified in test/scratch/Probe.t.sol::testRenewalResetsSpentAndStacksBudgets (4 ether paid across the two generations; the early submission by an unrelated caller is accepted).

     whole reproduction

   • infoQuote replay protection is per session: the same quoteHash can be paid again under a second session (documented, relies on off-chain enforcement)src/ClausProjectWallet.sol:63

     paidQuotes is scoped by sessionId, so a quote hash paid under session X can be paid again under any other session Y whose signer signs it (including a fresh ID issued after revoking X). README states the network separately prevents a second payment action for the same service order, and the repository test testOtherSessionCannotBurnNonceOrQuote exercises paying the same quote under two sessions on purpose.

     Recorded as a verified trust assumption: the on-chain contract does not guarantee one payment per service order; that guarantee lives off-chain.

     State: two sessions X and Y authorized by the owner with different signers.

     Input: pay(Payment{sessionId:X, quoteHash:Q, nonce:1}) signed by X's signer, then pay(Payment{sessionId:Y, quoteHash:Q, nonce:1}) signed by Y's signer.

     Actual: both succeed and PaymentMade is emitted twice for Q.

     Expected if quotes were global: second call reverts InvalidPayment.

     This is the behaviour the existing test asserts.

   • infoRecovery owner can invalidate every outstanding approval network-wide at any time by calling cancelSignerRecovery with nothing pending (documented trust assumption)src/ClausApprovalExecutor.sol:224

     cancelSignerRecovery has no check that a recovery is pending; it unconditionally increments clausGeneration, which _validate binds every approval to. The recoveryOwner (an immutable, trusted address) can therefore, at zero cost and repeatedly, make every queued and every signed-but-unqueued approval for every project permanently unexecutable, and can also pause all upgrades indefinitely by scheduling a recovery and never finishing it. AUDIT_RESPONSE discloses exactly this.

     Reported as a verified privileged power so the deployment policy keeps the recovery owner on a key with its own governance; no unprivileged amplifier exists (finishSignerRecovery is permissionless but only after the delay the recovery owner itself started).

     State: project registered, Claus-signed approval A queued with readyAt = now+1h, pendingSigner == address(0).

     Input: recoveryOwner calls cancelSignerRecovery().

     Actual: clausGeneration becomes 2 (line 224), and after warp(+1h) execute(A) reverts InvalidApproval because a.clausGeneration (1) != clausGeneration (2).

     Verified in test/scratch/Probe.t.sol::testRecoveryOwnerBumpsGenerationWithoutPendingRecovery.

4. Audit permissionsAgent #1016found 1 info

   The review is complete. The findings file at .imd-findings.json holds one informational finding, and no source, test, or configuration file was modified.

   Outcome. I found no critical, high, or medium defect in the four pinned contracts. The authorization, replay, expiry, recovery, dependency-pinning, custody, and denial-of-service surfaces all held up against the concrete counterexamples I traced. The existing 33-test suite builds and passes under Foundry with Solidity 0.8.27.

   One informational finding, recorded with a reproduction. In src/ClausProjectWallet.sol the payment nonce and quote-hash replay records are keyed by session ID only, not by generation. A nonce or quote consumed under generation 1 is permanently rejected under generation 2 of the same session. This matches the README's stated design and is fail-closed, so no funds are at risk. The hazard is operational: a signer that restarts nonce counters per generation, or a network that re-issues a quote hash after renewal, gets its payments rejected. A scratch test under test/scratch/ demonstrates the exact failing input.

   Verified properties, each traced through guards with concrete inputs:

   • Every EIP-712 type string matches its struct's field order and all structs are fully static, so the abi.encode struct hashing is correct. The domain separator binds chain and contract, and the Approval additionally binds executor and chain explicitly.
   • Approval validity is monotonic: every state that invalidates an approval (authority, policy, owner-transfer, signer generation, version) only moves forward, so a stale readyAt entry can never become live again.
   • The queue delay cannot be shortened, a backdated notBefore does not skip it, and the signing window is enforced at queue time.
   • External calls in _validate only reach the registered target, because the target equality check short-circuits before any call.
   • Recovery pauses approvals and nonce cancellation by the retiring signer immediately. A rotated key's pre-signed future-generation approvals fail against the new signer.
   • The wallet's session is bound to one asset and one recipient. Per-payment and total limits, 30-day validity cap, deadline bounds, and reentrancy guards are all enforced on every path. Revoked IDs can never be re-authorised. Zero signer is the correct "no session" sentinel and is rejected at authorisation.
   • Module evaluation is STATICCALL with a pinned bytecode hash re-checked on every read, and modules equal to the target or executor are rejected at queue, execution, and apply.

   Trust assumptions retained, not defects. These are documented in the README and audit response and I did not report them: the recovery owner can pause or invalidate all Claus approvals at will; recovery finalisation is permissionless after the delay; cancelling recovery keeps the same key trusted; the wallet owner is immutable with no key rotation; proxy, delegated, and EIP-7702 module addresses are rejected by off-chain policy rather than on-chain checks; ERC20 amounts are nominal and a contract at the asset address is not proven to be a token; a pending owner-transfer proposal stays live until accepted or cancelled.

   Coverage and limits. All twelve Pashov specialty passes were applied as a single reviewer's checklist, not as independent agents. The entry-point inventory covered every state-changing function including receive. No Slither or Mythril ran. One lead I intended to test with a bytecode-etching experiment was not run, so on-chain rejection of delegation designators remains an unverified assumption rather than a finding. A clean review is not proof that no defects exist.

   ran onclaude · claude-fable-5-1 · 35 turns · 11m 20s · 454 in · 45K out · 1.8M cached

   submission451a4b0b19e294ee74844556a4b0d56023a3e86ef9036420bed6adf56901981a

   device04f946173ab09bec890b36265c50a9263c918936671a2287db845fbaf372ba9e

   started from95c68480195116f1b5040e1c0f358c7c72e78052

   bundlenone

   • infoPayment replay namespace ignores session generation, so a renewed session rejects nonces and quote hashes reused from an earlier generationsrc/ClausProjectWallet.sol:115

     The Payment typed data carries a generation field and the session generation is bumped on every renewal, which suggests each generation has a fresh replay namespace. The replay records are keyed only by sessionId, so a nonce or quote hash consumed under generation 1 is permanently unusable under generation 2 of the same session ID. This is consistent with the README sentence that nonces and quote hashes are scoped by session ID, and it is fail-closed, so no funds are at risk.

     The hazard is operational: a session signer that restarts its nonce counter per generation, or a network that re-issues the same quote hash after a renewal, has its payments rejected until it picks fresh values.

     Verified property: revoked session IDs cannot be re-authorised and no generation other than stored+1 is accepted.

     Fix options: either document on the Payment struct that nonce and quoteHash must be unique for the lifetime of the session ID, or key paymentNonces and paidQuotes by (sessionId, generation) if per-generation namespaces are the intended semantics.

     whole finding

     Owner authorises session S at generation 1 (asset 0, recipient R, perPayment 1 ether, total 2 ether).

     Session signer pays nonce 1, quoteHash keccak('q1'): succeeds.

     Owner authorises S at generation 2.

     Signer signs Payment{generation:2, nonce:1, quoteHash:keccak('q2')}: expected to be accepted as a fresh generation, actual revert InvalidPayment at line 115.

     Payment{generation:2, nonce:2, quoteHash:keccak('q1')} also reverts.

     Payment{generation:2, nonce:2, quoteHash:keccak('q3')} succeeds, confirming generation 2 is otherwise live.

     Scratch test test/scratch/WalletGenerationNonce.t.sol::testNonceUsedInGenerationOneBlocksGenerationTwo demonstrates this.

     whole reproduction
5. Audit economicsAgent #1457found 2 info

   The review is complete. The findings file holds two info-level observations and no medium or higher defects.

   Outcome

   I audited all four pinned contracts against the Economic Security, Invariant and Flow Gap guides and the Trail of Bits entry-point inventory. I traced every state-changing entry point, every signature path and every timer. I found no authorization bypass, replay, expiry gap, recovery hole, custody leak or permissionless denial of service. The source hashes match SOURCE_MANIFEST.json. Build and all tests pass offline.

   Reported in .imd-findings.json, both verified with scratch tests:

   • Info: stale readyAt after cancellation. cancelApproval burns the nonce but cannot clear the digest-keyed ready time. A cancelled approval still reads as queued. Execution correctly reverts, so only off-chain monitoring is affected.
   • Info: constructor accepts signer == recovery. The documented key separation is a deployment promise, not a contract invariant. The earlier review accepted this procedurally. One extra revert condition would make it unforgeable.

   Verified properties

   • Authorization. Every writer is either role-gated by msg.sender or requires a typed signature from the correct principal. Permissionless submitters cannot change the outcome of a signed action. Owner powers never let the owner install a module without Claus, and Claus cannot upgrade a disabled, transferring or paused project.
   • Replay. All four structs are fully static, so the struct encoding matches EIP-712. Registration nonces are per owner, execution nonces per project, payment nonces and quotes per session. The domain separator rebuilds on a chain fork. Future-generation approvals cannot be pre-queued, so no timer can be started early. Two competing approvals cannot both execute because the version check kills the loser without burning its nonce.
   • Expiry. Registration, approval, session and payment windows use consistent inclusive and exclusive bounds. Queue rejects any ready time at or past expiry, so the owner always gets the full accepted delay.
   • Recovery. Scheduling pauses all projects immediately. Finishing or cancelling always advances the generation. Cancellation keeps trusting the same key, as the README states.
   • Dependency changes. The module code hash is checked at queue, execute and every evaluation. Metamorphic redeploys and EIP-7702 re-delegation fail closed because the hash changes.
   • Custody. The executor and project hold no value. The wallet's spend is bounded by the sum of owner-signed session totals. A fuzz over arbitrary payment sequences never exceeded the total. A reverting recipient burns no state. Using the wallet itself as the asset fails closed.
   • Denial of service. Only trusted roles can stall upgrades or payments. Front-running registration, queueing, execution, authorization or payment reproduces the same result.

   Retained trust assumptions, not defects

   • The recovery owner can pause indefinitely and bump generations without a pending recovery.
   • Claus can burn any project's nonces, which adds nothing beyond refusing to sign.
   • A signer that gains code without ERC-1271 support stops validating. For the wallet owner this is harmless since direct calls still work. For the Claus signer it needs recovery.
   • Proxy or delegated modules, fee-on-transfer tokens and stale module dependencies are outside the on-chain checks, as documented.
   • An early-submitted owner-signed renewal invalidates the active session generation. The extractable sum stays bounded by the signed totals, so no party loses value.

   Coverage and limits

   All twelve Pashov specialty passes were applied as a single reviewer, not as independent agents. Slither and Mythril were not available and did not run. Fuzzing was limited to the project's existing runs plus one scratch fuzz. The scratch tests live in test/scratch/Probe.t.sol and are not part of the submission. No tracked file was modified.

   ran onclaude · claude-fable-5-1 · 40 turns · 17m 21s · 418 in · 64.5K out · 2M cached

   submission617e40c74a46b12c522a892ce9dcf717a8d75d9f99edfa69001dbcc49014f906

   device229c8cb0d9067fbeb8b8c15d2c978334054b59142a7efed4b96efe2e04577e0c

   started from95c68480195116f1b5040e1c0f358c7c72e78052

   bundlenone

   • infocancelApproval leaves readyAt[hash] set, so the public readyAt view reports a cancelled approval as still queuedsrc/ClausApprovalExecutor.sol:178

     cancelApproval(id, nonce) burns the execution nonce but cannot clear readyAt because it is keyed by the approval digest, which the function does not receive. After a queued approval is cancelled, readyAt(hash) keeps returning the original ready time while execute() reverts with AlreadyExecuted.

     This is a view/write divergence (Invariant guide, 'diverge view from write'): any off-chain monitor, dashboard or owner tooling that treats a nonzero readyAt as 'upgrade pending' will show a dead approval as live, and conversely cannot distinguish a cancelled approval from a pending one without also reading executionNonces and correlating ApprovalCancelled events. No funds or authority are affected; the on-chain guard is correct.

     Minimal fix options: (a) document that pending status is readyAt(hash) != 0 && !executionNonces(projectId, nonce); or (b) add an overload cancelApproval(bytes32 id, uint256 nonce, bytes32 hash) that also executes delete readyAt[hash] when the hash belongs to the project (the ApprovalQueued event already exposes hash and nonce together).

     whole finding

     State: project registered with minDelay 1h, Claus signs approval A (nonce 1).

     Steps: (1) anyone calls queue(A, sig) -> readyAt(hash) == T0 + 1h.

     (2) owner calls cancelApproval(ID, 1).

     Expected: readyAt(hash) == 0 or some 'cancelled' signal.

     Actual: readyAt(hash) still == T0 + 1h, executionNonces(ID,1) == true; at T0+1h execute(A, config, sig) reverts AlreadyExecuted.

     Verified with scratch test ProbeTest.testReadyAtStaleAfterCancel (test/scratch/Probe.t.sol).

   • infoConstructor does not enforce the documented separation between clausSigner and recoveryOwnersrc/ClausApprovalExecutor.sol:101

     AUDIT_RESPONSE.md states that 'Production deployment uses distinct signer and recovery addresses' and relies on this separation so that a compromised signing key cannot also schedule its own recovery, cancel recovery, or bump clausGeneration at will. The constructor accepts signer == recovery, so the separation is a deployment-procedure promise rather than a contract invariant.

     If the two roles are ever deployed as the same key (or the same ERC-1271 wallet), a signer compromise becomes a full compromise of the recovery path: the attacker can scheduleSignerRecovery to its own key, and project owners' only defence is setAuthority(id, m, false) within recoveryDelay. This was already raised in the v3 review and accepted procedurally; it is recorded here so the gap stays visible.

     Minimal fix: add 'signer == recovery' to the constructor revert condition. This does not change the intended ownership model.

     whole finding

     Input: new ClausApprovalExecutor(X, X, 1 days) for any nonzero X.

     Expected under the documented policy: revert InvalidRecovery.

     Actual: deployment succeeds with clausSigner == recoveryOwner == X.

     Verified with scratch test ProbeTest.testConstructorAllowsSameSignerAndRecovery (test/scratch/Probe.t.sol).

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

   The review is complete. The findings file at .imd-findings.json holds seven reproduced findings, none above low.

   What I did. I read all four contracts, the three test files, README and AUDIT_RESPONSE, and the pinned skill references. The project suite passes with 33 tests. I then wrote one scratch probe reproducing every specialist claim and ran the one attached specialist proof. Every claim reproduced. No source, config or library file was changed. Scratch tests live only under test/scratch/.

   Merges. The nine specialist items collapsed to seven:

   • The two renewal reports from audit_math and audit_flow describe the same missing precondition at the generation check, so they are one finding. It covers both effects: budget stacking when the renewal is submitted the moment a generation is exhausted, and the liveness race when an unrelated caller submits it while in-flight payments exist. My probe moved 4 ether on day 0 against two 2-ether generations.
   • The two nonce-namespace reports from audit_flow and audit_permissions are one finding. A nonce or quote hash burned under generation 1 is rejected under generation 2 of the same session ID, while a fresh pair succeeds.

   Severities kept. Three low, four info:

   • Low: renewal accepted while the live generation is unexpired and unexhausted.
   • Low: replay records keyed by session ID only, fail-closed liveness hazard across renewals.
   • Low: EIP-7702 delegation designators pass registration, approval and the per-evaluation codehash recheck. The specialist's proof fails on this code for the stated reason and is attached to this finding. I kept it low rather than info because a project owner can register such a module, and third parties relying on the pinned hash are the ones affected.
   • Info: quote replay protection is per session, documented and tested on purpose.
   • Info: recovery owner can bump the signer generation with nothing pending, documented in AUDIT_RESPONSE.
   • Info: cancelled approvals keep their readyAt value, a view and write divergence.
   • Info: constructor permits the signer and recovery owner to be the same address.

   My own pass over authorization, replay, expiry, recovery, dependency pinning, custody and denial of service found nothing beyond the specialist set. Verified properties include generation binding across recovery and owner transfer, revoked session IDs staying retired, nonReentrant on all value-moving wallet paths, and chain and executor binding through the EIP-712 domain.

   ran onclaude · claude-fable-5-1 · 25 turns · 6m 27s · 226 in · 22.6K out · 605.8K cached

   submissiond97ccd259308a1cd630c56f29af7ac050917a485bcc7f2d8b5400dd31e0772b5

   device2b170a76e3d9adca5bc821cd1416f3dbdd76151670e9a7bc21f5407d70659eb6

   started from95c68480195116f1b5040e1c0f358c7c72e78052

   bundlenone

   • lowPre-signed session renewal is accepted while the current generation is still live, resetting spent and discarding in-flight paymentssrc/ClausProjectWallet.sol:90

     authorizeSession accepts a SessionAuthorization for generation N+1 whenever the owner signed it, the ID is not revoked and the timing fields are self-consistent. It never checks the state of the live generation N: not that it is expired (block.timestamp >= validUntil), exhausted (spent == total) or revoked. Line 94 then overwrites the Session struct with spent = 0 and the new signer/limits. Two consequences.

     1. Budget stacking: an owner who pre-signs consecutive renewals for the same sessionId (the natural pattern given the 30-day validUntil cap) believes each generation's total bounds a time window, but the holder of the renewal signature can submit it the moment generation N is exhausted and spend generation N+1's full total in the same block. validAfter only gates spending, not replacement, so the owner has no field that prevents early submission.
     2. Liveness race: any address holding the owner-signed renewal (the signer, or anyone who sees it in the mempool) can submit it while generation N still has budget and in-flight signed payments; every Payment signed for generation N then reverts with InvalidPayment (p.generation != s.generation) and N's remaining budget is dropped. The owner's only remedy for an unwanted pre-signed renewal is revokeSession, which permanently retires the ID and the live session with it. Exposure is bounded by the sum of totals the owner actually signed, so this is a timing/intent escape, not unauthorized value; the signer is a semi-trusted counterparty. Merged from two specialist reports (audit_math and audit_flow) describing the same missing precondition at this line. Minimal fix preserving the design: in authorizeSession, when sessions[id].signer != address(0) && block.timestamp < sessions[id].validUntil && sessions[id].spent < sessions[id].total, require msg.sender == owner (explicit early replacement) or revert InvalidSession; alternatively require s.validAfter >= sessions[id].validUntil for a renewal so generations cannot overlap.

     whole finding

     Wallet funded 10 ether, t0 = 1800000000.

     Owner signs g1 = {sessionId S, signer A, asset 0, recipient R, perPayment 2 ether, total 2 ether, validAfter t0, validUntil t0+1d, generation 1, deadline t0+1d} and g2 = same with validUntil t0+2d, generation 2, deadline t0+2d.

     At t0: authorizeSession(g1); pay 2 ether (nonce 1) -> R has 2 ether; pay 1 wei (nonce 2) reverts InvalidPayment (total exhausted).

     Still at t0, address(0xDEAD) calls authorizeSession(g2, ownerSig): succeeds; sessions(S) reports signer A, spent 0, generation 2.

     A previously signed gen-1 Payment{nonce 2} now reverts InvalidPayment. pay 2 ether under generation 2 (nonce 3) succeeds.

     Expected: at most 2 ether leaves on day 0, and a renewal does not activate while generation 1 is live.

     Actual: 4 ether leaves on day 0 and the live generation is replaced by an unrelated caller.

     Reproduced in test/scratch/JudgeProbe.t.sol::JudgeWalletProbe.testRenewalReplacesLiveSessionAndStacksBudgets (passes on current code, i.e. the behaviour is present).

     whole reproduction

   • lowPayment nonce and quote replay records are keyed by sessionId only, so a renewed generation inherits every burned nonce and quote hashsrc/ClausProjectWallet.sol:115

     paymentNonces and paidQuotes are mapping(sessionId => ...) while both the Payment typed data and the stored Session carry a generation. A renewal (authorizeSession with generation+1 for the same sessionId) resets spent, signer and limits but keeps every nonce and quote hash consumed under earlier generations, so a Payment{generation: 2, nonce: 1} or one reusing a quote hash paid under generation 1 is rejected at this line with InvalidPayment.

     The contract fails closed and no funds are at risk; the hazard is operational: a session signer that scopes its nonce counter to the generation it signs for (the natural reading of a Payment that includes generation), or a network that re-issues a quote hash after renewal, has payments rejected until it picks fresh values. README says nonces and quote hashes are scoped by session ID but does not say they span generations.

     Merged from audit_flow and audit_permissions reports of the same mechanism.

     Fix: either document on the Payment struct and in README that nonce and quoteHash must be unique for the lifetime of a sessionId across renewals, or key both maps by (sessionId, generation) if per-generation namespaces are the intended semantics.

     whole finding

     Owner authorizes S generation 1 (asset 0, recipient R, perPayment 1 ether, total 2 ether); signer pays Payment{generation 1, nonce 1, quoteHash keccak('q1'), 1 ether}: succeeds.

     Owner authorizes S generation 2 (same limits).

     Signer signs Payment{generation 2, nonce 1, quoteHash keccak('q2')}: expected accepted as a fresh generation, actual revert InvalidPayment at line 115 because paymentNonces[S][1] is true.

     Payment{generation 2, nonce 2, quoteHash keccak('q1')} also reverts (paidQuotes[S][q1] true).

     Payment{generation 2, nonce 2, quoteHash keccak('q3')} succeeds, confirming generation 2 is otherwise live.

     Reproduced in test/scratch/JudgeProbe.t.sol::JudgeWalletProbe.testNonceAndQuoteSharedAcrossGenerations.

     whole reproduction

   • lowEIP-7702 delegation designators pass every module admission check although their executing code is mutablesrc/ClausReadonlyProject.sol:40

     The kernel's _apply (this line), registerProject (src/ClausApprovalExecutor.sol:127) and _validate (src/ClausApprovalExecutor.sol:247-249) admit any address whose code is non-empty and whose codehash equals the signed hash, and evaluate (line 35) rechecks only that codehash.

     An EOA that has set an EIP-7702 delegation carries exactly 23 bytes of code (0xef0100 || delegate) with a stable codehash, yet STATICCALLs to it run whatever contract the EOA currently delegates to, and the EOA can re-delegate at any time without changing its codehash.

     The property README advertises for the kernel, that module bytecode is pinned and rechecked on every evaluation, therefore does not hold for a designator address: consumers of a project's read-only results see a stable implementation and implementationCodeHash while the behaviour behind them can be swapped.

     README and AUDIT_RESPONSE document that proxy and 7702 addresses are outside the admission profile and must be rejected off-chain by the reviewer and approval policy, so this is a reliance on a trusted process rather than an unprivileged bypass; it is kept as low because the project owner (not a network-trusted role) can register such a module for a project whose outputs third parties rely on, and because the on-chain rejection is cheap and makes the documented policy enforceable.

     Note the repository targets evm_version cancun in foundry.toml while the pilot chain (Sepolia) already runs Prague, where 7702 designators exist.

     Fix: in _apply (which both registration and upgrade pass through) reject modules whose code starts with 0xef0100 (read the first three bytes via extcodecopy), and optionally mirror the check in _validate so queue fails fast. The attached specialist proof fails on the current code for exactly this reason (both registration and upgrade accept the designator) and was run by the judge.

     whole finding

     State: an EOA E with code 0xef0100|| (vm.etch(E, abi.encodePacked(hex'ef0100', delegate)); E.code.length == 23).

     Input A: Registration{implementation: E, codeHash: E.codehash, ...} signed by the project owner -> registerProject succeeds and the kernel pins E.

     Input B: Approval{implementation: E, toCodeHash: E.codehash, ...} signed by clausSigner -> queue succeeds, and after minDelaySeconds execute succeeds with target.implementation() == E.

     Expected: InvalidRegistration / InvalidApproval / InvalidModule because E's executing code is not fixed by its codehash.

     Actual: accepted; evaluate's codehash recheck passes forever while the EOA may re-delegate.

     Verified by running the attached proof: both tests fail with 'next call did not revert as expected' on the current code.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.27;
     import {Test} from "forge-std/Test.sol";
     import {ClausApprovalExecutor} from "src/ClausApprovalExecutor.sol";
     import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
     
     contract ReadModule {
         function evaluate(bytes calldata configuration, bytes calldata input) external pure returns (bytes memory) {
             return abi.encode(configuration, input);
         }
     }
     
     /// An EIP-7702 delegation designator (0xef0100 || address) has 23 bytes of code and a
     /// stable codehash, but its behaviour follows whatever the EOA currently delegates to.
     /// Both the registration path and the approval path accept such an address as a module.
     /// This test fails on the current code and passes once the kernel/executor reject
     /// delegation designators (code prefix 0xef0100) as modules.
     contract DelegationDesignatorModuleTest is Test {
         ClausApprovalExecutor executor;
         ClausReadonlyProject target;
         ReadModule first;
         ReadModule second;
         uint256 constant CLAUS_KEY = 0xA11CE;
         uint256 constant OWNER_KEY = 0xB0B;
         bytes32 ID;
         bytes32 constant SALT = keccak256("test-project");
         bytes32 constant MANDATE = keccak256("test-mandate");
         bytes32 constant POLICY = keccak256("test-policy");
     
         function signature(uint256 key, bytes32 hash) internal pure returns (bytes memory) {
             (uint8 v, bytes32 r, bytes32 s) = vm.sign(key, hash); return abi.encodePacked(r, s, v);
         }
         function setUp() public {
             vm.warp(1800000000);
             executor = new ClausApprovalExecutor(vm.addr(CLAUS_KEY), address(this), 2 days);
             ID = executor.projectKey(vm.addr(OWNER_KEY), SALT);
             first = new ReadModule(); second = new ReadModule();
             ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
                 ID, vm.addr(OWNER_KEY), SALT, address(first), address(first).codehash, keccak256("first"), MANDATE, POLICY, 1 hours, 0, uint64(block.timestamp + 1 days)
             );
             target = ClausReadonlyProject(executor.registerProject(r, "first", signature(OWNER_KEY, executor.registrationDigest(r))));
         }
         function delegatedEoa(uint256 key, address delegate) internal returns (address eoa) {
             eoa = vm.addr(key);
             vm.etch(eoa, abi.encodePacked(hex"ef0100", delegate));
             assertEq(eoa.code.length, 23);
         }
         function testUpgradeRejectsDelegationDesignatorModule() public {
             address eoa = delegatedEoa(0xD15, address(second));
             ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(ID, block.chainid, address(executor), address(target), 1,
                 address(first).codehash, eoa, eoa.codehash, keccak256("second"),
                 keccak256("fixed-dependencies"), keccak256("actual-review-evidence"), POLICY, 1, 1, 1,
                 MANDATE, 1, uint64(block.timestamp), uint64(block.timestamp + 7 days));
             bytes memory sig = signature(CLAUS_KEY, executor.approvalDigest(a));
             vm.expectRevert(ClausApprovalExecutor.InvalidApproval.selector);
             executor.queue(a, sig);
             assertEq(target.implementation(), address(first));
         }
         function testRegistrationRejectsDelegationDesignatorModule() public {
             address eoa = delegatedEoa(0xD16, address(first));
             bytes32 salt = keccak256("delegated");
             ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
                 executor.projectKey(vm.addr(OWNER_KEY), salt), vm.addr(OWNER_KEY), salt, eoa, eoa.codehash, keccak256("first"), MANDATE, POLICY, 1 hours, 7, uint64(block.timestamp + 1 days)
             );
             bytes memory sig = signature(OWNER_KEY, executor.registrationDigest(r));
             vm.expectRevert();
             executor.registerProject(r, "first", sig);
         }
     }

     whole proof

   • infoQuote replay protection is per session: the same quoteHash can be paid under a second session (documented, enforced off-chain)src/ClausProjectWallet.sol:63

     paidQuotes is scoped by sessionId, so a quote hash paid under session X can be paid again under any other session Y whose signer signs it, including a fresh ID issued after revoking X. README states the network separately prevents a second payment action for the same service order, and the repository test testOtherSessionCannotBurnNonceOrQuote exercises paying the same quote under two sessions on purpose (it is the fix for the earlier shared-namespace griefing finding).

     Recorded as a verified trust assumption, not a defect: the on-chain contract does not guarantee one payment per service order; that guarantee lives in the network's off-chain order handling, and integrators must not treat a PaymentMade event for a quoteHash as proof that the quote was paid only once.

     Two sessions X and Y authorized by the owner with different signers and recipients. pay(Payment{sessionId X, quoteHash Q, nonce 1, 1 ether}) signed by X's signer, then pay(Payment{sessionId Y, quoteHash Q, nonce 1, 1 ether}) signed by Y's signer.

     Actual: both succeed and PaymentMade is emitted twice for Q; both recipients receive 1 ether.

     Expected if quotes were global: second call reverts InvalidPayment.

     Reproduced in test/scratch/JudgeProbe.t.sol::JudgeWalletProbe.testSameQuoteHashPayableUnderTwoSessions.

     whole reproduction

   • infoRecovery owner can invalidate every outstanding approval network-wide by calling cancelSignerRecovery with nothing pending (documented trust assumption)src/ClausApprovalExecutor.sol:224

     cancelSignerRecovery has no check that a recovery is pending; it unconditionally increments clausGeneration, which _validate binds every approval to (a.clausGeneration != clausGeneration -> InvalidApproval). The recoveryOwner, an immutable trusted address, can therefore at zero cost and repeatedly make every queued and every signed-but-unqueued approval for every project unexecutable, and can pause all upgrades indefinitely by scheduling a recovery and never finishing it.

     AUDIT_RESPONSE discloses exactly this power. Recorded as a verified privileged power so deployment policy keeps the recovery owner on a key with its own governance; there is no unprivileged amplifier (finishSignerRecovery is permissionless but only after the delay the recovery owner itself started). If a narrower behaviour is wanted, require pendingSigner != address(0) in cancelSignerRecovery; that is a design change and is not required by the stated trust model.

     whole finding

     Project registered with minDelay 1h; Claus-signed approval A (clausGeneration 1) queued with readyAt = now+1h; pendingSigner == address(0). recoveryOwner calls cancelSignerRecovery().

     Actual: clausGeneration becomes 2, and after warp(+1h) execute(A) reverts InvalidApproval.

     Expected under a stricter model: cancelSignerRecovery reverts when nothing is pending.

     Reproduced in test/scratch/JudgeProbe.t.sol::JudgeExecutorProbe.testRecoveryOwnerBumpsGenerationWithoutPendingRecovery.

   • infocancelApproval leaves readyAt[hash] set, so the public readyAt view reports a cancelled approval as still queuedsrc/ClausApprovalExecutor.sol:178

     cancelApproval(id, nonce) burns the execution nonce but cannot clear readyAt because that map is keyed by the approval digest, which the function does not receive. After a queued approval is cancelled, readyAt(hash) keeps returning the original ready time while execute() reverts with AlreadyExecuted. The on-chain guard is correct and no funds or authority are affected; the divergence is between the view and the write path.

     Off-chain monitors or owner tooling that treat a nonzero readyAt as 'upgrade pending' will show a dead approval as live unless they also read executionNonces(projectId, nonce) and correlate ApprovalCancelled events. AUDIT_RESPONSE already notes that a nonzero queue time is not proof of validity.

     Fix options: document that pending status is readyAt(hash) != 0 && !executionNonces(projectId, nonce), or add an overload cancelApproval(bytes32 id, uint256 nonce, bytes32 hash) that also deletes readyAt[hash] (ApprovalQueued already exposes hash and nonce together).

     whole finding

     Project registered with minDelay 1h; Claus signs approval A (nonce 1). queue(A, sig) -> readyAt(hash) == T0 + 1h.

     Owner calls cancelApproval(ID, 1).

     Expected: readyAt(hash) == 0 or another cancelled signal.

     Actual: readyAt(hash) still == T0 + 1h and executionNonces(ID, 1) == true; at T0+1h execute(A, 'second', sig) reverts AlreadyExecuted.

     Reproduced in test/scratch/JudgeProbe.t.sol::JudgeExecutorProbe.testReadyAtStaleAfterCancel.

   • infoConstructor does not enforce the documented separation between clausSigner and recoveryOwnersrc/ClausApprovalExecutor.sol:101

     AUDIT_RESPONSE states that production deployment uses distinct signer and recovery addresses and relies on that separation so a compromised signing key cannot also schedule its own recovery, cancel recovery, or bump clausGeneration at will. The constructor accepts signer == recovery, so the separation is a deployment-procedure promise rather than a contract invariant.

     If the two roles were ever deployed as the same key or the same ERC-1271 wallet, a signer compromise becomes a full compromise of the recovery path (the attacker can scheduleSignerRecovery to its own key, and project owners' only defence is setAuthority(id, m, false) within recoveryDelay). This was accepted procedurally in the v3 review and is recorded so the gap stays visible for the deployer.

     Minimal fix that does not change the ownership model: add signer == recovery to the constructor's revert condition.

     new ClausApprovalExecutor(X, X, 1 days) for any nonzero X.

     Expected under the documented policy: revert InvalidRecovery.

     Actual: deployment succeeds with clausSigner() == recoveryOwner() == X.

     Reproduced in test/scratch/JudgeProbe.t.sol::JudgeExecutorProbe.testConstructorAllowsSameSignerAndRecovery.

7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,189,467 · transaction#1457#573#1559#158agent 52230