Done. The SwarmCore token is implemented, tested, documented and committed on main as commit 5899099.

What was built

• src/SwarmCore.sol is a plain OpenZeppelin v5.4.0 ERC-20. The constructor takes no arguments and mints the whole supply to msg.sender once. Name is SwarmCore, symbol SWARMCORE, 18 decimals, supply 1,000,000,000 tokens.
• There is no owner, mint, burn, pause, blacklist, fee or exemption list. Every transfer moves exactly the requested amount, so the swarm share, pool seed and swaps in the protected floor test arrive whole. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The contract name fits the 32-character manifest limit and makes no external calls in the constructor.

Verification

All checks passed on a clean export of the commit, built offline with the pinned solc 0.8.26:

Check	Result
forge build	ok
forge test with the verifier's fuzz seed	29 passed, 0 failed
forge fmt --check	clean

Tests in test/SwarmCore.t.sol cover metadata, exact supply minted to an EOA, a fuzzed address and a contract deployer, transfer and allowance success and failure paths with the exact custom errors, conservation across chained transfers, rejection of every common admin selector from a stranger and the deployer, rejection of plain ether, and a bytecode opcode scan.

Dependencies and configuration

• forge-std v1.14.0 and the OpenZeppelin ERC-20 subset are vendored as ordinary files under lib/ with their licences. No submodules exist.
• foundry.toml pins solc 0.8.26, sets bytecode_hash to none, disables cbor metadata and ffi, and grants no filesystem permissions.

Documentation

The README records the assumptions, the launch manifest values as given, the supply distribution the factory performs, the operational responsibilities, and an empty "After launch" section since nothing is owner-settable. Slither and Mythril were not available on this machine and did not run; explorer verification is left to the launch deployer as an open item.

I found no defects in the math of SwarmCore, so .imd-findings.json has an empty findings list plus a coverage record. It is valid JSON, and no tracked files changed.

What the code is: src/SwarmCore.sol is a plain ERC-20 built on an unmodified copy of OpenZeppelin v5's ERC20. The constructor mints the whole supply once to msg.sender, and nothing changes how transfers or allowances work.

What I checked against the three guides (math precision, boundaries, numerical gaps):

• Supply constant: 1_000_000_000 * 1e18 comes out to exactly 10^27, which was the static-analysis "large numeric literal" warning. Nothing after the constructor can mint or burn, so the supply can't change.
• Unchecked arithmetic: the three unchecked blocks can't wrap. A sender's balance is only reduced after checking it covers the amount. A recipient's balance can never exceed the fixed supply. An allowance is only reduced after checking it covers the amount.
• Edge values:
  • Sending your whole balance works; one unit more reverts. Zero-amount transfers work.
  • Sending to yourself leaves your balance unchanged.
  • An allowance equal to the amount ends at 0; one below reverts.
  • The maximum uint256 allowance never goes down.
  • Transfers and approvals to the zero address revert.
• Rounding and decimals: there is no division, fee, burn or scaling, so nothing can round. decimals() is the default 18, matching the brief.

Checks run: the project's 29 existing tests pass. I also wrote a throwaway fuzz test (256 runs each) checking that transferFrom moves the exact amount and spends the exact allowance with the supply unchanged, that self-transfers net to zero, and the supply and decimals values. All of it passed, and I deleted the test afterwards.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds, along with two supply and decimals rows. None are unreached.

As the guides say, a clean review doesn't prove the code is free of defects.

launch.json is written and verified against the accepted tree.

What the manifest says

• kind "custom_token", token contract SwarmCore, name SwarmCore, symbol SWARMCORE, 18 decimals.
• constructorArgs is an empty list. The compiled ABI confirms the constructor takes no parameters.
• totalSupply is the exact constant the constructor mints to msg.sender, 1,000,000,000 tokens in minor units.
• contracts is empty, since the accepted tree holds only the token and no application contracts.
• pool and economics are copied exactly as the launch reference gives them: IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tickSpacing 60, one-to-one initialPrice, and the requester's economics object verbatim.
• notes describe only SwarmCore and its behavior, well under the 4,000 character limit.

Checks run

• A scripted shape check passed: only schema keys, strings for uint256 and address fields, numbers for fee, tickSpacing and decimals, lowercase addresses, supply equals the constructor constant.
• forge build succeeded, and forge test with the verifier's fuzz seed passed all 29 tests.
• git status shows launch.json as the only new or changed file. No configuration, lib, or test file was touched.

The review is complete. .imd-findings.json holds zero findings and eight coverage rows, and the working tree is unchanged apart from that file.

Result: no defects in the Access Control, Trust Gap or Asymmetry areas. SwarmCore is a thin, unmodified OpenZeppelin v5.4.0 ERC20 with no privileged surface at all.

What I verified:

• Permission model. The ABI has exactly three state-changing functions, approve, transfer and transferFrom, plus views and constant getters. There is no owner, minter, pauser, initializer, upgrade path, receive or fallback. The constructor hands out no role. The DEPLOYER immutable is informational and no function reads it for authorization.
• Vendored library integrity. All five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag, so no hidden privilege sits in _msgSender or _update.
• Asymmetry. transfer and transferFrom share the same _update path. A scratch fuzz run of 2,000 cases confirmed the allowance is debited by exactly the pulled amount, unrelated allowance pairs are untouched, and balances always sum to the fixed supply. The deployer retains no power once it pays the supply out.
• Trust-gap seams. With no admin setter, no economic formula and no caller-class branch, there is no seam for a permitted actor to extract value or treat holders differently. The factory, distributor, pool manager and traders are handled identically, which is what the launch floor requires.

Not counted as a defect: the standard ERC-20 approve overwrite race, which is inherent to the interface and already documented in the README.

Tools run: forge build, the project's 29 tests, forge inspect, and the scratch tests, which I removed afterwards. Slither and Aderyn output from the verifier reported nothing above low, and the one low item was the supply literal, which is correct.

The review is complete and clean. No defects found in SwarmCore. The findings file is written with an empty findings list and 8 coverage rows, and the only change to the tree is .imd-findings.json. Scratch tests were removed after running.

What I covered, by guide

• Execution Trace. Traced approve, transfer and transferFrom from entry through OpenZeppelin's internal _approve, _spendAllowance, _transfer and _update to final storage. Every failure path reverts with the expected custom error. Debits, credits and allowance decrements are exact. The only sentinel path is the unlimited allowance, which behaves as the standard specifies.
• Periphery. The vendored OpenZeppelin files are the real attack surface in a thin wrapper, so I fetched the five files from the upstream v5.4.0 tag and diffed them. All five are byte-identical. Storage layout is the five standard ERC20 slots and nothing else.
• First Principles. The supply constant is exactly ten to the twenty-seventh at compile time. The constructor takes no arguments and credits whoever creates it, which under the factory's CREATE2 is the factory itself. The compiled ABI exposes thirteen methods, all standard ERC20 plus four constant getters, with no owner, mint, burn, pause or blacklist selector. Plain ether is rejected.

Dynamic checks run

• Existing suite: 29 tests pass, formatting clean.
• Scratch invariant: five actors, roughly 128,000 handler calls including over-balance and over-allowance attempts. Sum of balances always equaled total supply.
• Scratch factory flow: CREATE2 deployment from a contract, then the 10/80/10 split and onward distributor and pool hops, every balance exact.

Not reported as defects. The ERC-20 approve-overwrite race is inherent to the standard, intentionally retained by OpenZeppelin v5, and already documented in the README. The static-analysis note about a large numeric literal is stylistic and the literal evaluates exactly.

Coverage. All three listed entry points are marked holds with reasons, plus five invariant rows covering supply minting, conservation, launch flow exactness, library provenance and bytecode content. Nothing in my area was left unreached.

The review is complete and the findings file is written. No defects found in the Economic Security, Invariant and Flow Gap areas for the SwarmCore token.

What I checked

• Source and library. The token is a bare OpenZeppelin ERC20 with a constructor that mints the supply to the deployer. I fetched the five vendored OpenZeppelin files at tag v5.4.0 and diffed them against the tree. They are byte-identical, so no logic was altered in the library.
• State-changing surface. The compiled ABI has only the constructor and the three listed entry points. There is no mint, burn, pause, blacklist, owner, initializer, receive or fallback. Storage is the standard five OpenZeppelin slots.
• Conservation invariant. A Foundry invariant run of 128,000 random transfer, approve and transferFrom calls among six actors kept the sum of balances equal to the fixed supply with zero reverts.
• Launch flows. I reproduced the factory to distributor to claimant hop, the factory to pool and factory to requester hops, and a buy and sell against a pool stand-in that moves tokens the way Uniswap v4's Currency library does. Every hop moved exactly the stated amount and allowances were consumed exactly.
• Boundaries and sentinels. One wei, whole balance, balance plus one, max uint, zero amount, self transfer, and all zero-address paths behave as the ERC-20 standard requires.
• Static analysis lead. The aderyn large-literal note resolves cleanly. The literal equals ten to the twenty-seventh exactly and matches the manifest value in the README.

Output

• .imd-findings.json holds an empty findings list and ten coverage rows: the three entry points, all marked holds, plus rows for the conservation invariant, fixed supply, launch flows, dependencies, deployment-time roles, library provenance, and the documented economics.
• The scratch test lives at test/scratch/EconomicsProbe.t.sol, which is gitignored. No tracked file was changed.

Not in scope of a defect but worth knowing. The approve overwrite race is standard ERC-20 behaviour and is already documented in the README. No launch manifest exists in the tree yet, which is expected at this stage.

I added two test files. With the verifier's seed, forge test passes all 46 tests (the 29 that were already there plus 17 new ones). I found no defects, so there is no .imd-findings.json.

test/SwarmCore.invariant.t.sol: invariant tests over random call sequences

• A handler contract makes random calls from five accounts (the deployer, alice, bob, carol and a distributor). It keeps its own record of what every balance and allowance should be after each call.
• It makes successful calls: transfer, approve (including unlimited approval) and transferFrom, with amounts kept within what each account holds and is allowed to spend.
• It also makes calls that must fail: sending more than the balance, sending to the zero address, pulling more than the allowance, and pulling more than the balance when the allowance is large enough. Each one checks that it reverts with the exact error.
• After every sequence, these must hold:
  • the supply stays exactly 1,000,000,000 × 10¹⁸;
  • the accounts' balances add up to the supply, and nothing ends up in the token contract, the handler or the zero address;
  • every balance and every allowance matches the handler's record;
  • name, symbol, decimals and deployer don't change, and the contract holds no ETH.
• Run counts are set in the test file: 256 runs × 100 calls = 25,600 calls, with no unexpected reverts. Each kind of call ran about 3,600 times.

test/SwarmCore.edges.t.sol: 16 edge-case and failure tests

• Zero address: transferFrom to the zero address, from the zero address, approve with the zero address as owner, and transfer with the zero address as sender. A pull to the zero address that fails does not use up the allowance.
• Allowance limits:
  • spending the exact allowance leaves zero, and the next wei fails;
  • an allowance of one below the maximum still goes down when spent;
  • pulling from your own account still needs an allowance;
  • approving zero cancels an allowance;
  • allowances are kept separately for each owner and spender pair.
• Events: transferFrom emits only Transfer (no Approval). A failed transfer emits nothing and changes nothing.
• Fuzz tests (1,000 runs each):
  • transfers between any two addresses, including to yourself;
  • over-allowance pulls revert and leave everything as it was;
  • any approval amount is stored exactly;
  • the launch split (10% to the swarm, a random pool share between 0% and 90%, the rest to the requester) adds back to the full supply with nothing lost.

The contract itself is OpenZeppelin's standard ERC-20 with the whole supply minted once to the deployer, and there are no admin functions. The suite therefore checks that the supply stays fixed and every balance and allowance is exact. It does not cover fees or burns, because the token has none.

The invariant run takes about two minutes locally. I didn't commit the files.

The review is complete with no defects found. The findings file holds an empty list and a coverage record answering all three entry points.

What I verified

• Specialist findings: all four areas and the test writer reported nothing, so there was nothing to reproduce or merge.
• Library provenance: the five vendored OpenZeppelin files diff byte-identical to the upstream v5.4.0 release.
• Entry points: approve, transfer and transferFrom are unmodified OpenZeppelin paths. Each reverts on zero addresses, insufficient balance or insufficient allowance, moves exactly the amount requested, and never changes total supply.
• Supply and privilege: the constructor is the only mint. The compiled ABI exposes no mint, burn, owner, pause, freeze, upgrade or initializer.
• Deployability: creation code is 2898 bytes and runtime 1931 bytes, both well under the limits. The constructor takes no arguments, matching the manifest's empty constructorArgs. Disassembly of the runtime shows no CALL, DELEGATECALL, CALLCODE, STATICCALL or SELFDESTRUCT.
• Launch flows: a scratch test deployed the token through CREATE2 from a factory contract and moved the swarm share, pool share and remainder. Every transfer arrived whole and a trader round trip through a pool-manager stand-in left supply unchanged.
• Manifest: launch.json uses only schema keys, correct types, lowercase addresses, a 32-character-safe contract identifier and a totalSupply equal to the constant in the code.
• Static analysis: the aderyn large-numeric-literal line is a style note on the supply constant and is not a defect.
• Existing suite: all 46 unit, fuzz and invariant tests pass, and forge fmt is clean.

Nothing was changed in the tree beyond the required findings file, and the scratch directory was removed.