The IMD Index build is in the working tree and passes forge build, forge test (215 tests, 0 failed) and forge fmt --check on solc 0.8.26. I did not commit, because the rules put .git/ off limits.

What was built

• LaunchToken — IMD Index / IMDEX, fixed 1,000,000,000 supply, 18 decimals, no admin surface.
• TimelockedAdmin — timelock plus role table. One address holds at most one role and the admin wallet holds none.
• AssetRegistry — token allowlist, price feeds, weight caps, approved routers and every bounded parameter.
• EpochManager — verifies quorum-signed EIP-712 proposals against the hard rules, holds them for a delay, re-checks at activation, and anchors daily report hashes.
• IndexVault — vIMDEX shares, deposits at oracle NAV, in-kind redemptions that no pause, oracle or keeper can block.
• RebalanceExecutor — the only trading path: delta-only, reserve buffer, oracle price floor, router allowlist, weekly window, quarantine after repeated failures.
• FeeWaterfall — the 40/25/20/10/5 split on-chain, changed only through the timelock.
• FeeHook and FeeHookDeployer — the v4 hook collects the fee in the quote currency on all four swap shapes and never trades the basket.

Docs are README.md, docs/METHODOLOGY.md, docs/SECURITY.md and docs/PROPOSAL.md (the milestone proposal the brief asked for).

Where this differs from the brief

• IMDEX is not the vault share. The launch token must be fixed-supply, so index shares are a second token, vIMDEX.
• The fee hook cannot sit on the launch pool. The launch pool gets the network's own guard and fee, so the hook works on a second v4 pool for the same pair. Moving liquidity there is your decision.
• The hook is deployed after launch. A v4 hook needs a mined address, so the launch deploys FeeHookDeployer and anyone then calls deploy(salt).
• The 25% LP share never reaches the waterfall. It is applied as the pool's LP fee; the hook collects the other 75%.
• No role exists at launch. Only $owner is available to a constructor, so guardian, signers, keepers and executor are assigned through the timelock afterwards. Until then deposits are closed and nothing can trade.
• CoW Swap is not integrated. Execution is route-agnostic with an on-chain oracle floor; a CoW adapter is milestone M5.
• No mainnet-fork tests. The verifier has no network; they are listed as required before real funds.

Checks

• The hook tests run inside the real Uniswap v4 PoolManager, with native ETH and with an ERC-20 quote on either side of the pair.
• I ran the two protected launch-floor tests locally against the built artifacts with the seven application contracts and mainnet literals; all nine pass.
• The invariant suite found one real defect, now fixed and covered: a sale too small to buy one unit of the target token had a price floor of zero.
• The five mainnet addresses in the README (PoolManager, USDC, WETH, USDC/USD and ETH/USD feeds) returned code and the expected names from a public RPC today. They are constructor arguments, not constants.
• Slither, Mythril and long fuzz campaigns were not run. Passing tests are not an audit.

Open decisions for you

• Reserve asset, USDC or WETH; it is fixed at launch.
• The guardian, signer, keeper and fee-recipient wallets, and the quorum (two recommended, one accepted).
• The named lead agent and human technical owner; I left both unnamed rather than invent them.
• Starting numbers I chose where the brief gave none, all changeable through the timelock:
  • minimums of $250M market cap, $5M liquidity and $5M daily volume;
  • 1% total swap fee, 1% maximum slippage, 2% reserve buffer, 2.5% drift threshold;
  • 6-hour proposal delay and 2-day timelock;
  • rank-buffer thresholds in the methodology.

runtime reported , not the required premium model claude-fable-5-1

Created launch.json with seven contracts in dependency order and ETH/WETH configuration.

Schema and constructor checks passed. forge build succeeded; forge test passed all 224 tests, including protected checks.

Only launch.json changed outside permitted scratch scaffolding.

Added adversarial tests and randomized custody/accounting invariants.

forge build and forge test pass: 246 tests, zero failures.

Reported two defects with failing proofs in .imd-findings.json:

• Strict redemption can silently forfeit unreadable assets.
• Stale research snapshots can activate.

Mainnet-fork validation remains outstanding.

The review is complete. The findings file is at .imd-findings.json in the repository root, and no tracked file was modified. The only new paths are the findings file and my test/scratch/ directory, both of which git ignores.

Outcome: 4 substantiated findings, 60 coverage rows (54 hold, 6 point at findings, none unreached).

Findings, most severe first:

1. High. The guardian can veto its own replacement and the timelock's unpause. TimelockedAdmin.cancel has no exception for operations that limit the guardian, and those operations only reach the chain through a schedule-delay-execute path whose id is public. A hostile or compromised guardian key can pause, revoke every signer and keeper, and then cancel every re-grant, unpause and setGuardian forever. Only in-kind redemption survives. The security document claims the opposite limit. Proof test attached; it fails today with NotScheduled().

2. Medium. The executor's _nav reads held-token balances with an uncapped staticcall, while the vault caps the identical read. A basket token whose balanceOf burns gas, which the trust model names as a threat, leaves the keeper's call with 1/64 of its budget, and every trade of every member then dies out of gas. Quarantine does not help, and after disposal the token is never dropped from the held list, so the executor is bricked until replaced. Proof test attached with a 30M gas budget; the same test with the burn switched off passes.

3. Low. Executor and vault disagree on what a member position is. The executor prices by raw vault balance, the vault only by its held list. A stranger who transfers a target's worth of a member token to the vault blocks the keeper from buying it, and holders never see it. The griefer loses the tokens to the timelock's rescue, which bounds the impact.

4. Low. failureCount is not reset by releaseQuarantine, so after a release one failed trade re-quarantines the token instead of three.

Coverage. I traced all 57 listed entry points plus three invariants (role exclusivity, executor-only asset movement, delta/buffer/window/floor on trades). The Access Control, Trust Gap and Asymmetry guides were applied in full to the timelock, registry, epoch manager, vault, executor, waterfall and hook. Leads I examined and dropped because the design intends them or the trigger is purely privileged: recipient changes not settling accrued protocol buckets, permissionless stale-feed quarantine followed by a keeper exit sale, and keeper-forced quarantine via underfunded gas. Not covered: economic correctness of fee math and NAV rounding, which belong to other specialists.

The review is complete. .imd-findings.json holds 4 findings and a 60-row coverage record (all 57 listed entry points plus 3 invariants). The working tree is otherwise unchanged; the scratch tests were removed after running, with the two proof sources embedded in the JSON.

Findings

• Medium, src/TimelockedAdmin.sol:146. The guardian can cancel any scheduled operation, and setGuardian, unpause, setSigner, setKeeper and setExecutor exist only as scheduled operations. A hostile or compromised guardian therefore pauses the system, revokes signers and keepers, and vetoes every repair, including its own replacement, forever. The docs claim "the timelock can replace the guardian and lift a pause"; it cannot. Only in-kind redemption survives. Proof test attached: it fails with NotScheduled() today.
• Low, src/EpochManager.sol:332. A proposal with zero tokens passes every hard rule, and additions are only counted when the active basket is non-empty. A quorum can activate an empty basket, then five brand-new members one epoch later, bypassing MaxAdditionsPerEpoch. An empty basket also makes every held position an exit, sellable with no window or drift threshold. Proof test attached.
• Low, src/RebalanceExecutor.sol:271. The rebalance window is anchored to the keeper's first trade of an epoch, not to activation as the README and methodology state. A keeper that has not traded yet may open a fresh two-day window at any moment, confirmed by a trade 20 days after activation.
• Info, src/RebalanceExecutor.sol:124. The keeper-forced quarantine is documented, but the failure counter also rises when a third party sandwiches an honest keeper's trade below the floor. Three such fills quarantine the member and open its unrestricted exit path.

Coverage. All entry points in the FeeHook, FeeWaterfall, IndexVault, AssetRegistry, LaunchToken and FeeHookDeployer were traced and hold. The hook's BeforeSwapDelta and afterSwap return-delta signs were checked against the vendored v4-core Hooks library for all four swap shapes. The _swap try/catch rollback, vault lock, approval reset and output measurement hold. The slither reentrancy and strict-equality leads were traced and are not reachable defects. Not run: Slither, fork tests, long fuzz campaigns.

The review is complete. Findings are in .imd-findings.json with a coverage row for every one of the 57 listed entry points; no tracked file was changed (git status is clean apart from the findings file and the scratch proof, which are not kept).

What I found (5 findings, 1 medium, 4 low)

1. Medium, IndexVault deposit pricing. The vault's NAV counts a held token at full oracle value even after the registry has quarantined it, and the vault cannot tell that the token refuses transfers. A depositor who enters after such a quarantine pays for a slice they can never withdraw. Measured: Bob deposits 100,000 USDC and an immediate round trip returns 82,282 USDC, with the difference credited to earlier holders. Anyone can amplify it by calling pushBasketReserve(0) to make the treasury buy in at the inflated NAV. The self-contained Foundry proof at test/scratch/QuarantinedHoldingDeposit.t.sol fails on the current code and passes if deposits are refused or quarantined holdings are valued at zero.
2. Low, strict redemption. With strict=true, a held token whose balanceOf is unreadable is silently skipped rather than reverting, so the redeemer burns shares and forfeits that slice. Measured: Alice's full redemption left ~196,000 USDC of value in the vault with zero shares outstanding.
3. Low, FeeHook beforeSwap. When the quote currency is the specified amount, the fee is charged on the requested amount, so a swap that stops at its price limit pays fee on unfilled volume. Measured in the real PoolManager: 750 USDC fee on ~100 USDC executed.
4. Low, AssetRegistry reserveDecimals. The registry's copy of the reserve decimals is never verified against the token or the vault, unlike the vault's copy. With registry=18 and vault=6 the oracle floor is 1e12 times too low and a keeper fill of 196,000 USDC for 0.000000000098 T0 is accepted.
5. Low, ProposalDelay bound. paramBounds allows a 7-day delay, which equals the 7-day validity cap, so every expiry is rejected as either too soon or too far and no proposal can be published until the parameter is changed again.

Coverage. I traced the arithmetic in the vault share formula and virtual offset, the waterfall split and its relation to the hook's per-swap record, the hook fee on all four swap shapes, the executor's delta, buffer, drift-threshold and oracle-floor rounding, the registry's price scaling and conversion, and the epoch timing boundaries. The remaining entry points hold on the paths in my area. Not reached: live non-standard tokens, mainnet feeds, and gas-bomb behaviour of a malicious held token inside the executor's uncapped balanceOf call, which I left as a lead rather than a finding.

The review is done. No tracked file was changed; .imd-findings.json and test/scratch/ are the only additions, and both are already excluded by the repository's git config.

What I found

I audited the economics (Economic Security, Invariant and Flow Gap lenses) across the hook, waterfall, vault and executor. The existing 215 tests pass. Nine defects are recorded in .imd-findings.json, three with Foundry proofs that fail on the current code:

Medium, with proofs

1. FeeHook charges the quote-specified fee on the requested amount, not the filled amount. In v4 the trader's delta is swapDelta - hookDelta, so a partial fill keeps the full-request fee. Against the real PoolManager: a sell-exact-output of 1,000 quote filled with 0.99 quote cost 7.5 quote in fees, leaving the trader negative in both currencies. An exact-input buy that exhausted the range paid 7,500 on 350,715 traded.
2. A keeper can liquidate the entire basket in one block. Three self-made failing swaps per member auto-quarantine it, a quarantined token has target zero, and target-zero sales skip the delta, drift and window rules. The proof moves a 1.15M USDC vault to all reserve and costs holders 9,800 USDC.
3. Same-block deposit at feed NAV plus in-kind redemption captures feed lag from existing holders. With every member up 1.9% and feeds inside their deviation threshold, the attacker turns 1,000,000 USDC into 1,009,310 and Alice loses the same amount. The README names the latency, but not that the arbitrage is atomic and flash-loanable.

Low (reproduced, no proof) 4. An untransferable held token with a dead feed closes deposits and the basket-reserve push permanently. 5. Dust positions below one reserve unit can never be sold via the keeper path and keep a held slot. 6. Strict redemption silently forfeits the slice of a token whose balanceOf reverts. 7. Anyone chooses when the treasury buys shares via pushBasketReserve, with minShares zero. 8. The rebalance window opens at the keeper's first trade, not at epoch activation, contrary to the README. 9. RebalanceExecutor._nav calls balanceOf uncapped and before the quarantine check; a gas-burning member costs ~29.5M gas per trade.

Coverage

All 57 listed entry points have a row (54 holds, 7 finding, 0 unreached), plus four invariant rows. The timelock and launch-token entry points were traced lightly since they sit outside my area. Not covered: mainnet-fork behaviour with live tokens, feeds and routers, and long fuzz campaigns.

Fixed 16 findings and recorded all 17 verdicts in .imd-responses.json.

One advisory is disputed: deposits remain closed for unpriceable, untransferable holdings to preserve existing holders’ claims. The limitation is documented.

Validation passed: forge build, forge fmt --check, and all 251 tests, including supplied proofs, fuzz tests, and invariants.

could not restore accepted work: accepted work conflicts with a dependency, which plan validation should have prevented:

Updated only launch.json, clarifying quarantine and redemption behavior while preserving deployment values.

Validation passed: supplied schema, constructor ABIs, forge build, and all 256 tests, including the protected checks.