I've built the plea (PLEA) token. forge build, forge test (with the verifier's fuzz seed) and forge fmt --check all pass on solc 0.8.26, and all 13 tests pass.

• Contract: src/PleaToken.sol defines contract PleaToken, a standard OpenZeppelin v5.4.0 ERC-20. name() returns plea, symbol() returns PLEA, and decimals are 18.
• Supply: the constructor mints TOTAL_SUPPLY (1,000,000,000 × 10¹⁸) once to msg.sender, which is the factory on the launch. It takes no constructor arguments.
• No admin powers: the token has no owner and cannot mint more, pause, blacklist, freeze or seize. Transfers carry no fee, so the factory, distributor and pool transfers move exactly the amounts they state.
• Tests: test/PleaToken.t.sol checks the token's details and the initial mint, transfers and allowances, and the failure cases (too little balance or allowance, zero receiver or spender). It also checks that mint and ownership calls fail, and a fuzz test confirms transfers never change the total supply.
• Config: foundry.toml pins solc = "0.8.26" with bytecode_hash = "none" and the optimizer on, and remappings.txt maps the two libraries. forge-std v1.9.7 and OpenZeppelin v5.4.0 are copied into lib/ as ordinary files, with no submodules or .git folders. I removed everything from OpenZeppelin except its contracts/ folder and licence.
• Docs: README.md covers the deployment parameters, my assumptions and who is responsible for what. There is nothing to configure after launch.

I haven't committed anything and didn't write a launch.json. The untracked dotfiles in the repository root (.bashrc, .mcp.json and others) were already there when I started. I didn't create them, and they shouldn't go into the commit.

I found no defects in the math, boundary or numerical-gap checks for PleaToken. .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all marked holds.

What the code is: src/PleaToken.sol is a plain OpenZeppelin v5.4.0 ERC-20 with nothing overridden. It has a fixed supply of 1_000_000_000 * 10 ** 18, minted once to msg.sender in the constructor. It has no owner, no fee or burn, and no way to mint after deployment. The vendored OpenZeppelin library is unmodified.

What I checked:

• Math precision: there is no division, rounding or fee calculation anywhere. The supply constant comes out to exactly 10^27, and the decimals are 18.
• Boundaries:
  • transfer and transferFrom check the balance and the allowance before their unchecked subtractions.
  • The unchecked addition when crediting a balance can't overflow, because no balance can exceed the fixed supply of 10^27, which is far below the uint256 limit.
  • An unlimited allowance (type(uint256).max) is never reduced, and any smaller allowance goes down by exactly the amount spent.
  • Zero-value transfers, self-transfers and moving the whole supply all behave correctly.
• Numerical gaps: the total supply can't change after the constructor, since there is no mint or burn entry point.
• Tests: the project's 13 tests pass. I also wrote a throwaway Foundry test covering the edge cases above, plus a fuzz test (256 runs) checking that balances always add up to the supply. Both passed, and I deleted the test afterwards.
• Static-analysis lead: aderyn's note about a large number at src/PleaToken.sol:11 is about readability only. The value is a correct compile-time constant.

What I didn't cover: the protected launch test (Token.protected.t.sol) imports src/LaunchLiquidity.sol and other files that aren't in this tree, so I didn't run it. Those look like files the checking setup supplies. Since this token has no transfer-time logic, the launch transfers should arrive in full.

I changed no project files.

I found no defects in the permissions area of PleaToken, and I've written .imd-findings.json with an empty findings list and a coverage record.

What I reviewed: src/PleaToken.sol (17 lines) and the vendored OpenZeppelin ERC20 it inherits. The contract only sets the name, symbol and a TOTAL_SUPPLY constant of 1e27. Its constructor mints that amount once to msg.sender, which is the factory at launch. The project's 13 existing tests pass.

• Access Control: there is no owner and no access-control role, and nothing is overridden. The only callable functions are the standard ERC-20 ones, and no admin function exists to bypass.
• Trust Gap: after deployment nobody holds a privileged role. There is nothing that could pause, blacklist, freeze, take, burn or mint tokens, and the supply can never grow.
• Asymmetry: transfer and transferFrom treat every address the same, with no fee and no exemptions. Moves from the factory to the distributor, the pool seed and pool swaps all deliver exactly the amount sent. transferFrom checks and spends the allowance before moving tokens, and leaves an unlimited allowance untouched. approve only sets the caller's own allowance.

Coverage rows: all three entry points (approve, transfer, transferFrom) are marked holds. I added two invariant rows, also holds: no privileged role exists, and the supply is fixed and minted once to the deployer.

Static analysis: the one aderyn note (a large number written out at line 11) is just the supply constant, 1_000_000_000 * 10 ** 18. It's correct and not a defect. Slither reported nothing.

Limits: the manifest file (launch.json) doesn't exist yet, so I couldn't check it. I didn't run the protected launch tests, because they need floor harness files that aren't in this tree. No other contracts are in scope.

Created launch.json matching PleaToken’s constructor, exact supply, and required pool and economics values.

forge build succeeded. All 13 tests passed with the supplied fuzz seed. Manifest and compiled ABI checks passed. Only launch.json is changed.

I found no defects in the control-flow audit of PleaToken. .imd-findings.json has an empty findings list and six coverage rows marked holds: the 3 listed entry points plus 3 I added (2 invariants, 1 launch flow). No repository files changed; the findings file is git-ignored, and I deleted my scratch tests and the temporary /tmp project.

What was reviewed: the compiled token is 6 source files, confirmed from the build metadata: src/PleaToken.sol plus 5 vendored OpenZeppelin files. All 5 are byte-identical to upstream v5.4.0, so the ERC20 base is unmodified. The ABI's only state-changing functions are the 3 listed entry points.

Execution Trace

• transferFrom ordering: it spends the allowance before moving tokens, but a failed move reverts everything. A test confirmed the allowance stays intact after a failure.
• Special values:
  • A type(uint256).max allowance skips only the decrement, not the balance check.
  • from or to of address 0 reverts even at zero value.
  • A zero-value transferFrom by a stranger moves nothing and grants nothing.
• Reentrancy and stale state: there are no external calls or hooks, so stale reads, partial updates and reentrancy have no path to run.

Periphery

• Context._msgSender is plain msg.sender, with no meta-transaction forwarder.
• _update has no override, so the base contract's unchecked arithmetic stays safe.
• The constructor is the only caller of _mint, and nothing calls _burn.
• Short calldata, dirty address bits and sending ETH to the token all revert.

First Principles

• Assumptions tested: the supply equals 1e27 and the launch transfers arrive whole.
• Constructor: with no arguments, the supply went to the deploying contract when deployed through CREATE2 from a stand-in factory.
• Fuzzing: 128,000 fuzzed handler calls across 5 actors, including the token's own address, kept the supply and allowances correct. The repo's own 13 tests also pass.
• Runtime code: a re-implementation of the floor's opcode scan found no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Launch flow: on a real Uniswap v4 PoolManager, with PLEA as currency0 and as currency1, the seed, a buy and a sell all moved exact amounts. My first run failed on my own wrong assertion about v4's sign convention, and it passed once corrected.

Leads rejected

• Aderyn's large-literal line: src/PleaToken.sol:11 is a false positive; the value is exactly 1e27.
• Standard ERC-20 behaviours: these are normal or self-inflicted, so they are not defects:
  • the approve race
  • zero-value Transfer events that can be used for address poisoning
  • tokens stuck if sent to the token's own address
  • transferFrom needing an allowance even on your own balance

Not reached

• Protected floor tests: I couldn't run them because LaunchLiquidity, PoolInitializationGuard, HookFlags and the IMD_* environment aren't supplied. I used equivalent checks with a stand-in seed and no hook, built with via_ir on latest v4-core, not the deployed PoolManager.
• Off-repo launch pieces: the real ProjectFactory, MerkleDistributor, launch.json and the economics that the README states are out of reach. None of them are in this tree, so I took the README's 10/70/20 split and the IMD pairing as stated rather than checking them against the job.

I found no defects in PLEA's economics, so .imd-findings.json has an empty findings list and no proof tests. All 3 listed entry points are marked holds, plus 10 extra invariant and flow rows, and 1 row is unreached. No tracked files changed; I built outside the repo and removed the out/ and cache/ folders my builds created.

PLEA is a thin wrapper around OpenZeppelin's ERC-20, with no owner, fee, hook or external call. That rules out most of what these guides look for, so the work went into confirming it.

What I checked

I made all three guide passes myself, with no helpers.

• Dependency: the 5 OpenZeppelin files the token compiles from are byte-identical to upstream v5.4.0. Creation and runtime bytecode built against the pristine release match the repo's build. Other vendored files differ only by formatting and never compile into the token.
• Economic Security:
  • The supplied floor test passes 8 of 8 on a real v4 PoolManager, with PLEA as either pool currency against IMD, and against ETH.
  • Fuzzed buy-then-sell round trips never made a profit. 1,000 IMD came back as about 977.8 IMD after two 1.25% fees.
  • Fee, rebase, reentrancy, flash-loan, oracle and shared-cap failures have nothing to act on in this token.
• Invariant:
  • Handler fuzzing (8,192 calls) found no break in balances summing to total supply, or in allowance tracking.
  • Boundary tests also held: self-transfer, full payout, zero-value calls, max and max-1 allowance, and allowance surviving a revert.
• Flow Gap: seed, swarm, claim and swap amounts move exactly, and supply is conserved across the launch flow.
• Chain and pair claims: IMD exists on mainnet with 18 decimals, as the README says. The example's pair address has no code on Base.
• Static analysis: the large-numeric-literal lead at line 11 is style only, and the value is correct.

Behaviours I did not report as defects

• Approve race: lowering a non-zero allowance has the standard ERC-20 ordering race. Going from 100 to 50 lets a front-running spender take 150. This is inherited ERC-20 behaviour, noted in the approve row.
• Zero-value spoofing: a stranger's zero-value transferFrom emits a Transfer event and moves nothing, which ERC-20 permits.
• Tokens sent to the contract itself: they are stranded, but only the sender is harmed.
• Swap before the first buy: selling into the pool before anyone has bought moves the tick from -122067 to -887272 and spends 0 PLEA. The next 100 IMD buy got exactly the same amount as the control. Anything reading the spot price would see a wrong value until then, but this is pool behaviour, not token code.
• Unlocked remainder (a design risk, not a bug): the token doesn't lock the 20% remainder or the swarm's 10%. In one run, a buyer spent 5,000 IMD, then a 200,000,000 PLEA remainder sale took about 3,417 IMD, leaving the buyer about 1,519 IMD. Those allocations are the launch's own economics, so changing this is the requester's decision.

Limits of this review

• Stand-ins for the seed path: LaunchLiquidity, PoolInitializationGuard and HookFlags weren't supplied, so I wrote minimal replacements in /tmp. The floor results for seeding and pool initialisation rest on those, not on the real helpers. Liquidity, ticks and the 70% seed were my own derivation from the example's economics, not the deployer's actual values.
• Assumed economics: the 5,000 opening cap, 70% pool share, 1.25% fee and tick spacing of 60 come from the example manifest. The job's own economics weren't available to compare against.
• Not run: Owners.protected.t.sol, because its base OwnerChecks.sol wasn't supplied. No application contracts are deployed here, so it should have nothing to check.
• Manifest: there is no launch.json yet, so that row is unreached. The token-side inputs for it are fine: no constructor arguments, a valid contract name, bytecode_hash = "none" and the correct supply litera

Added failure-path and boundary tests, nine fuzz properties, and four stateful invariants under test/.

forge build --offline and forge test --offline pass with the supplied seed, including 32,768 invariant calls.

No implementation defects found. Existing source and configuration remain unchanged.

The review is complete. The findings file holds an empty list and an eight-row coverage record.

Verdict: no defects. The four specialists and the independent tester all reported nothing, so there was nothing to reproduce or merge. My own pass against the code confirmed the token is clean.

What I verified:

• The contract is 15 lines over unmodified OpenZeppelin. The five vendored ERC20 source files hash identically to upstream v5.4.0, so the inherited approve, transfer and transferFrom behave exactly as documented.
• Launch floor replayed locally. A scratch test deployed the token by CREATE2 from a factory stand-in. The full supply landed at the factory, metadata matched, the 10% flow moved whole through a distributor to a claimant, 22 admin selectors reverted from both a stranger and the deployer, and the reachable-opcode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT. Bytecode sizes sit far under both limits.
• Manifest matches the code. Empty constructor arguments for a no-arg constructor, totalSupply equal to the minted amount, consistent name, symbol and decimals, and no extra keys.
• Static-analysis lead dropped. Aderyn's large-numeric-literal line points at the supply constant, whose value equals the manifest exactly.
• Project suite passes. All 53 existing tests, including the 256-run invariant campaign, pass on this tree.

Coverage rows answer all three ABI entry points as holds, plus five invariant rows covering the constructor mint, supply immutability, opcode and size limits, the manifest and dependency integrity. The scratch test was removed, so the only file written is the findings file.