The SwarmCore token project is written and complete, but I could not run forge on this machine: every Bash command failed before starting with the sandbox error below, so build, test and fmt checks are unverified here.

apply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied

What was delivered (all at the repository root, self-contained, no vendored dependencies):

• src/SwarmCore.sol is a plain fixed-supply ERC-20. The constructor takes no arguments, calls nothing, and mints 1,000,000,000 × 10^18 to msg.sender once. There is no owner, mint, burn, pause, blocklist, fee, delegatecall or selfdestruct, and failures revert with ERC-6093 custom errors. This satisfies every check in the pinned protected floor test: exact launch flows, no supply growth, no privileged hand, no forbidden opcodes.
• test/SwarmCore.t.sol holds 29 tests covering metadata, the single mint event, transfer and transferFrom success and failure paths, allowance semantics including the unlimited case, the same admin and freeze selector lists the floor uses, the launch flows arriving whole, the opcode scan, and five fuzz tests on supply conservation and revert bounds.
• test/utils/Harness.sol declares the handful of cheatcodes used against the hevm cheatcode address and a small assertion base, so no lib/ or submodule is needed and the offline verifier has nothing to resolve.
• foundry.toml pins solc 0.8.26, sets bytecode_hash to none, keeps ffi off and fs_permissions empty.
• README.md documents assumptions, the launch's deployment parameters, the empty "After launch" section, operational responsibilities and the security checklist mapping.

What is unverified. The code was reviewed by eye for compile errors, overload resolution and fuzz bounds, but forge build, forge test and forge fmt --check never ran because the shell sandbox could not start. If the verifier's run surfaces a compile error, the most likely spots are the hand-declared Vm interface in the harness and the inline string array literals in the two selector-list tests. Slither and Mythril were not available and were not run.

Done. I wrote launch.json as the only new file; nothing else in the tree changed.

What the manifest says

• Kind is custom_token, token contract SwarmCore, name SwarmCore, symbol SWARMCORE, 18 decimals.
• Constructor arguments are an empty list, matching the accepted contract's argument-free constructor.
• Total supply is the exact amount the constructor mints to the deployer, in minor units.
• The contracts list is empty, since the accepted tree contains only the token and no application contracts.
• Pool and economics are copied verbatim from the launch reference: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• Notes describe the fixed supply, the absence of owner or transfer rules, and why no launch placeholders are needed.

Verification

• The file parses as JSON with only the six schema keys, and the notes are well under the 4,000 character limit.
• The supply string and economics object were checked programmatically against the expected values.
• The build compiles cleanly and all 30 tests pass with the verifier's fuzz seed.
• git status shows launch.json as the only change.

The findings file is valid, the cited snippet matches line 103 exactly, and the scratch directory is removed. The tree shows no changes to tracked files; only the untracked .imd-findings.json output exists.

Review result

No math, boundary or numerical-gap defect found in SwarmCore. The token has no division, no runtime multiplication, no external calls, no payable path and no bytes decoding, so most failure modes in the three guides have nothing to attach to. One informational divergence from the ERC-20 reference is recorded.

What I verified

• The supply literal on line 34 is a compile-time constant equal to exactly 1e27. This closes the aderyn large-numeric-literal lead.
• The unchecked subtraction in _transfer is guarded by the balance check, and the unchecked addition cannot wrap because balances always sum to the fixed supply. Whole-balance self-transfer, zero value, and a value of max uint256 all behave correctly.
• Allowance handling holds at every edge. Max is unlimited and never decremented, max minus one is finite and decremented, and the balance check still governs under an unlimited allowance.
• A fuzzed sum-of-balances invariant over 8-step transfer chains with self-transfers passed 256 runs. The existing 30-test suite also passes.

One informational finding

transferFrom(address(0), to, 0) succeeds for any caller and emits a zero-value Transfer from the zero address, which has the exact shape of a mint event. OpenZeppelin v5 rejects this with ERC20InvalidSender. No tokens move and the supply is a constant, so the only effect is spurious zero-value mint events for indexers. The suggested fix is a single from == address(0) check at the top of _transfer.

Coverage has rows for all three entry points plus four invariant rows. One limit: the protected pool-seed and swap test could not be run here because v4-core and the platform's launch sources are not vendored in this tree. The token transfers exact amounts, so nothing in my area threatens those flows.

The review is complete and .imd-findings.json is written. It validates as JSON, the snippet matches the tree at the cited line, and the scratch tests are removed so the working tree holds only the findings file.

Outcome. SwarmCore holds up against the Economic Security, Invariant and Flow Gap guides. One low-severity defect was substantiated, no critical, high or medium.

Finding 1, low. transferFrom(address(0), to, 0) succeeds for any caller and emits a zero-value Transfer from the zero address. The allowance check passes because zero is not less than zero, and _transfer only rejects a zero to. The contract says its errors follow OpenZeppelin v5's ERC-6093 set, but it lacks the ERC20InvalidSender guard that set includes. No balance or supply changes, so the harm is confined to indexers and explorers that treat transfers from zero as mints. Reproduced with a Foundry test capturing the log, with a control showing value 1 reverts as expected. The suggested fix is a one-line sender check in _transfer.

Coverage. All three entry points have rows. approve and transfer hold. transferFrom carries the finding. I added rows for the invariants I checked: sum of balances equals the fixed supply under fuzzed random walks, no path grows or privilege-moves the supply, the launch flows arrive whole without exemptions, and the sentinel and dependency checks. The supply constant matches the manifest string in the README.

Checks run. The project's 30 tests pass. My scratch probes passed on the quirk, self-transferFrom conservation, a four-actor random walk, and the max-minus-one allowance decrement. Both static analysis leads were benign: Slither reported nothing, and the aderyn large-literal note is the supply constant itself.

Not reached. Nothing in the assigned area was left unexamined. The real PoolManager seed and swap could not be executed here since the protected harness imports v4-core and forge-std, which this repository does not vendor. The token's exact-transfer semantics make that flow mechanical, and the floor's own tests exercise it.

The review is complete. The findings file is written and validated, the snippet matches the source lines exactly, and the scratch test is removed so the tree is unchanged.

Outcome. SwarmCore holds up under the Access Control, Trust Gap and Asymmetry guides. One informational finding is recorded, nothing at medium or above.

What I checked

• Access control. The token has no owner, roles, modifiers, initializer, fallback or receive. Every state write is gated on the caller's own balance or allowance. The deployer cannot pull from a holder, and a holder cannot pull from the deployer. This was confirmed by the project's 30 tests and my own scratch test.
• Trust gap. There is no privileged actor, no price or fee formula and no settable parameter, so none of the four seams has an actor or value flow to combine.
• Asymmetry. I diffed approve against _spendAllowance, transfer against transferFrom, and all writers and readers of the two mappings. The only mismatch is the finding below.
• Launch floor. The constructor takes no arguments, calls nothing, and mints exactly the manifest supply to msg.sender. Transfers move whole amounts, so the distributor, pool seed and swap flows arrive exact. The opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT passes.
• Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on the supply constant is a style remark, not a defect.

The one finding (info). The function transferFrom accepts the zero address as the sender when the value is zero. The allowance check passes because zero is not below zero, and the balance check passes the same way. Any unprivileged caller can therefore emit a mint-shaped event of the form Transfer from the zero address to any target with value zero. No balance or supply changes. OpenZeppelin v5, whose error names the contract adopts, rejects this path with ERC20InvalidSender. A non-zero value on the same path is correctly refused by the allowance check. I verified both with a Foundry test before reporting.

Coverage. All three ABI entry points have rows. The approve and transfer rows hold. The transferFrom row points to the info finding. Four further rows record the constructor, the no-privileged-role invariant, the supply conservation invariant, the opcode invariant and the trust-gap seams, all holding.

Not reached. Nothing within the assigned area was left unexamined. I did not exercise a live Uniswap v4 PoolManager swap, since the protected floor test does that with its own harness and the token has no transfer rules that could affect it.

The review is complete and the findings file is written.

Result: no defects found. .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three state-changing entry points plus the constructor and four invariant and periphery rows.

What I checked, against the Execution Trace, Periphery and First Principles guides:

• transfer and transferFrom reject the zero receiver, check balance before the unchecked subtraction, and handle self-transfers correctly despite the cached balance read. No external calls exist, so there are no stale reads, callbacks or untrusted return values.
• approve overwrites rather than adds, rejects a zero spender, and the unlimited-allowance sentinel in _spendAllowance only skips the decrement, never the balance check.
• The constructor mints exactly 1e27 to msg.sender, which I confirmed equals the README literal, with one Transfer event and no arguments.
• The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, and in fact no CALL, STATICCALL or CREATE at all. Storage holds only balances and allowances, so there is no owner or pause slot to abuse.
• A scratch fuzz suite I wrote and then removed ran 256 interleaved sequences of transfer, approve and transferFrom across four actors and always conserved the supply. Settle-style balance-difference checks showed exact arrivals for the launch flows.
• The test harness in test/utils/Harness.sol was reviewed as periphery. Its cheatcode signatures, bound helper and opcode scanner are correct, and all 30 project tests plus forge fmt --check pass on forge 1.8.3.

Not run locally: a real Uniswap v4 PoolManager seed and swap, since the tree has no lib/. The token has no code path that could make those flows differ from a plain transfer, and the protected floor tests exercise them.

The approve front-running race is inherent to ERC-20, is documented in the README, and is not reported as a defect. The static-analysis lead about a large numeric literal resolved to the correct value.

Done. The suite builds and passes with the verifier's seed: 55 tests across three files, no failures.

What I added (all under test/, nothing else touched):

• test/SwarmCore.invariant.t.sol: a handler that drives the token from a closed set of 8 actors (deployer, holders, a distributor and claimant stand-in, a spender, a cold wallet) with bounded inputs and a ghost ledger of balances, allowances, inflows and outflows. Happy paths are mirrored in the ledger. Failure paths (transfer above balance, to the zero address, transferFrom above allowance or balance, approving the zero spender, any selector outside the ERC-20 interface) are asserted to revert with the exact ERC-6093 error and move nothing. Seven invariants run after every call: balances sum to the fixed supply, totalSupply and decimals never change, balances and allowances match the ledger, nobody holds more than they received, outsiders and the token itself hold nothing, and the deployer's balance equals supply less net outflow. Config is inline: 256 runs, depth 64, fail on revert.
• test/SwarmCore.edges.t.sol: 24 unit and fuzz tests for the inputs the existing suite did not pin. Allowance of max minus one is spent down, not treated as unlimited. Transfers of the maximum uint and supply plus one revert with the right arguments. The same transfer or transferFrom twice fails once exhausted. Allowance is checked before balance, receiver before balance. Self-approval, spender sending to itself, round trips to the owner. Truncated calldata, dirty address bits, empty calldata and random selectors are refused. A helper contract deploys the token and performs the three launch flows inside one constructor, so the launch is exercised as one transaction.
• test/utils/InvariantHarness.sol: the target-contract and target-selector plumbing forge's invariant runner reads, since the project deliberately vendors no forge-std.

Verification: I mutation-checked the invariant suite in scratch. A token that burns one wei per transfer fails at the first handler call. A token that treats an allowance of max minus one as unlimited was initially missed, so I added a near-unlimited approve path to the handler and a pinned unit test. Both mutants now fail the suite.

Finding reported in .imd-findings.json as info, not asserted in tests: transferFrom(address(0), anyone, 0) succeeds and emits a Transfer from the zero address, indistinguishable in shape from a mint. No balance or supply changes, so nothing of value is at risk. OpenZeppelin v5 rejects this with ERC20InvalidSender, and a one-line sender check in _transfer closes it. The repository's own exclude rule keeps that file out of git status, which is expected.

No defects of medium or higher severity were found in the token.

The review is complete and .imd-findings.json is written. No tracked files were changed; the scratch test under test/scratch/ is ignored by git and not part of the submission.

Outcome. One finding, severity low. All four specialists reported the same root cause, and I merged them into a single entry after reproducing it.

• The finding. _transfer in src/SwarmCore.sol rejects the zero address only as receiver, and the allowance check passes a zero value with a zero allowance. Any caller can therefore run a zero-value transferFrom with the zero address as sender and emit a mint-shaped Transfer event. Nothing moves on chain and the supply stays constant. The impact is limited to explorers and indexers that read Transfer-from-zero as issuance, which contradicts the contract's own NatSpec and the OpenZeppelin v5 semantics it claims. The one-line fix is a sender-zero check with an ERC20InvalidSender error.
• Reproduction. Confirmed with a scratch test using the project's own harness and recorded logs. The nonzero-value control reverts with ERC20InsufficientAllowance as expected, so this is the single input that slips past. No proof file is attached, since the severity is low and the tree vendors no forge-std.

Coverage. All three ABI entry points are answered: approve and transfer hold, transferFrom carries the finding. I also recorded rows for the supply invariant, the launch floor (argless constructor, 18 decimals, no CALL-family opcodes in the runtime), the manifest schema, and the aderyn numeric-literal lead, all of which hold. The project's existing 55 tests, including the invariant suite, pass on this code.