Implemented Masklings (MASKLINGS) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No administrative or further minting powers.

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

Validation passed:

• forge build
• forge test: 33 tests, including fuzz and invariant checks
• forge fmt --check
• Dependency integrity and deployment bytecode checks

Created launch.json matching the accepted constructor, exact supply, and required pool and economics values.

forge build succeeded. All 33 local tests passed with the supplied fuzz seed.

Only launch.json changed outside permitted scratch artifacts.

I found no economic defects in Masklings. The review is in .imd-findings.json, which holds one info-level note from outside the economics area, and no other file changed.

What I checked: src/Masklings.sol is OpenZeppelin v5.0.2's standard ERC20 with nothing added except a constructor that mints 10^27 units (1 billion tokens at 18 decimals) to msg.sender. I diffed the vendored ERC20.sol against upstream v5.0.2 and it is byte-identical. I checked the code against the Economic Security, Invariant and Flow Gap guides:

• Supply: the only mint is in the constructor. There is no other mint or burn function and the transfer logic is not changed, so the supply stays at 10^27 forever and can't be diluted below the market cap the opening price is based on.
• Launch flows: there is no fee, burn, rebase or exemption logic. Each launch transfer moves exactly the amount it says: the 10% swarm share to the distributor, claims out of it, the pool seed, and buys and sells through the PoolManager.
• Privileged powers: there is no owner, role, pause, blocklist, seize or burnFrom. Nobody but the holder can move or freeze a balance.
• Allowances: transferFrom reverts when the allowance is too small, an unlimited allowance is never reduced, and a failed call rolls back the allowance change. The approve race is the usual ERC-20 one, and the README already documents it.
• Tests: forge test passes all 33 tests, including the stateful invariant run. Slither found nothing, and Aderyn's only lead (the large number literal at line 10) is the supply constant, not a defect.

The info note: the project's own integrity check, sha256sum -c DEPENDENCIES.sha256, fails on 7 vendored forge-std files, even though DEPENDENCIES.md:15 says the files are unmodified. I compared them with the upstream v1.9.7 tarball, whose archive hash matches the recorded one: the only differences are formatting from forge fmt. No logic changed, the files are used only by tests, and the deployed token is unaffected.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds, along with four invariant and flow rows. I couldn't run the protected pool harness because its dependencies (v4-core and the floor files) aren't in this tree, so the pool-flow conclusions come from reading the code, not from a pool simulation. No finding is high enough to need a Foundry proof.

Review complete. The findings file is written and the only working-tree change is .imd-findings.json (ignored by git, so status is clean).

Outcome: the permission model holds. Masklings is a 17-line contract that inherits OpenZeppelin v5.0.2 ERC20 unchanged and mints the full supply once to the deployer. There are no roles, modifiers, initializers, proxies, or admin entry points, so the Access Control, Trust Gap and Asymmetry guides find nothing to break.

What I verified

• Vendored code is genuine. I downloaded the upstream v5.0.2 archive and all six OpenZeppelin files are byte-identical. The token's entire behaviour is unmodified upstream code.
• ABI surface. The compiled ABI exposes only the ten standard ERC20 and metadata selectors plus the supply constant. Nothing else.
• Scratch test replaying the protected floor. Deployed through a factory stub with a pranked origin. The factory holds the entire supply, the origin gets nothing. All 22 admin signatures revert from both the factory and a stranger. The factory cannot pull 1 wei from a holder without approval. ETH sent to the contract reverts. The reachable runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Asymmetry pass. The approve and spend paths write the same slot with consistent guards. Zero-value transferFrom without allowance succeeds and emits a Transfer event naming any sender. That is standard OpenZeppelin behaviour already documented in the README, so I noted it in coverage rather than as a defect.
• Project tests. All 33 tests and the 128-run invariant suite pass with the README's seed. forge fmt --check passes.

One finding, low severity, outside my area. The README's documented check sha256sum -c DEPENDENCIES.sha256 fails on the committed tree. Seven forge-std files were reformatted by forge fmt after their upstream hashes were recorded, so the manifest no longer matches and the claim that files are "unmodified upstream sources" is inaccurate. The diffs are whitespace-only and the files are test-only dependencies, so the token is unaffected. The fix is to regenerate the hash manifest or restore the upstream files verbatim.

Coverage record. All three listed entry points are marked holds, plus rows for the constructor, the receive/fallback absence, and three invariants. One invariant row points at the finding.

Not covered. The protected pool-seeding test depends on Uniswap v4 sources not in this tree, so I could not run it. Since the token has no transfer fee or exemption logic, the launch flows move exactly what is requested, and the project's own distribution test confirms this at the token level.

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

Outcome. The Masklings token has no control-flow defects. It is a bare OpenZeppelin v5.0.2 ERC20 with a single constructor mint, and all three state-changing entry points behave as the standard specifies. One low-severity integrity defect in the deliverable's vendored test dependency is reported.

What I checked

• Execution trace. Traced approve, transfer and transferFrom through the inherited ERC20 with concrete inputs: zero recipient, zero amount, self-transfer, over-balance, over-allowance, unlimited allowance, and reverts after the allowance decrement. All roll back cleanly and move exactly the stated amount. Sum of balances stays at 10^27 since no mint path exists after the constructor.
• Periphery. All five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 archive. The forge-std files are not: seven were reformatted after the hash file was written.
• First principles. The constructor takes no arguments, makes no external calls, and mints everything to the immediate creator. Under CREATE2 from a factory the factory holds the full supply. A reachable-opcode scan of the compiled runtime finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Plain ETH, unknown selectors and payable calls revert.
• Tests. The project's 33 tests and the invariant suite pass. A scratch floor test I wrote also passed and was removed, since it supports no finding.

The one finding (low). Running the README's own check fails:

sha256sum -c DEPENDENCIES.sha256
→ 7 FAILED (lib/forge-std/src/StdAssertions.sol, StdJson.sol, StdToml.sol, Vm.sol, console.sol, interfaces/IERC7540.sol, interfaces/IMulticall3.sol)

The recorded hashes match upstream forge-std v1.9.7, and the in-tree files are identical to upstream once whitespace is stripped, so the change is line-wrapping only. The statement in DEPENDENCIES.md that the files are unmodified is therefore false for the test dependency. The production contract is unaffected. The fix is to restore the seven files from the upstream archive or regenerate the hash file and amend the claim.

Coverage. All three listed entry points are marked holds, with additional rows for the constructor, the absence of privileged paths, both vendored dependencies, and the launch flows the protected floor exercises. Static-analysis leads were checked: the large-numeric-literal note is the exact required supply and is not a defect.

Not verified. The README's claim that the launch chain is Ethereum mainnet comes from no source I was given. It is a deployment input, not a code property, so it is not reported as a finding.

Expanded failure-path, boundary, fuzz, and stateful invariant coverage.

• forge build passed.
• All 51 tests passed with the supplied seed.
• Invariants passed across 32,768 randomized calls.
• Only test/ files changed.

No implementation defects were found.

The review found one low-severity issue and nothing wrong with the token itself. The results are in .imd-findings.json, and no other files were changed.

The finding (low): All four specialists reported the same problem, so I merged their reports into one. The repo says its bundled third-party files are untouched copies of the originals, and the README tells you to confirm this with sha256sum -c DEPENDENCIES.sha256. That check fails for 7 forge-std files (DEPENDENCIES.md:15, "Files are unmodified upstream sources."). I reproduced it: the check reports 7 failures. I also downloaded the original Vm.sol from forge-std v1.9.7. Its fingerprint matches the one recorded in the repo, and once whitespace is removed it is identical to the repo's copy. So the files were only reformatted, and no code changed. forge-std is used only by tests. The OpenZeppelin files the token is built on all pass the check, so the deployed token is not affected. That puts this at low severity, because the provenance claim and the README's own check are wrong but nothing else is. Two specialists rated it low and two rated it info; I kept low. Being low, it carries no test proof.

The token: src/Masklings.sol is OpenZeppelin's standard ERC20 v5.0.2 with nothing added. Its constructor creates 10^27 units (1 billion tokens with 18 decimals) once and gives them all to the deployer. It has no fees, no admin powers and no other way to create or destroy tokens, so the launch transfers move exact amounts. launch.json matches: the contract name is Masklings, there are no constructor arguments, 18 decimals, and the same total supply.

Coverage: approve, transfer and transferFrom are all marked holds. The record also has two extra rows for checks I made: the supply is fixed and all of it goes to the deployer, and the contract has no admin powers, DELEGATECALL or SELFDESTRUCT.

Checks run: forge build succeeded and all 51 local tests passed with the README's fuzz seed. Static analysis raised one note, a "large number" warning on INITIAL_SUPPLY at line 10. That value is correct, so I didn't report it.