Implemented Coinstark (COINSTARK): 1,000,000,000 tokens with 18 decimals, minted once to the deployer.

Included vendored dependencies, deployment documentation, and success/failure, fuzz, and invariant tests.

Verified with Solidity 0.8.26:

• forge build passes.
• forge test: 33 tests pass.
• forge fmt --check passes.
• Clean offline build and tests pass.

I found no math, precision, boundary or numerical-gap defects in Coinstark, so .imd-findings.json has an empty findings list and a coverage row for each entry point. The existing test suite passes (33 tests, including the invariant run), and I changed no files apart from writing that JSON.

What the token is: src/Coinstark.sol is OpenZeppelin's standard ERC-20 (v5.4.0) with nothing overridden. The supply is a constant: INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18, which is 1e27 and is worked out when the contract compiles, so it can't overflow. The constructor is the only place tokens are minted, and it mints the whole supply to the deployer. There is no fee, burn, rounding or scaled maths anywhere.

Coverage:

Static analysis: the aderyn "large numeric literal" lead at src/Coinstark.sol:11 is about style only. The value is correct and easy to read, so I left it out of the findings.

None of the Math Precision guide's checks apply here: there is no division, fee, exchange rate, unsafe narrowing cast or unchecked block in the project's own code. The boundary and numerical-gap checks (zero amounts, maximum allowances, whole-balance transfers, the supply ceiling) all hold.

Created launch.json matching Coinstark’s constructor, exact supply, and required pool and economics values.

Validation passed:

• Manifest fields and compiled constructor ABI checked.
• forge build succeeded.
• forge test: 33 passed, 0 failed.

Only launch.json is changed for submission.

Review complete. The findings file is written and validated, the scratch test is removed, and the tree is otherwise unchanged.

Outcome: no defects found in the assigned area. The token is an unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint of exactly 1e27 units to msg.sender, no overrides, no owner, and no external calls.

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

• Launch flows arrive whole. No tax, burn, reflection, exemption, blacklist, pause or hook exists, so factory to distributor, distributor to claimant, pool seed, and swaps in both directions all move exactly the stated amount. Verified with a CREATE2 factory harness moving the 10 / 88 / 2 split and round-tripping through a pool-manager stand-in with an unlimited allowance.
• Conservation. Sum of balances always equals totalSupply equals 1e27. The ABI has only approve, transfer and transferFrom as state-changing functions, so nothing reaches mint or burn after construction. The existing invariant suite and all 33 project tests pass.
• Sentinels and boundaries. Zero-address sender, receiver and spender all revert with ERC-6093 errors and no state change. Allowance rolls back atomically when the transfer reverts. Infinite allowance stays unchanged.
• Launch floor. No privileged entry points, decimals is 18, no DELEGATECALL, CALLCODE or SELFDESTRUCT in runtime, supply cannot grow.

Reported: one info-level note on the standard ERC-20 approve replacement race, with a concrete front-run sequence. It is inherent to the standard, already documented in the README, and does not require a code change under the requested design.

Limits: I could not execute the protected launch suite itself because v4-core and the LaunchLiquidity helpers are not in this tree. I reasoned about it from the token's code, which has no transfer-time logic for it to trip on. Coverage rows answer all three entry points plus five invariant and flow checks.

Review complete. The findings file is written at .imd-findings.json with one low finding and nine coverage rows, and no source files were changed.

Outcome: the token is a plain OpenZeppelin v5.4.0 ERC-20 with a constructor that mints the full supply once to msg.sender. I found no defect in the contract itself.

What I verified in the assigned area

• Execution trace: approve, transfer and transferFrom go straight into the vendored OpenZeppelin _approve, _transfer, _update and _spendAllowance. There are no external calls, hooks, fees, exemptions, sentinel paths or coupled state, so the factory, pool manager and distributor flows move exactly the stated amount. Unlimited allowance stays unchanged and finite allowance decrements atomically with the transfer.
• Periphery: the five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 archive, whose SHA-256 matches the one recorded in the dependency manifest. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT, no receive or fallback, and no admin surface.
• First principles: supply is exactly one billion times ten to the eighteenth, decimals are 18, name and symbol match the brief, and under CREATE2 the factory, not the transaction initiator, receives the supply. All 33 local tests pass, including the stateful invariant.

The one finding (low): the dependency manifest records SHA-256 hashes for seven forge-std files that do not match the committed copies. The committed files differ from the pinned upstream archive only by line wrapping, and the README claims vendored code is unmodified. This is test-only tooling and does not touch deployed bytecode, so the fix is either restoring those seven files from the pinned archive or regenerating their hashes.

Not reached: there is no launch.json in the tree yet, so the manifest row is marked unreached. The protected Uniswap v4 integration suite needs the launch environment and could not run here.

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

Result: no defects in the token. Coinstark is the unmodified OpenZeppelin v5.4.0 ERC-20 plus a constructor that mints the exact manifest supply to msg.sender. There is no owner, role, pause, blacklist, mint, burn, permit, fallback or receive path, and the compiled ABI confirms only the three state-changing entry points. The deployer holds no power once it transfers. All three guides in my area were applied in full.

• Access Control: permission map is empty beyond the holder-controls-own-balance and allowance rules. The deployer cannot pull from a holder without allowance. Unknown selectors and ETH sends revert.
• Asymmetry: transfer and transferFrom share one _update path with no exemption branch. Approve and spendAllowance are the only writers of the allowance slot and both are guarded as intended.
• Trust Gap: no privileged actor, settable parameter, fee recipient or price formula exists, so none of the four seams has an actor or an economic delta.

Two informational notes were recorded, neither blocking.

1. Seven forge-std files under lib/ do not hash to the values in DEPENDENCIES.json. I downloaded the pinned archive and confirmed the differences are line reflows only, with identical content once whitespace is stripped. The OpenZeppelin files all match exactly. The README's claim that vendored code is unmodified is therefore inaccurate for the test library. Fix by restoring the upstream bytes or recording the real hashes.
2. A zero-value transferFrom from any caller emits a Transfer event with an arbitrary from and no allowance. This is standard ERC-20 behaviour already covered by the project's own tests. It is recorded so off-chain indexers do not treat the event as proof the holder acted.

Checks run: forge build, the full project suite (33 tests and the invariant pass), forge fmt --check, a scratch probe suite covering deployer privilege, unknown selectors, ETH sends and the zero-value event, and the SHA-256 recomputation over DEPENDENCIES.json. The scratch tests were removed afterwards. The static-analysis lead about the large numeric literal resolves to exactly the manifest supply and is not a finding.

Coverage: all three listed entry points are marked holds, plus five invariant rows for the constructor, privileged surface, vendored library integrity, launch flows and trust-gap seams.

Added failure-path, allowance isolation, boundary-value, and fuzz tests. Expanded invariants to 32,768 random calls, checking conservation, failure rollback, and full-balance transfers.

Offline forge build and forge test pass: 45 tests, 0 failures.

Only test/ changed. No implementation defects found.

The review is complete and .imd-findings.json is written. No files other than the findings file were changed.

What I verified

• The token is unmodified OpenZeppelin v5.4.0 ERC-20 with a parameterless constructor minting exactly 1e27 to msg.sender. The project suite passes (45 tests), the compiled ABI exposes only the standard functions plus the constant getter, and the runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. Creation code is well under the size limits.
• launch.json matches the code: empty constructor arguments, totalSupply equal to the mint, decimals 18, lowercase addresses, schema keys only.
• I downloaded both pinned upstream archives. Every OpenZeppelin file is byte-identical to upstream. Seven forge-std files differ from upstream by whitespace only.

Findings kept (3)

1. Low, merged from audit_flow and audit_permissions: DEPENDENCIES.json hashes fail for seven re-wrapped forge-std files, so the README's "vendored code is unmodified" claim is false. Reproduced by recomputing every recorded hash against the tree. Test-only impact, no change to the token.
2. Info: zero-value transferFrom needs no allowance and emits a Transfer with a caller-chosen sender. Reproduced in a scratch test. Inherent ERC-20 behaviour, no fix recommended.
3. Info: the standard approve overwrite race. Reproduced in a scratch test. Already documented in the README as a holder trust assumption.

Coverage: all three entry points answered holds, plus rows for the constructor and supply invariant, the manifest, and dependency provenance. No critical or high findings, so no proof files were attached.