Implemented SwarmCore (SWARMCOR): 1 billion tokens, 18 decimals, minted once to the deployer. Includes vendored dependencies, deployment documentation, and success/failure tests.

Passed:

• forge build
• forge test: 29 passed, including 16,384 invariant calls, using the supplied seed
• forge fmt --check

The separate protected launch harness was not run locally.

I found no math, boundary or numerical-gap defects in SwarmCore. The only finding is one informational item outside that area. Everything is written to .imd-findings.json, and no repository file was changed.

What I reviewed: src/SwarmCore.sol is a plain ERC-20 built on OpenZeppelin v5.0.2. Its only code of its own is the constant INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 and a single _mint(msg.sender, ...) in the constructor. I checked it and the OpenZeppelin code it relies on against the Math Precision, Boundary and Numerical Gap guides:

• Supply and decimals: the supply comes out to exactly 1e27 and is calculated once, when the contract is compiled. Decimals are the default 18, as the brief requires. There is no other mint or burn, so the supply cannot grow or shrink.
• Overflow and rounding: there is no division, rounding, scale conversion, narrowing cast or fee anywhere. OpenZeppelin skips overflow checks in two places (moving balances and reducing allowances); both are safe because the code first checks that the balance or allowance is large enough. Adding to a balance can't overflow either, since nothing ever exceeds the total supply of 1e27.
• Edge cases: zero-value transfers and approvals work, transfers to and from the zero address revert, and an unlimited (type(uint256).max) allowance is never reduced. Fees and rounding are where the numerical-gap guide finds bugs that need two lenses at once, and this token has neither.
• Tests: forge test passes all 29 tests, including the 256-run invariant suite. Slither reported nothing. Aderyn's "large numeric literal" warning is just the supply constant, which is correct.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds. There are two more rows for the invariants I checked: the total supply and decimals, and that all balances add up to the total supply.

Finding (info, outside the math area): DEPENDENCIES.md:21 says the vendored libraries can be verified with sha256sum -c lib/SHA256SUMS. That check fails for 7 forge-std files, such as StdJson.sol and Vm.sol. forge-std is only used by the tests, and every OpenZeppelin file the token compiles against passes, so the deployed token is unaffected. Only the "unmodified" claim about the test library is wrong.

I had no critical or high findings, so I wrote no proof tests.

I found no defects in my area (economic security, invariants and execution flow), and .imd-findings.json holds an empty findings list.

What was reviewed: src/SwarmCore.sol and the OpenZeppelin v5.0.2 ERC-20 code it inherits (ERC20, IERC20, IERC20Metadata, Context and the error interface). The contract mints 1_000_000_000 * 10**18 to msg.sender (the factory) once, in the constructor. There is no fee, burn, owner, pause or blacklist, and no external calls.

Checked against the guides:

• Economic security: every launch flow moves exactly the amount stated. That covers the factory sending 10% to the distributor, distributor claims, the single-sided pool seed, and buys and sells through the pool. No dependency can block a flow, and there are no special-case addresses or callbacks.
• Invariants:
  • The supply stays at exactly 10^27: the only mint is in the constructor, and a transfer to the zero address reverts, so nothing can be burned either.
  • All balances always add up to the total supply.
  • Allowances drop by exactly the amount spent, the maximum allowance is never reduced, and a failed transfer leaves no partial change behind.
• Execution flow: transferFrom checks and reduces the allowance before moving tokens, and the whole call either completes or reverts. Nothing reads stale values, leaves allowance behind, or skips checks on a special-value path.

Coverage: each of the three entry points (approve, transfer, transferFrom) has a holds row. There are also five rows for the invariant and economic properties above. The project's own tests pass: 29 of 29, including the stateful invariant test.

Left out:

• Zero-value transferFrom calls that anyone can make, which can be used to fake entries in a wallet's history. The ERC-20 standard requires zero-value transfers to work, and the README documents it.
• The approve front-running race, also a known part of the standard and documented in the README.
• Running sha256sum -c lib/SHA256SUMS reports 7 mismatches, all in lib/forge-std, which only the tests use and which is never deployed. This is outside my area. DEPENDENCIES.md says the vendored files are unmodified, so the author may want to look, but it doesn't affect the token.

Not done: I couldn't run the protected launch tests here because they need the network's launch harness, so the pool seed and swap claims come from reading the code, not from a run.

Written launch.json for the SwarmCore launch. It is the only new or changed file in the tree.

What the manifest says

• kind is custom_token. The token entry names contract SwarmCore, name SwarmCore, symbol SWARMCOR, 18 decimals, and an empty constructorArgs list. The accepted constructor takes no parameters, confirmed from the compiled ABI.
• totalSupply is 1000000000000000000000000000, which is exactly the INITIAL_SUPPLY the constructor mints once to msg.sender.
• contracts is empty. The accepted tree has only the token and no application contracts.
• pool and economics are copied verbatim from the launch terms: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's 8800 bps, 2,500 IMD opening cap and remainder address.
• notes describe the token's fixed supply, absence of any privileged functions, plain untaxed transfers, and the launch flows. They run 1665 characters.

Checks run

• A local script confirmed the manifest has only schema keys, string uint256s and addresses, numeric fee, tickSpacing and decimals, and the exact economics object.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 29 tests across both suites.
• git status shows launch.json as the only addition.

The review is complete and .imd-findings.json is written with one low finding and nine coverage rows. The working tree shows no tracked changes; the only files I created are the findings file and a scratch test under test/scratch/, which is git-ignored and not kept.

What I found in the assigned area (Access Control, Trust Gap, Asymmetry): nothing. SwarmCore is an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint to msg.sender and no other code.

• Access control. The compiled ABI exposes only approve, transfer and transferFrom as state-changing. There is no owner, role, initializer, receive or fallback, and the internal mint, burn and update hooks are unreachable. I confirmed with a scratch test that a factory deployment hands the whole supply to the factory alone, that the transaction origin holds no balance or allowance, and that a zero-value transferFrom from the zero address is rejected before any state changes.
• Trust gap. No privileged actor exists, so none of the four seams in the guide has an actor to occupy it. Launch flows are plain transfers with no exemptions, so each moves exactly what it says.
• Asymmetry. transfer and transferFrom share the same internal path; the only difference is the allowance spend, which rolls back on any revert. Allowance writers are approve and _spendAllowance only, with the same zero-address guards.

The one finding is outside my area and low severity. DEPENDENCIES.md tells readers to verify the vendored libraries with sha256sum -c lib/SHA256SUMS and calls them unmodified. That command fails for seven forge-std files. The hash list matches upstream forge-std v1.9.7 exactly, so the vendored copies were re-wrapped after hashing. The differences are line formatting only, and forge-std is test-only, so the deployed token bytecode is unaffected. All five vendored OpenZeppelin files are byte-identical to upstream v5.0.2.

Checks run. Build, the full project suite with the README's seed (29 tests passing including the invariant suite), forge fmt --check, the ABI dump, hash verification, and upstream diffs of both libraries. The protected launch test could not run locally because it needs the network's Uniswap v4 harness, as the README states. No static-analysis lead rose to a finding: the aderyn large-literal note on line 11 is the correct 1e27 supply.

Review complete. The findings file is written and validated, and no repository files were changed.

Outcome: The SwarmCore token holds under all three of my guides. One low-severity periphery finding is recorded.

What I checked

• Execution Trace. The three entry points, approve, transfer and transferFrom, are the unmodified OpenZeppelin v5.0.2 paths. I traced the zero-address checks, balance and allowance reverts, the unchecked arithmetic, the max-allowance branch and the rollback of allowance on a failed delegated transfer. There are no external calls, callbacks, sentinel paths or multi-step operations, so nothing in the within-transaction or across-transaction lists applies.
• First Principles. The constructor mints exactly 10^27 minor units once to its immediate deployer, which is the factory under the launch. Storage holds only balances, allowances, supply, name and symbol. No mint, burn, owner, pause, receive or fallback exists, so the supply cannot grow and no privileged hand can move a holder's balance.
• Periphery. I fetched upstream OpenZeppelin v5.0.2 and forge-std v1.9.7 and diffed the vendored copies. The five OpenZeppelin files and both licence files are byte-identical to upstream and to the hash list.

The finding (low). Seven vendored forge-std files were reformatted by the project's own forge fmt, so the integrity command that DEPENDENCIES.md tells readers to run fails with seven mismatches, and its "unmodified sources" claim is untrue. I verified the differences are whitespace only and that running the formatter on the pristine upstream file reproduces the vendored file byte for byte. The test assertions and cheatcodes are therefore semantically upstream and the 29 passing local tests are meaningful. Restoring the seven pristine files is the smallest fix.

Coverage. All three ABI entry points plus the constructor, the fixed-supply and no-privilege invariants, the vendored libraries, the runtime opcode check and the local test suite are recorded as holds or finding. The manifest row is unreached because no launch.json exists yet. The build, the test suite with the README's seed, and the formatter check all pass. The aderyn large-literal lead is a style note on the supply constant and not a defect.

Everything is green and only the two new test files appear in the working tree. No defect was found in the token, so there is nothing to report in a findings file.

Outcome: forge test passes with the verifier's fuzz seed. The suite grew from 29 to 51 tests across four files, all under test/.

Suite	Tests	Result
Existing unit and fuzz suite	28	pass
Existing invariant suite	1	pass, 256 runs x 64 depth
New launch and adversarial suite	21	pass, fuzz at 1000 runs
New adversarial invariant suite	1	pass, 256 runs x 64 depth

What the new file test/SwarmCore.launch.t.sol adds:

• Launch shape: a factory fixture deploys the token and a project contract by CREATE2 in one call, checks the whole supply sits at the factory, that the caller, the transaction origin and the project get nothing, and that a project constructor cannot pull supply. Same-salt redeploys fail. The 10/88/2 split and claim flows arrive whole, and the factory cannot pull anything back.
• Privileged hands: both selector lists from the protected harness are tried from a stranger and from the deployer. None succeed, the supply never grows, and a holder keeps its balance and can still transfer. Allowance helpers, permit, owner and recovery entrypoints are absent.
• Arbitrary calldata: a fuzzed selector with fuzzed arguments from an unfunded stranger never moves any funded balance, the supply, or an allowance it was not granted. Standard calls from the stranger succeed only when harmless.
• Algebra: transfer round trips restore both balances, split transfers equal single ones, approvals overwrite, allowance is checked before balance with exact revert data, spending emits only one Transfer event, and maximum amounts revert without overflow. The runtime contains no CALL, STATICCALL, CREATE or forbidden opcodes.

What the new file test/SwarmCore.adversarial.invariant.t.sol adds: a handler with six unevenly funded actors including the deployer, unbounded amounts chosen at zero, the exact balance, one above, and the maximum, arbitrary bystander recipients, and a stranger sending arbitrary calldata. Each call's outcome and revert reason is predicted from a ghost ledger before it is made, so success and failure paths are both checked on every step without the handler ever reverting. Invariants cover fixed supply fully held by tracked accounts, ledger and flow equality for every touched balance, allowances that move only by approval or authorised spending with cumulative spend bounded by cumulative approvals, a stranger that never gains tokens or allowances, and every call accounted for as accepted, rejected or skipped.

Corrections during the run were all harness mistakes, not contract defects: forge-std 1.9.7 lacks fail(string), mixing expectRevert with a low-level call flips the success flag, and a zero-amount pull from the zero address reverts with ERC20InvalidSender. The inline run-count comments only take effect on the contract declaration, so they were moved there and confirmed at 1000 fuzz runs.

The two new files are uncommitted in the working tree, formatted with forge fmt, and nothing was created outside test/.

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

Outcome: the token is clean. Two documentation findings, no code defects.

What I verified

• Built with Solidity 0.8.26 and ran the full local suite with the assignment's fuzz seed: 51 tests passed, 0 failed.
• Fetched the upstream OpenZeppelin v5.0.2 archive. Its SHA-256 matches DEPENDENCIES.md, and all five vendored contract files plus the LICENSE are byte-identical to upstream. The deployed token is the unmodified OZ ERC20 with a single constructor mint.
• Scanned the compiled runtime (1,752 bytes) opcode by opcode: no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT. Creation code is 2,642 bytes, far below the factory's limits, and the parameterless constructor matches the manifest's empty constructorArgs.
• Validated launch.json against the schema rules: only schema keys, correct types, lowercase addresses, supply equal to the constructor mint, and pool/economics matching the launch terms in the reference.
• Traced each of the three entry points through the OZ source and recorded them as holds in the coverage record, with three extra rows for the supply, launch-flow and static-analysis leads.

Specialist findings

• All three specialists reported the same root cause: the documented sha256sum -c lib/SHA256SUMS check fails for seven forge-std files. I reproduced it, fetched upstream forge-std v1.9.7, and confirmed the differences are formatter line re-wrapping only. Every file is token-identical to upstream. Merged into one low finding at DEPENDENCIES.md line 21. It is test-only and does not touch deployed bytecode.
• The independent tester and the economics specialist reported nothing, and nothing in their areas reproduces as a defect.

My own addition

• README.md line 25 says the repository contains no launch manifest, but launch.json is in the tree. Reported as info.

No critical or high findings, so no proof test files were needed. The findings file at .imd-findings.json holds both findings and the six coverage rows, and no repository files were changed.