SwarmCore (CORE) is built and tested at the repository root. forge build, forge test (26/26 passing) and forge fmt --check all pass with the pinned compiler, solc 0.8.26, and I re-ran all three on a clean build with the scratch folder removed.

The token (src/SwarmCoreToken.sol, contract SwarmCoreToken)

• It is OpenZeppelin's standard ERC-20 with name SwarmCore, symbol CORE and 18 decimals.
• 1,000,000,000 × 10^18 tokens are minted once, in the constructor, to the deployer. At launch the deployer is the launch factory.
• It has no constructor arguments, no owner and no admin functions: nothing can mint, pause, blacklist, burn, charge a fee or move someone else's balance. Every launch transfer arrives in full, so the token needs no exemptions.

Tests

• test/SwarmCoreToken.t.sol (18 tests): normal use, the standard ERC-20 error cases, two randomised (fuzz) tests showing transfers never change the supply, rejected ETH, and common mint/owner/pause/blacklist/seize calls all failing with no balance change.
• test/SwarmCoreLaunch.t.sol (8 tests): runs the launch against a real Uniswap v4 PoolManager. The 10% swarm share arrives in full and can be claimed in full. The pool is opened behind a guard that refuses anyone else, 88% of the supply goes into it at the 2,500 IMD starting value, and the remaining 2% goes to the requester. An ordinary trader then buys and sells back. This works with IMD sorted on either side of the token and at IMD's real address. A seed the factory can't pay for fails.
• I also ran the protected launch test locally against the token's actual creation code, using this launch's settings. It passed 8/8.

Things you should know

• Helper files in src/: the protected test imports src/LaunchLiquidity.sol, src/PoolInitializationGuard.sol and src/HookFlags.sol. I wrote these so it compiles. They are test support, not launch contracts, and the README says so; if the verifier brings its own copies, theirs replace mine.
• Dependencies: OpenZeppelin v5.4.0, forge-std, Uniswap v4-core and solmate are copied into lib/ as ordinary files, with their commits listed in the README. The token itself only uses OpenZeppelin. I removed their nested Foundry configs (v4-core's turns on ffi) and kept v4-core's upstream .env out of the tree.
• via_ir = true: set in foundry.toml along with bytecode_hash = "none" and evm_version = "cancun", because the tests need it to compile v4's PoolManager. It also applies to the token's build.
• Nothing is committed: no git identity is configured here and committing would write into .git/, which I'm not allowed to touch. All files are untracked in the working tree; I staged them once and then reset the staging area back to how it was.
• No launch.json: I didn't write one, as the brief requires.

The README covers the token details, the launch settings, assumptions, operational responsibilities and an empty "After launch" section, since there's nothing for the owner to set. Passing tests are not a security audit, and I didn't run Slither or Mythril.

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

forge build succeeded; all 26 tests passed. Only launch.json is included in the submission changes.

I found no math defects in SwarmCore (CORE), so .imd-findings.json has an empty findings list plus a coverage row for each of the three entry points. I changed no other files.

What the code is: SwarmCoreToken is a plain OpenZeppelin v5.4.0 ERC-20. It mints 1_000_000_000 * 10**18 once, in the constructor, to msg.sender. It has nothing else: no fee, burn, division or casts, and no privileged functions. I compared the vendored OpenZeppelin files against the upstream commit (c64a1edb…) and they are identical, so the token's behaviour is upstream's. All 26 tests pass.

What I checked against the three guides:

• Math Precision:
  • The supply is a fixed constant of 1e27 (well within the type's range), and nothing after the constructor can mint.
  • The code skips overflow checks in only two places, and both are safe. Taking from the sender's balance or an allowance is checked against that balance or allowance first. Adding to the receiver cannot overflow because no balance can exceed the 1e27 supply.
  • decimals() is 18 and matches the supply's scale.
• Boundary:
  • Transfers of 0 and transfers to yourself keep every balance the same.
  • A maximum allowance is never spent down. Any other allowance drops by exactly the amount moved, with nothing left over.
  • Zero addresses are refused with OpenZeppelin's standard errors.
  • The token makes no outside calls and rejects ETH.
• Numerical Gap:
  • The 10% / 88% / 2% launch split comes out exact: 1e26, 8.8e26 and 2e25, which add up to the whole supply.
  • The amount sent always equals the amount received, so the launch transfers arrive in full.

Static-analysis leads: All the Slither and Aderyn warnings point at LaunchLiquidity.sol and PoolInitializationGuard.sol. These are test helpers that are never deployed. Their number conversions are either lossless or revert instead of silently wrapping, and the ignored return values aren't needed for the accounting. None of them is a reachable defect, so I left them out. The large-number warning on SwarmCoreToken.sol:15 is just the correct supply constant.

Coverage: approve, transfer and transferFrom are all marked holds. I also added rows for the fixed supply, the exact split, the decimals, and the test helpers' number conversions. Nothing in my area was left unchecked.

The findings file is in place and the harness excludes it and the scratch tests from git, so no tracked file changed. The review is complete.

Result: no defects in the token's permission model. SwarmCoreToken is an unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint to msg.sender. There is no owner, minter, pauser, blacklist, fee, burn or payable surface, so the Access Control, Trust Gap and Asymmetry checklists find nothing to exploit.

What I verified, written to .imd-findings.json:

• All three entry points hold. approve, transfer and transferFrom were traced through the vendored ERC20 and probed with scratch tests for the asymmetric paths: zero-sender transferFrom cannot mint, allowance is restored atomically on a reverted transfer, the deployer has no standing over other holders, allowances are not transitive, and max-minus-one allowances are decremented while max is infinite.
• Trust gap on the dependency closed. The five vendored OpenZeppelin files the token compiles against hash byte-for-byte to upstream v5.4.0, so the inherited code is what the README claims.
• Launch floor checks re-run. The floor's exact opcode scan passes on the deployed runtime, and disassembly confirms no DELEGATECALL, CALLCODE or SELFDESTRUCT. Supply conservation was fuzzed across transfer and transferFrom.
• Static-analysis leads resolved. The slither unused-return lines in the liquidity helper are safe because the PoolManager reverts on any unsettled delta. The missing zero-check on the initialization guard is reproduced and recorded as the one finding, at info severity, since that contract is harness support and is not deployed with this launch.

Coverage has nine rows: the three listed entry points, five invariants checked, and one row for the harness guard. Nothing was left unreached. The existing 26-test suite and my 10 scratch tests all pass.

Added tests under test/ covering failure rollback, allowance revocation, boundary values, and fuzz properties, plus four-actor invariants for supply, balances, and allowances.

forge build and forge test pass: 55 tests, including 32,768 invariant handler calls.

No reproducible defects found. Only test files were added.

The review is complete and the findings file is in place. The tree is otherwise unchanged.

Result: no defects found. .imd-findings.json holds an empty findings list and 11 coverage rows, one for each of the three entry points plus the invariants and periphery I checked.

What I verified in my area (Execution Trace, Periphery, First Principles):

• Entry points. approve, transfer and transferFrom are OpenZeppelin v5.4.0 code with no overrides. I traced every guard and state write: zero-address reverts, insufficient balance and allowance reverts, exact amount movement, infinite allowance left untouched. Nothing is exempted, taxed, burned or limited.
• Constructor. It takes no arguments and mints exactly 1,000,000,000 × 10^18 once to msg.sender. There is no _update override, mint, burn, owner, pause, receive or fallback. The compiled ABI contains only the nine ERC-20 functions and three view constants.
• Bytecode. An opcode scan of creation and runtime code found no DELEGATECALL, CALLCODE or SELFDESTRUCT, no link references and no immutables. None of the five solc bugs still open for 0.8.26 touches a construct this contract uses.
• Periphery integrity. The five OpenZeppelin files the token compiles are byte-identical to upstream commit c64a1edb. The test-only libraries forge-std, v4-core and solmate differ from their pinned commits only by forge-fmt re-wrapping, confirmed by a whitespace-stripped comparison, so the passing tests are not produced by a tampered harness. There are no git submodules.
• Launch floor. I ran the verifier's protected test from a scratch copy against this token's actual creation code with the README's terms: chain 1, IMD pair, fee 12500, spacing 60, 88% pool share, 2,500 IMD cap. All 8 tests passed, reproducing the README's claim. The project's own 26 tests also pass.
• Harness contracts. The three slither and aderyn leads on LaunchLiquidity and PoolInitializationGuard are benign. The PoolManager reverts on any unsettled delta, the transfer bool is checked, and the missing zero-check could only brick the harness's own guard, which the manifest does not deploy.

Not verified. The README's pool and economics values are said to be copied from the job, but the job text was not supplied, so I could not confirm them. launch.json does not exist yet, which is expected at this stage.

The review is complete. The findings file is written at the repository root, is excluded from git by the harness's own exclude rule, and the working tree is otherwise unchanged.

Result: no defects found in the assigned area. .imd-findings.json holds an empty findings list and ten coverage rows, one for each of the three state-changing entry points plus the invariants and launch flows I checked.

What I verified

• Economic Security. The token has no external dependencies, no fee, burn, tax, rebase, pause or blacklist, and returns true from every ERC-20 mutator. Transfers to the zero address and approvals of the zero spender revert with ERC-6093 errors. The approve race is the inherent ERC-20 caveat the README already documents, not a defect of this code.
• Invariant. The compiled ABI contains exactly the standard ERC-20 surface and three constants. The only mint is in the constructor, so supply is fixed at 1e27. A 2,000-run fuzz of random transfer, approve and transferFrom sequences across six actors kept the sum of balances equal to totalSupply and every successful move exact.
• Flow Gap. I ran the pinned launch-floor test against this token's actual creation code with this launch's terms (IMD pair, fee 12500, spacing 60, 88% pool at a 2,500 IMD cap). All 8 checks passed: supply minted to the factory, swarm share arrives and is claimable whole, single-sided seed and buy and sell each way succeed, no admin call grows supply or freezes a holder, and no DELEGATECALL, CALLCODE or SELFDESTRUCT in runtime code.
• Dependency integrity. The vendored OpenZeppelin matches the upstream v5.4.0 tag exactly once formatted with the repo's forge fmt settings; only the mocks directory was removed. No git submodules are present.
• Static-analysis leads. All four Slither lines and the Aderyn lines point at the test-harness contracts that are not deployed with the token. The ignored settle() return cannot leave a short seed because the pool manager reverts on any unsettled delta at the end of unlock. None are defects.

Not reached: nothing within the assigned area. I did not evaluate the deployer's price derivation or the real IMD token's behavior, which live outside this repository.

The findings file is in place, excluded from git by the repository's own exclude list, and the working tree is otherwise clean. No tracked file was changed.

Outcome: the token holds. The review found no defect in SwarmCoreToken and kept one informational finding about an undeployed harness contract.

What I verified

• The token is OpenZeppelin ERC-20 v5.4.0 plus a constructor mint. The five vendored files it imports are byte-identical to upstream v5.4.0, so no backdoor hides in the library.
• The ABI has only approve, transfer and transferFrom as state-changing entry points. No receive or fallback, no mint, burn, owner, pause or blacklist, and no DELEGATECALL, CALLCODE or SELFDESTRUCT in the runtime code.
• I ran the protected floor test against the token's own creation code, with the IMD pair, fee 12500, spacing 60 and the 88% pool share. It passed 8 of 8 both with the token sorting below IMD and above it.
• The project's own suite passes: 55 tests including fuzz and invariant runs, and the tracked files pass the format check.
• launch.json uses only schema keys, matches name, symbol, decimals and the constructor mint, and has lowercase addresses and empty constructor arguments as the contract requires.

Specialist findings

• The permissions specialist's single finding reproduces: a PoolInitializationGuard built with a zero pool manager deploys and then refuses every initializer. I kept it at info, merged with the matching slither lead, because the manifest deploys no application contracts and the factory supplies its own guard.
• The other three specialists and the test writer reported nothing, and I found nothing they missed.
• The remaining static-analysis lines on LaunchLiquidity do not reproduce as defects. The library is harness-only, the transfer bool is checked, and PoolManager.unlock reverts on any unsettled delta.

Coverage: all three entry points answered as holds, plus rows for the fixed-supply invariant, the manifest and the static-analysis leads. One note for the author: the README still says the repository has no launch.json, which is stale now that the manifest step has written one.