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

What was built

• src/Polyneum.sol: contract Polyneum, a plain OpenZeppelin v5.1.0 ERC-20. Name Polyneum, symbol POLYNEUM, 18 decimals. The constructor takes no arguments and mints the full supply of 1,000,000,000 × 10^18 once to msg.sender. No owner, no mint, no burn, no pause, no blacklist, no transfer fee, no upgradeability, no external calls.
• test/Polyneum.t.sol: 27 tests covering metadata, the single constructor mint and its events, transfer and transferFrom success and failure paths, a fuzzed supply-conservation check, the launch flows arriving whole, the absence of any mint or admin selector from both a stranger and the deployer, rejection of plain ether, and an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• script/DeployPolyneum.s.sol: a reviewable deploy script whose deploy() function the tests call directly. Its run() reads no environment.
• foundry.toml at the repo root pins solc 0.8.26, sets bytecode_hash = "none", and keeps ffi off with no filesystem permissions.
• lib/: forge-std v1.9.6 and the OpenZeppelin ERC20 subset vendored as plain files. No submodules, no .git directories.
• README.md: design, assumptions, deployment parameters, operational responsibilities, and open items for the launch.

Verification

forge build        Compiler run successful
forge test         27 passed, 0 failed (also passes under an empty environment)
forge fmt --check  clean

Slither and Mythril were not available here and did not run. No launch.json was written. Nothing was signed or broadcast.

I wrote launch.json for the Polyneum launch and verified it against the accepted tree.

What the manifest says

• Kind is custom_token. The token contract is Polyneum, name Polyneum, symbol POLYNEUM, 18 decimals.
• constructorArgs is empty, matching the accepted constructor, which takes no parameters and mints the whole supply to msg.sender once.
• totalSupply is 1000000000000000000000000000, the exact constant the constructor mints.
• contracts is empty. The tree holds only the token, a local forge script the launch does not use, and tests.
• 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 and absence of privileged behavior, at 1,145 characters.

Checks run

• JSON parses with only the schema's six top-level keys, economics matches the job's object, and totalSupply equals 10^9 times 10^18.
• forge build succeeded and forge test passed all 27 tests.
• Git status shows launch.json as the only new file. No other file changed.

The review is complete. No defects were found in the Access Control, Trust Gap or Asymmetry areas, and the findings file records an empty list with a full coverage record.

What the token is. Polyneum is an unmodified OpenZeppelin v5.1.0 ERC20 whose constructor mints the whole supply once to the deployer. It has no owner, no roles, no pause, no blacklist, no mint or burn, no fee branch, no receive or fallback, and no external calls.

What I verified.

• The five vendored OpenZeppelin files are byte-identical to upstream v5.1.0, so no hidden override of the transfer or sender logic exists.
• The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. A fuzz over 2000 random selectors from random callers confirmed every other selector reverts.
• A stateful invariant fuzz of about 128,000 transfer and approve-then-pull calls kept the sum of balances equal to a total supply of one billion tokens.
• The deployer, which is the factory at launch, cannot pull a holder's balance without an allowance, and holds no power beyond its own balance.
• The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, matching the project's own opcode scan and the protected floor test.
• The aderyn large-literal lead on the supply constant was checked and the value is correct.

Coverage. All three listed entry points are marked holds, plus four invariant rows covering privilege absence, supply, library provenance and the deployer trust assumption. The standard ERC-20 approve race is documented by the author and is not reported as a defect.

State of the tree. Only .imd-findings.json and the scratch test under test/scratch/ were written. No tracked files changed.

The review is complete and the findings file is written and validated.

Outcome: no exploitable math, boundary or numerical-gap defect found. The findings file holds one informational note and a full coverage record.

What I checked, against the Math Precision, Boundary and Numerical Gap guides:

• Math. The only arithmetic is the compile-time supply constant and OpenZeppelin v5.1.0's balance and allowance updates. The supply is exactly 1e27, which fits uint256, uint128 and int128 with wide margin, so Uniswap v4 balance deltas cannot saturate. The unchecked subtractions are guarded by a prior compare, and the unchecked additions are bounded by total supply. There is no division, scaling, fee or accumulator anywhere.
• Boundaries. The token makes no external calls, has no payable, receive or fallback function, decodes no bytes, and its only sentinel branches are the zero-address reverts in the library. The compiled ABI exposes exactly the three state-changing entry points the verifier listed.
• Seams. Every transfer moves exactly the requested amount, so no precision-versus-invariant or boundary-versus-precision seam exists. The 10/88/2 launch split of the supply divides with zero dust.

Scratch tests I ran under test/scratch, all passing: whole-balance self-transfer, self transferFrom, zero-amount transferFrom without allowance, max and max-minus-one allowance handling, overwrite approve semantics, transfers of supply+1 and uint256 max reverting, and a fuzzed sum-of-balances equals total-supply invariant. The project's own suite also passes at 27 tests.

The one note reported, at info severity, is that the public DECIMALS constant scales the minted supply but does not drive decimals(), which still returns the library default. Both are 18 today so the deployed code is consistent with the manifest. It is reported only because a future edit to that constant would silently desynchronise reported decimals from the supply scale. The aderyn large-literal lead is the intended supply value and is not a defect.

Coverage rows: all three entry points hold, plus rows for the constructor and supply constant, the supply-conservation invariant, the external boundary inventory and the numerical seams. Nothing in the assigned area was left unreached. The protected launch test could not be executed locally because it depends on v4-core, which is not vendored here.

The review is complete. The findings file is written and validated, the cited snippet matches the tree exactly, and the working tree shows no tracked changes.

Outcome: no defects in the token code. The Polyneum contract is a 41-line wrapper around OpenZeppelin ERC20 v5.1.0 with a single constructor mint. I found nothing in the Economic Security, Invariant, or Flow Gap areas that fails on a concrete input. The only entry in the findings file is an info-level documentation note.

What I checked, against each of the three assigned guides:

• Economic Security. No external dependencies, oracles, or callbacks exist. Transfer behavior is exact with no fee, rebase, pause, or blacklist. Sentinel probes (transfer to zero, transferFrom from zero, approve to zero) all revert as the standard requires. The ERC-20 surface in the compiled ABI is complete and has no hidden selectors.
• Invariant. A scratch invariant fuzz over random transfer, approve, and transferFrom sequences confirmed sum of balances equals total supply and total supply stays at 1e27 throughout. No burn path is reachable from any ABI entry point since transfers to the zero address revert.
• Flow Gap. I traced the protected floor test's flows: CREATE2 deployment from the factory mints the whole supply to the factory, the swarm share and claims arrive whole, and plain ERC-20 transfer semantics satisfy the Uniswap v4 PoolManager sync and settle paths for seeding and both swap directions.

I also diffed every vendored OpenZeppelin file against the upstream v5.1.0 tag and all five are byte-identical, so no transfer or allowance logic was altered locally.

The one info finding concerns README line 37 and the test file. They present the reference example's 88% pool share, 2% remainder, and the example's remainderTo address as if they were this launch's economics. The job text for Polyneum states only name, symbol, and supply. The token code is indifferent to the split, and admission would refuse a manifest with copied example values, so there is no on-chain effect. The fix is to drop the specific numbers or mark them as illustrative.

Coverage. All three listed entry points are marked holds, with additional rows for the constructor, the two conservation invariants, the privileged-hand invariant, the vendored dependency check, and the protected-floor flow trace. Nothing was left unreached.

One trust assumption worth noting for the judge: the standard ERC-20 approve front-running race applies and is documented in the README. It is accepted ERC-20 behavior, not a defect.

The findings file is excluded from git by the harness's own .git/info/exclude, which is how it is picked up. Everything is in place.

Outcome. Two new test files were added under test/, the whole suite passes, and no defect was found in the token. The existing unit suite was kept as is.

Suite	Tests	Result
test/Polyneum.t.sol (existing)	27	pass
test/Polyneum.fuzz.t.sol (new, 1000 runs each)	34	pass
test/Polyneum.invariant.t.sol (new, 256 runs × depth 64)	8 invariants	pass, 0 handler reverts

Invariant suite. A handler drives five actors through transfer, approve and transferFrom in random order. It has clamped entry points that always succeed and unclamped ones with unrestricted receivers, owners and amounts, plus stress variants: whole balance, one wei, self-transfer, balance plus one, allowance plus one, infinite approval, donation to the token's own address, and attempts at mint, burn, pause, blacklist and upgrade selectors. Every revert is caught and must be the exact ERC-6093 error for the inputs, and must leave every balance and allowance unchanged, so the failure paths are exercised inside the random sequences with fail-on-revert enabled. The invariants check that total supply is fixed, that balances across every address ever touched sum to the supply, that a ghost balance and ghost allowance model agree with the contract, that nobody holds more than flowed into them, that the zero address holds nothing, that metadata is constant, and that the campaign actually produced both successes and reverts.

Fuzz suite. Stateless properties with the edge cases pinned beside them: any deployer receives the full supply, two deployments are independent, round-trip transfers restore balances, self-transfer is a no-op, split transfers sum exactly, approve overwrites rather than accumulates, finite allowances decrement exactly while the infinite one never does, failed transfers and spends leave allowances and balances intact, allowance is checked before balance, zero-amount transferFrom needs no allowance, zero-address sender, receiver, spender and approver are all rejected, unknown selectors and ether with any calldata are rejected, and transferFrom emits only a Transfer event.

One harness correction during the work. My first expectation for a transferFrom from the zero address with amount zero was wrong. OpenZeppelin spends the allowance before checking the sender, and writing the spent allowance back rejects a zero owner, so the error is ERC20InvalidApprover, not ERC20InvalidSender. I confirmed this in the vendored library source and the tests now pin that exact behaviour.

Findings. No defect against the brief. One info-level note is recorded in the findings file: tokens sent to the token's own address are stuck forever, which the README already documents as deliberate for a token with no admin powers. It carries no proof because it is not a defect.

Review complete. The findings file is written and validated.

Outcome: no defect found that reopens the author's work. Polyneum is an unmodified OpenZeppelin v5.1.0 ERC20 with a no-argument constructor that mints the manifest's exact supply to the deployer. All three state-changing entry points hold, and the launch deployment model holds end to end.

Specialist findings settled

• DECIMALS not wired to decimals() was reported twice, by audit_math and audit_flow. Merged into one info finding. Reproduced: both values are 18 today and only an edit to the constant would expose the divergence. Not a defect in the shipped code.
• Tokens sent to the token contract are stuck, from the independent tester. Reproduced and kept as info. It follows from the brief's "no privileged hand" design and is already pinned by the project's own fuzz and invariant tests.
• README states 88%/2% as this launch's split, from audit_economics. Dropped. The reference states the example manifest's pool and economics are this launch's own, and launch.json carries those same values, so the README is correct.

Independent checks that passed

• Full suite: 62 tests pass, including the 256-run invariant campaign. Formatting check passes.
• Vendored OpenZeppelin files compared byte for byte with upstream v5.1.0. No differences.
• Creation code and runtime are far under the factory's size limits. Constructor takes no arguments and makes no external calls, so CREATE2 from the factory deploys it. A scratch test under test/scratch confirmed CREATE2 from a contract mints the whole supply to that contract, and that launch flows move exactly what they say.
• launch.json uses only schema keys, lowercase addresses, and a valid contract name. The paired currency on chain 1 has code and reports symbol IMD with 18 decimals, checked via the task's chain-1 endpoint.
• Static analysis leads: slither reported nothing; aderyn's large-literal note is the supply constant and is cosmetic.

Coverage record: seven rows, all holds, covering the three entry points plus the supply, deployability, privilege, and manifest invariants.