Implemented the eight-section site in site/ and complete static export in dist/, including live stats, meme downloads, generator and responsive interactions.

Validation passed: typecheck, 8 unit tests, 20 browser checks, and Foundry build/tests (51 passed; 1 fork skipped). Submission size is safely below 8 MiB.

Contracts and protected configuration remain unchanged. Design and verification details are in DESIGN.md, README.md and VALIDATION.md.

Completed on top of the existing project. Fixed an overflow check that rejected valid partial fills, expanded regression tests, and documented deployment and accounting.

Verified:

• forge build and forge fmt --check pass.
• 59 local tests pass; fork suite skips offline.
• 25 Robinhood fork tests pass.
• 11 protected tests pass.

Mine the CREATE2 salt using the final hook bytecode.

Added 37 tests covering failure paths, deferred refunds, sweep accounting, and invariants. Changes are confined to test/.

• forge build: passed.
• Offline tests: 96 passed, 2 fork skips.
• Robinhood fork: 31 passed.
• New invariants: 32,768 calls, no unexpected reverts.

No implementation defects reproduced. Details: TESTING.md.

Updated only launch.json, confirming constructor arguments, permissions and pool settings, and clarifying deployment notes.

Validation:

• forge build: passed; existing lint warnings remain.
• forge test: 96 passed, 0 failed, 2 fork setups skipped.
• imd launch check .: passed.
• Scope check: only launch.json changed.

The permissions review found one defect, rated medium. Everything else in the access-control area checks out. The results are in .imd-findings.json; no other file was changed. The existing suite passes: 96 tests passed and 2 were skipped.

Finding 1 (medium): the anti-snipe fee runs about 100 times longer than the spec allows (src/SPEPEHook.sol:93, with the opening block recorded at :77).

• Cause: the hook counts its 10-block fee window with Solidity's block.number. Robinhood Chain is built on Arbitrum, and there block.number returns the Ethereum mainnet block number, not Robinhood's own block height.
• Evidence from the live RPC: a contract call that returns block.number gave 26169729, which equals the latest block's l1BlockNumber. Robinhood's own height was 85893546. Robinhood produces about 10 blocks per second; the mainnet number moves about once every 12 seconds.
• Effect: each fee step (30%, 27%, … 3%) lasts about 12 seconds, so the fee window ends after about 120 seconds and 1,000+ Robinhood blocks, not 10 blocks. For example, a swap 5 seconds after opening should pay no hook fee under M1 but pays 30% in IMD to the vault. Every early trader in the first two minutes overpays.
• Why the tests miss it: Foundry's vm.roll and fork mode use Robinhood's own block number.
• Fix: count blocks with ArbSys(0x64).arbBlockNumber(), falling back to block.number where that precompile doesn't exist so local tests still run. If a two-minute window is actually wanted, the spec and notes should say so instead.

There's no proof test for this one: it only shows up on the real chain, and a proof test may not use a fork.

What checked out:

• Callbacks: all three only accept calls from the PoolManager.
• Pool opening: beforeInitialize accepts only the exact SPEPE/IMD pool at fee 12500, tick spacing 60, with this hook, and only once. It doesn't check who opens the pool. That is safe only because the factory deploys the hook and opens the pool in the same transaction; doing those in two steps would let anyone open the pool at their own price first.
• Fee collection: sweep() and unlockCallback can only send the hook's own accrued IMD to the fixed vault.
• No admin: there is no owner, setter or upgrade path.
• Permissions: launch.json, getHookPermissions and the address bits (0x20cc) agree.
• Fee accounting: the two fee paths balance (reserved = fee + refund), and the max-buy check reads the real SPEPE amount delivered.
• Token: the three SPEPE functions are unmodified OpenZeppelin ERC20.

Refunds to routers (not reported): partial-fill refunds go to the router, not the user's wallet. That follows the spec, which says the hook only sees the router, and the README makes routers responsible. On a full fill only 0–2 wei of rounding is left there. A router that doesn't handle these claims would strand a partial-fill refund, but I didn't report it because I couldn't show a material loss.

Coverage: all 7 entry points have a row, plus three checked invariants. The finding is recorded against afterSwap and beforeInitialize; the other five entry points hold.

The review is complete. The findings file is written at the repository root, no tracked file was changed, and only the scratch test remains under test/scratch/.

What I found (two medium findings, both in src/SPEPEHook.sol):

1. Anti-snipe fee decay runs on Ethereum L1 block numbers. Robinhood Chain is an Arbitrum Nitro chain, so the NUMBER opcode returns the parent-chain block number. I confirmed this live: an eth_call reading block.number returned 26,169,718 while the chain height was 85,892,230, and block headers show about 115 Robinhood blocks (roughly 12 seconds) per unit of block.number. The "first 10 blocks" window is therefore about 2 minutes and about 1,150 Robinhood blocks, the decay is a 10-step staircase rather than per-block linear, and steps can be skipped or held when the sequencer's L1 view lags. A swap 50 Robinhood blocks after opening pays 30% where the spec says 0%. Neither the unit tests nor the fork tests can see this because Foundry seeds block.number from the L2 height.

2. Specified-side refunds are stranded with claim-unaware routers. The excess reservation is minted as an ERC-6909 claim to the PoolManager's caller. With a V4Router or UniversalRouter style router that only settles and takes, a partial fill during the fee window loses the refund permanently, and when the fill is smaller than the reservation the seller ends with a negative IMD delta. Reproduced locally on a launch-like pool: an exact-output sell for 2,000 IMD filled 759.6 IMD gross, the fee was a correct 227.9 IMD, but the seller paid 97.5 IMD net and 629.3 IMD of claims were stuck in the router. The identical sequence through the repo's claim-aware test router paid the seller the expected 531.7 IMD. The brief mandates the ERC-6909 refund mechanism, so I flagged this as an integration and documentation gap rather than a spec violation.

What held: fee math in all four modes (fee never exceeds the reservation, hook delta nets to zero, SPEPE is never charged), the per-swap max-buy on the delivered amount, sweep and unlockCallback accounting, and the conservation invariants. The full offline suite passes (93 tests plus the three invariant suites, 2 fork setups skipped). Live IMD is a plain ERC-20 with no proxy, pause, or blacklist selectors.

Coverage: all seven listed entry points have rows, plus five invariant rows. The area I did not reach is the IMD owner's mint powers and the actual deployed Robinhood router addresses, which I could not identify from the task inputs.

The review is complete. The findings file is written, no tracked file changed, and the scratch directory is removed.

Outcome: two low-severity findings, no high or critical defects. The core control flow of the hook holds up under the Execution Trace, Periphery and First Principles checks.

What I traced

• All four swap modes in both token orderings through PoolManager.swap, Hooks.beforeSwap and Hooks.afterSwap: reserve, fee and refund always reconcile so the hook's net delta is zero and the fee equals the rate on the pool's actual fill, including the capped reservation and the int256 overflow guard.
• Max-buy enforcement on the raw pool delta, window boundaries, one-shot initialization, sweep and unlockCallback solvency, manifest versus implementation, bytecode size and escape opcodes.
• The existing 96 offline tests pass. The fork suites skip cleanly without an RPC.

Findings recorded in .imd-findings.json

1. Negative seller cash on price-limited exact-output sells. In the opening block, a sell requesting 1,000,000 IMD exact output with a tight price limit fills about 20,000 IMD, but the seller's ERC-20 IMD delta is about -408,572 IMD. The surplus exists only as ERC-6909 claims minted to the router. A router that only settles ERC-20 deltas either reverts or makes the user pay IMD on a sell and strands the claims. The design is spec-mandated and the README notes router responsibility, but it does not say a sell can require paying IMD, and no test uses a claim-unaware router. Reproduced locally with a stand-in router.
2. Anti-snipe window counts Ethereum L1 blocks. Live RPC probing shows Robinhood Chain is an Arbitrum Orbit chain with roughly 0.1 s blocks and a parent l1BlockNumber advancing every ~12 s. On Nitro, block.number returns that parent number, so the "10 blocks" window is about 2 minutes with 12 s fee steps that can skip tiers. The README and the decay test assume one fee step per chain block, and a fork test cannot detect this. Flagged for the author to confirm the intended semantics.

Coverage: rows for every listed entry point plus beforeSwap, two invariants, and the manifest. One row is marked unreached: an end-to-end Universal Router run on a Robinhood fork, since no router address for chain 4663 was given.

The review is complete. No tracked files were changed; the output is in .imd-findings.json (ignored by git), with one scratch proof under test/scratch/.

Outcome

Three substantiated findings, none critical or high. The fee arithmetic itself is sound: reservation bounds, int128 casts, the overflow guard, the max-buy boundary and the decay schedule all held under tracing, and the project's own suite passes offline (96 tests).

• Medium, src/SPEPEHook.sol:130. A price-limited exact-output sell (SPEPE in, exact IMD out) reserves more IMD in beforeSwap than the pool delivers when the fill is below 42.86% of the request at offset 0 (3.09% at offset 9). The seller's IMD delta then comes back negative, so a sell requires the caller to pay IMD in cash and receive the balance only as an ERC-6909 claim. Standard routers that take the output currency revert, and routers that settle without burning claims strand the refund. Reproduced with a 100,000 IMD request filling 19,999 IMD, giving a cash delta of -22,858 IMD and 36,857 IMD of claims. The scratch test fails on the current code and is attached as proof.
• Low, src/SPEPEHook.sol:93. On Robinhood Chain block.number is the Ethereum L1 block number. Verified live: Multicall3 reports 26,169,755 while the L2 height is 85,896,517. The anti-snipe window therefore steps every ~12 seconds and lasts about two minutes, with every L2 block in the opening L1 block charged the full 30%. The notes, README and tests describe per-block decay in L2 terms.
• Low, src/SPEPEHook.sol:125. The fee rounds down while the reservation rounds up. Fills under 4 wei pay nothing at offset 0, the vault loses up to 1 wei per swap, and nearly every full-fill IMD-specified swap mints a 1-wei refund claim at an extra SSTORE.

Coverage. All seven listed entry points have rows: afterSwap is marked finding, the rest holds, plus three invariant rows. IMD was checked on chain as a non-proxy ERC-20 without a pause function, and the vault is an EOA.

Not reached. No live fork swap was run against the real PoolManager; the on-chain PoolManager bytecode was not compared to the vendored v4-core.

The review is complete. .imd-findings.json holds three findings and an 11-row coverage record. No project files were changed; the scratch tests live under the ignored test/scratch/.

What I found

1. Medium, merged from three specialists. When IMD is the specified currency, the hook reserves the fee in beforeSwap and refunds the excess as ERC-6909 claims to the router. On a partial exact-output sell the swapper's IMD cash delta goes negative. The seller hands over SPEPE and must also pay IMD, with the refund reachable only by a claim-aware router. I ran the audit_math proof on this tree and it fails as described. The output showed a cash delta of about -22,858 IMD on a sell. Standard routers of the Universal Router shape either revert the swap or strand the refund. The proof is attached to this finding.

2. Medium, merged from all four specialists. The anti-snipe window counts block.number, which on Robinhood Chain is the Ethereum L1 block number. I verified this live: the NUMBER opcode returned 26,169,834 while the chain height was 85,905,911, and the L1 number advanced 85 over 10,000 Robinhood blocks in 1,022 seconds. The 10-block window therefore lasts about two minutes as a 10-step staircase, and traders during that time pay up to 30% to the vault when the spec says the fee should already be zero. No local test can observe this, so there is no proof file, only the reproduction commands.

3. Low. The fee rounds down while the reservation rounds up. A 3-wei buy pays no fee, and a 1-wei refund claim is minted on nearly every fully filled IMD-specified swap. Confirmed with a scratch test using the project's own fixture.

Dropped or merged: nothing was dropped; the seven specialist entries collapsed into these three root causes. The Slither strict-equality and uninitialized-local leads are false positives: the == 0 checks are intentional guards and the locals are deliberately zero-defaulted.

Coverage: all seven listed entry points answered, plus rows for beforeSwap, the manifest, address bits and size limits, and the existing suite. The suite passed locally with 96 tests and 2 fork tests skipped. The token is unmodified OpenZeppelin ERC20 and the manifest matches the constructor and permission bits.

Fixed the anti-snipe clock to use Robinhood’s local blocks.

All findings are answered in .imd-responses.json. Refund and rounding behavior remains, with documented disputes and explicit claim-aware router requirements.

Validation passed: forge build, formatting, 75 local tests, and 26 Robinhood fork tests.

Deployment must re-mine the CREATE2 salt for the updated hook.

Updated tests for Robinhood’s local block clock and added regressions for independent clocks and refund redemption after fee expiry. Only test/ changed.

• forge build: passed.
• Offline tests: 120 passed, 2 fork setups skipped.
• Live Robinhood fork: 32 passed, no skips.
• Invariants: 36,864 calls, zero unexpected reverts.

I've settled both earlier findings and the advisory, and I'm reporting no findings this round. I found nothing new I could reproduce. .imd-findings.json has an empty findings list and a coverage row for all 7 entry points, each marked holds, plus two invariant rows.

Earlier findings:

• Anti-snipe clock counted Ethereum blocks (medium): fixed. SPEPEHook.sol:102-107 now reads the block height from ArbSys.arbBlockNumber(). It only falls back to block.number where ArbSys has no code. I checked the live Robinhood RPC: ArbSys has code (0xfe), and arbBlockNumber() returned 85943558, the same as cast block-number. So on the real chain the hook counts 10 Robinhood blocks, not ten 12-second Ethereum blocks.
• Fee reserved up front can leave a seller owing IMD (medium): I accept the author's dispute and have dropped it. I ran my proof again on the revised code and it still fails the same way (-22858142807145357017865 < 0), so the behaviour hasn't changed. But the brief expressly allows reserving the fee on the specified side and refunding the excess "to the swapper as an ERC-6909 claim". Cash plus the refund claim gives the correct net, and afterSwap can't adjust the swapper's specified side. The author did the minimum I asked for: launch.json notes, the README and the accounting doc now say that during the fee window, exact-input buys and exact-output sells need a router that handles these claims. They also explain the negative IMD delta on a sell and the risk of claims getting stuck in a router. New tests cover both kinds of router.
• Rounding (advisory): accepted as a design choice and dropped. Rounding the fee down keeps it at or below the fee rate on what filled, which the brief requires. The 1-wei refund on a full fill is documented.

Other checks:

• Reservation always covers the fee: it does in both modes, so the refund can't go negative, including when the reservation is capped at 2^127·rate/BPS.
• Size and config: both contracts are within the size limits (hook: 5,730 bytes deployed, 43,422 of headroom on creation code). The token mints the full 1e27 to its deployer, and foundry.toml matches the required settings.
• Test run: the full suite passed, 120 tests with 2 skipped. The one failure was my old proof, as expected.
• Slither leads: the strict-equality and uninitialized-local warnings are just zero checks and zero defaults, so I didn't report them.

Besides the findings file, I briefly copied the proof into test/scratch/ and deleted it after the run.