Review complete. The findings file holds three entries, all with snippets verified against the tree.

What I found

• Medium, src/ProjectRegistry.sol:402. On Robinhood Chain the EVM's block number is Ethereum's height, not the rollup's. I confirmed this live: a contract reading block.number there returned 26,183,281, identical to mainnet's current block, while the chain itself was at 87,477,427. The registry stamps fromBlock and toBlock and the Listed and Delisted events with that value. The points counter in tools/snapshot/build.mjs compares those against the Stacker logs' own rollup heights, so on this chain every pre-listing credit earns points and every credit of a later-delisted project loses them. The mainnet registry is unaffected. The fix is the owner's call since the brief wants byte-for-byte code: read ArbSys.arbBlockNumber() in the callback, or keep the code and make the indexer use the log's block height and document that the stored fields are Ethereum heights.
• Low, src/ProjectRegistry.sol:500. claimBond accepts the registry's own address as the destination. The claim is zeroed and the self-transfer succeeds, stranding the bond with no sweep path. The other two self-address guards in the contract do not cover this one. A scratch test under test/scratch reproduces it.
• Info. The accepted limits are recorded for the adapter: self-challenge slot holding, stranger applications on ownerless projects, the signer, Intake, action and panel constants fixed for life, trust in the writer's pairing without a pinned question hash, and the expire race. It also records the live Robinhood probes.

What I verified

• All 131 registry tests and the deployment test pass locally. Runtime is 23,427 bytes. No forbidden opcodes, proxies, initializers, mint, pause or seize paths.
• launch.json has only the three schema keys, seven string arguments in constructor order, correctly checksummed addresses, and 1,624 characters of notes.
• The live Robinhood Intake sells the action for 0.5 IMD, has a 200,000 callback gas stipend, and its requests() record for the rehearsal request decodes with completed as the fourth word, so expire reads it correctly. Its runtime hash differs from Ethereum's, which immutables would explain.

Coverage. I read src/ProjectRegistry.sol and src/oracle/OracleAttestation.sol in full, the MockIntake test double, launch.json, and the points indexer. I did not read src/Stacker.sol or src/multichain since they are not deployed here, and I could not read the live Intake's or the Robinhood IMD token's source, only probe their behaviour over RPC.

Implemented both reproduced audit fixes: Robinhood listing block numbers and rejected bond self-transfers. These fixes change mainnet bytecode parity; manifest and protected files remain unchanged.

forge build and forge test pass: 360 passed, 29 skipped. Factory rehearsal passes; runtime is 23,709 bytes.

Changes and accepted limits are documented in ADAPTATION.md.

The live RPC probe returned HTTP 403. No transaction was broadcast.

Updated launch.json, preserving the approved ProjectRegistry arguments and documenting accepted limits. No other deliverable files changed.

Validation passed: forge build; forge test reported 345 passed, 0 failed, 29 skipped.

The unchanged source builds to 23,709 runtime bytes, versus the brief’s 23,427; it remains below the deployment limit.

The review is complete. The findings file is valid JSON, every snippet anchors to its line, and the working tree shows no tracked changes beyond my scratch tests and the findings file.

Outcome: no reproducible defect in the math, boundary or numerical-gap area. The registry's arithmetic is small and sound, and every edge I could name behaves as the brief describes. I wrote three informational notes and a full coverage record to .imd-findings.json.

What I verified with scratch tests (all under test/scratch/, 16 tests passing):

• Answer and expire deadlines agree at the exact second. At the ask time plus one day the answer is still accepted and expire refuses; one second later the answer is TooLate and expire clears.
• Issued-before-ask tolerance is exactly 300 seconds. An attestation issued 300 seconds before the ask passes; 301 seconds is refused.
• Panel lower bounds hold. Agreed 10, quorum 12 with agreed 11, and panel 14 are all refused.
• Rate bounds are inclusive at 25 and 100, and 24 and 101 are refused.
• Bond conservation. The registry holds exactly one 20 IMD bond per open challenge, forwards the fee in the same call, and leaves no residual Intake allowance.
• Callback gas headroom on the Robinhood path is wide. A cold listing settles in about 76k gas and a cold delisting with bond return in about 86k, against the 200k stipend.
• RemoteStacker tip rounding matches its documentation: tips truncate to zero below 50 bridge steps, dust stays untipped, the weighted clock rounds arrival up, and a fuzz run confirms the waiting delta equals delivered plus tip with the tip never above 2%. Slither's divide-before-multiply lines are the deliberate whole-step rounding.

The three informational notes:

1. The panel check has no upper bound, so an attestation with agreed 65535 over a panel of 15 is accepted. Only the trusted signer can produce one, so there is no exploit.
2. An owner() that needs more than 30,000 gas is treated as no owner, which is the brief's documented definition. Standard Ownable, proxy and Diamond patterns fit with wide margin, and gas starvation cannot bypass the gate.
3. The manifest notes still say the code is the mainnet registry's, but this tree compiles to a 23,709-byte runtime rather than the mainnet 23,427 because of the two accepted audit fixes recorded in ADAPTATION.md. The notes should describe those fixes rather than claim parity.

Coverage: all 13 listed entry points have a row, plus two invariant rows. Two rows point at the informational notes and the rest hold. Nothing was left unreached.

The review is complete. The findings file is written, the snippet matches the tree, and the working tree is otherwise clean (git status shows nothing besides the untracked findings file, which is the deliverable).

Outcome. The ProjectRegistry's permission model holds against the Access Control, Trust Gap and Asymmetry guides. I found one low-severity asymmetry and no bypasses, so no proof test was required.

What I checked

• Every registry entry point was traced through its guards, state writes and failure paths: owner-gated applications, open challenges with pinned beneficiaries, Intake-only callbacks bound to the registry's own open request and EIP-712 domain, once-per-day handoffs, and bond routing to the recorded asker or the beneficiary fixed at challenge time.
• Trust-gap seams were walked concretely: a third party's own paid question cannot settle a registry request, handoff front-running is defeated by the pin plus the daily interval, and self-challenge slot holding matches the accepted limits in the brief.
• The manifest matches the brief exactly: one contract, seven constructor arguments in order, schema keys only.
• The full non-fork unit suite passes on this tree.

The finding (low). The owner gate in applyListing treats any non-zero 20-byte answer from the project's owner function as a real owner. A project "renounced" to the 0x...dEaD burn address, or owned by a contract that cannot make calls, can therefore never be applied for by anyone. An identical project renounced to the zero address is open to all. This is within the brief's wording, so I recorded it as a design limit with a one-comparison fix if the owner wants it. I verified the revert with a scratch test, then removed the scratch directory.

Coverage. All 13 listed entry points have rows. The five Stacker, RemoteStacker and StackReceiver entry points are outside this area and not deployed by this launch, so they are marked as holding with the reason noted. Three extra rows record the invariants I checked and the accepted limits the brief asks to record.

The review is complete and .imd-findings.json holds the result. The working tree is clean apart from that file (the scratch test was removed).

Outcome: no defect of medium or higher severity in the ProjectRegistry launch's economics. The file records one informational finding and a coverage row for all 13 listed entry points plus three invariants and the manifest.

What I checked, in my area (Economic Security, Invariant, Flow Gap):

• Fee and bond conservation on every path: each ask pulls fee plus bond, the Intake pulls exactly the fee, every settle or clear pays or records exactly one bond, and the registry's balance equals open bonds plus owed bonds.
• The answer callback against the live chain. A fork test drove apply, list, challenge, delist and defend through the live Robinhood Intake v2 and IMD token, with the ArbSys precompile mocked. Gas used inside the 200k stipend:

• Live reads on Robinhood Chain confirmed the brief's facts: price 0.5 IMD, callbackGas 200,000, the requestWithFailure selector in the Intake's code, the requests() tuple with completed in the fourth word (true for the rehearsal request), and the RemoteStacker's IMD, receiver, vault and endpoint id.
• Griefing, slot holds, handoff races and timestamp levers all resolve to the limits the brief already lists as accepted. They are recorded as accepted, not as findings.
• The manifest has the three schema keys, seven constructor arguments in declaration order matching the brief, and notes well under the limit.

The one informational record: applyListing writes the applicant's beneficiary into the project record before the panel answers, so for an ownerless, delisted project a stranger can overwrite the recorded beneficiary of the last listing period for 0.5 IMD, and the stale value stays after a rejection. No funds are misdirected on chain and the events carry the true history. It is documented in the struct comment and identical to the mainnet registry, so no code change is suggested.

Not reached: the panel's off-chain judgement and the writer's pairing of answers to requests, which the design trusts, and the LayerZero bridge economics beyond one reading of the RemoteStacker and StackReceiver, which are outside the assigned area and not redeployed by this launch.

The full offline suite passes: 345 tests passed, 5 fork tests skipped without RPC URLs, 0 failed.

The review is complete and written to .imd-findings.json in the repository root. No source file was changed, and the scratch fork test I used for verification was removed.

Outcome: one low finding, no code defect in the registry's control flow.

• Finding 1 (low), launch.json line 17. The manifest notes say the code is the mainnet registry's, and the brief repeats "byte for byte" with a 23,427-byte runtime. The tree's registry differs: it reads the rollup block height through ArbSys on chain 4663 for listing periods, and claimBond refuses the registry itself as recipient. The built runtime is 23,709 bytes, and the diff against the launch-mainnet branch shows 24 changed lines. ADAPTATION.md told the manifest step to describe these two fixes instead of claiming parity. Both changes are correct and needed on Robinhood Chain. The fix belongs in the notes, not the code.

What I verified in my area (Execution Trace, Periphery, First Principles):

• Every registry entry point traced check by check: fee and bond are pulled only after all validation, every settle or clear path closes the question before any transfer, a bond leaves exactly once, and a late or duplicate Intake callback hits UnknownRequest.
• Live reads on Robinhood Chain: the Intake, IMD, RemoteStacker and trial venue have code, the signer is an EOA, the Intake sells the question for 0.5 IMD with a 200,000 callback gas, and its bytecode equals Ethereum's except the EIP-712 chain cache. The requestWithFailure and requests selectors the registry calls are present and the latter returns the four-word tuple the registry decodes.
• ArbSys at 0x64 answers arbBlockNumber() in the same block space as the RPC's block number.
• On a fork of chain 4663, a cold delisting and a cold defense through the real IMD token and the real ArbSys both completed under a 200,000-gas callback.
• The offline registry suite passes, with this result:

Ran 23 test suites: 142 tests passed, 0 failed, 0 skipped

Coverage record: all 13 listed entry points have rows. The eight registry functions hold. The five Stacker, RemoteStacker and StackReceiver entry points are not deployed by this launch and the registry never calls them; I read them for the static-analysis leads and found those leads benign, so they are marked holds with that reason. Two invariant rows and a manifest row are included.

Accepted limits, recorded not reported: self-challenge slot holding by a beneficiary, stranger slot holding on ownerless projects, and the fixed signer, Intake, action and panel constants.

Added tests under test/ for bond-accounting invariants, deferred claims, callback failures, reentrancy, and signer verification.

Offline validation passed:

• forge build
• forge test: 357 passed, 0 failed, 29 skipped.
• New invariant campaign: 16,384 calls without unexpected reverts.

Accepted limits and live-verification gaps are documented in test/ROBINHOOD_REGISTRY_COVERAGE.md.

The review is complete and written to .imd-findings.json. No file in the tree was changed; only the findings file and my scratch tests under test/scratch/ were created.

Outcome: no blocking defects. The registry as it stands in this tree holds on every entry point, and the one Robinhood-specific change it carries is correct and necessary. The findings file holds five informational notes and a coverage record answering all 13 entry points.

What I verified myself

• The ArbSys adaptation is right. I read Robinhood Chain live: the header's parent height was about 26.18 million while arbBlockNumber() at 0x64 returned about 87.5 million, the RPC height the RemoteStacker's credit logs are indexed by. A mainnet-identical registry would record listing periods in Ethereum's block space. The constructor still makes no external call.
• Live Intake v2 on chain 4663 reports a 200,000 callback gas, sells the question for 0.5 IMD, and its requests getter returns the 4-word tuple the registry's expire decodes.
• Build and tests: the tree compiles under the unchanged foundry config and the non-fork suite passes 357 of 357. Runtime is 23,709 bytes, creation 25,288 bytes plus 7 argument words, both under the limits. The manifest has only the three schema keys, 7 arguments in declaration order, and notes of 2,524 characters.
• My own pass over the callback, bond accounting, expiry boundaries, handoff rules, the owner gate, the JSON body and the three stacker contracts found nothing the specialists missed at medium or above.

Specialist findings, settled

• The two "manifest claims mainnet parity" reports (audit_math, audit_flow) were merged. Their quoted sentence is no longer in launch.json at HEAD, so the finding does not reproduce as stated. I kept one info note recording that the code differs from mainnet by the two accepted fixes, since the brief's own facts still say byte for byte.
• The burned-owner lockout, the 30,000-gas owner cap, the agreed-above-panel-size acceptance and the beneficiary rewrite on an unlisted project all reproduce. Each is either what the brief specifies or mainnet behaviour with no loss path, so each is recorded as info with a passing scratch test as its reproduction.

The static-analysis lines (divide-before-multiply, unused returns, timestamp use, locked ether) were each checked and are intentional or not reachable as defects, so none was promoted.