Implemented PLEA with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No additional minting or admin controls.

Dependencies are vendored for offline builds; deployment assumptions and responsibilities are documented in README.md.

Verified successfully:

• forge build
• forge test — 33 passing tests, including fuzz and stateful invariant tests
• forge fmt --check

launch.json is written and verified. The only new file in the tree is the manifest; the other untracked entries are the sandbox's device-node dotfiles, not my changes.

What the manifest says

• Token: contract PLEA, name PLEA, symbol PLEA, 18 decimals, empty constructorArgs, matching the accepted no-argument constructor in src/PLEA.sol.
• totalSupply: the constructor mints 1_000_000_000 * 10**18 to msg.sender, so the manifest states the matching 27-zero decimal string.
• Contracts: empty list. The accepted tree holds only the token, so no application contracts are named.
• pool: IMD pair address, fee 12500, tick spacing 60, and the one-to-one sqrtPriceX96 from the reference.
• economics: copied verbatim from the job.
• notes: 1,383 characters describing the fixed supply, the factory mint, the absence of privileged or fee-on-transfer logic, and the pool terms.

Checks run

• JSON parses, top-level keys are exactly kind, token, contracts, pool, economics, notes, and no hex string has odd length.
• forge build --offline, forge test --offline (33 tests across 2 suites, all passing, including the invariant suite), and forge fmt --check all succeed.

Nothing outside launch.json was modified.

The review is complete. The findings file is written and the tree is otherwise untouched.

Result: no defects found in the math, boundary or numerical-gap area. The file .imd-findings.json holds an empty findings list and eight coverage rows.

What the token is. PLEA is a 17-line contract that inherits the vendored OpenZeppelin v5.4.0 ERC20 unchanged and mints a constant supply to the deployer in the constructor. There is no override, no mint or burn path, no owner, and no arithmetic of its own beyond the supply constant.

What I checked, with concrete inputs run in a scratch Foundry suite:

• The supply constant evaluates exactly to 10^27 and equals totalSupply. It fits in uint128 and int128, which Uniswap v4 needs for liquidity and deltas.
• Transfer of uint256 max and of supply plus one revert with the insufficient-balance error before the unchecked subtraction. Transfer of the full balance, of 1 wei, of zero, and self-transfer all conserve balances exactly.
• Allowance edges: an allowance equal to the value drains to zero, one wei more reverts, max minus one decreases normally, max is treated as infinite and left unchanged. With infinite allowance and a max-value transfer, the balance check still fires.
• Zero-address sender, receiver and spender all revert. A zero-value transferFrom from the zero address reverts with the InvalidApprover error rather than InvalidSender, which is upstream library behaviour and still a revert with no state change.
• Launch-share arithmetic has no truncation: 10^27 divides evenly by 10,000 for every basis-point value from 1 to 10,000, and by 1,000.
• A 512-run fuzz plus the project's own invariant suite show totalSupply stays at 10^27 and equals the sum of balances.

The aderyn lead about the large numeric literal is not a defect. The literal is a compile-time constant that evaluates exactly.

Unreached. The pool seeding and price derivation could not be exercised because no launch.json exists yet and v4-core is not vendored in this tree. Only the supply's fit in the relevant integer types was verified.

Coverage rows mark all three entry points as holds, with the manifest and pool-math row marked unreached.

Review complete. The findings file is written at .imd-findings.json and the working tree is otherwise unchanged apart from that file.

Outcome: the PLEA token itself is clean across my area. I found one low-severity provenance defect in the vendored test library, and nothing in the production contract.

What I traced (Execution Trace, Periphery, First Principles):

• src/PLEA.sol is a plain OpenZeppelin v5.4.0 ERC-20 with a constructor-only mint of one billion tokens at 18 decimals to the deployer. No constructor arguments, no owner, no hooks, no external calls.
• All three entry points hold. Approve, transfer and transferFrom go through the unmodified OpenZeppelin paths, revert atomically on bad input, and move exactly the requested amount. The factory cannot pull a holder's tokens without approval.
• The five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 release archive.
• The compiled runtime contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT opcodes, checked with the same PUSH-aware scan the protected harness uses.
• A scratch replica of the protected harness flows (CREATE2 deploy by a factory, swarm share to distributor and claimant, pool transfers both ways, privileged selectors from the factory, ETH rejection) passed. The project's own 33 tests also pass. The scratch file has been removed.

The one finding (low): the vendored-library README claims every upstream file is unmodified and verifiable with the recorded checksums, but seven forge-std files were reformatted after the hash list was written. Running the documented command fails:

sha256sum --check lib/SHA256SUMS
# sha256sum: WARNING: 7 computed checksums did NOT match

I confirmed against the upstream v1.9.7 archive that the differences are whitespace only, so there is no behavioural impact and forge-std is test-only. The fix is to regenerate the hash list and soften the "unmodified" wording, or restore the upstream bytes and exclude lib/ from formatting in the configuration.

Coverage record: eight rows, all three listed entry points marked holds, plus rows for the constructor and supply invariant, runtime opcodes, OpenZeppelin provenance, forge-std provenance (finding 1) and the launch flows. Nothing was left unreached.

The review is complete and the findings file is written.

Outcome: The PLEA token's permission model holds. No access control, trust gap or asymmetry defect was found, and nothing in it needs a Foundry proof.

What was checked

• The token is the unmodified OpenZeppelin v5.4.0 ERC20 with a constructor-only mint to the deploying account. All five vendored OpenZeppelin files were read line by line and match the published release.
• The compiled runtime's dispatch table holds exactly the ten ABI selectors. There is no fallback, receive, owner, minter, pauser or initializer, and the runtime contains no call, create, delegatecall or selfdestruct opcodes.
• A scratch Foundry test exercised the boundaries with concrete actors: the factory that deploys the token receives the whole supply and its caller nothing; neither the deployer, a stranger nor the holder itself can move a holder's balance through transferFrom without an allowance; an allowance is usable only by its spender and only once; unknown selectors and any ETH revert. All five tests passed and the scratch file was removed.
• The existing suite of 33 tests, including the stateful invariant, passes.

One informational finding, outside the assigned area: running sha256sum --check lib/SHA256SUMS fails for seven forge-std files, so the provenance check the README documents does not pass. This touches test-only code and cannot affect the token's bytecode. The author should regenerate the hash file or re-vendor forge-std v1.9.7.

Coverage record: all three listed entry points are marked holds, with five additional rows for the constructor's role handout, hidden entry points, the fixed-supply invariant, launch-flow exactness and the paired-function symmetry checks. No launch.json exists yet, so there was no manifest to review. The protected harness could not be run locally because it depends on v4-core and launch libraries that are not in this tree.

Added 17 tests and expanded stateful invariants covering allowance failures, rollback, boundary values, and transfer liveness.

Offline forge build and forge test pass: 50 tests, 9,000 fuzz cases, and 32,768 invariant calls.

Only test/ changed. No defects found. The external protected launch integration was not run; its required configuration is absent locally.

The review is complete and .imd-findings.json holds the result: one low-severity finding and fourteen coverage rows, all three ABI entry points answered.

Outcome. The PLEA token has no defect in the assigned area. It is the unmodified OpenZeppelin v5.4.0 ERC-20 with a constructor-only mint of exactly 1e27 units to msg.sender, no owner, no hooks, no fee, and no exemption list to get wrong.

What I verified

• Economic Security. No external calls, oracles, fee formulas or sentinel branches exist. Transfers to the zero address and approvals of the zero spender revert, whole-balance transfers and max-uint approvals behave per ERC-20, and the vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag.
• Invariants. Supply equals the manifest string forever, since _mint is reachable only from the constructor and ten admin-style selectors revert from both a stranger and the factory. Sum of balances equals supply across the project's 16,384-call invariant run and my own fuzz.
• Flow Gap. I built a scratch lab outside the repository with the real Uniswap v4 PoolManager and ran the launch as the factory performs it: CREATE2 deploy, 10% to a distributor and onward to a claimant, single-sided seed at the 2,500-unit opening cap with fee 12500 and spacing 60, then a buy and a full sell-back by an ordinary trader. It passed with ETH as the pair and with an ERC-20 pair in both currency orders. A replica of the protected opcode scan finds no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Documentation claims. The README's Ethereum chain claim is consistent with the paired currency, which resolves to the IMD token with 18 decimals on mainnet, and forge fmt --check passes on the project files.

The one finding, low severity. Seven vendored forge-std files are whitespace-reformatted copies of v1.9.7, so the provenance check that lib/README.md tells a verifier to run fails:

sha256sum --check lib/SHA256SUMS   # 29 OK, 7 FAILED

It is outside my area and test-only. Production bytecode is unaffected. The fix is to re-vendor the pristine files or regenerate the checksums and drop the "unmodified" claim.

Not reached. The network's own protected harness could not be run here because it depends on the factory's LaunchLiquidity and hook-guard sources that are not in this tree. My lab reproduces its token-facing flows but not its hook or address-prediction steps.

The review is complete and written to .imd-findings.json. No repository file was changed (git status is clean apart from the findings file, which is ignored).

Outcome: the PLEA token is a plain OpenZeppelin v5.4.0 ERC-20 with a no-argument constructor that mints the full supply once to the deployer. I found no defect in the token itself. The only specialist finding, reported three times by the flow, permissions and economics areas, reproduces and is merged into one low finding.

The one finding (low): seven vendored forge-std files fail the hash check that the dependency README tells a verifier to run.

• Running the check from the repository root reports 29 OK and 7 FAILED, exit status 1, all under the forge-std sources.
• I downloaded the forge-std v1.9.7 archive, whose hash matches the value the README quotes, and compared each failing file. With all whitespace stripped the pairs hash identically, so the committed files are the upstream sources re-wrapped by the formatter.
• All five OpenZeppelin files the token imports verify, forge-std is test-only, and the compiled runtime has no CALL, DELEGATECALL, CREATE or SELFDESTRUCT opcodes, so the deployed bytecode is unaffected. The defect is a false provenance claim, nothing more.

Coverage: all three entry points hold. Each is the unmodified OpenZeppelin implementation, traced through the allowance, balance and zero-address failure paths. I also recorded the supply invariant, the manifest (schema keys only, empty constructor arguments matching the constructor, supply and decimals exact, sizes far below the limits) and the opcode floor as holding. The build succeeds and the existing 50 tests pass.

Leads dropped: the aderyn "large numeric literal" line points at the underscore-separated supply constant and is not a defect.