Implemented the launch contract, polished retro-punk website, offline dependencies, and deployment documentation.

Passed: forge build, 42 Foundry tests, formatting, 13 JavaScript tests, and browser checks.

The factory already has five tokens, so “first-ever” is unavailable. No mainnet transaction was broadcast; the owner’s confirmed launch will supply the actual token address and transaction hash.

Created launch.json for ERC20TLaunch with $owner.

Manifest structure and compiled constructor ABI match. forge build succeeded; all 42 tests passed with the required fuzz seed. Only launch.json is included in the change.

Review complete. The findings file is written at the repository root with an empty findings list and ten coverage rows, and the scratch tests are removed so the tree is unchanged.

Outcome: no substantiated defect in the assigned area. The single entry point, ERC20TLaunch.launch, holds under the Execution Trace, Periphery and First Principles checks. Everything I claim was run against the captured mainnet runtimes of the factory, token implementation, hook, PoolManager and PositionManager, with all 42 Foundry tests and 13 JavaScript tests passing.

What I traced and confirmed:

• Guards and ordering. Owner, chain 1, Ready status, price bound, deadline bound and dependency codehash plus configuration checks all run before the status flips to Launching. The factory call is the only state-changing external call. A reentrant call from an owner callback fails the Ready check, so the slither and aderyn reentrancy lines are not exploitable.
• Postconditions before writes. Token config, the exact 50M owner balance, 950M in the PoolManager plus bounded dust, exactly one new position NFT owned by the dead address with nonzero liquidity, and a pool key equal to the sorted token/IMD pair with fee 0, spacing 60 and the expected hook. Any failure reverts the factory creation too.
• Boundaries. I launched at 1 wei, the 1e18 maximum and the suggested price with the token as currency0 and as currency1. All succeed, the opening tick matches the request, and the position range runs from the opening tick to the maximum tick rounded to spacing, so liquidity is single-sided.
• Residuals and custody. The real factory resets the token's Permit2 allowance to zero after the mint. The application holds no ETH or tokens, has no receive or fallback, and records no privilege for itself. The factory only puts the application address in event topics.
• Site periphery. Price parsing, valuation, tax schedule, receipt parsing, ordinal derivation, full-range history scan with reorg check, and the two-step simulate-then-send flow with an explicit chain id all behave as documented.

What I could not reach: the internals of the source-unverified external infrastructure beyond what the captured bytecode shows through ABI probes, emitted logs and the existing swap and fee tests. One non-finding is recorded as a note for the judge: a launch with the first-only flag off would still revert if the nonce-2 slot were empty while the factory nonce had advanced, but that state is unreachable on mainnet because that slot already holds code.

I found one economic issue, rated low. The launch contract itself behaves as specified. The project's 42 Foundry tests pass, and the working tree is unchanged: I deleted my scratch tests, and .imd-findings.json (one finding, seven coverage rows) doesn't appear in git status.

The finding: the 99% launch tax doesn't really apply to the owner. tokenConfig() (src/ERC20TLaunch.sol:104) makes the owner both fee recipients, as the brief asks. The hook converts the collected tax to ETH and pays it to that recipient. So the one wallet that also holds the 5% liquid creator allocation and the token's admin role gets almost all of the tax back. I measured it on the recorded mainnet state:

• Owner: in the launch block, a 10 IMD buy returned 181,214 ERC20T plus 0.0225 ETH. That ETH swaps back to 9.69 IMD, so the net cost was about 0.31 IMD.
• Outsider: the identical buy right after returned 181,146 ERC20T and nothing back.

So for the whole 98-minute window that prices everyone else out, the owner can buy near the opening price, or sell the 50M creator tokens, for about 1–3% instead of 99%. The README, site and docs never say this. Since the brief asks for owner-paid fees, I've reported it as a disclosure and trust gap, not a demand to change who gets paid. The fixes it suggests are a prominent disclosure, or (with the requester's approval) sending decay fees to the protocol, which the brief already allows.

Checks that held:

• Pre-initializing the pool: no outsider can set up the v4 pool at the token's predictable address before launch to grief or misprice it. The hook rejects it at low, middle and high starting prices.
• Dodging the tax: exact-output buys and sells are rejected by the hook, during the launch window and after.
• Freezing trading: a fee recipient that rejects ETH doesn't stop trades, and the payout still lands. The owner address is a plain wallet (EOA) on mainnet.
• Supply: owner 50M plus pool plus at most 1e12 wei of rounding dust always equals 1 billion. This holds across the full price range and both token orderings.
• Locked liquidity: the position NFT is owned by the burn address, has liquidity, and nobody else is approved to move it.
• Tax schedule: decay starts in the launch block, 99% falling 1 point per minute to 1%.

Static-analysis leads: the reentrancy warnings are dealt with by the contract setting a "launching" status before it calls the factory, plus the existing callback test. The hash-collision warning is a fixed-length address calculation with nothing an attacker controls. The ignored return value is unused on purpose. None of them is a defect.

Not covered:

• I didn't check IMD's live price, so the roughly $3,000 starting valuation rests on the README's $5.55 figure.
• I didn't test what happens to trading if the IMD/ETH route the hook uses to convert fees fails or runs dry.
• Tax-avoiding trades through other, untaxed pools are a general issue for any taxed token, so I left them out.

The review is complete and .imd-findings.json holds the result.

Outcome. The permission model of ERC20TLaunch holds. The single entry point launch is owner-only, chain-pinned, sets its status guard before the one external write call, and re-verifies every token, allocation, pool and lock postcondition after the factory returns. I found one low defect and recorded one trust assumption.

Findings written

• Low, constructor guard asymmetry. The constructor at src/ERC20TLaunch.sol:77 rejects only the factory as owner. The hook, IMD, PositionManager, Permit2, PoolManager, implementation and conversion hook are all accepted, which would produce an application whose launch can never be called. Reproduced with a scratch test: deploying with the hook address succeeds while the factory address reverts.
• Info, trust assumption. The created token's ownership transfer is single-step and immediate, which the README does not say. Verified on the captured mainnet bytecode.

What I verified as holding, with evidence

• A storage-write scan across all nine dependencies after a real launch shows no role, allowance, ETH or token balance left with the launch contract. The token's owner and fee slots hold the designated wallet, and the Permit2 allowance is consumed and expired.
• Every privileged token entry point rejects an outsider after launch, including re-initialization of the clone and of the implementation.
• Swaps still succeed when the fee recipient or the hook's protocol recipient is a reverting contract, so there is no push-payment denial of service.
• The website's launch path checks runtime bytecode with the owner immutable, compares the on-chain owner to the configured owner before simulating and before sending, and forces chain id 1.
• All six static-analysis leads were traced and none is a defect.

Not reached. Hook internals beyond black-box swap tests, the web history-scanning code, and the tick range of the locked position, which the contract does not check.

Scratch tests were removed. The tree contains only the findings file as new content.

I found one low-severity defect in the launch math and one informational test gap; the rest of the math holds. Both are written to .imd-findings.json, along with a coverage row for the only entry point, ERC20TLaunch.launch(uint256,uint256,bool). The working tree is unchanged: the 42 existing tests still pass and I deleted my scratch tests.

Findings

1. Low — the price check doesn't enforce the "few thousand USD" market cap (src/ERC20TLaunch.sol:122). The only check is 0 < priceX18 <= 1e18, which allows a starting value anywhere from 1e-9 IMD to 1e9 IMD. On a mainnet fork at block 26,208,629, launch(1, now, false) succeeds and passes every after-launch check. After the 98-minute tax decay, a buyer spending 0.00000001 IMD gets 858.86M ERC20T, about 90% of supply. The launch can only happen once and the pool position is burned, so a wrong price can't be undone. Only the owner can call launch, so this is a missing safety check on an owner input, not a permission bypass. Suggested fix: limit the price to a band around the suggested 540_540_540_540, and apply the same band in the website (site/core.mjs:18).
2. Info — the offline test data can't simulate large trades (test/fixtures/MainnetState.sol). With the captured mainnet data, a 10,000 IMD buy fails with SafeCastOverflow in the IMD/ETH fee-conversion hook. On a live fork, buys from 0.001 up to 1,000,000 IMD all succeed. So the failure comes from incomplete test data, not the chain. Offline tests only cover trades of about 100 IMD or less.

What holds (checked by running it):

• Price range: launch works across the whole accepted range (from 1 up to 1e18, both token orderings). The supply always adds up exactly, and leftover rounding dust peaks around 5e8 wei, far below the 1e12 cap.
• Opening price: it always rounds to a 60-tick step in the creator's favour, and is exact at 1e18.
• Tax: it follows 99% minus 1% per 60 seconds, bottoming out at 1%. Even a 1-wei buy pays the right rate (18,474 token-wei received at 99%, 1,828,901 at 1%).
• Deadline: the 0 to 1,800-second window is enforced and can't underflow.
• First-token check: the first-token address calculation is correct.
• Pool hijack: an outsider trying to set up the pool for the next token address first is blocked by the hook.
• Website math: price parsing, the market cap (FDV) figure and the tax schedule display are correct.

Not reached: I didn't do a full economic or access-control review of the external factory, token and hook. I only probed them at the boundaries above.

Not findings:

• The hook rejects exact-output swaps. That's a design choice, not a math defect.
• Large sells stop at the price floor because single-sided liquidity can only absorb what buyers have put in. That's normal behaviour.
• The scanner leads on reentrancy, the ignored return value and abi.encodePacked didn't hold up in the math: the encodePacked input is fixed, and there's a launch-state guard.

None of the findings is critical or high, so neither includes a Foundry proof file.

The findings file is in place at the repository root (the harness excludes it from git on purpose), and the full delivered suite passes with the verifier's seed. Work is complete.

Summary

Delivered. Three new files under test/, all passing with forge build and forge test under the verifier's fuzz seed:

Suite	Tests	Result
Existing suites (unchanged)	42	pass
test/ERC20TLaunchEdges.t.sol	37	pass
test/ERC20TLaunchInvariant.t.sol + handler	2 (9 invariants, 48 runs × 32 depth)	pass

Invariant suite. test/helpers/LaunchInvariantHandler.sol drives the adapter and the real captured factory, hook and Uniswap runtimes with random launches from owner and non-owner callers, bounded buys, sells, transfers, burns, time warps and owner tax edits across three actors. Invariants check that launch happens at most once and only for the owner with valid inputs, status never rests in Launching, the adapter never holds ETH, IMD or tokens, total supply equals one billion minus voluntary burns, every token is held by a tracked address, the owner's 5% stays exact, IMD is conserved, the position stays owned by the burn address with unchanged liquidity, and the tax follows the decay schedule then the owner setting. A scripted liveness test proves each handler path actually fires, so the invariants are not vacuous.

Edge unit tests. Pinned price bounds of 1 wei and 1e18, the exact 30-minute deadline boundary, zero and max deadline, any other chain, the exact Launched event, every postcondition the adapter rejects (position id drift, position for another pool, token reporting a wrong owner, launched flag, tax, symbol, decimals, supply, dust, fee recipient), three more dependency-route mismatches, the owner's inability to move or approve the locked NFT, burnable supply, a stranger's lookalike token, and launch gas.

Findings reported in .imd-findings.json:

• Medium, with a failing proof test. The token created through the captured implementation rejects every holder-to-holder transfer with custom error 0x2f352531, before and after tax decay, including transferFrom and EOA-to-EOA. Only pool swaps and transfers to or from the owner succeed. Neither the README, the security review nor the site discloses that bought tokens cannot be sent to another wallet. I pinned the observed behaviour in one clearly labelled unit test so a change is noticed, without asserting it is desired.
• Info. Undisclosed owner powers on the token: setPairingEnabled, setExternalLiquidityEnabled, distributor setters, and renounceOwnership, which succeeded in the fixture and permanently freezes tax and recipient settings.

Still owed. Fork runs against live mainnet state remain untested here, since neither this machine's verifier nor the task has network access. The fixture is a captured block, so a live preflight before signing is still the operator's responsibility.

I've written four findings to .imd-findings.json: one medium and three low. No critical or high findings survived, and no project files were changed.

1. Medium – bought tokens can't be sent to another wallet (src/ERC20TLaunch.sol:132). I ran the tester's proof against the offline mainnet fixture and it failed as described. A buyer's transfer to another wallet reverts with error 0x2f352531, and the README and site never mention this. I merged the related note about undisclosed owner powers into this finding. The behaviour comes from the existing ERC20T token code that the launch contract uses, not from the launch contract itself.
2. Low – the price check is far too loose (:122). Any price from 1 up to 1e18 is accepted, and the launch can only happen once. A unit slip such as launch(1, …) passes the check and opens the pool at a near-zero price. Nothing afterwards checks the price, and the locked liquidity can't be recovered.
3. Low – the owner effectively doesn't pay the 99% launch tax, and buyers aren't told (:104/107). The brief asked for both fee recipients to be the owner, so the code matches the request. The problem is disclosure: the economics specialist measured the owner's net cost on a 10 IMD buy at about 0.31 IMD, against the full 10 IMD for anyone else. I only traced that this follows from the recipient settings; I didn't rerun the trade myself.
4. Low – the owner check only rejects the factory (:77). Setting the owner to the hook or another pinned contract deploys fine, but no one can ever call launch() after that. This can only happen if $owner resolves to the wrong address.

• The one entry point (launch(uint256,uint256,bool)): marked finding, citing finding 2. It is owner-only and can't be re-entered, because status is set before the factory call. The checks after the launch are thorough.
• Dropped:
  • The test-fixture size limit is a gap in the test setup, not a code defect.
  • The token's one-step ownership transfer is a property of the existing token code, not this contract.
  • The scanners' reentrancy and abi.encodePacked hash-collision warnings don't hold up. Re-entry is blocked by status, and the hash input has a fixed length.

None of the findings carries a proof file, since one is only required for critical or high.

The revision is complete. The shell sandbox on this worker refused to start any process for the entire run, so I could not execute forge build, forge test or the JavaScript tests here; I state that plainly in the validation record and in each response.

What I found

• Transfer restriction (medium): confirmed and fixed by disclosure plus tests. The implementation the factory clones has verified source on Blockscout and Sourcify. Its transfer hook reverts with InvalidTransfer() unless the transfer is a mint or burn, settles a swap through the PoolManager, involves the owner, involves an approved distributor contract, or is a direct wallet call where the sender is also the transaction origin and neither side has code. One correction to the report: a wallet sending to another wallet in its own transaction does work. The proof saw a revert because the buyer was a contract and the pranked wallet had a different transaction origin. New tokens also trust the hook owner's shared distributor registry by default, which was undisclosed.
• Price band (low): disputed in placement, mitigated. The website now refuses any price outside an FDV of 10 to 100,000 IMD before simulating and again before sending, with a live warning under the price field. The contract was left unchanged because the site verifies deployments against the reviewed runtime artifact, which only a build can regenerate.
• Owner pays almost no launch tax (low): fixed by disclosure in the README, the site FAQ, the economics card, the review dialog, the technical notes and the security review. Recipients follow the brief and were not changed.
• Constructor owner guard (low): disputed. A mis-resolved owner yields an inert application that nothing can launch or lose. The site already refuses an application whose owner differs from the designated wallet. The guard and the operator check are now documented.

Files changed

• test/ERC20TLaunch.t.sol and new test/helpers/HolderProbe.sol: four tests running the captured implementation for direct wallet transfers, transferFrom, contract holders, relayed calls, distributor approval and revocation, and the shared-registry switch, plus a selector-binding test.
• README.md, docs/SECURITY_REVIEW.md, docs/VALIDATION.md, site/index.html, site/docs.html: transfer policy, owner tax, price band, owner guard and after-launch steps.
• site/config.mjs, site/core.mjs, site/app.mjs, test/web/core.test.mjs: the price band and its test.
• .imd-responses.json: one answer per finding.

What remains unverified. No src/ file changed, so the accepted runtime, artifact and protected checks are unaffected. The new tests are written against the verified source and the file's existing passing patterns, but they were not compiled or run on this machine. Expected on the verifier: 46 Foundry tests and 14 JavaScript tests passing.

I left launch.json as it was. No review findings came with this round, and the existing manifest already matches the accepted source, so I didn't change any files.

What the manifest says:

• Shape: it has exactly kind: "evm_contracts", contracts and notes, with nothing extra.
• Contract: it names one contract, ERC20TLaunch, with constructorArgs: ["$owner"]. That matches the source: the only constructor parameter is constructor(address owner_), and the owner is the paying wallet.
• Fixed values: the factory, hook, IMD, PositionManager and Permit2 addresses are built into the contract, along with the supply, 5% creator share and tax schedule. None of them are constructor arguments, so they don't belong in the manifest.
• Notes: about 1,000 characters, under the 4,000 limit.

One point to be aware of: the brief asks to confirm this is the first token on the factory, and it isn't. The accepted evidence shows the factory's first token slot was already taken, so the manifest makes no first-token claim. Deploying this manifest also doesn't launch the token. The owner does that later with a separate transaction, so there is no token address or transaction hash yet.

Checks:

• forge build succeeds.
• forge test with the verifier's fuzz seed: all 46 tests pass.
• A scratch test in test/scratch/ deployed ERC20TLaunch with the owner address 0x3d6a89…36193 on chain id 1, the way the protected check does. The deployment worked, the owner was set correctly, the runtime code is under the 24,576-byte limit, and it contains none of the forbidden opcodes (DELEGATECALL, CALLCODE, SELFDESTRUCT).
• A Python script confirmed the manifest's keys, types and argument count.

I've made a small revision to my own test files; nothing else changed. forge build succeeds and forge test, run with the verifier's fuzz seed, passes all 85 tests with none skipped.

Why I revised: this round came with no findings to address. But since my last round, the implementer documented in docs/SECURITY_REVIEW.md how the launched token's transfer rule works. A wallet can send its own tokens to another wallet when it makes the call itself (msg.sender == from == tx.origin). A relayed call, a transfer to a contract, or a contract holder sending to anyone but the owner, pool or an approved distributor reverts with InvalidTransfer. My invariant tests only ever moved tokens out of contract holders, so they never tested the allowed path. Two of my comments also still pointed to an earlier findings report and described the rule as broader than it is.

What changed:

• test/helpers/LaunchInvariantHandler.sol: the random-sequence tests now include ordinary wallets as well as contracts.
  • The owner can hand part of the 5% creator allocation to a wallet.
  • Wallets then transfer in three ways: directly to another wallet (must succeed), relayed through another caller (must revert), and to a contract (must revert).
  • Counters record any transfer whose result breaks that rule, including a contract holder successfully sending to someone other than the owner.
  • I removed the outdated reference to the findings report.
• test/ERC20TLaunchInvariant.t.sol: two new checks that run after every random sequence.
  • Wallet balances are conserved: what wallets hold always equals what the owner gave them, so wallet-to-wallet transfers are never taxed and never lose or create tokens.
  • The transfer rule matches the documentation, both during the 99% launch tax and after it has decayed.
  • The existing check on the owner's balance now subtracts what the owner gave away.
  • Wallets are counted when checking that the total supply is all accounted for.
  • The scripted test that proves every random action actually runs now also does each kind of wallet transfer, before and after the decay.
• test/ERC20TLaunchEdges.t.sol: I corrected one test's comment so it describes the documented rule (the buyer in that test is a contract) instead of calling it an undisclosed defect. The test's assertions are unchanged.

In the verifier-seeded run, the 11 checks held over 48 random sequences of 32 calls each, all 9 action types ran, and none reverted unexpectedly.

No findings to report. The transfer restriction I reported earlier is now documented as part of the factory's existing token design, and the tests confirm it behaves as documented. Because the owner receives both fee streams, as the brief requires, the owner's own trades during the launch decay are taxed far less than everyone else's. The implementer has already disclosed this. So I have not written a .imd-findings.json.

The review is complete and .imd-findings.json is written. No tracked files were changed.

Outcome: every finding from the previous round is settled. Nothing blocks the launch.

What I verified this round, running the checks the author's worker could not:

• Medium, undisclosed transfer restriction (fixed). The author's correction is right. A wallet's own transfer in its own transaction succeeds on the captured implementation. My earlier repro saw reverts because the buyer was a contract and the EOA case pranked msg.sender without tx.origin. The four new tests pass against the fixture, and the policy is now disclosed in the README, site FAQ, review dialog, technical notes and security review.
• Low, owner pays almost none of the launch tax (fixed). Disclosed with the measured figures in the README, site economics card, FAQ, review dialog and docs. Recipients stay as the brief requires.
• Low, price bound and low, owner guard (disputed, accepted). Both still reproduce on-chain, but the author's reasoning holds. The site now refuses prices outside an FDV of 10 to 100,000 IMD before simulating and before sending, the site refuses an application whose owner differs from the designated wallet, and both residuals are documented. I confirmed the site's runtime artifact is byte-identical to a fresh build, so leaving src untouched was the correct call. Recorded as info, no action needed.

Check results this round:

Check	Result
forge build	ok
forge test	85 passed, 0 failed
forge fmt --check	clean
node --test test/web	14 passed

One stale note, not a defect: docs/VALIDATION.md expects 46 Foundry tests, but the suite now has 85 because other contributors added edge and invariant suites.

Coverage: the single entry point ERC20TLaunch.launch(uint256,uint256,bool) holds, with four extra rows recording the settled findings and the artifact and check results.