Implemented EmberEvo’s fixed-supply token, vendored dependencies, tests, and launch documentation, preserving the requested 86%/10%/4% allocation.

forge build, all 22 tests, and forge fmt --check pass, including clean offline verification.

Launch and actual quote binding remain blocked by missing official policy version, infrastructure addresses, and Check quote. No transactions were broadcast.

the task produced no changes; the agent's last message was: Blocked by the execution environment: every command fails before starting with bwrap: setting up uid map: Permission denied.

I could not read the implementation or pinned checks. Both forge build and forge test failed to start. No files were changed.

The sandbox must be repaired and the task rerun before I can implement and verify the tests.

The review is complete. The findings file is in place, no tracked file was changed, and the scratch directory is gone.

Result: no defects found in the assigned area. .imd-findings.json holds an empty findings list and eight coverage rows, one per verifier entry point plus the invariants and economic terms I checked.

What I verified, against the Economic Security, Invariant and Flow Gap guides:

• Token code. src/LaunchToken.sol is a 13-line, argument-free OpenZeppelin ERC-20 that mints 10^27 units once to the deployer. It has no mint, burn, owner, pause, tax, hook, external call, ETH path, or escape opcode. Every one of the three entry points was traced through the vendored library and behaves as a plain transfer or approval should.
• Dependencies. I downloaded the pinned OpenZeppelin v5.0.2 archive and compared every vendored file byte for byte. All six match, and the archive hash matches the one recorded in the dependency notes.
• Invariants. Supply stays constant and equals the sum of balances across the project's fuzz and stateful invariant suites. The full suite passes with no reverts. I also ran both protected floor tests from the task inputs against the compiled creation code, simulating a CREATE2 factory deployment on chain 1, and all nine assertions pass.
• Economics. The 86/10/4 split sums to 10,000 bps, the remainder recipient and launch payer both resolve to the issuing wallet, and the fee and opening-cap terms in the README match the route reference. The intent file's recorded SHA-256 matches its bytes. Policy version, factory, pair token, fee recipient and the actual quote are correctly left unresolved rather than filled with placeholders.

Static analysis leads: the aderyn large-literal note is a compile-time constant that tests assert equals 10^27, so it is not a defect. The one thing this review cannot establish is anything on the official side: the live LaunchFees value, the IMD pair address, and the quote binding all still need to be supplied at Check.

Created launch.json for EmberEvo’s token-only evm_project launch with the required IMD pair and economics documented.

Schema checks, offline forge build, and all 31 tests passed, including protected checks using a local fixture. Only launch.json is submitted.

Official policy, factory, payment/gas terms and authenticated quote binding remain unresolved and are documented as launch blockers.

Review complete. The findings file is written and validated.

Result: no math, boundary or numerical-gap defect in the token. The only substantiated item is an informational provenance inaccuracy in DEPENDENCIES.md.

What I verified

• src/LaunchToken.sol contains no arithmetic of its own. It inherits OpenZeppelin v5.0.2 ERC20, whose six vendored files I diffed byte-for-byte against the upstream archive. The archive hash matches the one recorded in DEPENDENCIES.md.
• Every unchecked block in the inherited _update and _spendAllowance is guarded by a strict less-than revert before the subtraction, and the unchecked addition cannot overflow because the balance sum is pinned at 10^27, a 90-bit value.
• The supply literal evaluates exactly to 10^27 and equals both 1e27 and 1_000_000_000 ether. The 8600/1000/400 bps split of that supply divides with zero remainder, so the three allocations sum back to the full supply with no dust. The base-unit strings in the README and intent file have the correct digit counts, and the manifest sqrtPriceX96 string equals 2^96 exactly.
• Boundary steps from the guide have nothing to apply to: the token has no external calls, no payable function, no receive or fallback, no sentinel branch beyond the zero-address reverts, and no bytes decoding.
• I ran a scratch test for edges the delivered suite skips: max-uint transfer, max-minus-one allowance decrement, transferFrom with a zero-address source at value 0 and 1, self-transferFrom, and a two-holder conservation fuzz. All behave as intended.
• The protected token floor, run against the compiled creation code with the policy supply and 18 decimals, passes 7 of 7. The full delivered suite passes 22 of 22, including the stateful invariant with no reverts, and forge fmt --check is clean.

The one finding, severity info

DEPENDENCIES.md line 15 says all vendored files are unmodified. Seven forge-std v1.9.7 files were reflowed by the formatter before commit. Stripping whitespace makes each pair identical, and applying forge fmt to the upstream tree reproduces the vendored tree exactly, so the change is cosmetic and test-only. The reproduction in the findings file is the download and diff command sequence.

Coverage record

All three entry points are marked holds, plus four rows for the supply and allocation invariants, the constructor floor, and the boundary enumeration. The static-analysis lead about the large numeric literal was checked and is not a defect.

Outside my area, noted for the judge

The swarm 2 percent and 8 percent per-wallet divisions happen in the factory and distributor, which are not in this tree, so any rounding dust there cannot be assessed here. The launch handoff documents correctly leave policy version, factory, pair token, fee addresses and quote as unresolved nulls rather than inventing values.

Review complete. The findings file is written and the working tree is otherwise untouched.

Outcome: no security defect in the token or its control flow. One informational provenance inaccuracy is reported.

What I checked, against the Execution Trace, Periphery and First Principles guides

• Token entry points. All three state-changing functions (approve, transfer, transferFrom) are the unmodified OpenZeppelin v5.0.2 implementations. I traced each path: zero-address rejection, insufficient balance and allowance reverts, allowance consumed before the balance move, infinite-allowance semantics, self-transfer correctness, and the absence of any external call, hook, fallback or receive. Nothing produces a stale read, partial update or value leak.
• Constructor and roles. Zero arguments, nonpayable, mints exactly 10^27 base units once to the deployer. No owner, mint, burn, pause, fee, proxy or selfdestruct exists in the ABI or runtime. Name and symbol match the brief.
• Protected floors. I ran both pinned protected test files from a scratch directory against the real creation code with a CREATE2 factory stand-in on chainId 1. All nine tests pass, including whole-supply-to-factory and the forbidden-opcode scan.
• Periphery. Downloaded the pinned OpenZeppelin v5.0.2 and forge-std v1.9.7 archives. Both archive hashes match the table in DEPENDENCIES.md. All six OpenZeppelin files are byte-identical. Seven forge-std files differ, but only by whitespace reformatting.
• Launch documents. Allocation, pair, chain, fee terms, opening cap, issuer and payer addresses, and the intent digest all reconcile with the brief and the route. Unresolved policy, factory and quote values are honestly recorded as null rather than defaulted, since no network or policy file was supplied.

The one finding (info): DEPENDENCIES.md line 15 says the vendored sources are unmodified, but the forge-std copies were reformatted. Test-only, no semantic change, no runtime effect. The fix is either restoring the archive bytes or correcting the sentence.

Not reported as findings: the aderyn large-literal lead is style only, and the ERC-20 approve race is a property of the standard the brief explicitly requests.

Coverage record: nine rows covering all three listed entry points, the constructor, the protected-floor invariants, both vendored dependencies, the launch documents and the build configuration.

The review is complete and the findings file is written and validated.

Outcome: no security defects in the token. src/LaunchToken.sol is a plain, unmodified OpenZeppelin v5.0.2 ERC-20 with a zero-argument constructor that mints the full supply once to its deployer and retains no role. Across my three guides I found nothing exploitable:

• Access Control. The only state-changing entry points are approve, transfer and transferFrom. Each acts solely on behalf of msg.sender or a spender with explicit allowance. The constructor hands out no owner, minter, pauser or upgrader. The compiled runtime dispatcher contains exactly the nine ABI selectors, with no receive, fallback, DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Asymmetry. transfer and transferFrom mirror each other on balance effects and zero-address checks. Allowance is spent before the balance moves, finite allowances decrement exactly, the maximum allowance is never touched, and a failed transferFrom leaves the allowance intact. These behaviours were confirmed with a scratch probe suite that passed and has been removed.
• Trust Gap. The vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 archive, so no hidden privilege exists in inherited code. The launch intent matches the brief: mainnet, IMD pair, 8600/1000/400 split, remainder and payer both the stated issuing wallet, empty contracts array, standard admission pool settings. The README and CHECK.md correctly leave policy version, factory, LaunchFees, recipient and quote unresolved rather than inventing values.

One informational finding was recorded. DEPENDENCIES.md states the vendored forge-std sources are unmodified, but seven files differ from the cited v1.9.7 archive. I verified every difference is whitespace-only reformatting, and forge-std is test-only, so this has no effect on deployed bytecode. The fix is either restoring those files byte for byte or amending the sentence.

Coverage. All three listed entry points are marked holds, plus seven invariant rows covering the constructor, absence of receive and fallback, dispatcher inventory, fixed supply, both dependency provenances and the intent economics. Static analysis leads were reviewed: Slither reported nothing, and the aderyn large-literal note is the intended supply constant. The forge build, all 22 project tests, and the formatter check passed.

Added failure-path tests, corrected admin-call probes, and strengthened balance/allowance invariants. Only test/ changed.

Validation passed:

• forge build
• forge test: 38 tests, zero failures or skips
• 24,576 invariant handler calls

No token defect was reproduced. Official launch policy, factory, payment terms and quote binding remain unverified because those inputs are missing; limitations are documented in test/README.md.

The review is complete and .imd-findings.json holds the result. No repository file was changed, and the scratch directory used for the protected floor run was removed.

Outcome: no defect in the token or the manifest. Two informational findings, both documentation accuracy.

• Finding 1 (info), DEPENDENCIES.md line 15. The three specialist reports were the same root cause and are merged into one. I reproduced it: the forge-std v1.9.7 archive hash matches the table, but seven vendored files differ from the archive. Whitespace-stripped digests are equal for every pair, so it is forge-fmt reflow only. All six OpenZeppelin v5.0.2 files and the licence are byte-identical. The production token inherits only OpenZeppelin ERC20, so no bytecode is affected.
• Finding 2 (info), README.md line 33. The README still says no mainnet IMD address was supplied, while the accepted launch.json pins a paired-currency address. That address has code on mainnet and returns symbol IMD with 18 decimals. This is stale wording, not a wrong manifest.

What I verified myself.

• The token is a four-line wrapper over unmodified OpenZeppelin ERC20: zero-argument nonpayable constructor, single mint of 10^27 to the deployer, no owner, mint, burn, pause, blacklist, fee, rebase or upgrade path. Runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The protected token floor from the pinned reads passed all seven checks against the real compiled creation code with the policy supply and decimals set.
• The project suite passed with 38 tests, including fuzz and a stateful invariant over transfers, approvals and delegated spends. Build and formatting checks pass. No submodules.
• Manifest fields match the brief: evm_project, empty contracts array, fee 3000, tick spacing 60, initial price exactly 2^96, lowercase pair address. Notes carry no deployment authority.
• Static analysis leads: slither reported nothing, and aderyn's large-literal note is the supply constant, which is intended.

Coverage record. All three entry points (approve, transfer, transferFrom) are marked holds with reasons, plus the constructor, the no-admin-path invariant, manifest-matches-brief, and the vendored-dependency invariant that points at finding 1.

Still unresolved and outside this code. Exact policy version, ProjectFactory, LaunchFees and fee-recipient addresses, the launch charge, and the quote binding are correctly recorded as null in launch/check-status.json. I could not confirm the pinned pair address against the official network.json, which was not among my inputs. That is a Check-time evidence gap, not a code defect.