minimumBuybackOutput returns 0.995 x (600 s time-weighted tick price) x amountIn with no allowance for the buyback's own price impact, and the vault forwards the same value as the router's amountOutMinimum.

At the live pool state read on chain 4663 (poolId 0x51c9a3...e6a7, tick 146722, liquidity 0x979f97c03cfd2286419 ~= 4.47e22, i.e. about 29.2 ETH of virtual currency0 reserve, LP fee 0, hook fee exempt for the vault), an exact-input zeroForOne swap of 0.5 ETH returns about 98.3% of the spot reference, 0.25 ETH about 99.15%, 0.15 ETH about 99.49%, and 0.14 ETH about 99.52%.

Any Plan with amountIn above roughly 0.14 ETH therefore reverts inside the router (V4TooLittleReceived) even when the time-weighted reference equals spot, so the constructor argument initialMaxBatch = 500000000000000000 is not reachable and the effective per-block buyback cap is set by liquidity, not by maxBatch. This is a liveness and configuration limitation, not a loss of funds: the floor is working as designed and the keeper can submit smaller batches.

It also means the oracle floor is effectively stricter than 50 bps relative to execution price, which should be stated in the activation notes. Minimal fix (optional): size initialMaxBatch and keeper automation to the liquidity-feasible amount, or document that batches must shrink as liquidity falls; changing OUTPUT_FACTOR would alter the agreed policy and is not recommended by this review.

The floor is derived from the pool's own 600 s time-weighted tick, not from an external fair-value source. The pool charges a 2% hook fee on the ETH side of every non-exempt swap and 0 LP fee, so any price deviation below about 2% is unprofitable for arbitrageurs to correct and persists until organic flow moves it.

Same-timestamp spikes carry no weight and a single-block attack cannot move the window (verified), but a slow attack does: at live liquidity (~29.2 ETH virtual reserve) pushing CLAUS 1.9% more expensive requires buying about 0.28 ETH of CLAUS and costs about 0.011 ETH in hook fees for the round trip.

After 600 s the mean tick fully reflects the shifted price, meanTick rounds toward +infinity (which is the conservative direction for ETH->CLAUS and does not help the attacker but also does not hurt), and the vault's floor becomes 0.995 x shifted price.

Each subsequent buyback (at most ~0.14 ETH per block given finding 1) then buys at a price up to ~2.4% worse than the pre-shift price, worth about 0.0034 ETH to the holder who sells into it; break-even after roughly four keeper buybacks, and the holder additionally benefits from the burn pressure.

The same mechanism works against the vault in a legitimate uptrend: if CLAUS appreciates more than 0.5% within 10 minutes, buybacks revert until the window catches up (safe direction). This is a design limitation the README acknowledges; it is reported here with numbers because the activation notes should state the bounded extraction.

No code change is required to preserve the agreed policy; options that change policy are a larger slippage allowance paid for by a longer window, capping buybacks per window, or an external reference.

After the first upgrade the ORACLE_SLOT namespace persists in the proxy.

If the administrator rolls the proxy back to the original implementation (which never writes that namespace) and later upgrades to this implementation again without calling initializeBuybackOracle, record() sees count != 0 and does not reset; meanTick extrapolates the last pre-rollback tick across the whole gap (branch time >= self.timestamp), so the window is immediately 'ready' with a reference that may be far from the live price.

If the stale tick is lower than the live tick (CLAUS was more expensive before), the floor is too low and the vault accepts correspondingly worse fills. The README documents this as a trusted-administrator obligation and the atomic batch includes the reset; this entry records that the code itself cannot enforce 'exactly once after every activation'.

Hardening option that keeps policy: store the implementation address or a monotonic activation nonce in the oracle namespace and reset when it differs from the current implementation (ERC-1967 slot read), which is a small scope decision for the owner.

Trust assumptions verified against live chain 4663 state, not defects: the vault owner and hook owner are the administrator 0x979d...dc46; its owner (founder) is 0xbb14...f1c5 and its operator is 0x8aca...4cfa. ClausAdministrator.execute lets either the founder or the operator call any selector on any managed target except renounceOwnership and (operator only) transferOwnership.

Managed targets include the hook proxy 0x15bb...bfff, its ProxyAdmin 0xf2ea...4ac0 (owner = administrator, exposes upgradeAndCall), the old vault, the CLAUS token proxy 0x1630...ffac (ERC-1967 implementation 0xd687...4bff) and the token's ProxyAdmin 0xcbc4...22a8 (owner = administrator).

Consequences: (a) the operator, not only the founder, can upgrade the hook to arbitrary code, replacing every buyback safeguard; (b) the operator can upgrade the token implementation, which the vault depends on for burn(uint256), balanceOf and totalSupply semantics (the burn-mismatch check would then be the only guard); (c) recoverUnspentFees(recipient, amount) sends any amount of vault ETH to any address; (d) initializeBuybackOracle can pause buybacks for 600 s at any time; (e) setAdvisorEnabled / setFeeRecipient / setLiquidityShare change future accrual at will.

The new vault must additionally be registered via setTarget(newVault, true) by the founder before configure/recoverUnspentFees on it can run; this is a post-deployment gate, not yet observable. No keeper or advisor holds any of these powers (verified: keeper can only call buyAndBurn under the floor and per-block limits; advisor is a constant payee).

Live state: hook allocation vault = old vault 0x6be6...0dcd, liquidityOwed = 0x4043002718e wei (about 4.4e12 wei) held as ERC-6909 native claims, old vault ETH balance = 0, treasuryOwed = 0. Anyone may call claimLiquidityFees() at any time; before setLiquidityVault(newVault) executes it sends the owed amount to the old vault.

If the activation batch encodes recoverUnspentFees(newVault, amount) with a precomputed amount, such a claim between planning and execution leaves the difference in the disabled old vault. Funds are not lost (the owner can recover later) and the amount today is negligible, but the batch should either call claimLiquidityFees() itself before the recovery step or read the old vault's balance at execution time.

Also verified: after the batch, old-vault buyAndBurn is blocked both by enabled == false and by the 'Fee destination changed' check, and the new vault's pre-swap claimLiquidityFees inside buyAndBurn is unaffected by treasury or advisor recipients.

The README states that every activation, including a return after rollback, must reset the oracle and require a fresh 600-second warmup. The code can only enforce this when ORACLE_SLOT is empty (count==0, auto-seed in BuybackOracle.record at flat/MigrationFeeHookV2.sol:1688).

If the proxy is rolled back to the old implementation (which never writes the oracle) and later re-upgraded to this implementation, the slot still holds count>0, timestamp and tick from before the rollback. meanTick then extrapolates the last pre-rollback tick across the whole gap and minimumBuybackOutput is served on the first call, with no OracleNotReady revert.

The reset is onlyOwner, so it cannot be executed atomically inside ProxyAdmin.upgradeAndCall (msg.sender would be the ProxyAdmin 0xf2ea...4ac0, not the owner 0x979d...dc46); it must be a separate call in the administrator batch and the hook cannot detect its omission.

Impact is bounded: the keeper still needs minBuyOutput >= floor and the router enforces it, so a stale floor that is too LOW lets a buyback fill up to the full real-price gap below the intended 50 bps tolerance, while a stale floor that is too HIGH blocks buybacks until a swap-driven window passes. This is the residual the README asks to assess; it is a verified gap, not a bypass by an unprivileged actor.

Minimal fix that preserves the design: let initializeBuybackOracle also accept msg.sender == the ERC-1967 admin read from slot 0xb531...6103 so the batch can call ProxyAdmin.upgradeAndCall(proxy, impl, abi.encodeCall(initializeBuybackOracle)) and the reset becomes atomic with every upgrade; alternatively store the implementation address from slot 0x3608...2bbc in BuybackOracle.State at reset and revert OracleNotReady in minimumBuybackOutput when it differs from the current one (this still cannot detect an identical-implementation round trip).

Live state on chain 4663 (block 0x67bc9cf): administrator 0x979d...dc46 has owner (founder) 0xbb14...f1c5 and operator 0x8aca...4cfa; managedTarget is true for the hook proxy 0x15bb...bfff, the old vault 0x6be6...0dcd, the hook ProxyAdmin 0xf2ea...4ac0 (OZ 5.0.0, owner = administrator), the token proxy 0x1630...ffac and the token ProxyAdmin 0xcbc4...22a8 (OZ 5.0.0, owner = administrator). execute() lets the operator call any selector on these targets except renounceOwnership and transferOwnership.

Therefore, in addition to the hook powers the task documents (setFee up to 999999 pips, setFeeRecipient which redirects the already-accrued treasuryOwed, setLiquidityShare 0..100%, setLiquidityVault to any contract which redirects accrued liquidityOwed, setAdvisorEnabled, initializeBuybackOracle which imposes a new 600 s pause each call, vault.configure, vault.recoverUnspentFees to any address, vault.buyAndBurn as owner), the operator can call ProxyAdmin.upgradeAndCall on the hook proxy and on the token proxy.

An upgraded hook can drop the fee split, the oracle floor, the exemption authentication and the advisor payment; an upgraded token can defeat the vault's burn and totalSupply checks. The README acknowledges the hook upgrade residual; the token ProxyAdmin being a managed target is not mentioned. Founder recovery (setOperator(0), setTarget(x,false)) stops future operator calls but cannot undo an executed upgrade or an executed recoverUnspentFees.

This is the agreed ownership model, reported as a trust assumption rather than a defect; if the requester wants it narrowed without changing the design, the founder can setTarget(ProxyAdmin,false) for both ProxyAdmins after activation so upgrades require the founder key, or a timelock can be placed as ProxyAdmin owner.

Every claim burns exactly the owed amount, so the hook's claims balance at the PoolManager can only ever be reduced to the sum of liquidityOwed + treasuryOwed + advisor.owed. Live reads at block 0x67bc9cf: PoolManager.balanceOf(hook,0) = 28,404,359,304,064 wei while allocation() reports liquidityOwed = 4,416,031,846,798 and treasuryOwed = 0 (advisor not yet present).

The 23,988,327,457,266 wei (about 0.000024 ETH) surplus predates the allocation bookkeeping and is unreachable by claimLiquidityFees, claimTreasuryFees or claimAdvisorFees; the upgrade carries it forward unchanged. Dust-level custody gap, not a loss path: no actor can extract it and the buckets themselves conserve (per swap lp + (treasury-earned) + earned == fee, verified in afterSwap lines 2907-2921).

A minimal fix is an owner-only sweep of balanceOf(hook,0) minus the three owed buckets to the treasury recipient, outside swaps; alternatively document it as intentionally stranded.

The schema's sourceFiles example gives sha256:f4a07bc6... for flat/ClausBuybackVaultV2.sol and sha256:623b0bea... for flat/MigrationFeeHookV2.sol. Recomputing digest({path,content}) with the schema's own canonical-JSON rule over the files in this tree yields sha256:71b51499bc5f729b51c54968f1cf788707eed158f66a69ddc5915a66af435000 and sha256:058a987a89811ce5b8a580284593b85c4c4e8cec7579818d6bf21d37cbf1cfcf. The aggregate manifest.sourceHash sha256:855602e0...

DOES verify (node build/verify-hashes.mjs -> verified:true) and both runtime bytecodes reproduce exactly from the standard inputs with solc 0.8.26 (hook 0x1af00947..., vault 0x8ff1deba...), so this is stale evidence from an earlier candidate rather than a mismatch of the reviewed code.

It matters for the task's requirement that old candidate artifacts and markers must not be mistaken for approval of the v3 policy: a reviewer who checks the schema's per-file hashes would be matching a different source version.

Fix: regenerate the sourceFiles entries from the current files or remove the example values.

buyAndBurn and burnDonatedTokens rely on token.burn(uint256) reducing balanceOf(vault) and totalSupply by exactly the burned amount. The token 0x1630...ffac is an ERC-1967 proxy (implementation slot -> 0xd68727ddd50e8ba07e4be20d37a5ecf3dd814bff, 20,432 bytes of runtime; admin slot -> ProxyAdmin 0xcbc4...22a8 owned by the administrator).

The repository supplies verified sources for the PoolManager and router (dependencies/, non-immutable runtime matched, hashes re-read live: manager 0xbd388118..., router 0x76b92a5b...) and for the old hook implementation (baseline/MigrationFeeHookOriginal.sol compiles byte-exact to the live 0x23ef...3eb7 with solc 0.8.26, viaIR, 200 runs, cancun, bytecodeHash none), but none for the token implementation.

Behavioural probes only: eth_call burn(0) from the old vault succeeds, burn(1) from a zero-balance holder reverts with ERC20InsufficientBalance (0xe450d38c), symbol() == CLAUS, owner() == administrator. The vault's post-burn equality checks will fail closed if burn ever stops behaving as a plain OZ ERC20Burnable, so this is a liveness/limitation note rather than a loss path; it is reported because the task requires missing dependency evidence to be explicit.

For a time at or after the newest observation, _cumulativeAt integrates self.tick forward with no bound on the gap. This is exactly right while this implementation is the live hook (no swaps implies no price change, because LP fee is 0 and liquidity changes do not move price).

It is wrong for the window during which the proxy pointed at the original implementation (which never calls record): swaps move the pool while nothing is written, and on re-upgrade record() sees count != 0 and does not reset. If the administrator omits initializeBuybackOracle in the re-activation batch, the first 600 s of meanTick after re-upgrade are dominated by the pre-rollback tick.

If CLAUS got cheaper during the gap (tick rose) the floor is stricter than spot and buybacks revert (safe); if CLAUS got more expensive (tick fell) the floor is below 0.995*spot and only the keeper's maxTickDrift <= 100 check and the 2% hook fee on any sandwicher's own swaps bound the loss. The code cannot distinguish 'quiet pool' from 'unobserved period', so this is a documented trust assumption on the administrator batch, not a code defect; the README states it.

Verified mitigations: initializeBuybackOracle resets history and forces a fresh 600 s warmup (test_reactivationDiscardsStaleTickAndRequiresFullWindow passes), and the supplied activation batch includes that call.

The floor is 99.5% of the output implied by the 600 s time-weighted mean tick, not of spot. (a) Liveness: if CLAUS appreciates by more than about 50 ticks relative to the mean within the window, every buyback reverts (router V4TooLittleReceived or 'Insufficient output') until the mean catches up; the keeper must retry later. No funds are at risk and this is the intended trade-off.

(b) Manipulation: because same-timestamp ticks carry zero weight and each distinct-timestamp record carries only its elapsed seconds, moving the reference by X requires holding the pool displaced by roughly X for a proportional share of 600 s. Each displacing swap pays the 2% hook fee on its ETH leg in both directions (about 4% round trip, with half of each fee funding the buyback itself), while the maximum gain per block is X times maxBatch (0.5 ETH).

The keeper-side maxTickDrift <= 100 check additionally bounds a same-block front-run to 1% from the quoted tick. With a one-tick-per-ETH-fee asymmetry this is unprofitable at any realistic pool depth; it is reported as the honest limit of an AMM-history reference, not as a defect.

(c) The keeper cannot weaken the floor: minBuyOutput below minimumBuybackOutput reverts at this line and the same value is passed as amountOutMinimum to the router and re-checked against the actual balance delta.

The advisor's share is hard-coded as one tenth of the treasury bucket to the constant ADVISOR address and cannot be changed, which satisfies the fixed-recipient and 100000-pip requirements. The treasury bucket itself is fee - feeliquiditySharePips/1e6 and fee is grossfeePips/1e6, both owner-settable (setFee < 1e6, setLiquidityShare <= 1e6, each onlyOwner and outsideSwap).

The owner is the administrator contract, so this is the intended owner power rather than a bypass, but the '0.1% gross to advisor, 0.9% to founder, 1% to buyback, 2% total' statement is only an invariant while feePips == 20000 and liquiditySharePips == 500000 remain unchanged.

Pending liquidityOwed/treasuryOwed are not affected by either setter; only future accrual changes. setFeeRecipient does redirect the already-accrued treasuryOwed to the new recipient at claim time (event AccruedFeesRedirected documents this); it does not touch advisor.owed.

BuybackOracle.minimumOutput computes referenceOutput = amountIn * price(meanTick) with no price-impact term and then applies the fixed 99.5% factor (OUTPUT_FACTOR at line 1657). The vault enforces p.minBuyOutput >= this value (flat/ClausBuybackVaultV2.sol:2220) and passes it to the router as amountOutMinimum, so a swap whose own impact exceeds 0.5% can never succeed, regardless of what the keeper supplies.

Against live chain 4663 state (block 0x67c0cfc) the pool 0x51c9a331... has active liquidity L = 0x979f97c03cfd2286419 (4.475e22) at tick 146234 (sqrtPriceX96 = 118623215958689183669501967264463), i.e. about 29.9 ETH of virtual ETH in the active range.

A zero-fee exact-input ETH->CLAUS swap of 0.5 ETH yields 1102415406645462985072459 CLAUS versus a floor of 1115252756589057385063355 (out/ref = 0.98355), so buyAndBurn with amountIn = maxBatch = 0.5 ETH reverts in the router with V4TooLittleReceived. 0.3 ETH (0.99006) and 0.2 ETH (0.99335) also fail; 0.15 ETH (0.99501) is the approximate largest passing batch.

No funds are lost (the revert is atomic), but the configured maxBatch of 500000000000000000 wei is economically unreachable and buyback throughput is capped near 0.15 ETH per ArbSys block while liquidity stays at this level. Assumes the active-range liquidity is the only liquidity across the ~330 ticks the 0.5 ETH swap crosses (a single migration position); extra liquidity below the current tick would raise the feasible batch somewhat.

This is a liveness/operational limitation of the fixed-tolerance design, not a value-extraction path; it should be documented and the keeper sized accordingly, or the vault owner should set maxBatch to a value that clears the floor.

BuybackOracle.record is only invoked from the V2 hook's beforeSwap/afterSwap. If the proxy is rolled back to the original implementation (which writes no observations) and later re-upgraded to V2, the ORACLE_SLOT state keeps count != 0, so record() does not re-seed and meanTick extrapolates the pre-rollback tick over the entire gap (the time >= self.timestamp branch).

Because 600 seconds of extrapolated stale tick dominate the window, minimumBuybackOutput is then anchored to a price that may be far from the live AMM price: if CLAUS fell during the gap the floor is too high and every buyback reverts until 600 s of fresh observations accumulate (liveness); if CLAUS rose during the gap the floor is too low and the only remaining protection is the keeper-chosen quotedTick/maxTickDrift (<= 100 ticks ~ 1%) against the keeper's own quote, so a sandwich around the keeper's transaction can take up to roughly 1% of the batch.

The repository's OracleReactivation test shows that calling reset() fixes this, and the README states the administrator must call initializeBuybackOracle on every activation; the contract itself has no implementation-change detection. This is a documented trusted-administrator obligation; it is reported here so the activation runbook keeps initializeBuybackOracle mandatory for every upgrade path, including the rollback->re-upgrade one.

The vault accepts output down to max(keeper minimum, 99.5% of the 600 s time-weighted reference) and only if spot is within maxTickDrift <= 100 ticks (~1.005%) of the keeper's quotedTick.

An attacker who front-runs the keeper by buying CLAUS pays the 2% hook fee on entry and again on exit (the exemption is tied to the vault's own swap via markBuyback, flat/MigrationFeeHookV2.sol:2754-2762) and can extract at most min(1% drift bound, 0.5% + 10-minute TWAP lag) of a batch that is itself capped at maxBatch (0.5 ETH) and, per the companion finding, ~0.15 ETH in practice: about 0.0015-0.005 ETH per block against a 4% round-trip fee on manipulating volume, so it is unprofitable.

Same-second manipulation carries zero weight in the mean (record() only overwrites self.tick at an equal timestamp, lines 1693-1696) and the 601-slot ring always retains >= 600 s of distinct-timestamp history, so eviction by spamming is not possible.

Conversely, when the legitimate price rises more than ~0.5% within the trailing 10 minutes, the floor exceeds what the pool can pay and buybacks revert until the TWAP catches up; a sustained manipulator can also hold the price elevated, but must keep paying 2% per trade and holds the inventory risk. These are inherent to using the pool's own history as the reference, as the README states; no change is required beyond documenting it for the keeper operator.

Live chain 4663 reads (eth_call/eth_getStorageAt at block 0x67c0cfc): hook proxy 0x15bb...bfff has implementation 0x23efc76d... and admin (ProxyAdmin) 0xf2eaa097...; hook.owner() = ProxyAdmin.owner() = oldVault.owner() = administrator 0x979d5810...; administrator.owner() = 0xbb145ca8...

(treasury/founder), administrator.operator() = 0x8aca8890d34086d7a30b9c06fae25e0c3cda4cfa; managedTarget is true for the hook proxy, the old vault, the ProxyAdmin AND the CLAUS token; the CLAUS token 0x1630...ffac is itself a transparent proxy (admin 0xcbc4bbd3..., whose owner() is also the administrator).

ClausAdministrator.execute only blocks renounceOwnership and (for the operator) transferOwnership selectors, so the operator can, without the founder: call ProxyAdmin.upgradeAndCall on the hook proxy (replacing every oracle/fee safeguard), hook.setFee/setFeeRecipient/setLiquidityShare/setLiquidityVault/setAdvisorEnabled/initializeBuybackOracle, vault.configure and vault.recoverUnspentFees(anyRecipient, amount) (draining accrued buyback ETH), and token admin functions.

Note also that setFeeRecipient (flat/MigrationFeeHookV2.sol:2832-2836) redirects the entire already-accrued treasuryOwed to the new recipient on the next claim (the AccruedFeesRedirected event makes this explicit).

None of this is a permission bypass: it is the intended administrator/operator model the brief asks to preserve, the founder retains revocation (setOperator(0)) and ownership recovery, and neither the advisor address nor the keeper receives any of these powers (keeper can only call buyAndBurn within maxBatch, advisor only receives claimAdvisorFees payouts). Recorded so the residual authority is assessed explicitly as the brief requires.

Entry files read in full: flat/MigrationFeeHookV2.sol (contract MigrationFeeHookV2 at 2717-3029, library BuybackOracle at 1654-1757, vendored OZ-upgradeable with ERC-7201 namespaced storage, v4-core libraries) and flat/ClausBuybackVaultV2.sol (contract ClausBuybackVaultV2 at 2141-2277 plus interfaces 2123-2139); baseline hook/vault/administrator and dependency router sources consulted for compatibility.

Verified in code: (1) keeper minimum cannot undercut the fixed 600 s / 50 bps on-chain floor (vault line 2220, constants library lines 1655-1657, all rounding toward the vault: meanTick rounds up, mulDivRoundingUp throughout); (2) treasury/advisor/liquidity settlements are three independent unlock calls, each zeroing only its own debt and restoring it on revert, none called during user swaps, so a rejecting founder or advisor cannot block buybacks or each other (hook 2962-2983); (3) the transient exemption is set only by _allocation().vault outside an unlock and consumed by the next zeroForOne exact-input swap, which must spend exactly amountIn or revert PartialFill (2754-2762, 2888-2892); (4) exact-input full expenditure and atomic rollback: SETTLE_ALL(address(0), amountIn) + hook check + router amountOutMinimum + vault burned >= minBuyOutput and burn/supply equality (vault 2231-2243), one success per ArbSys block (2209-2210, 2222); (5) 2% fee preserved: feePips 20000 live, _grossFee/_netFee give exactly 2% of gross on all four swap shapes, lp = 50%, advisor exactly floor(treasury/10) cumulative with carry; (6) storage compatibility: SETTINGS_SLOT and ALLOCATION_SLOT strings unchanged from the baseline, new state under fresh keccak namespaces, no linear slots added, initialize() is initializer-guarded so re-init after upgrade reverts; (7) same-timestamp writes carry no weight, 601-slot ring always spans >= 600 s, warmup 600 s after reset, int192 cumulative cannot overflow.

Verified live (chain 4663, block 0x67c0cfc): hook proxy impl = declared old implementation, ProxyAdmin 0xf2ea... owned by administrator, hook owner = administrator, feeRecipient = declared treasury, allocation = (500000, oldVault, 4.26e12 wei owed, 0), poolId equals keccak of the declared vaultConstructorArgs pool key, old vault enabled with declared keeper/maxBatch and owner = administrator, administrator owner = treasury EOA and manages hook/oldVault/ProxyAdmin/token; pool manager and router runtime keccaks equal dependencies/manifest.json (0xbd38..., 0x76b9...) and the administrator runtime equals baseline/administrator-proof.json.

Reproduced: node build/verify-hashes.mjs passes; forge build (solc 0.8.26, via-IR, 200 runs, cancun) yields runtime bytecode identical to both artifact runtimeTemplates after stripping CBOR metadata, and the template keccaks equal the manifest runtimeHashes 0x1af0... and 0x8ff1...; the 12 repository verification tests pass.

The approval marker digest equals the canonical sha256 of review-context.json (version 3, advisor fields), so prior two-recipient contexts hash differently.

Not verifiable now (post-deployment gates, reported as limitations, not defects): the new vault is undeployed, so its live runtime, owner, administrator.setTarget registration and the atomic batch receipts do not exist; the hook afterInitialize/oracle has never run on-chain (buybackOracleState reverts on the current implementation, as expected). The buyback floor's price-impact feasibility and the stale-tick rollback hazard are reported as separate findings.

No critical/high/medium defect was substantiated in the assigned economics scope.

Merged from audit_permissions, audit_flow, audit_math and audit_economics (same root cause). BuybackOracle.record only re-seeds when count == 0 (line 1688), and _cumulativeAt extrapolates self.tick across any gap after the newest observation (line 1737). The original implementation 0x23ef...3eb7 never writes ORACLE_SLOT.

If the proxy is rolled back and then upgraded back to this implementation without the owner-only initializeBuybackOracle(), count stays > 0. minimumBuybackOutput then returns a floor based on the pre-rollback tick right away, with no OracleNotReady and no fresh 600 s warmup.

The README requires a reset on every activation, including after a rollback, but only an administrator procedure enforces it. initializeBuybackOracle is onlyOwner, and the owner is the administrator, not the ProxyAdmin, so it cannot run inside ProxyAdmin.upgradeAndCall. It has to be a separate call in the administrator batch. Impact if CLAUS got dearer during the gap (tick fell): the floor is too high and buybacks only revert, which is safe.

If CLAUS got cheaper (tick rose): the floor is too low. The only remaining bound is the keeper's own quotedTick/maxTickDrift (<= 100 ticks, about 1%), so a sandwich of the keeper's transaction can take up to about 1% of a batch instead of 0.5%. A reset is required to set this up, so the planned first activation batch, which includes initializeBuybackOracle, is not affected.

Fix that keeps the policy: record the current ERC-1967 implementation address or an activation nonce in BuybackOracle.State at reset, and have record/meanTick treat a mismatch as count == 0. Alternatively, let initializeBuybackOracle also accept the ERC-1967 admin so the reset can be bundled through upgradeAndCall.

Merged from audit_flow and audit_economics. minimumBuybackOutput = 0.995 x amountIn x price(meanTick) has no term for the buyback's own price impact. The vault requires minBuyOutput >= that floor and passes minBuyOutput to the router as amountOutMinimum (line 2232), so any batch whose own impact exceeds about 0.5% always reverts.

Live chain 4663 (eth_call at block 0x67c27f3, PoolManager extsload of pool 0x51c9a331...e6a7) shows sqrtPriceX96 = 0x5d93c487091660c64314ab8eacf, tick 146234, liquidity 0x979f97c03cfd2286419 (4.475e22), which is about 29.9 ETH of virtual ETH reserve. The vault constructor argument initialMaxBatch = 5e17 is therefore not executable. No funds are lost: the revert is atomic and smaller batches work.

Effective throughput is capped by liquidity rather than maxBatch, and the keeper must size batches below about 0.15 ETH at current depth. Fix without changing policy: deploy or configure maxBatch at a size that clears the floor (about 0.1-0.15 ETH at current liquidity) and document that the cap must shrink as liquidity falls.

Merged from audit_flow (low), audit_math (info) and audit_economics (info).

Verified properties: same-timestamp writes only overwrite self.tick and carry zero weight (lines 1693-1696). The 601-slot ring at distinct timestamps always spans >= 600 s, so spam cannot evict history or force OracleNotReady. meanTick rounds toward +infinity, giving a stricter ETH->CLAUS floor, and every mulDiv rounds up. A keeper minimum below the oracle floor reverts at vault line 2220.

Limitations: (a) If CLAUS legitimately appreciates more than about 50 ticks against the 600 s mean, buybacks revert until the mean catches up. This only affects liveness. (b) The pool charges 2% on the ETH leg of every non-exempt swap and 0 LP fee, so deviations under about 2% are not arbitraged back.

Someone who holds the price displaced for the whole window lowers the floor by the displacement. Each buyback is still bounded by maxTickDrift <= 100 against the keeper's quote, and by the realistic batch of about 0.15 ETH (see the batch-size finding). The manipulator pays 2% per leg on volume large enough to move about 30 ETH of virtual reserve.

The flow specialist's per-buyback profit estimate rests on assumed exit prices and was not reproduced as profitable. This is reported as an honest limit of using the pool's own history, not as a defect. Tick quantisation of slot0 can also make the floor up to 1 tick (about 1 bp) more lenient than exactly 99.5% of spot.

Merged from audit_permissions, audit_flow, audit_economics and the audit_math fee-parameter note.

Live chain 4663 at block 0x67c27f3: administrator 0x979d...dc46 has owner 0xbb14...f1c5 and operator 0x8aca8890d34086d7a30b9c06fae25e0c3cda4cfa. managedTarget is true for the hook proxy 0x15bb...bfff, its ProxyAdmin 0xf2ea...4ac0 (owner = administrator), the old vault, the token proxy 0x1630...ffac, and the token ProxyAdmin 0xcbc4bbd337e62c926c995e66a231e5e2b0a722a8 (owner = administrator).

The hook implementation slot is the declared 0x23ef...3eb7, and hook.owner() is the administrator. execute() blocks only renounceOwnership, and transferOwnership for the operator.

The operator can therefore, with no delay, (1) upgrade the hook or the token to arbitrary code, which replaces the fee split, oracle floor, exemption authentication and advisor payment, or the burn/supply semantics the vault depends on; (2) call setFee, setLiquidityShare, setFeeRecipient, setLiquidityVault, setAdvisorEnabled and initializeBuybackOracle (a 600 s pause each call).

The 2% / 1% / 0.9% / 0.1% split therefore holds only while feePips == 20000 and liquiditySharePips == 500000. setFeeRecipient redirects already-accrued treasuryOwed, though not advisor.owed. (3) Once the new vault is registered, call recoverUnspentFees(any, amount) on it. This is the agreed ownership model, not a bypass.

The advisor (no privileged entry point) and the keeper (buyAndBurn only, floor-bound) receive none of these powers. Founder revocation (setOperator(0), setTarget(x,false)) cannot undo an upgrade or recovery that has already executed. The README does not mention that the token ProxyAdmin is a managed target.

Option: after activation, the founder calls setTarget(ProxyAdmin,false) for both ProxyAdmins, or puts a timelock in front of them.