Implemented UNLOCK (UNLK): 1,000,000,000 tokens with 18 decimals, minted once to the deployer. Dependencies are vendored; deployment assumptions and responsibilities are documented in README.md.

Validation passed: forge build, forge test with the specified seed, and forge fmt --check. All 29 tests passed, including fuzz and invariant checks.

I found no math defects in UnlockToken, so .imd-findings.json holds an empty findings list plus a coverage row for each entry point.

What I looked at: src/UnlockToken.sol is a 16-line contract built on OpenZeppelin's standard ERC-20 (version 5). It has no transfer fee, no tax, no burn, no rebasing, and no owner. The only mint is in the constructor, and it mints 1_000_000_000 * 10 ** 18 to msg.sender. That value is fixed when the contract is compiled, is exactly 10^27, and is far below the uint256 limit (about 1.2 × 10^77). It matches the brief: 1 billion tokens with 18 decimals.

Math precision and boundaries: this code does no division, rounding or scaling, so those checks don't apply. The only arithmetic is in OpenZeppelin's balance and allowance updates:

• Balance decrease: the sender's balance is checked against the amount before it is reduced, so it can't wrap below zero.
• Balance increase and supply decrease: these are capped by the total supply, which can never change after deployment.
• Allowance decrease: the allowance is checked against the amount first, and an allowance set to the maximum uint256 value is treated as unlimited and never reduced.
• Edge cases traced: a transfer to yourself, a transfer of 0, a transfer of exactly your full balance, and a balance-or-allowance plus 1. Each either works as intended or reverts with the right error.

Coverage:

• approve, transfer and transferFrom are all marked holds.
• I also checked two invariants: the supply is always 10^27, and 18 decimals is consistent with the supply. Both hold.

Leads I ruled out:

• Slither reported nothing.
• Aderyn's "large numeric literal" note on line 10 is about style only; the value is correct.

Tests: the project's own 29 tests pass, including the invariant fuzzing, which made over 8,000 calls with no reverts.

Not done: I didn't run the supplied launch-flow checks (Token.protected.t.sol); I only read their assertions. A plain ERC-20 with no transfer fee has no mechanism that could make a launch transfer arrive short.

No repository files were changed.

Done. I wrote launch.json for the UNLOCK (UNLK) custom token launch and verified the tree.

What the manifest says

• Kind is custom_token. The token contract is UnlockToken, name UNLOCK, symbol UNLK, 18 decimals.
• constructorArgs is empty, matching the accepted constructor, which takes no parameters and mints everything once to msg.sender.
• totalSupply is the constant the constructor mints, 1,000,000,000 tokens in minor units.
• contracts is empty. The accepted tree has only the token, so no application contracts are named.
• pool and economics are copied exactly as the launch gives them: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object verbatim.
• notes describe the token's fixed supply, lack of admin powers and exact transfer behavior, at 952 characters.

Checks

• A schema sanity check confirmed only the allowed top-level keys, the verbatim economics object, and the supply matching 10^27.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 29 tests in both suites.
• git status shows launch.json as the only new or changed file.

The review is complete. The findings file holds no defects and a full coverage record.

Result: no defects found in the UNLOCK token's permission model. .imd-findings.json is written with an empty findings list and seven coverage rows, one per listed entry point plus the constructor role map, dependency integrity, the supply invariant and the Aderyn lead.

What was checked, against the Access Control, Trust Gap and Asymmetry guides:

• The contract is a 16-line subclass of OpenZeppelin ERC-20 whose only privileged act is the constructor mint of exactly 10^27 units to the deployer, the factory on launch. It inherits no Ownable, AccessControl, initializer, proxy, mint, burn, pause or blocklist path, and the compiled ABI exposes only approve, transfer and transferFrom as state-changing.
• The vendored OpenZeppelin files are byte-identical by SHA-256 to upstream commit dbb6104 (v5.0.2), as DEPENDENCIES.json declares, so the inherited guards are the audited upstream ones.
• Every allowance and balance slot has one writer path with one validation shape. transferFrom spends the allowance before moving tokens, so even the factory cannot move a holder's balance without that holder's approval. The one asymmetry between transfer and transferFrom is OpenZeppelin v5 not emitting Approval when allowance is spent. That changes no state and the README documents it.
• Offline build and the existing 29 tests, including the invariant suite with 128 runs at depth 64 and zero reverts, all passed. The Slither lead list was empty and the Aderyn large-literal lead resolves to the exact brief supply.

Not covered: no launch.json exists yet, so the manifest was not reviewed. No files other than .imd-findings.json were written.

Review complete. The findings file is written with an empty findings list and nine coverage rows. No files outside it were changed and the formatter check passes.

Scope

Files read: src/UnlockToken.sol (16 lines), the vendored OpenZeppelin ERC20 and its four imports, both existing test files, the README, and the protected floor tests. Guides applied: Senior Auditor's Mindset, Economic Security, Invariant, Flow Gap.

Severity counts: 0 Critical · 0 High · 0 Medium · 0 Low

Result

The token is an unmodified OpenZeppelin v5.0.2 ERC-20 with one constructor mint of 10^27 units to the immediate deployer. There is no custom transfer logic, no owner, no external call and no supply path after construction. Every economic failure mode in the three guides needs a lever the code does not have.

What I checked and how:

• Dependency integrity. The six vendored OpenZeppelin files hash-match both the repo's pins and the upstream files at commit dbb6104c, which I fetched independently. No hidden hook or backdoor.
• Supply invariant. The constant equals exactly 10^27, confirmed with node and forge. Only the constructor calls mint; no burn, mint or update override is reachable, including from the deployer.
• Conservation. The existing invariant suite (128 runs, depth 64, reverts fatal) and my scratch probe both hold balances summing to supply across transfer, approve and transferFrom.
• Launch flow gaps. A scratch test modelled the factory deployment, the swarm share, the pool seed, the remainder and a trader round trip. Every leg arrived exactly, since there is no tax, burn, exemption or callback.
• Sentinel and boundary cases. Zero recipient and zero spender revert, zero-address sender reverts in allowance spending, self-transfer of the full balance is neutral, max allowance stays unlimited, finite allowance decrements and reverts atomically on shortfall.
• Static-analysis leads. Slither reported nothing; the aderyn "large numeric literal" line is cosmetic and the value is correct.

Observations (non-blocking)

• Standard ERC-20 allowance replacement ordering risk, already documented in the README.
• Tokens sent to the token's own address are unrecoverable by design, since there is no admin power.
• No launch.json exists in the tree yet. When it is written, the constructor takes no arguments, so its constructorArgs must be the empty list and totalSupply must be the 28-digit value 1 followed by 27 zeros.

Coverage

All three entry points are marked holds, plus six invariant and flow rows, in .imd-findings.json. Nothing was left unreached.

The review found no defects in the UNLOCK token. The findings file is written with an empty findings list and nine coverage rows, and the working tree is unchanged apart from that file.

What I reviewed

• src/UnlockToken.sol is a 16-line contract inheriting unmodified OpenZeppelin v5.0.2 ERC-20, with one constructor mint of 10^27 units to the immediate deployer and no other functions.
• I traced the three listed entry points, approve, transfer and transferFrom, through the vendored base contract for every failure mode in the Execution Trace, Periphery and First Principles guides: sentinel values, approval residuals, partial state updates, stale reads, unvalidated inputs, hidden side effects, and boundary cases.
• A scratch Foundry suite exercised the factory launch flow with exact 10/80/10 amounts, zero and max-uint sentinels, atomic rollback when allowance suffices but balance does not, ETH rejection, and the standard approve race. All six probes passed. The repo's own 29 unit, fuzz and invariant tests also pass with the verifier seed.

Periphery checks

• SHA-256 of all five vendored OpenZeppelin files matches DEPENDENCIES.json, and their contents read as genuine upstream sources.
• An opcode scan of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE opcodes, so there is no external-call or callback surface.
• The ABI exposes only ERC-20 functions, the supply constant, two events and six ERC-6093 errors. There is no mint, burn, owner, pause, blacklist or upgrade path.

Not reached

• Pool seeding and swaps were reasoned from the transfer path, not executed, since Uniswap v4 core is not vendored and the protected harness needs the network's environment.
• No launch.json exists yet, so the manifest row is marked unreached with the values it must carry.

The standard ERC-20 approve ordering race exists and is documented in the README. It is a property of the standard, not a defect in this code, so it is not reported as a finding.

Added boundary, failure-path, and fuzz tests, plus stateful invariants tracking balances and allowances independently.

Verified offline with the required seed:

• forge build passed.
• forge test passed: 48 tests, zero failures.
• Invariants exercised 32,768 random calls.

All changes are under test/. No confirmed implementation defects found.

The review is complete. The findings file is written and the working tree has no changes of mine beyond it.

Result: no defects found. All four specialists and the test writer reported nothing, and my own pass confirms the code is clean.

What I verified against the code:

• Source is a 16-line contract: OpenZeppelin v5.0.2 ERC20, name UNLOCK, symbol UNLK, default 18 decimals, and a no-argument constructor that mints one billion tokens to msg.sender. No owner, mint, burn, pause, blacklist, fee, hook, receive or fallback.
• Vendored library files match the hashes in DEPENDENCIES.json and read as genuine OpenZeppelin logic line by line. The sandbox blocked fetching upstream to compare independently, so the record in the repo was the reference.
• Bytecode is 2,635 creation bytes and 1,752 runtime bytes, far under the limits, with no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE opcodes.
• Floor behaviour was reproduced in a scratch Foundry test: CREATE2 deployment from a factory stand-in leaves the whole supply at the factory, the ten percent swarm flow arrives and is claimable whole, 22 common admin selectors revert from both a stranger and the factory, and the factory cannot pull a holder's balance without approval. The existing 48 project tests, including 256 invariant runs, also pass. The scratch file was deleted afterwards.
• launch.json uses only schema keys, totalSupply equals what the constructor mints, constructorArgs is empty to match the constructor, addresses are lowercase, and the notes are under the length limit.
• Static analysis leads were cosmetic: the aderyn large-numeric-literal is a compile-time constant with digit separators.

The coverage record answers all three entry points as holds, plus four invariant rows covering supply, privileged powers, dependency integrity and the static-analysis leads.