The GLOBAL INK (PAVE) token is implemented, tested, documented and committed. A fresh offline clone of the commit builds, passes all 33 tests with the verifier's fuzz seed, and passes the format check.

What was delivered

• src/PaveToken.sol: a self-contained, fixed-supply ERC-20. The contract name is PaveToken (9 characters, manifest-safe). It returns name GLOBAL INK, symbol PAVE, 18 decimals, and mints the full supply once to the deployer in a zero-argument constructor that calls no other contract.
• No owner, mint, pause, blacklist, freeze, seize, burnFrom, upgrade path or transfer fee exists, so the factory, distributor and PoolManager flows move exactly what they say. Holders can burn their own tokens, so supply can only shrink.
• test/PaveToken.t.sol: 33 tests covering metadata, the exact supply, the mint to an EOA and to a contract deployer, every transfer and allowance success and failure path, burn, fuzzed supply conservation, and a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT. Tests read no environment variables.
• README.md documents behaviour, assumptions, the manifest's deployment parameters, the launch terms, and operational responsibilities, including that there is nothing to configure after launch.
• foundry.toml pins solc 0.8.26 with bytecode_hash = "none", the optimizer on, and ffi and filesystem permissions off. forge-std v1.11.0 is vendored as plain files under lib/forge-std with no nested git metadata, mapped by remappings.txt.

Verification

Check	Result
forge build	passes
forge test with the verifier seed, empty environment, offline fresh clone	33 passed, 0 failed
forge fmt --check	clean
Scratch replay of the protected floor's admin-call, freeze and swarm-share probes	3 passed

The scratch replay could not exercise the PoolManager seed and swap, since the protected harness's v4 dependencies are not in this repository. A fee-free token with no exemptions has nothing that could make those fail.

No value was left open for the requester, so no blocked file was written.

The review is written to .imd-findings.json: one low-severity finding, and coverage rows for all six entry points. No repository files were changed.

Finding (low): transferFrom(address(0), to, 0) succeeds for any caller and emits Approval(address(0), caller, 0) followed by Transfer(address(0), to, 0).

• Cause: _transfer (src/PaveToken.sol:130) only rejects a zero to, and _approve only rejects a zero spender.
• Impact: no balance, allowance or supply changes. The harm is limited to a mint-shaped log that anyone can emit, despite the contract's "minted exactly once" claim.
• Reach: any amount above 0 reverts with InsufficientAllowance, so only the zero-amount call gets through.
• Reproduction: I confirmed both events with a scratch Foundry test (since deleted). No proof test is attached to the finding, since it is not critical or high.
• Fix: reject from == address(0) in _transfer, and a zero owner in _approve.

Coverage:

• transferFrom is marked finding.
• approve, burn, increaseAllowance, decreaseAllowance and transfer are marked holds. Each touches only the caller's own balance or allowance, and the unchecked arithmetic is guarded by a prior check.
• Two invariants are also recorded as holds: no privileged role exists after deployment, and totalSupply never increases and matches the sum of balances.

The existing test suite passes (33 tests). The supplied protected tests were not run. There is no launch.json in the tree, so no manifest was reviewed.

Done. The manifest is written and verified against the accepted tree.

What I wrote: launch.json at the repository root, kind "custom_token", describing the single accepted contract PaveToken. The token entry gives name GLOBAL INK, symbol PAVE, 18 decimals, an empty constructorArgs list, and a totalSupply of 1e27 minor units. The contracts list is empty because the accepted tree has no application contracts. The pool and economics objects are copied exactly from the launch terms, with IMD as the paired currency, fee 12500, tick spacing 60, and the one-to-one provenance price. The notes describe the token's fixed supply, lack of privileged powers, and holder-only burn.

How I checked it:

• The compiled PaveToken ABI has no constructor inputs, so the empty constructorArgs matches declaration order exactly.
• The constructor mints 1_000_000_000 * 10 ** 18 to msg.sender once, which equals the manifest's totalSupply string.
• The manifest has only the six schema keys, string uint256 values, numeric fee, tickSpacing and decimals, lowercase addresses, and notes under 4000 characters.
• forge build compiled cleanly and forge test passed all 33 tests.
• Git status shows launch.json as the only new file. Nothing else was changed.

Review complete. The findings file is written and validated, and the scratch tests are removed so the tree has only .imd-findings.json added.

Result: one low finding, no critical, high or medium defects. The token behaves as the brief and the protected floor require.

What I covered (Execution Trace, Periphery, First Principles against src/PaveToken.sol):

• Every entry point traced through checks, state writes and failure paths: approve, burn, decreaseAllowance, increaseAllowance, transfer, transferFrom, plus the constructor. All hold except one event-level quirk in transferFrom.
• Invariants confirmed by reading every writer and by fuzzing: sum of balances equals total supply, supply never exceeds 1e27, every unchecked block is justified by that bound, self-transfer at full balance does not double count.
• Launch flows move exactly what they say. There is no fee, exemption list, external call, owner, mint path, receive or fallback. The existing opcode-scan test passes and the interface matches the protected harness.
• Periphery has nothing to review: the contract vendors no library and its three internals are private. The aderyn lead on line 45 is the literal 1e27 and is not a defect.

The finding (low): transferFrom(address(0), X, 0) succeeds from any caller because _transfer validates only the recipient and a zero amount passes the allowance check with no allowance. It emits a mint-shaped Transfer(address(0), X, 0) and Approval(address(0), caller, 0). No balance or supply changes, so the impact is spoofed events for indexers and explorers. The fix is a one-line zero-sender check at the top of _transfer, which is what OpenZeppelin does.

Coverage record has eleven rows: six for the listed entry points, one for the constructor, three invariants and the static-analysis lead. None are marked unreached.

The findings file is valid, the snippet matches line 131, and the scratch directory is removed. The review is complete.

Result: no math defects found in PAVE. The token has no division, scaling, casts or fixed-point arithmetic, so the Math Precision and Numerical Gap failure modes have nothing to attach to. Every unchecked block is preceded by the guard that makes it safe. The one item recorded is informational.

What I checked, in src/PaveToken.sol:

• Supply constant is exactly 1e27, below the int128 and uint128 limits Uniswap v4 uses, and the 10/88/2 percent launch splits divide it with no dust.
• transfer and transferFrom keep the sum-of-balances invariant, including a full-balance self-transfer through both paths, since the receiver write re-reads storage.
• burn cannot underflow totalSupply because every balance is bounded by it. Burning zero, the whole supply, supply plus one and max all behave as intended.
• Allowance math decrements exactly, treats max as unlimited, converts max to finite on decrease, and reverts with a checked panic on max plus one in increaseAllowance. A revert in the transfer leg leaves the allowance untouched.
• Stateful invariant fuzzing across four actors over transfer, transferFrom with finite and infinite allowances, and burn never broke the supply invariant.

The one recorded finding, severity info: a zero-value transferFrom naming the zero address as sender succeeds and emits a mint-shaped Transfer event. No value can move that way, so it only misleads indexers. The suggested fix is a sender-not-zero check in the internal transfer.

Coverage in .imd-findings.json answers all six entry points plus three invariant rows. Nothing was left unreached.

Review complete. The findings file is written with an empty findings list and a full coverage record.

Outcome. I found no defects in src/PaveToken.sol within the Economic Security, Invariant and Flow Gap areas. The token is a self-contained fixed-supply ERC-20 with a holder-only burn, no owner, no fees, no exemptions and no external calls.

What I checked

• Economic Security: no dependencies, oracles or callbacks to break. Every transfer path moves exactly the stated amount, so the swarm share, pool seed and trader round trips arrive whole. Burn can only shrink the caller's own balance, so no holder can be harmed by another's burn and nothing can grow the supply.
• Invariants: a stateful fuzz campaign over transfer, approve plus transferFrom and burn across six actors never broke the conservation law that balances sum to totalSupply, which never exceeds the initial supply. Allowance paths were checked at the boundaries, including infinite allowance, overflow on increase and underflow on decrease.
• Flow Gaps: I replayed the launch flow through a CREATE2 factory contract using the strict return-data check Uniswap v4 applies to token transfers. The 10/88/2 split and the trader buy and sell moved exact amounts with the supply unchanged.
• Static analysis lead: the aderyn large-literal note points at the supply constant, which evaluates to exactly 1e27 as the manifest requires. Not a defect.

Coverage. All six listed entry points are marked holds, plus rows for the conservation invariant, the mint invariant, the launch flow and the absence of receive or fallback. No entry point was left unreached.

The scratch tests were removed after running, so the tree is unchanged apart from the findings file.

The findings file is in place at the repository root; the harness deliberately excludes it from git, same as the .imd/ reads, so that is expected.

Work is complete. Summary:

Added two test files under test/ beside the existing suite, which I left untouched.

• test/PaveToken.invariants.t.sol holds a handler with six actors (deployer plus five holders) and ghost variables for burned supply, transfer volume and a shadow allowance ledger. Seventeen handler functions drive bounded success paths, full-amount liveness paths, and explicit failure paths that assert the exact custom error and that nothing moved. Seven invariants run after every call: balances sum to the supply, supply equals initial minus burned and never grows, the zero address holds nothing, no balance exceeds supply, allowances match the shadow ledger, metadata is constant, and the token holds no ether and its runtime is unchanged. Run counts are set with inline config and the run uses fail-on-revert.
• test/PaveToken.edge.t.sol adds 44 unit and fuzz tests for the inputs the original suite skipped: whole supply and one wei, burning everything, the uint256 ceiling on burn, transfer and increaseAllowance, max-minus-one versus unlimited allowances, repeated identical calls, self-allowance and self-recipient transferFrom, a stranger naming the zero address as owner, ether and unknown selectors, and a second independent instance.

Verification. The full suite is 78 tests and passes with the verifier's fuzz seed and without it. Scratch checks confirmed every handler path fires and that the invariant harness fails on two mutant tokens, one that skips lowering supply on burn and one that never decrements a finite allowance.

One finding reported, severity info, written to the findings file rather than asserted as correct. Anyone can call transferFrom with the zero address as owner and amount zero. It succeeds and emits a Transfer event from the zero address with value zero, which explorers read as a mint. No balance or supply changes and the launch floor is unaffected. The edge test pins only the safety half: nothing is created and one wei from the zero address reverts.

No other defects found. The contract has no privileged surface, no payable path, no delegatecall or selfdestruct, and its supply can only shrink.

The review is complete and written to .imd-findings.json. No source files were changed, and the scratch tests were removed.

Outcome: PaveToken is a sound fixed-supply ERC-20. One low-severity defect survives, and it is the same root cause all four specialists reported.

Kept finding (merged from audit_permissions, audit_math, audit_flow and the test writer):

• _transfer in src/PaveToken.sol:131 checks only the recipient, never the sender. Any caller can run transferFrom(address(0), to, 0) and the token emits a mint-shaped Transfer(address(0), to, 0) plus Approval(address(0), caller, 0). I reproduced it with a Foundry test using expectEmit on both events, and confirmed that amount 1 reverts with InsufficientAllowance, so no value can move. Severity stays low: spoofed events only, no funds or supply at risk. Fix is a one-line sender zero-address check.

Dropped: the aderyn large-numeric-literal lead at line 45. The constant is the readable supply expression and equals the manifest value.

Coverage: all six entry points answered. Five hold, transferFrom carries the finding. I also recorded the constructor supply invariant, bytecode and size limits, and the manifest match (no constructor arguments, supply 1e27, decimals 18, name and symbol agree with launch.json). The existing 78 project tests pass.