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

2 low6 info

• 1.lowSocialRegistry: a stale coin link (linker no longer the fee recipient) still counts in linkCount, so a legitimate link of the same handle on another coin is flagged duplicatelaunchpad/contracts/src/SocialRegistry.sol:159

          duplicate = handleHash != bytes32(0) && linkCount[handleHash] > 1;

  Since R3-A4-9 a coin's link shows only while linkedBy[coin] is still the coin's fee recipient (handleOf returns 0 otherwise), but the stale entry stays in _handleOf and in linkCount[handleHash] until somebody calls unlink. badgeOf computes duplicate from linkCount, and link emits Linked(..., n > 1) from the same counter, so a handle visibly linked to exactly one coin is reported as a duplicate (the badge shows its warning) as long as any stale link with the same handle hash exists.

  THREAT-MODEL invariant 19 / ARCHITECTURE 5.5 say a coin's link counts only while its linker is the recipient; the duplicate flag still counts it. Nothing in the protocol clears stale links; a stranger's permissionless unlink is the only way.

  No funds involved: a wrong, user-visible warning on a valid badge. Reported by four specialists (economics, math, flow, permissions); merged.

  Fix: count only live links, e.g. have link clear any stale link of the same handle it is told about (an optional address[] staleCoins argument that it unlinks first, only entries with linkedBy != recipientOf), or let the site/indexer compute duplicate from live links and document that linkCount includes stale links until cleared; alternatively have badgeOf treat the flag as advisory.

  whole finding

  Judge's scratch test test_staleLinkStillFlagsDuplicate and the attached proof (fails on this commit).

  Creator is fee recipient of coin1 and coin2 (CreatorVault.register by the curve).

  (1) creator calls social.link(coin1, H, deadline, voucher(coin1,H,creator,nonce 0)): badgeOf(coin1) = (H,false), linkCount[H] = 1.

  (2) creator calls vault.setRecipient(coin1, bob): badgeOf(coin1) = (0,false), handleOf(coin1) = 0, but linkCount[H] is still 1.

  (3) creator calls social.link(coin2, H, deadline, voucher(coin2,H,creator,0)).

  Expected: badgeOf(coin2) = (H, false), no other coin shows H.

  Actual: badgeOf(coin2) = (H, true), linkCount[H] = 2, and the Linked event for coin2 carries duplicate = true.

  (4) any address calls social.unlink(coin1): badgeOf(coin2) becomes (H, false), confirming the stale entry is the cause.

  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.26;
  
  import {Test} from "forge-std/Test.sol";
  import {CreatorVault} from "src/CreatorVault.sol";
  import {SocialRegistry} from "src/SocialRegistry.sol";
  
  contract StaleLinkDuplicateTest is Test {
      uint256 internal constant LINK_KEY = 0xB0B;
      CreatorVault internal vault;
      SocialRegistry internal social;
      address internal creator = makeAddr("creator");
      address internal newOwner = makeAddr("newOwner");
      address internal coin1 = makeAddr("coin1");
      address internal coin2 = makeAddr("coin2");
  
      function setUp() public {
          vm.warp(1_000_000);
          vault = new CreatorVault(makeAddr("imd"));
          vault.initialize(address(this), makeAddr("hook")); // this test plays the curve
          social = new SocialRegistry(address(this), address(vault), vm.addr(LINK_KEY));
          vault.register(coin1, creator);
          vault.register(coin2, creator);
      }
  
      function _voucher(address coin, bytes32 handle, address account, uint256 nonce, uint256 deadline)
          internal
          view
          returns (bytes memory)
      {
          bytes32 digest = keccak256(
              abi.encodePacked(
                  "\x19\x01",
                  social.domainSeparator(),
                  keccak256(abi.encode(social.LINK_TYPEHASH(), coin, handle, account, nonce, deadline))
              )
          );
          (uint8 v, bytes32 r, bytes32 s) = vm.sign(LINK_KEY, digest);
          return abi.encodePacked(r, s, v);
      }
  
      function test_staleLinkStillCountsAsDuplicate() public {
          bytes32 h = keccak256("frogdao");
          uint256 deadline = block.timestamp + 1 days;
          bytes memory v1 = _voucher(coin1, h, creator, 0, deadline);
          vm.prank(creator);
          social.link(coin1, h, deadline, v1);
          vm.prank(creator);
          vault.setRecipient(coin1, newOwner); // coin1's badge is gone (R3-A4-9)
          (bytes32 b1,) = social.badgeOf(coin1);
          assertEq(b1, bytes32(0), "coin1 shows no badge");
          bytes memory v2 = _voucher(coin2, h, creator, 0, deadline);
          vm.prank(creator);
          social.link(coin2, h, deadline, v2);
          (bytes32 b2, bool dup) = social.badgeOf(coin2);
          assertEq(b2, h);
          assertFalse(dup, "only coin2 shows this handle, so it is not a duplicate");
      }
  }

  whole proof

• 2.lowSocialRegistry: routing a coin's fees to its holders (recipient = the coin) removes its X badge at once and makes any future badge impossible; not documented as a consequence of D-52 / D-82launchpad/contracts/src/SocialRegistry.sol:78

          if (msg.sender != creatorVault.recipientOf(coin) || msg.sender == address(0)) revert Unauthorized();

  link requires msg.sender == creatorVault.recipientOf(coin) and handleOf shows a link only while linkedBy[coin] == recipientOf(coin). When a recipient routes the coin's fees to its holders with CreatorVault.setRecipient(coin, coin) (D-52, final since the coin contract never calls setRecipient), the recipient becomes the PadToken contract.

  PadToken only ever calls IMD and the PoolManager, so no account can ever satisfy the link check again: the badge the creator linked disappears immediately (linkedBy = creator != coin), anyone may clear the stale link, and neither the creator (who still controls the X account), the X link service nor the owner can link an X account to that coin. link has no verifier or owner path.

  The most holder-friendly routing choice permanently removes the coin's level-1 trust signal (D-12), and THREAT-MODEL section 3, ARCHITECTURE 5.2 / 5.5, D-52 and D-82 don't say so. No funds affected. Reported by two specialists (flow, permissions); merged.

  Fix: either document it (THREAT-MODEL section 3, site copy), or keep the last recipient's link valid once the recipient is the coin (e.g. in handleOf: when recipientOf(coin) == coin, return _handleOf[coin] while linkedBy[coin] is the account that routed the fees, recorded at setRecipient, and allow unlink of such a link only by the verifier or the owner), or let the verifier link on behalf of a holder-routed coin.

  whole finding

  Judge's scratch test test_holderRoutedCoinCanNeverLink.

  Creator is recipient of coin1.

  (1) creator calls social.link(coin1, H, deadline, voucher): badgeOf(coin1) = (H, false).

  (2) creator calls vault.setRecipient(coin1, coin1).

  Actual: badgeOf(coin1) and handleOf(coin1) return 0 at once; social.link(coin1, H, deadline, voucherFor(creator, nonces(coin1))) from the creator reverts Unauthorized(); the same from the owner with its own voucher reverts Unauthorized(); vault.recipientOf(coin1) == coin1 and PadToken has no code path that calls SocialRegistry.link, so the state is permanent; a stranger's unlink(coin1) clears the stale entry (linkCount -> 0).

  Expected: either the badge the recipient linked survives, or the consequence is documented as accepted behaviour.

  whole reproduction

• 3.infoSocialRegistry: the new fee recipient's own clear of a stale link it did not make consumes the coin nonce and voids the voucher it already holdslaunchpad/contracts/src/SocialRegistry.sol:110

          if (msg.sender == recipient || msg.sender == verifier || msg.sender == owner()) nonces[coin]++;

  R4-A4-6 keeps the nonce when a stranger clears a stale link so the voucher the new recipient obtained (signed over the current nonces[coin]) stays valid. The nonce is still bumped when the caller is the current recipient, whether or not the cleared link is its own.

  A new recipient that tidies the coin page by clearing the previous recipient's stale link before linking its own handle voids the voucher it is about to submit (BadVoucher) and must go through X OAuth and the wallet signature again. The bump protects nothing: the stale link belongs to an account that can no longer link, and the new recipient's vouchers are bound to its own address and need it as msg.sender.

  UX trap with a workaround (call link directly, which replaces the stale link).

  Fix: bump the nonce only when the cleared link is live or the caller is the verifier or the owner, e.g. if (msg.sender == verifier || msg.sender == owner() || linkedBy[coin] == msg.sender) nonces[coin]++; evaluated before delete linkedBy[coin].

  whole finding

  Judge's scratch test test_newRecipientClearingStaleLinkVoidsItsOwnVoucher.

  Creator links coin1 to keccak256('old') (nonces[coin1] 0 -> 1); creator calls vault.setRecipient(coin1, bob); bob holds voucher(coin1, keccak256('new'), bob, nonce 1, deadline). bob calls social.unlink(coin1) (allowed: linkedBy = creator != bob).

  Expected: nonces[coin1] stays 1 and bob's voucher works, as it does when a stranger clears the link.

  Actual: nonces[coin1] = 2 (msg.sender == recipient branch) and bob's social.link(coin1, keccak256('new'), deadline, voucher) reverts BadVoucher().

  whole reproduction

• 4.infoAttestationVerifier refuses an attestation whose issuedAt is seconds ahead of the chain clock; the protocol's reference consumer tolerates 5 minutes of attester clock driftlaunchpad/contracts/src/AttestationVerifier.sol:103

          if (block.timestamp < att.issuedAt) revert NotYetValid();

  The oracle stamps issuedAt with its own wall clock while block.timestamp is the sequencer's.

  The protocol's OracleAttestationConsumer._verifyAttestation (oracle-consumer reference, ISSUED_AT_TOLERANCE = 5 minutes) accepts issuedAt <= block.timestamp + 5 minutes for that reason. verifyBool has no tolerance, so a VersionRegistry.activate sent in the seconds after an attestation is issued reverts NotYetValid whenever the chain's clock trails the attester's; a resubmission once the block timestamp passes issuedAt succeeds (the validity window is hours wide).

  Liveness only, no security impact.

  Fix: if (att.issuedAt > block.timestamp + 5 minutes) revert NotYetValid(); (the reference's tolerance), and update test_verifier_acceptsGoodRejectsBad, which asserts the strict check at T0 + 1.

  Judge's scratch test test_issuedAtSecondsAheadRefused.

  Verifier with an approved signer; a correctly signed bool attestation for a question with issuedAt = block.timestamp + 30 and expiresAt = block.timestamp + 6 hours. verifier.verifyBool(att, sig, question) reverts NotYetValid(); after vm.warp(+30 s) the same call returns true.

  Expected per the reference consumer: accepted at once, since 30 s is inside the 5-minute tolerance.

• 5.infoVersionRegistry.setVerifier (and the constructor) accept address(0) or an address without code; activate and retireManualActivation then revert until another 7-day changelaunchpad/contracts/src/VersionRegistry.sol:159

          verifier = AttestationVerifier(verifier_);

  setVerifier (7-day timelock) stores any address. With address(0) or an address without code, every activate (which calls verifier.verifyBool) and retireManualActivation (which calls verifier.signerCount()) reverts with an empty revert until the owner sets a real verifier again, which takes another 7 days. Owner-only, no path for anyone else, no funds; manual activation keeps working until retired.

  Fix: if (verifier_.code.length == 0) revert ZeroAddress(); in setVerifier and the constructor.

  Judge's scratch test test_versionsSetVerifierZero.

  Owner calls versions.setVerifier(address(0)), registers version 1, then anyone calls versions.activate(1, job, att, sig) -> reverts (call to an address without code); owner calls versions.retireManualActivation() -> reverts; activateManually(1, link) still works.

  Expected: the setter refuses an address that is not a contract.

• 6.infoSocialRegistry.setVerifier and constructor accept address(0), silently disabling every linklaunchpad/contracts/src/SocialRegistry.sol:167

          verifier = verifier_;

  setVerifier (48 h timelock) and the constructor store any address. With address(0), _validSignature returns false for every voucher (if (signer == address(0)) return false;), so link and linkWallet revert BadVoucher until the owner sets a key again (another 48 h). AirdropDistributor's equivalent setter refuses address(0) (R4-A3-8); this one does not. Owner-only, no funds.

  Fix: if (verifier_ == address(0)) revert BadVoucher(); (or a dedicated error) in both places.

  Judge's scratch test test_socialSetVerifierZero.

  Owner executes social.setVerifier(address(0)).

  A fee recipient calling social.link(coin, h, deadline, voucherSignedByTheRealKey) reverts BadVoucher(); linkWallet likewise.

  Expected: the setter rejects address(0) as the airdrop's does.

• 7.infoVersionRegistry.register does not require code at the five addresses: a version can commit to the hash of empty accountslaunchpad/contracts/src/VersionRegistry.sol:76

          bytes32 h = codeHashOf(factory, router, curve, hook, lens);

  codeHashOf uses address.codehash, which is 0 for an empty account and keccak256("") for an account with a balance but no code. register only refuses address(0), so the 7-day owner can register a version whose code hash commits to no code (a typo'd or not-yet-deployed address), and the audit question built from it would name a meaningless hash. Owner-only and the registry is informational (R1-A4-16), so no onchain effect.

  Fix: refuse factory.code.length == 0 (and the other four) in register.

  Judge's scratch test test_registerAcceptsNoCode.

  Owner calls versions.register(makeAddr('typo'), d, d, d, d) with d a deployed contract.

  Actual: succeeds; versionInfo(n).codeHash == keccak256(abi.encode(bytes32(0), d.codehash, d.codehash, d.codehash, d.codehash)); after vm.deal(typo, 1 wei) a second register commits to keccak256('').

  Expected: revert, since a version must name deployed contracts.

• 8.infoUntested A4 guards: VersionRegistry replay (RequestUsed), AnswerNo, CannotRetire, setVerifier; SwarmBudget AboveMaxRequest, InsufficientBudget, RequestClosed, stranger cancel, setRelay / setMaxRequestlaunchpad/contracts/test/Governance.t.sol:475

      function test_versions_registerActivateAndRollback() public {

  The suite (186 tests, all passing on this commit) never exercises these guards: grep for RequestUsed, AnswerNo, CannotRetire, AboveMaxRequest, InsufficientBudget, RequestClosed, NotLinked, UnknownCoin, setGuardian, setMaxRequest, 'versions.setVerifier', 'vault.register' and 'budget.setRelay' in test/*.t.sol finds no file.

  In particular no test re-submits an accepted attestation, so a regression that moved the usedRequest write after the verifier call or keyed it on something other than att.requestId would pass the suite.

  The judge's scratch probes show all of them behave as intended on this commit (a second activate with the same attestation, for the same or another version, reverts RequestUsed; a 'no' reverts AnswerNo and leaves the request id free; a stranger's unlink of a live link reverts Unauthorized), so this is coverage only. Reported by two specialists (math, permissions); merged.

  whole finding

  Add to Governance.t.sol after a successful versions.activate(2, job, a, sig): vm.expectRevert(VersionRegistry.RequestUsed.selector); versions.activate(2, job, a, sig); and for a third registered version vm.expectRevert(VersionRegistry.RequestUsed.selector); versions.activate(3, job, a, sig); (both pass on this commit). Likewise assert Ownable.Unauthorized for a stranger on versions.setVerifier, budget.setRelay, budget.setMaxRequest, config.setGuardian, vault.register / credit / initialize; AboveMaxRequest after budget.setMaxRequest(1e18) on requestSpend(coin, 2e18, spec) by the recipient; RequestClosed on a second cancel; NotLinked on unlink of an unlinked coin; and badgeOf(...).duplicate after a stale link (see the Low finding above).

  whole reproduction

1. Posted33 minto the first attempt
2. Audit economicsAgent #759found 1 low, 1 info

   The findings file is in place at the repository root (excluded from git by the harness's own .git/info/exclude, as intended). Scratch test lives under test/scratch/, which is mine and not kept.

   Scope

   Files read in full: AttestationVerifier.sol, VersionRegistry.sol, SocialRegistry.sol, CreatorVault.sol, SwarmBudget.sol, PadConfig.sol, BondingCurve.sol, FixedOwnable.sol, PondPadTimelock.sol, PadToken.sol, script/Deploy.s.sol. Followed into PadFactory, PadHook (constructor, initialize, flush, permissions), IntegratorVault, MarketController.initialize, AirdropDistributor.initiate, FeeLib, PadMarketHook.getHookPermissions, OpenZeppelin TimelockController, Solady ECDSA, the oracle-consumer reference, Governance.t.sol, DeployFork.t.sol, DeployCreate2.t.sol. Full local suite: 186 passed, 0 failed.

   Severity counts: 0 Critical · 0 High · 0 Medium · 1 Low · 1 Info

   [L-1] Stale coin link still counts as a duplicate badge

   Location: launchpad/contracts/src/SocialRegistry.sol:159 (badgeOf) Root cause: After a recipient change the old link is hidden by handleOf, but it stays in linkCount until someone calls unlink. The duplicate flag reads linkCount. Reproduction: creator links handle H on coin1, calls setRecipient(coin1, newOwner), then links H on coin2. Expected badgeOf(coin2) = (H, false). Actual (H, true). Scratch test test_staleLinkStillCountsAsDuplicate fails on current code; proof included in the findings file. Fix: count only live links when computing duplicate, or clear a stale entry's count when it goes stale.

   [I-1] No tolerance on issuedAt

   Location: launchpad/contracts/src/AttestationVerifier.sol:103 The protocol's reference consumer accepts issuedAt up to 5 minutes ahead of the chain clock because the attester stamps with its wall clock. verifyBool reverts NotYetValid for 30 s of drift (scratch test confirms). Liveness only. Fix: compare against block.timestamp + 5 minutes.

   Invariants checked (THREAT-MODEL §2)

   • 16 held: approved signer only (Solady recoverCalldata reverts on bad signatures), exact rebuilt question hash, panel ≥ 51, agreed ≥ 2/3 as an exact fraction and ≥ quorum, validity window, fromBlock ≤ toBlock, request id consumed once in activate, window emitted. The EIP-712 type string matches the oracle-consumer reference field for field. The question text cannot inject or collide: job ids are restricted to [0-9A-Za-z-] ≤ 64 chars, addresses and hashes are hex, " and \ are refused.
   • 17 held: CreatorVault.register is reachable only through PadFactory.create, which deploys a fresh CREATE2 token each time, so no coin can be re-registered. setRecipient is the only mutator and only the current recipient passes; the coin itself can never call it.
   • 18 held: code hash from live bytecode at registration, forward-only activation above highestActivated, owner-only rollback and setCurrent, retire needs a signer.
   • 19 held: nonces consumed before signature check, deadline enforced, stranger clear leaves the nonce, badge hidden when linker ≠ recipient.
   • 22 held: every owner and role in Deploy.s.sol matches D-57 and the fork test; hook flags match both getHookPermissions (validated in the constructors); $PONDPAD mined above IMD; supply split 900M/50M/20M/30M with a zero-balance check; every _deployer initializer is one-shot including IntegratorVault.setSale; CREATE2 reuse is safe because the init code names the deployer.

   Observations (non-blocking)

   • PadConfig bounds are consistent: max total fee 450 bps plus max snipe tax 9,000 bps stays below 100%, so a completing buy cannot divide by zero.
   • PondPadTimelock correctly routes _schedule through the overridden getMinDelay; raising the delay and role self-administration are the accepted D-81 powers.
   • A recipient naming the vault, the swarm budget or another coin as recipient strands or lump-pays i

   ran onclaude · claude-fable-5-1 · 59 turns · 19m 33s · 482 in · 59.1K out · 2.9M cached

   submissioneeb4b2d6897f730ae2b51be2595eafd8a7099ceb4e964f54bd3a36eb029d7904

   device39da99ded7f125c89427cb189b1700d574bdf4e48c5bd0b800397b7cd53eab55

   started from3cd764f1e5efa603547c470bb68813b9b801f174

   bundlenone

   • lowSocialRegistry: a stale coin link (linker no longer the fee recipient) still counts in linkCount, so the same account's fresh link on another coin is flagged as a duplicatelaunchpad/contracts/src/SocialRegistry.sol:159

     Since R3-A4-9 a coin's link only shows while linkedBy[coin] is still the coin's fee recipient (handleOf returns 0 otherwise), but the stale entry is left in _handleOf and in linkCount[handleHash] until someone calls unlink. badgeOf computes duplicate from linkCount, so a handle that is visibly linked to exactly one coin is reported as a duplicate (the badge shows its warning) as long as any stale link with the same handle hash exists.

     The NatSpec promise is 'a handle linked to more than one coin is flagged'; here the handle is effectively linked to one. Anyone can clear the stale link with unlink(oldCoin), so the effect is a wrong badge until somebody does; no funds involved.

     Minimal fix: count only live links, e.g. in badgeOf (and handleOf) ignore stale entries, or have link and setRecipient-aware code decrement linkCount when the entry goes stale; simplest is to make badgeOf.duplicate read linkCount[handleHash] > 1 only after subtracting stale ones, or to clear the stale link inside link of any coin whose linkedBy != recipientOf before counting.

     whole finding

     State: coin1 and coin2 registered in CreatorVault with recipient = creator.

     1. creator calls social.link(coin1, H, deadline, voucher0) with a valid X-link voucher (nonce 0).

     2. creator calls vault.setRecipient(coin1, newOwner): badgeOf(coin1) now returns (0, false) as designed.

     3. creator calls social.link(coin2, H, deadline, voucher) (nonce 0 for coin2).

     Expected: badgeOf(coin2) = (H, false), since only coin2 shows H.

     Actual: badgeOf(coin2) = (H, true) because linkCount[H] is 2 (the stale coin1 entry still counts).

     After anyone calls social.unlink(coin1) the flag clears, which confirms the stale entry is the cause.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {CreatorVault} from "src/CreatorVault.sol";
     import {SocialRegistry} from "src/SocialRegistry.sol";
     
     contract StaleLinkDuplicateTest is Test {
         uint256 internal constant LINK_KEY = 0xB0B;
         CreatorVault internal vault;
         SocialRegistry internal social;
         address internal creator = makeAddr("creator");
         address internal newOwner = makeAddr("newOwner");
         address internal coin1 = makeAddr("coin1");
         address internal coin2 = makeAddr("coin2");
     
         function setUp() public {
             vm.warp(1_000_000);
             vault = new CreatorVault(makeAddr("imd"));
             vault.initialize(address(this), makeAddr("hook")); // this test plays the curve
             social = new SocialRegistry(address(this), address(vault), vm.addr(LINK_KEY));
             vault.register(coin1, creator);
             vault.register(coin2, creator);
         }
     
         function _voucher(address coin, bytes32 handle, address account, uint256 nonce, uint256 deadline)
             internal
             view
             returns (bytes memory)
         {
             bytes32 digest = keccak256(
                 abi.encodePacked(
                     "\x19\x01",
                     social.domainSeparator(),
                     keccak256(abi.encode(social.LINK_TYPEHASH(), coin, handle, account, nonce, deadline))
                 )
             );
             (uint8 v, bytes32 r, bytes32 s) = vm.sign(LINK_KEY, digest);
             return abi.encodePacked(r, s, v);
         }
     
         function test_staleLinkStillCountsAsDuplicate() public {
             bytes32 h = keccak256("frogdao");
             uint256 deadline = block.timestamp + 1 days;
             bytes memory v1 = _voucher(coin1, h, creator, 0, deadline);
             vm.prank(creator);
             social.link(coin1, h, deadline, v1);
             vm.prank(creator);
             vault.setRecipient(coin1, newOwner); // coin1's badge is gone (R3-A4-9)
             (bytes32 b1,) = social.badgeOf(coin1);
             assertEq(b1, bytes32(0), "coin1 shows no badge");
             bytes memory v2 = _voucher(coin2, h, creator, 0, deadline);
             vm.prank(creator);
             social.link(coin2, h, deadline, v2);
             (bytes32 b2, bool dup) = social.badgeOf(coin2);
             assertEq(b2, h);
             assertFalse(dup, "only coin2 shows this handle, so it is not a duplicate");
         }
     }

     whole proof

   • infoAttestationVerifier refuses an attestation whose issuedAt is seconds ahead of the chain clock; the protocol's reference consumer tolerates 5 minutes of attester clock driftlaunchpad/contracts/src/AttestationVerifier.sol:103

     The oracle stamps issuedAt with its own wall clock while block.timestamp is the sequencer's.

     The protocol's OracleAttestationConsumer._verifyAttestation (oracle-consumer reference) accepts issuedAt <= block.timestamp + 5 minutes for that reason. verifyBool has no tolerance, so a VersionRegistry.activate sent in the seconds after an attestation is issued reverts NotYetValid whenever the chain's clock trails the attester's; a resubmission once the block timestamp passes issuedAt succeeds, since the validity window is hours wide.

     Liveness only, no security impact.

     Fix: if (att.issuedAt > block.timestamp + 5 minutes) revert NotYetValid(); (the reference's ISSUED_AT_TOLERANCE).

     Verifier with an approved signer; a correctly signed bool attestation for a question with issuedAt = block.timestamp + 30 and expiresAt = block.timestamp + 6 hours. verifier.verifyBool(att, sig, question) reverts NotYetValid() (scratch test test_verifierRefusesAnAttestationIssuedSecondsAhead passes with that expectRevert). Expected per the reference consumer: accepted, since 30 s is inside the 5-minute tolerance.

3. Audit permissionsAgent #158found 1 low, 5 info

   The review is complete and the findings file is written and validated against the tree.

   Result: no Critical, High or Medium in area A4. One Low and five Info findings are in .imd-findings.json, each with a concrete input and expected-versus-actual. The build and the full local suite ran here (186 tests, all passing), and my scratch probes in launchpad/contracts/test/scratch/A4Probe.t.sol confirm each reported behaviour and show the untested guards behave correctly.

   Findings

   • Low, SocialRegistry line 78. Routing a coin's fees to its holders makes the PadToken the recipient, so link can never be satisfied again. The coin's X badge disappears for good and nobody, not the creator, the X link key or the owner, can relink one. Not documented anywhere as an accepted consequence.
   • Info, SocialRegistry line 159. A stale link still counts in linkCount, so a second coin linking the handle is flagged duplicate while no coin shows it, until someone clears the stale entry.
   • Info, VersionRegistry line 159 and SocialRegistry line 167. Both setVerifier setters accept address zero or a code-less address. In the registry that makes activate and retireManualActivation revert for a 7-day cycle. Owner-only.
   • Info, VersionRegistry line 76. register accepts addresses without code, so a version can carry a code hash of empty accounts. Owner-only, informational registry.
   • Info, Governance tests line 454. Several guards in the area have no failing-input test: reused request id, "no" answer, retire without signer, SwarmBudget request bounds and stranger cancel, CreatorVault stranger guards, SocialRegistry NotLinked and a stranger's unlink of a live link.

   What I checked and found sound

   • Invariant 16: signer, exact rebuilt question hash, panel floor, exact two-thirds fraction, quorum, validity window, window order and single use all hold. The question text is unambiguous (job id charset restricted, fixed separators, hex fields of fixed length) and JSON injection is blocked by the printable-ASCII rule. The evidence chain id is still unpinned, which is the known open part of R2-A4-4.
   • Invariants 17 (retired rule), 18, 19 and 22: recipientOf has only two writers, the curve's register on a fresh CREATE2 coin and the recipient's own setRecipient, and holder routing is final. Forward-only activation above the highest ever activated, owner-only rollback, nonce consumption and stale-link handling all match the ledger. Every FixedOwnable and PondPadTimelock claim holds against OpenZeppelin 5.0.2, where _schedule reads the overridden getMinDelay.
   • Deploy: every constructor argument order, owner, role, amount and address matches D-57 and THREAT-MODEL section 1. Both hooks validate their flags in the constructor and refuse outside pool initialization, CREATE2 reuse is safe because the address commits to the init code, launches stay paused until fee routing is final, and the airdrop checks count distinct non-zero wallets as P5-3 states. Nothing stays with the deployer.
   • Earlier fixes in this area (R1-A4-6, R1-A4-13, R1-A4-14, R2-A4-4, R3-A4-4, R3-A4-5, R3-A4-6, R3-A4-9, R3-A4-11, R3-A4-12, R4-A4-6, P5-3) are each correct and complete, with their regression tests present and passing.

   Not run: fork tests (no network use was needed for this area) and any static analyser.

   ran onclaude · claude-fable-5-1 · 46 turns · 24m 16s · 450 in · 62.2K out · 3.5M cached

   submissiond3977964aba4a6e4ba60671b1893c5cd99ab0e637b5c35950d362291082aa607

   device0e3b71e2ffcd200ba549914774d84233f9b103c5a0c25615caef3d52db60e7d9

   started from3cd764f1e5efa603547c470bb68813b9b801f174

   bundlenone

   • lowSocialRegistry: a coin whose fees are routed to its holders loses its X badge for good and can never link one againlaunchpad/contracts/src/SocialRegistry.sol:78

     link requires msg.sender == creatorVault.recipientOf(coin) and handleOf reports a link only while linkedBy[coin] == recipientOf(coin) (R3-A4-9). When a recipient routes the coin's fees to its holders with CreatorVault.setRecipient(coin, coin) (D-52, final since the coin contract never calls setRecipient), the recipient becomes the PadToken contract itself.

     PadToken only ever calls IMD and the PoolManager, so no account can ever satisfy the link check again: the existing badge disappears (badgeOf returns 0, anyone may clear the stale link) and no X account can be linked to that coin, by the creator who still controls the X account, by the X link service or by the owner.

     The one routing choice THREAT-MODEL and D-52 present as the most holder-friendly permanently removes the coin's level-1 trust signal (D-12), and nothing in THREAT-MODEL §3, ARCHITECTURE §5.5 or DECISIONS says so. No funds are affected.

     If this is wanted, document it in THREAT-MODEL §3 and the site copy; otherwise let the badge survive holder routing, e.g. keep handleOf valid while linkedBy[coin] is the account that was the recipient when it routed to holders (record it in CreatorVault.RecipientChanged / a routedBy mapping) or allow the verifier to link on behalf of a holder-routed coin.

     whole finding

     Scratch test run on this commit (launchpad/contracts/test/scratch/A4Probe.t.sol, test_probe_holderRoutedCoinCanNeverHaveABadge): launch a coin (recipient = creator); creator calls social.link(coin, keccak256("frogcoin"), deadline, voucher) -> badgeOf(coin) = the handle.

     Creator calls vault.setRecipient(coin, coin).

     Actual: badgeOf(coin) and handleOf(coin) return 0; social.link(coin, h, deadline, voucherFor(creator, nonces(coin))) from the creator reverts Unauthorized(); the same from any other wallet with its own voucher reverts Unauthorized(); vault.recipientOf(coin) == coin, and PadToken has no code path that calls SocialRegistry.link, so the state is permanent.

     Expected: either the coin keeps a verified handle or the consequence is a documented, accepted behaviour.

     whole reproduction

   • infoSocialRegistry: stale links keep counting in linkCount, so another coin linking the handle is flagged duplicate while no coin shows itlaunchpad/contracts/src/SocialRegistry.sol:159

     linkCount[handle] is decremented only in unlink / on relink. After a coin's recipient changes, its link is stale (handleOf returns 0, the badge is gone, R3-A4-9) but still counted. A second coin that links the same handle is then reported duplicate = true by badgeOf and in the Linked event although it is the only coin showing that handle.

     The wrong warning stays until someone calls unlink on the stale coin, which anyone may do (R4-A4-6), so the harm is a misleading badge warning, not a loss.

     Fix: in badgeOf / link, count only live links (e.g. decrement linkCount when handleOf turns stale is impossible without a hook, so instead have link clear a stale entry it finds for the same handle, or compute duplicate from live links in the lens/indexer).

     Scratch test on this commit (test_probe_staleLinkKeepsTheDuplicateFlag): creator links handle H to coin A, then vault.setRecipient(A, alice). badgeOf(A) returns (0, false) but linkCount(H) == 1.

     Creator (still the X account's owner, and recipient of coin B) links H to coin B.

     Actual: badgeOf(B) returns (H, duplicate = true).

     Expected: duplicate = false, since no other coin shows H.

     After unlink(A) by a stranger, badgeOf(B) returns (H, false).

   • infoVersionRegistry.setVerifier accepts address(0) or an address without code; activate and retireManualActivation then revertlaunchpad/contracts/src/VersionRegistry.sol:159

     setVerifier (7-day timelock) stores any address. With address(0) or an address without code, every activate (which calls verifier.verifyBool) and retireManualActivation (which calls verifier.signerCount()) reverts with an empty revert until the owner sets a real verifier again, which takes another 7 days. The constructor has the same gap.

     Owner-only, no path for anyone else, no funds; a one-line if (verifier_.code.length == 0) revert ZeroAddress(); would stop a mis-encoded proposal from disabling attested activation for a week.

     Scratch test on this commit (test_probe_versionRegistryUntestedPaths): owner calls versions.setVerifier(address(0)), registers version 2, then anyone calls versions.activate(2, job, att, sig) -> reverts (call to an address without code); owner calls versions.retireManualActivation() -> reverts. Expected: the setter refuses an address that is not a contract.

   • infoSocialRegistry.setVerifier and constructor accept address(0), silently disabling every linklaunchpad/contracts/src/SocialRegistry.sol:167

     setVerifier (48 h timelock) and the constructor store any address. With address(0), _validSignature returns false for every voucher (if (signer == address(0)) return false;), so link and linkWallet revert BadVoucher until the owner sets a key again (another 48 h). AirdropDistributor's equivalent setter refuses address(0) (PRECHECK-5 §2, R4-A3-8); this one does not. Owner-only, no funds.

     Fix: if (verifier_ == address(0)) revert BadVoucher(); (or a dedicated error) in both places.

     Owner (48 h timelock) executes social.setVerifier(address(0)).

     Any fee recipient calling social.link(coin, h, deadline, voucherSignedByTheRealKey) reverts BadVoucher(); linkWallet likewise.

     Expected: the setter rejects address(0) as the airdrop's does.

   • infoVersionRegistry.register does not require code at the five addresses: a version can carry the hash of empty accountslaunchpad/contracts/src/VersionRegistry.sol:76

     codeHashOf uses address.codehash, which is 0 for an empty account and keccak256("") for an account with a balance but no code. register only refuses address(0), so the 7-day owner can register a version whose code hash commits to no code (a typo'd or not-yet-deployed address), and an attestation question would then name that hash. Owner-only and the registry is informational (R1-A4-16), so no onchain effect; but the audit question built from it would be meaningless.

     Fix: if (factory.code.length == 0 || ...) revert ZeroAddress(); (or a NoCode error) in register.

     Owner calls versions.register(makeAddr("typo"), router, curve, hook, lens).

     Actual: succeeds; versionInfo(n).codeHash == keccak256(abi.encode(bytes32(0), router.codehash, curve.codehash, hook.codehash, lens.codehash)).

     Expected: revert, since a version must name deployed contracts.

   • infoUntested A4 paths: reused request id, 'no' answer, retire without a signer, SwarmBudget request bounds and stranger cancel, CreatorVault guards, SocialRegistry NotLinked and live-link unlink by a stralaunchpad/contracts/test/Governance.t.sol:454

     The suite (186 tests, all passing here) never exercises these guards in the area: VersionRegistry.activate with a reused request id (RequestUsed), with a 'no' answer (AnswerNo), for an unregistered version (UnknownVersion through question), retireManualActivation without a signer (CannotRetire), setVerifier; SwarmBudget.requestSpend above maxRequest (AboveMaxRequest) or above the available budget (InsufficientBudget), cancel / release on a closed request (RequestClosed), cancel by a stranger while the recipient is not the coin (must revert), release by a non-relay, setMaxRequest; CreatorVault.register / credit / initialize from a stranger, fundHolders for an unknown coin (UnknownCoin); SocialRegistry.unlink of a coin with no link (NotLinked) and a stranger's unlink of a live link (must revert Unauthorized); PadConfig.setGuardian.

     The scratch test test/scratch/A4Probe.t.sol (probes 3 and 4) shows all of them behave as intended on this commit, so this is coverage, not a defect. Invariants 16, 18 and 19 would be guarded by regression tests for them.

     whole finding

     grep -rl RequestUsed launchpad/contracts/test/*.t.sol (and AnswerNo, CannotRetire, AboveMaxRequest, InsufficientBudget, UnknownCoin, RequestClosed, NotLinked, setGuardian, setMaxRequest, 'versions.setVerifier', 'vault.register') returns no file. Expected: at least one failing-input test per guard.

4. Audit flowAgent #1212found 1 low, 1 info

   The review is complete. The findings file holds two substantiated items, both minor, and the area otherwise held up.

   Outcome: no Critical, High or Medium in area A4. The local suite passes (186 tests). Every round 1 to 4 fix marked fixed for this area is in the code with its regression test, and I found no new path through any of them.

   Findings written to .imd-findings.json:

   • Low, SocialRegistry duplicate flag. A stale coin link (its linker no longer the fee recipient) still counts in the per-handle link count. When the same X account is then linked to another coin, that coin's badge is flagged as a duplicate although the stale coin reports no badge at all. The warning stays until anyone clears the stale link. Reproduced with a scratch test that prints the count and the flag.
   • Info, holder-routed coins and badges. Routing a coin's fees to its holders removes its X badge at once and makes any future badge impossible, since only the recipient can link and the recipient is now the coin contract. The rule producing this is in invariant 19, but the consequence is not listed in D-52, D-82 or the architecture. Reproduced with a scratch test.

   What I checked and found sound:

   • Attestation binding: question text is built onchain from the version number, chain id, code hash, five addresses and a job id restricted to letters, digits and hyphens. No quote, backslash or control character can reach the JSON, so no two inputs collide and no field can be injected. Request ids are consumed once per consumer and the EIP-712 domain binds the verifier and chain, confirmed by the live attestation test.
   • CreatorVault: after the takeover removal, the only writers of a recipient are the curve at launch and the current recipient. Holder routing through claim, fundHolders and sweepToHolders goes into the coin's time-weighted stream with consistent accounting.
   • VersionRegistry forward-only activation and rollback; SocialRegistry nonces, deadlines and the stranger-clear rule; PadConfig bounds and the owner versus guardian split; FixedOwnable's single handoff; PondPadTimelock's floor on its delay through the overridden delay getter.
   • Deploy: every owner, role and amount matches D-57 and the threat model's actor table (D-17, D-21, D-44, D-47, D-84 constants included). All deployer-gated functions are one-time initializers consumed in the run, hook flags match both permission tables, CREATE2 reuse only accepts identical init code, and the airdrop list check counts distinct non-zero wallets.
   • Invariants checked: 6 (holder stream parts), 16, 17 (retired, rule still holds), 18, 19, 22.

   Known items left open as documented: the evidence chain id pin on version attestations waits on the user's decision, and the timelock's self-administration is accepted under D-81. The scratch tests live under launchpad/contracts/test/scratch/ and are not part of the submission.

   ran onclaude · claude-fable-5-1 · 58 turns · 25m 48s · 612 in · 69.3K out · 4.2M cached

   submissionc175c32f5d0bdea507f7208c01894a4aa6f02d64436bf85ccbf2ab0be6c4c93a

   deviced11ea2b5e05fa7a87b4f93104e21f0e5d0435f2c729f01357ac11d3d92dc5d69

   started from3cd764f1e5efa603547c470bb68813b9b801f174

   bundlenone

   • lowSocialRegistry: a stale coin link (linker no longer the fee recipient) keeps counting in linkCount, so badgeOf flags a legitimate badge on another coin as duplicatelaunchpad/contracts/src/SocialRegistry.sol:159

     handleOf and badgeOf report nothing for a coin once the account that linked it is no longer the fee recipient (R3-A4-9), but linkCount[handle] is only decremented in unlink. A link that handleOf already treats as gone therefore still counts as a live link of that handle.

     When the same X account is then linked, legitimately, to another coin, badgeOf(thatCoin) returns duplicate = true (the badge shows the 'handle linked to more than one coin' warning) although badgeOf of the stale coin returns no handle at all. The two views disagree about whether the stale coin 'links' the handle.

     The warning stays until anyone calls the permissionless unlink on the stale coin; nothing in the protocol does that automatically, and the new linker cannot clear it inside link. Not a fund-safety issue: a wrong, user-visible duplicate warning on a valid badge.

     Fix options: (a) in handleOf/badgeOf, treat the flag as 'linkCount > 1 among live links' is not computable without enumeration, so instead have link() on any coin first clear that coin's own stale link (already done implicitly) and document that a stale link of another coin counts until cleared; or (b) let link() accept an optional list of stale coins to clear in the same call; or (c) simplest and exact: decrement linkCount in handleOf-consistent terms by making badgeOf skip the flag when linkCount[h] - staleCount[h] <= 1, where unlink by a stranger already is the only way to drop a stale link, so (a)/(b) plus a frontend keeper that calls unlink on stale links is the practical fix.

     Verified with the scratch test below (prints linkCount 2 and duplicate true).

     whole finding

     Creator C is fee recipient of coin1 and coin2 (CreatorVault.register by the curve).

     1. C calls SocialRegistry.link(coin1, H, deadline, voucher(coin1,H,C,nonce 0)) -> badgeOf(coin1) = (H,false), linkCount[H] = 1.
     2. C calls CreatorVault.setRecipient(coin1, safe). Now badgeOf(coin1) = (0,false) and handleOf(coin1) = 0 (stale).
     3. C calls SocialRegistry.link(coin2, H, deadline, voucher(coin2,H,C,0)). Expected: badgeOf(coin2) = (H, false), since no other coin shows H as its badge. Actual: badgeOf(coin2) = (H, true) because linkCount[H] = 2 counts coin1's stale link. Scratch test test/scratch/SocialProbe.t.sol::test_staleLinkStillFlagsDuplicate logs linkCount 2, duplicate true.

     whole reproduction

   • infoRouting a coin's fees to its holders (recipient = the coin) removes its X badge at once and makes any future badge impossible; not listed among the consequences of D-52/D-82launchpad/contracts/src/SocialRegistry.sol:78

     link requires msg.sender == CreatorVault.recipientOf(coin) and handleOf shows a link only while linkedBy[coin] is still the recipient. After the recipient names the coin itself (fees to holders, final by design), recipientOf(coin) == coin: the coin contract never calls link, so the badge the creator linked disappears immediately (linkedBy = creator != coin) and no account can ever link an X account to that coin again.

     A creator who takes the pro-community step of routing fees to holders therefore loses the coin's verified X badge for good, and anyone may clear the stale link. THREAT-MODEL invariant 19 states the rule that produces this, but D-52, D-82, ARCHITECTURE §5.2 and the badge docs do not mention that holder-routed coins can never carry a badge. If this is intended, document it (THREAT-MODEL §3 / ARCHITECTURE).

     If not, keep the last recipient's link valid once the recipient is the coin (e.g. in handleOf: if (recipient == coin) return linkedBy[coin] != address(0) ? _handleOf[coin] : 0; and allow unlink of such a link only by the verifier or the owner), since nobody else can ever become the recipient and the link was made by the account that was the recipient at the time.

     whole finding

     Creator C is recipient of coin1.

     1. C links handle H to coin1: badgeOf(coin1) = (H, false).
     2. C calls CreatorVault.setRecipient(coin1, coin1) (fees to holders, final). Actual: badgeOf(coin1) = (0, false) at once; C (or anyone) calling SocialRegistry.link(coin1, H, ...) reverts Unauthorized() for ever, since recipientOf(coin1) == coin1 and the coin contract never calls link. Expected (if the badge is meant to survive): the badge C linked while recipient stays shown. Scratch test test/scratch/SocialProbe.t.sol::test_holderRoutedCoinCannotLink.

     whole reproduction
5. Audit mathAgent #1188found 1 low, 2 info

   The review is complete. The findings file is in the repository root (git lists it as ignored by a global rule, which is why it did not appear in the short status), the scratch tests are removed, and no contract or configuration file was changed.

   Outcome. Area A4 is clean of Critical, High and Medium defects at this commit. I recorded one Low and two Info findings in .imd-findings.json. No finding needs a Foundry proof file (none is Critical or High).

   What I checked, and how

   • Read all eleven files in the area in full, plus the contracts they call into (FeeLib, PadHook, PadFactory, PadRouter's launch path, IntegratorVault, FeeSplitter, GrowthFund, WorkerFund, LiquidityReserve, TeamVesting, PondPadToken, the constructors of MarketController, PadMarketHook, PadSale, RewardDripper, AirdropDistributor, PadBuyer), the OpenZeppelin 5.0.2 TimelockController, and the Solady helpers (Ownable, ECDSA, EIP712, SignatureCheckerLib, SafeTransferLib, LibString).
   • Ran the full local suite (186 tests pass) and the mainnet-fork deployment rehearsal (4 tests pass against live Robinhood Chain).
   • Wrote and ran scratch probes, then deleted them: a 512-run fuzz of the holder-stream math (fund, warp, transfer, claim sequences: conservation holds, a settled running stream always ends in the future), a curve completing buy at the maximum tax and maximum snipe tax (net lands within 1 wei of the target, no division by zero), a 20-wei buy at those bounds, the VersionRegistry replay guard (second submission reverts, compact signatures accepted), the version question's length (558 characters with a 64-character job id, inside the 2,000 limit), and the airdrop list checks.
   • Every round-1 to round-4 fix marked fixed for this area closes its path: forward-only activation, exact-fraction agreement, inverted window, FixedOwnable handoff, the delay floor, nonce consumption on revocations, the stale-badge rule, the stranger's clear, the 100-wallet and distinct-wallet checks, launches paused during the run, CREATE2 reuse, the time-weighted stream.

   Invariants checked: 1 (curve rounding favours the curve), 5, 6 (holder stream), 16 (attestation binding: question text includes version, chain id, job id, code hash and the five addresses; job ids cannot carry quotes; request ids used once), 17 (only the recipient changes a recipient; routing to the coin is final), 18, 19, 20 (deploy list checks), 22 (every owner, role, address and amount in Deploy matches D-57 and THREAT-MODEL section 1; nothing stays with the deployer; hook flags match both hooks' permissions; no ordering bug).

   Findings

   • Low, SocialRegistry line 159. A stale coin link that R3-A4-9 hides is still counted in the per-handle counter, so another coin linked to the same handle is flagged duplicate until some stranger clears the stale link. Wrong warning badge only.
   • Info, SocialRegistry line 110. A new recipient that clears the previous recipient's stale link itself consumes the coin nonce and voids its own pending voucher. Self-inflicted, with a workaround.
   • Info, Governance.t.sol line 475. Coverage gaps: the replay guard, setVerifier, SwarmBudget's two setters, setGuardian and the duplicate flag across a stale link are never asserted.

   Not done. The twelve specialty guides were applied as review passes by one reviewer, not as separate agents. Fork tests other than the deployment rehearsal were not rerun.

   ran onclaude · claude-fable-5-1 · 80 turns · 46m 30s · 742 in · 100.5K out · 7.6M cached

   submission0f8ce6bff3f282aac80ba192c942d8e2da118212a4cd8e69dc9e0e9faef2aac4

   devicebe3be4cc237417f9b8b7b48f12d810fbe5c66335e939dfe0c91bb2aeb27d673f

   started from3cd764f1e5efa603547c470bb68813b9b801f174

   bundlenone

   • lowSocialRegistry: a stale (hidden) coin link still counts in linkCount, so another coin on the same handle is flagged duplicate until anyone clears it (R3-A4-9 fix incomplete for the flag)launchpad/contracts/src/SocialRegistry.sol:159

     R3-A4-9 made a coin's link count only while the account that made it is still the fee recipient: handleOf / badgeOf return nothing once linkedBy[coin] != recipientOf(coin).

     The per-handle counter was not given the same rule. link does ++linkCount[handleHash] (line 89) and only unlink decrements it, so a link that is already stale and invisible keeps counting. badgeOf of every other coin linked to that handle then reports duplicate = true (the site's warning badge), and Linked(..., n > 1) emits duplicate = true for the new link, although the registry itself no longer shows the stale coin's badge.

     The stale link is only removed when somebody calls unlink(staleCoin) (permissionless for stale links), which nothing in the protocol triggers. THREAT-MODEL invariant 19 and ARCHITECTURE 5.5 say a coin's link counts only while its linker is the recipient; the duplicate flag still counts it.

     No funds involved: a wrong warning on a badge.

     Fix: either prune when linking (in link, nothing can enumerate stale links cheaply, so) keep the counter but have badgeOf / the site treat duplicate as advisory and have a keeper clear stale links, or store per handle the set of linking coins and count only those whose linkedBy is still the recipient, or add a permissionless clearStale(address[] coins) the site calls before showing the flag and document that linkCount includes stale links until cleared.

     whole finding

     Scratch test (run on this commit, passes = behaviour present): creator is the fee recipient of coins A and B.

     (1) creator calls social.link(A, keccak256('samehandle'), deadline, voucherA): linkCount = 1.

     (2) creator calls vault.setRecipient(A, other): badgeOf(A) now returns (0x0, false) as R3-A4-9 intends.

     (3) creator calls social.link(B, keccak256('samehandle'), deadline, voucherB).

     Expected: badgeOf(B) = (keccak256('samehandle'), false), since the only other link to the handle is stale and no longer shown.

     Actual: linkCount = 2 and badgeOf(B) = (keccak256('samehandle'), true); the Linked event for B carries duplicate = true.

     (4) any address calls social.unlink(A): badgeOf(B) becomes (hash, false).

     The flag depends on whether a stranger has bothered to clear the stale link.

     whole reproduction

   • infoSocialRegistry: the new fee recipient's own clear of a stale link it did not make consumes the coin nonce and voids the voucher it already holdslaunchpad/contracts/src/SocialRegistry.sol:110

     R4-A4-6 keeps the nonce when a stranger clears a stale link, so the voucher the new recipient obtained (signed over the current nonces[coin]) stays valid. The nonce is still consumed when the caller is the current recipient, whether or not the cleared link is its own.

     A new recipient that tidies the coin page by clearing the previous recipient's stale link before linking its own handle therefore voids the voucher it is about to submit (BadVoucher) and must go through X OAuth and the wallet signature again. Nothing is protected by that bump: the stale link belongs to an account that can no longer link, and the new recipient's own vouchers are bound to its own address.

     Severity Info: a UX trap with a documented workaround (call link directly, which replaces the stale link).

     Fix: bump the nonce only when the cleared link is a live one (linkedBy[coin] == recipient) or the caller is the verifier or the owner, i.e. if (msg.sender == verifier || msg.sender == owner() || linkedBy[coin] == msg.sender) nonces[coin]++; evaluated before delete linkedBy[coin].

     whole finding

     Scratch test (run on this commit): creator links coin to keccak256('old') (nonces[coin] 0 -> 1); creator calls vault.setRecipient(coin, bob); bob holds a voucher for (coin, keccak256('new'), bob, nonce 1, deadline). bob calls social.unlink(coin) (allowed: linkedBy = creator != bob).

     Expected: nonces[coin] stays 1 and bob's voucher works, as it does when a stranger clears the link.

     Actual: nonces[coin] = 2 (msg.sender == recipient branch) and bob's social.link(coin, keccak256('new'), deadline, voucher) reverts BadVoucher.

     whole reproduction

   • infoUntested governance edges: VersionRegistry replay guard (RequestUsed) and setVerifier, SwarmBudget setRelay / setMaxRequest, PadConfig setGuardian, the duplicate flag across a stale linklaunchpad/contracts/test/Governance.t.sol:475

     The suite never re-submits an accepted attestation, so VersionRegistry.activate's replay guard (usedRequest, RequestUsed) is not exercised by any test (grep for RequestUsed in test/ finds nothing); a regression that moved the usedRequest write after the verifier call, or keyed it on something other than att.requestId, would pass the suite.

     Also untested: VersionRegistry.setVerifier (owner only, and that activate then uses the new verifier), SwarmBudget.setRelay / setMaxRequest (owner only; a lowered maxRequest refuses larger requests), PadConfig.setGuardian (owner only; the old guardian loses setLaunchesPaused / setIntegrator), and badgeOf(...).duplicate when one of the links is stale.

     Verified by a scratch test on this commit that the replay guard does work (a second activate with the same attestation, for the same or another version, reverts RequestUsed, and the 64-byte compact signature form is accepted); this item is coverage only.

     whole finding

     Add to Governance.t.sol after a successful versions.activate(2, job, a, sig): vm.expectRevert(VersionRegistry.RequestUsed.selector); versions.activate(2, job, a, sig); and, for a third registered version, vm.expectRevert(VersionRegistry.RequestUsed.selector); versions.activate(3, job, a, sig); (both pass on this commit). Likewise assert Ownable.Unauthorized for a stranger on versions.setVerifier, budget.setRelay, budget.setMaxRequest, config.setGuardian, and that after budget.setMaxRequest(1e18) a requestSpend(coin, 2e18, spec) by the recipient reverts AboveMaxRequest.

     whole reproduction
6. Audit judgeAgent #1299found 2 low, 6 info

   The review is complete. The findings file .imd-findings.json is in the repository root with 8 findings, and the tree is otherwise clean (the file is gitignored, so git status shows nothing; the scratch tests were removed).

   Verdict for A4: no Critical, no High, no Medium. Every specialist finding reproduced against the code; I merged the duplicates and kept 2 Low and 6 Info.

   Kept findings

   • Low, stale link keeps counting. A coin link whose linker is no longer the fee recipient is hidden by badgeOf but still counted in linkCount, so the same handle linked legitimately to another coin is flagged duplicate until a stranger clears it. Four specialists reported it; the attached proof fails on this commit for exactly that reason.
   • Low, holder routing kills the badge forever. Once a recipient routes fees to the coin itself, nobody can ever satisfy the link check again, since PadToken never calls the registry. The existing badge disappears at once. Not stated in THREAT-MODEL, ARCHITECTURE, D-52 or D-82.
   • Info, recipient's clear bumps the nonce. A new recipient tidying away the old recipient's stale link voids the voucher it already holds. A stranger's clear does not.
   • Info, no issuedAt drift tolerance. The verifier rejects an attestation issued seconds ahead of the chain clock. The protocol's reference consumer allows 5 minutes. Liveness only.
   • Info, three missing setter checks. VersionRegistry.setVerifier and register accept addresses without code; SocialRegistry.setVerifier accepts address zero. All owner-only, all recoverable after another timelock delay.
   • Info, coverage. None of the listed guards appear in any test (confirmed by grep). My probes show they all work.

   Dropped or rejected: nothing. All specialist items reproduced.

   What I checked and found sound. Attestation binding: the question embeds the version, chain id, job id, code hash and five addresses; the job id charset excludes quotes, backslashes and spaces, so no injection or ambiguity; a window or struct tamper breaks the signature; a reused request id reverts even when pointed at another version; a "no" leaves the id free. Forward-only activation and rollback behave per invariant 18. CreatorVault has no path for anyone but the current recipient to change a recipient or take fees; holder routing goes only through the coin's stream. Deploy.s.sol matches D-57 on every owner, role, address and amount; constructor argument orders match the sources; every initializer is one-shot, so the deployer keeps nothing; hook flags match the permission tables; the airdrop checks sort and deduplicate wallets before the 100 count. FixedOwnable and PondPadTimelock do what they claim.

   Invariants checked: 16, 17 (retired, confirmed no path), 18, 19, 22. The full suite passed with 186 tests before my probes.

   ran onclaude · claude-fable-5-1 · 40 turns · 17m 24s · 386 in · 38.7K out · 2.1M cached

   submissiona3f3d57455dc10b1ca9a36b491baf4e7fb017ca39dcb15098baf036585d06c6f

   device98b4506bef931d13cb913bf855d8360596e9aceab2a590f8f5b165a483e76a95

   started from3cd764f1e5efa603547c470bb68813b9b801f174

   bundlenone

   • lowSocialRegistry: a stale coin link (linker no longer the fee recipient) still counts in linkCount, so a legitimate link of the same handle on another coin is flagged duplicatelaunchpad/contracts/src/SocialRegistry.sol:159

     Since R3-A4-9 a coin's link shows only while linkedBy[coin] is still the coin's fee recipient (handleOf returns 0 otherwise), but the stale entry stays in _handleOf and in linkCount[handleHash] until somebody calls unlink. badgeOf computes duplicate from linkCount, and link emits Linked(..., n > 1) from the same counter, so a handle visibly linked to exactly one coin is reported as a duplicate (the badge shows its warning) as long as any stale link with the same handle hash exists.

     THREAT-MODEL invariant 19 / ARCHITECTURE 5.5 say a coin's link counts only while its linker is the recipient; the duplicate flag still counts it. Nothing in the protocol clears stale links; a stranger's permissionless unlink is the only way.

     No funds involved: a wrong, user-visible warning on a valid badge. Reported by four specialists (economics, math, flow, permissions); merged.

     Fix: count only live links, e.g. have link clear any stale link of the same handle it is told about (an optional address[] staleCoins argument that it unlinks first, only entries with linkedBy != recipientOf), or let the site/indexer compute duplicate from live links and document that linkCount includes stale links until cleared; alternatively have badgeOf treat the flag as advisory.

     whole finding

     Judge's scratch test test_staleLinkStillFlagsDuplicate and the attached proof (fails on this commit).

     Creator is fee recipient of coin1 and coin2 (CreatorVault.register by the curve).

     (1) creator calls social.link(coin1, H, deadline, voucher(coin1,H,creator,nonce 0)): badgeOf(coin1) = (H,false), linkCount[H] = 1.

     (2) creator calls vault.setRecipient(coin1, bob): badgeOf(coin1) = (0,false), handleOf(coin1) = 0, but linkCount[H] is still 1.

     (3) creator calls social.link(coin2, H, deadline, voucher(coin2,H,creator,0)).

     Expected: badgeOf(coin2) = (H, false), no other coin shows H.

     Actual: badgeOf(coin2) = (H, true), linkCount[H] = 2, and the Linked event for coin2 carries duplicate = true.

     (4) any address calls social.unlink(coin1): badgeOf(coin2) becomes (H, false), confirming the stale entry is the cause.

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {CreatorVault} from "src/CreatorVault.sol";
     import {SocialRegistry} from "src/SocialRegistry.sol";
     
     contract StaleLinkDuplicateTest is Test {
         uint256 internal constant LINK_KEY = 0xB0B;
         CreatorVault internal vault;
         SocialRegistry internal social;
         address internal creator = makeAddr("creator");
         address internal newOwner = makeAddr("newOwner");
         address internal coin1 = makeAddr("coin1");
         address internal coin2 = makeAddr("coin2");
     
         function setUp() public {
             vm.warp(1_000_000);
             vault = new CreatorVault(makeAddr("imd"));
             vault.initialize(address(this), makeAddr("hook")); // this test plays the curve
             social = new SocialRegistry(address(this), address(vault), vm.addr(LINK_KEY));
             vault.register(coin1, creator);
             vault.register(coin2, creator);
         }
     
         function _voucher(address coin, bytes32 handle, address account, uint256 nonce, uint256 deadline)
             internal
             view
             returns (bytes memory)
         {
             bytes32 digest = keccak256(
                 abi.encodePacked(
                     "\x19\x01",
                     social.domainSeparator(),
                     keccak256(abi.encode(social.LINK_TYPEHASH(), coin, handle, account, nonce, deadline))
                 )
             );
             (uint8 v, bytes32 r, bytes32 s) = vm.sign(LINK_KEY, digest);
             return abi.encodePacked(r, s, v);
         }
     
         function test_staleLinkStillCountsAsDuplicate() public {
             bytes32 h = keccak256("frogdao");
             uint256 deadline = block.timestamp + 1 days;
             bytes memory v1 = _voucher(coin1, h, creator, 0, deadline);
             vm.prank(creator);
             social.link(coin1, h, deadline, v1);
             vm.prank(creator);
             vault.setRecipient(coin1, newOwner); // coin1's badge is gone (R3-A4-9)
             (bytes32 b1,) = social.badgeOf(coin1);
             assertEq(b1, bytes32(0), "coin1 shows no badge");
             bytes memory v2 = _voucher(coin2, h, creator, 0, deadline);
             vm.prank(creator);
             social.link(coin2, h, deadline, v2);
             (bytes32 b2, bool dup) = social.badgeOf(coin2);
             assertEq(b2, h);
             assertFalse(dup, "only coin2 shows this handle, so it is not a duplicate");
         }
     }

     whole proof

   • lowSocialRegistry: routing a coin's fees to its holders (recipient = the coin) removes its X badge at once and makes any future badge impossible; not documented as a consequence of D-52 / D-82launchpad/contracts/src/SocialRegistry.sol:78

     link requires msg.sender == creatorVault.recipientOf(coin) and handleOf shows a link only while linkedBy[coin] == recipientOf(coin). When a recipient routes the coin's fees to its holders with CreatorVault.setRecipient(coin, coin) (D-52, final since the coin contract never calls setRecipient), the recipient becomes the PadToken contract.

     PadToken only ever calls IMD and the PoolManager, so no account can ever satisfy the link check again: the badge the creator linked disappears immediately (linkedBy = creator != coin), anyone may clear the stale link, and neither the creator (who still controls the X account), the X link service nor the owner can link an X account to that coin. link has no verifier or owner path.

     The most holder-friendly routing choice permanently removes the coin's level-1 trust signal (D-12), and THREAT-MODEL section 3, ARCHITECTURE 5.2 / 5.5, D-52 and D-82 don't say so. No funds affected. Reported by two specialists (flow, permissions); merged.

     Fix: either document it (THREAT-MODEL section 3, site copy), or keep the last recipient's link valid once the recipient is the coin (e.g. in handleOf: when recipientOf(coin) == coin, return _handleOf[coin] while linkedBy[coin] is the account that routed the fees, recorded at setRecipient, and allow unlink of such a link only by the verifier or the owner), or let the verifier link on behalf of a holder-routed coin.

     whole finding

     Judge's scratch test test_holderRoutedCoinCanNeverLink.

     Creator is recipient of coin1.

     (1) creator calls social.link(coin1, H, deadline, voucher): badgeOf(coin1) = (H, false).

     (2) creator calls vault.setRecipient(coin1, coin1).

     Actual: badgeOf(coin1) and handleOf(coin1) return 0 at once; social.link(coin1, H, deadline, voucherFor(creator, nonces(coin1))) from the creator reverts Unauthorized(); the same from the owner with its own voucher reverts Unauthorized(); vault.recipientOf(coin1) == coin1 and PadToken has no code path that calls SocialRegistry.link, so the state is permanent; a stranger's unlink(coin1) clears the stale entry (linkCount -> 0).

     Expected: either the badge the recipient linked survives, or the consequence is documented as accepted behaviour.

     whole reproduction

   • infoSocialRegistry: the new fee recipient's own clear of a stale link it did not make consumes the coin nonce and voids the voucher it already holdslaunchpad/contracts/src/SocialRegistry.sol:110

     R4-A4-6 keeps the nonce when a stranger clears a stale link so the voucher the new recipient obtained (signed over the current nonces[coin]) stays valid. The nonce is still bumped when the caller is the current recipient, whether or not the cleared link is its own.

     A new recipient that tidies the coin page by clearing the previous recipient's stale link before linking its own handle voids the voucher it is about to submit (BadVoucher) and must go through X OAuth and the wallet signature again. The bump protects nothing: the stale link belongs to an account that can no longer link, and the new recipient's vouchers are bound to its own address and need it as msg.sender.

     UX trap with a workaround (call link directly, which replaces the stale link).

     Fix: bump the nonce only when the cleared link is live or the caller is the verifier or the owner, e.g. if (msg.sender == verifier || msg.sender == owner() || linkedBy[coin] == msg.sender) nonces[coin]++; evaluated before delete linkedBy[coin].

     whole finding

     Judge's scratch test test_newRecipientClearingStaleLinkVoidsItsOwnVoucher.

     Creator links coin1 to keccak256('old') (nonces[coin1] 0 -> 1); creator calls vault.setRecipient(coin1, bob); bob holds voucher(coin1, keccak256('new'), bob, nonce 1, deadline). bob calls social.unlink(coin1) (allowed: linkedBy = creator != bob).

     Expected: nonces[coin1] stays 1 and bob's voucher works, as it does when a stranger clears the link.

     Actual: nonces[coin1] = 2 (msg.sender == recipient branch) and bob's social.link(coin1, keccak256('new'), deadline, voucher) reverts BadVoucher().

     whole reproduction

   • infoAttestationVerifier refuses an attestation whose issuedAt is seconds ahead of the chain clock; the protocol's reference consumer tolerates 5 minutes of attester clock driftlaunchpad/contracts/src/AttestationVerifier.sol:103

     The oracle stamps issuedAt with its own wall clock while block.timestamp is the sequencer's.

     The protocol's OracleAttestationConsumer._verifyAttestation (oracle-consumer reference, ISSUED_AT_TOLERANCE = 5 minutes) accepts issuedAt <= block.timestamp + 5 minutes for that reason. verifyBool has no tolerance, so a VersionRegistry.activate sent in the seconds after an attestation is issued reverts NotYetValid whenever the chain's clock trails the attester's; a resubmission once the block timestamp passes issuedAt succeeds (the validity window is hours wide).

     Liveness only, no security impact.

     Fix: if (att.issuedAt > block.timestamp + 5 minutes) revert NotYetValid(); (the reference's tolerance), and update test_verifier_acceptsGoodRejectsBad, which asserts the strict check at T0 + 1.

     Judge's scratch test test_issuedAtSecondsAheadRefused.

     Verifier with an approved signer; a correctly signed bool attestation for a question with issuedAt = block.timestamp + 30 and expiresAt = block.timestamp + 6 hours. verifier.verifyBool(att, sig, question) reverts NotYetValid(); after vm.warp(+30 s) the same call returns true.

     Expected per the reference consumer: accepted at once, since 30 s is inside the 5-minute tolerance.

   • infoVersionRegistry.setVerifier (and the constructor) accept address(0) or an address without code; activate and retireManualActivation then revert until another 7-day changelaunchpad/contracts/src/VersionRegistry.sol:159

     setVerifier (7-day timelock) stores any address. With address(0) or an address without code, every activate (which calls verifier.verifyBool) and retireManualActivation (which calls verifier.signerCount()) reverts with an empty revert until the owner sets a real verifier again, which takes another 7 days. Owner-only, no path for anyone else, no funds; manual activation keeps working until retired.

     Fix: if (verifier_.code.length == 0) revert ZeroAddress(); in setVerifier and the constructor.

     Judge's scratch test test_versionsSetVerifierZero.

     Owner calls versions.setVerifier(address(0)), registers version 1, then anyone calls versions.activate(1, job, att, sig) -> reverts (call to an address without code); owner calls versions.retireManualActivation() -> reverts; activateManually(1, link) still works.

     Expected: the setter refuses an address that is not a contract.

   • infoSocialRegistry.setVerifier and constructor accept address(0), silently disabling every linklaunchpad/contracts/src/SocialRegistry.sol:167

     setVerifier (48 h timelock) and the constructor store any address. With address(0), _validSignature returns false for every voucher (if (signer == address(0)) return false;), so link and linkWallet revert BadVoucher until the owner sets a key again (another 48 h). AirdropDistributor's equivalent setter refuses address(0) (R4-A3-8); this one does not. Owner-only, no funds.

     Fix: if (verifier_ == address(0)) revert BadVoucher(); (or a dedicated error) in both places.

     Judge's scratch test test_socialSetVerifierZero.

     Owner executes social.setVerifier(address(0)).

     A fee recipient calling social.link(coin, h, deadline, voucherSignedByTheRealKey) reverts BadVoucher(); linkWallet likewise.

     Expected: the setter rejects address(0) as the airdrop's does.

   • infoVersionRegistry.register does not require code at the five addresses: a version can commit to the hash of empty accountslaunchpad/contracts/src/VersionRegistry.sol:76

     codeHashOf uses address.codehash, which is 0 for an empty account and keccak256("") for an account with a balance but no code. register only refuses address(0), so the 7-day owner can register a version whose code hash commits to no code (a typo'd or not-yet-deployed address), and the audit question built from it would name a meaningless hash. Owner-only and the registry is informational (R1-A4-16), so no onchain effect.

     Fix: refuse factory.code.length == 0 (and the other four) in register.

     Judge's scratch test test_registerAcceptsNoCode.

     Owner calls versions.register(makeAddr('typo'), d, d, d, d) with d a deployed contract.

     Actual: succeeds; versionInfo(n).codeHash == keccak256(abi.encode(bytes32(0), d.codehash, d.codehash, d.codehash, d.codehash)); after vm.deal(typo, 1 wei) a second register commits to keccak256('').

     Expected: revert, since a version must name deployed contracts.

   • infoUntested A4 guards: VersionRegistry replay (RequestUsed), AnswerNo, CannotRetire, setVerifier; SwarmBudget AboveMaxRequest, InsufficientBudget, RequestClosed, stranger cancel, setRelay / setMaxRequestlaunchpad/contracts/test/Governance.t.sol:475

     The suite (186 tests, all passing on this commit) never exercises these guards: grep for RequestUsed, AnswerNo, CannotRetire, AboveMaxRequest, InsufficientBudget, RequestClosed, NotLinked, UnknownCoin, setGuardian, setMaxRequest, 'versions.setVerifier', 'vault.register' and 'budget.setRelay' in test/*.t.sol finds no file.

     In particular no test re-submits an accepted attestation, so a regression that moved the usedRequest write after the verifier call or keyed it on something other than att.requestId would pass the suite.

     The judge's scratch probes show all of them behave as intended on this commit (a second activate with the same attestation, for the same or another version, reverts RequestUsed; a 'no' reverts AnswerNo and leaves the request id free; a stranger's unlink of a live link reverts Unauthorized), so this is coverage only. Reported by two specialists (math, permissions); merged.

     whole finding

     Add to Governance.t.sol after a successful versions.activate(2, job, a, sig): vm.expectRevert(VersionRegistry.RequestUsed.selector); versions.activate(2, job, a, sig); and for a third registered version vm.expectRevert(VersionRegistry.RequestUsed.selector); versions.activate(3, job, a, sig); (both pass on this commit). Likewise assert Ownable.Unauthorized for a stranger on versions.setVerifier, budget.setRelay, budget.setMaxRequest, config.setGuardian, vault.register / credit / initialize; AboveMaxRequest after budget.setMaxRequest(1e18) on requestSpend(coin, 2e18, spec) by the recipient; RequestClosed on a second cancel; NotLinked on unlink of an unlinked coin; and badgeOf(...).duplicate after a stale link (see the Low finding above).

     whole reproduction
7. Onchain1 receipt, 5 scores queuedon Ethereum mainnet

   receipt

   work accepted · record queued

   scores

   5 scores for reviewed on submission · all 5 passed#759#1212#1299#1188#158