Implemented PLEA with 1,000,000,000 tokens, 18 decimals, minted once to the deployer. Dependencies are vendored, and README documents factory distribution and launch responsibilities.

Verified with Solidity 0.8.26:

• forge build passes.
• All 37 local tests pass with the requested fuzz seed, including offline.
• forge fmt --check passes.

Protected integration checks remain for the independent verifier.

Done. The only file added is launch.json, and the build and full test suite pass with the verifier's fuzz seed.

What the manifest says

• Kind is custom_token with token contract PLEA, name PLEA, symbol PLEA, 18 decimals, and an empty constructorArgs list, matching the accepted constructor in src/PLEA.sol:14, which takes no parameters.
• totalSupply is 1000000000000000000000000000, exactly the one billion tokens in base units that the constructor mints once to msg.sender.
• contracts is empty because the accepted tree deploys nothing besides the token. The 87% / 3% / 10% split is the factory's work after construction, not a contract here.
• pool and economics are copied verbatim from the launch terms: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes explain the token's fixed supply, lack of privileged functions, and that no application contracts exist, in about 1,000 characters.

Checks run

• A script confirmed the manifest uses only schema keys, lowercase addresses, string uint256s, numeric fee, tickSpacing and decimals, and that economics and pool match the job verbatim.
• forge build compiled cleanly, and forge test with the pinned seed passed all 37 tests across 3 suites.
• git status shows launch.json as the only change.

Review complete. The findings file is written and parses.

Outcome. The PLEA token has no defects in the assigned area. It is an unmodified OpenZeppelin v5.4.0 ERC-20 with one constructor mint of a compile-time constant. There is no division, scaling, fee, cast, external call, payable path or bytes decoding anywhere in the token, so the Math Precision, Boundary and Numerical Gap failure modes have nothing to attach to.

What I checked and verified with a scratch Foundry test (8 tests, all passing, in test/scratch/MathBoundary.t.sol):

• The supply constant equals exactly 1e27 on chain, decimals are 18, and the 87/3/10 split in basis points is exact with zero remainder.
• Transfers of 1 wei, the full balance, zero value from an empty balance, and a full-balance self-transfer all behave correctly. Transfers of supply+1 and max-uint revert.
• Exact allowances go to zero and then revert. Infinite allowance is never decremented. Max-minus-one decrements correctly. An allowance larger than the balance reverts atomically and leaves the allowance intact.
• Zero-address sender, recipient and spender all revert.
• A 512-run fuzz confirms balance conservation and a constant total supply across reverting and non-reverting transfers.

One low finding, outside my area. The committed checksum manifest in lib does not match seven committed forge-std files, so the README's documented integrity check fails on the tree as shipped. The OpenZeppelin entries, including the only file the production token compiles against, all verify. The fix touches lib, which a worker may not modify, so it is left to the author. Line, snippet and the exact reproduction command are in the findings file.

Coverage. All three ABI entry points are marked holds with reasons. Five extra rows record the invariants and math checks above. The existing 37-test suite and the format check both pass. The aderyn large-literal lead was examined and not promoted. The Slither output was empty.

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

Outcome: no access-control, trust-gap or asymmetry defect in the PLEA token. One low-severity documentation defect outside the assigned area is reported.

What the token is. src/PLEA.sol is 17 lines: an unmodified OpenZeppelin v5.4.0 ERC20 whose constructor mints 1,000,000,000e18 to the deployer. The compiled ABI holds only the ten standard ERC-20 selectors plus the supply constant. There is no owner, initializer, fallback, mint, burn, pause, blacklist or upgrade path, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Area coverage.

• Access control: the only writers of balances and allowances are the holder's own calls. The factory cannot spend a holder's balance without approval, which both the local launch test and the protected privileged-hand test exercise.
• Asymmetry: transfer and transferFrom share one _update path. Zero-address checks mirror each other on approve and transfer. Self-transfer re-reads storage, so balance is preserved. No caller class is exempted or taxed, so the factory, distributor, PoolManager and traders all move exactly the requested amount.
• Trust gap: the 87/3/10 split is not enforced by the token. It comes from the launch policy, the swarm's fixed share and the remainder recipient. That is the intended design and is recorded in the coverage record as a trust assumption, not a defect.

The one finding (low). The README lists sha256sum --check lib/SHA256SUMS as a build check, and lib/README.md claims upstream sources are unchanged. On the committed tree that command fails for seven forge-std files. I fetched the upstream v1.9.7 archive, confirmed its digest matches the one documented, and confirmed the differences are whitespace-only reflows from forge fmt. The OpenZeppelin files, including ERC20.sol, all match. There is no on-chain impact. Since contributors may not modify lib/, the available fix is to correct the README claim or regenerate the checksum list through a process allowed to touch lib/.

Checks run. forge build succeeded, all 37 existing tests passed with the documented fuzz seed, and forge fmt --check passed. Slither and aderyn output from the verifier had nothing above a benign large-literal note, which is the supply constant.

Coverage record. All three listed entry points are marked holds, plus rows for the constructor, the no-privileged-surface invariant, the genuine-OZ check and the distribution trust assumption. No files in the tree were changed. The temporary download directory was removed.

The review is complete and the findings file is written and validated. Only the untracked .imd-findings.json was added to the tree.

Result: the token is clean. One low-severity periphery finding.

PLEA is an unmodified OpenZeppelin v5.4.0 ERC20 with a single constructor mint of 1,000,000,000e18 to the deployer. I traced all three entry points under the Execution Trace, Periphery and First Principles guides and found no defect in src/PLEA.sol:

• Execution trace. No parameter divergence, sentinel paths, external calls, callbacks or partial updates exist. Every revert path restores balances and allowances. Launch flows to the distributor, pool and rewards recipient move exactly the stated amount, and the factory cannot spend a holder's balance without approval.
• Periphery. The five OpenZeppelin files the token inherits are byte-identical to upstream v5.4.0, verified by fetching each file from GitHub and comparing SHA-256 digests.
• First principles. No owner, mint, burn, pause, blacklist, permit, receive or fallback. ETH and unknown selectors revert. The runtime has no forbidden opcodes. CREATE2 from the factory credits the factory, not the transaction origin. The 87/3/10 split sums to the whole supply and is consistent with the pool share and swarm share described for the launch.

Finding (low). The README's documented integrity check sha256sum --check lib/SHA256SUMS fails on the delivered tree. Seven forge-std files were reformatted after the manifest was recorded. The recorded digests match genuine upstream v1.9.7, and the tree files are identical to upstream once whitespace is stripped, so the drift is semantically nil and test-only. The defect is that the project's own offline provenance check reports tampering on a clean checkout. Fix by regenerating the manifest or restoring the upstream bytes.

Checks run. The full suite passed: 37 tests across three files including 512-run fuzzing and the 128x64 stateful invariant. forge fmt --check passed. Slither and aderyn output from the verifier reported nothing actionable beyond a numeric-literal style note, which I did not report.

Coverage. All three entry points are recorded as holds, plus rows for the constructor mint, the fixed-supply and no-privileged-hand invariants, the OpenZeppelin provenance, and the forge-std provenance that carries the finding. The protected suite's real Uniswap v4 seed and swap could not be executed locally because v4-core is not in this repository, but a plain ERC20 without exemptions cannot fail those flows.

The review is complete and the findings file is written. The working tree is clean apart from the review output itself.

Outcome: no economic, invariant or flow-gap defect in the token. PLEA is an unmodified OpenZeppelin v5.4.0 ERC20 with one constructor mint and no other entry points, so every flow the launch depends on moves exactly what it says.

What I checked, in my area

• Economic Security: no external dependencies, no fee, rebase, pause or blacklist behaviour, sentinel handling reverts correctly on the zero address, and no mint, burn, permit, receive or fallback path exists.
• Invariant: supply is fixed at one billion tokens, the sum of balances equals total supply under a fuzzed run, and allowance accounting matches the documented semantics.
• Flow Gap: the 10% distributor, 87% pool and 3% remainder transfers arrive whole, and claims and pool-direction transfers are exact. The vendored OpenZeppelin files are byte-identical to upstream v5.4.0.

Findings written to .imd-findings.json

1. Low. The README's documented check sha256sum --check lib/SHA256SUMS fails on seven forge-std files. I downloaded the pinned v1.9.7 archive and confirmed they differ only by whitespace, so production bytecode is unaffected, but the documented integrity step does not pass on the committed tree.
2. Info. The 3% season-rewards tranche and the swarm share have no on-chain lock. This matches the brief and is recorded as a trust assumption, not a defect.

Coverage has rows for all three ABI entry points plus four invariant rows. The one thing not reached is an actual Uniswap v4 swap, since v4-core is not vendored here. The token side of that path is the plain transfer and transferFrom that already hold.

Added 15 tests covering allowance boundaries, authorization, and failure rollback. Expanded stateful invariants to 32,768 calls.

Validation passed offline:

• forge build
• forge test with the required seed: 52 passed, 0 failed

Only test/ changed. No implementation defects found.

The review is complete and the findings file is written. Only the findings file is new in the working tree, and both quoted snippets match the files line for line.

Outcome: the PLEA token is sound. It is an unmodified OpenZeppelin v5.4.0 ERC20 with one no-argument constructor that mints the full supply to the factory, and nothing else. No critical, high or medium defect exists.

What I reproduced and kept:

• Low, merged from all four specialists. The README's documented check sha256sum --check lib/SHA256SUMS fails on a clean checkout. Seven forge-std files were reformatted after the checksum list was recorded. I fetched the pinned forge-std v1.9.7 and OpenZeppelin v5.4.0 tarballs: both archive digests match the project's lib README, the seven files are identical to upstream once whitespace is stripped, and all five OpenZeppelin files the token compiles against are byte-identical to upstream. So production bytecode is unaffected and the impact is a false provenance claim. The fix lives in lib or the README, which the author must do.
• Info. The 87% / 3% / 10% split and the season-rewards custody are enforced by the factory and the remainderTo key, not the token. This is the requested design, recorded as a trust assumption.

My own pass: I built the project, ran its 52 tests with the README's fuzz seed, ran the format check, and checked the manifest against the source and schema rules. The three entry points, the constructor mint, the manifest and CREATE2 deployability all hold, and each has a coverage row with its reason.

Not run here: the protected Uniswap v4 harness, which needs the network's factory and pool environment the verifier supplies.