Implemented StrataIMD (STRATA): 1 billion tokens, 18 decimals, minted once to the deployer, with no administrative powers.

• forge build, forge test, and forge fmt --check pass.
• All 27 tests pass, including fuzz and invariant checks.
• Fresh offline build and parallel tests pass with an empty environment.
• Dependencies are vendored; assumptions and deployment responsibilities are documented in README.md.

The network-specific protected launch harness was not run locally.

Created launch.json matching the accepted token, exact supply, empty constructor arguments, requested pairing, and verbatim economics.

Manifest checks and forge build passed. forge test: 27 passed, 0 failed.

Only launch.json is changed for submission.

The findings file is in place and excluded from git by the harness's own .git/info/exclude, so the working tree is otherwise clean. The review is complete.

Outcome: no access-control, trust-gap, or asymmetry defect in the token. The review found one low provenance issue and one informational note, both recorded in .imd-findings.json with a nine-row coverage record.

What the token is. src/StrataIMD.sol is a 16-line wrapper over the vendored OpenZeppelin v5.0.2 ERC20. The constructor takes no arguments and mints 10^27 units once to the deployer. The compiled ABI has exactly ten selectors: seven views plus approve, transfer and transferFrom. There is no owner, role, initializer, proxy, receive or fallback, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Area coverage.

• Access control. Every state-changing path binds to plain msg.sender through an unmodified Context. approve writes only the caller's allowance row, transfer debits only the caller, transferFrom requires the caller's allowance from the owner. The deployer or factory has no bypass. Unknown selectors and raw ETH revert. All three listed entry points are marked holds.
• Trust gap. There is no privileged actor, so none of the four seams has an actor to occupy it. The only trust assumption is that the factory holds the whole supply until it distributes, which is the launch design.
• Asymmetry. transfer and transferFrom share the same internal path. The only pair difference is the allowance spend, and it behaves as specified, including on self-directed pulls and on reverts. The approve-overwrite race is standard ERC-20 and already documented in the README. I recorded it as info only.

Findings written.

1. Low: the README's own check sha256sum -c SHA256SUMS fails on six forge-std files. The recorded hashes match upstream v1.9.6, so the committed copies were reformatted afterwards. I downloaded both upstream archives and confirmed the diffs are whitespace-only and that all five OpenZeppelin files are byte-identical to upstream. The deployed bytecode is unaffected, but the stated integrity gate is red and the "unmodified" claim in DEPENDENCIES.md is false.
2. Info: the allowance replacement race, with a concrete sequence, marked as retained by design.

Verification run. The existing 27 unit, fuzz and invariant tests pass offline. I added five scratch probes under test/scratch covering the hand-traced access paths and the race sequence, all passed, and I deleted them afterwards along with the temporary download directory. Neither Slither nor Mythril ran beyond the verifier's supplied output, which reported nothing above the numeric-literal lint.

No critical or high findings exist, so no proof test was attached.

The review is complete and the findings file is written. The working tree is otherwise untouched: the scratch tests were removed and no project file was changed.

Outcome: no math, precision, boundary or numerical-gap defect in the token. One low finding outside the assigned area.

What was checked in the assigned area

• The supply constant is a compile-time literal product that equals exactly 10^27, which the deployed contract confirms. The aderyn "large numeric literal" lead is not a defect.
• All three entry points are the unmodified OpenZeppelin v5.0.2 ERC20, verified byte-for-byte against upstream. The token adds no division, scaling, casts, fees or external calls, so the precision and truncation failure modes have nothing to attach to.
• Boundary tests I ran on the deployed contract all passed: transfer of max uint and balance plus one revert without wrapping, exact-equality allowance and balance succeed and leave zero, the unlimited-allowance sentinel is exactly max uint while max-minus-one still decrements, self-transfer and self-spend preserve balance, a failed balance check rolls back allowance, two deployments are isolated, and a fuzzed split of the supply always sums exactly.
• Build, the project's 27 unit, fuzz and invariant tests, and the format check all pass.

The one finding (low): the README lists a hash check as a build step, and DEPENDENCIES.md claims the vendored files are unmodified, but that check fails on the committed tree. Six forge-std files are whitespace-reformatted relative to upstream v1.9.6. The difference is test-only and has no on-chain effect, but the documented verification step cannot be completed as written. The fix is to regenerate the hash list or restore the upstream bytes.

Coverage: all three entry points are marked holds, plus rows for the supply invariant, balance conservation, the static-analysis lead and the Boundary guide's external-call enumeration. Nothing was left unreached.

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

Result: no economic defects in the token. StrataIMD is an unmodified OpenZeppelin v5.0.2 ERC-20 plus one constant and a constructor mint. I verified the six vendored OpenZeppelin files are byte-identical to the upstream release, so the token's transfer, approval and supply behaviour is exactly the library's.

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

• Supply invariant. The only path that touches supply is the constructor mint of 10^27 units to the factory. No burn, mint, owner, pause, blacklist or initializer exists in the compiled ABI. The project's invariant test passes on re-run.
• Flow exactness. Transfer and transferFrom move precisely the requested amount with no fee, hook, tax or exemption list. The swarm share, pool seed, and swaps each way therefore arrive whole. The protected harness itself could not be run here because v4-core is not vendored.
• Token misbehaviour and compliance. No external calls, oracles, sentinel branches, rebasing, or void returns. Zero-address transfers and approvals revert. ETH is rejected. Runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Privileged power. The factory or deployer cannot move a holder's balance without allowance.

One low finding, outside my area. The committed SHA256SUMS fails to verify: six forge-std files under lib/ were whitespace-reformatted, so the README's checksum step reports six failures and the "unmodified upstream" claim in DEPENDENCIES.md is false. The recorded hashes match upstream v1.9.6, the files do not. This is test-only tooling and does not affect the token's bytecode. The fix is to restore those six files from the upstream archive.

Coverage: all three listed entry points marked holds, plus rows for the constructor, the supply invariant, launch-flow exactness, economic security, and dependency provenance (the finding).

Added 14 tests covering authorization failures, allowance revocation, maximum values, and recovery after failed transfers. Expanded invariants to mix valid and rejected operations.

forge build and forge test pass: 41 tests, including 32,768 invariant calls.

Only test/ changed. No defects surfaced in these checks.

The review is complete. The findings file is valid JSON, the snippet matches the tree, the scratch test and temp archives are deleted, and the working tree holds no new files beyond the required output and the build cache.

Outcome. The token is a plain OpenZeppelin v5.0.2 ERC-20 with a fixed constructor mint, and all three state-changing entry points hold. I found one low-severity defect, in the repository's provenance record rather than the contract.

What I covered, in my area. Execution Trace: I traced approve, transfer and transferFrom through the vendored ERC20 line by line, then probed the corner cases with a scratch Foundry test deployed from a CREATE2 factory and a pool-manager-style puller. Exact delivery holds for factory to distributor, pool manager and remainder, and for a buy and sell round trip. Finite allowances decrement exactly, the max allowance is untouched, max minus one decrements, a spender equal to the owner still needs an allowance, and failed delegated transfers roll back the allowance. Periphery: the five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 archive, and the compiled ABI has no receive, fallback, payable function, or admin surface. First Principles: the constructor mints to msg.sender, which under factory CREATE2 is the factory, as the protected harness requires. The supply constant cannot overflow, so the aderyn large-literal lead is benign. Slither reported nothing.

The finding. Six forge-std files fail the repository's own sha256sum -c SHA256SUMS check, which the README lists as a required check, and DEPENDENCIES.md claims the vendored files are unmodified. I diffed them against the pinned v1.9.6 archive, whose hash does match. Every difference is line re-wrapping consistent with a formatter run over lib, and the whitespace-stripped contents are identical. This is test-only and does not affect the token's bytecode, so I rated it low. The fix is either restoring the six files byte-for-byte or regenerating the six checksum lines and correcting the provenance note.

Coverage record. Eight rows: the three listed entry points hold, the constructor holds, two invariants hold, OpenZeppelin periphery holds, and the forge-std provenance row points to finding 1. Nothing was left unreached. No critical or high finding exists, so no proof test accompanies the report.

The review is complete and .imd-findings.json is written. No other file was changed.

Outcome. The StrataIMD token is clean. It is the unmodified OpenZeppelin v5.0.2 ERC20 with an argument-free constructor that mints the manifest supply once to the deployer, and it has no privileged entry points. The three entry points in the ABI all hold.

Specialist findings. Four specialists reported the same defect and one reported an informational note.

• Kept, merged into one low finding. The documented sha256sum -c SHA256SUMS check fails for six vendored forge-std files. I reproduced it independently by downloading the pinned forge-std v1.9.6 archive, which matches the hash in DEPENDENCIES.md. The six committed files differ from upstream only by line re-wrapping, and the whitespace-stripped contents are identical. All six vendored OpenZeppelin files are byte-identical to upstream. The token's bytecode and behaviour are unaffected, but the repository's provenance claim is false and its integrity gate is red.
• Dropped. The approve and transferFrom allowance replacement race. It reproduces, but it is standard ERC-20 behaviour inherited from the library and the README already documents the mitigation. It is not a defect in this code.

My own pass. Project build and all 41 tests pass, including the invariant suite. The deployed runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The manifest's totalSupply, decimals and empty constructorArgs match the contract, and its initialPrice equals the stated formula from the economics. The aderyn large-literal lead is a compile-time constant and is benign. The manifest's economics could not be checked against the job because the job's economics were not supplied to this task.

Coverage. Six rows: the three entry points hold, plus three invariant rows for the supply mint, the runtime opcodes and the manifest consistency.