Done. The Pons token is implemented, tested, documented and committed on main as commit f17f5ed.

What was built

• src/PonsToken.sol: a self-contained, immutable ERC-20. The constructor takes no arguments and mints the whole supply once to the deployer. name() is "Pons", symbol() is "PONS", 18 decimals, total supply 1e27 minor units as a constant. There is no owner, mint, burn, pause, blocklist, fee or proxy, and the runtime has no delegatecall, callcode or selfdestruct. The contract identifier PonsToken fits the 32-character manifest limit.
• foundry.toml at the repo root pins solc 0.8.26, sets bytecode_hash = "none" and cbor_metadata = false, keeps ffi off and grants no filesystem permissions. I confirmed the built runtime carries no metadata trailer.
• lib/forge-std is vendored as ordinary files with its licences. No submodule, no .git inside it. The token itself imports nothing.
• script/DeployPonsToken.s.sol exposes a deploy() function the tests call directly. run() reads no environment variables.
• test/PonsToken.t.sol holds 36 tests: metadata and supply, the mint to a contract deployer, exact transfers and allowance accounting, every revert path with the exact custom error, the absence of mint, admin, pause, freeze and seize selectors from both a stranger and the deployer, the launch-shaped 10/88/2 split arriving whole, a bytecode opcode scan, and four fuzz tests on supply conservation and allowance limits.
• README.md documents behaviour, assumptions, the manifest values for the launch, operational responsibilities and the note that nothing needs configuring after launch.

Verification

A clean rebuild, forge test and forge fmt --check all pass with an empty environment. The pinned protected test only needs a plain ERC-20 whose supply lands on the factory and whose transfers move exact amounts, which this token satisfies. Slither and Mythril were not available here and were not run; the README says so.

I found no defects in the Pons (PONS) token. .imd-findings.json holds an empty findings list and a coverage record for all three entry points, plus two invariant rows.

src/PonsToken.sol is a plain ERC-20 with nothing extra: no constructor arguments, no owner, no mint after deployment, no pause, no blocklist, no fee, no burn, and no DELEGATECALL, CALLCODE or SELFDESTRUCT. The project's own tests pass (36 of 36). I did not write or run a separate test, since there was nothing to reproduce.

Supply and launch: The constructor mints exactly 1,000,000,000 × 10^18 to whoever deploys it, which at launch is the factory. Decimals are 18. Nothing else can create or destroy tokens, so the supply can never change. Because transfers take no fee, the launch transfers move the exact amounts:

• the factory's transfer of the swarm's share to the distributor;
• claims paid out of the distributor;
• seeding the pool and swaps through the PoolManager.

Coverage:

• approve — holds. It sets the caller's allowance and rejects a zero spender. The known ERC-20 risk of a spender front-running an allowance change applies to every ERC-20, so I did not count it as a defect.
• transfer — holds. The balance check runs before the unchecked subtraction. A transfer to yourself leaves your balance unchanged. The addition can't overflow because all balances together always equal the fixed supply.
• transferFrom — holds. The allowance is checked and spent first, and the maximum allowance is treated as unlimited and never reduced. If the transfer then fails, the whole call reverts.

The static-analysis lead (aderyn, "large numeric literal" at src/PonsToken.sol:39) is the supply constant. It is a style warning, not a defect.

There is no launch.json in the tree yet, so I could not review the manifest. No repository files were changed. .imd-findings.json doesn't appear in git status, most likely because .gitignore excludes it.

Wrote launch.json for the Pons launch. Build and the full test suite pass, and the manifest is the only new or changed file.

What the manifest says

• Token: contract PonsToken, name Pons, symbol PONS, 18 decimals, empty constructorArgs, totalSupply 1000000000000000000000000000. This matches the accepted source, whose constructor takes no arguments and mints the constant supply once to msg.sender.
• Contracts: an empty list. The accepted tree has no application contracts.
• Pool and economics: copied exactly from the launch reference. Native ETH pair at the zero address, fee 12500, tick spacing 60, the one-to-one sqrtPriceX96, and the requester's economics object verbatim.
• Notes: a plain description of the token's behaviour and why it needs no exemption arguments.

Verification

Check	Result
Manifest keys, supply, economics, notes length	ok (script in shell)
forge build	successful
forge test	36 passed, 0 failed
git status	only launch.json added

The protected test will deploy the token with the empty constructorArgs and check that the minted supply equals the manifest's figure and that decimals are 18. Both hold against the accepted PonsToken source.

The review is complete and .imd-findings.json is written in the repository root with no findings and a full coverage record. The only files I touched were the findings file and a scratch test under test/scratch, which I removed.

Result: no defects found in the math, boundary or numerical-gap area. The Pons token is a self-contained fixed-supply ERC-20 with no division, no rate multiplication, no scale conversion, no downcast, no external call, no payable path and no bytes decoding. That leaves nothing for the three guides' failure modes to attach to, so I verified the remaining arithmetic directly.

What I checked against the code, each confirmed with a scratch Foundry test that passed on the current tree:

• Supply constant. The aderyn large-literal lead resolves to exactly 1e27, matching the brief's one billion with 18 decimals, and it fits in 96 bits, so downstream pool math has headroom.
• Transfer arithmetic. The balance guard runs before the unchecked block. Self-transfer of the whole balance, zero amounts, value equal to the balance, and a max-uint value all behave per ERC-20. Sum of balances stayed exactly 1e27 across 1000 fuzz runs.
• Allowance arithmetic. The allowance guard precedes the unchecked decrement, so the Approval event value cannot underflow. Exact consumption lands on zero, max-minus-one is decremented, and max is left as infinite while the balance check still applies.
• Sentinel branches. Both zero-address checks revert before any state write. A transferFrom with the zero address as sender reverts with no state change.

Coverage rows for all three listed entry points are marked holds, plus rows for the supply invariant, the constant, and the two guide categories that have no applicable surface. One observation outside my area, not reported as a finding because it is spec-permitted: transferFrom emits an Approval event on each decrement, which OpenZeppelin v5 no longer does. It is harmless to accounting and intentional per the README.

Review complete. The findings file is written at the repository root, no source files were changed, and the scratch tests I used were removed.

Result: no defects in the assigned area. The token is a plain fixed-supply ERC-20 with no roles, no initializer, no proxy, no external calls, and no fee or exemption logic. Every entry point is guarded only by the caller's own balance or allowance, which is exactly the intended permission model.

What I checked

• Access control: the ABI exposes only ERC-20 views and the three mutators. Storage is two mappings. The constructor hands out no role. The runtime has no delegatecall, callcode, selfdestruct, receive or fallback.
• Asymmetry: transfer and transferFrom share one _transfer path. Allowance handling is symmetric with OpenZeppelin v5 except for one event detail noted below. Self-transfers and zero-value transfers leave balances unchanged.
• Trust gap: the deployer holds the whole supply by design and gains no power beyond an ordinary balance, so no access-by-economics seam exists.
• Supply conservation: a 128,000-call invariant fuzz over transfer, approve and transferFrom held with zero reverts.
• The aderyn large-literal lead is a compile-time constant equal to the manifest supply. Not a defect.

One informational note recorded: _spendAllowance emits an Approval event on every finite-allowance spend, including a zero-value transferFrom against a zero allowance. Anyone can make the token emit an approval event the holder never authorised. Balances and allowances are unaffected. It is reported at info severity with a concrete reproduction for the author's awareness only.

Coverage: all three listed entry points have rows (two hold, one carries the info finding), plus rows for the no-privilege, supply-conservation, exact-launch-flow and deployer-trust invariants.

Both paths are excluded by the harness's own .git/info/exclude, which is expected for a review: the tree stays clean and the findings file is read from disk. The work is complete.

Result: no defects found in the assigned area

I audited src/PonsToken.sol against the Economic Security, Invariant and Flow Gap guides, with the Senior Auditor's Mindset, x-ray deployment-phase and token-behaviour checks, and the Trail of Bits entry-point inventory as background. The findings file at .imd-findings.json holds an empty findings list and 11 coverage rows: 10 holds, 1 unreached.

What was verified, and how

• Conservation. The only balance writer besides the constructor is the delta-paired _transfer, and totalSupply() is a pure constant. A StdInvariant fuzz with seven actors over 128,000 transfer/approve/transferFrom calls, with both success and revert branches confirmed exercised, never broke sum(balances) == 1e27 or moved anything to the zero address.
• Supply cannot grow and no privileged hand exists. The compiled ABI exposes exactly three mutators. The runtime contains no CALL-family, CREATE, SELFDESTRUCT or transient-storage opcode, so there is no dependency, callback or reentrancy surface. The unchecked arithmetic is bounded by the guards on lines 104 and 126 and by the 1e27 supply ceiling.
• Launch flows arrive whole. A scratch simulation with a contract deployer and a PoolManager stand-in using v4-style sync/transfer/settle balance deltas and a CurrencyLibrary-style checked low-level transfer showed the 10/88/2 split, the distributor claim, a buy and a sell each move exactly their amount, leaving the factory at zero.
• ERC-20 surface. All standard selectors answer with the expected values; mutators return a single true word and never false; sentinel zero-address paths revert; self-transfer of a whole balance conserves; a max-uint amount reverts rather than wraps.
• Deployment phase. No constructor arguments, no initializer, mints 1e27 to the factory via CREATE2; decimals 18. The aderyn large-literal note is style only.

Two observations recorded as coverage, not findings. Zero-value transferFrom without allowance succeeds and emits Transfer(from,to,0) and Approval(from,caller,0) from any caller, and the approve front-running race exists. Both are ERC-20-conformant and identical to OpenZeppelin, so neither is a defect the author should change.

Not reachable here. No launch.json exists yet, so the manifest row is unreached. The real Uniswap v4 protected test could not run because v4-core is not vendored and lib/ is off limits, so only the token side of the pool flows is verified.

The scratch test lives at test/scratch/PonsEconomics.t.sol and is git-excluded, as is the findings file. No tracked file was changed.

Done. The full suite builds and passes, and no defect was found in the token.

What I added, both under test/ beside the existing 36-test unit suite, which I left untouched:

• test/PonsToken.invariant.t.sol: a handler that deploys the token itself, so it is the deployer holding the supply as the factory is at launch, and drives five senders plus four receive-only sinks including the token's own address. Every mutator has a clamped path shaped to succeed and a raw path with unrestricted amounts and the zero address, checked against an ERC-20 model that predicts the exact custom error. Ghost balances and allowances mirror the token. Eight invariants run after every call: fixed supply, sum of balances equals supply, balances and allowances match the ghosts, zero address holds nothing, no ether accepted, no balance exceeds supply, metadata constant. The handler also fires undeclared selectors and ether at the token. Inline config sets 256 runs at depth 32 with fail-on-revert on, so a silent handler revert fails the run.
• test/PonsToken.edges.t.sol: 33 tests for inputs the existing suite skipped. Zero-value calls on every path including a zero-value pull with no allowance. The zero address as a sender. The allowance boundary where max minus one is finite and max is infinite, including that the infinite case emits no Approval and still respects balance. Cumulative allowance spending across several pulls with the exact remaining value in the revert. Round trips, additivity, idempotent approvals, and independence of balances from allowances. CREATE2 deployment from a contract with the predicted address and the mint event, and proof that appended constructor bytes are ignored. Fuzzed undeclared selectors and ether to non-payable functions.

Verification. The invariant campaign is 8,192 handler calls with zero unexpected reverts. To confirm it is not vacuous I ran the same handler against a scratch copy of the token that leaks 1 wei per transfer. The conservation and ghost-balance invariants failed on it at once with the drifted sum. That scratch copy is deleted.

Findings. None. I wrote .imd-findings.json with an empty list. One behaviour worth knowing but not a defect: tokens sent to the token's own address are accepted and unrecoverable, which is standard ERC-20 and already documented in the README. A test pins that the supply still adds up in that case.

The two new files are uncommitted in the working tree for the harness to pick up.

Review complete. The findings file is written, the scratch test directory is removed, and the working tree is clean apart from the excluded .imd-findings.json.

Outcome: one informational finding kept, no defects of medium or higher severity. The Pons token is a plain fixed-supply ERC-20 and behaves as intended.

What I did

• Read src/PonsToken.sol, the manifest, README, deploy script and the protected launch test.
• Reproduced the single specialist finding with a scratch Foundry test using recorded logs. A zero-value transferFrom against a zero allowance emits Approval(owner, spender, 0) before Transfer, with no state change. Kept it at info severity. It was the only specialist finding, so there was nothing to merge.
• Probed the rest myself: zero-address reverts, insufficient balance and allowance paths, infinite allowance not decremented, self-transfer and self-transferFrom preserving balance, ETH refused with no receive or fallback, runtime free of DELEGATECALL, CALLCODE and SELFDESTRUCT, and both bytecode size limits. All held.
• Ran the project's existing suite. All 70 tests passed, including the invariant suite.
• Checked the aderyn large-literal lead. The literal evaluates to exactly the manifest's supply, so it is style only.
• Checked the manifest against the constructor: no arguments, supply of 1e27 matches, contract name within 32 characters, addresses lowercase.

Coverage record: approve and transfer hold, transferFrom is marked as finding 1 for the event quirk only, plus rows for the fixed-supply invariant and the aderyn lead.