The plea (PLEA) token is built, tested, documented and committed as commit 8612830 on main.

What was delivered

• src/PleaToken.sol is a self-contained fixed-supply ERC-20. The constructor mints 1,000,000,000 PLEA with 18 decimals to msg.sender once and emits the mint Transfer. There is no owner, mint, burn, pause, blocklist, proxy, fallback or receive, and transfers carry no fee, so the launch flows the protected floor exercises move exactly what they say.
• foundry.toml pins solc = "0.8.26", sets bytecode_hash = "none", leaves ffi off and grants no filesystem permissions. forge-std v1.9.6 is vendored under lib/forge-std as ordinary files with its git metadata stripped, so no submodule and no network is needed.
• README.md documents the token's behaviour, the launch parameters as given, the assumptions made, operational responsibilities after launch, and the security checklist items that apply.

Verification

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

The tests cover metadata and supply, the mint to both an EOA and a contract deployer with the factory paying out whole, every transfer, approve and transferFrom success path with events, every revert path with its exact custom error, the absence of mint, admin, pause and freeze entry points from a stranger and from the deployer, ETH and unknown-call rejection, an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, five fuzz tests, and a handler-driven invariant suite checking constant supply, balances summing to supply and no stray balances.

Not run. Slither is not available on this machine, so it was not run. The code avoids the patterns its blocking detectors flag, and the README says so. The commit was authored under the workspace's existing identity because no git identity was configured here.

Created launch.json with the accepted PleaToken metadata, exact supply, empty constructor arguments, and required pool and economics values.

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

I found no defects in my area: the economic-security, invariant and flow-gap review of src/PleaToken.sol. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds.

What I checked:

• Supply and conservation: only the constructor sets balances, crediting exactly 1,000,000,000 × 10^18 to the deployer. There is no mint, burn, owner, pause, blocklist, proxy, receive or fallback. The unchecked addition in _transfer can't overflow because the sum of all balances never exceeds that fixed supply.
• Launch flows: transfers charge no fee, burn or tax, and no address gets special treatment. The factory's transfer to the distributor, the claim payouts, the pool seed through the PoolManager and later trades all move exactly the amount stated, so the token doesn't need any constructor arguments to exempt launch addresses.
• transferFrom: the allowance is checked before the unchecked subtraction, and an unlimited (type(uint256).max) allowance is never reduced. Sending to yourself, or a holder acting as their own spender, leaves both the balance and the allowance correct.
• Edge cases: I looked at zero amounts, zero-address receivers and spenders, overspending, and ETH sent to the contract. Each either reverts or does nothing.
• Known ERC-20 quirks: two standard behaviours don't amount to findings:
  • Allowance overwrite race: approve replaces an allowance rather than adding to it, so a spender can use the old allowance and then the new one. This is standard ERC-20 and the code's comments document it.
  • Zero-value call: anyone can call transferFrom(address(0), x, 0). It succeeds, moves nothing and only emits a zero-value Transfer event.
• Static analysis: the one tool warning (a large number written out at line 29) is just the supply constant and isn't a defect.

Tests: all 36 existing tests pass, including the invariant suite. I also wrote fuzz tests in test/scratch/ for self-transfers, exact delivery, allowance accounting, rejection of overspending and invalid calls, and a 10% distributor flow. All passed, and I deleted them afterwards, so .imd-findings.json is the only file I created.

Not covered:

• I couldn't run the supplied launch tests (Token.protected.t.sol and Owners.protected.t.sol). They need src/LaunchLiquidity.sol, PoolInitializationGuard, HookFlags and floor/OwnerChecks.sol, which aren't in this tree, so the Uniswap v4 seed-and-swap check wasn't executed. I reached that conclusion by reading the code instead.
• I did confirm that the pair token address the README gives (0xd34a…63b7) holds a contract with symbol IMD on chain 1, the chain the README names.

I found no defects I can back up with a failing input in src/PleaToken.sol, the only production file. .imd-findings.json contains {"findings":[]} and coverage rows for all three entry points, plus two rows for the supply and "no privileged hand" invariants.

What I checked, guide by guide:

• Execution Trace:
  • transfer: it rejects a transfer to the zero address or for more than the sender's balance before it writes anything.
  • transferFrom: it checks the allowance before reducing it. An allowance of type(uint256).max means unlimited and is never reduced.
  • Arithmetic and reverts: balanceOf[to] += amount skips overflow checks, but the sum of all balances is fixed at 1e27, so it can't overflow. A failed transfer reverts the whole call, including the allowance change.
  • Edge cases: sending to yourself leaves your balance unchanged, and zero-amount transfers work on both functions. I fuzzed both in a scratch test, which I then deleted.
• Periphery: The contract makes no external calls and has no hooks, receive or fallback; sending it ETH or an unknown function call reverts. There is no fee or burn on transfer, so all four launch flows move exactly the stated amount: the factory paying the distributor, distributor claims, the pool seed, and swaps through the pool manager. The constructor takes no arguments, which matches the README's constructorArgs: [] and the plan to take no exemptions.
• First Principles: The whole supply of 1,000,000,000 × 10¹⁸ is minted once, to the deployer (the factory, which deploys it at a precomputed address). Nothing can mint more: there is no mint, burn, owner, pause, blocklist or upgrade path, and no assembly. Decimals is the constant 18.

Checks run: the repository's own tests (35 unit tests and an invariant suite of 2,048 calls) and my scratch edge-case tests all passed, 42 in total. I did not run the protected launch test (Token.protected.t.sol): it needs the floor harness and environment variables, and this tree has neither.

Static analysis:

• slither: reported nothing.
• aderyn: its one low note, a large number written out at line 29, is just the supply constant and not a defect.

Not reported: transferFrom(address(0), to, 0) succeeds and emits a zero-value Transfer event from the zero address. It moves nothing, so I left it out as harmless. Other contracts and checks were out of reach: there are no application contracts, and no launch.json exists yet.

I found no math, boundary or numerical defects in the PLEA token (src/PleaToken.sol), so the findings list in .imd-findings.json is empty. All three entry points (approve, transfer, transferFrom) are marked holds, along with two invariant rows. No repository files were changed; I deleted my scratch test file afterwards.

Coverage. I checked the contract against the Math Precision, Boundary and Numerical Gap guides from the Pashov reference:

• Math Precision: the contract has no division, scaling, downcast or rounding. The total supply constant works out to exactly 10^27 (1,000,000,000 with 18 decimals), which matches the brief and decimals() = 18.
• Unchecked arithmetic: both unchecked subtractions are guarded by a check just before them, so they can't underflow. The unchecked balanceOf[to] += amount can't overflow because all balances always add up to the fixed 10^27 supply.
• Boundary: I tested amounts of 0, the whole balance, and one more than the balance (it reverts). I also tested allowances at the maximum (treated as unlimited, never reduced), maximum minus 1 (reduced normally to maximum minus 2), exactly enough, and one short (it reverts). The contract makes no external calls and has no payable functions or input decoding.
• Numerical Gap: sending to yourself, including through transferFrom where the spender, sender and receiver are the same address, leaves the balance unchanged and reduces the allowance correctly. Zero-amount transfers can't break the supply total.

Tests. The project's own 43 tests pass, including the invariant suite (64 runs, 2,048 calls, no reverts). My extra fuzz tests covering the cases above also passed.

Static analysis. Aderyn's only flag, a large number in the supply constant at line 29, is a style warning. The value is correct, so I didn't report it.

Not reported: anyone can call transferFrom(address(0), x, 0) and transferFrom(victim, x, 0) without an allowance. That emits a Transfer event worth 0 tokens, which can look like a mint to block explorers or be used for address-poisoning spam. This is allowed by the ERC-20 standard and changes no state. One difference: OpenZeppelin's version rejects a sender of address(0), and this contract doesn't. I left it out because it isn't a defect that can be reproduced.

Outside my area: I skimmed access control and the launch flow. The contract has no owner and no way to mint, pause or freeze, and nothing is charged on transfers, so the factory, distributor and pool transfers arrive in full. I didn't run the launch harness tests, because they need the launch's environment variables and contracts that aren't in this tree.

I added test/PleaToken.model.t.sol and left the earlier contributors' tests untouched. forge build succeeds and forge test with the verifier's seed passes all 50 tests (36 existing, 14 new), with 0 reverts in either invariant run.

What the new file adds:

• Model-based invariant tests (256 runs, depth 64, set inline in the file): the test handler keeps its own copy of every balance and allowance across five holders, including the token's own address. After every random call sequence the tests check three things:
  • every balance and allowance matches that copy;
  • balances add up to exactly 1,000,000,000 × 10¹⁸ and the supply never changes;
  • nothing ends up at addresses outside the five holders.
• Failing calls inside the random sequences: sending more than you hold, sending to the zero address, approving the zero address, spending past an allowance, and spending within an allowance but past the owner's balance. Each must fail with the exact error and values and change nothing; in particular, a failed transferFrom must not use up the allowance.
• Edge-case unit tests:
  • the launch payout (10% to the distributor, paid out to claimants down to the last unit, then the pool share and the remainder);
  • an unlimited allowance is still limited by the owner's balance;
  • an allowance of max − 1 counts down like any other;
  • a holder needs an allowance to transferFrom their own tokens;
  • transferFrom from an owner to themselves keeps the balance but still uses the allowance;
  • a zero-amount transferFrom works without an allowance;
  • nobody can pull tokens from the zero address;
  • a zero-amount transfer to the zero address is refused;
  • tokens sent to the token contract stay there.
• Fuzz tests (1000 runs each): a token passed along two holders keeps the total intact; a failed over-balance transferFrom leaves the allowance alone; repeated spending never goes past the approved amount.

No defects found. src/PleaToken.sol is a plain fixed-supply ERC-20 with no owner or admin functions, no fees and no mint after deployment. Every property I tested holds, so there was nothing to report and I didn't create .imd-findings.json. I installed no dependencies and made no commits.

Review complete. The findings file is written and validated, and the scratch tests are removed. Git status is clean apart from the ignored findings file.

Outcome. The permissions audit of src/PleaToken.sol found one low-severity defect and no access-control, trust-gap or privilege issue. The contract has no owner, no modifier, no initializer, no external call and no receive or fallback. The compiled ABI confirms the only state-changing entry points are approve, transfer and transferFrom.

Finding 1 (low). The internal transfer helper rejects a zero receiver but never checks the sender. Through transferFrom, any account can pass the zero address as the sender with a zero amount. The allowance from the zero address is always zero, and a zero-value transfer needs only a zero allowance, so the call succeeds and emits a Transfer event from the zero address. That is the exact event shape the contract documents as the constructor mint. Balances and supply are untouched, so the harm is limited to indexers or airdrop scripts that classify such logs as mints. OpenZeppelin rejects this case with an invalid-sender error. The minimal fix is a mirror check on the sender at the top of the transfer helper. I reproduced it with a Foundry test that fails on the current code and would pass with that check.

Coverage. Seven rows are recorded. The three listed entry points and the constructor are each traced. approve and transfer hold. transferFrom carries the finding. Three invariant rows cover the Access Control, Trust Gap and Asymmetry passes, with the Asymmetry row pointing to the same finding. I also verified by test that a max allowance still enforces balance, that max minus one is decremented, that allowances are per spender, and that self-transfer through an allowance does not double-count.

Not reached. Nothing in the assigned area was left unverified. The existing test suite passes, with every test and the invariant run green. Items outside my area such as pool seeding and the manifest were not examined, since no manifest exists yet in this tree and the token takes no constructor arguments.

Review complete. The findings file is written at .imd-findings.json with one finding and eight coverage rows. No repository files were changed. The scratch directory was removed after use.

Outcome: PleaToken is a 136-line self-contained fixed-supply ERC-20 with no owner, mint, burn, pause or external call. The project's own suite of 50 tests, including the invariant suite, passes. One specialist finding was kept at low severity. Nothing was found that affects funds, launch flows or the protected floor.

Finding kept (low): _transfer in src/PleaToken.sol checks the receiver but not the sender. Because approve only ever writes the caller's own allowance row, the allowance from the zero address is always zero, so an unprivileged caller can run transferFrom(address(0), self, 0) and emit a mint-shaped Transfer(0x0, self, 0) event. Balances, allowances and supply do not change. The impact is confined to off-chain indexers that treat zero-sender transfers as mints. I reproduced it two ways:

• A scratch test with vm.recordLogs confirmed exactly one Transfer log with sender zero and value zero, and that a non-zero amount reverts with InsufficientAllowance.
• The attached proof test asserts the call reverts. It fails on the current code and passes once _transfer rejects a zero sender, which is the minimal fix.

Specialists: permissions reported this one finding, and economics, flow, math and the tester reported none, so there were no duplicates to merge. The aderyn large-literal lead is a compile-time constant that the project test confirms equals 1e27, so it was dropped.

Coverage: all three entry points answered. approve and transfer hold. transferFrom carries finding 1. Additional rows record the constant supply, the argument-free constructor mint matching launch.json, the absence of privileged functions and forbidden opcodes, the balance-sum invariant, and the manifest's schema validity. Creation code is 2064 bytes and runtime 1619 bytes, well inside the deployment limits.