Implemented UNLOCK (UNLK): 1,000,000,000 tokens with 18 decimals, minted once to the deployer. No later minting or administrative powers.

Dependencies are vendored for offline builds. Deployment parameters, assumptions, and operational responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed all 30 tests using the supplied fuzz seed.
• forge fmt --check passed.

I wrote launch.json for the UNLOCK (UNLK) custom token launch, and it is the only file changed.

What the manifest says

• Token contract is UnlockToken, name UNLOCK, symbol UNLK, 18 decimals, with an empty constructorArgs list because the accepted constructor takes no parameters.
• totalSupply is one billion tokens in minor units, matching the INITIAL_SUPPLY constant the constructor mints once to msg.sender.
• contracts is empty since the accepted tree has no application contracts, only the token.
• pool uses the IMD pair address, fee 12500, tick spacing 60 and the one-to-one initialPrice from the launch reference.
• economics is copied verbatim from the job.
• notes describe the token's behavior, the absence of admin powers or transfer fees, and the launch flows, at about 1,250 characters.

Checks I ran

• Parsed the JSON and confirmed only the schema's six top-level keys, the exact supply string, the verbatim economics object, and a contract name within 32 characters.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 30 tests across both suites.
• git status shows launch.json as the only new file, with no other changes.

The review is complete and the findings file is written. The tree is otherwise unchanged (the findings file is gitignored or untracked, and the scratch test was removed).

Outcome: no math, boundary, or numerical-gap defects in the token. src/UnlockToken.sol is the unmodified OpenZeppelin ERC20 v5.0.2 plus one constant and a constructor. There is no division, scaling, fee, external call, payable path, sentinel branch, or byte decoding, so most items in the three guides have nothing to attach to. The remaining arithmetic was checked directly:

• Supply constant evaluates to exactly 10^27, which matches the manifest value and 18 decimals, and is minted once to the factory through checked addition.
• Transfer and transferFrom guard every unchecked subtraction with an explicit comparison. I exercised 1 wei, full balance, balance plus one, zero, self-transfer, full-supply moves, allowance equal to value, zero allowance, max and max-minus-one allowances, and self-transferFrom. All behaved exactly and supply was conserved.
• No receive or fallback: ETH sends and unknown selectors such as mint, burn, and admin calls revert.
• Existing suite of 30 tests, including 1,000-run fuzzes and the 128-by-64 invariant run, passes with the documented seed. Both static tools reported nothing above the "large numeric literal" style note, which is not a defect.

One info-level note outside my area. DEPENDENCIES.md and the README say every vendored file is verified by the checksum list, but running that check on the committed tree reports seven forge-std files as mismatched. All OpenZeppelin files match, so production code is unaffected. The reproduction is the single documented command and its FAILED output.

Coverage record: all three listed entry points marked holds, plus rows for the constructor and supply constant, the no-fallback boundary, and the supply-conservation invariant, each with a one-line reason.

The review is complete and .imd-findings.json holds the result.

Outcome: no access-control, trust-gap or asymmetry defect in the token. UNLK is a 17-line contract over byte-identical OpenZeppelin v5.0.2 ERC20. The constructor takes no arguments, hands out no roles, and mints the full supply once to the immediate deployer. The compiled ABI exposes exactly three state-changing functions and no receive, fallback or constructor inputs.

What I checked in the assigned area:

• Access control. Every writer of each storage slot is caller-scoped. Allowances are written only by the owner's own approve or decreased by _spendAllowance for the owner-spender pair. Balances move only through _transfer. There is no owner, initializer, minter, pauser, blacklist, upgrade path or delegatecall in the runtime bytecode. The deployer has no bypass of the allowance check.
• Asymmetry. transfer and transferFrom share the same _transfer leg, so the only difference is the allowance spend. Revert paths roll back the allowance. Zero-address and max-value branches behave as the standard says.
• Trust gap. The factory holds the whole supply after deployment by design and needs no exemption list, since there are no transfer rules. The 10/80/10 launch split, a claim and both pool directions move exact amounts with constant supply.
• Verification run. The project builds on Solidity 0.8.26, all 30 tests pass with the README's fuzz seed, and forge fmt --check passes. Slither and aderyn reported nothing above a style note on the supply literal.

One informational item outside the area: the integrity check in DEPENDENCIES.md fails. Seven vendored forge-std files differ from the recorded sums because they were reformatted after the sums were recorded. With whitespace removed they are identical to upstream v1.9.7, and all OpenZeppelin files match byte for byte, so the deployed bytecode is unaffected. The reproduction is the documented command itself:

sha256sum -c lib/SHA256SUMS
# WARNING: 7 computed checksums did NOT match (exit 1)

The coverage record marks all three entry points as holding, with five invariant rows and the one finding row. No proof test was written since nothing reached high severity, and no repository file other than the findings file was changed.

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

Result: one low-severity finding, all three entry points hold.

UnlockToken is the unmodified OpenZeppelin v5.0.2 ERC-20 plus a supply constant and a constructor minting 10^27 units to the immediate creator. I traced approve, transfer and transferFrom through _approve, _spendAllowance, _transfer and _update against the Execution Trace, Periphery and First Principles checklists. Every revert path rolls back fully, the unchecked arithmetic is bounded by the supply invariant, infinite allowance is not decremented, and there is no callback, fallback, owner, mint, burn or upgrade surface. The launch flows (factory to distributor to claimant, and both pool-manager directions) move exact amounts. The aderyn literal lead is exactly 10^27 and matches the manifest supply.

Finding (low): DEPENDENCIES.md says the 30 vendored forge-std files are unmodified and that the recorded checksums verify. In the committed tree the check fails:

sha256sum -c lib/SHA256SUMS   # 29 OK, 7 FAILED

The recorded sums match upstream v1.9.7, but the committed files were re-wrapped by forge fmt, which the README's format check prescribes and which formats lib/ because foundry.toml excludes nothing. The diff is whitespace only, so behaviour is unchanged. The six OpenZeppelin files are byte-identical to the v5.0.2 tag. Suggested fix: restore the 7 files and ignore lib/ in fmt, or regenerate the sums and drop the word "unmodified".

Coverage record: 9 rows. The three ABI entry points and the constructor hold, plus invariant rows for fixed supply, forbidden opcodes, OpenZeppelin integrity, and the static-analysis lead. The forge-std integrity row points to finding 1. Nothing was left unreached. The only item I could not check is the README's "Ethereum, chain ID 1" launch-chain claim, since no network.json or launch.json is in the tree.

I found no economic defects in UNLOCK (UNLK). The findings file .imd-findings.json holds one info-level note, which is outside the economics area, and a full coverage record. I changed no files in the repository: the build passes and all 30 local tests pass.

Economic Security

• The token is src/UnlockToken.sol, unmodified OpenZeppelin v5.0.2 ERC-20 code. Its six OpenZeppelin files match their recorded checksums, so the deployed logic is what it claims to be.
• Transfers have no fee, burn, rebase, blacklist, pause or callback. Every launch transfer arrives whole: factory to distributor, distributor to claimant, the pool seed, and trades in and out of the pool.
• It takes no constructor arguments, so there are no exemptions to get wrong. There are no ERC-2612 or ERC-4626 surfaces.

Invariants

• Supply: INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 is exactly 10^27 base units (1 billion tokens with 18 decimals). It is minted once, to whoever deploys the contract, which is the factory in a launch.
• No supply change: _mint is only reachable from the constructor. There is no mint, burn, owner or upgrade function anyone can call later.
• Balances add up: the sum of balances always equals total supply. The unchecked arithmetic is safe because a sender's balance can never exceed total supply.
• Allowances: an unlimited allowance is not decreased when spent, and a reverted transferFrom restores the allowance.

Flow Gap

• Since transfers carry no logic at all, no sequence of calls can short the swarm share, the pool seed or a trade, or freeze a holder's balance.

Note (info, outside economics): running sha256sum -c lib/SHA256SUMS reports 7 mismatches, all in test-only forge-std files (for example lib/forge-std/src/Vm.sol, line 23 of the checksum file). DEPENDENCIES.md says every vendored file is unmodified, so its own integrity check contradicts it. This does not affect the deployed token.

Coverage: approve, transfer and transferFrom all hold. I also added rows for the supply, balance-sum and launch-flow invariants. The aderyn "large numeric literal" lead at line 10 is a false positive: the value is correct.

Limits: I did not run the protected launch tests. They need the network's factory and pool contracts, which this repository doesn't include.

Added failure-path tests, five fuzz properties, and accounting invariants covering 32,768 random calls. All additions are under test/.

• Offline forge build and seeded forge test: 48 passed, 0 failed.
• Slither: two informational advisories; no concrete defect found.
• Aderyn unavailable.

Commands, results, and limitations: test report.

The review is complete and .imd-findings.json is written. The tree is otherwise untouched.

Outcome: the token is sound. The only reproducible defects are documentation accuracy, not code.

What I verified

• src/UnlockToken.sol is an unmodified OpenZeppelin v5.0.2 ERC-20 that mints exactly 10^27 units to msg.sender in its constructor with no parameters. The five vendored OpenZeppelin files are byte-identical to the upstream tag.
• The compiled ABI exposes only approve, transfer, transferFrom and the views. A scratch test deployed through CREATE2 from a factory contract confirmed the whole supply lands on the factory, the swarm share moves and is claimed whole, and admin-style selectors all revert. The opcode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT. Creation code is 2635 bytes.
• The project's own 48 tests, including the stateful invariants, pass with the documented seed.
• launch.json matches the code: empty constructorArgs, totalSupply equal to the minted amount, schema-only keys, lowercase addresses.

Findings kept

1. Low, merged from all four specialists. The sha256sum -c lib/SHA256SUMS check in DEPENDENCIES.md fails for seven forge-std files. I fetched the upstream v1.9.7 files: their hashes equal the recorded sums, and the whitespace-stripped content is identical, so the drift is a forge fmt re-wrap of test-only code. The "unmodified" claim is false but production bytecode is unaffected.
2. Info. README.md line 59 says the repository contains no launch manifest, but launch.json is now committed.

Coverage: all three entry points are marked holds with one-line reasons, plus rows for the supply invariant, deployability, and the merged specialist finding. No critical or high findings, so no proof files were attached.