Implemented the immutable token, 2% IMD rewards hook, and permissionless distributor.

• forge build, forge test, and formatting checks pass.
• 58 tests pass, plus two mainnet-fork tests.
• Three independent local review reports included.

Deployment parameters and limitations are in README.md. The mandatory 1.25% LP fee is additional.

Not deployed: IdentityMD’s swarm acceptance and launch stages must produce the addresses and transaction hashes.

Created launch.json, matching the contracts, constructor arguments, five hook permissions, and required pool values. Only this file changed.

Validation:

• forge build: exit 0.
• forge test with the supplied seed: exit 0; 58 passed.
• imd launch check .: exit 0.
• slither .: exit 255; 82 findings. The high-severity alert concerns intentional XOR in OpenZeppelin’s modular-inverse calculation. No arbitrary-send-erc20 finding. Existing warnings remain unchanged.

No deployment was performed; addresses and transaction hashes remain pending.

The review is complete and the findings file is written and validated. Nothing further is needed from tools.

Summary

I audited the permission model, trust gaps and asymmetries across ReferralHook, RewardDistributor and ReferralIMD, checked against the Pashov Access Control, Trust Gap and Asymmetry guides, and recorded the result in .imd-findings.json (2 findings, 13 coverage rows covering all 11 listed entry points plus two invariants). The project's own 58 tests pass on the current tree, and I removed my scratch test so no repository file is changed.

What holds. Every hook callback is gated to the PoolManager, the pool is bound to one immutable key, and initialization is restricted to the constructor-given factory. The fee mint and the returned hook delta always match, so the hook nets zero in every mode. recordFee is hook-only, unlockCallback is bound to an armed claim hash, and nobody else can burn or move the distributor's ERC-6909 claims. The claim cursor logic was traced across one-interval batches, same-block checkpoints and the finalized-block boundary without loss or double-pay. The exclusion set used for the denominator and for claim denial is symmetric.

Finding 1 (medium). Rewards for contract-held RIMD go to that contract with no recovery path. With the launch split, the swarm allocation contract holds about two thirds of eligible supply, so it receives about two thirds of every IMD distribution. If the factory's Merkle distributor cannot forward IMD, that IMD is permanently stranded, and anyone can force the payment via claimFor. Reproduced with the real PoolManager: a 300 IMD fee paid 200 IMD into a function-less contract. This is documented by the author as a limitation, but it undermines the brief's intent, and the exclusion list cannot be changed after deployment. The fix is a launch decision, not just code.

Finding 2 (info). beforeInitialize only accepts fee 12500 and tick spacing 60, so the manifest must match those exact values or the launch reverts.

Dropped lead. Dust-transfer griefing of a holder's checkpoint history: measured, the griefer paid about 3.6 times the victim's claim gas, and no entitlement is lost.

The review is complete and the findings file is in place. Git status shows no tracked-file changes, as required for a review task.

Outcome. No critical or high defect was found in the control flow of the hook, token or distributor. The findings file holds one medium, two low and one informational finding, each with a concrete reproduction I executed on this tree, plus a coverage row for all 11 listed entry points and three invariants.

What I traced and confirmed holds

• Hook delta flow against v4-core: the ERC-6909 mint in the callback (hook delta -fee) is offset by the +fee the manager credits after afterSwap, so the hook ends every swap at zero. Fee math is 2% of gross IMD in all four swap modes, and the specified-side partial-fill guard reverts atomically rather than over-charging.
• Distributor accounting: fees at block B use balances at the end of B-1, and the per-holder interval walk uses the same boundary, so numerator and denominator agree. Only immutable checkpoints (key below block-1) are ever read for payout. Claim progress, fraction carry and the authenticated unlock callback are atomic with the IMD transfer.
• The protected floor checks (manager-only callbacks, runtime opcode scan, whole supply to deployer, factory fee collect with no liquidity hooks) are all satisfied by the code as built.

Findings written

1. Medium. The exclusion set is fixed, so the swarm's launch MerkleDistributor (100M of the 150M eligible supply at launch) earns 2/3 of all early fees. It cannot claim or sweep IMD, so that share is stranded in either contract, and because it stays in the denominator no real wallet receives it. Reproduced: a 20 IMD fee paid 13.33 IMD into an empty contract.
2. Low. A hookless RIMD/IMD pool on the same manager trades with zero levy, so the 2%-on-every-trade requirement is not enforceable by the hook alone. Reproduced.
3. Low. One-wei transfers add a checkpoint per block to a victim's history; 200 dust blocks forced 4 claim calls. Gas-only impact, documented in the README.
4. Info. The hook hardcodes fee 12500 and tick spacing 60; a manifest that writes any other tick spacing would make the factory's initialize revert.

Not covered. I did not run the mainnet fork rehearsal or the network-dependent IMD bytecode check, and I did not re-audit the vendored library trees beyond the Checkpoints and ERC6909 paths the contracts use.

The review is complete. The findings file is written, both snippets verify against the tree, and no tracked file was changed.

Outcome: the fee, index and claim math is sound. I traced every swap mode, the one-block-lag index, the interval walk with fraction carry, conservation and solvency, and found no loss-of-funds or accounting defect. The full existing suite of 58 tests passes, and the verified IMD contract on mainnet is a plain LayerZero OFT with no pause, blocklist or transfer fee. Two economic edge cases survived verification, both substantiated with a passing scratch test under test/scratch/Economics.t.sol.

Findings written to .imd-findings.json:

• Medium: rewards to custodial contracts are stranded. Eligibility is literal custody, so the swarm's allocation contract (100M RIMD, two thirds of launch-time eligible supply), the factory and any V2/V3 pair earn pro rata, and permissionless claimFor sends IMD into them with no way out. Reproduced: 20 IMD of fees, 13.33 IMD delivered to a custodian contract that cannot move it. The README acknowledges this, but the brief directs that share to the swarm, so I reported it with three fix options for the launch.
• Low: deferred launch-block fees are re-weighted. With zero eligible supply at block D-1, block-D fees sit in pendingFees and are later assigned using end-of-block-D balances, so a launch-block buyer earns from its own block's fee. Not profitable as an attack, but it contradicts the documented one-block rule. Reproduced with a 100,000 IMD sniper buy earning 0.177 IMD back.

Coverage: all 11 verifier entry points have rows, plus seven invariant and economic rows (backing conservation, entitlement bound, wash-trade and sandwich economics, checkpoint-spam griefing, the IMD periphery, partial-fill fee behavior). The only thing not fully reached: I read the BridgedFP source's own body but not the full inherited OFT code, relying on the standard and the prior integration review for it.

Review complete. The findings file is written, valid JSON, and both snippets match the tree line for line. No tracked production file was changed; only the findings file and my scratch tests under test/scratch exist.

Outcome: no material math defect found. I traced all three assigned guides (Math Precision, Boundary, Numerical Gap) across the hook fee path and the reward index, and recorded two minor items.

What I verified in depth:

• Hook fee formulas against v4 semantics. All four swap modes charge 2% of the gross IMD side. The before-swap delta adjusts the core order by the fee so the trader's specified-side delta equals the request exactly. The after-swap partial-fill check compares the core delta to the request plus fee, which is exact on a full fill. The mint of ERC-6909 claims and the hook's returned delta net to zero every swap. Casts are bounded by the half-int128 guard.
• Reward index and claim intervals. A balance recorded at block t earns index growth from t through its next checkpoint, matching the one-block-lag denominator. The cursor only advances when an interval closes below the finalized block, so no interval is paid twice or skipped. Fraction carry yields the floor of cumulative entitlement, and the sum of payouts cannot exceed distributed fees. The eligible-supply subtraction cannot underflow.
• Edges probed with scratch tests. A 1-wei eligible supply with a 10^27 fee pays exactly, with no overflow. Dust-checkpoint griefing costs the attacker roughly 3.5 times what it costs the victim per interval.
• Dust only. Trades under 50 wei of IMD pay no fee, and exact-output gross-up rounds up to 1 wei more than exact-input for the same gross. Neither compounds, so neither is reported.

Findings recorded:

1. Low. Contract custodians earn rewards paid to their own address. At the launch split, the swarm allocation contract receives two thirds of every fee until members withdraw their RIMD. If that contract cannot move IMD, that share is stranded. The code follows the brief's eligibility wording and the README documents it, so this is flagged for the author and factory to confirm.
2. Info. The hook hardcodes the pool fee and tick spacing. The manifest must write fee 12500 and tick spacing 60 or initialization reverts.

Coverage has a row for all 11 entry points, all holds except beforeInitialize which points to the info item, plus three invariant rows.

Added failure-path, fuzz, and invariant tests under test/, covering initialization, swap settlement, reward accounting, and balance history.

Validation passed:

• forge build
• Seeded forge test: 95 passed, 0 failed
• New invariant campaign: 49,152 randomized calls, no unexpected reverts

No production defect was reproduced. Mainnet deployment and production factory allocations remain outside this offline test coverage.

The review is complete. .imd-findings.json is written and validated: all four snippets match their file and line, and the coverage record answers all 11 entry points plus three invariant rows.

Outcome

No critical or high defects. The code compiles, all 95 project tests pass, sizes are far under the deployment limits, and the manifest matches the constructor, permissions and the hook's hardcoded pool key. I kept four findings, each reproduced on this tree with a scratch Foundry test whose logged numbers match the specialists':

• Medium, merged from four specialists: rewards for RIMD held by custodial contracts are paid into those contracts with no recovery path. Under the brief's own split the swarm allocation contract is two thirds of launch-time eligible supply, so two thirds of early IMD fees go there. Whether that contract can forward IMD is outside this tree, so this is framed as a launch-level gap the author or factory must close.
• Low: fees from the launch block, when eligible supply is zero, are deferred and later weighted by a snapshot that includes launch-block buyers, contradicting the documented one-block-lag rule. Bounded and unprofitable.
• Low: one-wei transfers append recipient checkpoints, so a griefed holder needs extra bounded claim calls. Gas only, no lost entitlement.
• Low: a hookless pool of the same pair trades fee-free, so the hook alone cannot guarantee 2% on every trade. Inherent to the requested architecture and documented, reported for the requester to accept explicitly.

Dropped: the three info notes about the hardcoded fee and tick spacing, because launch.json already writes 12500 and 60. None of the static-analysis leads reproduced as a defect.

Own pass: I traced delta netting in all four swap modes against v4-core's hook library, callback authentication, claim accounting and cursor logic, constructor and factory deployment constraints, and the protected floor tests. Nothing beyond the specialists' findings surfaced. The scratch tests were removed after running so the tree is unchanged.

I partly fixed the main finding. IMD can no longer be pushed into a contract that can't move it, but contracts that hold rIMD still dilute what real wallets receive. The code can't fix that part without the swarm allocation contract's address, so the README now makes it a launch requirement. All 59 tests pass with the verifier's fuzz seed, and the build succeeds.

Main finding (medium): rewards stranded in custodial contracts. The report holds: a third party could call claimFor on a contract with no way to move IMD and lock the payout there.

• Change: claimFor in src/RewardDistributor.sol now reverts with ContractMustClaimItself when the target is a contract and isn't the caller. A contract's rewards stay inside the distributor until that contract calls claim itself. Wallets can still be claimed for by anyone.
• New test: test_contractHolderMustClaimItself covers both cases. A third-party claim for a dead-end contract reverts, and the same contract claiming for itself gets paid.
• What remains: contracts holding rIMD still count toward eligible supply. While the swarm's MerkleDistributor holds its 10%, that share of fees doesn't reach wallets. Excluding it would need its address, and the contracts are immutable and aren't given it.
• README: a new "Custodial holders" section says that before launch, everyone holding rIMD through a contract must either be able to call claim and forward IMD, or accept that its share stays unclaimed. It also asks that the swarm's 10% reach holders promptly.

The three advisory findings: no code change. I didn't re-run their tests; each matches the code as written and the report itself rates it low. I marked them "disputed" and listed them as known limitations in the README:

• Launch-block fees: fees from the launch block are weighted by a later snapshot that includes launch-block buyers. A buyer gets back at most its own share of those fees.
• Dust transfers: 1-wei transfers can make a holder need several bounded claim calls. Nothing is lost, and the attacker pays a transaction per block.
• Hookless pool: the 2% fee applies only to the launch pool, so anyone can open a fee-free rIMD/IMD pool. That follows from putting the fee in the hook, because the launch refuses a token with transfer fees.

My answers to all four findings are in .imd-responses.json.

Done. The only file changed is launch.json, and only its notes.

What I found. The existing manifest already matched the accepted tree: the hook contract name, four constructor arguments in declaration order (pool manager, launch token, the IMD pair address the brief gives, factory), the five permissions the hook's getHookPermissions returns, the token name ReferralIMD / RIMD at 18 decimals, and the launch pool values (IMD pair, fee 12500, tick spacing 60, the given initial price). No revision findings were listed in the brief.

What drifted. The last accepted code change to RewardDistributor made contract holders claim for themselves: claimFor from any other caller now reverts with ContractMustClaimItself. The notes still said anyone could call claimFor for any account, which no longer describes what was built.

What I changed. I rewrote that one sentence of the notes to state that claimFor works for wallets, that a contract account must call claim itself, that its entitlement stays in the distributor until it does, and that its RIMD still counts in the denominator. Notes are 2,586 characters, under the 4,000 cap. Nothing else in the manifest moved.

Verification.

• The manifest parses, starts with "kind": "univ4_hook", uses only schema keys, and has lowercase addresses with placeholders only where the brief requires them.
• A scratch test in test/scratch deploys the hook at a mined address, converts the manifest's permission names to flag bits, and asserts they equal the hook's implemented flags (0x20cc) and that the constructor arguments and pool fields are as written. It passes.
• forge build succeeds, and forge test with the verifier's fuzz seed passes all 59 project tests.

All 105 tests pass, including the new ones, using the verifier's fuzz seed (forge build is clean too). I didn't change any contract code.

What changed in the contracts: the only change since my last round is a new rule in src/RewardDistributor.sol. A contract holding rIMD now has to claim its own rewards. Nobody else can call claimFor on its behalf, and the call reverts with ContractMustClaimItself. All my earlier tests still passed against this, so the new tests focus on that rule.

test/ContractHolderClaims.t.sol (8 tests, one of them fuzzed 1,000 times):

• When someone else's claim for a contract is refused, nothing moves: the contract's claim progress, the IMD backing and the claimed totals are unchanged. The contract can still claim the full amount itself later.
• The refusal happens even when nothing is owed. If the batch size is invalid or the address is excluded, that error is raised first.
• A contract can still claim on behalf of ordinary wallets, for example a relayer paying the gas.
• For a contract address that hasn't been deployed yet, anyone can still push its rewards to it. Once it is deployed, they can't, and IMD sent before deployment is still spendable.
• An EIP-7702 wallet (an ordinary wallet that has delegated to contract code) can no longer be claimed for by others, but can still claim itself.
• A contract that never claims leaves its share locked in the distributor and keeps reducing what wallets receive. That stops from the block after it releases its rIMD.
• Fuzzed: a wallet and a contract split a fee. Each gets its exact share or 1 wei less, never more, and whoever pays the gas receives nothing.

test/ContractHolderInvariant.t.sol runs random sequences of transfers, fees and claims across two wallets and two contracts (256 runs × 96 calls). It checks the results against a separate per-holder ledger that doesn't use the distributor's own reward maths:

• Every claim made for a contract by someone else reverts with no side effects.
• Fees received always equal what has been paid out plus what the distributor still holds.
• At the end, the contracts claim everything they are owed, leaving nothing behind.

Reported in .imd-findings.json instead of being tested as correct:

• Low: a contract holding rIMD that cannot call claim locks its share of rewards permanently, and wallets get less while it holds rIMD. The swarm's 10% sitting in a distribution contract is the obvious case. The implementer's README already lists this as a launch requirement, but the contracts can't be changed afterwards. Before launch, someone needs to confirm that every contract holding rIMD can call claim(64).
• Info: the rule also catches EIP-7702 wallets, even though the code comment says anyone can pay claim gas for a wallet. Nothing is lost, because the wallet can still claim for itself.

Payouts are rounded down by up to 1 wei per holder, and that dust stays in the distributor. I've noted this in test/README.md but not reported it as a defect.

The new and updated files are uncommitted in the working tree: the two test files, test/README.md and .imd-findings.json.

I'm reporting no open findings this round. The medium is fixed, and the three lows reproduce as before but are now documented as accepted limitations, so none of them blocks the launch. .imd-findings.json holds {"findings":[]} and a coverage record that answers all 11 entry points.

Settling last round's findings

• [medium] Rewards stranded in contracts that hold RIMD: fixed. claimFor now reverts with ContractMustClaimItself when someone else targets an address that has code (src/RewardDistributor.sol:165). So nobody can push IMD into a contract that has no way to move it. The author's test test_contractHolderMustClaimItself passes. What's left is that such a contract still counts toward eligible supply, so it dilutes wallets' share. The author closed this with the third option my finding offered: the README's "Custodial holders" section and launch.json notes now state it as a launch requirement. The code can't do more here because the contracts are never given the swarm contract's address.
• [low] Launch-block fees reward same-block buyers: still reproduces. A buyer gets back at most its own fee share, and it can only happen in the launch block; documented at README line 120. Not restated.
• [low] 1-wei transfers forcing extra claim calls: still reproduces, but it costs the victim gas only, never their rewards, and the attacker pays for each transfer. Documented. Not restated.
• [low] Fee-free hookless RIMD/IMD pool: still reproduces, but it comes with the hook-only fee the brief asked for. Documented. Not restated.

Checks on the current tree

• Tests: the full suite passes, 105 of 105. I couldn't run the protected floor tests: they import harness files (src/HookFlags.sol, mocks/*, floor/*) that aren't in this tree. I deleted my scratch copy afterwards.
• Size limits: the hook is 12,498 bytes deployed and 36,654 bytes of creation code (which includes the distributor it creates), under the 24,576 and 49,152 limits.
• Hook address bits: the five permissions encode to 0x20cc, which matches getHookPermissions and launch.json.
• Constructor arguments: launch.json lists them in declaration order.
• Pool: fee 12500 and tick spacing 60 match the hook's constants.
• Fee accounting: I traced it on both the specified and unspecified sides. In each case the hook mints the distributor a claim equal to the fee it charges, so the balances net to zero and no transfer is needed mid-swap.

Nothing new came up that I could reproduce. The static-analysis leads didn't hold up either:

• Strict equalities: they are guards and are correct as written.
• "Uninitialized" locals: they default to zero on purpose.
• Reentrancy flagged in claimFor: the function is nonReentrant, saves the claim progress before it calls the pool manager, and the callback only accepts the exact claim in progress.

The specialists' EIP-7702 note is also not a defect. A delegated wallet can't have a third party claim for it, but it can still call claim itself and loses nothing.