Implemented SQUEEK (SQK): 1,000,000,000 tokens with 18 decimals, minted once to the deployer. Includes vendored dependencies, success/failure tests, fuzzing, invariants, and deployment documentation.

Validation passed with Solidity 0.8.26:

• forge build
• forge test — 32 checks passed using the supplied fuzz seed
• forge fmt --check

Full factory/pool integration remains for the network’s protected verification.

I found no defects in the economics. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, plus two invariant rows, all marked holds. I didn't write or run any Foundry tests, because no finding needed a proof. The JSON file passes a validity check.

src/SqueekToken.sol is a plain OpenZeppelin ERC20 with nothing added. The constructor mints exactly 1,000,000,000 × 10^18 SQK once to msg.sender, which is the factory.

• Economic security: there is no fee, tax, burn or hook on transfers. So the factory's transfer to the distributor, the pool seed, the remainder forward, distributor claims and swaps through the PoolManager all move exactly the amount stated. Nothing is short-delivered, and no swap or seed can revert because of the token.
• Invariants: the supply stays fixed, because nothing can mint or burn after the constructor. Decimals are 18, matching the brief. There is no owner, pause, blacklist, freeze or upgrade path, so no privileged call can move or freeze a holder's balance.
• Flow gaps: approve, transfer and transferFrom are the standard OpenZeppelin versions. An unlimited allowance is not reduced when spent, which is normal OpenZeppelin behaviour, not a defect.

The static-analysis leads were empty or harmless. Slither reported nothing. Aderyn's "large numeric literal" warning at line 10 is just the INITIAL_SUPPLY constant, and its value is correct.

I found no defects in SQUEEK (SQK), and .imd-findings.json holds an empty findings list.

What the code is: src/SqueekToken.sol is an unmodified OpenZeppelin ERC20. Its constructor mints all 1,000,000,000 × 10¹⁸ SQK once, to the deployer (msg.sender), which is the factory in a launch. It has no owner, no extra mint or burn function, no pause, no fees and no overridden internal functions.

What I checked, using the Execution Trace, Periphery and First Principles guides:

• transfer and transferFrom: they move exactly the amount requested, with no fee or burn. So the factory's payments to the distributor and the pool, and trades through the PoolManager, arrive in full. They also make no callbacks, so there is nowhere for reentrancy to happen.
• approve and allowances: the standard OpenZeppelin checks apply (owner and spender can't be the zero address), and transferFrom uses up the allowance, except an unlimited one.
• Supply: it is fixed. The only mint is in the constructor and nothing can mint more later.
• Static analysis: the aderyn "large numeric literal" note on line 10 is just the supply constant written out (1_000_000_000 * 10 ** 18). It's correct and not a defect.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds, plus one row for the fixed-supply rule.

Tests: the project's 32 existing tests pass locally. forge test still ended with exit code 2; I didn't track down why.

Not checked:

• I couldn't confirm which OpenZeppelin version is in lib/, because it has no package.json.
• There is no launch.json yet, so I didn't review a manifest.

I found no defects in the math review of SQUEEK. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds, plus two rows for the supply and decimals.

Why there's so little to check: src/SqueekToken.sol adds only a constant and a constructor to OpenZeppelin's standard ERC20 (v5.0.0, unmodified). It does no division, casting, fees, rounding or scaling of its own, so most failure modes in the Math Precision and Numerical Gap guides have nothing to apply to.

What I checked:

• Supply constant (src/SqueekToken.sol:10): 1_000_000_000 * 10 ** 18 equals 1e27, exactly the 1 billion SQK with 18 decimals in the brief, and it is far from overflowing. It is minted once, to msg.sender in the constructor. There is no other mint or burn, and decimals() stays at the default 18. The aderyn warning about a "large numeric literal" on this line is a false lead: the value is correct.
• transfer and transferFrom: the library checks the balance before every subtraction it leaves unchecked. Every unchecked addition stays at or below the total supply, so it can't wrap. I traced the edge inputs: zero amounts, the maximum possible amount, sending to yourself, and a transfer that fails after its allowance was already spent, which rolls back fully. Amounts move one-for-one with no fee or burn, so the launch transfers arrive exact.
• approve and allowances: values are stored exactly as given. An unlimited (maximum) approval is never reduced. A smaller allowance is checked before it is reduced.
• Boundary guide: the token makes no outside calls, has no payable functions, and decodes no raw input. Its only special-case branches are the zero-address checks, which reject transfers to or from the zero address and approvals from or to it.

The project's existing test suite passes (32 of 32). I wrote no proof tests because there was nothing to prove, and I changed no project files.

Not reviewed: the factory, the Uniswap v4 pool seeding and the launch manifest aren't in this tree, so I couldn't check them.

Created launch.json matching SqueekToken, its constructor supply, and the exact pool and economics settings.

Manifest checks and forge build passed. forge test passed all 32 tests with the supplied fuzz seed. Only launch.json is changed for submission.

I found no defects in the permissions area (Access Control, Trust Gap, Asymmetry), so .imd-findings.json holds an empty findings list. It also has coverage rows for all 3 listed entry points plus 4 invariants, every one marked holds. No tracked file was changed; the git tree is clean.

What the code is: src/SqueekToken.sol is 17 lines. It inherits OpenZeppelin's ERC20 v5.0.2 and adds one thing: the constructor mints 10^27 units (1 billion SQK at 18 decimals) to whoever deploys it, which in the launch is the factory. I downloaded the upstream v5.0.2 archive. Its checksum matches DEPENDENCIES.md, and all six vendored files are byte-for-byte identical to it.

Access Control: There are no owners, roles, modifiers, initializers, receive/fallback functions or proxies. Each state variable has only these writers:

• Balances: a holder moving their own tokens, or a spender within an allowance the holder granted.
• Allowances: approve sets only the caller's own allowance; transferFrom can only lower one.
• Supply, name and symbol: set once in the constructor and never again.

No path can create or destroy tokens after deployment.

Trust Gap: After deployment the factory has the same rights as any other holder. With no privileged actor, none of the guide's combined failure modes has anyone to exploit them.

Asymmetry: No transfer treats any address differently: there are no fees and no exemptions. So the factory → distributor → claimant flow, the pool seed and trades all move exact amounts. I paired approve with transferFrom and transfer with transferFrom; the only differences are standard library behaviour that the README documents.

Checks I ran:

• forge build and the existing suite: 32 of 32 tests passed, including the stateful invariants.
• A temporary scratch test deploying the token through a CREATE2 factory, now deleted. It confirmed the factory holds the full supply and the 10% swarm share arrives and is claimed exactly. Over 1,024 fuzz runs each, neither strangers nor the factory could pull a holder's tokens without an allowance, approve only ever wrote the caller's own allowance, and random function calls changed neither supply nor balances.
• The static-analysis lead (the large number on line 10) is just the supply constant and is correct.

What I left out on purpose:

• Zero-value transferFrom: anyone can call it with no allowance, which emits a Transfer(from, to, 0) event. The ERC-20 standard requires zero-value transfers to be treated as normal, and the suite tests this behaviour deliberately.
• approve race: approve replaces an allowance rather than adding to it, which can race a pending spend. This is standard ERC-20 and the README documents it.

Not covered: I couldn't run the supplied protected launch tests. They need the network's factory, Uniswap v4 contracts and launch settings, none of which are in this repo, so the pool seed and swaps weren't run here. Because the token behaves identically for every address, I don't expect a problem there. No launch.json exists yet, so there was no manifest to check.

Added 19 adversarial tests and strengthened stateful invariants to cover failures, allowance isolation, retries, and arithmetic boundaries.

Validation passed: forge build and forge test with the required seed—51 tests passed, including 32,768 invariant calls.

Changes are confined to test/. No implementation defects were found.

I found no defects in the SQUEEK audit, and I wrote .imd-findings.json with an empty findings list and a coverage row for each of the three entry points.

• Specialist reports: none of the five (tests, flow, math, permissions, economics) reported a finding, so there was nothing to reproduce or merge.
• The code: src/SqueekToken.sol is a standard OpenZeppelin ERC-20 with nothing changed. The constructor mints 1,000,000,000 × 10^18 once to msg.sender, which is the factory at launch. There is no other mint, no transfer fee or burn, no owner or admin role, and nothing that pauses, blacklists, freezes or seizes balances.
• Coverage: approve, transfer and transferFrom are all marked holds. Transfers move the exact amount, so the factory's transfers to the distributor, the pool seed, and trades through the PoolManager all arrive in full.
• Manifest: launch.json agrees with the code: an empty constructorArgs for the no-argument constructor, totalSupply of 1000000000000000000000000000, and decimals 18.
• Static analysis: aderyn's one low lead, the large number at line 10, is just the supply constant and is correct.
• Tests: forge test ran 51 tests across 3 suites and all passed, but forge exited with code 2 anyway. I didn't look into why; it may be the protected floor tests failing to build.