Implemented SQUEEKSTR (SQKSTR): 1 billion tokens with 18 decimals, minted once to the deployer. Dependencies are vendored for offline builds.

Validation passed: forge build, all 35 tests with the supplied fuzz seed, and forge fmt --check.

Deployment parameters and responsibilities are documented in README.md.

I found no defects, so .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all holds.

Why the permissions area comes up empty: src/SQUEEKSTR.sol is a plain OpenZeppelin v5.1 ERC20 and changes nothing it inherits. Its only code is a constructor that mints 1_000_000_000 * 10**18 (1e27) once to msg.sender, which is the factory in a launch. It has no owner or roles and no mint or burn functions. There is no pause, blacklist, fee or exemption list, no receive or fallback, and no external calls.

Against the three guides:

• Access Control: no privileged role exists. transfer only moves the caller's own balance. approve only sets the caller's own allowance and rejects the zero address as spender. transferFrom only works with an allowance from the holder, and only an unlimited allowance is left undecremented, as OpenZeppelin documents.
• Trust Gap: the constructor takes no arguments and gives out no roles, so after deployment nobody holds any power. The factory, PoolManager and distributor transfers move exactly the amount stated.
• Asymmetry: transfer and transferFrom both run through the same _update path, so neither has a check the other lacks.

Tool leads: aderyn flagged a large number at SQUEEKSTR.sol:12. It is 1_000_000_000 * 10 ** 18 = 1e27, which matches the stated supply, so it is not a defect. Slither reported nothing.

What I checked and what I didn't: the project's own 35 tests pass. I didn't run the protected tests: they import launch helpers that aren't in this tree, so I only read them. I didn't diff lib/openzeppelin-contracts against the official v5.1 release; I took it to be unmodified. The known race where a spender front-runs a change to their allowance belongs to every ERC20, not this code, so I didn't report it.

I wrote launch.json for the SQUEEKSTR launch, and it is the only file changed. forge build succeeds, and forge test with the verifier's fuzz seed passes all 35 tests in the repository's own suites. The two protected tests weren't run, because they need a launch harness and environment that only the verifier has. Nothing validates the manifest locally, so I checked it by reading it against the schema rules and confirmed it parses as JSON. I haven't committed it.

• Token: the contract is SQUEEKSTR, named "SQUEEKSTR" with symbol "SQKSTR" and 18 decimals. Its constructor takes no parameters, so constructorArgs is []. totalSupply is "1000000000000000000000000000", which is the 1,000,000,000 × 10^18 the constructor mints once to msg.sender.
• Contracts: []. The accepted code has only the token contract (src/SQUEEKSTR.sol), with no application contracts.
• Pool: paired with IMD (0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7), fee 12500, tick spacing 60, and the one-to-one initial price 79228162514264337593543950336.
• Economics: copied exactly as given: {"poolBps":6000,"initialMarketCapWei":"3000000000000000000000","remainderTo":"0xee2aaa315cf7ed169f93148d30d24af9318dbb66"}.
• Notes (667 characters): the token is a plain fixed-supply ERC-20 with no owner, no mint or burn functions and no transfer fees. The launch deploys no other contracts.

I found no economic defects in SQUEEKSTR, and one informational issue outside my area. The results are in .imd-findings.json: one finding, plus a coverage row for each entry point and the invariants I checked. I changed no other files.

What I checked (Economic Security, Invariant and Flow Gap guides):

• src/SQUEEKSTR.sol is a plain OpenZeppelin v5.1 ERC20 with no changes to its transfer logic. The constructor mints the full 1,000,000,000 × 10^18 tokens to whoever deploys it (the factory, in a launch). There is no other way to mint or burn, no fee or burn on transfer, no hooks, no owner or admin powers, and no delegatecall or selfdestruct.
• Flows: every transfer moves exactly the amount sent. So the factory's transfer to the distributor, the pool seed, and swaps in both directions through the PoolManager all arrive in full.
• Fixed supply: total supply stays at 10^27 and the sum of all balances always equals it. I checked this by reading the code; the project's own invariant suite also passes.
• Brief: decimals are 18 and the supply matches the brief exactly.
• Entry points: approve, transfer and transferFrom all hold. I traced each one's checks, state changes and failure paths. Over-balance and over-allowance calls revert, and an unlimited allowance is never reduced.
• Static analysis: aderyn flagged the large number on line 12 (INITIAL_SUPPLY). It is correct and only a style note.
• forge test passed 35 of 35. I didn't run the protected launch tests (Token.protected.t.sol) because they import harness files (src/LaunchLiquidity.sol and two others) that this tree doesn't have.

Finding (info, outside my area): the integrity check that DEPENDENCIES.md documents fails. Running sha256sum --check lib/SHA256SUMS reports 19 mismatches. They are all in the vendored forge-std files, which only the tests use; for example, Vm.sol hashes to e83459…, but the recorded value is 9068805…. The OpenZeppelin files that go into the deployed token all match. The deployed token isn't affected, but the dependency record is wrong for forge-std.

Not covered: there is no launch.json in the tree yet, so I couldn't review a manifest.

The review is complete and written to .imd-findings.json. No repository file was changed, and nothing was left under test/scratch/.

Result: one low finding, no defects in the token itself.

The contract is an unmodified OpenZeppelin v5.1.0 ERC-20 with a single constructor mint of 10^27 units to the immediate deployer. The three entry points (approve, transfer, transferFrom) were traced through the Execution Trace, Periphery and First Principles guides and each holds: zero-address sentinels are rejected, every revert rolls back the allowance debit atomically, max allowance is never decremented, self and zero-value transfers are balance-neutral, there are no external calls, hooks, receive or fallback, and the compiled ABI exposes no mint, burn, owner, pause or initializer. The runtime bytecode has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. All six vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 commit. The project's own suite (35 tests, fuzz and invariants) and forge fmt --check pass. Neither static-analysis lead (aderyn's large-literal note) is a defect.

The one finding (low): the documented integrity check in DEPENDENCIES.md, sha256sum --check lib/SHA256SUMS, fails on 19 of the 30 forge-std files. The recorded hashes match upstream forge-std v1.9.7, but the committed files were reformatted afterward (whitespace-only differences). It affects only the test toolchain and the repo's provenance claim, not deployed code. Fix is to regenerate the record or restore the upstream bytes.

Coverage: all three listed entry points plus five invariant rows (supply, vendored base, bytecode opcodes, forge-std record, test suite). Nothing was left unreached.

I added two test files and changed nothing else. The full suite passes with the verifier's fuzz seed: 54 tests in 4 suites, 0 failures.

Defects found: none. src/SQUEEKSTR.sol is a plain OpenZeppelin v5 ERC20. Its constructor mints 10^27 (one billion with 18 decimals) to whoever deploys it, and it adds nothing else: no owner, no mint or burn, no pause, no tax, no permit. Nothing failed that I would have to test around, so I did not write .imd-findings.json. One thing to know, though it isn't a defect: tokens sent to the token contract's own address are accepted and can never be recovered, because the contract has no rescue function. A test records this.

What was already there (earlier work, kept as it was): test/SQUEEKSTR.t.sol with 34 unit and fuzz tests, and test/SQUEEKSTR.invariant.t.sol, an invariant suite over four fixed holders.

test/SQUEEKSTR.edges.t.sol (18 tests):

• Deployment: for any deployer and any transaction origin, only the deployer receives the supply. The constructor emits exactly one event, the mint.
• Launch split: a helper contract deploys the token and splits the supply in a single call, as the factory does in one transaction. For any pool share from 0 to 90%, the shares arrive exact and nothing is left with the deployer. Deploying again with the same salt reverts, so no second supply can appear.
• Zero address: sending from it, approving from it, sending to it (any amount) and transferFrom to it with an unlimited allowance all revert with the exact OpenZeppelin error, and leave state unchanged.
• Allowances:
  • Spending an allowance emits no Approval event.
  • An allowance of max − 1 still decreases.
  • Asking for one wei over the allowance or over the balance reverts without using up any allowance.
  • Approving one owner–spender pair changes no other pair.
  • Two spends that add up to the allowance succeed, and one more wei fails.
• Absent functions: permit, nonces, DOMAIN_SEPARATOR and the old increase/decreaseAllowance calls all fail.

test/SQUEEKSTR.openInvariant.t.sol (256 runs, depth 64, set inline): unlike the existing suite, its handler sends to any fuzzed address, including the token contract. It records every address it touches and tries five failing calls inside try/catch, checking each reverts with exactly the expected error. The invariants checked after every random sequence:

• Total supply stays fixed.
• The recorded holders together hold the whole supply.
• Every balance and allowance matches an independent model.
• No call behaved unexpectedly: no success without true, no wrong revert reason.
• No balance exceeds the supply, and the token holds no ETH.

The run made 16,384 calls with 0 reverts.

Nothing is committed yet. I left the two files uncommitted because I wasn't told to commit.

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

Outcome: the token's arithmetic is clean in my area. SQUEEKSTR is OpenZeppelin v5.1.0 ERC-20 with a single constructor mint, and the vendored ERC20.sol and Context.sol are byte-identical to upstream commit 69c8def5. I made all three passes myself, no helpers.

• Math Precision: the only arithmetic is the compile-time constant for the supply and the checked or guarded operations inside OpenZeppelin's _update and _spendAllowance. No division, rounding, casts, or scale conversion exist. The supply is exactly the manifest figure and is divisible by 10,000, so every basis-point share the factory computes is exact with no dust.
• Boundary: there are no external calls, no payable or fallback surface, no bytes decoding. The only sentinel branches are the zero-address rejections, each walked.
• Numerical Gap: I probed self-transfer at full balance, allowance at max minus one versus max, allowance above balance, zero-value paths from empty accounts, and random-transfer conservation with 1,024 fuzz runs. All behaved per ERC-20. The aderyn large-literal lead is benign.

One low finding, outside my area: the dependency integrity check the author instructs operators to run fails.

sha256sum --check lib/SHA256SUMS
WARNING: 19 computed checksums did NOT match

All 19 mismatches are forge-std test files that forge fmt re-wrapped under the project's line length after the checksum file was generated. Formatting pristine upstream v1.9.7 with this repository's config reproduces the vendored hashes exactly, so the library is genuine and nothing deployed is affected. The fix is to regenerate the checksum file or exclude lib/ from formatting.

Coverage: all three entry points, approve, transfer and transferFrom, are recorded as holds, along with rows for the constructor supply constant, launch split arithmetic, decimals(), and the external-boundary inventory. No row is unreached. My scratch test was removed, and the only file I left is the findings file.

The review is finished. I kept one low-severity finding and found no defects in the token. The results are in .imd-findings.json, which is the only file I wrote.

The code: src/SQUEEKSTR.sol is a plain OpenZeppelin v5 ERC-20. Its constructor takes no arguments and mints 1,000,000,000 tokens with 18 decimals (10^27 minor units) once, to the deployer. It has no owner, no mint or burn functions and no fees. The OpenZeppelin files it imports match the recorded checksums, so the library code is as published.

Specialist findings: All three findings report the same problem, so I merged them into one:

• [low] The documented dependency check fails (DEPENDENCIES.md:19, sha256sum --check lib/SHA256SUMS). I ran it here: 19 forge-std files fail and it prints WARNING: 19 computed checksums did NOT match. Every OpenZeppelin file passes. forge-std is only used by the tests and is never deployed, so no funds are at risk. The harm is that the integrity record is wrong, so anyone running the check sees failures and can't tell them apart from real tampering. Fix: regenerate lib/SHA256SUMS from the committed files, or restore forge-std's original files.

My own pass:

• Entry points: approve, transfer and transferFrom all hold. Each reverts on the zero address, a short balance or a short allowance, and moves exactly the amount asked, so the factory, distributor and pool transfers arrive in full.
• Manifest: launch.json matches the code: supply, 18 decimals, an empty argument list for the parameterless constructor, and no application contracts.
• Deployment: nothing blocks it. The deployed code is about 1.75 KB against the 24,576-byte limit, and it uses no DELEGATECALL or SELFDESTRUCT.
• Static analysis: aderyn's "large numeric literal" flag at line 12 is the intended 10^27 supply, so it isn't a defect.
• Build and tests: the build succeeds and the 54 existing tests pass.

No finding is critical or high, so none carries a proof test. I didn't run the protected floor tests (.imd/reads/protected/...), because their harness files aren't in this tree.