Implemented Pleaimd (PLEA): 1 billion tokens, 18 decimals, minted once to the deployer. Standard ERC-20 behavior with no taxes or administrative controls.

Vendored dependencies and documented deployment parameters and responsibilities.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 27 tests, using the specified fuzz seed.
• forge fmt --check passed.

Created launch.json matching Pleaimd’s constructor, exact supply, pool settings, and economics.

forge build succeeded; all 27 local tests passed with the supplied fuzz seed. Only launch.json is included in the deliverable changes.

The review is complete. The economics audit found no defects, and the findings file records an empty list with nine coverage rows.

What was reviewed. The token in src/Pleaimd.sol is an unmodified OpenZeppelin v5.1.0 ERC20 with one constructor mint of exactly 10^27 base units to the deployer. I checked it against the Economic Security, Invariant and Flow Gap guides, plus the launch floor in the protected harness.

What holds, with evidence.

• All three entry points behave as plain ERC-20: exact delivery, no fee, burn, tax, exemption list or external call. Reverts are atomic with ERC-6093 errors.
• Supply cannot grow or be moved by a privileged hand. The ABI exposes no mint, burn, owner, pause, blacklist or upgrade function, and fourteen common admin selectors called from the factory all revert.
• Launch flows arrive whole: ten percent to the distributor and on to a claimant, twenty percent pulled by a manager-style transferFrom, seventy percent to the requester, then a buy and sell round trip, with supply conserved throughout.
• The compiled runtime contains no reachable DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or STATICCALL, has no receive or fallback, and is under the EIP-170 size limit.
• The five vendored OpenZeppelin files are byte-identical to the v5.1.0 release.
• The project's own 27 tests, including the 128-run invariant suite, pass under the pinned fuzz seed, and formatting is clean.

Not a defect, noted for the author. Tokens sent to the token contract's own address are accepted and unrecoverable. This is standard ERC-20 behaviour and the README already documents it.

Out of reach. The real Uniswap v4 seed and swap cannot be run here because v4-core is not vendored. The protected harness covers that at launch verification. No launch.json exists yet in this tree, so the only manifest facts checkable now are empty constructor arguments and the supply of 10^27.

The scratch test was removed after running, so no tracked file changed.

The review is complete. The findings file at the repository root holds an empty finding list and a six-row coverage record, and the working tree is otherwise unchanged.

Result: no defects in the permissions area. Pleaimd is a bare OpenZeppelin v5.1.0 ERC20 with no owner, no modifiers, no initializer, and no privileged selectors. The three entry points are all unprivileged and scoped to the caller.

What I verified:

• Permission map is empty. The compiled ABI exposes only the constructor, a public constant, six view functions, approve, transfer and transferFrom. There is no receive or fallback, and probes for owner, mint, burn, pause, blacklist, freeze, initialize and transferOwnership all revert from both the deployer and an attacker.
• No inconsistent guards. Balances are written only through the inherited update path reached by transfer, transferFrom and the constructor. Allowances are written only by approve and by allowance spending, both keyed on the caller. No writer has a weaker guard than another.
• Deployer has no bypass. With a holder funded, the deployer's transferFrom reverts with insufficient allowance, and the holder can still transfer after every privileged-selector probe. An attacker approving a spender writes only the attacker's own row.
• No asymmetry between branches. transfer and transferFrom share one update path with no exempt, tax, or caller-class branch. Trust-gap seams need a privileged actor and none exists.
• Base contract is genuine. All five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag, so nothing hidden is inherited.
• Static-analysis lead about the large numeric literal is the supply constant, which equals the documented 10^27 base units. It is style only.

Checks run: the existing 27 project tests plus a five-test scratch probe suite, all passing. The scratch tests were removed afterwards. No launch.json exists in the tree yet, so manifest review was not applicable.

Review complete. No defects found. The findings file holds an empty list and a nine-row coverage record, and the working tree is otherwise clean (git status shows only the ignored outputs; the scratch test was removed).

What the code is. src/Pleaimd.sol is a 15-line wrapper over unmodified OpenZeppelin v5.1.0 ERC20. The constructor mints 1e27 units to msg.sender once, takes no arguments and no value, and nothing else is overridden. The only state-changing entry points are approve, transfer and transferFrom.

What I checked in my area.

• Execution Trace: traced each entry point through the vendored ERC20. Zero-address sentinels revert on both sender and receiver, balance underflow is checked before the unchecked writes, transferFrom spends allowance and moves balance in one frame so a revert restores both, and the max-allowance branch behaves as documented. Allowance residuals after a revert and the max-minus-one case were exercised in a scratch test.
• Periphery: diffed every vendored OpenZeppelin file and its LICENSE against the upstream v5.1.0 tag. All byte-identical. No delegatecall, callcode or selfdestruct in source or in the reachable runtime, confirmed by replicating the protected harness opcode walk.
• First Principles: the deployer assumption holds under CREATE2 from a factory contract (supply lands on the factory, not tx.origin). Decimals, name, symbol and supply match the stated manifest values. There is no path that changes supply after construction in either direction, since burns to the zero address revert.

Other checks. Build, forge fmt --check and the project's 27 tests pass with the README's fuzz seed. A scratch test reproduced the launch flows (10% to distributor, 20% to pool, 70% to the requester address, then a claim) and every amount arrived whole. The aderyn large-numeric-literal lead is style only and was not reported.

Not reached. The Uniswap v4 seed and swap in the protected harness need v4-core and launch helpers that are not in this repository, so I could not run them locally. A plain ERC20 with no transfer hooks gives no mechanism for those to fail, but that remains the verifier's run to confirm.

Nothing remains to request. The findings file is written and valid, the scratch directory is removed, and the working tree holds nothing else. The review is complete.

The math audit of the Pleaimd (PLEA) token found no defects. The findings file at .imd-findings.json holds an empty findings list and eight coverage rows, all marked holds.

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

• Supply constant is exactly 10^27 base units. The literal compiles to a constant with no runtime arithmetic, and that constant appears in the bytecode. It fits in both uint128 and int128, so Uniswap v4 balance deltas cannot overflow for any launch flow.
• transfer and transferFrom inherit OpenZeppelin v5.1.0 unchanged. The unchecked subtraction and addition only run after the balance and allowance checks, so no wrap is reachable. Scratch tests exercised amounts of zero, the full supply, supply plus one, and max uint, plus self-transfers and self-transferFrom.
• Allowance boundaries behave as documented. Only an allowance of exactly max uint is infinite. Max minus one is decremented. A revert on balance or receiver restores the allowance atomically.
• approve is a pure storage overwrite with no arithmetic. Zero spender reverts.
• Boundary guide steps found nothing to enumerate. The compiled ABI exposes only the ERC-20 surface plus the supply constant. There is no external call, no payable function, no receive or fallback, no bytes decoding, and no sentinel branch that performs a mint or burn.
• Vendored dependencies match upstream OpenZeppelin v5.1.0 byte for byte. I compared sha256 hashes of all five files against the raw files at the release tag.
• Static analysis lead about the large numeric literal is a style note only. The value evaluates exactly and is not a defect.

Test results:

Suite	Result
Project tests (26 unit and fuzz, 1 invariant)	all passed
Scratch edge tests (10, including two 1000-run fuzzes)	all passed

Coverage rows were written for all three listed entry points, the constructor, and four invariants. No files in the repository were changed. The scratch test directory and temporary download directories were deleted.

Completed changes only under test/, adding failure-path and fuzz tests and strengthening stateful invariants.

Validation passed with the required seed:

• forge build
• All 43 tests
• 24,576 randomized invariant calls

No defects found. Live Uniswap v4 integration was not run locally; that remains covered by the external launch harness.

The review is complete. The findings file is valid JSON and no tracked file was changed.

Result: no defects. Pleaimd is an unmodified OpenZeppelin v5.1.0 ERC-20 with a zero-argument constructor that mints exactly the manifest supply to msg.sender. All four specialists reported nothing, and I confirmed that by reproduction rather than by agreement.

What I verified:

• The three entry points approve, transfer and transferFrom are the stock OpenZeppelin implementations. I traced each path by hand, including the zero-address, insufficient-balance and insufficient-allowance reverts, and the unlimited-allowance case.
• Vendored dependency integrity. All five OpenZeppelin files in lib are byte-identical to the upstream v5.1.0 tag.
• Launch floor. No reachable DELEGATECALL, CALLCODE or SELFDESTRUCT in the compiled runtime. Creation and runtime sizes are far under the protocol limits. No mint, owner, pause, blacklist or initialize function exists in the ABI, so no privileged call can grow the supply or freeze a holder.
• Deployability. The constructor needs nothing the manifest does not give, so a CREATE2 deploy at any salt succeeds.
• Manifest. launch.json uses only schema keys, has lowercase addresses, and its name, symbol, decimals, contract name and totalSupply all match the compiled contract.
• Project tests. All 43 tests pass with the documented fuzz seed.

The aderyn large-numeric-literal lead is a style note. The literal evaluates to the correct supply, so it is not a defect.

The coverage record in .imd-findings.json answers all three entry points as holds, plus five invariant rows covering fixed supply, deployability, opcode safety, dependency integrity and manifest consistency.