The Polyneum token is implemented, tested, documented, and committed on main.

What was delivered

• src/Polyneum.sol is a self-contained fixed-supply ERC-20. Name Polyneum, symbol POLYNEUM, 18 decimals, and the full 1,000,000,000 supply minted once to msg.sender in a no-argument constructor. It has no owner, mint, pause, blocklist, burn, fee, or upgrade path, so every launch flow moves exactly what it says and no privileged call can touch a holder.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", enables the optimizer, and leaves ffi and filesystem access off. forge-std v1.9.6 is vendored under lib/forge-std as plain files with no git metadata.
• test/Polyneum.t.sol holds 32 unit, failure, and fuzz tests covering metadata, the one-time mint, transfers, allowances, custom-error reverts, absence of admin selectors, and an opcode scan for delegatecall, callcode, and selfdestruct. test/Polyneum.invariant.t.sol adds stateful invariants for supply conservation.
• script/DeployPolyneum.s.sol exposes a tested deploy() function and reads nothing from the environment.
• README.md documents behaviour, deployment parameters, launch economics, assumptions, operational responsibilities, and the security checklist review.

Checks run

Check	Result
forge build	passes
forge test with empty environment	33 passed, 0 failed
forge fmt --check	clean
scratch mirror of the protected floor's non-Uniswap flows	3 passed

The protected test's Uniswap v4 seed and swap cases could not be run here because v4-core is not available offline, but the token has no transfer hooks or exemptions, so those flows see a plain ERC-20. Slither and Mythril were not available and did not run. Explorer verification remains an open item for the launch deployer.

I found no defects in src/Polyneum.sol. I wrote .imd-findings.json with an empty findings list and a coverage record. I didn't run any tests.

What the contract is: a plain fixed-supply ERC-20. It has no owner, no mint, no burn, no fee and no pause.

What I checked against the economic security, invariant and flow gap guides:

• Supply: exactly 1e27 minor units (1,000,000,000 tokens at 18 decimals) is minted once to msg.sender in the constructor. totalSupply is immutable, and nothing can increase or lower it later.
• Launch flows: the factory's transfer to the distributor, the claims, the pool seed and swaps both ways all move the exact amount. Nothing is skimmed, so no flow arrives short.
• Math: _transfer checks the balance before its unchecked subtraction. The unchecked addition can't overflow because all balances together never exceed totalSupply.
• Allowances: transferFrom checks the allowance before reducing it. An allowance of type(uint256).max is treated as unlimited, as documented.
• Edge cases: a transfer to yourself leaves balances unchanged, and a failed transfer reverts everything.
• Static analysis: aderyn's one note, a large number at line 26, is just the supply constant and not a defect.

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

One gap: the constructor takes no arguments, so it doesn't use the $factory, $poolManager or $launchNumber inputs. That's fine here because the token has no transfer rules that would need exemptions.

I found no access-control defects in Polyneum, so .imd-findings.json has an empty findings list. It also has a coverage row for each of the three entry points, all holds, plus two invariant rows. No source files were changed. The project's own test suite passes (33 of 33).

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

• Roles: the constructor takes no arguments and only mints the full supply to msg.sender, which is the factory at launch. After deployment there is no owner, minter, pause, blocklist, freeze, burn or upgrade path. totalSupply is fixed at deployment (immutable), so the supply can never grow.
• approve: it only writes the caller's own allowance. A zero-address spender reverts.
• transfer: it only debits the caller, after checking the balance. Sending to the zero address reverts, and sending to yourself leaves the balance unchanged.
• transferFrom: it checks the (from, msg.sender) allowance before moving anything. Without the holder's approval, no caller can move their tokens, including the factory or the deployer. An allowance of type(uint256).max is treated as unlimited, as documented.
• Launch flows: there is no fee, burn or exemption list on transfers. The four launch flows are factory to distributor, distributor to claimant, the pool seed, and swaps. Each moves exactly the amount stated, and nothing can switch the token off for one party and not another.

Two leads I set aside:

• Static analysis: aderyn's "large numeric literal" warning is about 1_000_000_000 * 10 ** 18, which is correct and harmless. Slither reported nothing.
• Zero-amount transferFrom(address(0), x, 0): it emits a Transfer event from the zero address with value 0. Nothing moves, so I left it out.

Not run: the launch's protected test file imports contracts this repo doesn't contain, so it can't run here. I only checked by reading that the token meets each of its requirements.

Created launch.json matching Polyneum’s constructor, exact supply, required pool settings, and verbatim economics.

forge build succeeded; forge test passed all 33 tests. Only launch.json is changed for submission.

The review is complete and .imd-findings.json is written with one info-level finding and nine coverage rows. The working tree is otherwise unchanged (git status reports nothing; .imd-findings.json is gitignored).

Outcome: no defect of low severity or higher in the Polyneum token. The three entry points plus the constructor, the deploy script, and the launch-flow and supply invariants all hold under the Execution Trace, Periphery and First Principles checklists.

What I verified

• Execution trace. Both value paths check receiver, then balance, then move exactly the requested amount with no fee or burn. The unchecked block is bounded by the fixed supply. Self-transfers and self-transferFrom leave balances intact. The unlimited-allowance sentinel is documented and behaves as stated. Allowance is decremented before the transfer and the whole call reverts atomically.
• Periphery. There are no libraries, helpers or external calls. The deploy script only wraps new Polyneum() in a broadcast and reads no environment. The tests pass (33 of 33, including the 256x500 invariant run).
• First principles. The supply constant evaluates to exactly the manifest's minor units. The constructor takes no arguments and credits everything to the creator, which is the factory under CREATE2. No fallback or receive exists, so unknown selectors and ether revert. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.

The one finding (info): transferFrom(address(0), X, 0) succeeds for any caller and emits Transfer(0x0, X, 0), which the ERC-20 spec reserves for mints. Balances and supply are untouched, so this only affects event consumers that key on the from-zero shape. OpenZeppelin v5 rejects this path; Solmate accepts it. I reproduced it with a Foundry test and documented a one-line optional guard that would not alter any launch flow.

Not reached: the protected harness itself cannot run here because Uniswap v4 core is not vendored. Since the token has no transfer rules or callbacks, I covered the launch flows by tracing the code rather than executing the harness. The aderyn large-literal lead is style only.

The findings file parses as valid JSON, the scratch directory is gone, and git status --porcelain shows only the gitignored build output and the findings file. The review is complete.

Result: no defects found in the Math Precision, Boundary and Numerical Gap area. The findings file at .imd-findings.json holds an empty findings list and seven coverage rows.

What I checked

• All three entry points, approve, transfer and transferFrom, trace as intended. Each unchecked subtraction sits behind a strict less-than guard, and the unchecked addition cannot wrap because the sum of balances is pinned at the one-time mint of 1e27.
• Self-transfer and self-transferFrom read storage after the write, so a holder's balance is unchanged and only the allowance moves.
• Zero amounts, whole-balance amounts, supply plus one, max-uint amounts, and max-minus-one allowances all behave correctly. The max allowance is never decremented, and the max-minus-one allowance decrements without wrapping.
• The contract has no division, no downcast, no payable path, no external call and no bytes decoding, so most of the Boundary and Numerical Gap checklist has no surface to hit. The only sentinel branches are the zero-address rejections, and both sides behave as documented.
• The aderyn large-literal lead on line 26 folds at compile time to exactly 1000000000000000000000000000. It is not a defect.

Evidence run

The existing suite of 32 unit and fuzz tests passed, the stateful invariant suite passed, and a scratch file of 11 extra edge-case tests passed before I deleted it. Slither reported nothing.

Noted, not reported

The plain set-to-value approve carries the standard EIP-20 front-running caveat, and transfers to the token's own address are allowed. Both are ordinary ERC-20 behaviour and match the requested plain-token design, so they appear as coverage notes rather than findings.

The findings file is deliberately excluded by the harness via .git/info/exclude, so it is read from disk as designed. The work is complete.

Outcome: forge build and forge test pass with no failures. The suite grew from 33 to 80 tests across 5 suites, and the full run takes about 55 seconds. No defect was found in the token.

What I added (three new files under test/, the existing two suites untouched):

• test/Polyneum.ghost.invariant.t.sol: a ghost-accounted invariant suite over random call sequences. The handler has unclamped entry points with arbitrary receivers, spenders and amounts that predict the exact outcome before every call, so every failure path (wrong success, wrong revert, wrong error data, state change on a failed call) is checked in-sequence with fail-on-revert enabled. Clamped and stress variants pin full-balance, one-wei, zero, and the unlimited-allowance sentinel. Hostile probes try 22 admin selectors, unknown selectors, and ether from random actors. Invariants cover fixed supply, sum of all touched balances including strangers, per-address flow accounting, allowance accounting, and no allowance outside recorded pairs.
• test/Polyneum.edges.t.sol: 35 boundary and algebraic tests. Zero to the zero address, max uint, max-minus-one allowance, the owner spending through transferFrom with no implicit allowance, error precedence, truncated calldata, value-bearing calls, and a raw-ABI fuzz where arbitrary calldata from a stranger never moves a holder. Properties include round-trip, additivity, commutativity, transfer and transferFrom equivalence, and exact revert data above balance and above allowance.
• test/Polyneum.launch.t.sol: a launch-floor emulation mirroring the protected harness without the Uniswap dependency. A factory probe deploys through CREATE2, the address is predicted from creation code alone, the swarm share and remainder arrive and are claimable whole, many fuzzed claims sum exactly, and no admin call from a stranger or the factory grows the supply or moves a holder.

Validation of the suite itself: I ran the ghost suite in scratch against three mutants (one-wei fee on transfer, allowance not decremented, public mint). Each was caught within the first run by the handler's per-call check and the corresponding invariant, so the properties are not vacuous. The scratch files were removed afterwards.

Findings file: .imd-findings.json holds two info entries only. One records that no defect was found and how the suite was validated. The other notes the standard EIP-20 approve race with no increase or decrease allowance helpers, which is specification behaviour rather than an implementation error, so it carries no proof.

The three new files are untracked in the working tree and not committed, since no commit was requested.

The review is complete and the findings file is written. Snippets match the source lines exactly, the JSON parses, and the working tree is clean apart from the gitignored findings file and scratch tests.

Outcome: Polyneum has no defect that needs a revision. All 85 repository tests pass, including the launch-floor emulation, and my six scratch checks pass.

Specialist findings, settled:

• Kept as info (audit_flow): transferFrom(address(0), to, 0) from any caller succeeds and emits a mint-shaped Transfer(0x0, to, 0). Reproduced with an exact event expectation. Nothing moves and any non-zero amount reverts, so impact is limited to event consumers.
• Kept as info (write_foundry_tests): the standard EIP-20 approve overwrite race, with no increase/decrease helpers. Traced step by step. It is specified behaviour, recorded as a usage note rather than a defect.
• Dropped: the "no defect found" report is a coverage statement, not a finding. The aderyn large-literal lead is the readable 1_000_000_000 * 10 ** 18 constant and not a defect.

My own pass: the constructor mints exactly the manifest supply to msg.sender with no arguments, self-transfers preserve balances, the unlimited-allowance sentinel is handled correctly, the owner needs an allowance to spend via transferFrom, there are no privileged functions or forbidden opcodes, and launch.json matches the code. Coverage answers all three listed entry points plus three invariant rows.