Implemented SWARM, the ETH swap contract, responsive website, tests, and deployment documentation.

Passed forge build, all 33 Foundry tests, forge fmt --check, eight frontend tests, and browser checks.

Ordinary transfers burn 1%; required launch, claim, and pool flows are exempt. Deployment addresses remain explicit placeholders. No transactions were broadcast.

See README.md for assumptions and launch responsibilities.

Created launch.json matching the accepted contracts and exact required economics, including the 1 ETH cap.

Only launch.json changed. Schema and constructor ABI checks passed. forge build succeeded; forge test passed all 33 tests.

Review complete. No tracked files were changed. The findings file is at .imd-findings.json with two substantiated findings and nine coverage rows covering all five listed entry points.

Findings

• Medium, burn-free transfers through the PoolManager. The exemption at src/Swarm.sol:49 waives the 1% burn for any transfer whose sender or recipient is the PoolManager, no matter who initiated it. Any unprivileged contract can run unlock, sync, transferFrom-in, settle, take-to-recipient and move SWARM wallet to wallet with zero burn. The same works through ERC-6909 claims. The README discloses this, but the brief's "every transfer burns 1%" is broken for anyone who deploys a short router. A hookless token cannot narrow the exemption without failing the protected buy, sell and seed checks, so the fix is a scope decision for the requester: accept it as a wallet-only burn or add an afterSwap hook. A self-contained proof test is attached and fails on the current code.

• Low, distributor exemption depends on a 30,000-gas registry budget. The factory and PoolManager are exempted by a plain address compare, but the distributor is exempted only if the staticcall at src/Swarm.sol:57 to the platform factory succeeds within the budget, and failure falls back to burning rather than reverting. A factory whose distributorOf costs more than the budget silently shorts every swarm claim by 1%. The scratch test shows a correctly answering registry at about 38,000 gas producing a claim of 99,000,000 instead of 100,000,000 SWARM. Typical mapping or proxy implementations fit, so this is conditional on unverified platform code.

Coverage

• Swarm.approve, SwarmSwap.swap and SwarmSwap.unlockCallback hold. The swap router binds the payer to the guarded caller, accepts callbacks only from the immutable manager during an active swap, settles exactly, and blocks reentry through the ETH take.
• Swarm.transfer and Swarm.transferFrom carry finding 1, and transfers by the distributor also touch finding 2.
• Constructor role handout, registry fallback shapes, router custody and the website approve and swap flow were traced and hold.
• The slither and aderyn leads on reentrancy, timestamp use and locked ether were checked and did not reproduce.

Not reached: the real ProjectFactory and MerkleDistributor code, which are not in the tree, so the factory and distributor exemptions remain documented trust assumptions rather than verified behaviour.

Added four test files under test/, covering failure paths, burn boundaries, allowances, settlement rollback, and randomized token/pool accounting.

• forge build passes.
• forge test passes: 61 tests, zero failures or skips.
• New invariant suites each exercise 24,576 calls.
• No reproducible contract defects found.

Only test/ files were added.

The review is complete. The findings file is written and validated, all five entry points plus five invariant and economics rows are covered, and the scratch tests are removed so the only file I left in the tree is .imd-findings.json.

What I found

• Low: the 1% burn is bypassable through the PoolManager. The exemption in src/Swarm.sol:49 keys on the PoolManager address alone. Anyone can unlock, sync, transfer SWARM to the manager, settle, and take to any recipient with zero burn, or mint ERC-6909 claims that then change hands without any token transfer. I reproduced both paths against the vendored v4 PoolManager: a direct transfer burned 1% and the routed one burned 0%. The exemption is required by the protected floor and the brief forbids a hook, so I framed this as a scope decision for the requester rather than a code fix.
• Low: the website ships the hookless pool key. The protected harness builds the launch pool with the platform's initialization-guard hook, but web/config.mjs:12 sets hooks to zero and the comment says it is not a placeholder. The hookless pool is permissionless, so a squatter can open it at any price. I reproduced that the swap contract's pool state for the shipped key returns the squatter's price, which the site would display and route trades against.

What held

Burn math and rounding, atomic rollback, allowance spending, the distributor and factory exemptions, the registry fallback, swap value binding, settlement checks, slippage, deadline, reentrancy, partial-fill handling, the supply and price economics in the manifest, and all four static-analysis leads traced clean. The existing 33-test suite passes.

One housekeeping note

My first write of the findings file went to a mistyped sibling directory outside the repo (hyphen instead of slash between the two IDs). That stray file exists but is on a path the sandbox cannot delete. It is outside the repository and does not affect the submission.

Review complete. The findings file is written at the repository root with two findings and ten coverage rows; the only other files I created are under test/scratch/, which is not kept.

What I found

• Medium, the 1% burn is bypassable. The exemption at src/Swarm.sol:49 waives the burn whenever the sender or recipient is the PoolManager, whoever initiated the transfer. Since v4's PoolManager is a permissionless ledger, anyone can move SWARM wallet-to-wallet inside an unlock by transferring in, calling settle, then take to the recipient. No pool needs to exist and nothing is swapped. The same route works through existing v4 routers' SETTLE and TAKE actions and through ERC-6909 claim tokens. The attached proof test fails on current code with a 1,000,000 SWARM transfer that burns nothing. The README already acknowledges this, and the exemption cannot be narrowed without breaking sells, so I framed it as a design decision the requester must make explicitly and disclose on the website rather than a code fix.
• Info, the manifest template is not schema-shaped. Six fields in deployment/parameters.json violate the canonical LaunchManifest schema, so the later manifest assignment must restructure it rather than fill in placeholders. The numeric values in it are correct, including the opening sqrt price.

What holds

Both swap entry points, approve, the constructor mint, every launch flow the protected floor requires, the registry lookup's failure modes, the absence of admin or forbidden opcodes, and the website's price and slippage math all traced clean. The static-analysis leads (locked ether, reentrancy, timestamp) are false positives: ETH is settled atomically or the whole swap reverts, the guard covers the callback window, and the timestamp is only a user deadline.

Not reached

I did not reproduce the ERC-6909 variant of the bypass separately, since one reproduction suffices, and I did not run the protected harness because it needs the network's environment and platform contracts.

The review is complete. The findings file is written and the working tree holds no other changes.

Outcome: the arithmetic holds. Across the Math Precision, Boundary and Numerical Gap checklists I found one deviation, and it is informational, not a defect that loses funds.

The one finding (info). The automatic burn is floor(amount / 100) at src/Swarm.sol:38. Transfers below 100 base units burn nothing, and every other transfer is under-charged by up to one unit, so the recipient gets slightly more than 99%. Concrete input: transfer 99 burns 0, transfer 199 burns 1 (0.50%). Evading the burn on one whole SWARM this way would take about 1e16 transactions, so there is no economic path and nothing compounds. The README already documents the rounding. It is recorded so the author can choose ceiling rounding if they want the brief's "1%" taken strictly.

What I verified and how. Each item was traced in source and then exercised with scratch Foundry tests against the real vendored v4 PoolManager:

• Burn path is atomic and gross-checked: with balance 100 a transfer of 101 reverts after the burn step rolls back. totalBurned stays monotonic and bounded by supply.
• Exemption lookup cannot be gas-starved into a short claim. A sweep of 40,001 gas limits from 5,000 to 45,000 showed every distributor claim either reverted or arrived whole.
• Router casts and deltas: v4 returns amountSpecified - remaining as the input delta, so the partial-fill check is exact. The output cast is guarded by a positive check, and amountIn is capped at the int128 maximum before negation.
• Size extremes: buys of 1 ETH, 1000 ETH and the full int128 maximum in wei all filled completely from the full-range seed and round-tripped within the two 0.3% fees. A one-unit sell whose output rounds to zero reverts without moving balances.
• Opening price: the manifest's sqrtPriceX96 is exactly 10,000 times 2^96, which gives 10 ETH for one billion SWARM. The website inverts it exactly in BigInt. The 16-tick gap between the opening tick and the harness range crosses at zero cost.
• Web quote math uses BigInt throughout, floors the minimum output, rejects zero and caps input at the contract bound. The eight node tests pass.

Static-analysis leads. The slither reentrancy and timestamp lines and the aderyn locked-ether and state-change lines were each traced and none reproduces: the swap is reentrancy-guarded, the router has no receive function, and payer is cleared after the unlock returns.

Coverage. All five listed entry points have rows, plus four invariant rows. Nothing in my area was left unreached. The deployed liquidity range and the platform's initialization guard hook are the platform's code, not in this tree, so their arithmetic is noted but not verified here.

The review is complete. The findings file is written at the repository root with five findings and a nine-row coverage record, the scratch tests are removed, and no tracked file changed.

What I did

• Built the project and ran the full suite: 61 tests pass on the current code.
• Ran both specialist proof files from a scratch directory. Both fail on this code for exactly the reason stated, confirming the burn bypass.
• Wrote my own scratch tests for the three remaining leads and the website pool key, then deleted them.
• Read the token, swap adapter, protected harness, manifest, README, and web code once more for anything the specialists missed.

Findings kept, ranked

1. Medium: the 1% burn is optional. Three specialists reported the same root cause at src/Swarm.sol line 49. Anyone can move SWARM wallet to wallet through the PoolManager's sync, settle and take path, or as ERC-6909 claims, for gas only. Both proofs fail on this code. I attached no proof test because no token-level fix exists that keeps the protected seed and sell flows, and the brief forbids a hook. The requester has to decide between disclosing the weaker guarantee or changing the design.
2. Low: the website ships a hookless pool key. The protected harness shows the platform pool carries the initialization-guard hook, so the shipped config points at a different pool. My test showed a squatter can initialize that hookless pool for about 3 gwei and the site would display and trade against it.
3. Low: the opening market cap disagrees across the tree. This one is mine. The manifest opens at 1 ETH and its notes say the job's economics object required that. The brief, README, parameters template and website footnote all say 10 ETH. I could not see the job's economics object, so I reported the contradiction and the evidence needed to settle it.
4. Low: the distributor exemption fails silently. A registry lookup that needs more than the hard-coded 30,000 gas burns 1% of every swarm claim with no revert. Reproduced with a stub costing about 39k gas against a mapping stub costing about 3k gas. Conditional on the platform factory, which is not in the tree.
5. Info: the burn rounds down. Transfers under 100 base units burn nothing. Dust-level impact, already documented.

Dropped

• The parameters.json schema note from the flow specialist. A schema-shaped launch.json now exists in the tree and the template is documented as a template, so there is nothing to fix.
• All static-analysis lines. The reentrancy and locked-ether leads are covered by the reentrancy guard, the payer reset and the absence of any receive function, and msg.value is either fully settled or the whole swap reverts.

Coverage

All five listed entry points are answered. Approve, swap and the unlock callback hold. Transfer and transferFrom carry finding 1. Four extra rows cover the constructor and supply, the launch flows, economics consistency and the website pool key.

The finding is disputed and launch.json stays as it is.

What I checked. The job's economics object, printed in this assignment, sets the opening cap to 1 ETH and must be copied verbatim. I parsed launch.json and compared its economics field to that object. They are identical. Recomputing the cap from the manifest's provenance sqrtPriceX96 also gives 1 ETH, so the manifest is internally consistent. The token constructor takes factory, PoolManager and launch number, and SwarmSwap takes the token, matching the manifest's constructor arguments.

Why no change. Raising initialMarketCapWei to 10 ETH would make the manifest a non-verbatim copy, which admission refuses. The README, deployment parameters and website carry the 10 ETH figure, but those files are outside the one path this task may write, and the deployer reads the price only from launch.json. The manifest notes already record that the economics object governs over the brief's prose.

Verification. The build succeeds and all 35 tests pass. The answer to the reviewer is written to .imd-responses.json with verdict "disputed" and the comparison described above.

The revision is complete. forge build succeeds and forge test passes with 78 tests across 9 suites, up from 63.

What this round addressed. No findings file existed and none were listed, but the implementation was revised after my first-round tests were written. That revision raised the distributor-lookup gas budget from 30k to 100k and made the swap adapter expect callers to pass the platform's pool initialization guard as the hook address. Neither change was pinned by a test, so I added two files and left all previously accepted work untouched.

• test/SwarmSwap.hooked.t.sol launches the pool under a hook mined for the BEFORE_INITIALIZE flag, as the platform guard will be. It proves the guard refuses a stranger's initialization, the adapter reads and trades the guarded pool exactly with no burn on settlement, fuzzed round trips never create ETH, a hookless key resolves to a different pool that a stranger can open at an absurd price, a swap against that pool keeps the caller's ETH, and neither contract accepts plain ETH.
• test/Swarm.lookupBudget.t.sol uses its own factory whose lookup costs a chosen amount of gas. It pins both sides of the 100k budget: lookups up to 95k exempt claims, lookups from 105k fall back to the documented 1% charge without reverting. A fuzz over claim gas limits shows a tight-gas claim either reverts whole or arrives whole, never taxed.

No defects reported. The two behaviours that look like weaknesses, the silent fallback for an over-budget registry and the burn bypass through the PoolManager ledger, are both documented in the README and SECURITY.md, accepted by the requester's brief, and already pinned by tests. Nothing surfaced with a concrete failing input, so I did not write .imd-findings.json.

Two harness mistakes came up while writing the hooked tests and were fixed before anything was asserted: passing a view call as an argument consumed the prank and expected revert. Both new files are formatted and sit untracked in the working tree, ready for the network's commit step.

The review is complete. The findings file is written and the tree is otherwise untouched (git status is clean apart from the gitignored output file, and the scratch directory was removed).

Outcome: four of the five earlier findings are settled. One low finding remains, re-anchored to the files the manifest task could not write.

Settled as fixed

• Distributor lookup budget. The token now forwards 100,000 gas to the registry lookup. I re-ran my heavy-registry reproduction (41,621 gas per lookup) and the full swarm claim arrives whole with nothing burned. The new budget test file also shows a claim submitted with scarce gas reverts whole rather than being taxed.
• Hookless pool key on the website. The config now ships the hook as null, validation treats null as launch-pending and rejects the zero address, and the 8 Node tests cover each case. A new test file exercises the router under a guard-hooked key.

Settled as accepted limitation

• Burn bypass through the PoolManager. The code is deliberately unchanged, which is the option (a) I offered. The specialist proof still fails by design. The limit is now stated on the website, in the README, SECURITY.md, the manifest notes and the contract comment, and pinned by a test against the real PoolManager.

Dropped

• Floor rounding of the 1%. The author's reasoning holds: rounding up would under-deliver the promised 99% instead, and the impact is dust either way.

Still open, low: the opening market cap. I accept the author's answer that launch.json copies the job's economics object verbatim, and its initial price recomputes to a 1 ETH cap. But the website footnote, the README and deployment/parameters.json still say 10 ETH, so buyers are shown an opening valuation ten times what the pool will open at. Fixing it needs a task that can write those files, or the requester confirming which number they meant.

Coverage: all five entry points traced and marked holds. The full Foundry suite passes 78 tests. The protected harness could not run locally because it needs platform contracts not in this tree.