The SQUEEKSTR token project is complete, committed, and verified from a clean export of the commit with an empty environment.

What was delivered

• src/SqueekstrToken.sol: contract SqueekstrToken, an OpenZeppelin v5.1.0 ERC-20 with ERC-2612 permit. Name SQUEEKSTR, symbol SQKSTR, 18 decimals. The constructor takes no arguments and mints the whole 1,000,000,000 supply once to msg.sender, which is the launch factory. No owner, minter, pause, blocklist, fee or upgrade path exists, so the supply can never grow and no privileged call can move or freeze a balance. Holders may burn their own tokens only.
• test/SqueekstrToken.t.sol: 23 tests covering metadata, the single constructor mint, exact transfers, allowance success and failure, permit success, expiry, wrong signer and replay, burn limits, every common admin and mint selector rejected from both the deployer and a stranger, the launch flows arriving whole, a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and three fuzz tests for conservation of supply.
• script/DeploySqueekstrToken.s.sol: a reference deploy script whose deploy() is called directly by a test, with no environment reads.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables ffi and filesystem access. remappings.txt points at the vendored libraries.
• lib/: forge-std 1.9.7 and OpenZeppelin Contracts 5.1.0 committed as plain files, with no submodules.
• README.md documents behaviour, assumptions, manifest values for the launch step, deployment parameters, the empty "After launch" section, and operational responsibilities.

Verification results

• forge build, forge test with the verifier's fuzz seed, and forge fmt --check all pass, both in the workspace and from a clean git archive export with an empty environment.
• The token matches the protected floor's requirements: whole supply to the factory, decimals 18, no supply growth, no privileged balance moves, no forbidden opcodes in reachable runtime, and tax-free transfers so the seed and swaps move exact amounts.

Not done

• Slither was not run; it is not in this machine's toolchain. The contract avoids all six rejected detectors by construction, as noted in the README.
• No launch.json was written, per the launch rules. The README lists the values the manifest step needs.

I found no defects in the math area. .imd-findings.json has an empty findings list and a coverage row for all 5 entry points, each marked holds. I made no other changes, and all 23 existing tests pass.

What I checked: src/SqueekstrToken.sol is a plain OpenZeppelin 5.1.0 ERC20 + ERC20Permit with one addition, burn, which burns only the caller's own tokens. I read the vendored OpenZeppelin _update, _spendAllowance and permit code against the Math Precision, Boundary and Numerical Gap failure modes:

• Supply: 1_000_000_000 * 10**18 is computed as a uint256 and equals 1e27 exactly. It is minted once, only in the constructor, to msg.sender. Aderyn's "large numeric literal" warning is about style only.
• Unchecked arithmetic: every unchecked block comes after its bound check. A transfer or burn of balance + 1 reverts with ERC20InsufficientBalance. Spending above the allowance reverts with ERC20InsufficientAllowance. Credits can't overflow because no balance can exceed the total supply.
• Exact amounts: there are no fees, taxes or division, so there's nothing to round. Transfers move exactly the amount asked, which also means the launch flows arrive in full.
• Edge values:
  • A transfer or burn of 0 succeeds and changes nothing.
  • An allowance of type(uint256).max is never reduced, which is the standard behaviour.
  • permit accepts a deadline equal to the current block time and rejects anything earlier.
  • Each nonce works only once, and the signature check rejects malleable and zero-address signatures.
• Supply only shrinks: the only way to change the total supply after deployment is a holder burning their own balance.

Two other things:

• I didn't write a scratch reproduction test, because there was nothing to reproduce.
• After my run, git status lists files I didn't create in the repository root: .bashrc, .profile, .zshrc, .gitconfig, .mcp.json, .claude/, .idea, .vscode, .gitmodules and others. They come from the environment, not from this review. Strip them before anything is compared, because the submission is rejected if any file changes. .imd-findings.json itself doesn't show up in git status, so it is probably git-ignored.

I found no economic defects in SqueekstrToken, so .imd-findings.json has an empty findings list and a coverage row for each of the five entry points. All five are marked holds, and I added three rows for invariants I checked. No project files were changed; I wrote some scratch tests and deleted them afterwards.

Covered (Economic Security, Invariant and Flow Gap guides):

• What the code is: src/SqueekstrToken.sol is a plain OpenZeppelin 5.1.0 ERC20 with permit. It adds nothing to transfers: no fee, no burn on transfer, no special cases. The only mint is in the constructor: TOTAL_SUPPLY = 1_000_000_000 * 10**18 (1e27), sent to msg.sender. The only extra function is burn(uint256), which can only burn the caller's own balance.
• Supply and balances: there is no way to mint after deployment, so the supply can only shrink, and only when a holder burns their own tokens. Fuzz tests showed that the balances always add up to the total supply after transfers and burns.
• Launch flows: every launch transfer (factory to distributor, pool seed, distributor to claimant, swaps, remainder) delivers exactly the amount sent, because no transfer logic is overridden.
• Allowances and permit: transferFrom reverts when the amount exceeds the allowance and reduces the allowance by exactly the amount; an unlimited allowance is never reduced. A permit signature cannot be reused, either on the same chain or on a different chain ID.
• Vendored OpenZeppelin: the 19 library files the token depends on are byte-for-byte the same as the official v5.1.0 release, so the library hasn't been tampered with.
• Static analysis lead: aderyn flagged the large number at line 24. It is correct (1e27) and harmless.
• Tests: all 23 existing project tests pass, and my 4 scratch tests passed before I deleted them.

Not covered: I couldn't run the protected launch test here. It depends on harness files (src/LaunchLiquidity.sol, PoolInitializationGuard, HookFlags, the floor's OwnerChecks) that aren't in this repository. Since the token adds no transfer logic, I expect it to pass, but I haven't run it. There is no launch.json yet, so I didn't review one.

I found no defects in SQUEEKSTR's control flow, so .imd-findings.json has an empty findings list. Its coverage record has one holds row for each of the five entry points, plus a row for the supply invariant.

What the contract is: src/SqueekstrToken.sol is plain OpenZeppelin ERC20 + ERC20Permit 5.1.0 with nothing overridden. Its constructor mints 1e27 (1,000,000,000 × 10^18) to msg.sender, and its only other function is burn(amount), which can burn only the caller's own balance. I compared the vendored lib/openzeppelin-contracts/contracts against a fresh clone of upstream v5.1.0, and they are byte-identical. So the library code it inherits behaves exactly as upstream.

What I checked, by guide:

• Execution Trace: Every transfer moves exactly the amount asked for, with no fee or burn. So the launch flows (factory to distributor, distributor to claimant, the pool seed, buys and sells) arrive whole. Zero-address cases revert. A max allowance stays unlimited, and a partial allowance goes down by exactly what is spent. A permit cannot be replayed, and one signed for another chain ID is rejected.
• Periphery: The ECDSA, Nonces and EIP712 code behind permit rejects high-s malleated signatures, expired deadlines and an owner of address(0). It rebuilds the signing domain when the chain ID changes.
• First Principles: Supply only changes through the constructor mint and the holder's own burn. Self-transfers and transfers of zero conserve balances. There is no owner or other privileged role, and no path to DELEGATECALL, CALLCODE or SELFDESTRUCT. decimals() is 18.

Tests: I wrote a scratch Foundry suite (fuzzed burns and self-transfers, permit replay, chain-ID change, malleated signatures, allowance edges) and it passed 6/6. The project's own 23 tests also pass. I deleted the scratch tests afterwards, and .imd-findings.json is the only file I wrote.

Static analysis: Slither reported nothing. Aderyn's one lead is a "large numeric literal" at line 24, which is just the supply constant 1_000_000_000 * 10 ** 18. It is correct, so I didn't report it.

Not covered: I did not run the protected floor tests. They need the launch harness's environment variables and source files (LaunchLiquidity, PoolInitializationGuard) that are not in this tree. No launch.json exists yet to review. If one is written, the token's constructorArgs should be [] and totalSupply should be "1000000000000000000000000000".

The permissions audit of SQUEEKSTR is complete and the area is clean. The findings file is written and validated against the tree.

What I checked

• Access Control. The token is OpenZeppelin 5.1.0 ERC20 plus ERC20Permit and a self-only burn. There is no owner, role, initializer, proxy, receive or fallback. The constructor mints the whole supply once to the deployer. Mint, pause, blacklist, upgrade and burnFrom selectors all revert whether called by the factory or a stranger.
• Trust Gap. Every vendored OpenZeppelin file the token reaches was diffed byte for byte against the upstream v5.1.0 tag. All are identical, so there is no hidden library backdoor such as a patched _msgSender or _update.
• Asymmetry. approve and permit write the same allowance slot in the same overwrite direction and both emit Approval. transferFrom with no allowance reverts for the deployer like anyone else. Mint exists only in the constructor and burn only for the caller.
• Inversion probes in a scratch Foundry test confirmed: stranger burn touches nothing, replayed and malleable permit signatures are rejected, zero-address owner is rejected, and the token refuses plain and value calls. The scratch directory was removed afterwards.

Result in .imd-findings.json

• One informational note, not a defect: a permit signature can be submitted by any third party, which is standard ERC-2612 behaviour and only matters for integrators that call permit and transferFrom together without tolerating a pre-submitted permit. It carries a concrete reproduction.
• Nine coverage rows: all five entry points answered, four holds and permit marked finding pointing at the informational note, plus four invariant rows that hold.

The aderyn large-literal lead is a style remark on a constant written as 1_000_000_000 * 10 ** 18 and is not a defect. Slither reported nothing. Nothing outside my area was found severe enough to report, and no entry point was left unreached.

I added two test files to the SQUEEKSTR test suite. The full suite (61 tests, three suites) passes with forge build and forge test, run with the verifier's fuzz seed. I found no defect, so I didn't write a findings file.

The token is a standard OpenZeppelin 5.1 ERC-20 with signature approvals (permit) and a burn that only works on the caller's own balance. It mints 1,000,000,000 × 10¹⁸ to the deployer once in the constructor. It has no owner, no way to mint more, no pause and no transfer fee. The 23 tests that were already there are unchanged.

test/SqueekstrToken.edges.t.sol has 37 tests, mostly failure paths:

• Deployment: deploying from inside a contract (the way the launch factory does) mints the whole supply to that contract, and deploying again at the same address reverts, so the supply can't be minted twice.
• Signature setup: the signing domain has the right name, version, chain and token address.
• Transfers: sending the exact balance works and one wei more reverts. Also covered: sending the maximum possible amount, sending to yourself, and sending zero to the zero address, which still reverts. Tokens sent to the token contract itself are accepted and then stuck there; that's standard ERC-20 behaviour, not a defect.
• Allowances:
  • Approving the zero address reverts, and a new approval replaces the old one rather than adding to it.
  • A spender can't move tokens to the zero address, and a failed attempt doesn't use up any allowance.
  • Having enough allowance doesn't help when the owner's balance is too low.
  • An unlimited allowance is never reduced, while maximum-minus-one is; spending the exact allowance leaves zero.
  • An owner moving their own tokens through the spender route still needs an allowance, and allowances are separate per spender.
• Burn: burning zero, burning the whole supply, burning the maximum amount (reverts), and confirming a burn can't touch another holder's balance or allowance.
• permit: works at exactly the deadline and fails one second after it. It rejects a signature reused for a different spender or amount, a skipped nonce, the alternate form of a valid signature, a malformed signature, an all-zero signature, and a zero-address spender (which doesn't use up the nonce). It also rejects a signature taken from another chain or another copy of the token. Repeated permits use nonces in order and replace the allowance.
• Fuzz tests: random amounts through approve-and-spend, transfers between random addresses, and random signers through permit (each signature works once and is then refused).

test/invariant/SqueekstrToken.invariant.t.sol is the random-sequence test. A helper contract makes random calls from five accounts: transfers, approvals, spender transfers, burns, permits and time jumps. It also deliberately tries things that must fail: overspending a balance, overspending an allowance, burning too much, and permits signed by the wrong person. It keeps its own record of what every balance, allowance and nonce should be. After every call it checks:

• total supply equals 1,000,000,000 minus what was burned, and never goes above that;
• each account's balance matches the record, and the five accounts together hold the whole supply;
• every allowance and nonce matches the record;
• nothing that should have failed succeeded, and no call returned false;
• the name, symbol, decimals and supply constant never change.

It runs 64 sequences of 32,000 calls in total, and every call type was exercised.

I left the new files uncommitted.

The review is complete and written to .imd-findings.json. No source files were changed. Only ignored paths exist in the working tree.

Outcome: no defects. The token is OpenZeppelin ERC20 plus ERC20Permit with a self-only burn, and nothing custom beyond constants and the constructor mint.

Specialist findings judged

• Four specialists and the independent tester reported nothing. The permissions specialist reported one info item on permit.
• I kept that item as info, merged under my own reproduction. Anyone holding a holder's permit signature can submit it first. The allowance is set exactly as signed, the nonce advances, and the intended spender's own permit call then reverts. Transfer still works. This is standard ERC-2612 behaviour, not a token defect, and is recorded as a trust assumption for integrators. A scratch test under test/scratch reproduces the sequence and passes on this tree.

What I verified myself

• Every vendored OpenZeppelin file the token depends on hash-matches the upstream v5.1.0 tag, so the inherited behaviour is the documented one.
• The constructor mints exactly the manifest supply to the deployer, decimals are 18, and the manifest's empty constructor arguments match the argument-free constructor. The aderyn large-literal lead is style only. The value is correct.
• No owner, mint, pause, blocklist or burnFrom exists. The project test suite, 61 tests, passes, including the opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• Runtime and creation bytecode are well under the size limits.
• The protected floor tests cannot run here because they import service-side files not in this tree. I checked each of their assertions against the code by hand and all hold.

Coverage record. All five entry points are answered. Four hold. Permit points to the single info finding. Three invariant rows cover supply, privilege and opcode checks, and the dependency match.