Implemented the standard EMBEO token, empty application manifest, tests, ABI, exact logo, and documentation with the prominent historical EMVO warning.

forge build, all 20 tests, empty-environment tests, and forge fmt --check pass.

Not deployed: owner quote/signing, complete LP custody verification, and official deployment evidence remain pending.

See README and launch handoff.

Updated only launch.json for token-only EmberEVO (EMBEO), with native ETH pairing and clarified launch terms.

Schema/refinement checks and offline forge build passed. forge test: 29 passed, including pinned checks; none failed or skipped.

Actual deployment addresses, poolKey and LP custody evidence remain pending.

Review complete. The findings file is written and validated, and the scratch directory has been removed.

Result: no math defects in the token. One deliverable defect outside the math area.

The audited code is a 13-line LaunchToken that wraps unmodified OpenZeppelin 5.0.2 ERC20 and mints 10^27 units once in the constructor. Across the Math Precision, Boundary and Numerical Gap guides, every failure mode either does not apply or holds:

• Math Precision. The only arithmetic is the constructor constant and the OZ balance/allowance updates. There are no divisions, casts, scale conversions or fixed-point systems. The unchecked subtractions are each preceded by the matching < check, and the unchecked additions are bounded by a total supply of 10^27. The aderyn "large numeric literal" lead is stylistic only.
• Boundary. The token makes no external calls and has no payable, receive or fallback functions and no bytes decoding. The only sentinel branches are the zero-address checks, and both sides revert as intended.
• Numerical Gap. With no rounding anywhere, the invariant that balances sum to total supply holds exactly. I ran a scratch Foundry test over the seams the delivered suite does not hit directly, such as self-transferFrom with a finite allowance, allowance of max minus one, and a zero-value spend on a zero allowance. All passed, as did the delivered 20 tests and the 128-run invariant suite.

The one finding (medium): the artifacts/ directory that README, docs/REVIEW.md and docs/LAUNCH.md present as delivered evidence does not exist in the tree and was never committed. The README-documented command python3 scripts/export_artifacts.py --check exits 1, the ABI and reproducibility links are dead, and the claimed saved factory fee read, policy snapshot and "no blockers" Check response have no artifact behind them. The fix is to run the export script and commit its output plus the referenced discovery and status files, or to correct the docs.

Coverage rows cover all three ABI entry points as holds, plus five invariant and boundary rows and one finding row for the missing artifacts. Nothing was left unreached.

The review is complete. The findings file is valid, both snippet anchors match the tree, and no repository files were changed.

Outcome. The token code is clean. All three ABI entry points hold, and the two findings are gaps in the delivered documentation and provenance, not defects in the contract.

What I checked in the assigned area

• Execution trace. approve, transfer and transferFrom resolve to the vendored OpenZeppelin 5.0.2 ERC20 with no overrides. Zero-address checks, balance and allowance checks, unchecked arithmetic bounds, atomic rollback and the infinite-allowance path all behave as the standard specifies. The constructor mints exactly 10^27 units once to the caller.
• Periphery. The six OpenZeppelin files are byte-identical to the upstream v5.0.2 archive. Runtime has no delegatecall, callcode or selfdestruct, no receive or fallback, and the ABI exposes only the nine standard functions.
• First principles. I re-read every mainnet claim in the launch document over a public RPC. The block hash, factory address, fee contract, 1.25% pool fee, fee recipient, treasury, pool manager, hook, deployer, and the old EmberEvo test token all match the prose. The manifest validates against the schema, with notes well under the 4000-character cap. The request file carries the required route, chain, pairing, owner and economics.
• Tests. 20 tests pass, including fuzz and stateful invariants. Formatting check passes.

Findings written to .imd-findings.json

1. Medium. README and docs link verification artifacts under artifacts/ that are not in the tree: ABI, build record, deployment status, the factory discovery reads, and validation logs. The README's own documented check command fails on the last step. The mainnet facts the docs cite are accurate, but the evidence file they point at does not exist.
2. Low. The dependency document says forge-std was vendored unmodified, but seven files are reformatted relative to the pinned v1.9.7 archive. The changes are whitespace only and test-only, so no deployed code is affected, but byte comparison against the archive contradicts the provenance statement.

Coverage. Eleven rows: the three entry points plus the constructor mint, vendored ERC20 integrity, runtime opcode and ABI surface, manifest schema, request economics, mainnet discovery claims, forge-std provenance, and test-suite edges. Nothing was left unreached.

Not in scope and not asserted. Actual pool initialization, LP custody powers, distributor proofs and the LaunchFees claim flow still depend on the protocol's deployment handoff, as the delivered docs already state.

Added adversarial tests and expanded stateful invariants within test/.

• forge build and forge test pass: 36 tests, zero failures or skips.
• Invariants exercised 32,768 randomized calls.
• No reproducible token defect found.

Coverage and live-protocol verification limits are documented in test/README.md.

Review complete. The findings file is written at .imd-findings.json, snippets verified against the tree, scratch tests removed, and no tracked file was changed.

Outcome: the token code is clean in my area. The defects are in the deliverable's documentation and evidence, not in Solidity.

What I checked, against the Access Control, Trust Gap and Asymmetry guides plus the Trail of Bits entry-point inventory:

• Access control. The token is an unmodified OpenZeppelin 5.0.2 ERC20 with a no-argument constructor that mints the full supply once to the deployer. No roles, initializer, owner, receive or fallback exist. All three listed entry points hold. Twenty admin and extension selector probes from the deployer, issuer and a stranger all revert.
• Trust gap. The vendored OpenZeppelin files are byte-identical to upstream v5.0.2, and the logo hash matches the brief. I independently confirmed the README's mainnet claims by read-only RPC: the factory's fee contract reports a 12500 pool fee (1.25%), and the fee recipient, hook and service-fee figures match. The manifest validates against the schema and correctly pairs with native ETH, unlike the referenced old EMVO manifest, which paired with IMD.
• Asymmetry. The transfer and transferFrom paths share one internal routine. The only asymmetry is standard: allowance spend emits no Approval event, which TOKEN.md already discloses.

Findings reported, most severe first:

1. Low. README, LAUNCH.md and REVIEW.md point to an artifacts/ directory holding the ABI, build record, deployment status, saved factory reads and validation output. That directory is not in the tree. The documented check command exits 1. The fee and custody statements are correct but their cited evidence is undelivered.
2. Info. DEPENDENCIES.md says vendored sources are unmodified, but seven forge-std files were reformatted. I confirmed the changes are whitespace-only.
3. Info. One test uses a bare expectRevert for a zero-source transferFrom, and its comment names the wrong check. The real revert is ERC20InvalidApprover, which I confirmed with a scratch test.

No critical or high findings, so no proof tests were attached. Coverage rows answer all three entry points plus five invariants. Static analysis leads (the large-numeric-literal note) were checked and are not defects.

The findings file is on disk (9.4 KB) and is excluded by the harness's .git/info/exclude, which is why git status is silent; nothing else in the tree changed and I created no test/scratch/ files. The review is complete.

Summary

Scope covered (Economic Security, Invariant, Flow Gap): the three ABI entry points, the supply/allowance invariants, the factory allocation math, the manifest/request against the brief's schema, and — because the token itself is a 13-line OZ specialization — the economics claims in the docs, which I checked against the live chain and the public API rather than taking them on trust.

What holds

• src/LaunchToken.sol is an unmodified OZ 5.0.2 ERC-20 (all five vendored files byte-identical to upstream): no mint/burn path after the constructor, no callbacks, no fee, 9-function ABI, no forbidden opcodes. 20/20 tests pass including the stateful invariant model; the 86/10/4 split is exact in 10^27 units.
• launch.json validates against the schema in the brief (notes 2,177/4,000 chars); request.json carries only poolBps/remainderTo, lowercase owner, chainId 1, ETH pairing.
• Every on-chain/API claim in the docs checked out: factory fees() → LaunchFees with poolFee()=12500, recipients/owner as documented; policy 18 cap 10 ETH; launch.open = 0.5 IMD. Decoding the historical EMVO launch receipt confirmed static fee 12500 in the poolKey, the guard-only hook, the factory as LP sender, and that the cap is a valuation over total supply (2,500 IMD / 1e9 exactly). claimFees(uint64) simulated from a stranger succeeds and credits owed(account,currency) — the docs' "anyone can claim, nobody gains entitlement" description is accurate.

Findings (2)

1. Medium — README.md:49 and docs/LAUNCH.md/docs/REVIEW.md link seven artifacts/ files (ABI, build record, solc input, deployment status, factory-read discovery, validation logs) and mark them "Delivered/preserved", but none exist in the tree; the README's own python3 scripts/export_artifacts.py --check exits 1. The economics evidence the brief requires is asserted, not delivered.
2. Info — DEPENDENCIES.md:10 says forge-std was "not modified", but seven files differ from v1.9.7 by whitespace only (confirmed by whitespace-stripped hash equality — test semantics are unaffected).

Neither is critical/high, so no proof tests were warranted. One lead I could not close: the factory's LP withdrawal/admin powers are unprovable from bytecode (source is unverified on Sourcify/Blockscout/Etherscan); the docs already flag this as the open custody blocker rather than claiming custody, so I did not report it.

The review is complete. The findings file is written at .imd-findings.json, the scratch directory is removed, and the working tree contains no other new files.

Outcome. The token itself is clean. Every defect that survived is in documentation or test precision, not in deployable code. All three entry points hold.

What I reproduced from the specialists, merged to two findings:

• Medium, README.md line 49. Four specialists reported the same root cause, so it is one finding. The README, LAUNCH.md and REVIEW.md link seven artifact paths and mark the ABI, bytecode, Check response and factory-read evidence as delivered or preserved. No artifacts directory exists in any commit, and nothing ignores it. The README's own check command exits 1 on a fresh checkout. The fee, opening-cap and custody statements therefore carry no inspectable evidence in the repository.
• Low, DEPENDENCIES.md line 10. Three specialists reported this. The file says vendored sources were not modified. I re-downloaded both upstream archives, which hash exactly as the document states. All five OpenZeppelin files are byte-identical. Seven forge-std files differ by line wrapping only, and hash identically once whitespace is stripped. Semantics are unchanged, but the provenance statement is false.

Kept as info:

• test/LaunchToken.t.sol line 176. The zero-source transferFrom case uses a bare expectRevert and its comment names the wrong check. I ran both variants. The actual error is ERC20InvalidApprover from the allowance update, not ERC20InvalidSender.
• docs/REVIEW.md line 18 (my own finding). The review doc says the invariant campaign runs 128 sequences of depth 64. The delivered file's inline config and the actual run use 256 of depth 128, as test/README.md correctly states.

What I verified myself beyond the specialists. The build compiles, all 36 delivered tests pass, and the formatter check passes. The two protected floor tests pass when fed the compiled creation code and the policy supply, including a CREATE2 deployment from the discovered factory address. The compiled ABI is exactly the nine ERC-20 functions with a no-argument nonpayable constructor, and the runtime has no delegatecall, callcode or selfdestruct. The manifest is schema-valid, with notes under the 4000-character ceiling. The docs carry the required test-token notice without the forbidden wording, never describe the pool as 0.3%, and the logo bytes hash to the expected value.

Next step for the author. Run the export script without the check flag and commit the resulting artifacts along with the discovery and validation captures the docs describe, or reword the docs to claim only what is delivered. The DEPENDENCIES.md fix is either restoring the seven forge-std files byte-for-byte or stating that they were reformatted.

Restored missing artifacts and validation captures, corrected dependency provenance, and removed unsupported evidence claims.

The invariant advisory was not reproducible: this tree runs 128 × 64 as documented. All three findings are answered in .imd-responses.json.

forge build, forge test, forge fmt --check, and artifact checks pass. Token code is unchanged; deployment remains pending.

Updated only launch.json to require Check/quote confirmation of the 86% pool allocation and disclosure of incompatible terms.

Validation passed: supplied schema and admission refinements, forge build, and all 29 tests—including both pinned suites—with no failures or skips. No deployment performed.

Reproduced and fixed the advisory: the test now expects exact ERC20InvalidApprover(address(0)) revert data, with the comment corrected.

Recorded the response in .imd-responses.json.

Validation passed: forge build and forge test — 36 tests passed, including the invariant campaign.

Fixed artifact delivery: added six compiler exports, deployment status and validation records, and corrected Git exclusions hiding them. Removed unsupported discovery-evidence claims.

The invariant finding was not reproducible: this checkout runs 128×64 with three handlers. Both dispositions are recorded in .imd-responses.json.

Passed forge build, forge test (20 tests), forge fmt --check, artifact checks and a clean offline rebuild.

Token code remains unchanged. Mainnet deployment and external evidence remain pending.

Updated only launch.json, clarifying that the service fee is assignment-reported and supporting discovery/quote evidence remains unavailable. Existing launch parameters are unchanged.

Validation passed: manifest schema/refinements, source/ABI consistency, forge build, and all 20 tests.

Actual mainnet deployment, poolKey and effective fee remain pending.

Preserved the accepted Solidity tests and recorded validation in test/README.md.

• forge build: passed.
• forge test: 36 passed, zero failures or skips.
• Both invariants passed across 32,768 randomized handler calls.

No contract defect reproduced. Mainnet deployment and protocol integration remain unverified. Only test/README.md changed.

Saved .imd-findings.json.

• Low: Artifacts are delivered, but a stale manifest hash still fails verification.
• Info: Review documentation understates the actual invariant campaign.

All 36 tests and formatting checks passed. All three token entry points hold. No tracked files changed.