The constructor refuses team_ == vault_ because IMD paid to the vault can never leave it (the vault has no function that moves anything but its asset, and IMD is not its asset). propose() has no such check: the admin can propose the vault, the router itself, or address 0x...dEaD, and handOn() then calls factory.setRequester(launchNumber, next). From then every claimFees pays the requester's 80% of both tokens to that address.

For next == vault the $IMDUEL joins the reserve (fine) but every IMD fee is stranded in the vault for ever; for next == address(this) the router keeps collecting, which is harmless. Only the admin can trigger it and the 3-day notice gives time to notice a typo, so this is an admin-mistake guard, not an exploit; it is reported because the constructor's own symmetric check shows the intent.

Fix: in propose(), revert InvalidSetup() when next == vault (and optionally when next == address(this) or next.code.length == 0 is not what is wanted).

By design the admin (launch wallet 0x6AA302EFf055259c9Cf177f33Ae3cBA5d4135B23 in launch.json) can propose any address and, between 3 and 6 days later, hand the launch's requester share (80% of the 1% trade fee, both tokens, for ever) to it; collect() is run first so nothing accrued is stranded. lock() renounces that for good.

There is no owner of the vault and nothing else is adjustable; no minting, pausing, freezing, seizing, delegatecall, selfdestruct, proxy or initializer exists in either contract. The IMD token at 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 is a LayerZero OFT (OpenZeppelin ERC20 transfers, owner can only rename it), and $IMDUEL is a fixed-supply plain ERC-20, so SafeERC20 forwarding cannot be blocked by a blocklist or pause.

Also read: the live PoolFees/LaunchFactory source from Sourcify (claimFees does not revert when nothing is owed and keeps a failed payout as owed; setRequester requires the current requester and a non-zero next), and the hook's public imduel()/imd() getters.

Read in full: src/IMDuelStaking.sol, src/IMDuelFeeRouter.sol, src/IMDuelToken.sol, launch.json, test/Staking.t.sol, test/FeeRouter.t.sol, the protected checks, OpenZeppelin ERC4626 (v5.0 in lib). Read for the router's dependencies: the live LaunchFactory/PoolFees source (Sourcify, exact match) and the IMD token source (Sourcify, exact match); the hook's imduel/imd getters in src/IMDuelHook.sol.

Not reached: the rest of IMDuelHook, ChessEngineV5 and the chess libraries (out of scope, already live), the v4 PoolManager path inside claimFees, and the mainnet fork test (test/StakingFork.t.sol needs an RPC).

Checks made and found clean: release/reserve/staked conservation and the share price never falling (the project's invariant suite passes: 35 staking and router tests run here, all pass); deposit/withdraw settle before every supply change so release is never backdated; uint128 casts bounded by the 1e27 supply; _keep overflow-free; donation to the vault never moves the share price; first-deposit inflation bounded by the dead stake (price per share-wei at most reserve/1e18); no reentrancy (plain tokens, trusted factory); handOn cannot skip collect; claimFees cannot be made to revert by a third party; launch.json has the schema's keys, 1 and 7 constructor words in declaration order, a backward $contract reference, static owner addresses the brief states, notes under 4,000 characters, no forbidden opcodes.

Documented privileged power, not a bypass (Pashov: report owner powers as trust assumptions). launch.json sets both team_ and admin_ to the same EOA 0x6AA302EFf055259c9Cf177f33Ae3cBA5d4135B23.

The admin's propose()/handOn() path moves the factory's requester role for launch 2843 away from the router, after which 100% of future fees (both the IMD the team already receives and the $IMDUEL the vault's reserve receives) go wherever the admin named; nothing in the vault or router protects stakers' expected future reserve inflow.

Mitigations present and verified: NOTICE = 3 days before handOn (line 108), a stale proposal expires NOTICE later (line 109), handOn collects first so fees accrued up to the handoff still go by the old split (line 110), lock() is one-way (line 119), and only the current requester can call the factory's setRequester (verified in the Sourcify source of LaunchFactory/PoolFees.sol: reverts NotRequester otherwise, and ZeroRequester for address 0).

Related asymmetry, admin-error only: propose() validates exactly one stuck destination (the vault, line 97) but accepts others that can never call setRequester back, e.g. address(this), the factory, the hook, the PoolManager or 0x...dEaD; a handOn to one of those strands every future fee of launch 2843 permanently (the factory only lets the current requester hand on).

No unprivileged amplifier exists for either point, so this is recorded as the trust surface for the judge, not as a defect.

Periphery / execution-trace: the router's constructor makes five external calls before it stores anything: factory_.positionOf (line 72), duel.imduel() and duel.imd() (line 78), IERC4626(vault_).asset() (line 79) and ISync(vault_).sync() (line 82). Every one of them is a high-level Solidity call, so each reverts when the target address holds no code.

The brief requires exactly this ('the router's constructor reads the live LaunchFactory ... so it must run against mainnet state'), and the behaviour is correct on mainnet: I confirmed from the verified source of 0x12C63b581d07093F6126bc02263c58f7EadaA96F (Sourcify) that positionOf(uint64) returns (PoolKey, int24, int24, address) with no revert path, that claimFees has no access restriction and does not revert on zero fees, that it pays by ERC-20 transfer (not ERC-6909), and that setRequester reverts NotRequester for anyone but the current requester.

The IMD token 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 is an OpenZeppelin 5.4 ERC-20 (BridgedFP) with no transfer gating. The LaunchFactory's ABI has only launch(LaunchParams) and no launchContracts, so the contracts-only project factory the protected harness etches (Contracts.protected.t.sol, vm.etch(factory, probe)) is a different address and does not overwrite what the router reads.

What remains is a service-side requirement, not a code defect: the recipe states the launch checks run constructors on an empty chain, and on an empty chain application 1 (the router) fails with 'application 1 constructor failed' and the launch parks. This was previously reported as e1d42d70 and deliberately retained; the repository's own test test_emptyChainCannotSubstituteForMainnet reproduces it.

Evidence needed before deployment: the protected Contracts.protected.t.sol run executed against an Ethereum mainnet fork (block with launch 2843's position present), e.g. forge test --fork-url $ETH_RPC --match-test test_exactLaunchOnMainnet, which the ADAPTATION.md author could not run (RPC unreachable).

If the service cannot fork, the only code-level alternative is the recipe's lazy pattern (store the addresses, validate on first collect), which contradicts the brief and is the requester's scope decision.

Math Precision / Boundary (break downcasts). _deposit books _pool.staked += uint128(assets) (src/IMDuelStaking.sol:68): the narrowing cast truncates silently, and the author relies on the following safeTransferFrom of the full assets reverting because no holder owns 2^128 $IMDUEL (fixed supply 1e27 < 2^128 ~ 3.4e38).

That reliance holds on the live token, so no value can be lost: every deposit of assets >= 2^128 reverts (verified: deposit(2^128), deposit(2^128+1) and mint(2^200) all revert, and the pool stays at 1e18 staked).

What remains is an ERC-4626 conformance deviation: EIP-4626 says maxDeposit MUST NOT be higher than the amount deposit would accept assuming the caller has infinite assets, and maxMint likewise, yet both return 2^256-1 while the packing accepts at most 2^128-1-staked assets. An integrator that sizes a call from maxDeposit and then calls deposit (the EIP's stated use) gets a revert instead of a bounded value.

No funds at risk; the token's supply makes the truncating branch unreachable.

The per-second release rate is scaled by f = redeemable/supply (the share fraction outside DEAD), but the released amount is added to staked, which backs every share pro rata, DEAD's 1e18 included. Live stakers therefore receive f * (f * base) of the reserve per second and the fraction f * (1 - f) of the base rate is credited to DEAD's shares, which can never be redeemed: it is burned reward budget.

The leak is maximal at f = 0.5, i.e. when the live stake equals the dead stake's one token, and it is exactly the state a public vault is in right after the seed if the first depositor stakes about one IMDUEL before anyone stakes materially.

Nothing in the vault enforces a minimum initial live stake; the fork rehearsal (test/StakingFork.t.sol _release) avoids the state by staking 1,000,000 IMDUEL for the launch wallet before sending the seed, but launch.json's notes describe only 'funds the vault and hands the launch's requester to the router', so the operational order that keeps the leak at 1e-6 is undocumented.

The code comments ('a dust stake enables only a dust rate', 'the dead stake's cut: 1 / (all staked)') describe the 1-wei case; a one-token stake, which costs nothing, enables half the base rate and burns a quarter of it.

Who loses: the reserve (the project's reward budget and future fee income) and every later staker; who gains: the first small staker, whose one token is worth ~25,063 IMDUEL after a day while it is alone.

Minimal fix that preserves the design: before the seed is sent, stake a material amount for the launch wallet (the fork test's order) and state that order in the launch notes/runbook, so f is ~1 from the first second; alternatively, distribute the release only over redeemable shares (e.g. use the ERC-4626 virtual-share offset instead of real DEAD shares), which is a design change.

Verification note: forge could not be executed in this review session (the command sandbox failed to start), so the figures below are computed from KEEP and the suite's own dailyKeep constant (test/Staking.t.sol line 106) rather than from a run.

Merged from audit_economics (reproduced by tracing _now(); forge could not be executed in this review session, so figures derive from the suite's own asserted constant dailyKeep = 994987437252023507328880933 at test/Staking.t.sol:106, which the passing suite checks against the code to 1e-15). The per-second rate is scaled by f = redeemable/supply (line 101) but the released amount is added to staked (line 103), which backs every share pro rata, DEAD's 1e18 included.

Live stakers therefore receive ff of the base release and f(1-f) of it is credited to DEAD's shares, which can never be redeemed (DEAD has no key; test_theDeadStakeIsForever).

The leak peaks at f = 0.5, i.e. when the live stake equals the dead stake's one token, which is exactly the state right after the seed if anyone stakes about one IMDUEL before a material stake exists; nothing in the vault enforces a minimum live stake and the launch.json notes describe only 'vault funding and sync to establish the dead stake', not the fork rehearsal's order (test/StakingFork.t.sol _release: the launch wallet stakes 1,000,000 IMDUEL before the seed), which keeps the dead cut at ~1e-6.

The contract comments ('a dust stake enables only a dust rate', 'the dead stake's cut: 1 / (all staked)') hold for a 1-wei stake and for a million-token stake, but a one-token stake, costing nothing, enables half the base rate and burns a quarter of it.

Who loses: the reserve (the project's reward budget and future fee inflow) and every later staker; who gains: the first small staker (one token worth ~25,063 IMDUEL after a day while alone).

Severity low: loss of reward budget only under a specific, avoidable operational state, no principal at risk. Minimal fix preserving the design: stake a material amount for the team before the seed is sent, and state that order in the launch notes/runbook (the fork test already does it). Design alternative (scope decision): distribute the release only over redeemable shares, e.g. replace the real DEAD shares with the ERC-4626 virtual offset.

Merged from audit_flow; reproduced by tracing.

The constructor makes five high-level external calls before storing anything: factory_.positionOf (line 72), duel.imduel() and duel.imd() (line 78), IERC4626(vault_).asset() (line 79) and ISync(vault_).sync() (line 82). positionOf returns data, so on a chain where 0x12C63b581d07093F6126bc02263c58f7EadaA96F has no code the ABI decoder reverts on empty returndata; the vault's own sync would also revert there (IERC20(asset()).balanceOf on a code-less token).

This is what the brief demands ('it must run against mainnet state and reverts on any wrong argument') and the behaviour is correct on mainnet: the verified LaunchFactory source on Sourcify shows positionOf(uint64) is a view with no revert path, claimFees(uint64) has no access restriction, pays by ERC-20 transfer and does not revert on zero fees (its _split/_payAccount return early on amount == 0), and setRequester reverts NotRequester for anyone but the current requester and ZeroRequester for address 0.

What remains is a deployment-rehearsal requirement, not a code defect: the recipe states launch checks run constructors on an empty chain, and the supplied Contracts.protected.t.sol does not fork (it only sets chainId and etches ContractsDeploymentProbe over IMD_PROJECT_FACTORY). On an empty chain application 1 reverts and the launch parks; if IMD_PROJECT_FACTORY were the LaunchFactory address itself, the etch would also break positionOf.

Previously reported as e1d42d70 and deliberately retained by the author (ADAPTATION.md).

Severity low: no funds at risk; the launch either deploys correctly against mainnet or parks. Evidence needed before deployment: the protected run executed against an Ethereum mainnet fork (block with launch 2843's position present and the live hook 0xA92F72DcDd90229C32F6d51229F4cc5c916410CC), e.g. forge test --fork-url <Ethereum RPC> --match-test test_exactLaunchOnMainnet, which neither the author nor this review could run (no RPC/shell).

The only code-level alternative is the recipe's lazy pattern (store addresses, validate on first collect), which contradicts the brief and is the requester's scope decision.

Merged from audit_math; reproduced by tracing. _deposit books _pool.staked += uint128(assets) (line 68): the narrowing cast truncates silently, and correctness relies on the following SafeERC20.safeTransferFrom of the full assets reverting because no holder owns 2^128 IMDUEL (fixed supply 1e27 < 2^128 ~ 3.4e38; IMDuelToken has no mint).

That reliance holds on the live token, so no value can be minted or lost: every deposit of assets >= 2^128 reverts with InsufficientBalance, and mint(2^200) reverts the same way. What remains is an EIP-4626 deviation: maxDeposit/maxMint MUST NOT exceed what deposit/mint would accept assuming infinite assets, yet both return 2^256-1 while the packing accepts at most 2^128-1-staked. An integrator sizing a call from maxDeposit gets a revert instead of a bounded value.

Non-behavioural fix: return type(uint128).max - _now().staked from maxDeposit and _convertToShares(that, Floor) from maxMint when the supply is non-zero, or document the deviation.

Merged from audit_permissions; documented privileged power, not a bypass. launch.json fills both team_ and admin_ with $owner. The admin's propose()/handOn() path moves the factory's requester role for launch 2843 away from the router, after which 100% of future fees (the IMD the team already receives and the $IMDUEL the vault's reserve receives) go wherever the admin named; nothing in the vault protects stakers' expected future reserve inflow.

Mitigations verified in code: NOTICE = 3 days before handOn (line 108), a proposal expires NOTICE after maturity (line 109, the d944c9f4 fix: handOn is possible only for readyAt <= now <= readyAt + NOTICE), handOn collects first so fees accrued to the handoff follow the old split (line 110), lock() is one-way and cancels a proposal (line 119), and only the current requester can call the live factory's setRequester (Sourcify source: NotRequester otherwise, ZeroRequester for address 0).

Related, admin-error only: propose() validates exactly one stuck destination (the vault) but accepts others that can never call setRequester back, e.g. address(this), the factory, the hook, the PoolManager or 0x...dEaD; a handOn to one of those strands every future fee of launch 2843 permanently. No unprivileged amplifier exists, so this is the trust surface for the judge, not a defect.