The pleaimd (PLEA) token is built, tested, documented and committed as commit 6b94ff6 on main.

What was delivered

• src/PleaToken.sol: a self-contained ERC-20 named PleaToken whose name() is "pleaimd" and symbol() is "PLEA", 18 decimals. The constructor takes no arguments and mints the full 1,000,000,000 PLEA once to msg.sender, which is the factory at launch. There is no owner, mint, pause, blacklist, freeze, upgrade path, receive or fallback. Holders may burn only their own tokens, so the supply can shrink but never grow. Transfers carry no fee, so the swarm share, pool seed and swaps move exactly what they say.
• test/PleaToken.t.sol: 38 tests covering metadata, supply minted to the deploying contract rather than tx.origin, transfer and transferFrom success paths, typed-error reverts for insufficient balance, insufficient allowance and zero-address targets, infinite allowance, burn, rejection of every privileged selector the launch floor probes, rejection of ether, and an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT. Five fuzz tests check supply conservation and allowance accounting.
• foundry.toml: solc pinned to 0.8.26, bytecode_hash = "none", cbor metadata off, ffi off, no fs permissions, and the verifier's fuzz seed pinned.
• lib/forge-std (v1.9.7) vendored as ordinary files with its .git removed, plus remappings.txt.
• README.md: behaviour, assumptions, the manifest values for deployment, operational responsibilities and security notes.

Verification

Check	Result
forge build (clean, empty env)	success, no warnings
forge test with the verifier's fuzz seed	38 passed, 0 failed
forge fmt --check	clean

Slither was not available on this machine and did not run. The code avoids its six rejecting patterns by construction: no selfdestruct, no delegatecall, no library calls, no upgrade or initializer, no shifts and no abi.encodePacked.

Open items for the launch are only the ones the manifest step owns: token.contract is PleaToken, constructorArgs is empty, and totalSupply is 1000000000000000000000000000. There is nothing to configure after launch, since the contract has no settable state.

I found no defects in the permissions area of src/PleaToken.sol. I wrote .imd-findings.json with an empty findings list and a coverage row for each of the six entry points, all marked holds, plus one row for the "no privileged role" invariant. The project's existing tests all pass (38 of 38).

Access Control. The contract has no owner, no modifiers and no admin functions, and the constructor takes no arguments and gives no one a role. The whole supply (10^27 minor units) goes to msg.sender once, and nothing can mint afterwards. So nothing can pause, freeze, blacklist, seize or burn a holder's tokens. burn only destroys the caller's own balance, and there is no burnFrom.

Trust Gap. Every write affects only the caller's own balance or allowances, or spends an allowance someone gave the caller (transferFrom). No function trusts a stored address or an external call: the token makes no outside calls and has no callbacks or hooks.

Asymmetry.

• transfer and transferFrom share the same internal transfer, so both reject sending to the zero address and check the balance the same way.
• increaseAllowance reverts on overflow, and decreaseAllowance reverts if you try to lower an allowance below zero, before any unchecked subtraction.
• An allowance of type(uint256).max counts as unlimited and is never reduced.
• Granting an allowance to the zero address reverts.
• transferFrom(address(0), …) can't be reached, because the zero address can never have approved anyone.

Launch flows. There is no fee, burn or exemption on transfer, so what the factory sends to the distributor, to the pool and to the remainder address arrives in full. Trades through the PoolManager move exact amounts too.

Static analysis. Aderyn's "large numeric literal" warning (line 27) is just the supply constant 1_000_000_000 * 10 ** 18, which is correct, so it isn't a defect.

Not covered. I didn't review launch.json because the tree doesn't have one yet, and I didn't run the protected floor tests here.

Created launch.json matching PleaToken, its supply and constructor, and the exact pool/economics settings.

Manifest checks and forge build passed. All 38 tests passed with the required fuzz seed. Only launch.json is included for submission.

The findings file is valid, the quoted snippet matches line 113 exactly, and the working tree is clean apart from the gitignored findings file and scratch test.

Result: no math defect that moves or loses value. One info-level inconsistency recorded.

The token at src/PleaToken.sol is a minimal fixed-supply ERC-20 with no division, multiplication, scaling, downcast or external call. Its entire arithmetic surface is four guarded subtractions in unchecked blocks, one checked addition, and the unchecked credit in the transfer path. I traced each against the Math Precision, Boundary and Numerical Gap guides.

What I verified

• Conservation invariant. The sum of all balances equals totalSupply after every writer, so the unchecked balanceOf[to] += amount and totalSupply -= amount cannot wrap. A 256-run Foundry invariant test with four actors driving random transfer, transferFrom, burn and infinite-approve calls never broke it.
• Boundaries. Zero amounts, whole-supply transfers and burns, self-transfer, self-transferFrom, a transfer of type(uint256).max, and burning everything then one more all behave as specified with typed reverts.
• The max-allowance sentinel. Reaching it via approve(max-1) then increaseAllowance(1) makes the allowance unlimited as documented. Decreasing from it by one makes it finite again and transferFrom decrements normally.
• Static-analysis lead. The aderyn large-literal note on the supply constant is style only. The constant equals 1e27 exactly and matches the manifest supply.
• Existing checks. The project's 38 tests pass and forge fmt --check is clean.

The one finding (info)

The README states every failure reverts with a typed error. The overflow path in increaseAllowance instead reverts with the compiler's Panic code 0x11. Reproduction: approve a spender for type(uint256).max, then call increaseAllowance for that spender with 1. The allowance is unchanged and no funds are at risk, so this is a documentation or error-contract mismatch, not a loss.

Coverage

All six verifier entry points have rows: five hold, and increaseAllowance points at the finding. Five extra rows record the conservation invariant, the supply constant, and each of the three guides. Nothing in my area was left unreached.

The review is complete and .imd-findings.json is written in the repository root with an empty findings list and nine coverage rows.

Outcome: no defects found in the control-flow area (Execution Trace, Periphery, First Principles) of src/PleaToken.sol.

What I checked

• All six entry points traced from call to final state: zero-address guards, balance and allowance checks, the unchecked blocks and why they cannot wrap, error argument order, and event emission. Each gets a holds row with its reason.
• Execution Trace items: the type(uint256).max allowance sentinel skips the decrement and the Approval event only, with no validation bypassed. Allowance is spent before the balance check, and a balance revert undoes the spend atomically. Self-transfer re-reads the debited slot so balances are conserved.
• First Principles items: the sum of balances equals totalSupply from the constructor onward, which is the assumption the unchecked credit in the transfer helper rests on. A stateful fuzz run over transfer, transferFrom and burn across 4 actors held it for 128,000 calls with zero reverts.
• Periphery: there are no libraries or inherited contracts. The three private helpers are reached only from the six entry points. Constants return the required name, symbol and decimals, and the supply constant equals the manifest value.
• Surface: the compiled ABI has exactly the six nonpayable functions plus views. No payable function, receive, fallback, owner, mint, pause, blacklist or burnFrom exists. The existing opcode-scan test passes.

Leads I examined and left out, since they are self-harm only or standard behaviour with no victim: approving the zero address reverts, including with amount zero, and tokens can be sent to the token's own address. The aderyn large-numeric-literal line is style only.

Scratch tests under test/scratch/ were run and then removed, so the tree is unchanged apart from the findings file.

The review of the PLEA token's economics is complete. The findings file holds an empty list and ten coverage rows, and the tree is otherwise unchanged apart from that file.

Result: no substantiated defect in the Economic Security, Invariant or Flow Gap areas. The contract at src/PleaToken.sol is a self-contained fixed-supply ERC-20 with no external calls, no fee or rate parameters, no owner, and no mint path.

What I checked and how:

• Economic Security. No oracle, token or cross-contract dependency exists to break. The token delivers exactly the amount sent for every caller, so no flow uses an assumed amount that differs from the received one. Sentinel branches (zero to, zero spender) revert rather than silently succeed. The EIP-20 approve race is documented in the code and is self-harm only, so it is not reported.
• Invariant. A 256-run handler invariant over all six entry points with seven actors (factory, distributor, pool manager, remainder, two traders, the token itself) held three properties: sum of balances equals totalSupply, totalSupply equals the initial supply minus burns, and on-chain allowances match a model. The unchecked arithmetic in burn and _transfer is guarded by the preceding balance checks and the conservation law.
• Flow Gap. A scratch probe reproduced the launch legs (10% to distributor, claim, 70% seed through a sync/settle balance delta, 20% remainder, then a buy via v4's assembly return-value check and a sell back). Every leg arrived whole and supply stayed at 1e27.
• Existing suite. All 38 project tests pass under the pinned fuzz seed.

Coverage rows mark all six entry points as holds, plus rows for the two invariants, the launch flows, and the dependency surface. The static-analysis lead (large numeric literal at line 27) is a style note: the constant evaluates to exactly the manifest supply.

Not reached: the protected Uniswap v4 floor test itself, since v4-core is not vendored here. My probe mimics its transfer and settle checks but is not the real PoolManager. No launch.json exists in the tree yet, so there was no manifest to check.

I added two test files under test/. With the verifier's fuzz seed, forge build and forge test both pass: 71 tests, 0 failing. I found nothing wrong in src/PleaToken.sol, so I didn't write .imd-findings.json.

test/PleaToken.invariant.t.sol covers the "holds value" requirement. A handler drives the token with random call sequences from five accounts, set to 256 runs of 100 calls each (about 25,600 calls per campaign). It calls transfer, approve, increase/decrease allowance, transferFrom and burn with bounded inputs, sometimes using an unlimited allowance. It also tries five calls that should fail: transferring more than the balance, spending more than the allowance, burning more than the balance, lowering an allowance below zero, and sending to the zero address. The handler keeps its own record of what every balance and allowance should be, and these must hold after every call:

• Total supply equals the initial supply minus everything burned, and never goes up.
• The five accounts' balances add up to the total supply; the token contract and the zero address hold nothing.
• Every balance and every allowance matches the handler's record. An unlimited allowance is never reduced.
• None of the calls that should fail ever succeeds.
• Name, symbol and decimals never change.

A short unit test confirms the handler really moves tokens, so the invariants can't pass just because nothing happened.

test/PleaToken.edge.t.sol adds 31 edge-case and failure-path tests beyond the existing suite:

• Self-dealing: you need an allowance to transferFrom your own balance, and a transferFrom back to the same account uses up allowance without changing the balance.
• Which check comes first: a failed transferFrom leaves the allowance unspent, and when both the allowance and the balance are short, the allowance error is reported first.
• Unlimited allowance: spending it logs only a Transfer, with no Approval event. One below the maximum behaves as a normal limited allowance. An unlimited allowance still can't move more than the owner holds.
• Rejected inputs: allowance changes for the zero address revert. Raising an allowance past the maximum fails with an overflow error.
• Supply edges: burning the whole supply works. Burns can't reach other people's balances. Nothing can be pulled out of the zero address. Ether is refused.
• Launch flow: deploying the token and moving the 10% swarm share, the pool seed and the remainder in one transaction delivers exact amounts.
• Fuzz tests: 1,000 runs each.

One harmless quirk, not reported as a defect: transferFrom(address(0), x, 0) succeeds and logs a zero-value Transfer from the zero address. Indexers usually read that as a mint, but it can never move any value.

I didn't touch src/ or any config files. The new files aren't committed yet.

Review complete. The findings file is written and validated, and no repository file was changed. Only the ignored test/scratch/ directory and the findings file were created.

Outcome: one finding kept, at info severity. The token is otherwise sound.

• Kept (info): the audit_math finding that increaseAllowance overflow reverts with the compiler's Panic code rather than a typed error, which contradicts the README's promise that all failures use a typed error. I reproduced it with a scratch Foundry test: approve the maximum allowance, then increase by one, and the revert data is Panic 0x11 with the allowance unchanged. No funds are at risk, so it stays at info.
• Dropped or merged: nothing. The other three specialists and the tester reported no findings, so there were no duplicates to merge.

My own pass found nothing further. I traced all six entry points plus the constructor and the launch invariants. Self-transfer, transferFrom from the zero address, burn underflow, the exact-maximum allowance boundary, ether rejection and creation code size all behave as documented. The manifest's empty constructor arguments and supply match the code. The project's own suite passes with 79 tests and 7 invariants, and the reachable-opcode test confirms no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Coverage: all six listed entry points answered, five hold and one carries the info finding, plus two invariant rows.