Implemented the mainnet launch path with 880 million DCA (88%) at 0.002 FWA/DCA, using the specified operator and fee recipient.

forge build, forge test — 196 tests passed — and forge fmt --check pass.

Launch runbook documents parameters, assumptions and responsibilities. The operator must configure the liquidity range and supply its quoted FWA funding. No mainnet transactions were sent.

I've written the Ethereum mainnet launch for DCA paired with FWA, without the fault that got the last attempt rejected. forge build, forge test (168 tests, all passing) and forge fmt --check all pass. Slither now reports nothing above informational: only three notes about long number literals in embedded contract code. Nothing was deployed, signed or committed.

How the launch works (src/DCAMainnetLauncher.sol)

• The operator 0x1EE3…413d is the launcher's owner. They call launch(salt) once, and the whole launch happens in one transaction:
  • it creates the DCA token, with the full 1,000,000,000 supply minted to the launcher;
  • it deploys the existing 5% FWA fee hook at an address prepared in advance;
  • it opens the DCA/FWA pool at a 2,000,000 FWA market cap (0.002 FWA per DCA);
  • it puts 88% of the supply into the pool as DCA-only liquidity;
  • it sends the other 12% to the operator.
• The price, supply, 88% share and fee recipient are fixed in the code. The operator's only input is the salt, and there are no settings to change after deployment.
• The rejected fault is gone. The launcher only ever spends tokens it holds itself. There is no transferFrom and no approval anywhere.
• Fees: the hook's 5% FWA fee and the pool's 1.25% trading fees both go to 0xCAE0…4b. Anyone can trigger the payouts, with hook.claimFees() and launcher.collectFees().
• If something fails: a wrong salt or any other error undoes the whole transaction, and the launch can be retried.
• I also fixed the other warnings from the last review in DCAHook and DCAHookLauncher. Return values that were ignored are now checked, and events and state changes now come before outside calls.

Script (script/MainnetLaunch.s.sol)

• deploy() deploys the launcher with the operator and the Uniswap v4 PoolManager address.
• prepare(launcher, start, attempts) is read-only. It checks mainnet, the owner, the PoolManager and FWA's settings, finds the hook salt, and returns the exact zero-value transaction for the operator to sign, with every expected number.

Choices I made where the brief was open (all documented in the README):

• Liquidity is locked forever. Nothing can withdraw the 88%, including the operator.
• No FWA goes into the pool. Because the pool holds only DCA, it can't start exactly at the opening price. Liquidity begins at most about 0.5% above it, so the first buyer pays up to that much more.
• Trading fees go to 0xCAE0…4b too. I read "send fees to 0xCAE0…" as covering them as well as the 5% hook fee.
• No IMD platform fee share is paid by this route.
• The 12% goes entirely to the operator. The earlier launch plan's 10% for the swarm and 2% remainder are not split out by the contracts; that is now the operator's decision.

Things to watch:

• Deploy only DCAMainnetLauncher. Don't use it alongside the older DCAHookLauncher route, or you'd end up with two DCA tokens.
• FWA's owner controls FWA's transfer rules. If the PoolManager stopped being an FWA distributor, FWA swaps and fee payouts would fail.
• Passing tests is not an audit. A separate independent review is still needed before launch.

The README has the full parameter tables, the launch steps and an "After launch" section. SECURITY.md and test/ADVERSARIAL_TESTS.md record the security cases and failure tests.