Implemented LaunchToken, CityRegistry, GrantExecutor, vendored dependencies, ABI exports, and deployment documentation.

Verified: forge build, 71 passing tests, forge fmt --check, and ABI consistency.

Unresolved conflict: protected checks require fee-free transfers, contradicting the workflow’s universal 4% tax. The token is fee-free; an optional taxed route is implemented. Details and deployment assumptions are in README.md.

Created launch.json with matching token metadata and constructor dependencies.

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

Notes preserve the unresolved transfer-tax conflict and required policy-owner authorization check.

The review is complete. .imd-findings.json holds two findings and 20 coverage rows, the scratch tests are removed, and no source file was touched.

Outcome for the assigned area (Math Precision, Boundary, Numerical Gap): the arithmetic holds. I traced every division and multiplication in CityRegistry and confirmed each empirically against the compiled code:

• City price is exact. The formula multiplies before dividing, and 1e22 carries enough factors of two that division by 65,536 never rounds. All 256 prices matched the spec formula, and the sold-out boundary reverts as documented.
• Reward accounting conserves exactly. Each distribution adds the truncated share to city credits and the modulus to the carried remainder, so credits plus remainder plus queue always equal the pool times 1e27. Claiming the entire supply at the maximum weight of 102,400 left zero unclaimable dust and no underflow of the pool.
• No overflow at extreme state. The accumulator stays below 1e54 and level squared is at most 400, far under uint256. Grant backing, fee arithmetic and level-up cost are bounded by supply.
• Weight bookkeeping is correct. Level-up settles before changing weight and adds 2L+1, matching the square difference. Heartbeat grants re-check the pot after each award.

Findings recorded:

1. Medium, outside my area: the approved universal 4% transfer tax is not implemented. Plain transfer moves the exact amount and funds neither pot. This is a requirement conflict with the protected floor test that forbids fee-on-transfer, and it needs a requester decision rather than a code fix. Reported because it removes the funding source all the reward math assumes.
2. Low: the opt-in tax route floors every bucket and hands all dust to treasury. At a fee of 9 wei the treasury share is 33% and nothing burns, and amounts under 25 wei pay no fee at all. Bounded to about 3 wei per call and documented, so dust-level. This also resolves the slither divide-before-multiply lead.

Static-analysis leads resolved: the aderyn reentrancy line points at the constructor's decimals call, not exploitable; buyCity's burn happens after all state writes under the guard.

Not reached: no third-party integration paths exist, so nothing in the assigned area was left unexamined. Neither finding carries a proof file since neither is high or critical.

Review complete. The findings file is written and the scratch tests are removed, so the tree holds only .imd-findings.json beyond the accepted work.

What I found in the economics area, checked against the Economic Security, Invariant and Flow Gap guides:

• Medium: the approved universal 4% transfer tax does not exist. LaunchToken is stock OpenZeppelin ERC20; a plain transfer of 1000 GRID delivers 1000 GRID, burns nothing and pays the treasury nothing. The only taxed path is the opt-in transferWithTax on the registry, which no DEX trade or wallet transfer uses. So the mandated loop where trading fills the pots never runs unless someone voluntarily funds them. The README discloses that this was chosen because the protected floor test forbids fee-on-transfer, so the two requirements conflict and the requester has to decide. A proof test is attached that fails on the current token.
• Low: buyCity has no max-price bound. A buyer quoted 10,000 GRID whose transaction lands after another purchase burns 10,078.28 GRID if they used the infinite allowance the ABI docs endorse. Nobody profits since the excess is burned, so impact is bounded.
• Info: operator and treasury both come from one constructor argument. The code correctly avoids hard-coding the wallet, so the manifest must encode the approved address literally or the policy owner must equal it. No launch.json exists yet.
• Info: GRID backing granted resources is locked forever, neither burned nor recoverable. Leveling one city to 20 strands 286,900 GRID. This is a documented design interpretation the requester should confirm.

What holds. Reward accounting conserves exactly across weight changes and claims, the view and write paths agree, the price and level-cost formulas match the workflow, heartbeat and grant paths are pot-bounded and atomic, and every custody-changing path preserves the registry balance invariant. The slither divide-before-multiply lead is a few wei of dust to treasury and the aderyn reentrancy lead is constructor-only, so neither is reported. All 17 entry points have coverage rows, plus four invariant and static-analysis rows. The existing suite passes (71 tests) and the ABI check is clean.

The review is complete. The findings file is valid JSON, every cited snippet matches the tree, the scratch tests are removed, and no repository file was changed.

Outcome: no critical or high defects. The Solidity is sound in my area: every entry point traced clean, and the reward accounting held under an invariant run of 128 runs by 256 depth with fail-on-revert. The three reported findings are all requirement or design conflicts rather than exploitable bugs.

Findings written to .imd-findings.json:

• Medium: the approved universal 4% transfer tax is not implemented. Plain transfer and transferFrom move the exact amount and fund nothing. The author documents this as a conflict with the protected floor test, which requires exact-value transfers. It needs a requester decision, since both requirements cannot hold at once.
• Low: GRID backing granted resources is locked forever. The registry accumulates it and nothing ever burns, recycles or withdraws it, even after leveling consumes the resources. A full game strands roughly 7% of supply as dead custody. This is a documented design choice, flagged as an unrequested value sink.
• Info: treasury and grant authority share one constructor argument. The manifest must resolve it to the approved wallet. No launch.json exists yet, so this is the concrete check for the manifest reviewer rather than a defect today.

Coverage: all 17 listed entry points have a row, plus rows for two invariants, the vendored libraries, the ABI exports, and the not-yet-existing manifest. I also verified the vendored OpenZeppelin v5.1.0 and forge-std v1.9.7 files against the pinned upstream archives: they are byte-identical apart from formatter line wrapping.

Rejected leads: the Slither divide-before-multiply line is bounded rounding dust that the author documents, and the Aderyn reentrancy line is two harmless view calls in the constructor.

The review is complete. The findings file is valid JSON, all three cited snippets match the tree line for line, the scratch tests are removed, and the working tree has no changes other than the findings file.

Outcome: The access-control surface of Swarm Cities is sound. Every state-changing entry point carries the guard the brief asks for, and I found no permission bypass, confused deputy, initialization gap, or asymmetric writer. The three items I reported are requirement and trust conflicts, not code bugs.

Findings written to .imd-findings.json:

• Medium: the approved universal 4% transfer tax is not implemented. The token is a plain fee-free ERC-20, and the taxed route in the registry is opt-in. A plain transfer of 1000 GRID delivers 1000 GRID and funds nothing. This is disclosed in the README as a conflict with the protected launch floor, which requires exact-value transfers. The requester has to amend the brief or accept donation-funded pots before admission.
• Low: treasury and grant authority both follow the executor's operator argument. The registry derives its treasury from the executor. If the manifest passes $owner and the policy owner differs from the approved wallet, fees and pause/grant control all move to that other address. No manifest exists in the tree yet, so this is a gate for the manifest reviewer, with the exact expected address recorded.
• Info: operator trust assumptions. The single immutable operator can steer resources to its own city and capture most future rewards, cannot be rotated, and its loss disables grants permanently. Confirmed by a scratch scenario where the operator's city took 80% of a distribution against a peer's 20%.

Coverage: all 17 listed entry points have rows. Fourteen hold, three point at finding 1 (the two token transfer functions and the taxed route). I added rows for the custody invariant, the no-privileged-withdrawal invariant, post-deployment role assignment, and one unreached row for the absent manifest.

What I checked and passed over: the static-analysis leads. The divide-before-multiply in the fee split is intentional and dust goes to treasury. The reentrancy warning on the constructor concerns immutable writes after view calls and is not exploitable. Existing tests, ABI export check, and formatting all pass.

Added failure-path fuzz tests and stateful invariants covering 32,768 randomized calls.

Offline forge build and forge test pass: 79 tests, zero failures.

Reported one high-severity defect with a verified failing proof in .imd-findings.json: ordinary transfers bypass the required 4% tax, which conflicts with the protected exact-transfer check.

The review is written to .imd-findings.json in the repository root: 5 merged findings and a coverage record answering all 17 entry points plus 3 invariants. No tracked file was changed; the scratch tests I used were deleted afterwards.

Findings kept

All 13 specialist reports were reproduced in a scratch Foundry run and merged by root cause into five.

#	Severity	Finding	Location	Merged from
1	medium	The approved universal 4% transfer tax is not implemented; transfer and transferFrom are fee-free	src/LaunchToken.sol:11	5 reports (one high, four medium)
2	low	buyCity has no maximum price, so an over-approved buyer burns more than quoted	src/CityRegistry.sol:121	1 report
3	low	transferWithTax rounding gives dust to treasury and charges nothing below 25 minor units	src/CityRegistry.sol:196	1 report plus the slither lead
4	low	GRID backing granted resources is locked in the registry forever	src/CityRegistry.sol:247	2 reports (low, info)
5	info	Operator, pauser and treasury all come from the single $owner argument	launch.json:12	3 reports (low, info, info)

Observed values behind each:

• Finding 1: a 1000e18 transfer delivered 1000e18 to the recipient, with both pots, the treasury and the supply change all at zero.
• Finding 2: quoted 10000e18, burned 10078.277587890625e18 after one intervening buy.
• Finding 3: amount 24 paid no fee; amount 225 split 4 / 2 / 0 / 3 (rewards / resources / burned / treasury); 1000e18 split exactly.
• Finding 4: after granting 400 resources and levelling up, resources were 0 but allocatedResourceBacking was still 400e18.
• Finding 5: with operator 0xdEaD, the treasury share went to 0xdEaD and the approved wallet could not pause.

Decisions a reviewer should know about

• Finding 1 is medium, not high. No holder loses funds; what is broken is an approved guarantee. The supplied launch floor test test_transferMovesExactlyWhatItWasAsked requires exact-value transfers, so the author cannot fix this alone — the requester has to reconcile the workflow with the floor.
• I did not attach the two specialist proofs to finding 1. I ran both and both fail for the stated reason (1000000000000000000000 != 960000000000000000000). But each asserts that a transfer from the deployer delivers 96%, the direct opposite of the floor test, so holding the author to them would make the token unadmittable.
• Finding 5 is an evidence gap, not a defect. The manifest uses $owner as the launch rules require. I could not see the launch policy, so I could not verify that it resolves to 0x5b95A971B4583A5f011E9DA082acdD679b870D06; admission needs that shown.
• One specialist report was dropped as a finding. The operator trust assumptions (single immutable key, can favour its own city, loss disables grants) match what the brief asks for; they are recorded inside finding 5 instead.

My own pass

I found no additional defect beyond the specialists' reports. Two behaviours I reproduced are documented in the README and I left them as coverage notes:

• Rewards funded before any city exists go wholly to the first buyer (10000e18 queued, first city claimed all of it).
• recordHeartbeat reverts CityNotOwned until three cities are owned.

The aderyn reentrancy lead at line 88 is the constructor reading decimals() and operator() before assigning immutables, and is not exploitable.

Other checks run

• The project's own suite passes: 79 tests, 0 failed.
• docs/abi/*.json are identical to the compiler output for all three contracts.
• The three runtimes contain no DELEGATECALL, CALLCODE or SELFDESTRUCT and are 1884, 1272 and 6151 bytes.
• launch.json was read against the schema by hand: field set, contract order, references and notes length (1313 characters) are fine.

Not done

• The protected floor tests were not run with their IMD_* environment; I re

Recorded all four decisions in .imd-responses.json.

Fixed fee rounding and consumed-resource backing. Added exact-allowance purchase guidance and regression tests.

Universal tax remains disputed: it contradicts the protected fee-free transfer requirement and requires a release decision.

Validation passed: forge build, all 81 tests, formatting, and ABI checks.

Left launch.json unchanged. Recorded the reproduced advisory in .imd-responses.json, disputing only that it requires a manifest change. Admission still needs evidence that $owner resolves to the approved wallet.

Schema and ABI checks passed. forge build succeeded; forge test: 83 passed, 0 failed.

Updated the invariant model to account for resource backing burned on level-up. Added regression coverage for exhausted grants and level-20 consumption.

forge build and forge test pass: 90 tests, including 36,864 randomized handler calls.

Reported the unresolved universal 4% transfer-tax defect in .imd-findings.json, with reproduced failing proofs for both transfer paths.

The review is complete and .imd-findings.json is written. No source, test or manifest files were changed, and my scratch tests are deleted.

Settlement of the five earlier findings

• Universal 4% tax (medium), still open. LaunchToken is unchanged and the reproduction still holds: a 1000 GRID transfer delivers the full amount, funds no pot, burns nothing and pays treasury nothing. The author's dispute is correct on fixability. I ran the supplied token floor test against the compiled creation code and its exact-transfer assertion passes, so implementing the tax would fail admission. This stays a requester decision: amend the workflow and site tagline to the opt-in route, or obtain a floor ruling. No author edit is requested.
• buyCity over-approval (low), settled. The contract is unchanged as agreed. README and docs/ABI.md now require an exact allowance and the infinite-allowance guidance is gone. Dropped.
• transferWithTax rounding (low), fixed. Fee is now the ceiling of amount divided by 25 and dust goes to rewards. Reproduced 24 → fee 1, 225 → 7/2/0/0, 625 → 14/7/2/2, 1000 GRID → 20/12/4/4, plus a 256-run conservation fuzz. Dropped.
• Stranded resource backing (low), fixed. levelUp now decrements the backing and burns it. Reproduced level 2 with backing zero and supply down 400 GRID, and level 20 burning all 286,900 GRID. Dropped.
• Policy owner evidence (info), kept as advisory. Manifest and ABIs are correct and the exported ABIs match the build byte for byte. The pinned policy row is still not in the tree, so the resolved GrantExecutor argument remains the evidence admission needs.

Fresh pass. The full suite passes with 90 tests and both invariant suites green. The aderyn reentrancy lead is the constructor and was dropped. I found nothing new in the revised levelUp and transferWithTax lines.

Coverage. All 17 entry points are answered: two rows point to the tax finding, the rest hold, with extra rows recording the three settlements and the checked custody invariant.

Recorded the reproduced finding as disputed in .imd-responses.json: universal taxation contradicts the mandatory exact-transfer check. Contracts remain unchanged; the conflict requires a requester decision before release.

Validation passed: forge build, all 81 project tests, six protected token tests, formatting, and ABI checks.

Reproduced the advisory and recorded the response in .imd-responses.json. No manifest revision is warranted; launch.json remains unchanged and validates. Admission still needs evidence that $owner resolves to the approved wallet.

forge build succeeded. All 83 tests passed.

The findings file is excluded from git by design in this workspace (.git/info/exclude), so the worker reads it from disk rather than from a commit. Everything is in place.

Outcome. The full suite passes offline with the new file included: 98 tests across 10 suites, 0 failures, including the two existing invariant campaigns (64×64 and 256×128 random sequences). The new test file is forge fmt clean.

What I added in test/FullGridLimits.t.sol (eight tests):

• Maximum state. All 256 plots sold and every city driven to level 20, weight 102,400. The grid then rejects every quote, purchase and upgrade for all 256 ids. One wei of funding rounds to zero for everyone with no remainder. Funding exactly the weight in wei pays each city exactly 400 wei. Funding the entire remaining supply splits equally within one wei per city, every owner claims it in full, and at most 256 wei stays as fractions.
• Grants at level 20 are accepted through both grant paths, keep their backing in custody, burn nothing and cannot be consumed, matching what the README documents.
• Self-transfer and treasury-recipient paths on the explicit levy route: a self-transfer still loses the full fee, and the treasury as recipient gets net plus its own share only.
• Pause is executor-wide. One pause blocks grants and heartbeats on two registries while buys and claims stay live on both.
• Forwarding to a non-registry contract reverts and leaves the executor and registry state untouched.
• Two fuzz properties. Coordinate round-trip plus the grid walk to the next id, and equal shares for equal levels at every level 1 to 20 and funding size, with the claim paying its quote.

I also updated test/CONTRIBUTOR_TESTS.md to describe the new file.

Reported, not tested around. I refiled .imd-findings.json with one high finding: the launch token levies nothing on plain transfers, so the workflow's universal 4% tax with burn and treasury share is unmet. The proof test in the file fails on the current code with recipient balance 1000e18 instead of 960e18, for both transfer and transferFrom. The finding notes the known conflict with the protected floor's exact-transfer check, which is a decision for the requester or manifest reviewer, not something tests can resolve.

No source defects beyond that were found. Two failures during development were my own harness mistakes, fixed before the final run.