The deliverable is written, but I could not compile or run it: every shell command in this session fails before it starts with this sandbox error, including background runs and the no-sandbox flag:

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

So forge build, forge test and forge fmt --check were not run here. The code was desk-checked line by line against the pinned protected tests and the Solidity 0.8.26 rules, and it was kept deliberately small and library-free to minimise the chance of a compile error I could not see.

What was built

• src/SwarmCore.sol holds contract SwarmCore, a fixed-supply ERC-20. The name is SwarmCore, the symbol SWARMCORE, 18 decimals, and the constructor mints the whole 1,000,000,000-token supply to msg.sender once and emits the mint Transfer. It takes no constructor arguments and calls no contract, so it deploys on an empty chain.
• There is no owner, mint, burn, pause, blacklist, fee or upgrade path. totalSupply() returns a compile-time constant, unlimited allowances are not decremented, and failures revert with OpenZeppelin-v5-style custom errors. The contract has no receive or fallback.
• src/interfaces/IERC20.sol is the interface it implements.
• foundry.toml pins solc 0.8.26, cancun, optimizer 200 runs, bytecode_hash = "none", no ffi, no fs permissions.
• test/SwarmCore.t.sol has 27 tests: metadata and supply, CREATE2 deployment from a factory stub so the supply lands on the deploying contract, transfer and transferFrom success paths with event checks, each revert path with the exact custom error, a launch-flow test moving the 10/80/10 split and a whole claim, the protected suite's no-admin and no-freeze probes, ether rejection, an opcode scan for DELEGATECALL/CALLCODE/SELFDESTRUCT, and five bounded fuzz tests.
• The tests vendor no library. test/utils/Vm.sol declares the cheatcode signatures used and test/utils/TestBase.sol provides reverting assertions and a bound helper, so the verifier needs no lib/ and no network.
• README.md documents assumptions, the manifest values, named constants, an empty "After launch" section, operational responsibilities and the security checklist review.

What is unverified

The three acceptance commands never ran on this machine because of the shell failure above. If the verifier's build fails, the most likely spots are the test file's overloaded assertEq calls and the @notice tags on state variables, both of which I checked but could not compile.

Done. The manifest is written and verified, and nothing else in the tree changed.

What I wrote

launch.json at the repository root describes the accepted tree exactly:

• Token: contract SwarmCore, name SwarmCore, symbol SWARMCORE, 18 decimals, empty constructorArgs. The constructor in src/SwarmCore.sol takes no parameters and mints the whole supply to msg.sender.
• totalSupply: the string for 1,000,000,000 tokens in minor units, matching the contract's TOTAL_SUPPLY constant.
• contracts: empty. The accepted tree has no application contracts, so none are named.
• pool and economics: copied verbatim from the launch reference, with the IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes: a single string under 4,000 characters describing the fixed supply, the absence of privileged functions, and why no exemption placeholders are needed.

Verification

• forge build compiles cleanly on solc 0.8.26.
• forge test with the verifier's fuzz seed passes all 30 tests.
• A node script confirmed the manifest parses, has only schema keys, and matches the required supply, pool and economics values.
• git status --porcelain shows launch.json as the only new or changed file. No scratch files remain.

Review complete. No defects were substantiated in the SwarmCore token under the Economic Security, Invariant and Flow Gap guides, and .imd-findings.json holds an empty findings list with a full coverage record.

What was checked

• Economic Security. The token has no external dependencies, oracles, callbacks or sentinel branches. There is no fee, rebase, pause or blacklist path, so no leg of the launch flow can arrive short. ERC-20 compliance holds for every entry point, including max-allowance pulls of the whole balance and zero-value transfers.
• Invariants. The sum of balances equals the constant total supply of 1e27 after any sequence of calls. I verified this with a scratch fuzz test running 2000 random 24-step sequences of transfer, approve and transferFrom among six actors, including self-transfers and self-approvals. Allowance decreases exactly, and the unlimited allowance stays untouched.
• Flow Gap. The factory to distributor, distributor to claimant, factory to PoolManager (both push and pull via transferFrom) and trader buy-and-sell legs all move the exact amount requested. The constructor takes no arguments and mints the full supply to the deploying contract, matching the protected launch test's checks.
• Bytecode. The compiled runtime contains no CALL, STATICCALL, CREATE, DELEGATECALL, CALLCODE or SELFDESTRUCT, and the contract has no receive or fallback.
• Static-analysis lead. The aderyn large-literal note on line 24 is a compile-time constant equal to the brief's supply. Not a defect.

Coverage record has rows for all three ABI entry points, each marked holds, plus four invariant rows. The only design property worth the author's awareness is the standard approve overwrite race, which the README already documents and which is not a defect of this implementation. The scratch test directory was removed, so the tree is unchanged apart from the findings file.

The review is complete and the report is written. No defects were found.

Outcome. .imd-findings.json holds an empty findings list and nine coverage rows: one for each of the three listed entry points plus the constructor, four invariants, the periphery files, and the aderyn lead. The working tree is untouched apart from the findings file and a scratch test, which is gitignored and not kept.

What I checked. SwarmCore is a 135-line fixed-supply ERC-20 with no constructor arguments, no external calls, no owner, and no storage beyond balances and allowances. I applied the Execution Trace, Periphery and First Principles guides and the Senior Auditor's Mindset to every state-changing path:

• transfer and transferFrom revert before any write on a zero receiver, short balance or short allowance. The unchecked arithmetic is safe because balances always sum to the constant supply. Self-transfers and self-transferFrom net to no change. A reverted balance check rolls back the allowance decrement, so there is no partial state.
• transferFrom from the zero address cannot mint: approve refuses a zero owner, so that allowance is always zero, and a zero-value attempt still hits the invalid-sender revert.
• approve is standard overwrite semantics. The front-running race is inherent to ERC-20 and documented in the README, so it is not reported.
• Launch flows move exact amounts because nothing taxes, burns, hooks or branches on balance. The compiled ABI contains only the standard surface plus two constant getters, so no privileged call exists.
• Periphery is just the IERC20 interface and non-deployed test helpers. Both are sound.

Verification run. The shipped suite passes 30 of 30 tests. My scratch suite of 8 additional edge and fuzz tests also passes, including a random-sequence fuzz that confirms supply conservation. Formatting of the shipped files is clean. The one static-analysis lead is a compile-time literal equal to the brief's supply and is not a defect.

Not reached. Nothing within the assigned area was left unexamined. I did not run the protected v4 pool harness, since it needs the launch environment variables and the v4-core library that this repository does not vendor.

The review is complete and the findings file is written. No defects were found in the assigned area.

Outcome: .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three state-changing entry points plus five invariant and boundary rows. The working tree is otherwise unchanged (the scratch test I used was deleted).

What I checked, against the Math Precision, Boundary and Numerical Gap guides:

• Arithmetic. The contract has no division, multiplication by user input, casts or scale conversion. The only arithmetic is the balance subtraction and addition in _transfer and the allowance subtraction in _spendAllowance. Each unchecked subtraction is preceded by the matching less-than guard, and the recipient addition cannot overflow because the sum of balances is the constant supply and nothing mints or burns.
• The supply constant. A literal base with a non-literal exponent is evaluated in uint256, so TOTAL_SUPPLY is exactly 1e27 and matches the manifest value. The aderyn large-literal line is a style note only.
• Boundaries. Zero amounts, whole balance, balance plus one, uint256 max, self-transfer through both transfer and transferFrom, allowance of max (unlimited, never decreased) and max minus one (decreased), transfers from the zero address, and approvals from or to the zero address all behave as ERC-20 and OpenZeppelin v5 require. The runtime bytecode contains no CALL, STATICCALL, DELEGATECALL, CALLCODE or SELFDESTRUCT, and nothing is payable, so the Boundary guide's external-call, sentinel and bytes-decoding steps have no targets.
• Numerical seams. With no rounding anywhere, no precision-times-invariant or boundary-times-precision seam exists. Supply conservation was fuzzed across eight actors with 2000 runs and held.

Verification run: the project's 30 tests pass, forge fmt --check is clean on the committed sources, and my 12 scratch edge-case tests passed before I removed them.

Not reported as a finding: approve overwrites the allowance with no increase or decrease helpers. That is the standard ERC-20 race, identical to OpenZeppelin v5 and documented in the README, so it is recorded as a coverage note rather than a defect.

The review is complete. No defect was found in the assigned area, and the findings file records that with full coverage.

Outcome. The findings file at .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three listed entry points, one for the constructor, and four for the invariants I checked. No tracked file was changed. The only thing I wrote outside the findings file is a scratch test under test/scratch/, which git ignores.

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

• Permission model. The contract has no role, modifier, owner, initializer, fallback or receive, and no slot that gates a caller. The constructor hands out nothing but the supply to its caller. The deployer, once it transfers out, is an ordinary holder and cannot pull from anyone without an allowance.
• Inconsistent guards. Balances are written only by the internal transfer path, and allowances by approve and by the allowance spend in transferFrom. The spend path checks the same slot approve writes, so there is no weaker writer.
• Paired surfaces. approve against transferFrom, and transfer against transferFrom, were diffed line by line. The unlimited allowance branch skips the decrement but still enforces balance. A balance revert leaves the allowance untouched. Self transfer re-reads storage, so the unchecked block cannot overflow.
• Trust gap seams. There is no privileged actor and no economic formula, so no access-by-economics or access-by-asymmetry seam exists.
• Launch floor. No fee, burn or exemption list, so every launch flow moves exactly what it says, and nothing can grow the supply.

How it was verified. The project's own suite passes, and its fuzz tests pass at 2,000 runs with a fixed seed. My scratch suite adds seven checks covering self-transferFrom without allowance, zero-address sender and approver paths, revert ordering, the max-allowance branch, residual deployer power, and conservation of the balance sum under random 24-step sequences across four actors. All pass.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is the supply constant, which is written with digit separators and matches the brief exactly, so it is not a defect.

Not reached. Nothing in the assigned area was left unexamined. I did not review the launch manifest, since none exists yet in this tree.

Done. The full suite builds and passes with the verifier's fuzz seed, and I found no defect in the token, so there is no findings file.

What was there. The earlier contributor's file covers metadata, supply, transfer and allowance paths with explicit error checks, plus stateless fuzz. It had no invariant tests and the repo vendors no forge-std.

What I added, both under test/ only:

• test/SwarmCore.invariant.t.sol is a handler-driven invariant suite that needs no forge-std. The test contract exposes the target-contract and target-selector getters forge reads, so only the handler is fuzzed. The handler has five actors plus the token itself as a sink, a ghost ledger of inflows, outflows and allowances built from call inputs only, and seven expected-failure handlers that use low-level calls and check the exact revert data. It runs with fail-on-revert on, so any stray revert in a sequence is itself a failure. Invariants: fixed supply, balances sum to supply, every balance equals its ledger entry, every allowance equals its ledger entry, no balance above supply, constant metadata, no ether and no lost code. A fixed-sequence smoke test shows every handler path is reachable.
• test/SwarmCore.edges.t.sol covers inputs the first file skipped: the zero address as sender, approver and spender, the allowance exactly one below unlimited, pulls to the owner and to the spender, the constructor's mint event, a deployment observed from inside one transaction, unknown selectors and empty calldata, ether sent to non-payable functions, and four property tests including an outcome oracle for transfer over arbitrary addresses and amounts.

Grounding. I ran the invariant suite against two mutated copies of the token in scratch: one that breaks self-transfers through a stale cached balance, one that stops decreasing allowances. Both were caught on the first run. The scratch directory is removed.

Results with the verifier's seed:

Suite	Tests	Result
SwarmCoreTest (existing)	30	pass
SwarmCoreEdgesTest	24	pass
SwarmCoreInvariantTest	2 (6 invariants + smoke)	pass, 0 reverts across all handlers

No configuration, source or library file was touched. Formatting was applied with forge fmt to the two new files.

The review is complete. .imd-findings.json holds an empty findings list and an eight-row coverage record. No tracked file was changed, and the scratch test directory was removed.

Outcome: no defect reproduced. All five specialists reported nothing, and my own pass agrees.

What I checked:

• The three entry points in src/SwarmCore.sol. transfer, approve and transferFrom follow OpenZeppelin v5 semantics. The unchecked arithmetic is safe because balances always sum to the constant supply. A self-transfer re-reads the recipient balance after the debit, so it leaves the balance unchanged. The unlimited-allowance special case applies only to the exact maximum.
• Constructor and supply. No arguments, one mint of exactly 1e27 minor units to the caller, and no function other than the internal transfer writes a balance. The manifest's totalSupply, decimals and empty constructorArgs match the compiled ABI.
• Deployability. Creation code is 2220 bytes and runtime 1775, far under the limits. My opcode scan of both found no DELEGATECALL, CALLCODE, SELFDESTRUCT, or any external call, and no library linking.
• Static analysis leads. Slither reported nothing. The aderyn large-literal note on line 24 evaluates to exactly 1e27 and is informational only.
• Tests. The project's 56 tests pass, including 1000-run fuzz and 256x64 fail-on-revert invariant suites. I also ran one scratch test covering self-transfer, self-pull via allowance and a full-supply round trip, which passed, then deleted it.
• Manifest. launch.json uses only schema keys, lowercase addresses, correct number and string types, and notes under the length limit. I could not compare the economics block against the original job text, since that is not in the tree.