The plea (PLEA) token project is complete, verified and committed on main.

What was built

• src/PleaToken.sol is a fixed-supply ERC-20 on OpenZeppelin v5.1.0. The constructor takes no arguments and mints 1,000,000,000 PLEA with 18 decimals once to the deployer. It has no owner, mint, pause, blocklist, fee or upgrade path, so every launch flow moves exactly what it states and the supply can never grow.
• script/DeployPleaToken.s.sol is a reference deploy script. Its deploy function takes no environment input and is tested directly.
• test/PleaToken.t.sol and test/DeployPleaToken.t.sol hold 30 tests: metadata, exact supply and mint target, constructor event, launch-style forwarding from a contract deployer, transfer and allowance successes, insufficient balance and allowance reverts, zero-address reverts, absence of admin and mint selectors, no ETH acceptance, a reachable-opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and four fuzz tests for supply conservation and allowance bounds.
• README.md documents behaviour, manifest values, launch policy values, assumptions, after-launch settings (none), operational responsibilities and the security checklist notes.
• foundry.toml pins solc 0.8.26, enables the optimizer, sets bytecode_hash to none, and disables ffi. Dependencies are vendored as plain files under lib/ with no git metadata: forge-std v1.9.7 and only the five OpenZeppelin files the token imports.

Verification

Check	Result
forge build	passes, PleaToken runtime 2,158 bytes
forge test with the verifier's fuzz seed	30 passed, 0 failed
forge test with an empty environment	30 passed, 0 failed
forge fmt --check	clean

Slither was not available on this machine, so the Slither detectors were addressed by design rather than run. The protected floor tests supplied as inputs run in the verifier's own harness; this token meets each of their conditions by construction, since it exempts nothing, taxes nothing and exposes no privileged call.

I found no defects in the control-flow area (Execution Trace, Periphery, First Principles), so .imd-findings.json has an empty findings list. It also has a coverage row for each of the three entry points, plus three invariant rows. The file is valid JSON and the working tree is otherwise unchanged.

Why there is nothing to report:

• One small contract. src/PleaToken.sol is OpenZeppelin's ERC20 plus constants. Its constructor takes no arguments and mints 1e27 (1,000,000,000 × 10^18) once to msg.sender. It only overrides decimals(), which returns 18.
• Unmodified library. The five vendored OpenZeppelin files are byte-identical to upstream v5.1.0; I diffed them against the published release.
• Execution trace. transfer and transferFrom run the library's standard code with no hooks and no external calls. That rules out reentrancy and callbacks, and every launch flow (factory to distributor, the pool seed, swaps) moves exactly the amount stated. There is no tax or exemption logic that could go wrong.
• Periphery. No owner, mint function, pause, blocklist, receive or fallback exists, and the ABI exposes only standard ERC-20 functions and constants. I scanned the 2,158-byte deployed bytecode the same way the protected test does: there is no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• First principles. The supply can't grow after deployment and nobody can move or freeze a holder's balance. The only lead from static analysis, Aderyn's "large numeric literal" on line 26, works out to exactly 1e27, so it isn't a defect.
• Approval race. approve has the usual ERC-20 risk when changing an allowance, but that is how the standard behaves, so I didn't report it.

All 30 of the project's own tests pass. I didn't run the protected floor tests: they need contracts and environment variables this tree doesn't have.

Created launch.json matching PleaToken’s constructor, supply, and exact requested pool settings and economics.

forge build succeeded. All 30 repository tests passed with the supplied fuzz seed. Only launch.json changed.

The review is complete. The findings file is valid and the working tree is unchanged.

Result: no defects found in the permissions area. The findings file at .imd-findings.json holds an empty findings list and nine coverage rows, one for each of the three listed entry points plus the constructor and five invariants.

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

• Permission map. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no owner, minter, pauser, blocklist, initializer, receive or fallback, and no override of the internal update hook. With no privileged role, every Trust Gap seam that needs a privileged actor is structurally unreachable.
• Supply. The mint happens once in the constructor to the caller. No burn path exists, and transfer to the zero address reverts, so the total supply can neither grow nor shrink after launch.
• Allowance pairing. A scratch test confirmed that allowances are scoped to the owner and spender pair, that a third party or a different owner cannot use them, that the deployer and the token itself cannot pull a holder's balance, and that self-transfers conserve balance.
• Launch flows. Transfers move exactly the stated amount with no exemption branch, so the factory, distributor and pool flows arrive whole.
• Vendored base. The five OpenZeppelin files and forge-std's Test.sol are byte-identical to the upstream v5.1.0 and v1.9.7 tags, so the inherited behavior is the published library's.
• Static analysis lead. The aderyn large-numeric-literal note is style only. The constant evaluates to exactly one billion tokens at 18 decimals, as the existing tests assert.

Tooling. The project builds with solc 0.8.26, and all 30 existing tests plus seven scratch tests pass. The scratch file lives under the git-ignored test/scratch/ directory and is not part of the tree.

Not covered. The protected pool seed and swap tests need the v4-core harness and launch environment variables, which this repository does not vendor, so I could not run them locally. Those flows fall to the economics and control flow specialists in any case.

The math audit of the PLEA token is complete. It found no defects, and the findings file records that with full coverage.

Result. The token is a bare OpenZeppelin v5.1.0 ERC-20 with one constructor mint and a decimals() override returning 18. I verified all five vendored library files hash-match the upstream v5.1.0 tag byte for byte, so the transfer, approve and allowance arithmetic is the audited upstream code, unmodified. The repository builds cleanly and its 30 tests pass.

What I checked against the three guides.

• Math Precision: there is no division, no fixed-point scaling, no narrowing cast and no share math anywhere in the token. The only arithmetic is the supply constant, which evaluates at compile time to exactly the manifest value, and the library's balance updates, whose unchecked blocks are justified because every value is bounded by a balance that is bounded by the fixed supply.
• Boundary: the token makes no external calls, has no payable, receive or fallback function, no sentinel branch and no bytes decoding, so the guide's call-site and decode questions have no sites to apply to. I exercised the input edges instead: amounts of max uint, supply plus one, the full supply, self-transfers, and allowances at max, max minus one and zero.
• Numerical Gap: the single invariant that matters, sum of balances equals total supply, has no rounding term to drift by, and the supply divides evenly by basis points so the swarm and pool shares leave no dust.

Evidence. I wrote 13 scratch tests covering those edges and ran them at 2000 fuzz runs each. All passed, and I deleted the scratch directory afterward. The static-analysis lead about the large literal on line 26 is the intended supply value, not a defect, so it is not reported.

Deliverable. The findings file holds an empty findings list and eight coverage rows: one for each of the three listed entry points, all marked holds, plus rows for the supply constant, the conservation invariant, the dust-free launch split, the absence of boundary sites, and the library provenance. The working tree is otherwise unchanged.

The review is complete and the findings file is written and valid JSON.

Outcome: no economic, invariant or flow-gap defect found in the PLEA token. The one entry recorded is informational.

What I checked, in my assigned area:

• Economic Security. The token has no oracles, external calls, fees, rebasing, pause, blocklist or admin role. It refuses ETH and has no fallback, so unknown selectors such as mint, burn or burnFrom revert. I diffed the vendored OpenZeppelin files against upstream v5.1.0 and they are byte-identical.
• Invariant. The only writer of total supply is the constructor mint of exactly 1e27 units to msg.sender. A 256-run Foundry invariant test over random transfer, approve and transferFrom sequences kept the sum of balances equal to total supply throughout.
• Flow Gap. Transfers move exactly the stated amount, so the factory to distributor, factory to pool, distributor to claimant and pool round-trip flows all arrive whole. Uniswap v4 settle and take will observe exact deltas. The protected harness itself could not run here because v4-core is not vendored, so that row is reasoned from the code rather than executed.

The informational finding is the inherent ERC-20 approve overwrite race, reproduced with a test showing a spender moving 150 PLEA when the owner intended at most 100. It is a standard property, not a defect requiring a token change, and is noted for integrators.

Coverage has seven rows: the three entry points approve, transfer and transferFrom all hold, plus four invariant and flow rows. Existing suite: 30 tests pass, formatting check passes, no compiler warnings. Scratch tests live under test/scratch/ and are not part of the submission.

Added boundary and failure-path tests, six fuzz properties, and four stateful invariants covering 32,768 random handler calls.

forge build --offline and forge test --offline pass with the required seed: 52 passed, 0 failed, 0 skipped.

Only test/ changed. No confirmed implementation defects found.