Implemented the launcher with 1 billion PG, 5% beneficiary allocation, 95% LP allocation, IMD pairing, 2.5% inclusive tax, and no decay.

All 36 tests pass, including offline with the supplied fuzz seed. forge build and forge fmt --check pass.

Before launch, the owner must set a fresh IMD/USD quote. Valuation rounding, deployment steps, and retained token-admin powers are documented in README.md. No transactions were broadcast.

Created launch.json for PlaygroundLauncher with $owner.

Manifest structure and constructor ABI checks passed. forge build succeeded; all 36 tests passed with the supplied fuzz seed. Only launch.json changed outside the permitted scratch directory.

I found no defects in PlaygroundLauncher that need fixing. .imd-findings.json holds one info-level trust note and a coverage record with a row for both entry points plus four invariants. No repository files were changed; the scratch tests I wrote under test/scratch/ have been deleted.

Checks run:

• Existing suite: all 36 tests pass.
• Pre-launch front-run of the pool: a stranger initialising the PG/IMD pool at the predicted PG address, before launch, at a price of their choosing. The hook reverted that call, and launch() still succeeded afterwards. Holds.
• Live mainnet state:
  • The factory's implementation is the requested one, and the hook's protocol fee is 15 bps.
  • IMD is registered and enabled as a pairing base, with symbol "IMD" and 18 decimals.
  • The factory and hook code hashes match the test fixtures.
  • The beneficiary 0xcB58… is a plain wallet, not a contract, so it can move its 50M PG freely.
• Mainnet-fork rehearsal (simulation only, nothing broadcast): with an assumed IMD price of $1, setImdUsdPrice then launch() gave 50M PG to the beneficiary and 950M PG to the pool. A buy and a sell through the live IMD→ETH conversion pool both paid the beneficiary in ETH. The beneficiary could also send PG to another wallet.
• Checked against the brief:
  • Supply split: 1e27 total = 50e24 to the beneficiary + 950e24 to the pool.
  • Tax: 250 bps. The 15 bps protocol share comes out of the 250, as the brief asks, on both buys and sells. There is no launch decay.
  • Price: the opening price targets $20,000 FDV. Rounding to the tick grid can raise it by up to about 0.6%, which the README discloses.
• Static-analysis leads, all rejected:
  • Reentrancy (slither/aderyn): the factory is a fixed address and nothing calls back into the launcher. Both functions that change state are owner-only, and _launching is set before the external call.
  • Ignored return at line 91: the call is there only to validate the price.
  • "Unsafe ERC20" at line 154: both the return value and the resulting balances are checked.
  • Timestamp warnings: they enforce the one-hour price expiry on purpose.

The info note (trust assumption, not a bug): launch() passes token ownership to $owner (src/PlaygroundLauncher.sol:158). The README names 0x1EE3… as that owner, which is not the beneficiary. A test confirmed that the owner can call setFeeRecipient and setTaxBps after launch and redirect the beneficiary's 2.35%. The README discloses this and the brief doesn't say who should own the token. If the requester wants the fee terms enforced after launch, the smallest change is to hand ownership to the beneficiary instead.

Not covered:

• I couldn't audit the hook's source because it isn't verified. My checks ran its deployed bytecode only.
• The IMD/USD price is entered by the owner rather than read from an oracle. That is by design and disclosed, so its accuracy is the owner's responsibility.

The economics audit found one low-severity issue and nothing critical, high or medium. .imd-findings.json holds that finding plus a coverage row for each of the two entry points and four extra rows for the invariants and leads I checked. No repository files were changed, and my scratch tests are deleted.

The finding (low): src/PlaygroundLauncher.sol:158 hands control of the token to the launch owner (0x1EE3…413d in the README), who is not the beneficiary 0xcB58…ddaC. After launch that owner can raise the tax to 5% or send the beneficiary's 2.35% to any other address, at any time. I confirmed both changes go through after a local launch. The README and docs/SECURITY.md already disclose this, so it is a trust assumption rather than a bypass. I reported it because the brief asks for neither an owner nor a changeable tax. Each possible fix needs your decision:

• hand the token to the beneficiary instead;
• give up ownership after launch, which also removes the ability to approve smart-wallet integrations later;
• explicitly accept the changeable terms.

What holds against the brief:

• Supply: 1,000,000,000 PG, with exactly 50,000,000 (5%) to 0xcB58… and 950,000,000 in the locked LP position. The only leftover is tiny rounding dust, which stays locked in the token contract. Nobody can withdraw the position.
• Tax: 2.5% on buys and sells. The 0.15% protocol share comes out of the 2.5%, not on top: the hook on mainnet reports 15, and the swap tests with the real deployed code show the protocol gets 15/250 of fees. There is no launch decay fee.
• Starting valuation: the price formula gives at least $20,000 and at most about 0.6% more, because the pool can only start on fixed price steps. This holds whichever way the token address sorts against IMD. The dollar figure depends on the IMD price the owner enters; nothing on-chain checks it.
• Recipients: both the beneficiary and owner addresses are plain wallets on mainnet, so fee payouts in ETH can't be blocked by a contract refusing them.
• Static-analysis leads: the reentrancy warnings don't hold. Every call goes to fixed, known contracts, only the owner can launch, and any failure undoes the whole launch. The timestamp, return-value and ERC20 warnings are intentional checks.
• Pre-launch interference: I tested whether someone could set up the pool early at a bad price, since the token's address is predictable. The hook refuses it and the launch still succeeds.

Worth knowing, not reported as defects:

• At this valuation liquidity is thin. With IMD at $1, one buyer spending $20,000 gets about 474M PG, roughly 47% of supply. That follows from the brief's $20k start with no decay fee.
• The hook's own source isn't published, so I judged its behaviour from tests run on its live code and from on-chain reads, not from reading its source.
• The IMD-to-ETH pool used to convert fees and the hook's admin are outside this contract's control.

All 36 existing tests pass.

The review is complete and .imd-findings.json holds the result. No source file was changed and the scratch probe was removed.

Outcome: no defect in the launcher's permission model. The audit covered the Access Control, Trust Gap and Asymmetry guides against src/PlaygroundLauncher.sol, with the factory and ERC20T reference sources read for the inherited behaviour.

What I verified:

• Access control. Only two state-changing entry points exist, and both carry the same onlyOwner plus beforeLaunch guards. There is no weaker writer of any storage slot, no receive or fallback, no initializer, no proxy, and the owner is immutable and validated against zero, self, and every protocol address. Reentry during the factory call is blocked by the in-progress flag. The static-analysis reentrancy leads are not exploitable because the only reentrant path requires the owner and is refused.
• Asymmetry. The price setter's bounds mirror the reader's exactly. The config handed to the factory matches the post-launch assertions field for field. Preview and launch use the same dependency checks and price source.
• Live state. Through a public RPC I confirmed the factory's implementation, the hook's pool manager and 15 bps protocol fee, IMD registration and symbol, and the position manager bindings all match the constants. The owner and the beneficiary are both EOAs.
• Existing suite. All 36 tests pass.

One info-level entry, recorded as a trust assumption rather than a bypass. After launch, ownership of the PG token passes to the launch owner, who can call setFeeRecipient and setTaxBps on the token. I measured it: after those two calls, a 100 IMD buy paid the beneficiary nothing and paid the new recipient about 4.86 ETH at a 5% tax. The brief's "2.5% to 0xcB58..." therefore holds only while that owner leaves the settings alone. Making the terms permanent would mean the launcher keeping token ownership or the owner renouncing, which removes other documented operator powers, so that is the requester's decision and the file says so.

Also checked and found harmless: the shared hook's administrator can only delay the launch before it runs, and disabling IMD afterwards did not stop trading or beneficiary payouts. The global distributor registry cannot move PG between ordinary wallets.

Coverage rows are written for both listed entry points, the constructor, and five invariants. Nothing was left unreached.

The review is complete. The findings file at .imd-findings.json holds two low-severity findings and eleven coverage rows, with both snippets verified against the tree and the JSON parsed cleanly.

What I covered. The Math Precision, Boundary and Numerical Gap passes over PlaygroundLauncher, traced through the verified factory and ERC20T sources and exercised against the real deployed bytecode in the fixtures. I also checked the live mainnet state through a public RPC. The owner's price formula, the factory's tick alignment, supply conservation, the 250/15/235 basis-point tax split, the one-hour freshness window, and the reentrancy guard all hold. Third-party pre-initialization of the predicted PG/IMD pool is rejected by the real hook. Every live dependency value matches the launcher's constants, including the three fixture code hashes.

Findings, both low.

• Unbounded price input on an irreversible launch. The launcher accepts any IMD/USD price from 1 to 2e31 and the factory launches at every one of them. A scale slip such as typing 1e16 for a $1 IMD launches at a $2,000,000 valuation with the liquidity locked forever. A plausibility window on the input is the minimal fix.
• Launch readiness tied to IMD's mutable symbol. The dependency check compares the IMD symbol string, which the IMD owner can change through its live updateSymbol function. A rename permanently disables both launch and preview, confirmed with the real IMD runtime. The check protects nothing since the IMD address is a constant.

Not reached. The hook's internal fee conversion arithmetic, since its source is unverified. Only its observed runtime split was checked.

Numbers worth recording for the author:

The two scratch tests under test/scratch/ reproduce the probes and are not part of the submission.

Added failure-path, fuzz, and invariant tests under test/, covering launch retries, permissions, supply and fee conservation, and both token orderings.

forge build passed. Full suite passed with the required seed: 55 tests, 49,152 invariant calls, zero failures.