Delivered five 1024×1024 logo options and the selected wallet logo, reviewed at 32 px.

Built-in image generation produced six drafts; five were kept. One was rejected for transparency and rough edges. Prompts recorded here.

Implemented RAIToken, launch.json, and the Foundry project. forge build, all 20 tests, and artwork checks pass. No live-chain fork was run.

The existing RAIToken and launch.json matched the brief. Preserved them, added two focused smoke tests, and expanded deployment documentation.

Checks passed: forge build, forge test (22 tests), forge fmt --check, and exact manifest validation. Protected configuration and dependencies remain unchanged.

Pool integration checks remain for the verifier; no live-chain tests ran.

Committed as 5c76b0f; only test/ changed.

Added PoolManager swaps with fees, failure-path coverage, and randomized balance/allowance invariants. Dependencies are vendored for offline execution.

forge build and forge test pass: 43 tests, including 6,144 invariant actions. Offline checks also pass. Live-chain validation remains unrun.

The review is complete. The findings file is written and validated, and the working tree is unchanged apart from that file.

Outcome: no defects in the assigned area. The token at src/RAIToken.sol has no owner, roles, initializers, fallback, proxy, delegatecall or selfdestruct. Its three entry points all route through one private transfer function whose only branch is the source-based buy tax. I traced every path from the Access Control, Trust Gap and Asymmetry guides and each holds.

What I checked

• Access control: only approve, transfer, transferFrom exist. Each can spend only the caller's own balance or allowance. The PoolManager never approves, so a stranger can pull at most zero value from it, which is standard ERC-20.
• Asymmetry: buy taxed, sell untaxed, by design. Balances always sum to the fixed supply on every branch, including self-transfers, transfers to the tax wallet, zero amounts and the manager self-transfer exemption. Transfer events match the balance changes.
• Trust gap: the only beneficiary is a constant wallet with no setter, so no setter race or retroactive sweep exists. I tried the v4 flash-accounting tricks against the vendored PoolManager built at the constant address: a take to the manager itself between sync and settle reverts with CurrencyNotSettled, and a taxed outflow can never be settled for less than gross.
• Manifest: launch.json keys, name length, empty constructor args, supply, lowercase addresses and the provenance price all match the order and the code.

Reported, both at info level since they follow the authoritative mechanics line M1 and the project README documents them:

1. Any PoolManager outflow pays the 3%, including the factory's RAI fee collection, liquidity withdrawal and claim redemption. The narrative text says "buys", so the author should confirm this is intended.
2. The tax truncates to zero below 34 minor units. Splitting takes into dust avoids it, but each avoided unit is worth about 1e-9 wei at launch, so it is not a feasible bypass.

Coverage rows are recorded for all three ABI entry points plus the constructor, the admin-surface invariant, the v4 settlement invariant, the tax invariant and the manifest. The existing 43-test suite passes. Live Robinhood Chain fork runs remain owed to the deployer, as the test README already states.

The review is complete and the findings file is written and validated.

Result: no defects in the math. The token's only arithmetic is the 3% basis-point division on PoolManager outflows, and it holds under every check in the Math Precision, Boundary and Numerical Gap guides:

• Overflow is impossible. The balance check on line 61 runs before the multiplication, so the operand is bounded by the fixed 1e27 supply and the intermediate peaks at 3e29.
• Conservation is exact on every path. The debit is the gross amount and the credits are tax plus gross minus tax, including the PoolManager self-transfer and the PoolManager-to-creator overlap cases.
• Uniswap v4 settlement balances. Transfers into the PoolManager are untaxed, so sync and settle see the full input. Take moves exactly the gross amount out, so no currency debt arises. The vendored v4-core suite, two invariant campaigns, and all 43 existing tests pass.
• The manifest's initialPrice equals the exact sqrtPriceX96 derivation to the last digit.

Two informational notes are recorded in .imd-findings.json, each reproduced in a scratch test:

1. The tax rounds down and is zero for outflows of 1 to 33 minor units. The maximum leak per transfer is about 3e-26 ETH at the opening cap, so it is dust and not farmable. The manifest notes already document the round-down.
2. The tax fires only on a real ERC-20 transfer out of the PoolManager. A trader who settles a buy as an ERC-6909 claim and later burns it to sell pays the 1.25% LP fee but never the 3% creator tax. This matches the authoritative definition of a buy in mechanics M1, so it is a design property rather than a defect.

Coverage answers all three entry points as holding, plus three invariant rows. Nothing in my area was left unreached. Fork checks against the live Robinhood Chain PoolManager remain owed, as the test README states.

The review is complete and .imd-findings.json holds the result.

Outcome: one low-severity economic finding, no critical or high defects. The token's accounting is sound against the Economic Security, Invariant and Flow Gap checklists. Every transfer path conserves the 1e27 supply, transfers to the PoolManager arrive whole so Uniswap v4 settlement never leaves debt, buys debit the PoolManager gross so the pool never falls into deficit, the multiplication cannot overflow, and there is no admin surface. The manifest validates: exact key set, supply matches the mint, empty constructor arguments match the zero-argument constructor, and the provenance price equals sqrt(1e-9) times 2^96.

Finding 1 (low), src/RAIToken.sol:67. The creator tax fires only on an ERC-20 transfer whose sender is the PoolManager. A v4 trader can avoid that transfer entirely:

• settle the RAI they bought as ERC-6909 claim tokens with mint, later sell with burn, or
• buy and sell inside one unlock so the RAI delta nets to zero.

In both cases real swaps happen and LP fees are paid, but the creator wallet receives nothing. Expected tax on a 0.01 ETH buy was about 2.95e23 units; actual was 0. The scratch test at test/scratch/ClaimBypass.t.sol reproduces both paths against the vendored PoolManager and fails on the "3% of every buy" assertion. I rated it low because it conforms to the authoritative M1 definition of a buy, an ERC-20 cannot observe claim mints, and closing it would need a pool hook, which is a spec decision for the requester.

Coverage. All three entry points have rows: approve holds, transfer and transferFrom carry the finding. Seven invariant and economics rows also hold, including tax rounding on dust buys and the documented 3% on LP fee collection and liquidity withdrawals. One lead is recorded there rather than as a finding: if the launch factory forwards the gross fee amount it took, that forward would revert since only 97% arrives, but the factory code is not in the tree so it cannot be reproduced here.

The existing suite still passes (43 tests). The scratch directory is gitignored and nothing outside it or the findings file was changed.

Review complete. The findings file is in place and no tracked file was changed.

Outcome: RAIToken's control flow holds. I found no defect of low severity or above in the token, and recorded one info-level limitation for the author to document.

What I checked, in my area

• Execution Trace: every path through transfer, transferFrom and approve. Balance is checked before the debit, the tax leg plus the net leg always equal the gross amount, self-transfers and PoolManager self-transfers leave balances unchanged, and a revert inside the transfer rolls back the allowance decrement. There are no external calls, so no reentrancy or partial-state window exists.
• Periphery: I diffed every vendored v4-core and solmate file against the pinned upstream commits in a temp directory. They are verbatim apart from the documented import path and whitespace in a license file, so the integration tests run real v4.0.0 PoolManager logic. The test harnesses mirror v4's sync, transfer, settle and take sequence faithfully.
• First Principles: the implicit assumption that "every buy ends in a transfer from the PoolManager" is the one that breaks, which is the finding below. The manifest, constructor, supply invariant, and forbidden-opcode scan all hold.

The one finding (info): a trader can buy RAI into ERC-6909 claim tokens with PoolManager.mint and sell them back with PoolManager.burn. Neither call touches the token, so that round trip pays only the LP fee and never the 3% creator tax. I reproduced it against the vendored PoolManager, with exact figures in the report. Taking claims out as real tokens is still taxed, so no pool funds leak. This matches the authoritative M1 definition and cannot be fixed inside the token, so it is reported for documentation and as an untested edge in the suite.

Coverage record: all three listed entry points marked holds, plus rows for the constructor, supply conservation, launch flows, the vendored dependencies, the harnesses and the manifest. One row is unreached: whether the hard-coded PoolManager address is the live one on Robinhood Chain, which needs a fork or network access.

Verification: the full suite passes, 45 tests including my two scratch tests, which live in the gitignored test/scratch/ directory. The temporary upstream clones outside the repository were removed.

Review complete. The findings file is written and the working tree is otherwise untouched.

Outcome: no defects in RAIToken. The code implements the authoritative mechanics M1 exactly, and the project's own 43 tests pass against the vendored Uniswap v4 PoolManager. All six specialist findings reproduced, but every one describes a design consequence of the specified source-based tax rather than a bug, so I merged them into three info-level entries.

What I reproduced and kept

• ERC-6909 claim and single-unlock bypass (merged from math, economics and flow). A buyer who settles with mint or nets a buy against a sell in one unlock never triggers an ERC-20 transfer from the PoolManager, so the creator receives nothing. The economics specialist's proof fails on this code at its final "3% of every buy" assertion only. Both M1 and the narrative define a buy as a transfer FROM the PoolManager, so I lowered it from low to info. It cannot be fixed inside an ERC-20.
• Every PoolManager outflow is taxed (from permissions). RAI LP fee collection and liquidity withdrawal pay 3% to the creator. Verified with a scratch probe and the committed withdrawal test. Matches M1 and is already stated in the README.
• Rounding down (merged from math and permissions). Outflows below 34 minor units pay zero tax. Verified with a scratch probe. The chunked-take bypass costs far more gas than it saves.

My own pass found nothing further. Allowance handling, zero-address checks, conservation, the untaxed seed and sell paths, the absence of admin or mint selectors, and the CREATE2 deployability of a no-argument constructor all hold. The manifest matches the schema and the constructor. The static-analysis line about large numeric literals is style only.

Coverage: all three entry points answered as holds, plus three invariant rows. The findings file carries all of this, and the scratch tests were removed.