AUDIT-NOTES.md and DEPLOY.md accept the 4663 RANDOM-mode weakness with the bound that RANDOM 'must stay off' there.

Nothing enforces it: script/DeployMiyamints.s.sol deploys MiyaPoolFactory on every chain, the factory has no owner, no chain gate and no mode allowlist, and createPool(collection, RANDOM) is open to anyone for any ERC721.

On an Arbitrum-stack chain the weakness is worse than on mainnet: block.number is the L1 block estimate, blockhash is a sequencer-known pseudo-random value, and the EIP-2935 history contract has no code, so MiyaPool._blockHash returns 0 after 256 L1 blocks (about 51 minutes) and revealRedeem re-arms the commit instead of settling it.

A committer who computes the pick from the mined target block (pick = keccak(seed, pool, commitId, i) over the deposit-order queue) and dislikes it can simply not reveal; on a quiet pool nobody else does, and after 256 L1 blocks the next reveal gives a fresh draw. Repeated until a desirable id comes up. The accepted item's stated bound (keep it off) is therefore wrong for the code as it ships: it is an operational wish with no mechanism behind it.

Every instance snapshots registry.treasury() as an immutable and pays the protocol cut with SafeTransferLib.safeTransferETH, which reverts if the treasury rejects ETH. The same pattern is in ERC721AuctionInstance.reclaimUnsold (line 393), ERC721DropInstance.withdraw (line 239) and ERC1155Instance.withdraw (line 477).

The owner-side payments were already hardened against this (forceSafeTransferETH for the deposit refund, SmartTransferLib for the artist, parking for the vault cut), but the treasury leg was not. For auctions this is the only path that releases the winning bid and the creator's deposit, so a non-receiving treasury locks them forever; for drops it locks all mint proceeds; the registry owner changing the treasury does not help because the instance's copy is immutable.

The deploy script's only check on TREASURY is _requireCode, which the INFER token address or any non-payable contract passes.

The mainnet fork test exercises a split against the real imdUSD Treasury at the fork block, and the verified source on Etherscan (contract 'Treasury', not a proxy) has a payable receive, so the current mainnet treasury is known to accept ETH today; the risk is a treasury that is upgradeable, replaced on 4663 by an arbitrary 'Safe/treasury you control', or any future state in which it rejects plain ETH.

convertAndAddLiquidity books LP yield with _collectAndAccumulateVaultFees(true) before the swap, but every pass of _swapAndAdd then swaps ETH through the vault's own pool. The vault's full-range position earns its share of the 1% fee on that swap. The following _addToLpPosition calls modifyLiquidity, whose returned delta is principal net of feesAccrued, so the vault pays that much less ETH than amount0 and the fee ETH stays in the balance.

The next pass (or the next batch) measures it as ethForLP and adds it as liquidity, so it is credited as shares to the current or next batch rather than as fees (accFeePerShare) to the holders who owned the position when it was earned. Question 1 asks whether fees earned before a batch closes stay with earlier holders: fees generated by the batch's own swap do not.

The amount per conversion is the vault's share of pool liquidity times 1% of the ETH swapped (about half the batch), so at most 0.5% of each batch, and it grows as the vault becomes most of the INFER pool. AUDIT-NOTES' Leftovers item describes 'fees earned by the position net off what it pays in' as a windfall to the next batch, so the bound is stated; this is reported because it is a systematic transfer from old holders to new batches rather than rounding dust.

Both reference prices are integers scaled by 1e18 (wei of WETH per whole token). For a token worth less than 1e-18 ETH per unit the V3 price (line 337, token0 == WETH case) and the V2 price (line 246, priceV2 = (uint256(reserve0) * 1e18) / uint256(reserve1)) truncate to 0, and _checkPriceDeviation (line 377) treats a zero price as unacceptable, so validatePrice reverts PriceDeviationTooHigh on every call.

Between about 1e-18 and 1e-16 ETH per unit the prices are small integers (1..100), so one tick of TWAP rounding or one wei of reserve imbalance produces a deviation of hundreds to thousands of bps against the 500 bps limit, and the conversion reverts although the pools agree.

The vault calls validatePrice at the top of convertAndAddLiquidity (UniAlignmentVault.sol:386), so the pending ETH of that vault can never be converted while the two reference pools exist; the keeper's floors do not help because the revert happens before the swap. Only tokens with a V2 pair holding at least 10 WETH and a V3 pool holding at least 10 WETH with a TWAP are affected.

INFER (about 2.7e6 per ETH) is not in that range, so the deployed default vault is unaffected; any future vault for a high-supply low-price token is.

Fix: compare prices in a higher-precision fixed point (e.g. Q96 or 1e36 scale, computed with fullMulDiv), or skip the cross-check when either price is below a precision floor instead of treating it as a deviation.

The treasury address is snapshotted as an immutable in each instance (auction protocolTreasury, drop treasury, 1155 protocolTreasury) and MiyaRegistry.setTreasury only affects future launches. The protocol cut is paid with safeTransferETH, which reverts on failure, while the vault cut and the artist share have fallbacks (try/catch parking, WETH fallback). On mainnet the treasury is the imdUSD Treasury contract (config note: a 25 kB contract).

The fork test asserts it accepts plain ETH today, but if it is ever upgraded, paused, or replaced so that its receive path reverts, then for every collection already launched: settleAuction reverts (the winner's bid and the token are locked in the instance forever, since the auction cannot be settled or reclaimed), ERC721DropInstance.withdraw reverts (proceeds locked), and ERC1155Instance.withdraw reverts. There is no owner path to change the treasury of an existing instance.

Not a code defect in the split math, but the treasury is the single reverting dependency in all three paths and should be documented as a trust assumption or given the same parking fallback the vault cut has (park protocolCut in a pendingProtocolCut and let anyone flush it).

convertAndAddLiquidity force-collects LP yield once (line 376), before any swap. _swapAndAdd then swaps the batch through the vault's own pool (zRouter, 1% tier), so the vault's existing full-range position earns that swap fee, and then calls modifyLiquidity with a positive delta on the same position (salt 0). v4 returns principal + feesAccrued in one callerDelta, so the fee comes off what the vault pays in.

It is never passed to _creditYield: it sits in the balance as 'free' ETH (address(this).balance - owed), and a later pass or the next batch picks it up as LP. The holders before the close (whose liquidity earned it) get nothing, and the protocol misses its 1% cut. This breaks question 1's property that fees earned before a batch closes stay with earlier holders.

AUDIT-NOTES (round 1, 'Leftovers', Low) says fees 'net off what it pays in' and calls the result a 'small windfall' for the next batch. It does not say the fee comes out of existing holders' yield on every conversion, or that on a thin pool, where the vault is most of the liquidity, it is almost all the yield from that volume (about 0.33% of each batch here).

Fix: credit the fees inside the add. Either poke the position (liquidityDelta 0) and _creditYield the ETH before each pass's add, or read feesAccrued from modifyLiquidity's second return value in unlockCallback and credit it (ETH via _creditYield, tokens to pendingFeeTokens) before measuring leftovers.

AUDIT-NOTES.md accepts, as a bound, that RANDOM pools 'must stay off' on chain 4663 because the Arbitrum-stack blockhash is 'cryptographically insecure, pseudo-random' and 'does not come from the parent chain' (Arbitrum docs, Solidity support page; Nitro's arbos/blockhash fills skipped L1 numbers with keccak of known data).

The bound is wrong as a bound: MiyaPoolFactory is ownerless and permissionless, has no chain gate, and DeployMiyamints deploys it unchanged on 4663 (step 8, same CREATE3 address on every chain by design). Anyone can call createPool(collection, RANDOM) there.

MiyaPool._blockHash (src/pools/MiyaPool.sol:369-374) then uses blockhash() for the last 256 'blocks' (which on 4663 are estimated L1 numbers) and the EIP-2935 lookup returns 0 because HISTORY has no code there, so every reveal draws from a sequencer-controlled value and anything unrevealed for 256 L1 blocks is re-armed.

Redeemers who commit lose the fairness the mode promises, and the sequencer (or whoever controls the first L2 block that sees the target L1 number) can pick which ids a commit receives. The code, not the runbook, has to keep the mode off on that chain.

Fix: refuse RANDOM in createPool unless the chain has secure block hashes, e.g. if (mode == RANDOM && (block.chainid != 1 || HISTORY.code.length == 0)) revert RandomUnsupportedHere(); or an immutable randomAllowed set by the deploy script per chain.

Proof test: test/scratch/RandomPoolOnArbitrumStack.t.sol (written, not executed: the shell sandbox never started in this session; it expects createPool RANDOM to revert with chainId 4663 and fails on the current code because the pool is created).

AUDIT-NOTES states 'The keeper's floors are the only price protection' and bounds a malicious keeper at 'the whole batch'. For an outside attacker the floor only catches the direction where the vault receives fewer tokens.

If the attacker sells INFER into the thin 1% pool in the block before the keeper's (private-mempool) conversion, the keeper's live quote already reflects the depressed price, the vault buys more tokens than minOutTarget, _swapAndAdd adds full-range liquidity at the depressed spot (no band check: validatePrice is a no-op for INFER, which has no v2/v3 pool, and calculateSwapProportion only sets the split), and the attacker buys back through the now-deeper pool.

The vault's loss is the impermanent loss of the new position across the price deviation; the attacker pays the 1% fee twice on their leg.

At the 1% tier this is only profitable when the batch is a sizeable fraction of pool depth (roughly: IL of ~5-6% on the batch at a 50% deviation versus ~2% fee on a sale of ~0.3x depth), which is exactly the regime the notes already tell the keeper to avoid ('convert often enough that batches stay small against the pool'), but the notes attribute the protection to the floors, which cannot see this direction.

Not run: numbers above are from the constant-product/IL approximations, not from a PoolManager run. Fix options that preserve the design: have the keeper pass a maximum tokens-out (or a sqrtPrice band) alongside minOutTarget and revert when spot is outside it, or have the keeper skip conversion when the batch exceeds a fraction of the pool's virtual depth.

computeVaultAddress assumes CreateX's 'msg.sender-permissioned, no redeploy protection' branch (first 20 bytes of salt == factory, byte 21 == 0x00). deployVault passes the owner's salt to CreateX unchanged (line 73) and nothing in the factory shapes it. For any other salt CreateX's _guard hashes it as keccak256(abi.encode(salt)), an unpermissioned salt that anyone can use through CreateX first.

Consequences: (1) the preview address is wrong, so an app or runbook that announces computeVaultAddress(salt) announces an address the vault will never have; (2) an attacker who sees the owner's pending deployVault can front-run the CREATE3 address with any contract, making the owner's transaction revert (denial only: the owner picks a new salt).

The deploy script avoids this by building the salt as factory || 0x00 || 11 bytes, but the factory is a long-lived owner entry point. The auction and 1155 factories already build the salt internally (_creatorSalt); do the same here: derive the CreateX salt inside deployVault from the caller-supplied salt, and compute the preview from the derived salt.

The vault cut is parked on failure (pendingVaultCut) on all three paths, but the protocol cut is sent with safeTransferETH, which reverts the whole call: ERC721DropInstance.withdraw (line 239), ERC721AuctionInstance.settleAuction (line 329) and reclaimUnsold (line 393), ERC1155Instance.withdraw (line 477). The treasury is immutable per collection and snapshotted from the registry at launch.

If it cannot accept a plain ETH call, a drop's and an edition's entire proceeds (artist share and vault cut included) are stuck, and an auction can never settle: the winner's bid stays in the contract, the token is never minted, and the line never advances.

I checked the mainnet treasury 0x6Ac8fF96Fb8DCF5d79A8eF1E59D9AC23f2BD27Bc on Etherscan: verified 'Treasury', not a proxy, has a payable receive(), so mainnet is safe as configured; the fork test's treasury-balance assertion also confirms it. On 4663 TREASURY is an env value the script only checks for code (_requireCode), and setTreasury on the registry can later point new collections anywhere.

Fix: park the protocol cut like the vault cut (pendingProtocolCut + permissionless flush), or at least have DeployMiyamints._check send 1 wei to the treasury and revert if it is refused.

Two ways the backstop can veto a conversion it should not. (1) priceV2 is the pair's current reserves (lines 246/250), not a TWAP, while priceV3 is a 30-minute TWAP; once a token has a v2 pair holding >= 10 WETH and any v3 pool with >= 10 WETH, a swap in the pair that moves spot by more than maxPriceDeviationBps (5%) in the same block as the keeper's conversion makes validatePrice revert.

The keeper's private mempool stops a targeted sandwich, but a griefer who keeps the v2 pair skewed (paying the arbitrage) blocks every conversion of that token for as long as they fund it; the notes bound this at '10 WETH (recoverable)', but the v2 side does not even need to be at a wrong price permanently, only during the keeper's blocks.

(2) _rawPrice/price lose precision for very low prices: when token0 == weth, price = 1e36 / rawPrice is 0 once a token trades above 1e18 raw units per WETH, and priceV2 = reserveWETH*1e18/reserveToken is 0 at the same ratio; _checkPriceDeviation treats a zero as 'not acceptable' (line 377-379) and validatePrice reverts, so a real v2+v3 token at that price could never convert.

Neither applies to INFER today (no v2 or v3 pool, ~2.7e6 per ETH), so impact is limited to future alignment targets.

Fix: use the v2 pair's cumulative price (or drop the v2 leg, as the notes already consider it a backstop), and skip rather than revert when either price rounds to zero.

setUp swallows any createSelectFork failure and every test then vm.skip()s, so a green forge test on a machine without network (as in this review session) proves nothing about the deployment; CI must assert the fork tests ran.

When they run, setUp seeds its own ETH/INFER pool with 100 ETH at about 2.7M INFER/ETH if the real pool is absent, so the 'largeBatches' test (10 ETH against ~100 ETH of depth) is a 0.1x-depth case, not the 'one far bigger than the pool' its comment claims, and the no-windfall test's 12% threshold is loose against a 1-in-110 share. The conversions use floors of (1, 1), so the keeper's price protection is never exercised.

The on-chain checks for Q14 I could not perform: the shell was unavailable, so no cast code; Etherscan confirms zRouter 0x0000...00e4 (verified, swapV4 present), the treasury (verified, payable receive) and INFER (18 decimals, plain ERC-20 ABI); the 4663 addresses (PoolManager, WETH, v3 factory, USDG) could not be verified because Blockscout refused the requests, so they stay 'as configured, unverified'.

Merged from three specialists (audit_flow, audit_math, audit_permissions).

AUDIT-NOTES.md ('Accepted or deferred') and DEPLOY.md accept that RANDOM redeem is unsafe on chain 4663 (Arbitrum stack: block.number is an L1 estimate, blockhash is sequencer-influenced pseudo-randomness, the EIP-2935 history contract has no code so MiyaPool._blockHash returns 0 after 256 L1 blocks and revealRedeem re-arms the commit) with the bound 'RANDOM needs a different source of randomness, or must stay off, before any 4663 deployment'.

Verified against the code: the only mode restriction in MiyaPoolFactory.createPool is the ERC1155+RANDOM check on line 30; the factory is ownerless and has no chain or mode gate; script/DeployMiyamints.s.sol line 259 deploys MiyaPoolFactory unconditionally on every chain (the config for 4663 exists and DEPLOY.md gives the 4663 broadcast command).

So on 4663 anyone can call createPool(collection, RANDOM) for any ERC721 and depositors into that pool get the insecure draw: a committer reads blockhash(targetBlock) once mined and, disliking the pick, waits 256 L1 blocks for a re-arm (MiyaPool.sol lines 295-302, 369-371), and the sequencer can influence the hash. The stated bound is an operational wish with no mechanism; as shipped, the 4663 deployment offers the mode the notes say must be off.

Fix: gate RANDOM in createPool (e.g. revert unless block.chainid == 1, or unless HISTORY.code.length != 0), or an immutable per-chain flag set by the deploy script, or leave MiyaPoolFactory out of the 4663 deployment.

Not executed: the shell sandbox never started in this session, so forge was not run; this is established by reading MiyaPoolFactory.createPool, MiyaPool.commitRedeem/revealRedeem/_blockHash and the script.

The attached proof is the audit_flow specialist's test, read and judged sound (solady ERC721 answers ERC-165 for 0x01ffc9a7 and 0x80ac58cd and false for 0xffffffff, so _detectKind passes and the pool is created, which makes vm.expectRevert fail on the current code); it was not run here.

Merged from audit_permissions and audit_economics. convertAndAddLiquidity books LP yield once with _collectAndAccumulateVaultFees(true) (line 376) before any swap, and the comment on lines 374-375 states this is so fees accrued before the new shares are minted stay with existing holders. Every pass of _swapAndAdd then swaps ETH through the vault's own pool (lines 467-470), so the vault's full-range position earns its share of the 1% fee on that swap.

The following _addToLpPosition calls PoolManager.modifyLiquidity with a positive delta on the same position (salt 0); Uniswap v4 returns callerDelta = principalDelta + feesAccrued, and unlockCallback/_settleLPDelta settles callerDelta, so the vault pays that much less than amount0/amount1 and the fee ETH and fee tokens stay in its balance.

They are never passed to _creditYield: the next pass (line 457/459, ethAvailable and tokensHeld) or the next batch measures them as free and adds them as liquidity, and _closeBatch assigns the resulting shares to the batch. Holders before the close get nothing and the protocol misses its 1% cut.

Magnitude: vault share of pool liquidity x 1% x ETH swapped (about half the batch), so up to about 0.5% of each batch, growing toward that as the vault becomes most of the INFER pool.

AUDIT-NOTES round 1 'Leftovers' says fees 'net off what it pays in' and calls the result a small windfall for the next batch, so the size is stated, but it does not say the windfall is taken from existing holders' yield on every conversion, which contradicts the H2 guarantee that fees accrued before a join stay with existing holders (question 1).

Fix: inside each pass, after the swap and before _addToLpPosition, poke the position (liquidityDelta 0, as _claimVaultFees does) and route the ETH through _creditYield and the tokens into pendingFeeTokens; or read feesAccrued (modifyLiquidity's second return value) in unlockCallback and credit it before measuring leftovers.

Not executed: forge could not be run in this session; traced through v4 PoolManager.modifyLiquidity semantics and the vault code. The audit_economics specialist attached a real-PoolManager test (.imd/reads/proofs/Proof_447c93c0ac74.t.sol) reporting a 0.0644 ETH shortfall for the earlier holder on a 20 ETH batch against 1 ETH of third-party depth; I could not run it, so its numbers are reported as the specialist's.

Merged from audit_flow, audit_math and audit_permissions. Each instance snapshots registry.treasury() as an immutable at launch and pays the protocol cut with SafeTransferLib.safeTransferETH, which reverts the whole call on failure: ERC721AuctionInstance.settleAuction (line 329) and reclaimUnsold (line 393), ERC721DropInstance.withdraw (line 239) and ERC1155Instance.withdraw (line 477).

The other legs were hardened (forceSafeTransferETH for the deposit refund, SmartTransferLib WETH fallback for the artist, try/catch parking for the vault cut), but the treasury leg was not, and MiyaRegistry.setTreasury only affects future launches, so there is no recovery path for an existing instance.

For an auction, settleAuction is the only path that releases the winning bid, mints the token and refunds the creator's deposit; reclaimUnsold reverts HasBids, so a rejecting treasury locks the bid, the deposit and the line forever.

The mainnet treasury is the imdUSD Treasury contract; the specialists report its verified source has a payable receive() and the fork test asserts it receives the cut, so mainnet is safe as configured today; I could not confirm this on chain (Etherscan refused the unauthenticated request).

On 4663 TREASURY is an env value the script only checks with _requireCode (any contract passes, including a token), and a future treasury that is upgradeable or paused would trigger it on mainnet too.

Fix: park a failed protocol cut in a pendingProtocolCut with a permissionless flush (mirroring pendingVaultCut), or use forceSafeTransferETH; and have the deploy script prove the treasury accepts a 1-wei call.

Not executed: reading only.

Merged from audit_flow and audit_permissions. deployVault passes the owner-supplied salt to CreateX.deployCreate3 unchanged (line 73) and nothing shapes it.

CreateX's _guard applies the msg.sender-permissioned hash keccak256(sender ‖ salt) only when the salt's first 20 bytes equal msg.sender and byte 21 is 0x00 (0x01 adds the chain id; any other flag byte reverts InvalidSalt); a salt whose first 20 bytes are zero is chain-id-guarded, and any other salt is hashed as keccak256(abi.encode(salt)), i.e. unpermissioned. computeVaultAddress always applies the sender-guard formula, so for any salt not prefixed factory ‖ 0x00 it returns an address the vault will never have, and because that salt is unpermissioned anyone who sees the owner's pending deployVault can deploy anything at the real CREATE3 address through CreateX first, making the owner's transaction revert (denial only; the owner picks a new salt).

The deploy script builds a correctly prefixed salt (DeployMiyamints.s.sol lines 276-280), so the default vault is unaffected; the factory is a long-lived owner entry point and the auction and 1155 factories already derive their salts internally (_creatorSalt).

Fix: derive the CreateX salt inside deployVault from the caller-supplied salt (factory ‖ 0x00 ‖ bytes11(salt)) and compute the preview from the same derivation, or revert when the salt is not so prefixed.

Not executed: reading of the factory and CreateX's _guard.

Merged from audit_flow and audit_math. Two ways the backstop vetoes a conversion it should not, both only for a token that has a v2 pair holding at least 10 WETH and a v3 pool passing the depth checks (INFER has neither today, so the default vault is unaffected).

(1) priceV2 is the pair's current reserves (lines 246/250), not a TWAP, while priceV3 is a 30-minute TWAP; a swap in the v2 pair that moves spot by more than maxPriceDeviationBps (500) in the same block as the keeper's conversion makes validatePrice revert PriceDeviationTooHigh at the top of convertAndAddLiquidity (vault line 386), before the keeper's floors matter.

The private mempool stops a targeted sandwich, but a griefer who keeps the pair skewed (paying arbitrage) blocks every conversion while they fund it; AUDIT-NOTES bounds this at '10 WETH (recoverable)' in the v3 pool, but the v2 side only needs to be off during the keeper's blocks.

(2) Both prices are wei of WETH per whole token as integers: when token0 == weth, price = 1e36 / rawPrice (line 337) is 0 once a token trades above 1e18 raw units per WETH, and priceV2 = reserveWETH*1e18/reserveToken (line 246) is 0 at the same ratio; _checkPriceDeviation treats a zero as unacceptable (lines 377-379), so validatePrice reverts unconditionally.

Between about 1e-18 and 1e-16 ETH per unit the prices are small integers, so one tick of TWAP rounding yields deviations of thousands of bps and the conversion reverts although the pools agree.

Fix: compare in higher precision (Q96 or 1e36 via fullMulDiv), use the v2 pair's cumulative price or drop the v2 leg, and skip rather than revert when either price rounds to zero.

Not executed: arithmetic checked by hand.

From audit_permissions, verified. AUDIT-NOTES 'Keeper trust (M2)' says the keeper 'can sandwich its own conversion with low floors and take up to the whole batch being converted. It cannot touch earlier LP positions or settled fees.'

The token side of LP yield accumulates in pendingFeeTokens from every claim and conversion and belongs to existing holders; it is sold only by the keeper through _convertPendingFeeTokens with a keeper-chosen minEthOut, where any value >= 1 passes (lines 622-644) and 0 leaves the tokens pending.

A keeper (or whoever holds its key) that front-runs convertFeeTokens(1) with a large sell into the ETH/INFER pool and back-runs it captures essentially all of that yield, which is neither the batch being converted nor settled fees; the same applies to minEthOutForFees inside convertAndAddLiquidity. Question 6 asks whether the notes state the keeper's powers fully: they do not.

This is an existing trust assumption (the keeper is trusted and replaceable), reported so the written bound matches the code.

Fix: document it, or bound minEthOut against a quote from pool state at call time.

Not executed: reading only.

From audit_flow, verified as a property of the code (numbers not run). AUDIT-NOTES says 'The keeper's floors are the only price protection'. The floor only catches the direction in which the vault receives fewer tokens than quoted.

If an attacker sells INFER into the thin 1% pool in the block before the keeper's conversion, the keeper's live quote already reflects the depressed price, the vault buys more tokens than minOutTarget, _swapAndAdd adds full-range liquidity at the depressed spot (validatePrice is a no-op for INFER, which has no v2/v3 pool, and calculateSwapProportion only sets the split), and the attacker buys back through the now-deeper pool.

The vault's loss is impermanent loss on the new position across the deviation; the attacker pays the 1% fee twice. At the 1% tier this only pays when the batch is a sizeable fraction of pool depth, the regime the notes already tell the keeper to avoid, but the notes attribute the protection to the floors, which cannot see this direction.

Fix options that keep the design: have the keeper pass a maximum tokens-out or a sqrtPrice band alongside minOutTarget, or skip conversion when the batch exceeds a fraction of the pool's virtual depth. Not executed.

From audit_flow, verified in the test source. setUp swallows any createSelectFork failure (lines 95-97) and every test then vm.skip()s, so forge test on a machine without network exits green while the deployment is untested; CI must assert the fork tests ran.

When they do run and the real pool is absent, setUp seeds its own ETH/INFER pool with 100 ETH (lines 107-112), so the 'large batches' test converts batches of about a tenth of depth rather than batches far larger than the pool, and the no-windfall threshold is loose against a 1-in-110 share. The conversions use floors of (1, 1), so the keeper's price protection is never exercised.

On the Q14 on-chain checks: in this session the shell did not start, so no cast calls were made, and both unauthenticated lookups I tried (Robinhood Blockscout API, Etherscan v2 API) were refused; the config addresses for 1 and 4663 remain 'as configured, unverified by this review' beyond the specialists' Etherscan reports for zRouter, the treasury and INFER.