Implemented contracts, ABI exports, deployment documentation and vendored dependencies.

Verified:

• forge build
• forge test: 64 passed
• Six mainnet-fork tests passed
• forge fmt --check

The README documents operational assumptions and the conflict between the brief’s “no new token” requirement and the mandatory launch token for independent launch review.

Created launch.json matching the accepted token and constructor arguments.

Schema and ABI checks passed. forge build passed; forge test reported 72 passed, 0 failed, and 1 fork suite skipped.

Notes preserve the unresolved brief/policy conflict. Only launch.json is delivered.

Added four test files under test/ covering failure paths, payout boundaries, quote comparisons, and token/jackpot invariants.

• forge build: passed.
• forge test: 99 passed, 0 failed, 1 offline fork skip.
• Invariants exercised 32,768 randomized calls.
• No reproducible defects found.

Live mainnet-fork verification remains outstanding for this run.

The math audit is complete. The findings file is in place with an empty findings list and a full coverage record, and no source file was changed. The scratch test directory has been removed.

Result: no reproducible defect in the Math Precision, Boundary or Numerical Gap areas. Every formula that moves value was checked against exact reference arithmetic, against the vendored Uniswap v4 core, and against the verified mainnet LaunchpadHook source.

What I verified, and how:

• Payout formulas in _draw. The 90% expression available/10*9 + available%10*9/10 equals floor(available*90/100) for every uint256 (5000-run fuzz against FullMath.mulDiv plus an exhaustive sweep of small values). The capped prize fee > cap/20 ? cap : fee*20 equals min(20*fee, available/10) for all fees up to int128.max. The roll mapping yields exactly one 77 and five multiples of 20 per 100 words. Slither's divide-before-multiply lead on line 321 is therefore not a defect.
• Fee accounting on all three routes. Sell floors 1% of input (at most 99 wei short, and documented). Buy floors 1% of gross ICE, and output plus fee equals gross. Throne splits ethIn into fee leg and player leg that sum exactly to the settled value. Refund arithmetic cannot underflow because msg.value ≥ ethIn is enforced first.
• Quoter parity. The tick walk, fee composition and protocol-fee split mirror Pool.swap. The curve buy and sell formulas, the order of creator and burn fees, and the floor rounding match the Sourcify-verified hook line for line. I re-ran the six fork rehearsal tests at block 26087742 through publicnode. All pass with exact quote equality, and the real ICE payout succeeded inside the 100k sub-call and 500k callback budget.
• Custody invariant. ICE balance never drops below totalClaimable, because claimable grows only by a failed payout bounded by pot() and shrinks only before a transfer that must move exactly that amount.
• VRF fee. The quote and the wrapper's charge both derive from tx.gasprice with the same gas limit and word count. The real wrapper accepted the exact amount and the excess was refunded.

Coverage: all 12 listed entry points are marked holds with reasons, plus three invariant rows. Nothing was left unreached. The only design observations outside my area, such as the fixed jackpot odds being identical for a 0.001 ETH ticket and a 10,000 ICE ticket, follow the brief as written and were not reported as defects.

Review complete. The findings file is written at the repository root and no tracked file was changed.

Outcome: one high finding with a runnable proof, one low design-level note, one informational policy conflict, and all 12 entry points covered.

Finding 1 (high): a third party can void any pending ticket, including a winning one. The VRF callback in src/PepeJackpot.sol:203 is gated by the contract's own reentrancy flag and routes through a PoolManager unlock it does not need. Anyone holding the oracle's proof can submit it to the Chainlink coordinator themselves, since that entry has no caller restriction, and the wrapper swallows a reverting consumer callback and deletes the request. So a griefer front-runs the oracle's transaction with the same proof wrapped either in their own PoolManager unlock or in a 1 wei dust trade whose refund re-enters them. The jackpot reverts, the request is consumed, and the ticket expires unpaid. Because the roll is computable from the proof, the blocking can be selective: only payouts get denied, and every other pending ticket holder benefits from the pot that stays. I verified both Chainlink facts against the published 1.4.0 sources. The proof test under test/scratch fails on the current code for this reason and passes with a minimal fix that draws directly from the callback without the guard or unlock.

Finding 2 (low): ticket routes are economically asymmetric with identical odds. A 0.001 ETH throne puts about 0.00001 ETH of ICE into the pot yet gets the same 1 percent chance at 90 percent of the pot as a 10,000 ICE sale. Once the pot exceeds roughly the VRF fee divided by 0.009, dust tickets are positive expectation for anyone. This matches the brief's thresholds and payout table, so it is reported as a design decision for the requester rather than a defect.

Finding 3 (info): the release-scope conflict is still open. The brief says no new token, pool or liquidity, while the launch policy deploys PJACK and a PJACK/ETH pool the jackpot never uses. The builder documented it correctly. No manifest exists in the tree yet. The exported ABI files match fresh compiler output exactly.

Coverage. All 12 listed entry points have rows: 11 hold, the VRF callback carries finding 1. Access control on the unlock callback, the self-only payout helper, claim, expire and the constructor traced clean, with no owner, rescue, receive or delegatecall path. The fork rehearsal against the live hook and wrapper was not rerun here.

The review is complete. The findings file is written, all three quoted snippets match the tree, and my scratch tests are removed so no source or test file is changed.

Outcome: no critical, high or medium defect in the control flow. The jackpot's execution paths hold under the Execution Trace, Periphery and First Principles checks. Three findings are recorded, one low and two informational, all about launch configuration and design rather than code.

What I verified

• Every value action runs in one authenticated PoolManager unlock. The callback requires the manager as caller, the reentrancy flag set, and a one-shot hash of the exact unlock payload. Foreign or replayed callbacks revert.
• Both fridge routes and the throne route settle every currency before the ETH refund. The refund reentry probe that tried take on the manager during the refund reverted the whole trade with CurrencyNotSettled, so the debt lands on the attacker, never the pot. A reentered claim was rejected.
• The VRF callback path was measured from the wrapper address with exactly the fixed 500,000 gas budget. The worst path, a prize whose transfer fails and lands in claim storage, used about 167k. Ticket state becomes terminal before the isolated payout call.
• The pot accounting invariant holds. Reserved claims are credited only from the available pot and decremented together with the balance on claim.
• The quoter's tick traversal, fee selection and bitmap search match v4-core Pool.swap. The exported ABIs are byte-identical to forge inspect output.
• The full offline suite passes: build, 64 tests, fmt.

Findings recorded

1. Low, configuration gap. The constructor accepts codeless addresses by design. I reproduced deploying the five mainnet addresses on chain 11155111: deployment succeeds and every entry point, including the view pot(), reverts forever. The manifest review needs launch.chainId == 1, the exact five constructor arguments, and code evidence at each address.
2. Info, policy conflict. The brief says the project creates no token, pool or liquidity, but the launch must deploy PJACK and seed an ETH/PJACK pool. The builder documented this. The manifest review must surface it as a requester decision.
3. Info, design, outside my area. Every eligible ticket has expected value of fee plus 0.9% of the pot, so minimum-size grinding drains the pot in expectation. This matches the requested rules and is flagged for the economics reviewer.

Coverage: all 12 listed entry points have rows, all holds, plus six invariant and manifest rows, two of which point at findings 1 and 2. What I could not reach offline is the real LaunchpadHook curve formula in the quoter, which only the mainnet fork rehearsal verifies.

Review complete. The findings file is written, its snippets match the tree, and the working tree has no changes besides the ignored findings file and the scratch proof.

Outcome: one High finding, one informational note, all 12 entry points covered.

High: any third party can burn a winning ticket's VRF fulfilment. The callback in rawFulfillRandomWords routes the draw through a fresh poolManager.unlock even though the draw never touches a pool. Uniswap v4 rejects a nested unlock with AlreadyUnlocked. Chainlink's v2.5 coordinator lets anyone submit the oracle's proof once it is in the public mempool, and the direct-funding wrapper swallows a consumer revert and deletes the request. So an attacker front-runs the oracle, submits the fulfilment from inside their own unlock, the jackpot's callback reverts, and the ticket stays Pending until it expires unpaid. The winner loses up to 90% of the pot plus fee and VRF fee. A rival holding pending tickets profits by keeping the pot intact. The proof at test/scratch/FulfillInsideUnlock.t.sol fails on the current code and passes when the draw is called directly without the nested unlock. I verified that fix on a temporary copy and restored the source.

Info: ticket expected value is size-independent. The 20x branch alone returns the fee in expectation, and the 77 branch adds 0.9% of the pot per ticket. At a 1,000,000 ICE pot, ten 10,000 ICE trades yield 91,000 ICE expected payout versus 10,000 ICE for one 100,000 ICE trade with the same pot contribution. This matches the approved brief, so it is recorded with numbers rather than as a defect.

Leads checked and rejected:

• Callback gas: measured 137k direct and 167k deferred against the 500k budget.
• Payout math: floor(90%) and min(20×fee, pot/10) are exact for all integers.
• Pot conservation: balance always equals pot plus reserved claims.
• Refund reentrancy, pot front-running around fulfilment, slippage and settle accounting all hold.

Not reached: the launch manifest does not exist in the tree yet. The coverage record notes the five constructor addresses must be the mainnet dependencies and never a $token or $owner reference.

Review complete. The findings are in .imd-findings.json at the repository root, the tracked tree is unchanged, and the only files I created are the findings file and two scratch tests under test/scratch/.

Outcome: four findings kept from eight specialist entries, one high.

• High, kept and merged from the permissions and economics areas. VRF fulfilment is routed through PoolManager.unlock and the contract's own reentrancy guard, although the draw never touches the pool. Anyone who relays the oracle's proof from inside their own unlock, or from the refund callback of a 1 wei dust trade, makes the authenticated callback revert. The Chainlink wrapper swallows that revert and consumes the request, so a winning ticket stays pending and expires unpaid. I reproduced both vectors with a self-contained proof that fails on this tree and passes with the minimal fix of calling the draw directly from the callback and gating the payout helper on self-call alone. The fix also breaks two existing tests that encode the old routing, which I named in the finding.
• Low, kept from the flow area. The constructor accepts codeless addresses by design, so a launch on any chain other than mainnet deploys and is bricked. Reproduced locally. The needed action is release evidence of chain ID 1 and the five addresses, not a source change, since a constructor code check would fail the offline protected floor.
• Info, merged from two areas. The brief says no new token, pool or liquidity, but the manifest necessarily declares PJACK and an ETH/PJACK pool. The manifest is otherwise schema-valid, its addresses match the README in constructor order, and the ABI exports match compiler output.
• Info, merged from three areas. The jackpot roll pays 90% of the pot regardless of ticket size, so minimum tickets are positive expected value once the pot is large. This matches the brief exactly and is recorded as a design confirmation with the numbers.

Dropped or downgraded: none dropped outright. The permissions specialist's low on ticket asymmetry was folded into the design note at info, since the code implements the brief's own table.

My own pass over all twelve entry points found nothing beyond the specialists' items. Every slither and aderyn lead traced to intended behaviour: the refund goes to the trade's own caller, the balance-delta checks are the transfer guard by design, the floor arithmetic is exact, and the flagged unused constant is in fact used by the payout helper. Coverage answers all twelve entry points plus three invariant and manifest rows.

The responses file is in place at the repo root; it is excluded by the harness's own git exclude rather than the project gitignore, which is expected for a harness-consumed file.

Recap

High finding (VRF fulfilment blocked by locks): reproduced and fixed. Both vectors from the report failed on the unmodified tree with the exact message the reviewer quoted. The cause was confirmed: rawFulfillRandomWords took the contract's reentrancy guard and routed the draw through PoolManager.unlock, although the draw only reads and transfers ICE. Changes in src/PepeJackpot.sol:

• Fulfilment now calls _draw directly, without the reentrancy guard. The wrapper sender check still gates it, and the ticket becomes terminal before the payout attempt, so replay and reentry into value actions stay blocked.
• The dead Fulfill action branch and enum member are removed.
• deliverPayout is gated on the self-call sender alone, no longer on the entered flag.
• claim() is left as it was, as the finding requested.

Tests: the roll-77 test now asserts zero unlock calls during fulfilment. Three regression tests cover the foreign-unlock relay, the refund-time relay, and replay or reentry from inside a delivery, with two new relay fixtures in the mocks file. The reviewer named one test to update that does not exist in this tree; the player-call rejection test still passes because the sender check remains.

Low finding (codeless dependency addresses): disputed, documented. The protected launch floor constructs the contract offline on a chain with no mainnet code, so any constructor code or chain check would fail it. The README deployment section now carries the admission evidence table the reviewer asked for, and the review notes hand it to the deployer.

Info finding (per-trade eligibility economics): disputed, documented. The implementation matches the brief exactly. The README now states the expected-value formula, the split-trade example and the positive-EV condition as a design property for the requester to confirm.

Verification results:

Check	Result
forge build	pass
forge test	69 passed, 0 failed, fork suite skipped locally
forge fmt --check	pass
ABI export	unchanged, matches forge inspect

The fork rehearsal was not re-run, since it needs a mainnet RPC. Its callback test impersonates the wrapper with a 500,000-gas budget and needs no change for the new routing.

The revision is complete. The manifest stays as accepted apart from one added sentence in its notes, and the advisory finding is answered as disputed.

What I found

• The single advisory finding reports a real conflict: the approved brief says the jackpot creates no token, pool or liquidity, yet launch.json declares LaunchToken (PJACK) and an ETH/PJACK pool.
• That conflict is not a manifest defect. The evm_project kind cannot launch without the token and pool, LaunchToken is present in the accepted tree with the exact name, symbol and decimals the manifest states, and the supply split comes from policy rather than from the manifest.
• The PepeJackpot entry matches the accepted implementation. Its five address constructor arguments are the PoolManager, ICE, LaunchpadHook, IMD and the VRF wrapper, in the order the constructor in src/PepeJackpot.sol declares them. The contract never references PJACK.

What I changed

• launch.json notes gained one sentence recording what the reviewer asked for: resolution needs a recorded requester decision accepting PJACK and the ETH/PJACK pool alongside the game, and the launch site must not present PJACK as the jackpot's asset since the pot is ICE.
• .imd-responses.json answers the finding with verdict disputed and explains the reasoning and verification above.

Verification

• launch.json passes the LaunchManifest schema and refinements. Notes are 1,459 characters.
• forge build is clean. forge test passes 67 of 67 tests outside the mainnet-fork suite.
• The protected token suite, run from test/scratch with the manifest's decimals and the compiled creation code, passes 6 of 6 including the decimals cross-check.
• The protected project suite needs the verifier's factory environment variables and could not run locally.
• git status shows launch.json as the only tracked change.

Done. The suite is green again on the revised source and the revision's new behaviour is now covered under random sequences.

What was wrong. The implementer's revision made oracle fulfilment lock-free and gated deliverPayout on the self-call sender alone. My accepted adversarial test still expected a revert when pranking as the jackpot itself, which is not a reachable caller on chain, so it failed against the revised code.

What I changed, only under test/:

• test/PepeJackpotAdversarial.t.sol
  • The gate test now asserts that the manager, the wrapper, a player and the test contract are all rejected by deliverPayout, and that the pot and player balance are untouched.
  • New test: a winner whose token receipt re-enters seed during an unguarded oracle payout. The exact balance check rejects the delivery, the nested action rolls back with it, the prize is reserved for claim, and the later claim pays in full. Witnessed through the Drawn event's deferred flag and balances.
  • New test: a callback that tries claim or expire on the settling ticket finds no credit and a terminal ticket, so nothing pays twice.
  • The mock token gained a callback mode and a ReenteringWinner helper to drive these.
• test/PepeJackpotInvariant.t.sol
  • The handler now delivers words through three contexts: the wrapper directly, a relay inside a foreign PoolManager.unlock, and a relay from the ETH refund of its own sub-threshold trade while the jackpot's guard is held. All existing failure modes apply to each context, the relay's own fee is folded into the expected pot, and the relay's trade and refund are checked.
  • A deterministic sequence test covers a relayed jackpot, a relayed deferred prize, a relayed replay of a drawn ticket, and a late relay that expires.

Verification.

forge build --offline   ok
forge test --offline    105 passed, 0 failed, 1 skipped (fork test, guarded)
forge fmt --check       ok

The invariant campaign ran 256 runs at depth 64 with zero reverts, and the relay path was exercised about as often as the direct one. No defect in the revised implementation reproduced, so no .imd-findings.json was written.

Saved .imd-findings.json.

• VRF denial finding: fixed; both regressions pass.
• Dependency and economics advisories: settled as deployment/design assumptions.
• Retained one informational finding: unresolved PJACK token/pool scope conflict.
• All 12 entry points covered; no new Solidity defects reproduced.
• 105 project tests and 8 protected tests passed. Mainnet fork not rerun.

No source or configuration files changed.