Implemented the fresh IMDPot contract and prepared the existing website integration. Deployment parameters and operating steps are in README.md.

Passed forge build, 42 Solidity checks, forge fmt --check, 12 frontend tests, and 4 release-tool tests.

Live deployment and website publication remain pending the launch service’s confirmed address.

Anvil end-to-end validation was blocked by this machine: Operation not permitted (os error 1).

Created launch.json for a fresh IMDPot deployment with $owner, matching the compiled constructor ABI.

forge build succeeded; all 42 tests passed with the specified fuzz seed. Only the manifest changed.

Deployment, owner token configuration, and website publication remain subsequent launch steps.

The review is complete and the findings file is written. Nothing in the tracked tree was changed; only the ignored scratch test and .imd-findings.json were created.

Outcome: the contract's arithmetic holds across my whole area. I found no defect in the Solidity math, one low-severity boundary mismatch in the website, and one info-level rounding note.

What I checked (Math Precision, Boundary, Numerical Gap guides):

• Every division in _settle: floor shares for burn, treasury, lock, second and third prize, with dust to first prize. Prizes plus fees always equal the pool, and first prize never underflows since it is at least 40% of the pool.
• Overflow limits: per-purchase weight is at most 2e10 and amount at most 1e23, so no intermediate can overflow; uint64 deadline cast is safe.
• Winner selection: modulo by the tree total is never zero, the Fenwick find never returns a zero-weight interval, and remove of one unit always succeeds for a found winner.
• Boundaries: entry closes exactly at endTime while finalize opens there; settle is valid through drawBlock + 256 and cancel from drawBlock + 257; paused cancel at exactly endTime + 1 day.
• Loyalty cap: pending boost plus any live restorable boost never exceeds 10,000 bps through any redeem, cancel and restore sequence.
• Real token: the mainnet IMD token read from the previous contract is an OpenZeppelin v5 ERC20 (LayerZero OFT) with 18 decimals and no transfer tax, so every share divides exactly and the 150k fee-transfer gas budget is ample.
• Scratch fuzz in test/scratch/MathProbe.t.sol ran 256 cases over decimals 1 to 18, up to 1,000,000 tickets per buy and maximum boost weights. All passed, as did the repository's 42 tests and the 12 web unit tests.

Findings recorded:

1. Low, web/game-rules.mjs:34. The settle button reads ready at head equal to drawBlock + 256, but a transaction sent then is mined one block later and reverts with DrawExpired.
2. Info, src/IMDPot.sol:312. With a 1-decimal token a one-ticket pool pays 100% to the winner because all fee shares floor to zero. Not reachable with the 18-decimal IMD token.

Coverage: all 16 entry points have rows, 15 holds and the web rules module finding, plus two invariant rows. No entry point was left unreached.

Review complete. The findings and the full coverage record are in .imd-findings.json; no tracked file was changed, and the only scratch test lives under test/scratch/.

Outcome. The control flow of IMDPot holds up under the Execution Trace, Periphery and First Principles passes. I traced all 16 entry points, the Fenwick tree library, and the conservation invariant, and reran the existing suites. Two findings are recorded, neither critical or high.

• Low, cancelRound at src/IMDPot.sol:340. An ended round's two permissionless recovery paths are mutually exclusive on the owner-controlled paused flag. Cancel needs paused, the first finalize phase needs unpaused. An owner that flips the flag in front of each third-party transaction keeps the round Active forever, with the pool stuck. This contradicts the README and SECURITY.md claim that the 24-hour timeout protects participants from a malicious owner. The sequence is demonstrated in test/scratch/OwnerHostage.t.sol. Suggested fix: let the commit phase of finalizeRound run while paused once the round has ended, or let the paused-round cancel ignore the pause after the delay.
• Info, setToken at src/IMDPot.sol:206. I probed the live address the README tells the owner to configure. It is a Sourcify-verified LayerZero OFT named BridgedFP, with owner-renamable name and symbol and revert strings reading "FPHyperLiquid". Its supply on Ethereum is mintable through the token owner's bridge peers. Transfers are plain OpenZeppelin ERC20, so the exact-transfer checks and 150k fee stipend are compatible. Since setToken is one-shot, this is worth confirming against authoritative records before configuration.

What I checked and found sound. Deadline and draw-window boundaries, the 3-block commit, zero-hash rejection, prize and fee rounding with dust to first prize, ticket-level removal in the draw, boost consumption and restoration, the single unsettled loyalty record, reentrancy guarding including the isolated fee self-call, exact transfer checks on both directions, and the obligations-equals-balance invariant. The 42 Foundry tests, 12 Node tests and 4 Python tests all pass. Slither and Aderyn leads were all either guarded by the reentrancy lock or benign strict-equality on enums.

Not reached. The end-to-end Anvil and browser run connecting the site to a deployment was not executed here, matching the README's own limitation, so the website wiring row is marked unreached.

The review is complete and .imd-findings.json holds four findings plus a coverage row for all 16 entry points. The working tree is otherwise untouched: the only new files are the findings JSON and the ignored test/scratch/ probe.

What I audited

The Access Control, Trust Gap and Asymmetry guides against src/IMDPot.sol, with the Senior Auditor's Mindset first. I mapped every role and guard, diffed paired paths (buy vs refund, settle vs cancel, user vs owner variants, getPlayer vs _syncPoints), and checked each privileged setter for in-flight value redirection. The existing 42 tests pass. I also read the live chain over a public RPC to check the trust assumptions the code bakes in.

Findings, most severe first

1. Medium: house fee beneficiary hardwired to the owner wallet. The constructor takes only owner_ and sets TREASURY to it with no setter. The contract this launch replaces pays its 5% fee to a different treasury wallet than its owner, so the new deployment silently redirects every house fee to the owner wallet, irrevocably. The release tool also refuses any deployment whose treasury differs from that owner, so a $owner that resolves to a different payer wallet can never be connected to the website. The fix is an explicit treasury constructor argument. The requester must confirm the intended fee wallet before deploying.
2. Low: owner cannot rescue fee-on-transfer foreign tokens. The rescue path reuses the exact-transfer check meant for the game token, so taxed or rebasing third-party tokens revert forever. Confirmed with a scratch test.
3. Info, trust assumption: pause gives the owner a 24-hour hold on a closed round and the choice between settlement and refund at the deadline. No fund loss and no randomness edge, but players cannot force either outcome.
4. Info: weightOf and totalWeight diverge for cancelled rounds after refund. View-only, untested by the invariant suite.

What holds

Ownership is two-step with zero and self rejected, renounce is disabled, every owner function is guarded, transferFee is self-call only, setToken is one-shot with decimal checks, and no admin setter alters in-flight value. The live IMD token is a plain OpenZeppelin ERC20 wrapped as a LayerZero OFT, with no tax or blocklist and a 35k-gas transfer, so the exact-transfer and 150k fee-gas assumptions hold on mainnet.

Not reached

Deep economic modelling of block-producer randomness bias and the Privy bundle internals under web/assets-future-v1/ are outside my area and were not reviewed beyond ABI equality.

The review is complete. The findings file at .imd-findings.json holds two findings and a coverage row for every one of the sixteen entry points. The working tree is otherwise untouched; the scratch tests live only under the ignored test/scratch/ directory.

What I checked

I ran the three assigned guides (Economic Security, Invariant, Flow Gap) over src/IMDPot.sol and the Fenwick tree library, after the Senior Auditor's Mindset section. The existing 42 tests pass. I added scratch probes that fuzz loyalty-boost cap and point crediting across cancel, refund and settle interleavings, settle a round with a million 2x-boosted tickets, binary-search the minimum gas for settlement to see fee deferral behave, and check dust allocation. All invariants held: the token balance always equals the summed obligations, prize shares always sum to the pool, and pending plus live boost never exceeds the cap.

Because the Economic Security guide turns on how the real asset behaves, I pulled the live IMD token's verified source from Sourcify. It is a plain OpenZeppelin ERC20 inside a LayerZero OFT wrapper with no fee, cap, pause, blocklist or transfer hook, so the fee-on-transfer, max-wallet and gas-starvation vectors do not reach this deployment. I also confirmed the website modules call only functions and events the contract exposes, with matching shapes.

Findings

• Medium, draw targeting. The commit at src/IMDPot.sol:278 fixes the draw block only three blocks ahead, and anyone may commit at any time after the round ends. Ethereum publishes proposers up to 64 slots ahead, so a validator or builder waits until the block three ahead is its own, commits, and then grinds candidate block contents until the hash selects its own ticket. In the scratch reproduction a 1% ticket share took the 40 IMD first prize of a 100 IMD pool after 339 candidate hashes. The brief chose blockhash randomness and the README documents producer influence, so I framed this as an amplification of the accepted risk with a design-preserving mitigation: a draw delay beyond the lookahead window, or a word derived from several consecutive hashes. No proof file is attached because the fix is a design decision with a cadence trade-off.
• Info, fee beneficiary. The treasury is frozen to the deployment owner at src/IMDPot.sol:159, so after a two-step ownership transfer the former owner keeps every future 5% fee. The README calls this deliberate. It is recorded as a trust assumption for the requester to confirm before the irreversible launch.

Not covered

Static-analysis leads about reentrancy and strict equality were traced and rejected: every value-moving path is guarded, the self-call is restricted to the contract itself, and the equality checks are on enum status values. I did not run the Anvil site integration test, which the README also reports as blocked in the worker. Areas outside economics, such as the frontend bundle internals and Privy login, were only checked to the extent they touch contract calls.

Added failure-path, fuzz, winner-selection, and accounting invariant tests. Only test/ changed.

• forge build: passed.
• forge test with the required seed: 62 passed, zero failures.
• New invariants exercised 32,768 random calls.

No implementation defects reproduced. Live deployment and website integration remain unverified.

I reviewed the code and kept two low-severity findings. Nothing reaches medium or higher, so no Foundry proof was required. The findings and coverage are in .imd-findings.json, and I changed no tracked files.

The build passes and all 62 project tests pass. The contract fits the size limits: 13,680 bytes deployed (limit 24,576) and 13,938 bytes of creation code (limit 49,152). launch.json is valid against the schema, and its one argument ($owner) matches constructor(address owner_).

Kept:

1. Low: the website's settle deadline is one block late (web/game-rules.mjs:34, if (head > target + 256n) return {). When the latest block is exactly drawBlock + 256, the site still shows "Settle winners". A transaction sent then is mined in block drawBlock + 257, where finalizeRound() reverts with DrawExpired (src/IMDPot.sol:284). For example, with drawBlock = 100, at block 356 the site offers settlement and the player pays gas for a revert. The site's pre-send simulation doesn't catch it, and the cancel button stays hidden for that block. The existing test at test/web.test.mjs:63 asserts the wrong boundary.
2. Low: rescueForeignToken can't recover fee-on-transfer tokens (src/IMDPot.sol:411). It reuses the game token's exact-transfer check. If a token sent by mistake delivers 99 when 100 is sent, the rescue reverts every time, and those tokens stay stuck for good.

Dropped or merged:

• Treasury paid to the owner (raised by two specialists; medium and info): dropped. The live site's ABI for the updated contract also has only constructor(address owner_), so a fixed owner beneficiary is the agreed design. I did confirm on Ethereum mainnet that the old contract paid fees to a separate wallet (0x0b17…F118, distinct from owner 0x3428…28EA). Fees will now go to the owner wallet, so the requester should confirm that's what they want.
• Draw block only 3 blocks ahead (medium): dropped. With future-blockhash randomness, which the requester asked for and the README documents as producer-influenceable, any block builder can buy the target slot however long the delay is. The suggested fix doesn't remove that.
• Owner keeps a round stuck by toggling pause (low): dropped. At any moment either cancel or commit is open, so the owner would have to front-run every single attempt. A private transaction or one call that checks the pause first gets around it.
• 24-hour pause hold, mismatched weight views, rounding with 1- or 2-decimal tokens, re-labelled bridged token: dropped. They are either documented trust assumptions or views and token setups that can't change the planned deployment's money flows.

Coverage: I answered all 16 entry points. rescueForeignToken is marked as having a finding; the other 15 hold. I also added a row for the balance-conservation invariant and one for the manifest.

Not run: I didn't execute either finding as a test; both rest on tracing the code. The repo's Anvil end-to-end test (test/site.integration.mjs) wasn't run either; the author's README says it couldn't run in their worker.