Implemented SwarmPeg (SWARMPEG) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer.

Included vendored dependencies, success/failure tests, fuzz and invariant tests, and deployment documentation.

Verified successfully:

• forge build, including forced offline compilation
• forge test with the supplied seed: 38 passed
• forge fmt --check

No transactions were broadcast.

I found no defects in SwarmPeg's permissions. .imd-findings.json has an empty findings list and 9 coverage rows, all holds: the 3 listed entry points plus 6 invariant and seam rows.

What the code is. src/SwarmPeg.sol is a 17-line contract built on OpenZeppelin's ERC20. Its constructor takes no arguments and mints 1e27 base units (1 billion tokens with 18 decimals) to msg.sender. Its only addition to the standard is a read-only INITIAL_SUPPLY getter. I downloaded OpenZeppelin v5.1.0 and compared it with the copy in lib/: the archive's SHA-256 matches DEPENDENCIES.md, and all six vendored files are byte-identical to the release. So nothing in the library has been altered.

Access Control guide

• Roles: there are none. No owner, role, or initializer exists, and the constructor grants nothing beyond the one mint.
• Inconsistent guards: each writable value has exactly one way in. Balances change only through transfer and transferFrom, and allowances only through approve and the allowance check inside transferFrom.
• Supply: _mint runs only in the constructor. Sending from the zero address can't be used as a hidden mint, because it always reverts.
• Proxies and raw ETH: there is no delegatecall, proxy, or catch-all function. An unknown function call such as mint(address,uint256) reverts, and so does sending ETH.

Asymmetry guide

• transfer and transferFrom move tokens the same way; the only difference is the allowance check, as the ERC-20 standard requires.
• Two quirks of OpenZeppelin v5 are deliberate and covered in the README, so I did not report them. A maximum allowance is never reduced, and spending an allowance emits no Approval event.
• The known front-running risk when changing a nonzero allowance is a property of ERC-20 itself, and the README already tells holders how to handle it.

Trust Gap guide

• No behaviour depends on who the caller is: there are no fees, exemptions, or admin setters. The factory, pool manager, distributor and traders are all treated the same.
• Every launch transfer moves exactly the amount requested, so no group of users can gain or lose relative to another.

Checks I ran

• forge build succeeded, and the compiled ABI is only the ERC-20 functions plus INITIAL_SUPPLY.
• The existing suite passed: 38 tests with the README's fuzz seed.
• I wrote a 7-test scratch probe, all passing, which included a 512-run fuzz test. It confirmed four things:
  • The deployer has no power over a holder's balance.
  • A spender can never take more than their allowance.
  • A holder needs an allowance to call transferFrom on their own balance, and revoking an allowance takes effect.
  • Zero-address and ETH calls are rejected.
• I deleted the probe afterwards and changed no tracked files.
• I could not run the two protected checks, because they need a launch harness, pool code and environment variables that aren't in this repository. I only traced them by reading, and none of them should fail on this token.

Several untracked entries now show in git status, such as .bashrc, .gitconfig and .claude/*. I didn't create them: they are empty device-file placeholders created by the sandbox, so I left them alone.

Created launch.json matching SwarmPeg’s constructor, supply, pool settings, and exact economics. Only the manifest changed; local JSON and consistency checks passed.

forge build and forge test were attempted with the supplied fuzz seed. Both stopped because Solc 0.8.26 returned Permission denied.

The review is complete and clean. The findings file is written with an empty list and full coverage, and the working tree holds no other changes.

Result: no defects in the Economic Security, Invariant or Flow Gap areas for SwarmPeg. The token at src/SwarmPeg.sol is a fixed-supply OpenZeppelin ERC-20 with no owner, fee, hook, mint or burn path after the constructor.

What I verified

• Supply and allocation. The constructor mints exactly 10^27 minor units once to the caller, which is the factory under launchCustom. Decimals are the OpenZeppelin default of 18. The aderyn literal lead evaluates correctly.
• Conservation invariant. The only writers of balances are the constructor mint and plain transfers, which reject the zero address on either side. Supply cannot grow or shrink after deployment. The project's stateful invariant suite and a 16-actor, 200-step scratch fuzz both pass.
• Launch flows. Factory to distributor, distributor to claimants, factory to pool, pool to trader and sell-back all move the exact amount. A fuzzed scratch test over claimant counts and trade sizes confirms every leg arrives whole and the pool returns to its seeded balance.
• Economic dependencies. No oracle, callback, reentrancy surface or external call exists. The compiled ABI exposes only the nine ERC-20 functions and the supply constant, with no link references, DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Library provenance. All six vendored OpenZeppelin files are byte-identical to upstream v5.1.0.

Coverage record. All three listed entry points are marked holds, plus the constructor, two invariants, the pool flow and the static-analysis lead, eight rows total.

Not reached. The real ProjectFactory, MerkleDistributor and pool seeding contracts are not in this tree, so the Uniswap v4 seed and swap were reasoned from the token's behaviour rather than executed against the protected harness. The manifest does not exist yet in this tree; it should list constructorArgs as an empty array and totalSupply as 1000000000000000000000000000.

The review is complete and .imd-findings.json holds an empty findings list with nine coverage rows. Git status shows no tracked changes beyond that output file.

Outcome: no defects found. SwarmPeg is a 17-line contract that inherits OpenZeppelin ERC20 and mints the full supply to the constructor caller. There is no custom transfer logic, no roles, no external calls and no fallback, so every failure mode in the Execution Trace, Periphery and First Principles guides collapses to the behaviour of the vendored base contract.

What I verified, by reading and by running a scratch Foundry test that I removed afterwards:

• Constructor: mints exactly 10^27 units once to the caller. Deployed through a CREATE2 factory stand-in, the factory holds the whole supply. The constructor is nonpayable and makes no external calls. The aderyn "large numeric literal" lead resolves to the exact intended value.
• approve, transfer, transferFrom: traced through the OpenZeppelin v5.1.0 implementation. Amounts move exactly, zero recipient and zero spender revert, insufficient balance and allowance revert before any state write, infinite allowance stays unchanged, and a self-transfer preserves balances.
• Launch flows: factory to distributor, distributor to claimant, factory to pool and a buy/sell through approve plus transferFrom all deliver the exact amounts, and total supply stays fixed.
• Periphery: all six vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 archive, whose checksum matches the one recorded in DEPENDENCIES.md.
• Runtime: no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or STATICCALL opcodes. Unknown selectors such as mint, burn, pause and blacklist revert. Plain ETH transfers revert.
• Project tests: the existing 38 unit, fuzz and invariant tests pass with the README's seed.

One note rather than a finding: approvals replace rather than increment, which is the standard ERC-20 race and is documented in the README. I did not run the protected pool-manager swap test here because v4-core is not vendored in this tree; its pass is implied by the token having no transfer hooks, but the verifier's harness is where that is proven.

The review is complete. The findings file at .imd-findings.json holds zero findings and eight coverage rows, and the working tree is otherwise untouched.

Outcome: no math, boundary, or numerical-gap defect in SwarmPeg. The token is a 17-line wrapper over OpenZeppelin v5.1.0 ERC20 with one constructor mint and no overrides.

What I verified:

• Supply constant. The literal 1_000_000_000 * 10 ** 18 is folded at compile time to exactly 10^27, matches the manifest string, and fits in uint128 so Uniswap v4 delta math never sees it overflow. The aderyn large-literal line is style only.
• Transfer arithmetic. Both unchecked blocks in OpenZeppelin's _update are guarded: the subtraction by the insufficient-balance revert, the addition by the sum-of-balances invariant, which cannot break because there is no post-constructor mint path.
• Allowance arithmetic. The unchecked decrement in _spendAllowance is guarded by the insufficient-allowance revert. Only exactly max is infinite. Max-minus-one decrements normally, and an allowance above balance is bounded by the balance check and rolls back atomically.
• Launch split. The 1000 and 8000 basis-point legs divide 10^27 with no dust. With no fee or burn, every launch leg and claim arrives whole.
• Boundary enumeration. No external calls, no payable or receive functions, no bytes decoding, and only address-zero sentinel branches, all of which revert.
• Library integrity. All six vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 archive, whose hash matches DEPENDENCIES.md.

I ran the shipped suite of 38 tests plus seven reviewer probes under test/scratch/, all passing, and removed the probes afterward. Coverage rows mark all three entry points as holds with the reasons above.

I added test/SwarmPeg.open.t.sol. It builds on the suite that was already here and doesn't change it. I found no defect in src/SwarmPeg.sol, so I wrote no .imd-findings.json.

Check: forge build and forge test pass with the verifier's seed 0x1605…5756: 51 tests in 5 suites, none failing. During the invariant runs every handler function was called about 2,700–3,300 times with 0 reverts, and fail_on_revert is on. So none of the properties passes vacuously.

About the contract: it is OpenZeppelin v5.1.0's ERC20 with nothing added except a constructor. That constructor mints exactly 1,000,000,000 × 10¹⁸ to whoever deploys it. There are no admin, mint, burn, pause or ownership functions. The existing tests already covered the basic happy paths and failure paths, so the new file goes after what they left open:

• Open-ended invariant test: the existing invariant test only uses four fixed holders. This handler sends to addresses the fuzzer picks, including the token contract and the handler itself. It also tries transfers above the balance, transferFrom above the allowance, and transfers to the zero address, all of which must revert. After every random sequence it checks:
  • every holder's balance equals a separately kept expected balance;
  • all balances add up to the full supply, and totalSupply never changes;
  • the zero address holds nothing;
  • no balance is larger than the supply;
  • name, symbol and decimals never change.
• Launch invariant test: a copy of the token deployed by a factory hands out shares in random order: to a distributor, a pool, a remainder address, claimants and traders. Checks:
  • all the launch accounts add up to the supply;
  • the distributor's balance is exactly what it received minus what it paid out, and claimants receive exactly what was claimed (never more than the 10% swarm share);
  • the factory holds the whole supply before launch and nothing after it.
• Fuzz and edge tests:
  • a random caller can't move another holder's tokens without an allowance;
  • a holder approving itself gives nobody else access;
  • a new approve replaces the old allowance rather than adding to it, and repeating it changes nothing;
  • sending tokens away and back restores both balances, and two transfers add up to the same as one;
  • spending an allowance emits only a Transfer event, no Approval;
  • the zero address can't approve or send;
  • one-wei edges;
  • the supply is exactly one billion whole tokens.

Expected behaviour, not a defect: tokens sent to the token's own address are accepted and then stuck for good, because there is no rescue function. That is normal for a token with no admin powers. I wrote a test that pins this behaviour so any change to it gets noticed, rather than reporting it as a finding.

Not done:

• I didn't change the existing tests, src/, or any configuration.
• I didn't commit; the file is left in the working tree.
• The protected launch-floor tests need the real factory and Uniswap v4 setup, which isn't in this repo, so I didn't run them.

The review is complete and the findings file is written. No tracked file was changed.

Outcome: no defects found. All five specialists reported nothing, and my own pass against the Pashov, x-ray, Trail of Bits and ethskills checklists reproduced nothing to report. The findings file holds an empty list and a coverage record with all three entry points marked holds.

What I verified against the code

• Token source. src/SwarmPeg.sol is a 16-line contract that inherits OpenZeppelin ERC20 and has a parameterless constructor minting the whole supply to msg.sender. It has no owner, mint, burn, pause or hook, and no receive or fallback. The compiled ABI exposes only the standard ERC-20 functions.
• Dependency integrity. I downloaded the OpenZeppelin v5.1.0 archive. Its SHA-256 matches DEPENDENCIES.md, and all five vendored contract files plus the licence are byte-identical to upstream.
• Entry points. A scratch Foundry test traced approve, transfer and transferFrom through their success and revert paths: zero-address rejections, insufficient balance, insufficient allowance, finite allowance decrement, infinite allowance left untouched, and a stranger with no allowance refused. The launch flow (factory to distributor to claimant) moves exactly the amount sent and leaves the supply unchanged.
• Deployment model. Deploying through CREATE2 from a factory contract mints exactly the manifest's supply to that factory, and the address matches the prediction. Runtime is 1752 bytes and creation code 2641 bytes, far under the limits. An opcode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT. Metadata confirms solc 0.8.26, cancun, and bytecode hash none.
• Manifest. launch.json uses only schema keys, an empty constructorArgs list matching the zero-parameter constructor, the exact supply, 18 decimals, matching name and symbol, and lowercase addresses.
• Static-analysis lead. The aderyn "large numeric literal" line refers to the supply constant, which evaluates to exactly 1e27 at compile time. It is a style note, not a defect, so it was left out.

The project's own 51 tests, including the invariant suites, pass. The scratch test directory was removed after use, so nothing outside the findings file was left behind.