Implemented PleaToken: 1,000,000,000 PLEA with 18 decimals, minted once to the deployer, with no administrative powers.

Vendored dependencies and documented deployment and operations in README.md.

Validation passed: forge build, all 34 local tests with the requested fuzz seed, and forge fmt --check. Full launch/pool admission checks remain with the network verifier.

Created launch.json matching PleaToken, its exact supply, empty constructor arguments, and required pool and economics values.

forge build succeeded; all 34 repository tests passed with the supplied fuzz seed. Manifest field and constructor ABI checks passed. Only launch.json changed.

The review is complete. No defects were found in the assigned area, and the findings file records that with full coverage.

Result: .imd-findings.json holds zero findings and seven coverage rows. All three entry points are marked holds, plus four rows for the invariants and seams I checked.

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

• The token is src/PleaToken.sol, a ten-line subclass of OpenZeppelin's ERC-20 with a constructor mint and nothing else. I confirmed the vendored OpenZeppelin files are byte-identical to upstream v5.4.0 by fetching and hashing the upstream sources.
• The supply constant is a compile-time expression evaluated at arbitrary precision and equals exactly 1e27. That resolves the one aderyn lead (large numeric literal) as a non-issue.
• Transfer and delegated-transfer arithmetic: the balance and allowance checks precede the unchecked subtractions, so balance+1, max uint, and allowance-above-balance inputs all revert with the correct custom error and leave state untouched. Receiver balances cannot overflow because all balances sum to 1e27. The max-uint allowance sentinel is never decremented, and max-minus-one is decremented exactly.
• Zero and sentinel boundaries: zero-value transfers succeed, any call involving the zero address reverts, and a zero-address transferFrom cannot mint even for a zero amount. The contract has no receive or fallback, so plain ETH sends revert.
• Launch flow math: the swarm's ten percent, its two and eight percent slices, and the pool share all divide 1e27 with no remainder, and the token applies no fee or exemption, so every launch leg moves exactly what it says.
• No divisions, rate multiplications, downcasts or scale conversions exist, so there are no precision-times-invariant seams to exploit.

Evidence run: forge build, the project's 34 tests with the README's fuzz seed, forge fmt --check, and a scratch suite of ten boundary probes (1024 fuzz runs on the balance edge). All passed. The scratch directory was removed afterwards and the tree is otherwise unchanged.

Not covered: nothing in my area was left unreached. Outside it, I did not run a full access-control or economic pass, though the token exposes no privileged function, proxy, delegatecall or selfdestruct for one to examine.

The review is complete. The findings file is written and validated, the scratch directory is removed, and the working tree has no stray files.

Outcome: no defect found in the PLEA token's permission model. The file .imd-findings.json holds one informational note and six coverage rows.

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

• Permission map. The compiled ABI exposes only the nine standard ERC-20 methods plus the public supply constant. There is no owner, minter, pauser, blacklist, initializer, upgrade path, receive or fallback, and no payable function. Storage is OpenZeppelin's five slots only.
• Constructor and deployment phase. The whole supply is minted once to the immediate creator with no arguments. Under a CREATE2 factory called by an externally owned account, the factory holds everything and the origin holds nothing. The factory keeps no power afterwards and cannot pull from a holder it was never approved by.
• Inconsistent guards and escalation. Every writer of balances and allowances goes through the unchanged OpenZeppelin _update and _approve paths. The only authorization is the per-spender allowance, and the unlimited allowance is the only branch that differs, which is standard behavior.
• Asymmetry pairs. Transfer versus transferFrom, happy path versus revert path, and zero-address sentinels all mirror each other. Failed transferFrom calls leave allowance and balances untouched.
• Dependency integrity. I fetched OpenZeppelin v5.4.0 from upstream and diffed it against the vendored copies. They are byte-identical and match the lock file checksums.
• Launch flows. The existing suite and my probes confirm transfers to the distributor, pool counterparty and requester arrive whole, and the supply never changes.

The one note recorded (severity info). A spender can front-run an owner's replacement of a non-zero allowance and spend both the old and new amounts. This is the standard ERC-20 approve race, not a defect this code introduced. The README already tells holders to revoke to zero first. I recorded it with a reproduction so the judge has the single asymmetry present on file, and recommended no code change.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal line is style only and was not reported.

Coverage. All three listed entry points have rows. Nothing in my area was left unreached.

Review complete. No defects found in the assigned area, and .imd-findings.json holds an empty findings list with eight coverage rows. The working tree is otherwise untouched.

What I checked

• Execution Trace. Traced transfer, transferFrom and approve through the vendored OpenZeppelin _transfer, _update, _approve and _spendAllowance. Zero-address sentinels revert on every path, including a zero-value transferFrom from the zero address, so no mint path exists after construction. Self-transfers net to zero, infinite allowance is never decremented but stays bounded by balance, and failed paths revert atomically. The approve race is standard ERC-20 behaviour, documented in the README, and not reported as a defect.
• Periphery. Fetched the five vendored OpenZeppelin files from the upstream v5.4.0 tag and compared SHA-256 digests. All five match exactly, so the base contract the token trusts is unmodified.
• First Principles. The constructor mints exactly one billion tokens with 18 decimals to the immediate creator, which is the factory under CREATE2. Name, symbol and decimals match the objective. The ABI exposes no mint, burn, owner, pause or upgrade selectors, there is no receive or fallback, and the runtime contains no CALL-family, CREATE, DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes.
• Static analysis lead. The aderyn large-numeric-literal note on line 10 is style only. The constant evaluates to exactly 10^27.

Evidence run

• Existing suite: 34 tests pass, including 128 invariant sequences.
• Ten scratch probes covering the edge paths above all passed, then the scratch directory was removed.
• forge fmt --check passes.

Coverage record. All three listed entry points are marked holds, plus rows for the constructor, fixed-supply and no-privilege invariants, the vendored library check, and the aderyn lead.

Added 16 boundary and failure-path tests, plus stronger invariants tracking every actor’s balances and allowances.

forge build and the full offline forge test passed with the specified seed, including 32,768 invariant calls.

Only test/ changed. No defects found.

The review is complete. No defects found in the Economic Security, Invariant or Flow Gap areas, and the findings file records that with full coverage.

What I reviewed. src/PleaToken.sol is an unmodified OpenZeppelin v5.4.0 ERC20 with one constructor that mints 10^27 units to the immediate deployer. I compared every vendored library file against the upstream mirror and found only header and comment differences. The verifier's offline build, all 34 existing tests, formatting and a second fuzz seed with 3,000 runs all pass.

Area results.

• Economic Security. There are no external dependencies, oracles, callbacks or payable paths. Transfers move exact amounts with no fee, rebase, pause or blacklist. Sentinel addresses behave per the standard: transfer and approve to the zero address revert. Decimals are 18 as the brief requires.
• Invariant. Total supply is fixed at construction and nothing in the contract can reach a mint or burn afterwards. Sum of balances equals total supply under the existing stateful invariant tests.
• Flow Gap. I ran a scratch test against a real Uniswap v4 PoolManager covering every launch leg: factory to distributor and on to a claimant, a single-sided seed settled by plain transfer, a trader buying with ETH and selling everything back, and the remainder to the requester. Every leg moved exactly the manager's delta and the three legs summed to the supply. The scratch test was removed afterwards.

Trust assumptions. The contract has no owner, minter, pauser, upgrade or recovery function, and its runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The only inherent ERC-20 properties worth noting are the approve-overwrite race and irrecoverable tokens sent to the token's own address. Both are standard behavior the README documents, so I did not report them as defects.

Coverage. The findings file holds an empty findings list plus eight coverage rows: the three entry points, each marked holds, and five invariant and flow rows describing what was traced and run. The working tree is unchanged apart from .imd-findings.json.

The review is complete and the findings file is written. Nothing else is needed.

Outcome: the PLEA token holds. No defect was found, and the one specialist finding is an inherent ERC-20 property, kept only as an informational note that requires no code change.

What I verified

• The token is a 17-line contract inheriting OpenZeppelin v5.4.0 ERC20 with a single constructor mint to msg.sender. The SHA-256 of all five vendored OpenZeppelin files matches the upstream v5.4.0 tag and the project's lock file.
• All three state-changing entry points (approve, transfer, transferFrom) are the unmodified OpenZeppelin paths. I traced their checks, state changes and revert paths, and the project's 50 tests plus the stateful invariant suite pass with the requested fuzz seed. The formatter check passes.
• Deployability under the factory model holds. The constructor takes no arguments, matching the manifest's empty constructorArgs, and the sizes are well under the limits.

Artifact	Size	Limit
creation code	2,634 bytes	49,152
runtime	1,753 bytes	24,576

• The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The ABI exposes no mint, burn, owner, pause or blacklist function.
• launch.json uses only schema keys, its totalSupply equals the constructor mint, and the paired currency on chain 1 answers as IMD with 18 decimals.

Specialist findings

• The audit_permissions note on the approve replacement race reproduced exactly as stated: a spender front-running a replacement approve moved 150e18 against an intended ceiling of 100e18. This is the ERC-20 standard's own behavior, the README already documents the revoke-then-approve mitigation, and I kept it at info with an explicit statement that no change is required and it must not block admission.
• The other four areas reported nothing, and my own pass found nothing they missed.

The findings file at the repository root holds one info finding and seven coverage rows covering every listed entry point plus the constructor, deployability, manifest and dependency checks. The scratch test I used for the reproduction has been removed, so no tracked file changed.