The review is complete and the findings are in .imd-findings.json at the repository root. No file in the tree was changed; the scratch test I used for verification was removed.

Outcome: no critical, high or medium defect. The code the launch deploys is the live test run 4 registry plus exactly two changes, and both hold up.

What I read and checked

• Read in full: the registry, the oracle attestation library, the Stacker, the mock Intake, the gate, policy, fork, deployment and fixture tests, the manifest, the rule docs, and the pinned references.
• Diffed the tree against the Sourcify-verified test run 4 registry: the only changes are the owner gate and the version 3 trader and feeGuard strings. The attestation library is byte-identical to the live one.
• Read the live Intake v2 source from Sourcify. Its requests getter, payment pull, writer-only complete, failure-argument check and callback stipend all match what the registry assumes.
• Live Sepolia reads: callback gas 1,000,000, price 0.5 test IMD, test run 4 registry trusts 0x5598…2982 and has PLEA listed, PLEA's hook reports owner 0x4b91…6821. The Intake's own signer() is a different key, but that one signs quotes, not attestations.
• Offline suite: 223 passed, 13 skipped (fork and mainnet-manifest tests), as the brief states.
• Manifest: seven arguments in declaration order, all four addresses correctly checksummed, name and notes within limits.

Findings written

• Low. A listed project's beneficiary can challenge itself repeatedly. Its bond comes straight back on each yes, the cooldown does not restart, and while its own question is open every outsider's challenge reverts with AskOpen. Net cost is one oracle fee per round. I verified the sequence with a forge test. The design doc covers the cooldown half but not the slot occupancy.
• Info. The Sepolia fork test applies for PLEA's previous hook and wires the registry to the test run 1 Stacker rather than the launch's. It still passes, since both hooks report the same owner.
• Info. A scope and coverage statement listing what was read, what was verified on chain, what could not be reached (the plane's off-chain body validation, the panel's reading of the new rules, the deployer's gas policy), and the trust assumptions the adapter should keep in view.

Confirmed sound: the owner gate cannot be starved of gas because of the 63/64 rule, bond accounting pays out exactly once per challenge, answers are replay-protected and panel-checked, and the runtime contains nothing the launch forbids.

Prepared the launch handoff: corrected fork targets, updated the registry-only factory rehearsal, and documented the reproduced self-challenge limit in ADAPTATION.md.

Contracts, manifest, configuration and dependencies remain unchanged.

• forge build: passed.
• forge test: 224 passed, 13 skipped.
• Fork verification: 12 passed, including all 11 fork tests.

Live deployment and the README address await the launch service’s confirmed receipt.

I found one low-severity issue and nothing else in the permission review. Results are in .imd-findings.json; no repository files were changed (the scratch test was deleted after it ran).

The baseline suite passes offline: 224 passed, 13 skipped, 237 tests in total. The brief says 236, so one test seems to have been added on this branch.

The finding (low): a project whose owner is 0xdEaD can never be applied for by anyone else (src/ProjectRegistry.sol:247)

• projectOwner counts any non-zero address as an owner, including burn addresses like 0x…dEaD that many contracts "renounce" to.
• For such a project, applyListing admits only 0xdEaD, whose key nobody holds, or the project contract itself, which usually can't make the call. Any other caller gets NotProjectOwner(0xdEaD), so the project is locked out of listing for good.
• A scratch Foundry test reproduced this: a call from 0xBEEF reverted with NotProjectOwner(0xdEaD).
• This follows the brief exactly as written ("zero means no owner"), so it's a gap in the agreed design rather than a deviation from it. You'd need to decide whether burn addresses should count as no owner.

Coverage: all 9 listed entry points have a row, plus two invariants (token balance equals open bonds plus bondOwed, and no privileged role after deployment):

• applyListing: marked as having the finding. Apart from it, the owner check runs before any fee is taken, and its fixed 30,000-gas cap means an applicant can't make it fail by limiting gas.
• The other entry points hold:
  • challenge and challengeForBeneficiary check the beneficiary pin and refuse a changed wallet before taking any payment.
  • onOracleResult and onOracleFailure accept only the Intake and only this contract's own open questions, with the signature, panel and timing checks in the brief.
  • expire's one-day boundary lines up with onOracleResult's.
  • setBeneficiary is limited to the current wallet, once per day, and never while a question is open.
  • claimBond pays only what is owed to the caller.
  • Stacker.credit isn't deployed by this launch and the registry never calls it.
• launch.json: its constructor arguments match the brief.

Not reported: I looked at three griefing routes and found none worth reporting, because each costs the attacker money or hands the bond to the beneficiary:

• a beneficiary repeatedly challenging its own project to keep real challengers out;
• someone challenging just ahead of a setBeneficiary call to block it;
• a challenge reason worded to split the panel so the bond comes back.

Test IMD is free to mint, so on Sepolia these cost almost nothing, but they don't break any guarantee in the brief. I didn't run the 11 fork tests, since that needs the RPC URLs.

Updated only launch.json, preserving the exact ProjectRegistry constructor arguments and clarifying the Sepolia test run 5 notes.

Validation passed: manifest structure, compiled ABI, and forge build. forge test: 224 passed, 0 failed, 13 skipped—11 require RPC URLs; 2 apply only to mainnet.

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

Outcome. The math, boundary and numerical-gap pass over src/ProjectRegistry.sol found no value-moving defect. The registry has no multiplication or division at all. Its arithmetic is limited to checked timestamp additions, one fee-plus-bond sum, and bond accounting against an immutable bond, and every boundary I traced behaves as the brief specifies.

What I checked, with numbers:

• Deadline boundaries line up with no gap or overlap. The callback refuses after one day and expire refuses at or before one day unless the Intake completed the request.
• Signature-window edges are inclusive as specified: an answer issued up to 300 seconds before the ask is accepted, one issued earlier is refused, and expiresAt itself is still valid.
• Callback gas under the 200k mainnet stipend has headroom. The heaviest cold path, a defended challenge, used about 131k gas. The bond-owed variants were lower, and failures used at most about 82k.
• Question and rule lengths at maximum input stay well under the paid door's caps: about 1,010 characters for an application and 1,107 for a challenge, against a 2,000 limit. Each of the 8 rules is asserted at or under 512 by the existing tests.
• Bond conservation holds for the standard Sepolia test IMD. The fee is forwarded exactly and each challenge bond is paid once or recorded in bondOwed.
• The applicant cannot starve the owner() staticcall to skip the owner gate. The 63/64 rule leaves under 500 gas after a starved call, far less than the rest of applyListing needs.

One finding, severity info. A project whose owner() genuinely costs more than the 30,000-gas cap reads as ownerless, so a stranger can apply for it and occupy its question slot. I reproduced this with a scratch test under test/scratch/. It matches the brief's own definition of the cap, so I reported it to make the threshold explicit rather than as a required fix.

Coverage. All nine listed entry points have rows: eight holds, one finding for applyListing, plus two invariant rows. The live Intake's requests() return layout used by early expire is confirmed by the existing Sepolia fork test. I did not run the fork tests myself since no RPC URL is set here.

Review complete. The findings file is written and the scratch probe removed.

Outcome: no exploitable defect in the registry's control flow. One info-level documentation drift reported.

What I checked, from the Execution Trace, Periphery and First Principles guides:

• Every entry point's guard order, state writes and failure paths: applications, both challenge forms, the signed result callback, the unsigned failure callback, expire, bond claims and beneficiary handoffs.
• Interleavings across transactions: answers after expiry, failures after expire, re-applications after rejection or delisting, handoffs around challenges, self-challenges, third-party paid requests naming the registry as callback. All were either refused by a guard or already documented as accepted limits in docs/design.md.
• The one lead I tested mechanically: a stranger starving the 30,000-gas owner() staticcall to read "no owner". A scratch test over gas limits from 25k to 2M never completed an application, because EIP-150 leaves under 1/64 of the gas after the sub-call fails.
• Periphery: the EIP-712 struct hashing, signature verification order, and the two assembly helpers (owner read, tolerant transfer) use scratch memory correctly and gate on return size.
• The offline suite passes (223 tests, 2 mainnet-manifest skips as expected).

The one finding (info): the NatSpec at src/ProjectRegistry.sol:540 says the contract sends version 2 of the panel rules, while the definitions carry version 3's trader and fee-guard text. No behavioral effect, but this source is what gets verified and reused for mainnet.

Coverage record: all nine listed entry points marked holds with reasons, plus rows for the bond-conservation and single-ask invariants and the two periphery pieces. Nothing was left unreached.

The review is complete and written to .imd-findings.json. The tree is otherwise untouched: the scratch probe test was removed and git status is clean apart from the findings file, which is ignored.

Outcome: no critical, high or medium defect in the economics, invariants or flow gaps. Two low findings and one documented-limit note are recorded, each with a concrete reproduction, plus coverage rows for all nine entry points and five invariants.

What I verified, beyond reading the code:

• Scope of change. Diffing this tree against test run 4's verified source on Sourcify shows only the owner gate and the two version 3 rule strings differ. The rule text matches docs/panel-rules-v2.md character for character, at 473 and 408 characters.
• Live Intake v2 flows. Its source on Sourcify confirms the assumptions expire relies on: a request is completed exactly once, the flag is set before the single callback attempt, and the requests getter has the shape the registry decodes. Live reads: price 0.5 test IMD, callback gas 1,000,000, PLEA's owner is the test wallet.
• Bond conservation. Contract balance always covers open-challenge bonds plus bondOwed; the fee approval is consumed whole in the same call. The existing accounting invariant suite passes, and the full suite passes offline (224 passed, 13 fork tests skipped).

The findings:

1. Low. The question text never names Sepolia. It says "on chain 11155111" while the body is filed under chain 1, although the brief and docs/design.md state the text names Sepolia. The rehearsal body that reached a signed yes had the same wording, so this is a wording and documentation mismatch rather than a loss.
2. Low. The owner gate can make a project unlistable. A hook deployed through a CREATE2 deployer with Ownable(msg.sender) reports the deployer as owner, and nobody can then apply. This is the requested design, reported as a consequence for the author to weigh.
3. Info. Retiring the oracle action freezes the listing set. With no owner and a constant action id, a zero price makes every ask revert. The owner has already accepted this as a documented limit; no funds are at risk.

Nothing in my area was left unreached. Stacker.credit is marked holds because this launch does not deploy it and the registry never calls it.

Added owner-boundary tests and bond-recovery invariants covering refused payouts, failed claims, relistings, and expiry. Changes are confined to test/.

Verification passed: 238 tests passed, 0 failed, 13 skipped. Skips cover 11 RPC-dependent fork tests and 2 mainnet-manifest checks. forge build also passed.

The review is complete and the findings file is written. git status shows only the untracked .imd-findings.json, which is the deliverable; the scratch test directory is removed and no repository file was changed.

Outcome: no blocking defects. The registry deploys through the factory and behaves as the brief specifies. I kept five findings, one low and four info, every one reproduced on this tree.

What I verified myself

• The full suite passes offline: 238 tests pass and 13 fork or mainnet-manifest tests skip, as the brief describes.
• Deployability holds. Runtime is 23,256 bytes and init code with arguments is 25,059 bytes, both under the factory limits. The constructor makes no external call and accepts the manifest's seven arguments in order. The manifest has only the three schema keys and its notes are under 4,000 characters.
• Every one of the nine entry points traced as intended: the Intake-only callbacks with their selectors confirmed, the one-day expiry boundary shared by result and expire so they cannot race, bond routing on keep and delist, the handoff interval, and the once-per-request replay key.
• The eight rules measure 173 to 473 characters, worst-case questions stay under 2,000, and the version 3 trader and feeGuard texts match the docs word for word.
• Live Sepolia reads at block 11,899,669 match the brief: the Intake sells the question for 0.5 test IMD, PLEA's hook reports the expected owner, the Stacker has code, and the Intake's request getter returns the four words the registry decodes.

Findings kept

1. Low, merged from two specialists. The owner-only gate permanently locks out any project whose reported owner cannot call applyListing, such as a burn-address renounce or a CREATE2 deployer that became the hook's owner. It follows the brief's literal wording, so it is a design gap for the author to decide on, not a bypass.
2. Info. An owner() costing over 30,000 gas reads as no owner, so that project's gate becomes permissionless. Starving the call from the applicant's side is not reachable.
3. Info. The comment above the rules still says version 2 while the code sends version 3.
4. Info. The question text names the chain only as 11155111 and never contains the word "Sepolia", while the brief and design doc say it does. The manifest notes state the chain-id reading and test runs 3 and 4 were listed and defended with this exact wording, so I lowered it from the specialist's low.
5. Info, trust assumption. With no owner and immutable Intake, asset and signer, a retired action or zero price freezes the listing set. The brief requires no owner, and the author already records this limit.

The coverage record answers all nine entry points plus four invariant rows. No finding carries a proof file because none is critical or high.