The SBEE launch token is delivered, verified and committed on main.

What was built

• src/SBEEToken.sol is a fixed-supply OpenZeppelin ERC-20 named Swarm Bee, symbol SBEE, 18 decimals. The constructor mints the whole supply of 1e27 units once to the deployer and nothing can mint afterwards.
• The buy tax lives in one _update override. When the sender is the Uniswap v4 PoolManager, 2% goes to the fixed creator wallet and the recipient gets 98%. Transfers to the PoolManager, factory flows, distributor claims and wallet-to-wallet transfers move whole.
• There is no owner, no setter, no pause, no blacklist, no burnFrom, no proxy, no delegatecall and no selfdestruct. The PoolManager, tax wallet, tax rate and the informational pool fee of 12500 are compile-time constants.
• foundry.toml pins solc 0.8.26, evm_version cancun, optimizer on and bytecode_hash none. Dependencies are committed as ordinary files under lib/ with no submodules: forge-std 1.16.2 and the five OpenZeppelin 5.7.0 files the ERC-20 needs.
• launch.json carries exactly the keys and values from the brief, including the given initialPrice, economics block and an empty constructorArgs list.
• README.md documents parameters, transfer rules, the factory's responsibilities, and the assumption that only transfers sent by the PoolManager count as buys.

Verification

The smoke tests cover supply and metadata, zero balances at the swarm and tax wallet after minting, the taxed buy path through both transfer and transferFrom, untaxed seed and sell paths, untaxed wallet transfers, three revert cases, a probe that common admin selectors all revert, and a bytecode scan for forbidden opcodes.

I also ran a throwaway end-to-end check outside the repository against the real v4-core PoolManager built in place at its Robinhood Chain address, mirroring the protected harness. The single-sided seed arrived untaxed, a buy paid exactly 2% of the gross to the tax wallet, and the trader could sell the full bought amount back. That scratch project was not committed.

Left for the next agent

The fuzz and invariant suite is intentionally absent per the brief. One deliberate design choice worth noting for review: a transfer from the PoolManager directly to the tax wallet is delivered whole rather than taxed against itself.

Done. The suite is committed, forge build and forge test both pass offline, and nothing outside test/ was touched.

What was delivered (all under test/, committed as plain files, no submodules):

• test/SBEEToken.fuzz.t.sol adds 21 property and failure-path tests. It fuzzes the 2% split for any gross amount, the 50 wei rounding boundary, event ordering, allowance spent for the gross, per-buy rounding never over-taxing, exemptions for pay-outs to the tax wallet and PoolManager self-transfers, and exactness of sells and plain transfers for arbitrary parties. Failure paths include a buy that reverts atomically when the gross exceeds the pool's balance but the net would not, a net-only allowance, zero-address receivers, and a fuzzed sweep asserting every unknown selector is rejected from the deployer, the PoolManager and a stranger with state unchanged.
• test/SBEEToken.invariant.t.sol runs a handler over seven actors including the PoolManager and the tax wallet, with a ghost ledger that encodes the brief's transfer rules. Invariants check that every balance matches the ledger, balances sum to the fixed supply, net plus tax equals gross, and admin attempts never succeed. It runs with fail-on-revert enabled and 128 runs by 64 depth, set inline so foundry.toml stays untouched.
• test/SBEEToken.swap.t.sol builds a real Uniswap v4 PoolManager in place at the hard-coded address, puts a pair-token stand-in at the IMD address, and runs the factory's launch flow: 10% to the distributor, single-sided seed of 90% at the manifest price with the 1.25% fee, remainder to 0xdead. Each scenario runs with SBEE as currency0 and as currency1. It verifies the pool fee is exactly 1.25% of the input via SwapMath, that the buyer receives gross minus 2% and the tax wallet 2%, that sells settle whole, that unpaid buys revert with no tax kept, that ERC-6909 claims cannot bypass the tax, and a fuzzed random buy/sell sequence after which the LP withdraws fully and the PoolManager holds only rounding dust.
• test/vendor/ holds Uniswap v4-core source and solmate's Owned mixin with one relative-import patch, documented in VENDOR.md.

Verification. 58 tests pass. I also ran the invariant and swap suites against two scratch mutants, one taxing sells and one at 3%, and both were caught broadly, so the suite is not vacuous.

No defects found, so no .imd-findings.json was written. Two behaviours worth knowing that follow from the spec rather than contradict it: a liquidity withdrawal paid out in SBEE by the PoolManager is taxed 2% like any other pay-out, and a pay-out addressed directly to the tax wallet is exempt, as the README documents. Fork runs against live Robinhood Chain state remain owed since no network is available to the verifier.

The findings file is in place and valid, excluded from git by the harness's own exclude rule as expected. The working tree is otherwise untouched (scratch test removed). The review is complete.

Result: no critical, high or medium defects in the math. The findings file holds two substantiated items and a coverage row for every entry point.

What I checked (Math Precision, Boundary, Numerical Gap guides):

• The only arithmetic in the contract is the buy-tax line in _update. For any value up to the 1e27 supply the multiply cannot overflow, the subtraction cannot underflow, and tax plus net equals the gross exactly, so the supply-conservation invariant holds and the PoolManager is debited the full amount it accounts for.
• Both sentinel branches (recipient is the PoolManager, recipient is the tax wallet) deliver whole. Zero-address recipient and insufficient PoolManager balance revert atomically, so no tax is kept from a failed buy.
• Sells, the seed, factory and distributor flows fall through untouched, so Uniswap v4 sync/settle sees exact amounts. ERC-6909 claims are taxed on redemption and cannot bypass the tax.
• The allowance is spent on the gross value, so there is no gross/net mismatch in transferFrom.
• launch.json numbers are consistent: totalSupply matches the mint, and the provenance sqrtPriceX96 matches 2500 IMD over 1e27 units.

Findings written:

1. Low. The tax uses floor division. A 49-wei buy pays zero tax and a 149-wei buy pays 1.34% rather than 2%. Splitting a take into sub-50-wei pieces avoids tax entirely, but at launch price that is worth about 1e-22 IMD per take and costs far more in gas, so it is dust and not farmable. The README documents it. A one-line ceiling division is the fix if fee-favouring rounding is wanted.
2. Info. The multiply runs before the balance check, so a buy above roughly 5.79e74 wei reverts with an arithmetic panic instead of the ERC-20 insufficient-balance error. Both paths revert with no state change, so no harm.

Coverage: approve holds; transfer and transferFrom are marked finding pointing at item 1, since both share the same tax arithmetic. Seven additional rows record the invariants and boundaries I traced. Nothing in the assigned area was left unreached.

Review complete. The findings file is at the repository root with two entries and eleven coverage rows, and no tracked file was changed.

Outcome for the assigned area. The permission model holds. SBEEToken has no owner, role, initializer, setter, pause, blacklist, burnFrom, proxy, delegatecall or selfdestruct. The only state-changing entry points are the three OpenZeppelin ERC-20 writers, and the vendored ERC20 body matches upstream v5.7.0 apart from import ordering. The tax branch in _update conserves supply on both sides, reverts atomically when the gross exceeds the PoolManager's balance, and consumes the gross allowance on a pull. The manifest keys, constructor arguments, supply and economics match the brief. The existing 58 tests pass.

Findings written to .imd-findings.json:

1. Low, with a failing scratch test. The creator tax is defined at the ERC-20 transfer level, so a swapper who receives SBEE as ERC-6909 claims inside the PoolManager and later sells by burning those claims completes a full buy-then-sell round trip with zero tax. The test under test/scratch/ reproduces it: a 100e18 pair-currency buy owes roughly 748,230 SBEE in tax under the brief's "2% of every buy", and the tax wallet receives nothing. Mechanics spec M1 is literally satisfied, so this is a gap between intent and what a token can enforce. Closing it needs a swap hook outside the token, or the limitation documented as a trust assumption.

2. Info. Seed in and liquidity out are asymmetric by spec: any SBEE the PoolManager pays to the launch LP, the protocol-fee collector or an overpaying seller is taxed 2%. Recorded as a trust assumption for the launch operator, already exercised by the existing swap suite.

Coverage. All three listed entry points are marked holds, plus rows for the constructor, the tax branch, the access-control surface, the inherited ERC20, the claims round trip (finding 1), the seed/withdrawal asymmetry (finding 2), launch.json and the protected floor. Nothing in the area was left unreached.

The findings file is in place and excluded from git by the repository's own exclude rule. The scratch directory is removed and the tree is otherwise clean.

Outcome: the audit of the control-flow area (Execution Trace, Periphery, First Principles) found no critical, high or medium defect. The token's tax routing, Uniswap v4 settlement, launch flows, manifest and vendored dependencies all behave as the brief specifies. Three findings are recorded in .imd-findings.json, with coverage rows for all three ABI entry points plus five checked invariants.

Findings written:

• Low: tax-free round trip via ERC-6909 claims. A trader who settles a buy with PoolManager.mint instead of take, and later sells by burn, never triggers an ERC-20 transfer from the PoolManager. I reproduced this against the vendored v4 PoolManager at the hard-coded address with the launch pool seeded as the factory seeds it. A buy of about 390,172 SBEE was bought and sold back with the tax wallet receiving nothing, where the take path would have paid about 7,803 SBEE. The existing claims test only covers the redeem-by-take path. This follows from the specification's own definition of a buy, so the fix is a requester decision rather than a code change.
• Info: LP withdrawals and fee collection are taxed 2%. Any take from the PoolManager is taxed, including the factory's own seeded position. The existing swap test already asserts this as expected, so it is recorded as a design consequence to confirm.
• Info: README provenance. The vendored OpenZeppelin ERC20 matches the master branch, not the v5.7.0 tag the README names. Logic is identical to v5.7.0, so no behavioural impact.

What I verified and did not find defective: the two-leg _update is atomic on shortfall, transferFrom spends the gross allowance, mint bypasses the tax branch, transfers to the PoolManager arrive whole so settle balances, no gitlinks or submodules exist, the manifest has exactly the required keys with matching constructor args and supply, and the full existing suite of 58 tests passes. The Slither and Aderyn leads were style-only and not reported.

Not reached: no live-chain check of the PoolManager or pair-token addresses on Robinhood Chain, since no network fork is available to the verifier. Those remain owed as an operational check by the deployer.

The review is complete. The working tree holds only .imd-findings.json (git status is clean because the harness excludes that path), and the scratch test is removed.

Outcome: no critical, high or medium defects in SBEEToken. The token honours the authoritative mechanics exactly: only transfers sent by the PoolManager are split 2% to the fixed wallet and 98% to the recipient, the PoolManager is debited the gross amount so Uniswap v4 settlement balances, and seeds, sells, the swarm share, the remainder and wallet transfers move whole. Supply is fixed at 1e27 with no admin surface, and the full suite of 58 tests plus my checks pass offline against the vendored v4 PoolManager in both currency orders.

Findings reported (2):

• Low: the creator tax is avoidable through ERC-6909 claims. A swapper can settle a buy with PoolManager.mint instead of take, hold or transfer the claims, and sell by burning them. Real SBEE never leaves the PoolManager, so the from == POOL_MANAGER branch at src/SBEEToken.sol:47 never fires. Reproduced: a 10 IMD buy acquired about 3.89M SBEE untaxed, and the round trip netted the trader a profit while the tax wallet received nothing. The token meets the spec's literal definition of a buy, so the gap is between economic intent and the observable event. The fix is outside the token, either documenting the limitation or taxing in a v4 hook on the launch pool.
• Info: every PoolManager payout is taxed, including the LP's own liquidity withdrawal and fee collection. This is by spec and already asserted in the project's own tests, recorded so the launch policy knows the position holder forfeits 2% of the SBEE side on exit.

Coverage: all three entry points (approve, transfer, transferFrom) hold, plus eight invariant and manifest rows. launch.json has exactly the required keys, economics copied verbatim, lowercase addresses, 1,482-character notes, and an initialPrice that resolves to the 2,500 IMD opening cap. lib/ is committed as 40 plain files with no submodule.

Not reached: nothing within the assigned Economic Security, Invariant and Flow Gap guides was left unexamined. Fork runs against the live Robinhood Chain PoolManager and tax wallet remain owed to a networked verifier.

I've finished the review of SBEEToken and written the results to .imd-findings.json: three findings and five coverage rows. Nothing blocks the launch. No source files were changed, and the scratch test I used for reproduction has been deleted. The full suite (forge test) passes, 58 of 58.

Findings

1. Low: buys settled as Uniswap v4 claims pay no 2% tax (src/SBEEToken.sol:47). Three specialists reported this; I merged them into one finding. A trader can take a buy as claims held inside the PoolManager, then sell by burning the claims, so the token never moves and the tax never triggers. I reproduced it against the vendored v4 PoolManager. A buy of 100 pair tokens produced 37,411,547.83 SBEE as claims and was sold straight back. The tax wallet ended at 0 instead of 748,230.96 SBEE, the same figure the permissions specialist reported. The code does what the mechanics spec says: it taxes transfers from the PoolManager. But the brief's "2% of every buy" doesn't hold, and README.md:50 ("pool buys are always taxed") is wrong. I kept it at low: only the tax wallet loses, and the token alone can't close the gap. The options are to document the limit, or to tax in a swap hook on the pool, which is the requester's call.
2. Info: liquidity withdrawals and fee collections of SBEE are also taxed 2% (line 47). Three specialists reported this; I merged them into one finding. It follows the spec, and the project's own tests assert it. I recorded it as something to know about, not a defect.
3. Info: the tax rounds down (line 48). Payouts under 50 wei pay no tax. The amounts are dust and the README already says so. I folded the math specialist's separate overflow item into this note: an absurdly large amount reverts with a different error, but nothing moves either way.

Dropped: the claim that the README cites the wrong OpenZeppelin version. Checking it needs the upstream release, which I couldn't fetch offline, and it changes no behaviour.

Coverage:

• approve: holds. It is standard OpenZeppelin, not overridden.
• transfer: finding 1.
• transferFrom: holds. Its only taxed path needs an allowance from the PoolManager, which the PoolManager never grants.
• Two invariants: both hold. The supply is fixed at 1e27 minted to the deployer, and the contract has no owner, admin, delegatecall or selfdestruct.

launch.json matches the brief, and its opening price matches a 2,500 IMD market cap.

git status also lists files I didn't create, such as .bashrc, .gitmodules and .mcp.json. They're empty placeholders the sandbox puts in place, and I left them alone.