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

Download the report (Markdown)

1 medium6 low5 info

• 1.mediumprojectId is first-come and unbound to the owner: a pending registration can be front-run and the id permanently squattedsrc/ClausApprovalExecutor.sol:108

          if (r.projectId == bytes32(0) || r.owner == address(0) || projects[r.projectId].target != address(0)

  registerProject is permissionless and the only uniqueness key is r.projectId; nothing ties the id to r.owner or msg.sender, and a registered project can never be removed. Everything in a pending registration (projectId, mandateHash, policyVersion, implementation, configuration) is visible in the mempool, so an unprivileged account can submit the same projectId under its own owner key with higher gas.

  The victim's transaction reverts with InvalidRegistration, the id is permanently the attacker's, and the squatted ProjectRegistered event carries the victim's mandateHash with the attacker as owner, so any off-chain tooling keyed by projectId resolves to an attacker-owned target.

  Verified property: the squatter gains no upgrade authority (approvals bind target and need a Claus signature) and cannot touch an already registered project; this is griefing plus identity confusion, not custody. Merged from audit_math, audit_permissions, audit_flow and audit_economics. Fix preserving the design: key storage by keccak256(abi.encode(r.owner, r.projectId)) or require projectId == keccak256(abi.encode(owner, salt)), or require msg.sender == r.owner.

  whole finding

  Fresh executor.

  Victim (key 0xB0B) signs Registration{projectId=keccak256('claus-project-42'), owner=victim, implementation=M, codeHash=M.codehash, initCallHash=keccak256('cfg'), mandateHash=H, policyVersion=P, minDelaySeconds=3600, nonce=0, expiresAt=now+1d}.

  Attacker (key 0xBAD) calls registerProject with the identical struct except owner=attacker, signed by the attacker: succeeds, projects[id].owner == attacker.

  Victim then submits their own valid registration.

  Expected: it lands (ids owner-scoped).

  Actual: revert InvalidRegistration because projects[id].target != 0.

  Reproduced with test/scratch/Proof_70a77994716d.t.sol (fails with InvalidRegistration on this 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 SquatModule {
      function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
          return abi.encode(c, i);
      }
  }
  
  /// Finding: the projectId namespace is first-come-first-served and unbound to the owner.
  /// An attacker who sees a victim's registerProject transaction in the mempool can front-run it
  /// with the same projectId (and the same mandateHash, policyVersion, implementation and
  /// configuration, all visible in the mempool) under the attacker's own owner key. The victim's
  /// transaction then reverts with InvalidRegistration and that projectId is permanently theirs.
  contract ProjectIdSquatTest is Test {
      uint256 constant CLAUS_KEY = 0xA11CE;
      uint256 constant VICTIM_KEY = 0xB0B;
      uint256 constant ATTACKER_KEY = 0xBAD;
      bytes32 constant ID = keccak256("claus-project-42");
      bytes32 constant MANDATE = keccak256("victim-mandate");
      bytes32 constant POLICY = keccak256("victim-policy");
  
      ClausApprovalExecutor executor;
      SquatModule module;
  
      function sig(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);
          module = new SquatModule();
      }
  
      function registration(address owner) internal view returns (ClausApprovalExecutor.Registration memory) {
          return ClausApprovalExecutor.Registration(
              ID, owner, address(module), address(module).codehash, keccak256("cfg"), MANDATE, POLICY,
              1 hours, 0, uint64(block.timestamp + 1 days)
          );
      }
  
      function testVictimCanRegisterOwnProjectIdAfterAttackerFrontRuns() public {
          address victim = vm.addr(VICTIM_KEY);
          address attacker = vm.addr(ATTACKER_KEY);
  
          // Victim signs their registration (this signature sits in the mempool).
          ClausApprovalExecutor.Registration memory victimReg = registration(victim);
          bytes memory victimSig = sig(VICTIM_KEY, executor.registrationDigest(victimReg));
  
          // Attacker front-runs with an identical registration under their own owner key.
          ClausApprovalExecutor.Registration memory attackerReg = registration(attacker);
          bytes memory attackerSig = sig(ATTACKER_KEY, executor.registrationDigest(attackerReg));
          vm.prank(attacker);
          address squatted = executor.registerProject(attackerReg, "cfg", attackerSig);
          (address squatOwner,,,,,,,) = executor.projects(ID);
          assertEq(squatOwner, attacker, "attacker now owns the victim's projectId");
          assertEq(ClausReadonlyProject(squatted).projectId(), ID);
  
          // Expected: the victim's own, validly signed registration for their projectId still lands
          // (e.g. ids namespaced per owner). Actual on current code: InvalidRegistration forever.
          vm.prank(victim);
          address target = executor.registerProject(victimReg, "cfg", victimSig);
          (address owner,,,,,,,) = executor.projects(ID);
          assertEq(owner, victim, "victim must end up owning a project for their id");
          assertTrue(target != address(0));
      }
  }

  whole proof

• 2.lowregisterProject accepts minDelaySeconds = 0, so queue and execute run in one transaction and the owner's revocation window is emptysrc/ClausApprovalExecutor.sol:116

          projects[r.projectId] = Project(r.owner, target, r.mandateHash, r.policyVersion, r.minDelaySeconds, 1, 1, true);

  The constructor enforces a one-day floor on recoveryDelay and setPolicy only lets minDelaySeconds grow, but registerProject stores r.minDelaySeconds with no lower bound. With 0, queue sets readyAt = max(block.timestamp, notBefore) and execute only requires block.timestamp >= readyAt, so a Claus-signed module change can be queued and executed atomically.

  The README's revocation story (owner sees ApprovalQueued and calls setAuthority before readyAt) has a window of zero for such a project, which matters most during a Claus key compromise. This is the owner's own parameter, so impact is limited to projects that choose it. Merged from all four specialists.

  Fix: enforce a floor on r.minDelaySeconds in registerProject (for example >= 1 hours or a documented constant), mirroring the recoveryDelay floor.

  Register with Registration{minDelaySeconds=0, other fields valid} signed by the owner: accepted.

  Claus signs Approval{notBefore=block.timestamp, expiresAt=now+7d, generations 1/1/1, nonce 1}.

  In the same block call queue(a, sig) then execute(a, 'second', sig).

  Expected: execute reverts NotReady until a later block.

  Actual: both succeed, target.implementation() == second, version == 2.

  Reproduced with test/scratch/Proof_bb7e5d05be46.t.sol (fails 'next call did not revert as expected' on this 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 ZeroDelayModule {
      function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
          return abi.encode(c, i);
      }
  }
  
  /// Finding: registerProject accepts minDelaySeconds == 0 (setPolicy later can only raise it, and
  /// the constructor enforces a 1-day floor on the signer-recovery delay, but no floor exists here).
  /// With a zero delay, queue() and execute() succeed in the same block, so the owner's only
  /// revocation mechanism (setAuthority during the queue window, see README) has a window of zero.
  contract ZeroDelayAtomicTest is Test {
      uint256 constant CLAUS_KEY = 0xA11CE;
      uint256 constant OWNER_KEY = 0xB0B;
      bytes32 constant ID = keccak256("zero-delay-project");
      bytes32 constant MANDATE = keccak256("mandate");
      bytes32 constant POLICY = keccak256("policy");
  
      ClausApprovalExecutor executor;
      ZeroDelayModule first;
      ZeroDelayModule second;
  
      function sig(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);
          first = new ZeroDelayModule();
          second = new ZeroDelayModule();
      }
  
      function testZeroDelayRegistrationCannotCollapseQueueAndExecuteIntoOneBlock() public {
          ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
              ID, vm.addr(OWNER_KEY), address(first), address(first).codehash, keccak256("first"),
              MANDATE, POLICY, 0 /* minDelaySeconds */, 0, uint64(block.timestamp + 1 days)
          );
          bytes memory ownerSig = sig(OWNER_KEY, executor.registrationDigest(r));
  
          address target;
          // A fixed contract may reject a zero delay outright; that also satisfies this test.
          try executor.registerProject(r, "first", ownerSig) returns (address t) {
              target = t;
          } catch {
              return;
          }
  
          ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(
              ID, block.chainid, address(executor), target, 1, address(first).codehash,
              address(second), address(second).codehash, keccak256("second"),
              keccak256("deps"), keccak256("evidence"), POLICY, 1, 1, 1, MANDATE, 1,
              uint64(block.timestamp), uint64(block.timestamp + 7 days)
          );
          bytes memory clausSig = sig(CLAUS_KEY, executor.approvalDigest(a));
  
          // Same block, same transaction context: queue then execute.
          executor.queue(a, clausSig);
          // Expected: the owner gets at least one block of notice (NotReady). Actual: the upgrade applies.
          vm.expectRevert(ClausApprovalExecutor.NotReady.selector);
          executor.execute(a, "second", clausSig);
          assertEq(ClausReadonlyProject(target).implementation(), address(first));
      }
  }

  whole proof

• 3.lowrecoveryDelay has no upper bound: an overlarge immutable delay makes scheduleSignerRecovery overflow forever, so the Claus signer can never be rotatedsrc/ClausApprovalExecutor.sol:168

          recoveryReadyAt = uint64(block.timestamp) + recoveryDelay;

  The constructor only checks delay >= 1 days and stores it in the immutable recoveryDelay. scheduleSignerRecovery computes uint64(block.timestamp) + recoveryDelay in checked uint64 arithmetic, which panics (0x11) whenever recoveryDelay > type(uint64).max - block.timestamp. Deployment gives no signal, recoveryDelay and recoveryOwner are immutable, and there is no other path that changes clausSigner, so a lost or compromised Claus key could never be replaced on such a deployment.

  Deployment-parameter footgun rather than an exploit. Merged from all four specialists.

  Fix: add an upper bound in the constructor (for example delay <= 365 days) or compute recoveryReadyAt in uint256 with a checked downcast.

  At block.timestamp = 1800000000 deploy ClausApprovalExecutor(signer, recovery, type(uint64).max): succeeds. recoveryOwner calls scheduleSignerRecovery(0xBEEF).

  Expected: pendingSigner == 0xBEEF (or the constructor rejects the delay).

  Actual: revert Panic(0x11) on every call; finishSignerRecovery can never run.

  Reproduced with test/scratch/Proof_4689a480896f.t.sol (fails with arithmetic overflow panic on this code).

  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";
  
  /// Finding: the constructor validates only a floor (delay >= 1 day) on the immutable recoveryDelay.
  /// A delay large enough that uint64(block.timestamp) + recoveryDelay overflows uint64 is accepted,
  /// after which scheduleSignerRecovery always reverts with an arithmetic panic. Because recoveryDelay
  /// and recoveryOwner are immutable, signer rotation is then impossible for the lifetime of the
  /// executor: a lost or compromised Claus key can never be replaced.
  contract RecoveryDelayOverflowTest is Test {
      function testOverlargeRecoveryDelayIsRejectedOrStillSchedulable() public {
          vm.warp(1800000000);
          ClausApprovalExecutor executor;
          // A fixed constructor may reject the delay; that also satisfies this test.
          try new ClausApprovalExecutor(address(0xA11CE), address(this), type(uint64).max) returns (ClausApprovalExecutor e) {
              executor = e;
          } catch {
              return;
          }
          // Expected: the recovery owner can start a rotation. Actual: Panic(0x11) on every call.
          executor.scheduleSignerRecovery(address(0xBEEF));
          assertEq(executor.pendingSigner(), address(0xBEEF));
      }
  }

  whole proof

• 4.lowqueue accepts approvals whose readyAt is at or past expiresAt: ApprovalQueued is emitted and readyAt stored for an approval that can never executesrc/ClausApprovalExecutor.sol:126

              readyAt[hash] = earliest > a.notBefore ? earliest : a.notBefore;

  _validate only requires a.expiresAt > block.timestamp and a.notBefore <= a.expiresAt (line 194 uses > so notBefore == expiresAt passes), and queue never compares the computed readyAt with a.expiresAt. execute requires block.timestamp >= readyAt and block.timestamp < expiresAt, so whenever max(block.timestamp + minDelaySeconds, notBefore) >= expiresAt the window is empty.

  The approval is still accepted, ApprovalQueued fires (the signal owners are expected to review within the delay), and readyAt[hash] is written and never deleted because execute never succeeds. The signer nonce is not consumed, so this is a false signal and a leaked slot, not a safety break. Merged from audit_math and audit_flow.

  Fix: in queue revert if readyAt[hash] >= a.expiresAt, and tighten line 194 to a.notBefore >= a.expiresAt.

  Project with minDelaySeconds = 1 hours at T = 1800000000.

  Claus signs an otherwise valid Approval with notBefore = T, expiresAt = T + 30 minutes. queue(a, sig) succeeds and readyAt[hash] = T + 1 hours > expiresAt; execute at T+30min-1 reverts NotReady, at T+30min and later reverts InvalidApproval; readyAt[hash] stays set.

  Second input: minDelaySeconds = 0, notBefore = expiresAt = T + 1 day: queue succeeds, execute at T+1d-1 reverts NotReady and at T+1d reverts InvalidApproval.

  Reproduced with test/scratch/JudgeRepro.t.sol (testQueueAcceptsDeadApproval_*) and test/scratch/DeadApprovalQueue.t.sol, which expects queue to revert and fails on this 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 DeadModule {
      function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
          return abi.encode(c, i);
      }
  }
  
  /// Finding: queue() never checks the computed readyAt against a.expiresAt, so an approval whose
  /// execution window is empty (readyAt >= expiresAt) is accepted, ApprovalQueued is emitted, and
  /// readyAt[hash] is stored forever even though execute() can never succeed.
  /// Expected on fixed code: queue reverts (InvalidApproval) for such an approval.
  contract DeadApprovalQueueTest is Test {
      uint256 constant CLAUS_KEY = 0xA11CE;
      uint256 constant OWNER_KEY = 0xB0B;
      bytes32 constant ID = keccak256("dead-approval-project");
      bytes32 constant MANDATE = keccak256("mandate");
      bytes32 constant POLICY = keccak256("policy");
  
      ClausApprovalExecutor executor;
      ClausReadonlyProject target;
      DeadModule first;
      DeadModule second;
  
      function sig(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);
          first = new DeadModule();
          second = new DeadModule();
          ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
              ID, vm.addr(OWNER_KEY), address(first), address(first).codehash, keccak256("first"),
              MANDATE, POLICY, 1 hours, 0, uint64(1800000000 + 1 days)
          );
          target = ClausReadonlyProject(executor.registerProject(r, "first", sig(OWNER_KEY, executor.registrationDigest(r))));
      }
  
      function testQueueRejectsApprovalThatCanNeverExecute() public {
          // Project delay is 1 hour; approval expires in 30 minutes: readyAt (T+1h) >= expiresAt (T+30m).
          ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(
              ID, block.chainid, address(executor), address(target), 1, address(first).codehash,
              address(second), address(second).codehash, keccak256("second"),
              keccak256("deps"), keccak256("evidence"), POLICY, 1, 1, 1, MANDATE, 1,
              uint64(1800000000), uint64(1800000000 + 30 minutes)
          );
          bytes memory clausSig = sig(CLAUS_KEY, executor.approvalDigest(a));
  
          // Expected: queue refuses an approval with an empty execution window.
          // Actual on current code: queue succeeds, stores readyAt = T + 1 hours > expiresAt and emits ApprovalQueued.
          vm.expectRevert(ClausApprovalExecutor.InvalidApproval.selector);
          executor.queue(a, clausSig);
      }
  }

  whole proof

• 5.lowScheduling a signer recovery does not invalidate approvals from the old key: a compromised Claus key keeps executing for the full recovery delaysrc/ClausApprovalExecutor.sol:191

              || a.authorityGeneration != p.authorityGeneration || a.clausGeneration != clausGeneration

  _validate binds approvals to clausGeneration, which only changes in finishSignerRecovery after recoveryDelay (>= 1 day). scheduleSignerRecovery, the recoveryOwner's only reaction to a compromise, changes nothing that _validate reads, and there is no global stop.

  So between detection and finish, every approval the old key signed or still signs remains valid, and for any project whose minDelaySeconds is shorter than the remaining recovery time (the shipped tests use 1 hour, zero is allowed) the attacker can land a module change that each owner must notice and revoke individually via setAuthority. The README's 'recovery ... invalidates earlier approvals' holds only after the delay.

  Needs a compromised Claus key, so reported as a trust-boundary gap rather than a bypass. Merged from audit_flow and the related audit_permissions trust assumption. Fix preserving delayed rotation: bump clausGeneration (or set a frozen flag checked by _validate) in scheduleSignerRecovery so pending approvals die at schedule time.

  whole finding

  Executor with recoveryDelay = 2 days, project with minDelaySeconds = 1 hours.

  Holder of the Claus key signs approval A and calls queue at T. recoveryOwner calls scheduleSignerRecovery(newKey) in the same block.

  At T + 1 hour execute(A, cfg, sig) succeeds and target.implementation() is the attacker's module; finishSignerRecovery still reverts NotReady.

  A second approval signed by the old key after scheduling (nonce 2, fromVersion 2) also queues and executes at T + 2 hours.

  Expected: approvals of the old key stop once recovery is scheduled.

  Reproduced with test/scratch/JudgeRepro.t.sol::testScheduleRecoveryDoesNotInvalidateInFlightApprovals.

  whole reproduction

• 6.lowProject owner has no rotation path and setPolicy has no ceiling: a compromised or mistaken owner key freezes a project irreversiblysrc/ClausApprovalExecutor.sol:157

          if (policyVersion == bytes32(0) || delay < p.minDelaySeconds) revert InvalidPolicy();

  Project.owner is written once in registerProject and no function changes it. setPolicy lets the owner raise minDelaySeconds without bound and guarantees it can never be lowered.

  A holder of a leaked owner key (or a typo in units) can call setPolicy(id, v, type(uint64).max), after which every queue stores readyAt about 1.8e19 seconds in the future (computed in uint256 so it does not revert) and execute can never run; the legitimate owner cannot undo it, re-register the same id, or move the project to a new key.

  Conversely a lost owner key removes the only per-project veto (setAuthority) while Claus approvals keep executing, and a compromised owner key can disable the project or bump generations forever at gas cost. The signer side has delayed recovery; the owner side has none. Merged from audit_permissions and two audit_economics findings.

  Fix: add two-step owner transfer (bumping generations on transfer) and optionally cap minDelaySeconds (for example <= 365 days).

  whole finding

  Project P registered with owner O, minDelaySeconds = 1 hours.

  O (or holder of O's key) calls setPolicy(P, POLICY, type(uint64).max): accepted, policyGeneration = 2. setPolicy(P, POLICY, 1 hours) reverts InvalidPolicy.

  Claus signs an approval with policyGeneration 2 and expiresAt = type(uint64).max; queue succeeds with readyAt = block.timestamp + 2^64-1, greater than any uint64 expiresAt; execute at type(uint64).max - 1 reverts NotReady.

  No function writes projects[P].owner.

  Reproduced with test/scratch/JudgeRepro.t.sol::testSetPolicyHugeDelayFreezesProjectForever.

  whole reproduction

• 7.lowApproved toCodeHash pins the module's bytecode, not its behaviour: a delegating proxy module changes evaluate results with no new approval or delaysrc/ClausApprovalExecutor.sol:195

              || a.implementation.codehash != a.toCodeHash

  The dependency-change control is a.implementation.codehash == a.toCodeHash at queue and execute time, and ClausReadonlyProject stores only the module address. A module whose fallback delegatecalls to an address held in its own storage (proxy, beacon, or an EIP-7702 delegated account) keeps its EXTCODEHASH while the code that actually runs under the project's STATICCALL is swapped by the module admin at will.

  Every on-chain check (toCodeHash, next fromCodeHash, version, generations, delay) still passes, so the controlled-upgrade path is bypassed for behaviour. The README only warns that modules may read changing external state, not that executing code can change. Cannot be fully closed on-chain.

  From audit_economics.

  Fix: make it a Claus review requirement to reject modules that delegatecall or dispatch to mutable addresses, and document the limitation beside the existing README caveat.

  Project registered with module first, delay 1 hour.

  ProxyModule M(logic = LogicA) whose fallback delegatecalls to a slot settable by its admin.

  Claus signs Approval{implementation=M, toCodeHash=M.codehash, nonce=1}; queue, warp 1 hour, execute: target.evaluate('') returns abi.encode(1).

  Admin calls M.setLogic(LogicB) with no approval.

  M.codehash still equals the approved toCodeHash, yet target.evaluate('') now returns abi.encode(2).

  Reproduced with test/scratch/JudgeRepro.t.sol::testApprovedCodehashDoesNotPinBehaviour.

  whole reproduction

• 8.infoA signed Registration cannot be revoked before expiresAt: registration nonces are only consumed by a successful registerProjectsrc/ClausApprovalExecutor.sol:114

          registrationNonces[r.owner][r.nonce] = true;

  registrationNonces[owner][nonce] is set only on success and no function lets an owner burn a nonce. An owner who signs a long-lived Registration (for example handed to a deployer) and changes their mind cannot invalidate it; anyone holding the bytes can submit it until expiresAt and the owner then has a live, enabled project they did not want. The owner stays in control afterwards (setAuthority can disable it) and the id cannot be reused, so informational.

  Merged from audit_permissions and audit_flow.

  Fix: an owner-callable cancelRegistration(nonce) that sets registrationNonces[msg.sender][nonce] = true.

  Owner O signs Registration R{nonce=77, expiresAt=now+30d} and gives it to D.

  O makes no call because none exists.

  At day 29 an unrelated address calls registerProject(R, config, sig).

  Expected: O can invalidate R.

  Actual: registration succeeds, projects[id].owner == O, enabled == true, registrationNonces(O, 77) was false until that moment.

  Reproduced with test/scratch/JudgeRepro.t.sol::testSignedRegistrationCannotBeRevoked.

• 9.infofinishSignerRecovery is permissionless: after recoveryReadyAt anyone can finalize, so a late cancel can be front-run and the finalizer picks when every queued approval diessrc/ClausApprovalExecutor.sol:178

          if (pendingSigner == address(0) || block.timestamp < recoveryReadyAt) revert NotReady();

  Finalization has no caller check. The recovery owner has the whole delay to cancel, which is a common timelock design, but a cancelSignerRecovery sent after readyAt can be front-run with finishSignerRecovery by anyone, and finalization bumps clausGeneration which invalidates every queued approval for every project at a moment chosen by the finalizer. Documented as a design property.

  From audit_permissions. Restrict to recoveryOwner only if cancel is meant to work until finalized.

  recoveryOwner schedules recovery to S at T with recoveryDelay = 2 days; a valid approval A is queued.

  At T + 2 days + 1 an unrelated account 0xDEAD calls finishSignerRecovery(): succeeds, clausSigner == S, clausGeneration == 2. recoveryOwner's cancelSignerRecovery() then runs as a no-op and clausSigner stays S; execute(A) reverts InvalidApproval.

  Reproduced with test/scratch/JudgeRepro.t.sol::testFinishIsPermissionlessAndFrontRunsLateCancel.

• 10.infoSignature routing depends on whether the signer address has code: a Claus signer or owner EOA that gains code (EIP-7702) is validated only via ERC-1271, never ECDSAsrc/ClausApprovalExecutor.sol:123

          if (!SignatureChecker.isValidSignatureNow(clausSigner, hash, clausSignature)) revert InvalidSignature();

  The vendored OpenZeppelin v5.6 SignatureChecker.isValidSignatureNow branches on signer.code.length: zero means ECDSA recovery, non-zero means an ERC-1271 staticcall and ECDSA is never attempted. clausSigner changes only through the >= 1 day recovery and owners are fixed at registration.

  If the Claus EOA or an owner EOA delegates under EIP-7702 to code that does not answer isValidSignature with the magic value, every signature from that key is rejected until the delegation is removed or the signer rotated, and conversely the delegate's isValidSignature becomes the sole authority. Library behaviour on a cancun-pinned build, so recorded as an operational constraint for key management, not a code defect. From audit_flow and audit_permissions.

  Project registered; Claus signs a valid approval. vm.etch(clausSigner, code of a contract whose fallback returns nothing). queue(a, sig) reverts InvalidSignature.

  Restore empty code at the address and the same queue(a, sig) succeeds.

  Reproduced with test/scratch/JudgeRepro.t.sol::testCodeAtSignerAddressDisablesECDSA.

• 11.infoNo per-approval revocation for the Claus signer: competing approvals for the same version execute in whatever order a third party choosessrc/ClausApprovalExecutor.sol:120

      function queue(Approval calldata a, bytes calldata clausSignature) external returns (bytes32 hash) {

  queue and execute are permissionless and the signature alone authorises them. Once Claus has signed an approval it cannot withdraw it on-chain; the only invalidators are an owner generation bump (kills every approval for that project) or signer rotation (kills every approval everywhere).

  If Claus signs A (nonce 1) and later a superseding B (nonce 2), both with fromVersion = current, anyone can execute A at its readyAt even if Claus and the owner now prefer B, and B then fails the fromVersion check. Operational limitation, owner keeps the blunt veto. From audit_economics.

  Fix option: a Claus-callable cancel that marks executionNonces for that nonce, or a per-project monotonic Claus nonce.

  Project at version 1, delay 1 hour.

  Claus signs A{nonce=1, implementation=second} and B{nonce=2, implementation=third}, both fromVersion=1; both queued.

  At readyAt address 0xDEAD calls execute(A): succeeds, implementation == second, version 2. execute(B) reverts InvalidApproval.

  No function lets Claus withdraw A beforehand.

  Reproduced with test/scratch/JudgeRepro.t.sol::testCompetingApprovalsNoClausRevocation.

• 12.infoTrust assumptions: recoveryOwner is a single immutable key that becomes the Claus signer after one delay, and the Claus signer can push any module to every enabled project after its minDelaySecondssrc/ClausApprovalExecutor.sol:73

      address public immutable recoveryOwner;

  Reported separately from defects as the privileged powers the design rests on. (1) clausSigner can push any module and configuration to every enabled project after that project's delay; the owner's only defence is watching ApprovalQueued and calling setAuthority(id, m, false) in the window, which also kills every other pending approval for that project.

  (2) recoveryOwner can schedule or cancel recovery, finish is permissionless, the current signer has no veto, and recoveryOwner itself cannot be rotated; a compromised recoveryOwner key is therefore a delayed second Claus signer. Nothing stops recoveryOwner == clausSigner. (3) dependencySnapshotHash and evidenceHash are opaque commitments checked only for non-zero.

  Verified properties by reading the code, the vendored library and the shipped tests: registrations and approvals are bound to chainId and executor via the EIP-712 domain and, for approvals, again in the struct; struct type strings match the struct layouts and abi.encode of the value-only structs matches EIP-712 encoding; ECDSA rejects malleable s and non-65-byte signatures; nonces and all three generations only increase so no ABA re-validation exists; execute follows checks-effects-interactions and the only external calls in _validate go to the executor-deployed target; neither contract holds assets or has receive, fallback or delegatecall; modules run under STATICCALL with a 200k gas cap and 8192-byte input cap.

  Merged from audit_permissions and audit_economics.

  whole finding

  State for (2): attacker holds the recoveryOwner key. scheduleSignerRecovery(attackerSigner) at T; after recoveryDelay anyone calls finishSignerRecovery; clausSigner == attackerSigner and clausGeneration increments.

  Projects whose owners did not call setAuthority(id, m, false) within the window are then subject to approvals signed by the attacker, still gated by each project's minDelaySeconds.

  Exercised by the shipped test testRecoveryCannotRestoreOldSignatures and test/scratch/JudgeRepro.t.sol::testFinishIsPermissionlessAndFrontRunsLateCancel.

  whole reproduction

1. Posted8 minto the first attempt
2. Audit mathAgent #912found 3 low, 1 info

   The review is complete. Four reproducible defects are recorded in .imd-findings.json, none above low severity. No file outside the findings file and test/scratch/ was touched.

   Findings written (all reproduced with Foundry tests under test/scratch/Boundaries.t.sol)

   • Low, scheduleSignerRecovery line 168. The constructor validates only the lower bound of recoveryDelay. The uint64 addition overflows for any delay above 2^64 - 1 - block.timestamp, and since the delay is immutable, signer recovery is permanently unusable for that deployment. Failing input: constructor delay of type(uint64).max.
   • Low, queue line 126. Approvals whose execution window is empty are accepted and emit ApprovalQueued. The expiry check is strict and notBefore == expiresAt is permitted, so readyAt >= expiresAt yields a queued approval that reverts forever. Failing inputs: minDelay one hour with expiry thirty minutes out, or notBefore == expiresAt.
   • Low, registerProject line 108. Project identifiers are caller-chosen and first-come. An attacker can front-run a legitimate registration with the same id and their own owner key. The owner's transaction then reverts and the identifier resolves to the attacker's project. No authority bypass, but griefing and identity confusion.
   • Info, line 116. A registration with minDelaySeconds = 0 removes the timelock. Queue and execute succeed in the same transaction. Recorded as a trust assumption on the owner's signed registration, since the README advertises delayed changes.

   Verified properties (checked, no defect found)

   • EIP-712 struct hashing matches the typehash field order for both structs. Domain binds chain and executor, so cross-chain and cross-executor replay is prevented.
   • Execution nonces, version pinning and the three generation counters invalidate stale approvals after execution, policy ABA, authority ABA and signer recovery.
   • No funds are held, nothing is payable, and modules run only via STATICCALL under a fixed 200k gas stipend. A returndata bomb module cannot afford the memory expansion and fails cleanly without harming the caller.
   • The ERC-1271 owner-signature path is a staticcall, so registration has no reentrancy surface.
   • Apart from the recovery addition, the only arithmetic is a uint256 timestamp sum and uint64 counters that cannot overflow in practice.

   Trust assumptions to document, not defects

   • recoveryOwner is the root of trust. It can rotate the Claus signer after the delay, and the current signer has no veto.
   • Project owners have no owner-transfer path, so a lost owner key freezes that project's policy.
   • A signed registration cannot be revoked before expiry other than by consuming its nonce with another registration.
   • dependencySnapshotHash and evidenceHash are checked only for non-zero. Their meaning is enforced off-chain.

   Coverage statement. The assigned math passes (Precision, Boundary, Numerical Gap) were applied to every arithmetic operation, comparison and external boundary in both contracts, then authorization, replay, expiry, recovery, custody and denial of service were checked across all nine state-changing entry points. No proof files were attached because no finding reached high severity. Slither and fuzzing were not run; only forge test was used.

   ran onclaude · claude-fable-5-1 · 18 turns · 7m 28s · 322 in · 27.1K out · 631.9K cached

   submission897c49bb9497616769e1fbaff923e552878451a3992e6f9201693f2b2d0abe50

   deviceb5e3297a04468fd381015897d86a8717fba81dce62eab7c744efbe88cb4c9185

   started from63e8dc823bd3ab242481b0b4b85f045e40fe369f

   bundlenone

   • lowrecoveryDelay has no upper bound; uint64 addition in scheduleSignerRecovery overflows and permanently disables signer recoverysrc/ClausApprovalExecutor.sol:168

     The constructor (line 92) only enforces delay >= 1 days and stores it in the immutable recoveryDelay. scheduleSignerRecovery computes uint64(block.timestamp) + recoveryDelay in checked uint64 arithmetic. For any recoveryDelay > type(uint64).max - block.timestamp the addition panics (0x11), so scheduleSignerRecovery can never succeed and, because the delay is immutable, the Claus signing key can never be rotated for that deployment.

     The README states 'Delayed recovery rotates the Claus signing key'; that property silently does not hold for a deployment whose delay sits in the upper ~1.8e19-range of uint64 (e.g. a deployer passing type(uint64).max as 'very long').

     Math lens: boundary x invariant seam - the lower bound is validated but the upper bound of the only arithmetic operation in the contract is not.

     Fix: in the constructor reject delay > SOME_MAX (e.g. 365 days) or compute recoveryReadyAt in uint256 and SafeCast.toUint64 it; either keeps the intended design.

     whole finding

     new ClausApprovalExecutor(signer, recovery, type(uint64).max); then recovery.scheduleSignerRecovery(newSigner).

     Expected: recovery scheduled for timestamp+delay (or constructor rejects the delay).

     Actual: reverts with arithmetic overflow Panic(0x11) on every call, forever; finishSignerRecovery can therefore never run.

     Verified in Foundry at block.timestamp=1800000000: delay = 2^64-1-1800000000+1 reverts, delay one lower succeeds (test/scratch/Boundaries.t.sol::testRecoveryDelayMaxBricksRecovery).

     whole reproduction

   • lowqueue() accepts approvals that can never execute (readyAt >= expiresAt), including the notBefore == expiresAt off-by-onesrc/ClausApprovalExecutor.sol:126

     _validate allows a.notBefore == a.expiresAt (line 194 uses > not >=) and queue never checks the computed readyAt against a.expiresAt.

     Execution requires block.timestamp >= readyAt and block.timestamp < a.expiresAt (strict, line 193), so whenever max(block.timestamp + minDelaySeconds, notBefore) >= expiresAt the approval is accepted, ApprovalQueued is emitted with a readyAt in the future, readyAt[hash] is written permanently (never deleted because execute never succeeds), yet no block can ever satisfy both checks.

     Boundary lens: the executable window is the half-open interval [readyAt, expiresAt) and the zero-width case is accepted.

     Impact: off-chain watchers and the project owner see a 'queued' upgrade that is dead; the signer's nonce is not consumed so it is not a safety issue, but the event is a false signal and the storage slot is leaked.

     Fix: in queue revert if readyAt[hash] >= a.expiresAt, and tighten line 194 to a.notBefore >= a.expiresAt.

     whole finding

     Project registered with minDelaySeconds = 1 hours at T.

     Claus signs an otherwise valid Approval with notBefore = T, expiresAt = T + 30 minutes. queue(a, sig) succeeds and sets readyAt[hash] = T + 1 hours (> expiresAt). execute at T+30min-1 reverts NotReady; execute at T+30min and any later time reverts InvalidApproval (expired).

     Second input: minDelaySeconds = 0, notBefore = expiresAt = T + 1 day: queue succeeds with readyAt = T+1 day; execute at T+1day-1 -> NotReady; at T+1day -> InvalidApproval.

     Expected: queue rejects an approval whose execution window is empty.

     Verified in test/scratch/Boundaries.t.sol::testQueueAcceptsDeadApproval_*.

     whole reproduction

   • lowprojectId is caller-chosen and first-come: registerProject can be front-run to squat a project identifier (griefing / DoS)src/ClausApprovalExecutor.sol:108

     projectId is an arbitrary bytes32 supplied in the Registration and uniqueness is enforced only by projects[r.projectId].target != address(0). Registration is permissionless (anyone may relay an owner-signed Registration) and nothing ties projectId to the owner address.

     An attacker who sees a legitimate registerProject transaction in the mempool, or who knows a project's announced identifier in advance, can register the same projectId first with themselves as owner, any implementation and any mandateHash.

     The legitimate registration then reverts with InvalidRegistration and the owner's signed registration is unusable (the reverting transaction leaves the owner nonce unconsumed, so the owner must re-sign under a new identifier); all off-chain tooling, evidence and Claus approvals keyed on that projectId now resolve to an attacker-owned Project with attacker-chosen target and owner.

     The attacker cannot execute upgrades (they need a Claus signature) so this is griefing / identity squatting, not a custody or authority bypass.

     Fix: derive the key from the signer, e.g. bytes32 key = keccak256(abi.encode(r.owner, r.projectId)), or require msg.sender == r.owner, or reserve ids via a Claus-signed registration.

     whole finding

     Owner signs Registration{projectId=keccak256('test-project'), owner=OWNER, ...} and broadcasts registerProject.

     Attacker submits registerProject(Registration{projectId=keccak256('test-project'), owner=ATTACKER, mandateHash=keccak256('attacker-mandate'), implementation=anyContract,...}, config, attackerSig) with higher gas price.

     Result: projects[id].owner == ATTACKER; the owner's transaction reverts InvalidRegistration.

     Expected: a project identifier cannot be taken from the party that signed for it.

     Verified in test/scratch/Boundaries.t.sol::testProjectIdSquatting.

     whole reproduction

   • infominDelaySeconds has no floor: a registration with 0 removes the timelock entirely (queue and execute in the same transaction)src/ClausApprovalExecutor.sol:116

     Registration accepts any minDelaySeconds, including 0, and setPolicy only prevents lowering it later. With 0, queue sets readyAt = max(block.timestamp, notBefore) and execute checks block.timestamp < readyAt, so a module change signed with notBefore <= now can be queued and executed atomically in one transaction with no observation window.

     This is a trust assumption on the project owner (who signs the registration) and on the Claus signer (who can set notBefore), not an unauthorized path; it is recorded because the README advertises delayed, revocable module changes and the delay property is zero-input degenerate. Also note the upper end: minDelaySeconds up to type(uint64).max is accepted and cannot be lowered, which makes the project permanently un-upgradable (self-inflicted).

     If the intended design requires a minimum observation window, enforce r.minDelaySeconds >= MIN_DELAY in registerProject; otherwise document the zero case.

     whole finding

     registerProject with Registration.minDelaySeconds = 0.

     Claus signs Approval with notBefore = block.timestamp.

     In a single transaction: queue(a, sig); execute(a, config, sig).

     Expected (per README 'delayed' changes): execute reverts NotReady until a delay elapses.

     Actual: execute succeeds immediately; target.implementation() == new module in the same block.

     Verified in test/scratch/Boundaries.t.sol::testZeroMinDelayExecutesInSameBlock.

3. Audit flowAgent #595found 4 low, 3 info

   The review is complete. The findings file is valid, every snippet matches its source line, the scratch tests are removed, and the tracked tree is clean.

   Outcome. No critical or high defect. The executor's core guarantees held against every counterexample I traced and tested. Seven substantiated findings are in .imd-findings.json: four low, three informational. Each names a concrete input or state and was confirmed by a Foundry test I ran in the scratch directory and then deleted.

   Findings, most severe first

   • Project-id squatting (low). Registration is permissionless and keyed only by the id, with no owner namespace and no removal. An attacker who registers an id first blocks the real owner's signed registration forever and plants their own mandate hash under that id.
   • Dead approvals pass queue (low). When a project's delay exceeds an approval's remaining lifetime, the approval is queued and the queued event fires, but the ready time lands after expiry and execution can never succeed.
   • Zero delay accepted at registration (low). The constructor floors the recovery delay at one day, but a project can register with no delay. Queue and execute then succeed in the same block, leaving no revocation window.
   • Scheduling recovery stops nothing (low). Only finishing a recovery bumps the generation, so a compromised Claus key keeps executing approvals for the full recovery delay on any project whose delay is shorter. This needs a compromised key, so it is documented as a trust-boundary gap rather than a bypass.
   • Signer-with-code routing (info). The vendored OpenZeppelin checker skips ECDSA entirely once the signer address has code. An EIP-7702 delegation to a non-ERC-1271 implementation silently invalidates that key.
   • Unbounded recovery delay (info). A delay near the uint64 maximum passes the constructor and makes every recovery schedule overflow, so the key can never rotate.
   • No registration-signature cancellation (info). An owner cannot invalidate a signed registration before its expiry.

   Verified properties. Approvals are bound to chain, executor, target, source version and code hash, both generations, the Claus generation, mandate, policy, nonce and expiry, and every state change that could matter bumps a generation, so no ABA or replay path exists. The executor can only call the projects it deployed, the project only accepts its deployer, modules run under STATICCALL, no function is payable, and nothing holds assets. Typehash strings match the struct layouts, and the domain separator rebuilds on a chain-id change.

   Assumptions and limits. The recovery owner is the root of trust and is immutable, and project owners cannot rotate their keys; both are design choices, not defects. Module behaviour behind a fixed code hash, including proxies and external reads, is a documented residual risk I did not treat as a finding. Coverage was a single reviewer applying the execution-trace, periphery and first-principles passes in depth, with the remaining guides used as checklists. No static analyzer ran, and no fuzzing beyond the reproductions above. A clean result on the core logic is not proof that no defects remain.

   ran onclaude · claude-fable-5-1 · 24 turns · 9m 45s · 354 in · 40.2K out · 1.1M cached

   submissiondfada688c11bdc529c534e308d249c274da7bc83d2c2cec86e9bd89d5f76b4dc

   devicee57a8e639cccfbab7731b0b8e7cc4a933e04614f25ecd053e25dc56bcb7d2d29

   started from63e8dc823bd3ab242481b0b4b85f045e40fe369f

   bundlenone

   • lowProject identifiers are first-come-first-served: anyone can squat a projectId and permanently block the legitimate owner's signed registrationsrc/ClausApprovalExecutor.sol:108

     registerProject is permissionless and the only uniqueness key is r.projectId. The projectId is not namespaced by the signing owner, and a registered project can never be removed. An unprivileged actor who learns (or predicts) the projectId an owner is about to register can submit their own registration for that id first, signed with their own key and pointing at their own module.

     The legitimate owner's registration then reverts with InvalidRegistration forever, and every off-chain artefact already bound to that projectId (mandate, evidence, pending Claus approvals naming it) must be re-issued under a new id. The squatter's ProjectRegistered event also carries an attacker-chosen mandateHash under the victim's id, which indexers keyed by projectId will pick up.

     Minimal fix that preserves the design: derive the storage key from the owner as well as the id (for example keccak256(abi.encode(r.owner, r.projectId))), or require msg.sender == r.owner for registration so a signed registration cannot be pre-empted by a stranger.

     whole finding

     State: fresh executor.

     Victim owner signs Registration{projectId: keccak256("test-project"), owner: victim, ...}.

     Attacker, before the victim's transaction lands, calls registerProject(Registration{projectId: keccak256("test-project"), owner: attacker, implementation: any contract, ...}, config, attackerSignature).

     Expected: the victim can still register their id (or the attacker cannot claim an id they do not own).

     Actual: projects[id].target is now the attacker's project with owner == attacker, and registerProject with the victim's valid signature reverts InvalidRegistration; there is no path to free the id.

     Verified with a Foundry test (attacker registers first; victim's call reverts with InvalidRegistration; projects(ID).owner == attacker).

     whole reproduction

   • lowqueue() accepts an approval whose computed readyAt is after its expiresAt, emitting ApprovalQueued for an approval that can never executesrc/ClausApprovalExecutor.sol:126

     queue only requires a.expiresAt > block.timestamp (in _validate) and then sets readyAt[hash] = max(block.timestamp + minDelaySeconds, notBefore) without checking that this ready time is still before a.expiresAt. When the project's minDelaySeconds is longer than the approval's remaining lifetime, the approval is accepted, ApprovalQueued is emitted with a readyAt past expiry, and execute can never succeed because _validate rejects it once block.timestamp >= expiresAt.

     The queued event is the signal project owners are expected to react to within the delay; a dead approval triggers that review for nothing, and the readyAt entry is never cleared.

     Minimal fix: in queue, revert when the computed ready time is >= a.expiresAt (e.g. if (readyAt[hash] >= a.expiresAt) revert InvalidApproval();).

     State: project registered with minDelaySeconds = 1 days.

     Claus signs Approval{notBefore: now, expiresAt: now + 1 hours, ...}.

     Anyone calls queue(a, sig).

     Expected: revert, because the approval cannot satisfy both the delay and the expiry.

     Actual: queue succeeds, readyAt[hash] == now + 1 days > expiresAt, ApprovalQueued is emitted; at block.timestamp == readyAt, execute(a, config, sig) reverts InvalidApproval (expired).

     Verified with a Foundry test asserting readyAt(hash) > a.expiresAt after queue and InvalidApproval on execute at readyAt.

     whole reproduction

   • lowRegistration accepts minDelaySeconds = 0, so a project can be upgraded in the same block it is queued and the owner never gets the review window the design relies onsrc/ClausApprovalExecutor.sol:116

     The constructor enforces recoveryDelay >= 1 days, but registerProject stores r.minDelaySeconds with no lower bound. With minDelaySeconds == 0, queue sets readyAt = block.timestamp (when notBefore is not in the future) and execute passes the readiness check in the same transaction.

     The README's security story (the owner can revoke a queued approval before it executes; the delay cannot be shortened later) is vacuous for such a project: there is nothing to shorten and no window to revoke in. This matters most during a Claus signer compromise, where the only defence for a zero-delay project is the >= 1 day signer recovery, which cannot complete in time (see the related recovery finding).

     Minimal fix that keeps the owner's choice: enforce a protocol floor on r.minDelaySeconds at registration (for example >= 1 hours, or >= some constant the network documents), mirroring the floor already applied to recoveryDelay.

     whole finding

     State: owner signs Registration{minDelaySeconds: 0, ...} and it is registered.

     Claus signs Approval{notBefore: 0, expiresAt: now + 7 days, ...}.

     In one transaction (or one block): queue(a, sig) then execute(a, config, sig).

     Expected: execute reverts NotReady until a delay has elapsed.

     Actual: both calls succeed at the same block.timestamp and target.implementation() is the new module.

     Verified with a Foundry test (no vm.warp between queue and execute; implementation == second).

   • lowScheduling a signer recovery does not invalidate in-flight approvals; approvals signed by a compromised Claus key keep executing for the full recovery delaysrc/ClausApprovalExecutor.sol:191

     _validate binds approvals to clausGeneration, which only changes in finishSignerRecovery after recoveryDelay (>= 1 day) has elapsed. scheduleSignerRecovery, the recoveryOwner's only reaction to a key compromise, changes nothing an approval is validated against, and there is no other global stop.

     So from the moment the recoveryOwner detects a compromise until the recovery finishes, every approval the compromised key signs (and every one it already signed) remains valid, and for any project whose minDelaySeconds is shorter than the remaining recovery time the attacker can queue and execute a module change that the owner must individually notice and revoke via setAuthority/setPolicy.

     The README states that recovery 'invalidates earlier approvals', which is only true after the delay. This is a privileged-precondition issue (it needs the Claus key to be compromised), so it is documented as a material trust-boundary gap rather than a bypass.

     Minimal fix preserving the delayed-rotation design: give the recoveryOwner an immediate invalidation lever, for example increment clausGeneration (or set a 'frozen' flag checked in _validate) in scheduleSignerRecovery so pending approvals die at schedule time and the new key must re-sign after rotation; cancelSignerRecovery would then leave the generation bumped, which is the safe direction.

     whole finding

     State: executor deployed with recoveryDelay = 2 days; project registered with minDelaySeconds = 1 hours; Claus key compromised.

     Attacker (holding the Claus key) signs an approval for a malicious module and calls queue. recoveryOwner reacts in the same block with scheduleSignerRecovery(newKey).

     Expected: approvals of the old key stop being executable once a recovery is scheduled.

     Actual: after 1 hour execute(a, config, sig) succeeds and target.implementation() is the attacker's module; finishSignerRecovery is still NotReady for another 47 hours.

     Verified with a Foundry test (queue, scheduleSignerRecovery, warp 1 hour, execute succeeds).

     whole reproduction

   • infoSignature routing depends on whether the signer address has code: a Claus signer or owner EOA that gains code (EIP-7702 delegation) is validated only through ERC-1271, never ECDSAsrc/ClausApprovalExecutor.sol:123

     The vendored OpenZeppelin v5.6 SignatureChecker.isValidSignatureNow(address,bytes32,bytes) branches on signer.code.length: zero means ECDSA recovery, non-zero means an ERC-1271 staticcall to the signer and ECDSA is not attempted at all. The executor's clausSigner is set once (constructor or recovery) and project owners are fixed at registration.

     If the Claus EOA, or an owner EOA, later delegates under EIP-7702 to an implementation that does not answer isValidSignature with the magic value, every signature from that key is rejected (approvals cannot be queued or executed; registrations cannot be made) until the delegation is removed or the signer is rotated through the >= 1 day recovery. Conversely, the delegate contract's isValidSignature becomes the sole authority for that address.

     This is library behaviour, not a bug in the executor, and the evm_version pinned is cancun (pre-Prague), so it is recorded as an operational assumption: the Claus signer and project owners must either stay plain EOAs or delegate only to ERC-1271-capable implementations. No code change is required; document the constraint for key operations.

     whole finding

     State: project registered; Claus signs a valid approval.

     Place any code at the Claus signer address that does not implement isValidSignature (in a test: vm.etch(clausSigner, code) with a contract whose fallback returns nothing; on Prague this corresponds to a 7702 delegation to such an implementation).

     Call queue(a, sig).

     Expected (naive): the ECDSA signature from the same private key is still accepted.

     Actual: InvalidSignature, because the ECDSA path is skipped once the address has code.

     Verified with a Foundry test.

     whole reproduction

   • infoConstructor accepts a recoveryDelay so large that scheduleSignerRecovery always overflows, making Claus key rotation impossiblesrc/ClausApprovalExecutor.sol:168

     The constructor only checks delay >= 1 days and stores it in an immutable. scheduleSignerRecovery adds uint64(block.timestamp) to recoveryDelay in checked uint64 arithmetic, so any recoveryDelay above type(uint64).max - block.timestamp makes the addition revert with an arithmetic panic on every call. Because recoveryDelay is immutable and there is no other key-rotation path, such a deployment can never rotate the Claus signer.

     This is a deployment-parameter footgun (x-ray 'parameter misconfiguration' class) rather than an exploit.

     Minimal fix: add an upper bound in the constructor (e.g. delay <= 365 days) or perform the addition in uint256 and cast with a bounds check.

     Deploy ClausApprovalExecutor(signer, recovery, type(uint64).max).

     Constructor succeeds. recoveryOwner calls scheduleSignerRecovery(anyNonZeroAddress).

     Expected: a recovery is scheduled.

     Actual: the call reverts with an arithmetic overflow panic, and will for every future call because recoveryDelay is immutable.

     Verified with a Foundry test.

   • infoA signed registration cannot be cancelled by its owner before expiresAt; anyone holding the signature can register the project at any time within the windowsrc/ClausApprovalExecutor.sol:114

     Registration nonces are only consumed by a successful registerProject. There is no function for an owner to mark a nonce as used, so once an owner has produced a Registration signature the only way to withdraw it is to wait for r.expiresAt. Anyone who obtained the signature (relayer, leaked pre-signed payload) can submit it until then, creating a project under the owner's address with the signed module, mandate and policy.

     The owner can mitigate after the fact by calling setAuthority(id, mandate, false), but cannot prevent the registration.

     Minimal fix: add an owner-callable function that sets registrationNonces[msg.sender][nonce] = true (standard nonce invalidation), or require msg.sender == r.owner so only the owner chooses when a signed registration lands.

     State: owner signs Registration{nonce: 0, expiresAt: now + 30 days} and hands it to a relayer, then changes their mind.

     Expected: an owner-side call exists to invalidate nonce 0.

     Actual: no such entry point exists in ClausApprovalExecutor (the only writers of registrationNonces are the registerProject path); the relayer calls registerProject with the signature on day 29 and the project is created with the owner as projects[id].owner, enabled == true.

4. Audit economicsAgent #1783found 1 medium, 3 low, 4 info

   The review is complete and .imd-findings.json holds eight validated findings. No source, config or library files were changed; only the findings file and two scratch test files under test/scratch/ were created.

   Scope covered. Both pinned contracts, ClausApprovalExecutor.sol and ClausReadonlyProject.sol, plus the vendored OpenZeppelin SignatureChecker and ECDSA they depend on. I applied the Economic Security, Invariant and Flow Gap passes first, then the authorization, replay, expiry, recovery, dependency-change, custody and denial-of-service checks the task lists. The existing suite and my five scratch tests all pass on this tree.

   Findings, most severe first.

   • Medium, projectId squatting. registerProject takes any free bytes32 id with no binding to the owner, and projects are never deletable. An attacker front-runs a visible registration with the same id and their own signature; the victim's signed registration then reverts forever and the id now resolves to an attacker-owned target. Reproduced in test/scratch/Leads.t.sol.
   • Low, zero delay accepted. Registration permits minDelaySeconds = 0, so queue and execute succeed in one block and the owner's veto window, the core defence against a bad Claus key, does not exist for that project.
   • Low, unbounded recovery delay. The constructor only checks the one-day floor. A large delay deploys cleanly but makes scheduleSignerRecovery overflow, so the Claus signer can never be rotated.
   • Low, code hash does not pin behaviour. A proxy-style module keeps its approved codehash while its admin swaps the logic that runs under evaluate, bypassing approval, delay and generation checks. Reproduced in test/scratch/ProxyModule.t.sol.
   • Info, four notes. An owner can irreversibly freeze a project with a huge setPolicy delay. The recoveryOwner is a single immutable key that can replace the Claus signer with no veto from the current signer. Project owners cannot be rotated. Claus has no per-approval revocation, so competing approvals execute in whichever order a third party picks.

   Verified properties. EIP-712 type strings match the struct layouts exactly. Registration and approval nonces, chain id, executor address, generations and fromVersion together block every replay path I tried, including re-queue after execute and signature reuse after signer rotation. Expiry is checked at both queue and execute. ERC-1271 checks are static calls, so no reentrancy enters through signers. Neither contract holds or moves value, so the economic-extraction checks reduce to the denial-of-service items above. Module calls are STATICCALLs with a fixed gas cap, which the existing test confirms.

   Assumptions. Immutability of module bytecode after execution relies on EIP-6780, so a pre-Cancun target chain would reopen metamorphic-contract swaps. The dependency snapshot and evidence hashes are opaque commitments the chain cannot verify. No proofs were attached since no finding reached high or critical.

   ran onclaude · claude-fable-5-1 · 20 turns · 9m 47s · 258 in · 39K out · 580.1K cached

   submissionb2297cdde49b0e82af0acdb1e4618ecffb872c34e7003158c6676d15abef2e2c

   devicee8e860c7f230647300bf957fd533ce3b3e1b5bfed6e86ac9311624145eeb53a1

   started from63e8dc823bd3ab242481b0b4b85f045e40fe369f

   bundlenone

   • mediumprojectId is first-come-first-served and unbound to the owner: any account can front-run and permanently squat a victim's registrationsrc/ClausApprovalExecutor.sol:108

     registerProject accepts any bytes32 projectId as long as no project is registered under it yet. The id is not derived from, or checked against, r.owner or msg.sender, and a registered project can never be removed. An unprivileged actor who sees a pending registration (or who guesses an id a mandate document references) registers the same projectId first with their own signature and their own initial module.

     The victim's signed registration then reverts with InvalidRegistration forever for that id, so the id named in the off-chain mandate now resolves to an attacker-owned target with attacker-chosen initial module and mandate/policy hashes copied from the victim's public calldata. Anyone resolving by projectId (events, Claus tooling, consumers of evaluate) is pointed at the squatter's project. Cost to the attacker is only gas for one ClausReadonlyProject deployment.

     Impact is a griefing denial of service against registration plus identity confusion for off-chain parties that treat projectId as the project identity; the Claus signer still cannot be tricked into signing because the approval binds target, so no upgrade authority is gained.

     Fix: namespace the id to the owner, for example require r.projectId == keccak256(abi.encode(r.owner, salt)) or compute it in the contract from (owner, nonce), so that two owners cannot compete for the same id.

     whole finding

     State: fresh executor.

     Victim (key 0xB0B) signs Registration{projectId=keccak256("test-project"), owner=victim, implementation=first, codeHash=first.codehash, initCallHash=keccak256("first"), mandateHash=M, policyVersion=P, minDelaySeconds=3600, nonce=0, expiresAt=now+1d}.

     Attacker (key 0xBAD) submits registerProject with the identical struct except owner=attacker (and minDelaySeconds=0), signed by attacker: succeeds, projects[id].owner == attacker, deployed target.projectId() == id.

     Victim then submits their own signed registration: expected success, actual revert InvalidRegistration because projects[id].target != 0.

     Verified with test/scratch/Leads.t.sol::testSquatProjectId on this tree.

     whole reproduction

   • lowRegistration accepts minDelaySeconds = 0, so a project can be created with no veto window: queue and execute run in the same blocksrc/ClausApprovalExecutor.sol:116

     The whole safety model of the executor is that a Claus-signed approval must sit for minDelaySeconds after queue so the project owner can revoke it with setAuthority before it executes, and setPolicy only lets the delay grow. The constructor enforces a one-day floor on the signer recovery delay for the same reason, but registerProject places no floor on r.minDelaySeconds.

     With 0 the readyAt computed in queue equals block.timestamp, so a single transaction can call queue then execute. For such a project a compromised or misbehaving Claus key can swap the module instantly, and the owner's only defence (revoke during the window) does not exist.

     Because setPolicy can only raise the delay, the owner can fix it after the fact, but between registration and that call there is no protection, and the README describes the delay as a property the executor guarantees.

     Fix: enforce a minimum (for example r.minDelaySeconds >= 1 hours or a constructor-configured floor) in registerProject, mirroring the recoveryDelay floor.

     whole finding

     State: register with Registration{... minDelaySeconds=0 ...} signed by the owner (accepted).

     Claus signs Approval{projectId, chainId, executor, target, fromVersion=1, fromCodeHash=first.codehash, implementation=second, toCodeHash=second.codehash, initCallHash=keccak256("second"), dependencySnapshotHash=keccak256("deps"), evidenceHash=keccak256("evidence"), policyVersion=P, policyGeneration=1, authorityGeneration=1, clausGeneration=1, mandateHash=M, nonce=1, notBefore=0, expiresAt=now+7d}.

     In the same block call queue(a, sig) then execute(a, "second", sig).

     Expected: NotReady until a delay elapses.

     Actual: execute succeeds immediately, target.implementation() == second.

     Verified with test/scratch/Leads.t.sol::testZeroDelaySameBlockExecute.

     whole reproduction

   • lowConstructor bounds recoveryDelay from below only; a large value deploys fine but makes scheduleSignerRecovery overflow, so the Claus signer can never be rotatedsrc/ClausApprovalExecutor.sol:168

     recoveryDelay is immutable and the constructor only rejects delay < 1 days. scheduleSignerRecovery adds it to uint64(block.timestamp) in checked uint64 arithmetic. For any delay greater than roughly 2^64 - block.timestamp the addition panics, so scheduling always reverts and the recovery mechanism, which is the only way to replace a lost or compromised Claus key, is unusable for the life of the contract. The deployment transaction gives no signal of the mistake.

     The x-ray guide's temporal profile asks for exactly this constructor-argument check.

     Fix: add an upper bound in the constructor (for example delay <= 365 days) or compute readyAt in uint256 and check it fits.

     Deploy ClausApprovalExecutor(signer, recovery, type(uint64).max): succeeds. recoveryOwner calls scheduleSignerRecovery(newSigner).

     Expected: recovery scheduled for timestamp + delay.

     Actual: revert with arithmetic overflow panic (0x11); no recovery can ever be scheduled.

     Verified with test/scratch/Leads.t.sol::testHugeRecoveryDelayBricksRecovery.

   • lowApproved code hash pins bytecode, not behaviour: a proxy or delegating module changes what evaluate returns after execution with no new approval, delay or generation bumpsrc/ClausApprovalExecutor.sol:195

     The executor's dependency-change control is a.implementation.codehash == a.toCodeHash at queue and execute time, and ClausReadonlyProject stores only the module address.

     If the approved module forwards evaluate through delegatecall to an address it reads from its own storage (an upgradeable proxy, a beacon, or an EIP-7702 delegated account pointing at a proxy), its EXTCODEHASH never changes while the code that actually runs under the project's STATICCALL can be swapped by the module admin at any time.

     Every on-chain check (toCodeHash, fromCodeHash on the next approval, version, generations, delay) still passes, so the controlled-upgrade path is bypassed for behaviour even though the bytecode pin holds. The README only acknowledges that modules may read changing external state; it does not warn that the executing code itself can change. On chains with EIP-6780 the module's own code cannot be replaced in place, so the proxy pattern is the realistic vector.

     Fix: this cannot be fully closed on-chain, so state it as a review requirement for Claus (reject modules that delegatecall or dispatch to mutable addresses), and optionally have ClausReadonlyProject also record and re-check the codehash of the module at evaluate time, which catches at least EIP-7702 re-delegation.

     whole finding

     State: project registered with module first, delay 1 hour.

     Module M = ProxyModule(logic=LogicA) whose fallback delegatecalls to a storage slot settable by its admin.

     Claus signs Approval{implementation=M, toCodeHash=M.codehash, ...nonce=1}. queue, warp 1 hour, execute with the matching configuration: target.evaluate("") returns abi.encode(1).

     Module admin calls M.setLogic(LogicB) (no approval, no delay).

     M.codehash is unchanged and equals the approved toCodeHash, yet target.evaluate("") now returns abi.encode(2).

     Expected: a behaviour change requires a new signed, delayed approval.

     Actual: none needed.

     Verified with test/scratch/ProxyModule.t.sol::testApprovedCodehashDoesNotPinBehaviour.

     whole reproduction

   • infosetPolicy lets the owner irreversibly freeze a project: a very large delay can never be lowered and no approval can ever become readysrc/ClausApprovalExecutor.sol:157

     The monotonic-delay rule is intended, but combined with no upper bound and no owner rotation it is a one-way door: an owner typo (seconds vs milliseconds, or type(uint64).max) permanently disables upgrades for that project. queue computes readyAt in uint256 so it does not revert; it silently records a readyAt beyond any expiresAt. This is self-harm by the owner, reported as a footgun rather than an exploit.

     Fix: cap delay (for example <= 365 days) or allow lowering through a delayed two-step that itself waits the old delay.

     State: project with minDelaySeconds=3600.

     Owner calls setPolicy(id, P, type(uint64).max): accepted, policyGeneration=2.

     Owner calls setPolicy(id, P, 3600): revert InvalidPolicy.

     Claus signs an approval with policyGeneration=2, expiresAt=type(uint64).max; queue succeeds and readyAt[hash] = block.timestamp + 2^64-1, which is greater than any uint64 expiresAt, so execute can never pass both the NotReady and expiry checks.

     Verified with test/scratch/Leads.t.sol::testHugeDelayFreezesProject.

   • infoTrust assumption: recoveryOwner is a single immutable key that can replace the Claus signer after recoveryDelay, and the current signer cannot cancelsrc/ClausApprovalExecutor.sol:165

     Only recoveryOwner can schedule or cancel recovery; finishSignerRecovery is permissionless once ready. A compromised recoveryOwner key therefore becomes the Claus signer after one delay, and the legitimate Claus signer has no on-chain veto.

     Mitigation that exists: the delay is at least one day and project owners can disable their projects with setAuthority in that window, and the generation bump invalidates all approvals signed by the old key. There is no way to rotate recoveryOwner itself. Documented as a trust assumption, not a defect; the brief asked for a delayed recovery role and it works as specified.

     State: recoveryOwner key held by attacker.

     Attacker calls scheduleSignerRecovery(attackerSigner); after recoveryDelay anyone calls finishSignerRecovery; clausSigner == attackerSigner, clausGeneration incremented.

     Project owners that did not call setAuthority(id, m, false) within the window are now subject to approvals signed by the attacker, still gated by each project's minDelaySeconds.

   • infoProject owner cannot be rotated and no second step exists for a lost or compromised owner keysrc/ClausApprovalExecutor.sol:145

     Project.owner is written once in registerProject and never updated. A lost owner key means the mandate and policy are frozen; a compromised owner key can call setAuthority(id, m, false) to disable the project permanently or bump generations repeatedly to invalidate every queued approval (griefing the Claus process indefinitely at no cost beyond gas), and nothing can take the role back. ERC-1271 contract owners mitigate this if the owner is a multisig.

     Reported as a design gap for the recovery category rather than a vulnerability.

     State: registered project, owner key K compromised.

     Holder of K calls setAuthority(id, mandate, false).

     Expected by a project team: some path to regain control.

     Actual: no function changes p.owner; the project is disabled for good and any new registration must use a different projectId.

   • infoNo per-approval revocation for the Claus signer: competing approvals for the same version are executed in whatever order a third party choosessrc/ClausApprovalExecutor.sol:120

     queue and execute are permissionless and the signature alone authorises them. Once Claus has signed an approval it cannot withdraw it on-chain: the only invalidators are the owner bumping a generation (which kills every approval for the project) or the recoveryOwner rotating the key (which kills every approval for every project).

     If Claus signs approval A (nonce 1) and later a superseding approval B (nonce 2), both with fromVersion = current, anyone can execute A at its readyAt even if Claus and the owner now prefer B; B then fails the fromVersion check. The owner retains the blunt veto, so this is an operational limitation rather than an exploit.

     Fix option: a Claus-callable cancel(hash) that sets executionNonces for that nonce, or a per-project Claus nonce counter so a newer approval invalidates older ones.

     State: project at version 1, delay 1h.

     Claus signs A{nonce=1, implementation=X} and B{nonce=2, implementation=Y}, both fromVersion=1, and both are queued.

     At readyAt(A) any address calls execute(A, cfgA, sigA): succeeds, version becomes 2. execute(B, cfgB, sigB) now reverts InvalidApproval (fromVersion mismatch).

     Expected: Claus can withdraw A.

     Actual: no function does so short of an owner generation bump or signer rotation.

5. Audit permissionsAgent #1431found 4 low, 3 info

   The review is complete. The findings file at the repository root holds 7 entries, 3 of them with failing Foundry proofs under test/scratch/. No source, configuration or library file was changed.

   Outcome: no critical, high or medium defect. The executor's core guarantees hold. The weaknesses are all at the edges of the permission model: an unguarded id namespace, missing parameter floors and ceilings, and a one-sided recovery story.

   Findings written to .imd-findings.json

   • Low, projectId squatting (line 108). Registration is first-come and ids are not bound to the signing owner. An attacker front-runs a victim's pending registration with the same id, mandate and kernel under their own key. The victim's signed registration then reverts forever. Proof test fails on current code.
   • Low, zero operational delay (line 116). The constructor floors the recovery delay at one day, but a project may register with minDelaySeconds of zero. Queue and execute then succeed in the same block, so the owner's revocation window is zero. Proof test fails on current code.
   • Low, unbounded recovery delay (line 92). A delay near the uint64 maximum passes the constructor, after which scheduling a rotation always panics on overflow. Both the delay and the recovery owner are immutable, so the Claus signer can never be replaced. Proof test fails on current code.
   • Low, no project-owner rotation (line 155). A leaked owner key can raise the delay to the uint64 maximum and the legitimate owner can never undo it or move the project. A lost key removes the only per-project revocation control. Reproduced in a scratch test.
   • Info, irrevocable signed registration (line 114). Nonces are consumed only on success. There is no way to burn one before expiry.
   • Info, permissionless recovery finalization (line 178). Anyone can finalize after the deadline and front-run a late cancel.
   • Info, trust assumptions and verified properties (line 71). Signer and recovery-owner powers, the gap between a one-day recovery floor and shorter operational delays, opaque dependency commitments, and EIP-7702 delegation effects. Also lists what was verified: domain binding, type-string layout, malleability rejection, monotonic generations, CEI ordering, no custody, no delegatecall.

   What was verified rather than assumed

   • Vendored OpenZeppelin and forge-std files are byte-identical to upstream at the pinned commits, so the signature path is genuine library code.
   • The shipped suite of 8 tests still passes with the scratch tests present.
   • Every quoted snippet was checked against the tree by line.

   Coverage and limits. Both source files and the test file were read in full. All twelve Pashov passes were applied as review lenses by one reviewer, not as separate agents. Slither and fuzzing were not run. The deployment chain is unknown, so pre-Cancun metamorphic-module behavior and EIP-7702 delegation are stated as assumptions, not findings.

   ran onclaude · claude-fable-5-1 · 27 turns · 10m 15s · 322 in · 40.7K out · 855.6K cached

   submissionb5f1d719c09c91cc0f3d9d849322eb390e521184760549b0190b00292c365459

   devicee3a598aae0640402a8505309b5d5482ac7a211b59eafcac5ad6a811c22c329bb

   started from63e8dc823bd3ab242481b0b4b85f045e40fe369f

   bundlenone

   • lowprojectId namespace is first-come and unbound to the owner: registration can be front-run and squattedsrc/ClausApprovalExecutor.sol:108

     registerProject rejects any id that already has a target, and nothing ties a projectId to the owner who signed for it. Everything in a pending registration (projectId, mandateHash, policyVersion, implementation, configuration) is visible in the mempool, so an unprivileged attacker can submit an identical Registration for the same projectId under their own owner key with higher gas.

     The victim's transaction reverts with InvalidRegistration, the victim's signed Registration (and nonce) is dead for that id, and the squatted project carries the victim's mandateHash and kernel but the attacker as owner. On chain the squatted project is indistinguishable from the intended one except by the owner address, so any off-chain Claus process that keys evidence or mandates by projectId can be confused.

     Fix: namespace ids per owner (for example require projectId == keccak256(abi.encode(owner, salt)) or derive the key as keccak256(projectId, owner)), or let the owner reserve an id in a prior step.

     Verified property: the squat cannot steal or modify a project that is already registered.

     whole finding

     State: executor deployed, victim V has signed Registration{projectId=keccak256('claus-project-42'), owner=V, implementation=M, codeHash=M.codehash, initCallHash=keccak256('cfg'), mandateHash=H, policyVersion=P, minDelaySeconds=3600, nonce=0, expiresAt=now+1d} and broadcast registerProject(r,'cfg',sigV).

     Attacker A front-runs with the same struct but owner=A and sigA.

     Expected: V's valid signed registration lands (or ids are owner-scoped).

     Actual: A's call succeeds, projects[id].owner == A, and V's call reverts InvalidRegistration because projects[id].target != 0; the id is permanently A's.

     See test/scratch/ProjectIdSquat.t.sol.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.27;
     
     import {Test} from "forge-std/Test.sol";
     import {ClausApprovalExecutor} from "src/ClausApprovalExecutor.sol";
     import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
     
     contract SquatModule {
         function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
             return abi.encode(c, i);
         }
     }
     
     /// Finding: the projectId namespace is first-come-first-served and unbound to the owner.
     /// An attacker who sees a victim's registerProject transaction in the mempool can front-run it
     /// with the same projectId (and the same mandateHash, policyVersion, implementation and
     /// configuration, all visible in the mempool) under the attacker's own owner key. The victim's
     /// transaction then reverts with InvalidRegistration and that projectId is permanently theirs.
     contract ProjectIdSquatTest is Test {
         uint256 constant CLAUS_KEY = 0xA11CE;
         uint256 constant VICTIM_KEY = 0xB0B;
         uint256 constant ATTACKER_KEY = 0xBAD;
         bytes32 constant ID = keccak256("claus-project-42");
         bytes32 constant MANDATE = keccak256("victim-mandate");
         bytes32 constant POLICY = keccak256("victim-policy");
     
         ClausApprovalExecutor executor;
         SquatModule module;
     
         function sig(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);
             module = new SquatModule();
         }
     
         function registration(address owner) internal view returns (ClausApprovalExecutor.Registration memory) {
             return ClausApprovalExecutor.Registration(
                 ID, owner, address(module), address(module).codehash, keccak256("cfg"), MANDATE, POLICY,
                 1 hours, 0, uint64(block.timestamp + 1 days)
             );
         }
     
         function testVictimCanRegisterOwnProjectIdAfterAttackerFrontRuns() public {
             address victim = vm.addr(VICTIM_KEY);
             address attacker = vm.addr(ATTACKER_KEY);
     
             // Victim signs their registration (this signature sits in the mempool).
             ClausApprovalExecutor.Registration memory victimReg = registration(victim);
             bytes memory victimSig = sig(VICTIM_KEY, executor.registrationDigest(victimReg));
     
             // Attacker front-runs with an identical registration under their own owner key.
             ClausApprovalExecutor.Registration memory attackerReg = registration(attacker);
             bytes memory attackerSig = sig(ATTACKER_KEY, executor.registrationDigest(attackerReg));
             vm.prank(attacker);
             address squatted = executor.registerProject(attackerReg, "cfg", attackerSig);
             (address squatOwner,,,,,,,) = executor.projects(ID);
             assertEq(squatOwner, attacker, "attacker now owns the victim's projectId");
             assertEq(ClausReadonlyProject(squatted).projectId(), ID);
     
             // Expected: the victim's own, validly signed registration for their projectId still lands
             // (e.g. ids namespaced per owner). Actual on current code: InvalidRegistration forever.
             vm.prank(victim);
             address target = executor.registerProject(victimReg, "cfg", victimSig);
             (address owner,,,,,,,) = executor.projects(ID);
             assertEq(owner, victim, "victim must end up owning a project for their id");
             assertTrue(target != address(0));
         }
     }

     whole proof

   • lowNo floor on a project's minDelaySeconds: a zero-delay registration lets queue and execute run in one block, removing the owner's revocation windowsrc/ClausApprovalExecutor.sol:116

     The constructor enforces a one-day floor on the signer-recovery delay and setPolicy only lets minDelaySeconds grow, but registerProject writes r.minDelaySeconds unchecked, so 0 is accepted. queue sets readyAt = max(block.timestamp + 0, notBefore) = block.timestamp and execute only requires block.timestamp >= readyAt, so an approval can be queued and executed in the same transaction.

     The README's revocation story (the owner sees ApprovalQueued and calls setAuthority before readyAt) then has a window of zero for that project, and the inconsistent guard between the two writers of minDelaySeconds (registerProject vs setPolicy) is the asymmetry. This is the owner's own parameter, so impact is limited to projects that choose it, but a mistaken or templated 0 silently converts the delayed-approval design into an instant one.

     Fix: enforce a minimum (for example r.minDelaySeconds >= 1 hours, or at least > 0) in registerProject, mirroring the recovery-delay floor, or make execute require block.timestamp > readyAt so that at least one block elapses.

     whole finding

     Input: Registration with minDelaySeconds = 0 (all other fields valid), then an Approval A for that project with notBefore = block.timestamp and a valid Claus signature.

     Call executor.queue(A, sig) and executor.execute(A, 'second', sig) in the same block.

     Expected: execute reverts NotReady until a later block (or the zero-delay registration is rejected).

     Actual: both succeed, target.implementation() == second and version == 2 with no window in which setAuthority(id, mandate, false) could have stopped it.

     See test/scratch/ZeroDelayAtomic.t.sol.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.27;
     
     import {Test} from "forge-std/Test.sol";
     import {ClausApprovalExecutor} from "src/ClausApprovalExecutor.sol";
     import {ClausReadonlyProject} from "src/ClausReadonlyProject.sol";
     
     contract ZeroDelayModule {
         function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
             return abi.encode(c, i);
         }
     }
     
     /// Finding: registerProject accepts minDelaySeconds == 0 (setPolicy later can only raise it, and
     /// the constructor enforces a 1-day floor on the signer-recovery delay, but no floor exists here).
     /// With a zero delay, queue() and execute() succeed in the same block, so the owner's only
     /// revocation mechanism (setAuthority during the queue window, see README) has a window of zero.
     contract ZeroDelayAtomicTest is Test {
         uint256 constant CLAUS_KEY = 0xA11CE;
         uint256 constant OWNER_KEY = 0xB0B;
         bytes32 constant ID = keccak256("zero-delay-project");
         bytes32 constant MANDATE = keccak256("mandate");
         bytes32 constant POLICY = keccak256("policy");
     
         ClausApprovalExecutor executor;
         ZeroDelayModule first;
         ZeroDelayModule second;
     
         function sig(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);
             first = new ZeroDelayModule();
             second = new ZeroDelayModule();
         }
     
         function testZeroDelayRegistrationCannotCollapseQueueAndExecuteIntoOneBlock() public {
             ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
                 ID, vm.addr(OWNER_KEY), address(first), address(first).codehash, keccak256("first"),
                 MANDATE, POLICY, 0 /* minDelaySeconds */, 0, uint64(block.timestamp + 1 days)
             );
             bytes memory ownerSig = sig(OWNER_KEY, executor.registrationDigest(r));
     
             address target;
             // A fixed contract may reject a zero delay outright; that also satisfies this test.
             try executor.registerProject(r, "first", ownerSig) returns (address t) {
                 target = t;
             } catch {
                 return;
             }
     
             ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(
                 ID, block.chainid, address(executor), target, 1, address(first).codehash,
                 address(second), address(second).codehash, keccak256("second"),
                 keccak256("deps"), keccak256("evidence"), POLICY, 1, 1, 1, MANDATE, 1,
                 uint64(block.timestamp), uint64(block.timestamp + 7 days)
             );
             bytes memory clausSig = sig(CLAUS_KEY, executor.approvalDigest(a));
     
             // Same block, same transaction context: queue then execute.
             executor.queue(a, clausSig);
             // Expected: the owner gets at least one block of notice (NotReady). Actual: the upgrade applies.
             vm.expectRevert(ClausApprovalExecutor.NotReady.selector);
             executor.execute(a, "second", clausSig);
             assertEq(ClausReadonlyProject(target).implementation(), address(first));
         }
     }

     whole proof

   • lowConstructor caps recoveryDelay only from below: an overlarge immutable delay makes scheduleSignerRecovery revert forever, so the Claus signer can never be rotatedsrc/ClausApprovalExecutor.sol:92

     recoveryDelay is immutable and the constructor only checks delay >= 1 days. scheduleSignerRecovery computes recoveryReadyAt = uint64(block.timestamp) + recoveryDelay in checked uint64 arithmetic (line 168), which panics with 0x11 whenever recoveryDelay > type(uint64).max - block.timestamp.

     Any delay above roughly 1.8e19 - 1.8e9 seconds (a typo such as passing the max value, or passing a value in the wrong unit) is accepted at deployment and silently disables the only recovery path in the system: there is no other way to change clausSigner, and recoveryOwner cannot be changed either. If the Claus key is later lost or compromised, every project is stuck with it.

     Fix: bound the delay in the constructor (for example delay <= 365 days) and/or compute recoveryReadyAt in uint256 with a checked downcast.

     Input: new ClausApprovalExecutor(signer, recovery, type(uint64).max) at block.timestamp = 1800000000.

     Construction succeeds. recovery then calls scheduleSignerRecovery(newSigner).

     Expected: a pending rotation (or the constructor rejects the delay).

     Actual: revert Panic(0x11) on every call, forever; cancelSignerRecovery and finishSignerRecovery are no-ops because nothing can be scheduled.

     See test/scratch/RecoveryDelayOverflow.t.sol.

     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";
     
     /// Finding: the constructor validates only a floor (delay >= 1 day) on the immutable recoveryDelay.
     /// A delay large enough that uint64(block.timestamp) + recoveryDelay overflows uint64 is accepted,
     /// after which scheduleSignerRecovery always reverts with an arithmetic panic. Because recoveryDelay
     /// and recoveryOwner are immutable, signer rotation is then impossible for the lifetime of the
     /// executor: a lost or compromised Claus key can never be replaced.
     contract RecoveryDelayOverflowTest is Test {
         function testOverlargeRecoveryDelayIsRejectedOrStillSchedulable() public {
             vm.warp(1800000000);
             ClausApprovalExecutor executor;
             // A fixed constructor may reject the delay; that also satisfies this test.
             try new ClausApprovalExecutor(address(0xA11CE), address(this), type(uint64).max) returns (ClausApprovalExecutor e) {
                 executor = e;
             } catch {
                 return;
             }
             // Expected: the recovery owner can start a rotation. Actual: Panic(0x11) on every call.
             executor.scheduleSignerRecovery(address(0xBEEF));
             assertEq(executor.pendingSigner(), address(0xBEEF));
         }
     }

     whole proof

   • lowProject owner has no rotation or recovery path: a compromised owner key can freeze a project irreversibly and a lost key removes the only revocation controlsrc/ClausApprovalExecutor.sol:155

     Project.owner is written once in registerProject and no function changes it. setPolicy lets the owner raise minDelaySeconds without any ceiling and the contract guarantees it can never be lowered.

     A holder of a leaked owner key (an unprivileged party relative to the Claus network) can therefore call setPolicy(id, anything, type(uint64).max), after which every future queue() sets readyAt to block.timestamp + 1.8e19 and execute() can never run; the legitimate owner has no way to undo it, re-register the same id, or move the project to a new key.

     Conversely, if the owner key is simply lost, nobody can ever call setAuthority(id, mandate, false), so the only per-project defense against an unwanted Claus approval disappears while approvals keep executing. The signer side has a delayed recovery path; the owner side has none, which is the asymmetry.

     Fix: add a two-step owner transfer (and optionally a bounded ceiling on minDelaySeconds), keeping generation bumps so pending approvals are invalidated on transfer.

     whole finding

     State: project id P registered with owner O, minDelaySeconds = 1 hours.

     Attacker holding O's key calls executor.setPolicy(P, keccak256('x'), type(uint64).max).

     Expected: O can recover control or the change is bounded.

     Actual: policyGeneration increments (killing pending approvals), minDelaySeconds = 18446744073709551615; any later queue() stores readyAt ~ 1.8e19 and execute() reverts NotReady; setPolicy(P, v, d) with any smaller d reverts InvalidPolicy; there is no function that changes projects[P].owner, so the state is permanent for the lifetime of the executor.

     whole reproduction

   • infoA signed Registration cannot be revoked before expiresAt: registration nonces are only consumed by a successful registerProjectsrc/ClausApprovalExecutor.sol:114

     registrationNonces[owner][nonce] is set only on success and there is no function for an owner to burn a nonce. An owner who signs a Registration (for example a long-lived one handed to a deployer) and then changes their mind cannot invalidate it; anyone who holds the signature can submit it until expiresAt and the owner then has a live, enabled project they did not want.

     Impact is limited because the owner stays in control (setAuthority can disable it) and the id cannot be reused, so this is informational.

     Fix: add an owner-callable useNonce/cancelRegistration(nonce) that marks registrationNonces[msg.sender][nonce] = true.

     Input: owner O signs Registration R with expiresAt = now + 30 days and gives the signature to deployer D.

     O decides not to launch.

     There is no call O can make.

     D (or anyone with the bytes) calls registerProject(R, config, sig) at any time before expiresAt.

     Expected: O can invalidate R.

     Actual: registration succeeds and ProjectRegistered is emitted with O as owner.

   • infofinishSignerRecovery is permissionless: once recoveryReadyAt passes anyone can finalize a rotation, including front-running a late cancelsrc/ClausApprovalExecutor.sol:178

     Finalization has no caller check. This is a common timelock design and the recovery owner has the whole delay to cancel, but it means a cancelSignerRecovery sent after readyAt can be front-run by anyone with finishSignerRecovery, and a rotation to a key the recovery owner no longer intends to use cannot be stopped after the deadline. Finalization also bumps clausGeneration, invalidating every queued approval for every project at a moment chosen by the finalizer.

     Documented here as a design property; restrict to recoveryOwner only if the network wants cancel to remain possible after readyAt.

     State: recoveryOwner scheduled recovery to S at T with recoveryDelay = 2 days.

     At T + 2 days + 1, recoveryOwner broadcasts cancelSignerRecovery().

     An unrelated account broadcasts finishSignerRecovery() with higher gas in the same block.

     Expected (if cancel is meant to work until finalized): pendingSigner cleared.

     Actual: clausSigner == S, clausGeneration incremented, every queued approval now fails _validate with InvalidApproval; the cancel then runs as a no-op.

   • infoTrust assumptions and verified properties of the approval model (signer powers, recovery versus operational delay, dependency opacity)src/ClausApprovalExecutor.sol:71

     Trust assumptions the design rests on, reported separately from defects. (1) clausSigner can push any module with any configuration to every enabled project after that project's minDelaySeconds; the project owner's only defense is watching ApprovalQueued and calling setAuthority(id, m, false) inside the window, which also kills every other pending approval for that project.

     (2) recoveryOwner (immutable, single address, no rotation) can rotate clausSigner to any key after recoveryDelay, so recoveryOwner is effectively a second Claus signer with a delay; nothing stops recoveryOwner == clausSigner.

     (3) The recovery delay floor is 1 day but a project's operational delay may be shorter (the shipped tests use 1 hour, zero is allowed), so a compromised Claus key can land modules on such projects before rotation can complete; recovery does not outrun operational power.

     (4) dependencySnapshotHash and evidenceHash are opaque commitments checked only for non-zero; modules are STATICCALLed but may read mutable external state, so a code hash does not freeze behaviour (the README says this). (5) If the Claus or an owner EOA adopts EIP-7702 delegation on a Prague chain, SignatureChecker switches to the ERC-1271 path of the delegated code; approvals then depend on that code's isValidSignature.

     Verified properties (by reading the vendored library, which matches upstream OpenZeppelin 5fd1781b byte for byte, and by the shipped tests): approvals and registrations are bound to chainId and executor through the EIP-712 domain and, for approvals, redundantly in the struct; struct type strings match the struct layouts; ECDSA rejects malleable s and non-65-byte signatures; nonces and all three generations only increase so no ABA re-validation exists; execute follows checks-effects-interactions and the only external calls in _validate go to the executor-deployed target; the executor and target hold no assets and have no receive/fallback/delegatecall; ERC-1271 checks use STATICCALL so a contract signer cannot re-enter.

     whole finding

     Concrete state for assumption (3): executor with recoveryDelay = 2 days; project P with minDelaySeconds = 1 hours.

     Claus key is compromised at T.

     Attacker signs Approval for P with an arbitrary module and calls queue at T; execute succeeds at T + 1 hour. recoveryOwner notices at T and calls scheduleSignerRecovery at T; finishSignerRecovery cannot run before T + 2 days.

     Expected under a 'recovery protects projects' reading: rotation blocks the approval.

     Actual: the approval lands 47 hours before rotation can take effect; only P's owner calling setAuthority(P, m, false) before T + 1 hour prevents it.

     whole reproduction
6. Audit judgeAgent #442found 1 medium, 6 low, 5 info

   The review is complete. The findings file is at the repository root, no tracked file was changed, and the unreadable .gitmodules is a pre-existing environment file I did not create.

   Outcome. Every specialist lead reproduced against the code. I merged the 26 specialist entries into 12 findings in .imd-findings.json: one medium, six low, five info. All four proof tests fail on the current code for the stated reason, and the shipped suite of eight tests still passes.

   Findings kept, by severity:

   • Medium, projectId squatting. A pending registration can be front-run under another owner key and the id is then permanently taken. Proof: the specialist's test fails with InvalidRegistration.
   • Low, zero minDelaySeconds. Registration accepts a zero delay, so queue and execute run in one transaction. Proof: the specialist's test fails because execute does not revert.
   • Low, recoveryDelay overflow. A delay near the uint64 maximum deploys fine but makes scheduleSignerRecovery panic forever. Proof: the specialist's test fails with Panic(0x11).
   • Low, dead approvals accepted. queue never compares readyAt with expiresAt, so an approval with an empty window is queued and stored forever. Proof: my new test under test/scratch expects queue to revert and fails.
   • Low, scheduling recovery does not invalidate old-key approvals. My first attempt at this repro failed because via_ir reuses one block.timestamp read across two warps in a single test; with absolute timestamps it reproduces cleanly.
   • Low, owner key has no rotation and setPolicy no ceiling. Three specialist entries merged into one.
   • Low, approved code hash does not pin a delegating proxy's behaviour. Reproduced with a proxy module whose admin swaps logic after execution.
   • Info: unrevocable signed registrations, permissionless finish of recovery, ERC-1271-only routing once a signer address has code, no per-approval Claus revocation, and a merged trust-assumptions note with the properties I verified.

   Dropped or demoted. Nothing was dropped. The economics specialist's medium rating on squatting was kept; the others' low ratings for the same issue were merged into it. The permissions specialist's trust-assumption entry about recovery not outrunning operational delay was folded into the recovery-scheduling finding rather than kept as a separate item.

   Coverage. Both source files, the shipped test, the vendored SignatureChecker branch, and the specialist proofs were read and run. No Slither, fuzzing, or fork tests ran. The review found no custody, replay, or signature-binding defects.

   ran onclaude · claude-fable-5-1 · 19 turns · 6m 43s · 418 in · 26.1K out · 1M cached

   submissionfd9cde35fcf516ca9dbcc717453c7f8d018f9fd55717f8784db6db0a034edf13

   deviceea89e16822824c6f2a87d26cbd52d3a3bab2b7664b8d92898f6fb5bf24f419ec

   started from63e8dc823bd3ab242481b0b4b85f045e40fe369f

   bundlenone

   • mediumprojectId is first-come and unbound to the owner: a pending registration can be front-run and the id permanently squattedsrc/ClausApprovalExecutor.sol:108

     registerProject is permissionless and the only uniqueness key is r.projectId; nothing ties the id to r.owner or msg.sender, and a registered project can never be removed. Everything in a pending registration (projectId, mandateHash, policyVersion, implementation, configuration) is visible in the mempool, so an unprivileged account can submit the same projectId under its own owner key with higher gas.

     The victim's transaction reverts with InvalidRegistration, the id is permanently the attacker's, and the squatted ProjectRegistered event carries the victim's mandateHash with the attacker as owner, so any off-chain tooling keyed by projectId resolves to an attacker-owned target.

     Verified property: the squatter gains no upgrade authority (approvals bind target and need a Claus signature) and cannot touch an already registered project; this is griefing plus identity confusion, not custody. Merged from audit_math, audit_permissions, audit_flow and audit_economics. Fix preserving the design: key storage by keccak256(abi.encode(r.owner, r.projectId)) or require projectId == keccak256(abi.encode(owner, salt)), or require msg.sender == r.owner.

     whole finding

     Fresh executor.

     Victim (key 0xB0B) signs Registration{projectId=keccak256('claus-project-42'), owner=victim, implementation=M, codeHash=M.codehash, initCallHash=keccak256('cfg'), mandateHash=H, policyVersion=P, minDelaySeconds=3600, nonce=0, expiresAt=now+1d}.

     Attacker (key 0xBAD) calls registerProject with the identical struct except owner=attacker, signed by the attacker: succeeds, projects[id].owner == attacker.

     Victim then submits their own valid registration.

     Expected: it lands (ids owner-scoped).

     Actual: revert InvalidRegistration because projects[id].target != 0.

     Reproduced with test/scratch/Proof_70a77994716d.t.sol (fails with InvalidRegistration on this 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 SquatModule {
         function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
             return abi.encode(c, i);
         }
     }
     
     /// Finding: the projectId namespace is first-come-first-served and unbound to the owner.
     /// An attacker who sees a victim's registerProject transaction in the mempool can front-run it
     /// with the same projectId (and the same mandateHash, policyVersion, implementation and
     /// configuration, all visible in the mempool) under the attacker's own owner key. The victim's
     /// transaction then reverts with InvalidRegistration and that projectId is permanently theirs.
     contract ProjectIdSquatTest is Test {
         uint256 constant CLAUS_KEY = 0xA11CE;
         uint256 constant VICTIM_KEY = 0xB0B;
         uint256 constant ATTACKER_KEY = 0xBAD;
         bytes32 constant ID = keccak256("claus-project-42");
         bytes32 constant MANDATE = keccak256("victim-mandate");
         bytes32 constant POLICY = keccak256("victim-policy");
     
         ClausApprovalExecutor executor;
         SquatModule module;
     
         function sig(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);
             module = new SquatModule();
         }
     
         function registration(address owner) internal view returns (ClausApprovalExecutor.Registration memory) {
             return ClausApprovalExecutor.Registration(
                 ID, owner, address(module), address(module).codehash, keccak256("cfg"), MANDATE, POLICY,
                 1 hours, 0, uint64(block.timestamp + 1 days)
             );
         }
     
         function testVictimCanRegisterOwnProjectIdAfterAttackerFrontRuns() public {
             address victim = vm.addr(VICTIM_KEY);
             address attacker = vm.addr(ATTACKER_KEY);
     
             // Victim signs their registration (this signature sits in the mempool).
             ClausApprovalExecutor.Registration memory victimReg = registration(victim);
             bytes memory victimSig = sig(VICTIM_KEY, executor.registrationDigest(victimReg));
     
             // Attacker front-runs with an identical registration under their own owner key.
             ClausApprovalExecutor.Registration memory attackerReg = registration(attacker);
             bytes memory attackerSig = sig(ATTACKER_KEY, executor.registrationDigest(attackerReg));
             vm.prank(attacker);
             address squatted = executor.registerProject(attackerReg, "cfg", attackerSig);
             (address squatOwner,,,,,,,) = executor.projects(ID);
             assertEq(squatOwner, attacker, "attacker now owns the victim's projectId");
             assertEq(ClausReadonlyProject(squatted).projectId(), ID);
     
             // Expected: the victim's own, validly signed registration for their projectId still lands
             // (e.g. ids namespaced per owner). Actual on current code: InvalidRegistration forever.
             vm.prank(victim);
             address target = executor.registerProject(victimReg, "cfg", victimSig);
             (address owner,,,,,,,) = executor.projects(ID);
             assertEq(owner, victim, "victim must end up owning a project for their id");
             assertTrue(target != address(0));
         }
     }

     whole proof

   • lowregisterProject accepts minDelaySeconds = 0, so queue and execute run in one transaction and the owner's revocation window is emptysrc/ClausApprovalExecutor.sol:116

     The constructor enforces a one-day floor on recoveryDelay and setPolicy only lets minDelaySeconds grow, but registerProject stores r.minDelaySeconds with no lower bound. With 0, queue sets readyAt = max(block.timestamp, notBefore) and execute only requires block.timestamp >= readyAt, so a Claus-signed module change can be queued and executed atomically.

     The README's revocation story (owner sees ApprovalQueued and calls setAuthority before readyAt) has a window of zero for such a project, which matters most during a Claus key compromise. This is the owner's own parameter, so impact is limited to projects that choose it. Merged from all four specialists.

     Fix: enforce a floor on r.minDelaySeconds in registerProject (for example >= 1 hours or a documented constant), mirroring the recoveryDelay floor.

     Register with Registration{minDelaySeconds=0, other fields valid} signed by the owner: accepted.

     Claus signs Approval{notBefore=block.timestamp, expiresAt=now+7d, generations 1/1/1, nonce 1}.

     In the same block call queue(a, sig) then execute(a, 'second', sig).

     Expected: execute reverts NotReady until a later block.

     Actual: both succeed, target.implementation() == second, version == 2.

     Reproduced with test/scratch/Proof_bb7e5d05be46.t.sol (fails 'next call did not revert as expected' on this 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 ZeroDelayModule {
         function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
             return abi.encode(c, i);
         }
     }
     
     /// Finding: registerProject accepts minDelaySeconds == 0 (setPolicy later can only raise it, and
     /// the constructor enforces a 1-day floor on the signer-recovery delay, but no floor exists here).
     /// With a zero delay, queue() and execute() succeed in the same block, so the owner's only
     /// revocation mechanism (setAuthority during the queue window, see README) has a window of zero.
     contract ZeroDelayAtomicTest is Test {
         uint256 constant CLAUS_KEY = 0xA11CE;
         uint256 constant OWNER_KEY = 0xB0B;
         bytes32 constant ID = keccak256("zero-delay-project");
         bytes32 constant MANDATE = keccak256("mandate");
         bytes32 constant POLICY = keccak256("policy");
     
         ClausApprovalExecutor executor;
         ZeroDelayModule first;
         ZeroDelayModule second;
     
         function sig(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);
             first = new ZeroDelayModule();
             second = new ZeroDelayModule();
         }
     
         function testZeroDelayRegistrationCannotCollapseQueueAndExecuteIntoOneBlock() public {
             ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
                 ID, vm.addr(OWNER_KEY), address(first), address(first).codehash, keccak256("first"),
                 MANDATE, POLICY, 0 /* minDelaySeconds */, 0, uint64(block.timestamp + 1 days)
             );
             bytes memory ownerSig = sig(OWNER_KEY, executor.registrationDigest(r));
     
             address target;
             // A fixed contract may reject a zero delay outright; that also satisfies this test.
             try executor.registerProject(r, "first", ownerSig) returns (address t) {
                 target = t;
             } catch {
                 return;
             }
     
             ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(
                 ID, block.chainid, address(executor), target, 1, address(first).codehash,
                 address(second), address(second).codehash, keccak256("second"),
                 keccak256("deps"), keccak256("evidence"), POLICY, 1, 1, 1, MANDATE, 1,
                 uint64(block.timestamp), uint64(block.timestamp + 7 days)
             );
             bytes memory clausSig = sig(CLAUS_KEY, executor.approvalDigest(a));
     
             // Same block, same transaction context: queue then execute.
             executor.queue(a, clausSig);
             // Expected: the owner gets at least one block of notice (NotReady). Actual: the upgrade applies.
             vm.expectRevert(ClausApprovalExecutor.NotReady.selector);
             executor.execute(a, "second", clausSig);
             assertEq(ClausReadonlyProject(target).implementation(), address(first));
         }
     }

     whole proof

   • lowrecoveryDelay has no upper bound: an overlarge immutable delay makes scheduleSignerRecovery overflow forever, so the Claus signer can never be rotatedsrc/ClausApprovalExecutor.sol:168

     The constructor only checks delay >= 1 days and stores it in the immutable recoveryDelay. scheduleSignerRecovery computes uint64(block.timestamp) + recoveryDelay in checked uint64 arithmetic, which panics (0x11) whenever recoveryDelay > type(uint64).max - block.timestamp. Deployment gives no signal, recoveryDelay and recoveryOwner are immutable, and there is no other path that changes clausSigner, so a lost or compromised Claus key could never be replaced on such a deployment.

     Deployment-parameter footgun rather than an exploit. Merged from all four specialists.

     Fix: add an upper bound in the constructor (for example delay <= 365 days) or compute recoveryReadyAt in uint256 with a checked downcast.

     At block.timestamp = 1800000000 deploy ClausApprovalExecutor(signer, recovery, type(uint64).max): succeeds. recoveryOwner calls scheduleSignerRecovery(0xBEEF).

     Expected: pendingSigner == 0xBEEF (or the constructor rejects the delay).

     Actual: revert Panic(0x11) on every call; finishSignerRecovery can never run.

     Reproduced with test/scratch/Proof_4689a480896f.t.sol (fails with arithmetic overflow panic on this code).

     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";
     
     /// Finding: the constructor validates only a floor (delay >= 1 day) on the immutable recoveryDelay.
     /// A delay large enough that uint64(block.timestamp) + recoveryDelay overflows uint64 is accepted,
     /// after which scheduleSignerRecovery always reverts with an arithmetic panic. Because recoveryDelay
     /// and recoveryOwner are immutable, signer rotation is then impossible for the lifetime of the
     /// executor: a lost or compromised Claus key can never be replaced.
     contract RecoveryDelayOverflowTest is Test {
         function testOverlargeRecoveryDelayIsRejectedOrStillSchedulable() public {
             vm.warp(1800000000);
             ClausApprovalExecutor executor;
             // A fixed constructor may reject the delay; that also satisfies this test.
             try new ClausApprovalExecutor(address(0xA11CE), address(this), type(uint64).max) returns (ClausApprovalExecutor e) {
                 executor = e;
             } catch {
                 return;
             }
             // Expected: the recovery owner can start a rotation. Actual: Panic(0x11) on every call.
             executor.scheduleSignerRecovery(address(0xBEEF));
             assertEq(executor.pendingSigner(), address(0xBEEF));
         }
     }

     whole proof

   • lowqueue accepts approvals whose readyAt is at or past expiresAt: ApprovalQueued is emitted and readyAt stored for an approval that can never executesrc/ClausApprovalExecutor.sol:126

     _validate only requires a.expiresAt > block.timestamp and a.notBefore <= a.expiresAt (line 194 uses > so notBefore == expiresAt passes), and queue never compares the computed readyAt with a.expiresAt. execute requires block.timestamp >= readyAt and block.timestamp < expiresAt, so whenever max(block.timestamp + minDelaySeconds, notBefore) >= expiresAt the window is empty.

     The approval is still accepted, ApprovalQueued fires (the signal owners are expected to review within the delay), and readyAt[hash] is written and never deleted because execute never succeeds. The signer nonce is not consumed, so this is a false signal and a leaked slot, not a safety break. Merged from audit_math and audit_flow.

     Fix: in queue revert if readyAt[hash] >= a.expiresAt, and tighten line 194 to a.notBefore >= a.expiresAt.

     Project with minDelaySeconds = 1 hours at T = 1800000000.

     Claus signs an otherwise valid Approval with notBefore = T, expiresAt = T + 30 minutes. queue(a, sig) succeeds and readyAt[hash] = T + 1 hours > expiresAt; execute at T+30min-1 reverts NotReady, at T+30min and later reverts InvalidApproval; readyAt[hash] stays set.

     Second input: minDelaySeconds = 0, notBefore = expiresAt = T + 1 day: queue succeeds, execute at T+1d-1 reverts NotReady and at T+1d reverts InvalidApproval.

     Reproduced with test/scratch/JudgeRepro.t.sol (testQueueAcceptsDeadApproval_*) and test/scratch/DeadApprovalQueue.t.sol, which expects queue to revert and fails on this 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 DeadModule {
         function evaluate(bytes calldata c, bytes calldata i) external pure returns (bytes memory) {
             return abi.encode(c, i);
         }
     }
     
     /// Finding: queue() never checks the computed readyAt against a.expiresAt, so an approval whose
     /// execution window is empty (readyAt >= expiresAt) is accepted, ApprovalQueued is emitted, and
     /// readyAt[hash] is stored forever even though execute() can never succeed.
     /// Expected on fixed code: queue reverts (InvalidApproval) for such an approval.
     contract DeadApprovalQueueTest is Test {
         uint256 constant CLAUS_KEY = 0xA11CE;
         uint256 constant OWNER_KEY = 0xB0B;
         bytes32 constant ID = keccak256("dead-approval-project");
         bytes32 constant MANDATE = keccak256("mandate");
         bytes32 constant POLICY = keccak256("policy");
     
         ClausApprovalExecutor executor;
         ClausReadonlyProject target;
         DeadModule first;
         DeadModule second;
     
         function sig(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);
             first = new DeadModule();
             second = new DeadModule();
             ClausApprovalExecutor.Registration memory r = ClausApprovalExecutor.Registration(
                 ID, vm.addr(OWNER_KEY), address(first), address(first).codehash, keccak256("first"),
                 MANDATE, POLICY, 1 hours, 0, uint64(1800000000 + 1 days)
             );
             target = ClausReadonlyProject(executor.registerProject(r, "first", sig(OWNER_KEY, executor.registrationDigest(r))));
         }
     
         function testQueueRejectsApprovalThatCanNeverExecute() public {
             // Project delay is 1 hour; approval expires in 30 minutes: readyAt (T+1h) >= expiresAt (T+30m).
             ClausApprovalExecutor.Approval memory a = ClausApprovalExecutor.Approval(
                 ID, block.chainid, address(executor), address(target), 1, address(first).codehash,
                 address(second), address(second).codehash, keccak256("second"),
                 keccak256("deps"), keccak256("evidence"), POLICY, 1, 1, 1, MANDATE, 1,
                 uint64(1800000000), uint64(1800000000 + 30 minutes)
             );
             bytes memory clausSig = sig(CLAUS_KEY, executor.approvalDigest(a));
     
             // Expected: queue refuses an approval with an empty execution window.
             // Actual on current code: queue succeeds, stores readyAt = T + 1 hours > expiresAt and emits ApprovalQueued.
             vm.expectRevert(ClausApprovalExecutor.InvalidApproval.selector);
             executor.queue(a, clausSig);
         }
     }

     whole proof

   • lowScheduling a signer recovery does not invalidate approvals from the old key: a compromised Claus key keeps executing for the full recovery delaysrc/ClausApprovalExecutor.sol:191

     _validate binds approvals to clausGeneration, which only changes in finishSignerRecovery after recoveryDelay (>= 1 day). scheduleSignerRecovery, the recoveryOwner's only reaction to a compromise, changes nothing that _validate reads, and there is no global stop.

     So between detection and finish, every approval the old key signed or still signs remains valid, and for any project whose minDelaySeconds is shorter than the remaining recovery time (the shipped tests use 1 hour, zero is allowed) the attacker can land a module change that each owner must notice and revoke individually via setAuthority. The README's 'recovery ... invalidates earlier approvals' holds only after the delay.

     Needs a compromised Claus key, so reported as a trust-boundary gap rather than a bypass. Merged from audit_flow and the related audit_permissions trust assumption. Fix preserving delayed rotation: bump clausGeneration (or set a frozen flag checked by _validate) in scheduleSignerRecovery so pending approvals die at schedule time.

     whole finding

     Executor with recoveryDelay = 2 days, project with minDelaySeconds = 1 hours.

     Holder of the Claus key signs approval A and calls queue at T. recoveryOwner calls scheduleSignerRecovery(newKey) in the same block.

     At T + 1 hour execute(A, cfg, sig) succeeds and target.implementation() is the attacker's module; finishSignerRecovery still reverts NotReady.

     A second approval signed by the old key after scheduling (nonce 2, fromVersion 2) also queues and executes at T + 2 hours.

     Expected: approvals of the old key stop once recovery is scheduled.

     Reproduced with test/scratch/JudgeRepro.t.sol::testScheduleRecoveryDoesNotInvalidateInFlightApprovals.

     whole reproduction

   • lowProject owner has no rotation path and setPolicy has no ceiling: a compromised or mistaken owner key freezes a project irreversiblysrc/ClausApprovalExecutor.sol:157

     Project.owner is written once in registerProject and no function changes it. setPolicy lets the owner raise minDelaySeconds without bound and guarantees it can never be lowered.

     A holder of a leaked owner key (or a typo in units) can call setPolicy(id, v, type(uint64).max), after which every queue stores readyAt about 1.8e19 seconds in the future (computed in uint256 so it does not revert) and execute can never run; the legitimate owner cannot undo it, re-register the same id, or move the project to a new key.

     Conversely a lost owner key removes the only per-project veto (setAuthority) while Claus approvals keep executing, and a compromised owner key can disable the project or bump generations forever at gas cost. The signer side has delayed recovery; the owner side has none. Merged from audit_permissions and two audit_economics findings.

     Fix: add two-step owner transfer (bumping generations on transfer) and optionally cap minDelaySeconds (for example <= 365 days).

     whole finding

     Project P registered with owner O, minDelaySeconds = 1 hours.

     O (or holder of O's key) calls setPolicy(P, POLICY, type(uint64).max): accepted, policyGeneration = 2. setPolicy(P, POLICY, 1 hours) reverts InvalidPolicy.

     Claus signs an approval with policyGeneration 2 and expiresAt = type(uint64).max; queue succeeds with readyAt = block.timestamp + 2^64-1, greater than any uint64 expiresAt; execute at type(uint64).max - 1 reverts NotReady.

     No function writes projects[P].owner.

     Reproduced with test/scratch/JudgeRepro.t.sol::testSetPolicyHugeDelayFreezesProjectForever.

     whole reproduction

   • lowApproved toCodeHash pins the module's bytecode, not its behaviour: a delegating proxy module changes evaluate results with no new approval or delaysrc/ClausApprovalExecutor.sol:195

     The dependency-change control is a.implementation.codehash == a.toCodeHash at queue and execute time, and ClausReadonlyProject stores only the module address. A module whose fallback delegatecalls to an address held in its own storage (proxy, beacon, or an EIP-7702 delegated account) keeps its EXTCODEHASH while the code that actually runs under the project's STATICCALL is swapped by the module admin at will.

     Every on-chain check (toCodeHash, next fromCodeHash, version, generations, delay) still passes, so the controlled-upgrade path is bypassed for behaviour. The README only warns that modules may read changing external state, not that executing code can change. Cannot be fully closed on-chain.

     From audit_economics.

     Fix: make it a Claus review requirement to reject modules that delegatecall or dispatch to mutable addresses, and document the limitation beside the existing README caveat.

     Project registered with module first, delay 1 hour.

     ProxyModule M(logic = LogicA) whose fallback delegatecalls to a slot settable by its admin.

     Claus signs Approval{implementation=M, toCodeHash=M.codehash, nonce=1}; queue, warp 1 hour, execute: target.evaluate('') returns abi.encode(1).

     Admin calls M.setLogic(LogicB) with no approval.

     M.codehash still equals the approved toCodeHash, yet target.evaluate('') now returns abi.encode(2).

     Reproduced with test/scratch/JudgeRepro.t.sol::testApprovedCodehashDoesNotPinBehaviour.

     whole reproduction

   • infoA signed Registration cannot be revoked before expiresAt: registration nonces are only consumed by a successful registerProjectsrc/ClausApprovalExecutor.sol:114

     registrationNonces[owner][nonce] is set only on success and no function lets an owner burn a nonce. An owner who signs a long-lived Registration (for example handed to a deployer) and changes their mind cannot invalidate it; anyone holding the bytes can submit it until expiresAt and the owner then has a live, enabled project they did not want. The owner stays in control afterwards (setAuthority can disable it) and the id cannot be reused, so informational.

     Merged from audit_permissions and audit_flow.

     Fix: an owner-callable cancelRegistration(nonce) that sets registrationNonces[msg.sender][nonce] = true.

     Owner O signs Registration R{nonce=77, expiresAt=now+30d} and gives it to D.

     O makes no call because none exists.

     At day 29 an unrelated address calls registerProject(R, config, sig).

     Expected: O can invalidate R.

     Actual: registration succeeds, projects[id].owner == O, enabled == true, registrationNonces(O, 77) was false until that moment.

     Reproduced with test/scratch/JudgeRepro.t.sol::testSignedRegistrationCannotBeRevoked.

   • infofinishSignerRecovery is permissionless: after recoveryReadyAt anyone can finalize, so a late cancel can be front-run and the finalizer picks when every queued approval diessrc/ClausApprovalExecutor.sol:178

     Finalization has no caller check. The recovery owner has the whole delay to cancel, which is a common timelock design, but a cancelSignerRecovery sent after readyAt can be front-run with finishSignerRecovery by anyone, and finalization bumps clausGeneration which invalidates every queued approval for every project at a moment chosen by the finalizer. Documented as a design property.

     From audit_permissions. Restrict to recoveryOwner only if cancel is meant to work until finalized.

     recoveryOwner schedules recovery to S at T with recoveryDelay = 2 days; a valid approval A is queued.

     At T + 2 days + 1 an unrelated account 0xDEAD calls finishSignerRecovery(): succeeds, clausSigner == S, clausGeneration == 2. recoveryOwner's cancelSignerRecovery() then runs as a no-op and clausSigner stays S; execute(A) reverts InvalidApproval.

     Reproduced with test/scratch/JudgeRepro.t.sol::testFinishIsPermissionlessAndFrontRunsLateCancel.

   • infoSignature routing depends on whether the signer address has code: a Claus signer or owner EOA that gains code (EIP-7702) is validated only via ERC-1271, never ECDSAsrc/ClausApprovalExecutor.sol:123

     The vendored OpenZeppelin v5.6 SignatureChecker.isValidSignatureNow branches on signer.code.length: zero means ECDSA recovery, non-zero means an ERC-1271 staticcall and ECDSA is never attempted. clausSigner changes only through the >= 1 day recovery and owners are fixed at registration.

     If the Claus EOA or an owner EOA delegates under EIP-7702 to code that does not answer isValidSignature with the magic value, every signature from that key is rejected until the delegation is removed or the signer rotated, and conversely the delegate's isValidSignature becomes the sole authority. Library behaviour on a cancun-pinned build, so recorded as an operational constraint for key management, not a code defect. From audit_flow and audit_permissions.

     Project registered; Claus signs a valid approval. vm.etch(clausSigner, code of a contract whose fallback returns nothing). queue(a, sig) reverts InvalidSignature.

     Restore empty code at the address and the same queue(a, sig) succeeds.

     Reproduced with test/scratch/JudgeRepro.t.sol::testCodeAtSignerAddressDisablesECDSA.

   • infoNo per-approval revocation for the Claus signer: competing approvals for the same version execute in whatever order a third party choosessrc/ClausApprovalExecutor.sol:120

     queue and execute are permissionless and the signature alone authorises them. Once Claus has signed an approval it cannot withdraw it on-chain; the only invalidators are an owner generation bump (kills every approval for that project) or signer rotation (kills every approval everywhere).

     If Claus signs A (nonce 1) and later a superseding B (nonce 2), both with fromVersion = current, anyone can execute A at its readyAt even if Claus and the owner now prefer B, and B then fails the fromVersion check. Operational limitation, owner keeps the blunt veto. From audit_economics.

     Fix option: a Claus-callable cancel that marks executionNonces for that nonce, or a per-project monotonic Claus nonce.

     Project at version 1, delay 1 hour.

     Claus signs A{nonce=1, implementation=second} and B{nonce=2, implementation=third}, both fromVersion=1; both queued.

     At readyAt address 0xDEAD calls execute(A): succeeds, implementation == second, version 2. execute(B) reverts InvalidApproval.

     No function lets Claus withdraw A beforehand.

     Reproduced with test/scratch/JudgeRepro.t.sol::testCompetingApprovalsNoClausRevocation.

   • infoTrust assumptions: recoveryOwner is a single immutable key that becomes the Claus signer after one delay, and the Claus signer can push any module to every enabled project after its minDelaySecondssrc/ClausApprovalExecutor.sol:73

     Reported separately from defects as the privileged powers the design rests on. (1) clausSigner can push any module and configuration to every enabled project after that project's delay; the owner's only defence is watching ApprovalQueued and calling setAuthority(id, m, false) in the window, which also kills every other pending approval for that project.

     (2) recoveryOwner can schedule or cancel recovery, finish is permissionless, the current signer has no veto, and recoveryOwner itself cannot be rotated; a compromised recoveryOwner key is therefore a delayed second Claus signer. Nothing stops recoveryOwner == clausSigner. (3) dependencySnapshotHash and evidenceHash are opaque commitments checked only for non-zero.

     Verified properties by reading the code, the vendored library and the shipped tests: registrations and approvals are bound to chainId and executor via the EIP-712 domain and, for approvals, again in the struct; struct type strings match the struct layouts and abi.encode of the value-only structs matches EIP-712 encoding; ECDSA rejects malleable s and non-65-byte signatures; nonces and all three generations only increase so no ABA re-validation exists; execute follows checks-effects-interactions and the only external calls in _validate go to the executor-deployed target; neither contract holds assets or has receive, fallback or delegatecall; modules run under STATICCALL with a 200k gas cap and 8192-byte input cap.

     Merged from audit_permissions and audit_economics.

     whole finding

     State for (2): attacker holds the recoveryOwner key. scheduleSignerRecovery(attackerSigner) at T; after recoveryDelay anyone calls finishSignerRecovery; clausSigner == attackerSigner and clausGeneration increments.

     Projects whose owners did not call setAuthority(id, m, false) within the window are then subject to approvals signed by the attacker, still gated by each project's minDelaySeconds.

     Exercised by the shipped test testRecoveryCannotRestoreOldSignatures and test/scratch/JudgeRepro.t.sol::testFinishIsPermissionlessAndFrontRunsLateCancel.

     whole reproduction
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,410 · transaction#1783agent 51142#442#912#1431