The pleaimd (PLEA) token is implemented, tested, documented and committed at the repository root as a Foundry project.

What was built

• src/PleaToken.sol is a plain OpenZeppelin v5.4.0 ERC20 whose constructor mints the whole supply once to the deployer. It takes no constructor arguments, makes no external calls, and has no owner, mint, burn, pause, blacklist, fee or upgrade path.
• Name is pleaimd, symbol PLEA, 18 decimals, supply 1,000,000,000 tokens. The Solidity contract name PleaToken is 9 characters, well under the launch's 32-character limit.
• script/DeployPleaToken.s.sol is a local deployment script whose deploy() function is tested directly and reads no environment.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", enables the optimizer, and leaves ffi off with no filesystem permissions.
• forge-std v1.9.7 and the OpenZeppelin token, utils and interfaces trees are vendored as ordinary files under lib/, with no git submodule.
• README.md documents behaviour, assumptions, the expected manifest token fields, that nothing needs setting after launch, operational responsibilities, and security notes.

Checks run locally

Check	Result
forge build	passes
forge test with the verifier's fuzz seed	43 passed, 0 failed
forge test with an empty environment	43 passed, 0 failed
forge fmt --check	passes

The tests cover metadata, the one-time mint and its events, transfer and transferFrom success and failure paths with exact OpenZeppelin custom errors, allowance handling including the infinite-allowance case, rejection of every common mint and admin selector, a bytecode walk confirming no DELEGATECALL, CALLCODE or SELFDESTRUCT, and a launch-flow suite that deploys via CREATE2 from a factory stand-in and checks the 10/70/20 split arrives whole. Fuzz tests check supply conservation and over-balance and over-allowance reverts.

Not done here

Slither is not available on this machine, so it was not run. The design avoids its six hard-fail detectors. No manifest was written, as the brief directs.

I found no defects in my area (Execution Trace, Periphery, First Principles). .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds. I changed no repository files.

What the code is: src/PleaToken.sol is a plain token built on OpenZeppelin's standard ERC20 (v5.4.0). It doesn't override any of the library's functions and adds no hooks. Its constructor takes no arguments, makes no outside calls, and mints 1,000,000,000 × 10^18 tokens once to the deployer. I compiled the contract's function list: it has only the standard ERC20 functions and four constant getters. There is no mint, burn, owner, pause, upgrade, receive or fallback function. The vendored OpenZeppelin copy has no local changes.

What I checked:

• Execution Trace:
  • transfer: it rejects a zero sender or recipient, rejects a balance that is too low, and moves exactly the amount asked. So the factory → distributor, distributor → claimant and PoolManager flows arrive whole.
  • transferFrom: it rejects a spend above the allowance and leaves an unlimited (maximum) allowance untouched.
  • approve: it rejects a zero owner or spender. There are no external calls or callbacks anywhere, so nothing can re-enter.
• Periphery: nothing deploys alongside the token, and the deploy script only creates it.
• First Principles:
  • Supply can't grow: the constructor's mint is the only one.
  • No privileged power: no one can freeze or move a holder's balance.
  • Decimals: they are 18, as stated.
  • Exact transfers: nothing takes a fee or burns on transfer, so seeding the pool and swapping both ways should work.
• Static-analysis lead: aderyn flagged the large number at src/PleaToken.sol:26. It works out to 1e27, which matches the stated supply, so it's a style note, not a defect.
• Tests: forge test passes all 43 tests. I couldn't run the two supplied launch checks here: they need launch settings this machine doesn't have and contracts that aren't in this tree.

Known risk, not a defect: the usual ERC20 approve race exists here as in every standard token. Someone holding an allowance can spend the old amount before a change lands. It is standard behaviour, so I didn't report it.

Done. launch.json is written and is the only change in the tree.

What the manifest says

• Kind custom_token, token contract PleaToken with name pleaimd, symbol PLEA, 18 decimals, empty constructorArgs and totalSupply equal to the one billion tokens the constructor mints to msg.sender.
• An empty contracts list, since the accepted tree contains only the token and no application contracts.
• The pool block as the launch fixes it: IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 as the paired currency, fee 12500, tick spacing 60, and the one-to-one sqrtPriceX96 as provenance.
• The requester's economics object copied verbatim.
• Notes describing the token's fixed supply, lack of any admin path, untaxed transfers, and the absence of application contracts or initialization calls.

Checks

• forge build compiles cleanly on solc 0.8.26.
• forge test with the verifier's fuzz seed passes all 43 tests across the three suites.
• A scratch check confirmed the manifest parses, uses only the schema's top-level keys, matches the compiled ABI's zero constructor parameters, and keeps notes under the limit.
• git status shows launch.json as the only new or changed file.

I added random-sequence (invariant) tests and edge-case tests for PleaToken. I found no defects, so there's no .imd-findings.json. With the verifier's fuzz seed, forge test passes all 58 tests across 5 test files.

What I found: src/PleaToken.sol is a plain OpenZeppelin ERC-20. Its constructor mints 1,000,000,000 × 10¹⁸ to the deployer once. It has no owner, no second way to mint, no pause, no fee and no burn. The tests already in the repo cover the basic behaviour, the failure paths and the launch payout steps, but had no invariant tests. I added two files:

• test/PleaTokenInvariant.t.sol: a helper contract makes random calls with five accounts: transfer, approve, transferFrom, a transfer to the zero address, and a pull by an account with no allowance. Each call is bounded so it sometimes goes one wei past the balance or allowance, so success and failure both get exercised. Each expected failure must revert with OpenZeppelin's exact error. A separate record of balances and allowances is updated only from the call inputs, not from what the token reports. After every sequence these must hold:

  • total supply stays at 1e27, and the five accounts' balances add up to it;
  • the zero address, the account with no allowance and the token contract itself hold nothing;
  • every balance and allowance matches the separate record;
  • every successful call returned true;
  • name, symbol and decimals stay fixed.

  It ran 256 runs × 64 calls (16,384 calls), with zero unexpected reverts and no inputs thrown away.

• test/PleaTokenEdges.t.sol: cases the existing tests didn't pin down:

  • the zero address can neither send (even 0) nor approve;
  • transfer of type(uint256).max and of the full supply plus one both revert;
  • an unlimited allowance is still limited by the owner's balance;
  • an owner calling transferFrom on their own balance still needs an allowance;
  • pulling 0 needs no allowance;
  • approving 0 revokes an allowance;
  • repeating a transfer after the balance is spent fails.

  It also has three fuzz tests (1,000 runs each): sending to yourself, a there-and-back transfer, and an allowance spent in two pulls.

One behaviour worth knowing, not a defect: tokens sent to the token's own address are accepted and can never be moved out, which is standard ERC-20. I wrote a test for it so any change shows up.

Not committed: this machine has no git user name or email, and I didn't set one. Both files are staged but not committed. If the upload needs a commit, someone with a git identity has to make it.

I didn't run the two protected launch tests in .imd/reads/protected/custom_token/. They need the verifier's environment settings and Uniswap v4 sources that aren't in this repo.

The permissions review is complete and the findings file is written. The tree is otherwise unchanged (the scratch test was removed and the findings file is git-ignored by the harness).

Outcome: no defects in the permission model. PleaToken is a plain OpenZeppelin v5.4.0 ERC20 with a single constructor mint. The only finding is an informational note, not a fix request.

What I checked, across the Access Control, Trust Gap and Asymmetry guides:

• Permission map: no roles, owner, initializer, upgrade path, pause, blacklist or burn. The compiled ABI exposes exactly approve, transfer and transferFrom as state-changing selectors.
• Constructor hands out no persistent privilege. It mints exactly the manifest supply to the factory via CREATE2 and takes no arguments, so no exempt list can be misconfigured.
• Confused deputy: Context is unmodified, so transferFrom authorises against the real caller. The deployer cannot pull from a holder without approval.
• Asymmetry: transfer and transferFrom share the same _transfer/_update path. The mint and burn internals are unreachable after construction.
• Vendored library integrity: ERC20.sol, Context.sol and the three interfaces are byte-identical to upstream v5.4.0. Storage layout is the standard five slots.
• Runtime bytecode: no DELEGATECALL, CALLCODE or SELFDESTRUCT on reachable paths.
• Build, the 43 project tests, the formatter check and the verifier-seeded fuzz run all pass.

The one recorded item (info): the standard ERC-20 approve race. A spender who front-runs a holder lowering an allowance from 100 to 50 can move 150. I reproduced it in a scratch test. It is inherent to the agreed plain-ERC20 design, so I recommend no code change, only the operational advice to approve zero before setting a new value.

Static-analysis leads: Slither reported nothing. Aderyn's large-literal note on line 26 is stylistic. The constant evaluates to exactly 1e27, which matches the brief.

Not reviewable: launch.json is not yet in the tree, as the README states. The README's intended manifest values match the code.

Coverage record: all three listed entry points marked holds, plus six invariant rows (constructor, no admin surface, library integrity, fixed supply, manifest, deploy script).

The math review of PleaToken found no defects. The findings file is written with an empty findings list and eight coverage rows, and the working tree is otherwise untouched.

What the token is. src/PleaToken.sol is a bare OpenZeppelin v5.4.0 ERC20 with one constructor mint of the whole supply to the deployer. It has no fee, burn, owner, pause, external call, payable path, receive or fallback. All arithmetic that moves value lives in the vendored library.

What I checked, per guide:

• Math Precision. The supply constant evaluates to exactly 10^27, which also resolves the aderyn large-literal lead. The only unchecked blocks are OpenZeppelin's, each preceded by a checked bound. Self-transfers over the full range 0 to 10^27 leave the balance unchanged. Allowance at max is never decremented, and at max minus one it is decremented exactly. The supply fits in int128, so a Uniswap v4 balance delta cannot truncate it.
• Boundary. There are no external call sites, payable functions, bytes decoding or sentinel branches other than the library's zero-address reverts. Max-uint and supply-plus-one transfers revert with the expected insufficient-balance error. A transferFrom from the zero address reverts, so no mint path exists through it.
• Numerical Gap. The conservation invariant holds under an 8-step random-transfer fuzz among four parties. The launch split of 10%, 70% and 20% divides 10^27 with zero remainder.

Verification steps. All five vendored OpenZeppelin files hash identically to the files at upstream tag v5.4.0. The existing 43-test suite passes, including with the verifier's fuzz seed. My scratch probes passed except one whose expectation I had written wrong, and that case still reverts correctly. The scratch directory has been removed.

Not covered. Nothing in my area was left unreached. The three ABI entry points and the constructor each have a coverage row, plus rows for the conservation invariant, the launch split arithmetic, the boundary inventory and the dependency integrity check.

The review found no defects in PLEA's economics. The findings file is written with an empty list and ten coverage rows, and no tracked file changed.

What was checked, against the Economic Security, Invariant and Flow Gap guides:

• Conservation and supply fixity. The only mint is in the constructor at src/PleaToken.sol:35. No burn, mint, owner, pause or upgrade selector exists in the compiled ABI, and transfers to the zero address revert, so supply can neither grow nor shrink. A stateful invariant test with random transfers, approvals and transferFroms kept the sum of balances equal to the fixed supply across 64 runs of depth 64.
• Launch flows. The 10% swarm share, 70% pool seed and 20% requester remainder all arrive whole. A trader buy and sell through a Uniswap v4 style balance-delta settle sees received amounts equal to claimed amounts. The claim from the distributor is exact.
• Economic dependencies and token misbehavior. The token has no fees, hooks, exemptions, external calls or sentinel paths. The compiled runtime and creation code contain no CALL, CREATE, DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes.
• Library integrity. The five vendored OpenZeppelin files the token imports are byte-identical to upstream v5.4.0. The two vendored files containing delegatecall are not imported.
• Trust assumptions. Whoever deploys receives the whole supply. In the launch that is the factory by CREATE2 construction. No privileged role survives deployment. The ERC-20 approve race and infinite allowance are inherent to the standard and documented in the README.

Not reached: the real v4-core protected harness could not be run locally because v4-core is not vendored here. Its flows were reproduced with a balance-delta stand-in, and the token has no code path that could make a delta differ. The scratch test is in test/scratch/EconomicsReview.t.sol, which is gitignored and not submitted.

Review is complete and .imd-findings.json is written. The tree is otherwise unchanged (scratch test removed, git status clean).

Outcome: no defects. The token is an unmodified OpenZeppelin v5.4.0 ERC20 with a one-time constructor mint, and every check I ran against it holds.

Specialist findings settled

• The one finding, from the permissions specialist, is the standard ERC-20 approve race when a holder lowers an allowance. I reproduced it with a scratch Foundry test: the spender ends with 150e18 after a 100e18 then 50e18 approval. It is inherent to the agreed plain-ERC20 design, so I kept it at info as a holder trust note that does not block the launch. The other three specialists and the tester reported nothing, so there was nothing to merge.

My own pass

• All five vendored OpenZeppelin files the token compiles against hash identically to the upstream v5.4.0 tag.
• The constant supply equals the manifest's totalSupply exactly, is minted once to msg.sender, and the ABI exposes no mint, owner, pause or burn selector. Decimals match the manifest.
• A reachable-opcode walk of the compiled runtime finds no DELEGATECALL, CALLCODE, SELFDESTRUCT or any external call. Creation and runtime sizes are far under the limits, so the CREATE2 deployment with an empty argument list works.
• The full existing suite passes, including the invariant run and the launch-flow test with a CREATE2 factory stand-in.
• The manifest uses only schema keys, lowercase addresses and correct types, with an empty constructorArgs list matching the zero-parameter constructor.
• Static analysis leads: slither had nothing. Aderyn's large-numeric-literal line is the supply constant written with underscores and a power of ten, which is correct, so it is not reported.

Coverage: all three entry points answered holds, plus four invariant rows for the supply mint, bytecode, vendored sources and manifest.