Implemented PleaToken: plea (PLEA), 18 decimals, with 1,000,000,000 tokens minted once to the deployer.

Included vendored dependencies, success/failure tests, conservation invariants, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed using the required fuzz seed.
• forge fmt --check passed.

Protected launch integration remains for the separate launch harness.

I found no permission defects in PleaToken. .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all marked holds, plus two rows for supply and minting invariants. I changed no other files.

Scope: src/PleaToken.sol and the OpenZeppelin v5.0.2 ERC20 it inherits. I made the Access Control, Trust Gap and Asymmetry passes myself; no helpers were used.

• Access Control: the contract adds only a constant and a constructor. The constructor mints all 1,000,000,000 × 10^18 units once to msg.sender, which in a launch is the factory. There is no owner, role, pause, blacklist, freeze, seize, burn function or further minting. _mint runs only from the constructor and _burn never runs, so the total supply cannot change.
• Trust Gap: none of the inherited functions are overridden, so there are no fees, hooks or exemptions. The factory's handoffs, the distributor's claims and pool swaps all move exactly the amount stated.
• Asymmetry: transfer and transferFrom both go through the same internal transfer. transferFrom checks the spender's allowance before moving anything. An unlimited allowance is not reduced when spent, which is the standard documented behaviour. The race when changing an existing allowance is a known property of every ERC-20, not a defect here.
• Leads: slither reported nothing. Aderyn's only line, a "large numeric literal" at line 10, is the supply constant and is not a defect.
• Checks run: the project's own tests pass (32 of 32). The OpenZeppelin files match the hashes in DEPENDENCIES.sha256.

Outside my area (no finding filed): six forge-std files (Vm.sol, StdJson.sol, StdToml.sol, StdAssertions.sol, console.sol, IMulticall3.sol) do not match DEPENDENCIES.sha256. That contradicts DEPENDENCIES.md, which says the files are unmodified. forge-std is used only by tests and is not part of the deployed token, so it has no effect on the contract. I didn't look into why the files differ.

Not run: the protected launch checks depend on floor files that aren't in this tree, so I didn't run them. A clean review here does not prove the token has no defects.

Done. The manifest is written and verified, and it is the only changed file.

What I wrote in launch.json:

• Kind is custom_token. The token entry names the Solidity contract PleaToken, with name plea, symbol PLEA, 18 decimals, an empty constructorArgs list, and totalSupply of 10^27 minor units.
• The contracts list is empty. The accepted tree contains only the token, with no application contracts.
• Pool and economics are copied exactly from the brief: IMD pair at the given address, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object verbatim.
• Notes describe the fixed supply token, its lack of admin powers, and that the launch flows move exact amounts. The notes are well under the 4000 character limit.

What I verified:

• The compiled ABI confirms the constructor takes no inputs, matching the empty constructorArgs.
• The constructor mints exactly 1,000,000,000 times 10^18 to msg.sender, matching totalSupply.
• The JSON parses and contains only the schema's six top level keys, with addresses in lowercase.
• Build succeeds and all 32 tests pass with the verifier's fuzz seed.
• Git status shows launch.json as the only new or changed file.

I found no economic defects in the PLEA token. The findings file holds one informational item from outside the economics area. The report is in .imd-findings.json; it is valid JSON and nothing in the repository was changed.

The contract: src/PleaToken.sol is a stock OpenZeppelin v5.0.2 ERC20. The OZ files it builds from match their pinned hashes. Its constructor mints exactly 1,000,000,000 × 10¹⁸ to the deployer, which is the factory. It takes no constructor arguments, so the manifest's constructorArgs should be []. The name is "plea", the symbol "PLEA", and decimals 18. The public functions are only the standard ERC-20 ones.

What I checked against the three guides:

• Economic Security: transfers have no fee, burn, rebase or hook, so the factory's transfers to the distributor and the pool, and traders' swaps, all move exactly the stated amount. There is no external dependency or oracle, and no owner, pause, blacklist or seize power.
• Invariant: the supply is fixed (the constructor is the only place tokens are created) and always equals the sum of balances. A finite allowance drops by exactly the amount spent, an unlimited one stays unlimited, and a failed transfer rolls the allowance back.
• Flow Gap: none of the four seams applies here, because the token makes no outside calls and runs no code mid-transfer.

Testing: the project's 32 tests pass. I also ran my own fuzz test (1,024 runs) on exact transfer amounts, allowance accounting and supply conservation, and it passed. I then deleted it. I could not run the protected floor tests here, because the files they import aren't in this tree.

Coverage: approve, transfer and transferFrom each have a row marked holds, plus two rows for the supply invariant and the constructor and metadata.

The informational item: running sha256sum --check DEPENDENCIES.sha256 fails on six vendored forge-std files. I compared them with the upstream v1.9.6 release, and the only differences are whitespace and line wrapping. This contradicts the statement at DEPENDENCIES.md:13 that the files are unmodified, but it doesn't affect the token, because forge-std is used only by tests. The fix is to restore those six files exactly from the release.

Leads I dropped:

• The large-number warning from aderyn is just the supply constant, which is correct.
• The approve front-running race is standard ERC-20 behaviour.
• Tokens sent to the token contract's own address are stuck for good, which is expected for a token with no admin.

The review is complete and .imd-findings.json is written. The working tree is clean apart from that file.

Outcome: the math area of PleaToken is clean. The token is an unmodified OpenZeppelin v5.0.2 ERC-20 with one compile-time constant supply, no division, no downcast, no scale conversion and no mint or burn entry point after the constructor. I traced all three entry points through the vendored _update, _spendAllowance and _approve paths and found every unchecked block guarded by the check that makes it safe.

What I checked in depth (Math Precision, Boundary, Numerical Gap guides):

• Supply constant. 1_000_000_000 * 10 ** 18 evaluates to exactly 10^27 and matches the manifest supply; decimals return 18. The aderyn large-literal lead is a style note, not a defect.
• Transfer arithmetic. The balance guard precedes the unchecked subtraction, and the unchecked addition is bounded by the fixed supply. Values at max uint, supply plus one, one wei, zero and self-transfer all behave as specified and conserve the sum of balances.
• Allowance arithmetic. The max-uint sentinel is never decremented, max minus one decrements normally, an allowance equal to the value reaches zero, and a balance revert rolls back the allowance write.
• Invariants. The project's invariant suite and a fuzz conservation test of my own pass.

One finding, low severity, outside my area. DEPENDENCIES.md tells readers to verify the vendored libraries with the checksum file, but six committed forge-std files do not match it, so the documented check fails. OpenZeppelin verifies and forge-std is test-only, so the token bytecode is unaffected. The author should regenerate the checksum list or restore the exact release files.

Coverage: all three listed entry points are marked holds, plus rows for the supply invariant, balance conservation, the decimals scale and the static-analysis lead. Nothing was left unreached. No proof file was needed since no finding is high or critical.

The review is complete. The findings and coverage record are written to .imd-findings.json in the repository root, and no tracked file was changed.

Outcome. The token is a 17-line wrapper over an unmodified OpenZeppelin v5.0.2 ERC-20, and the control-flow audit found no defect in the contract itself. One low-severity defect was substantiated in the vendored test library.

Finding 1, low. The repository's own provenance gate is red. The README lists a sha256sum --check of the dependency hashes as a build step, and the dependency notes claim every vendored file is an unmodified release source. On the committed tree that check fails for six forge-std v1.9.6 files. The recorded hashes are the correct upstream values. The committed files were re-wrapped in forge fmt style after vendoring. A whitespace-stripped comparison against upstream is identical for every file, so test semantics and the deployed bytecode are unaffected. The fix is to restore the six pristine files or regenerate the hash list and reword the claim.

What was traced and holds.

• The three entry points, approve, transfer and transferFrom, follow the stock OpenZeppelin paths. Zero-address sentinels revert, self-transfers re-read storage so balances are preserved, and a failed allowance spend or transfer rolls both back.
• The constructor mints the whole supply once to the immediate caller. Deployed through a CREATE2 factory, that is the factory, not the transaction origin.
• The ABI exposes only the ten standard ERC-20 functions plus the supply constant. No mint, burn, pause, blacklist or owner path exists, so the supply is fixed and launch flows move exact amounts.
• A reachable-opcode scan of the compiled runtime and creation code found no DELEGATECALL, CALLCODE, SELFDESTRUCT or external call, and no metadata hash.
• Chain 1 and chain 4663 both accept PUSH0 and TSTORE, so the Cancun build target is deployable on either.
• All five OpenZeppelin files are byte-identical to upstream v5.0.2.
• Build, the seeded test suite of 31 tests and 2 invariants, and forge fmt --check all pass.

Not reached. The Uniswap v4 seed and swap path in the protected floor could not be executed locally because v4-core is not vendored. The token has no transfer override, so nothing in it can tax or block that path.

Added 15 boundary, failure-path, and fuzz tests. Strengthened invariants to track exact balances and allowances across random call sequences.

Offline forge build and forge test pass with the supplied seed: 47 tests passed, including 16,384 invariant handler calls.

Changes are confined to test/. No contract defects were found.

The findings file is valid, both cited snippets match the tree byte for byte, and git status shows no files changed besides the findings output (which is gitignored by the harness).

Outcome: the PLEA token itself is clean. The only substantiated defect is the one all three specialists reported, merged into a single low finding.

What I verified

• Build, formatting check and all 47 tests pass with the README's fuzz seed.
• The token is a bare OpenZeppelin v5.0.2 ERC20 with one constructor mint of exactly 1e27 to the deployer. All five vendored OpenZeppelin files hash identically to upstream, so the inherited approve, transfer and transferFrom behave as documented. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT in reachable code, and both bytecode sizes are far under the limits.
• The manifest matches the code: contract name, token name, symbol, decimals, empty constructor arguments and total supply, with only schema keys, lowercase addresses and short notes.
• The aderyn large-literal lead is the correct 1e27 constant, so it was dropped.

Findings written to .imd-findings.json

1. Low, merged from three specialists. The documented sha256sum --check DEPENDENCIES.sha256 fails on six forge-std files. I reproduced it and confirmed the cause: the recorded hashes match upstream v1.9.6 exactly, while the committed files differ only in whitespace, consistent with a formatter pass. Test-only, no bytecode impact, but the shipped provenance claim is false.
2. Info. README line 92 says the repository ships no launch.json, yet one is committed at the root. Documentation drift only.

Coverage: all three entry points marked holds with traced reasons, plus one row for the constructor and supply invariant. No critical or high findings, so no proof tests were needed.