Implemented SwarmCore (SWORE): 1,000,000,000 tokens with 18 decimals, minted once to the deployer.

Dependencies are vendored, Solidity is pinned to 0.8.26, and deployment assumptions and responsibilities are documented in README.md.

Validation passed, including from a clean offline copy:

• forge build
• forge test — 35 passed, including fuzz and invariant checks
• forge fmt --check

The external protected launch harness was not run locally.

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

Manifest field and ABI checks passed. forge build succeeded; forge test passed all 35 tests. Only launch.json is a submission change.

Review complete. No defects found in the assigned area, and the findings file is written with full coverage.

Outcome. .imd-findings.json holds an empty findings list and seven coverage rows: one for each of the three listed entry points plus four invariants, all holds. The working tree has no other changes.

What I checked, against the Access Control, Trust Gap and Asymmetry guides:

• SwarmCore is a bare OpenZeppelin ERC20 with a constructor that mints the full supply to msg.sender. The ABI exposes only approve, transfer and transferFrom as state-changing functions, with no receive, fallback, owner, minter, pause, blacklist or upgrade path.
• All five vendored OpenZeppelin files hash identically to upstream v5.0.2 at the pinned commit, so the inherited transfer and allowance logic is unmodified.
• A scratch test confirmed that 22 common admin, mint, freeze, seize and pause selectors revert from both the deployer and a stranger, that the deployer cannot pull from a holder without an allowance, that allowances are spent only up to what the owner granted, and that the contract rejects ETH. The existing 35 repo tests, including the invariant suite, pass.
• The runtime contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT. A first scan of mine flagged two bytes, but they are PUSH2 immediates and my scanner's PUSH skip was off by one. The repository's opcode test and the protected harness scan both handle this correctly.
• The aderyn "large numeric literal" lead is the supply constant 1_000_000_000 * 10 ** 18, which equals the stated supply exactly. Not a defect.

Trust assumption, not a finding. The factory receives the entire supply at deployment, as the brief requires. It has no authority afterwards beyond ordinary holder rights.

Not reached. Nothing within the assigned area was left unreached. The Uniswap v4 seed and swap flow in the protected harness was not executed locally since v4-core is not vendored here, but the token has no exemptions or transfer hooks that could affect it.

The review is complete and the findings file is written and valid.

Outcome: no defects found. The findings file at the repository root holds an empty findings list and nine coverage rows, every entry point answered as holds.

What I checked in my area:

• Execution Trace: traced approve, transfer and transferFrom through the inherited OpenZeppelin paths. Zero-address sender, receiver and spender revert, balance and allowance checks run before any unchecked arithmetic, failed calls leave allowances and balances untouched, unlimited allowance is never decremented, and every path moves exactly the requested amount. A scratch Foundry test confirmed each of these edge cases, then was removed.
• Periphery: all five vendored OpenZeppelin files hash-match the upstream v5.0.2 commit byte for byte, so the base contract is unmodified. There are no linked libraries and no submodule.
• First Principles: the constructor takes no arguments and mints exactly 1e27 units once to msg.sender, which is the factory under CREATE2. No role, owner, initializer, burn, mint, pause or freeze surface exists in the ABI. The deployed runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE opcodes, and there is no receive or fallback.

The existing suite of 35 tests passes and the formatter check is clean. The aderyn large-literal lead at line 10 is style only. The working tree has no stray files. Nothing in the assigned area was left unreached.

The review is complete. The findings file is written with an empty findings list and seven coverage rows, and no repository file was changed.

Result: no defects found in the Economic Security, Invariant and Flow Gap areas.

SwarmCore is a sixteen-line contract that inherits OpenZeppelin v5.0.2 ERC-20 unchanged and mints 10^27 units to msg.sender in the constructor. There is nothing else: no owner, no hooks, no external calls, no mint or burn path after construction.

What I verified:

• Vendored library integrity. All five OpenZeppelin files are byte-identical to upstream commit dbb6104 (SHA-256 compared), so the inherited transfer and allowance logic is the audited one.
• Supply invariant. The constant evaluates to exactly 1000000000000000000000000000. The compiled ABI exposes only the standard ERC-20 functions plus the supply view. Transfers to the zero address revert, so supply can neither grow nor shrink.
• Launch flows. Factory push to the distributor, allowance-based pull by a PoolManager stand-in measured by balance delta, trader buy and sell round-trip, and distributor claim all move exactly the requested amount. Conservation holds across the whole sequence.
• Economic security checklist. No external dependency to break, no token misbehavior (fee, rebase, pause, blacklist), no sentinel-address paths, no privileged power that moves or freezes a holder. Runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, STATICCALL or SELFDESTRUCT.
• Project checks. All 35 project tests pass including the stateful invariant suite, and formatting is clean. The aderyn large-numeric-literal lead is the supply constant and is benign.

Two notes that are not defects:

• The README states the intended chain is Ethereum mainnet. The launch chain is set by the service policy, not the token, and I had no network file to confirm it. Worth a glance by the manifest author.
• The standard ERC-20 approve race applies and is already documented in the README as a holder responsibility.

The findings file is in place and is git-excluded by the workspace's own rule, so the tree has no stray changes. The review is complete.

Result: no defects found in the math, boundary or numerical-gap area. The findings file at .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What the token is: a 16-line contract inheriting OpenZeppelin v5.0.2 ERC20 unchanged, minting a constant supply once in the constructor. It has no division, no scaling, no casts, no external calls, no payable path, and no receive or fallback. The only state-changing entry points are approve, transfer and transferFrom.

What I checked against the three guides:

• Math Precision. The supply constant evaluates at compile time to exactly 1e27, matching the README figure, fitting uint256 and the int128 used by Uniswap v4 balance deltas. Every unchecked subtraction in the inherited code sits behind a strict less-than guard, and the unchecked balance addition is bounded by the fixed supply because no mint or burn path exists after construction. The aderyn large-literal lead resolves to a correct value.
• Boundary. Exercised value 0, exact balance, balance plus one, max uint, self-transfer of the full balance, zero receiver and zero spender, finite versus max-uint allowance including max minus one, pulls from the zero address, raw ETH and unknown selectors. All behave as the README documents, and the runtime contains no CALL, DELEGATECALL, CALLCODE, STATICCALL or SELFDESTRUCT opcodes.
• Numerical Gap. There are no formulas, so no precision-by-invariant seams. The sum of balances equals total supply exactly under integer arithmetic, confirmed by the existing stateful invariant run and a fuzzed conservation check. The supply is divisible by 10,000, so the swarm's ten percent and any basis-point split leave no remainder.

Verification I ran: build, the existing 35 tests, a 13-test scratch suite covering the cases above, formatting check, and a byte-for-byte comparison of the six vendored OpenZeppelin files against the upstream archive, whose hash matches DEPENDENCIES.json. The scratch tests were removed afterwards.

Two notes for the judge, neither a defect: the standard ERC-20 approve race applies and the README already documents it, and the two-percent and eight-percent swarm splits are rounded by the distributor, which is outside this tree.

Added 12 adversarial tests and expanded stateful invariants to cover rejected calls, rollback, allowance boundaries, and continued transferability.

Offline verification passed: forge build and forge test—47 tests, zero failures, including 32,768 invariant calls.

Only test/ changed. No confirmed defects found.

Review complete. The SwarmCore token has no defects, and .imd-findings.json holds an empty findings list with a full coverage record.

What I checked

• All four specialists and the tester reported nothing. There was nothing to reproduce or merge, so I audited the code independently.
• The contract is a 16-line wrapper over OpenZeppelin v5.0.2 ERC20 that mints 1e27 units to msg.sender in an argument-free constructor. I fetched the five vendored OpenZeppelin files from the pinned upstream commit and their SHA-256 hashes match byte for byte, so the inherited approve, transfer and transferFrom logic is the audited upstream code.
• Launch flows reproduce whole. A scratch Foundry test deployed the token through CREATE2 from a probe contract, moved ten percent to a distributor, claimed it, and round-tripped tokens through an approving custodian. Every amount arrived exactly and supply stayed constant.
• No privileged surface. Twenty-two mint, pause, blacklist, freeze, seize, burnFrom and upgrade selectors revert from both a stranger and the factory address. The ABI exposes only the standard ERC-20 functions.
• Deployable under the factory. Creation code is about 2.6 KB and runtime about 1.7 KB, well under the limits. The runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or STATICCALL opcodes. Decimals are 18.
• The manifest is valid. Only schema keys, correct types, lowercase addresses, empty constructorArgs matching the parameterless constructor, totalSupply equal to the minted amount, and notes under the length limit.
• The aderyn large-numeric-literal lead is a style note. The literal folds to exactly 1e27 at compile time.

The project's own 47 tests pass. The scratch test directory was removed, and the working tree is unchanged apart from the findings file.