The SwarmCoreIMD token project is complete and verified. Build, tests, and format check all pass with the pinned compiler.

What was delivered

• src/SwarmCoreIMD.sol is a fixed-supply ERC-20 on unmodified OpenZeppelin v5.4.0. The constructor takes no arguments and mints the full 1,000,000,000 tokens with 18 decimals to the deployer, which on the launch is the factory. There is no owner, mint, burn, pause, blacklist, fee, or any other privileged function.
• test/SwarmCoreIMD.t.sol holds 32 tests: metadata and supply constants, constructor events, CREATE2 deployment with no arguments, standard transfer and allowance success paths, revert paths for overdraft, missing allowance, zero-address receiver and zero spender, the whole admin-selector list from the protected floor test rejected from both stranger and deployer, the three launch flows arriving whole, three fuzz tests for supply conservation, and a runtime scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• script/DeploySwarmCoreIMD.s.sol exposes a deploy() function the tests call directly. It reads no environment variables.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables ffi and filesystem access, and defines the remappings.
• README.md documents behaviour, assumptions, deployment parameters, an empty "After launch" section, and operational responsibilities including audit status.

Dependencies are vendored as plain files under lib/, with no nested git metadata or .gitmodules. A clean rebuild with --offline succeeds, and the artifact has empty link references and no metadata hash.

Results

Check	Result
forge build	success
forge test	32 passed, 0 failed
forge fmt --check	clean
runtime size	2287 bytes

I did not run git commit, since .git/ is off limits and the harness handles the commit and upload. A dry-run git add confirms all project files and the 371 vendored library files would be included.

I found no access-control, trust-gap or asymmetry defects in SwarmCoreIMD, so .imd-findings.json holds an empty findings list plus a coverage record. The file is valid JSON, and no source, test, script or config file was changed.

What I checked:

• Source: src/SwarmCoreIMD.sol builds on OpenZeppelin's standard ERC20 (v5.4.0). I read the copy in lib/ and it behaves as the stock contract should. The token adds only constants, an INITIAL_HOLDER value that nothing depends on, a fixed decimals() of 18, and a constructor. That constructor takes no arguments, makes no external calls and mints 1_000_000_000 * 10**18 once to msg.sender (the factory).
• Access control: there is no owner, minter, pauser, blacklist, fee, burn or exemption list. No outside call can create or destroy tokens. The deployer has no special rights over other holders, and there is no function that receives ETH or catches unknown calls, so both revert.
• Trust gap and asymmetry: approve only ever sets the caller's own allowance. transferFrom checks the allowance before moving anything, and no caller, the factory included, can skip that check. Every transfer moves exactly the requested amount, so the launch flows to the distributor and the pool manager arrive in full. The launch rules' ban on privileged moves, freezes and supply growth is met.
• Static-analysis leads: the aderyn note at line 30 just flags a large written-out number (1_000_000_000), which is not a defect. Slither reported nothing.
• Tests: the project's existing 32 Foundry tests pass. I wrote no proof tests, because there was no finding to prove.

Coverage record: approve, transfer and transferFrom are each marked holds. Further holds rows cover four properties: no privileged role exists, the supply is fixed, decimals match the launch spec, and neither the constructor nor plain ETH sends hand anyone extra power.

Not covered: I didn't work through the other nine specialty guides beyond what touches access control. The token's few functions leave little else to check.

I found no defects in the math, boundary or numerical-gap areas for SwarmCoreIMD. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all holds.

What there is to audit. The token has almost no arithmetic of its own. src/SwarmCoreIMD.sol is a standard OpenZeppelin 5.4.0 ERC-20 that adds only:

• the supply constant, 1_000_000_000 * 10**18 = 1e27, which is far too small to overflow;
• decimals() fixed at 18;
• a constructor that mints the whole supply once, to the deployer.

I compared the vendored OpenZeppelin files the token uses against the npm @openzeppelin/contracts@5.4.0 package, and they are identical. So the transfer and approval code is the standard library code, unmodified.

Checked against the three guides:

• Math Precision: there is no division, rounding, cast or scale conversion anywhere. The two places OpenZeppelin skips overflow checks are both safe: a balance is checked before it is reduced, and an allowance is checked before it is spent. No credit can exceed the fixed total of 1e27.
• Boundary: the token makes no external calls and has no payable functions. Zero amounts, transferring a whole balance, transferring to yourself, the maximum ("unlimited") allowance, and the zero address as recipient or spender all behave as the ERC-20 standard says.
• Numerical Gap: the sum of all balances always equals the total supply, every transfer moves exactly the amount requested, and nothing outside the constructor can create new tokens. There is also no burn function, so the supply never changes.

Coverage: approve, transfer and transferFrom are all holds. I added two extra rows for the supply constant and for "the supply can never grow."

Static analysis: aderyn's one note (a large number at src/SwarmCoreIMD.sol:30) is just the supply value written out. It's correct and harmless, so I didn't report it.

The project's own 32 tests pass. I didn't run the protected launch test, because it needs launch environment variables and source files that aren't in this tree.

I changed no project files. Some untracked dotfiles (.bashrc, .claude/, .gitmodules and others) appear in git status; they were already there and I didn't create them.

I wrote launch.json for the SwarmCoreIMD launch, and it is the only file changed in the tree.

What the manifest says

• Token: contract SwarmCoreIMD, name SwarmCoreIMD, symbol SWARMCORE, 18 decimals, empty constructorArgs. The accepted constructor takes no parameters and mints the whole supply to msg.sender.
• totalSupply is "1000000000000000000000000000", the constant the constructor mints.
• contracts is an empty list. The accepted tree has no application contracts, only the token, its reference deploy script and tests.
• pool and economics are copied exactly from the launch reference. IMD pair address in lowercase, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's verbatim economics object.
• notes describe only what is in the accepted source: an unmodified OpenZeppelin ERC20 with no privileged surface, no tax or burn, so every launch flow arrives whole.

Verification

• A scratch test deployed the raw creation code with nothing appended, from a stand-in factory address, and confirmed the minted supply, recipient, decimals, name and symbol match the manifest.
• A structural check confirmed the schema keys only, string types for uint256 and address fields, integer types for fee, tickSpacing and decimals, and economics equal to the job's object.
• forge build succeeded and forge test passed all 33 tests, including the scratch test.
• Git status shows launch.json as the only new file. The scratch test lives in test/scratch and is not part of the submission.

The review is complete. The findings file is written and validated, the scratch directory is removed, and the quoted snippet matches the tree.

Outcome: SwarmCoreIMD has no economic, invariant or flow-gap defect. It is an unmodified OpenZeppelin v5.4.0 ERC20 with a single constructor mint of 1e27 units to the deployer, no owner, no hooks, no external calls, and no fallback surface. I recorded one informational note and nine coverage rows in .imd-findings.json.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Conservation. Sum of balances always equals totalSupply, and totalSupply can only be written by the constructor. A fuzzed transfer and transferFrom sequence confirmed this.
• Supply growth. No selector reaches a mint path. The protected test's admin selectors all revert because there is no fallback or receive.
• Launch flows. Ten percent to the distributor, the pool seed, and the remainder each arrive whole, because no address is taxed or exempted. A trader can buy and sell without the token interfering.
• Dependencies and sentinels. The token holds no other asset, makes no external calls, and reverts on zero-address approve or transfer and on any ETH sent to it.
• Vendored library. The ERC20 body matches stock OpenZeppelin v5.4.0.

The one recorded item is the inherent ERC-20 approve race, filed as info rather than as a defect. Lowering a non-zero allowance can be front-run so a spender moves the old amount plus the new one. I verified it with a test where the spender moved 150e18 when the holder meant at most 100e18 then 50e18. The README already advises exact approvals, and fixing it would mean departing from plain ERC-20, which the brief did not ask for.

Coverage. All three entry points have rows: approve is marked finding with reference 1, transfer and transferFrom hold. Six additional rows record the invariants and flows I traced. Nothing in the assigned area was left unreached. The aderyn "large numeric literal" lead on line 30 is a style note with no behavioural effect, since the constant evaluates to exactly one billion and is covered by the existing supply tests.

The findings file is in place at the repository root and is excluded from git by the harness's own exclude file, as intended. No source files were changed, and the scratch directory was removed.

Result: no exploitable defect found. The token is an unmodified OpenZeppelin v5.4.0 ERC20 with a single constructor mint, and every entry point behaves as the brief requires. One informational note was recorded.

What I covered in the assigned area:

• Execution Trace. Traced approve, transfer and transferFrom from entry to storage through the vendored base. Zero-address, overdraft, insufficient-allowance, infinite-allowance, self-transfer and zero-value paths all behave as documented. No sentinel bypass, no stale read, no partial update, no external call anywhere.
• Periphery. Hashed the five OpenZeppelin files the token depends on against upstream v5.4.0 fetched from GitHub. All five match byte for byte. The vendored tree has no nested git directory or submodule, and all 371 library files are tracked as plain files.
• First Principles. Checked the supply constant arithmetic, the deployer identity assumption under CREATE2 from the factory, the absence of any privileged surface in the ABI, and the launch flows. Nothing taxes or burns, so the swarm share, pool seed, claims and swaps move exact amounts.
• Static analysis lead. The aderyn large-literal note on line 30 is a style remark only. The constant equals exactly 1,000,000,000 and the derived supply is correct.

The informational finding is that INITIAL_HOLDER is an immutable, so the deployer address is embedded in the runtime bytecode. A scratch test showed two deployers produce two different runtime hashes, and neither equals the compiler's deployed bytecode. This only matters if any attestation step derives the runtime hash from a local compile rather than from a deployment at the factory address. It is not a behavioural defect and needs no change unless that comparison is compile-based.

The coverage record answers all three listed entry points as holds, plus rows for the constructor, decimals, three invariants, the vendored base and the deploy script. Existing tests pass, 32 of 32.

Added failure-path, boundary, fuzz, and stateful invariant tests under test/.

Offline forge build and forge test passed: 57 tests, including 32,768 random handler calls checking supply, balances, and allowances.

No defects found. Only three files under test/ were added.

I found nothing to report: the review of SwarmCoreIMD (SWARMCORE) has no reproducible defects. .imd-findings.json has an empty findings list and a coverage record for all three entry points.

Code reviewed. src/SwarmCoreIMD.sol is the OpenZeppelin v5.4.0 ERC20, unmodified. The only additions are the name/symbol/decimals constants, an INITIAL_HOLDER immutable, and a constructor that mints 1,000,000,000 × 10^18 to msg.sender once. I read the vendored ERC20.sol and Context.sol to make sure the library itself hadn't been altered. It hadn't.

Checks run. The project builds, and all 57 existing tests pass. The deployed code is about 2.3 KB and the creation code about 3.5 KB, well under the size limits. The constructor needs no arguments, no particular address bits and no linked libraries, so the factory's CREATE2 deployment works.

Coverage, every row holds:

• approve: it overwrites the allowance, rejects the zero address and emits Approval.
• transfer: it moves exactly the amount asked, with no fee, burn or exemptions. So the swarm's 10% to the distributor, the pool seed, the remainder and trader swaps all arrive in full.
• transferFrom: it checks and reduces the allowance (except an unlimited one), then does the same exact-amount transfer. No privileged caller can move a holder's tokens.
• Supply: it can't grow, because there's no mint function after the constructor. It equals totalSupply in launch.json, which correctly lists no constructor arguments.

Specialist findings dropped. Both reproduce, but neither is a defect in this code:

1. Approve race (audit_economics, info). Lowering an allowance can be front-run so the spender moves both the old and the new amount. That is how every ERC-20 works; the README already tells holders to approve exact amounts to trusted spenders. Changing it would mean departing from the standard, which the brief didn't ask for.
2. INITIAL_HOLDER makes the deployed bytes depend on the deployer (audit_flow, info). True, but the launch always deploys from the same factory address, so the launch's deployed code is fixed and the factory-address harness gets the same bytes. The claimed failure needs a compile-only runtime-hash comparison, which the finding itself only hypothesised.

Static analysis. The one aderyn line, a large numeric literal at line 30, is the supply constant written with digit separators. It isn't a defect.

The only file I wrote is .imd-findings.json; git status shows no changes to tracked files. That file appears in neither the git status output nor the repo's .gitignore, so a global ignore rule probably hides it. It is on disk and reads as valid JSON.