Implemented PleaIMD (PLEA): 1 billion tokens, 18 decimals, minted once to the deployer, with no admin or additional minting powers.

Included vendored dependencies, deployment documentation, and success, failure, fuzz, and invariant tests.

Verified with Solidity 0.8.26: forge build, all 31 tests using the supplied seed, and forge fmt --check pass.

I found no defects in the permissions area, so .imd-findings.json has an empty findings list. The coverage record says all three entry points hold.

What I reviewed: src/PleaIMD.sol is an unmodified OpenZeppelin v5.1.0 ERC20 (I checked the vendored ERC20.sol and Context.sol against the pinned hashes in DEPENDENCIES.json, and they match). Its only addition is a constructor that mints 1_000_000_000 * 10**18 to msg.sender once.

• Access control: There is no owner, role, modifier or admin function. Nobody can mint, burn, pause, blacklist or move a holder's balance after deployment.
• Trust gap: The deployer, which is the factory, receives the supply and gets no lasting powers. No launch addresses are passed in or trusted. There are no external calls, callbacks, receive or fallback, and no DELEGATECALL or SELFDESTRUCT.
• Asymmetry: transfer and transferFrom go through the same _update path, with no fees, exemptions or special treatment for any sender or recipient. So the factory, distributor and pool flows move exactly the amounts they state. transferFrom checks the allowance before moving anything, and an unlimited allowance is not reduced, which is normal OpenZeppelin behaviour.
• Static analysis: Aderyn's "large numeric literal" warning on line 11 points at the supply constant, which is correct as written, so it isn't a defect. Slither reported nothing.

Tests: I ran the existing project suite and all 31 tests passed, including the invariant run. I didn't run the protected launch tests, because they import files that aren't in this tree. The coverage record also lists three checked invariants: no privileged role after deployment, a fixed supply minted to the deployer, and no delegatecall, selfdestruct or external calls.

The usual race when an allowance is changed with approve is a property of the ERC-20 standard rather than of this code, so I left it out. No other files were changed.

I found no defects in PleaIMD, so .imd-findings.json holds an empty findings list plus a coverage record. No other file was changed.

What I reviewed: src/PleaIMD.sol (16 lines) and the OpenZeppelin ERC-20 code it inherits (version 5.1.0). The library files in lib/ match the hashes recorded in DEPENDENCIES.json, so the library is unmodified. The token overrides nothing and only calls _mint(msg.sender, 1e27) once, in its constructor. It has:

• no owner, pause or blacklist powers;
• no way to mint after deployment;
• no fee or burn on transfer;
• no assembly, external calls, receive or fallback.

Execution Trace: I followed approve, transfer and transferFrom through _approve, _spendAllowance, _transfer and _update.

• Transfers from or to the zero address revert.
• A balance or allowance that is too small reverts.
• An unlimited allowance is never reduced.
• Every transfer moves exactly the amount requested.

Periphery: Because transfers move exact amounts, the factory → distributor → claimant flow arrives whole, and so do the pool seed and swaps through the PoolManager. Decimals default to 18, matching the brief.

First Principles: Total supply is fixed at 10⁹ × 10¹⁸, and every unit starts with the deployer, which is the factory at launch. Nothing can move or freeze a holder's balance except the holder or a spender they approved.

Coverage rows: All three entry points are holds. I added two invariant rows: the fixed supply, and the absence of admin roles and forbidden opcodes.

Leads I dropped:

• Aderyn's "large numeric literal" at src/PleaIMD.sol:11 is only a style note about writing the supply constant; the value is correct.
• The known approve front-running race is standard ERC-20 behaviour, not a defect in this code.

The existing tests pass: 31 of 31 under forge test. I wrote no proof tests, since there were no findings. The protected launch checks need launch environment values I don't have, so I read them against the code instead of running them.

I found nothing to report in the math area (Math Precision, Boundary and Numerical Gap) for PleaIMD (PLEA). .imd-findings.json holds {"findings":[]} and a coverage record that answers all three entry points.

What the code is. src/PleaIMD.sol is a stock OpenZeppelin v5.1.0 ERC20 with no changes. The only custom code is INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 (1e27, far below 2^256), minted once to msg.sender in the constructor. I checked the vendored OpenZeppelin files against the hashes in DEPENDENCIES.json and they match, so the library is unmodified.

Math checks. Against all three guides, there is no division, rounding, scaling, downcast, fee, burn, shift or bitmask to examine. The only arithmetic is OpenZeppelin's _update and _spendAllowance. Its unchecked steps are safe because no amount can exceed the fixed 1e27 supply.

Boundary tests. I ran a temporary fuzz test (1,024 runs each) and then deleted it. All tests passed:

• Supply is exactly 1e27, the deployer holds all of it, and decimals() is 18.
• Transfers of 0, the full balance and to yourself work; one more than the balance reverts.
• transferFrom lowers the allowance by exactly the amount spent, reverts if the amount exceeds the allowance, and leaves an unlimited (type(uint256).max) allowance unchanged.
• Sending or approving to the zero address reverts.
• After every transfer, balances still add up to the total supply.

Coverage rows (all holds):

• approve(address,uint256)
• transfer(address,uint256)
• transferFrom(address,address,uint256)
• Two invariants: the fixed supply minted once, and 18 decimals with no fee or burn rounding.

The project's own 31 tests also pass. The aderyn "large numeric literal" warning is about code style only. Slither reported nothing.

The tree has some untracked files I did not create (.bashrc, .claude/, .mcp.json, .vscode and other editor/shell files). I left them alone; you may want to check they don't end up in the submission. I did not modify any tracked files.

Created launch.json with the exact supply, economics, pool settings, and empty constructor arguments matching PleaIMD.

forge build succeeded; all 31 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

The review is complete and the record is written. No tracked file changed, and the only new files are the findings record and my gitignored scratch test.

Result: no defects found in the Economic Security, Invariant or Flow Gap area. The findings list in .imd-findings.json is empty, with a coverage record of ten rows that answers all three listed entry points as holds.

What I checked and how:

• Source. The token is sixteen lines: an unmodified OpenZeppelin v5.1.0 ERC-20 whose constructor mints a compile-time constant of exactly 10^27 base units to its caller. The compiled ABI exposes only approve, transfer and transferFrom as state-changing. There is no receive, fallback, mint, burn, owner, pause, blacklist or upgrade path.
• Supply invariants. Only the internal update routine writes total supply, and both of its supply-changing branches need a zero address, which every external path rejects. Total supply can never change after construction, and the sum of balances equals it on every path.
• Launch flows. With no exemptions, taxes or hooks, the factory's transfer to the distributor, the single-sided seed through the PoolManager, claims, and trader buys and sells all move exactly the stated amount and return true. My scratch test deploys through a CREATE2 factory stand-in and confirms the 10%/80%/10% split arrives whole, the factory ends at zero, round trips are lossless, and ETH or unknown selectors are refused.
• Dependency integrity. The vendored ERC20.sol hashes byte for byte to the upstream v5.1.0 file I fetched from GitHub, and every vendored file matches DEPENDENCIES.json.
• Static-analysis lead. The aderyn large-literal note is the supply constant, which evaluates to exactly 10^27 under checked arithmetic. Not a defect.
• Existing tests. All 31 project tests pass with the verifier's fuzz seed, including the invariant suite at 128 runs of 64 calls with revert-on-failure enabled.

One non-defect trust note for the author: the standard ERC-20 allowance-replacement race exists as in every OpenZeppelin v5 token. The README already documents it, and the guides list it under design properties rather than reportable defects, so I did not record it as a finding.

Not reached: the protected floor's live Uniswap v4 seed and swap test, which needs the network's harness and pool manager that are not in this tree. Nothing in the token's code can affect its outcome, since the token has no address-dependent behaviour.

Added 15 tests covering failure paths, allowance boundaries, authorization isolation, and recovery after rejected transfers. Expanded invariants to 256 random sequences totaling 32,768 calls.

forge build and forge test pass offline with the required seed: 46 tests passed. No implementation defects found. Only test/ files changed.

The review is complete and the findings file is written. No tracked file changed.

Verdict: clean review, zero findings. All four specialists and the independent tester reported nothing, and nothing they said needed merging or dropping. My own pass with the supplied checklists found no defect either. .imd-findings.json holds an empty findings list and a coverage record of seven rows, all holds.

What the code is. src/PleaIMD.sol is a 16-line contract inheriting the vendored OpenZeppelin v5.1.0 ERC20 with no overrides. Its parameterless constructor mints one billion tokens with 18 decimals to the deployer. The ABI exposes only the standard ERC-20 functions plus a public constant.

What I verified myself:

• The five vendored OpenZeppelin files match the pinned v5.1.0 hashes byte for byte, so approve, transfer and transferFrom behave as the upstream library does. I traced each one's checks and failure paths.
• A scratch Foundry test deployed the real creation code by CREATE2 from a factory stand-in with empty constructor arguments. The whole supply sat at the factory, the swarm share, pool pull, remainder and a trader round-trip all moved exact amounts, and 22 common admin selectors reverted from both a stranger and the deployer. The deployer could not pull a holder's balance without allowance. All four tests passed, and the scratch directory was removed afterward.
• Creation code is 2,636 bytes and runtime is 1,752 bytes, far under the limits. A reachable-opcode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The manifest uses only schema keys, lowercase addresses, string-typed integers, a 7-character contract name, and a supply equal to what the constructor mints. The paired currency has code on Ethereum mainnet and returns symbol IMD with 18 decimals.
• The existing 46-test suite passes.

Leads dropped. Aderyn's large-numeric-literal note at line 11 is a style lint. The expression compiles to exactly 10^27, which the tests assert against the manifest supply. Slither reported nothing.