The review context declares administrator = 0x979d5810d32292358639f25294472f01c95bdc46 but vaultConstructorArgs[0] = 0x8aca8890d34086d7a30b9c06fae25e0c3cda4cfa. Live chain 4663 state (eth_getCode / eth_call, block 0x67a32d6): 0x8aca... has no code (EOA, nonce 16) and is operator() of the ClausAdministrator contract at 0x979d..., whose owner() is the treasury/founder 0xbb145ca83272c3806d4ddc75ca1d5514789cf1c5.

The live old vault 0x6be6... has owner() == 0x979d..., so today the founder can revoke the operator (setOperator(0)) and, as administrator owner, call configure/recoverUnspentFees/transferOwnership on the vault through administrator.execute.

Deploying ClausBuybackVaultV2 with the declared args makes the operator EOA the sole Ownable2Step owner: recoverUnspentFees (any recipient, any amount), configure (keeper/maxBatch/enabled) and transferOwnership of the new vault are then controlled by a single hot key with no founder recovery, which is a regression from the baseline ownership model and contradicts the context's 'administrator' field and the README's claim that the vault is owned by the existing administration.

Fee custody exposed: every ETH pushed by claimLiquidityFees (50% of all 2% trading fees) sits in this vault until spent. The task's bound invariant 'constructor ownership and keeper rights' is therefore not met by the declared deployment inputs.

Fix (scope decision for the requester): pass 0x979d5810d32292358639f25294472f01c95bdc46 as the first constructor argument (and add the new vault as a managedTarget of the administrator), or explicitly re-declare the intended owner as 0x8aca... and accept the loss of founder recovery.

vaultConstructorArgs[2] in the review context is "0xac796f7ac40c0ce9cdc0dbe61d8bc7c98dc5cb5" (39 hex digits, not a valid 20-byte address). The live old vault 0x6be6... reports keeper() == 0xac796f7ac40c0ce9cdc0dbe61d8bc7c98dc5cbc5 (40 digits; nonce 0x318 and a funded balance, i.e. the active automation key). The declared string is missing one character and is not a truncation of the live value.

If the deployment tool left-pads it, the vault's keeper becomes 0x0ac796f7ac40c0ce9cdc0dbe61d8bc7c98dc5cb5, an address with nonce 0 and no code that nobody is known to control, so buyAndBurn can only ever be called by the owner and the 'original keeper' invariant the README asserts is false. If the tool rejects the string, deployment fails. Either way the declared constructor args do not reproduce the live keeper.

The constructor only checks nextKeeper != address(0), so the wrong value is accepted silently.

Fix: use 0xac796f7ac40c0ce9cdc0dbe61d8bc7c98dc5cbc5 (the live keeper) and verify keeper() after deployment.

The context binds runtimeHash 0x6cd4d064b20618060be82611ae8959bbe9ff13632380c6d79dcc576adb292b78 (hook) and 0x8477800a55ac2bcc949c1a388c14004cd91c0a7ddc1716d0ef42ed14dc064023 (vault) and artifact/build sha256 values to the entry files.

Rebuilding flatmin/MigrationFeeHookV2.sol and flatmin/ClausBuybackVaultV2.sol with solc 0.8.26, via_ir, optimizer 200 runs, evm cancun, ipfs bytecode hash gives deployedBytecode keccak 0x67e22526b08d9f741755b987fbced44521084f0a34b37fd77dbc02b57876cd59 (hook) and 0xd305cb6eca3f1a25fb7d54cae7e2de6956a93e50b88d35a49372c20babe400b1 (vault); metadata-stripped: 0x6257a5572e8b96d8554dc0e30ab4bd6d3316a1a5812753e73902a3d94b60543f and 0x3b65056c1699a35db35beb438ea136679f42d1b4102201dc4c19820dbd2a7ca9.

Neither the full nor the stripped hashes match the declared values, and the artifacts behind the declared sha256 values are not in the repository, so it cannot be determined whether the difference is metadata-only or a different source.

By contrast the baseline sources do reproduce the live code exactly: baseline/MigrationFeeHookOriginal.sol -> stripped 0x03ecadebbda28e0c9427bf95569cf9a3e0c477dad071ae1eb9e4dad4a9328dfb == live 0x23ef... stripped; baseline/ClausBuybackVault.sol -> stripped 0xdd18ec3899a64dc37d33e531b34006642fd05337ef9c9e75834db9a7d063f427 == live 0x6be6... stripped.

The code review below therefore covers the source as read; the binding between that source and the declared deployable artifact is unverified and the activation step should recompute and publish metadata-stripped runtime hashes for the artifacts it actually deploys.

Live (block 0x67a32d6): hook allocation() == (500000, 0x6be6888c5f8b4a8315eb379ef96d5eeb8e970dcd, 0x49a5ab217913 liquidityOwed, 0 treasuryOwed); the old vault has enabled() == true, balance 0, token balance 0, totalEthSpent 0x8dc80656653ba5b, totalTokensBurned 0xe4e38dd63b068786054d.

Verified properties: once the hook owner calls setLiquidityVault(newVault), the old vault's buyAndBurn reverts at this same check in the baseline (destination != old vault), so it is disabled even if its enabled flag stays true; its owner keeps recoverUnspentFees for any later dust; the hook's ERC-6909 ETH balance (0x49a5ab217913) equals liquidityOwed + treasuryOwed exactly, so no accrued fee is stranded.

Ordering note: if setLiquidityVault(newVault) is executed before the proxy is upgraded to MigrationFeeHookV2, the new vault's buyAndBurn reverts at hook.markBuyback() (selector absent in the old implementation) and buybacks pause until the upgrade, with no fund loss. No code change required; this is an activation checklist item.

Verified behaviour of the exemption (design, not a defect): markBuyback() is only callable by _allocation().vault while the manager is locked; _exempt requires the transient flag and zeroForOne; beforeSwap then returns a zero hook delta and afterSwap clears the flag and reverts PartialFill unless the swap is exact-input and the pool consumed exactly _specified(p) ETH, which makes a partial fill roll back the whole keeper transaction (the vault's require(burned >= minBuyOutput) and the router's amountOutMinimum are second and third guards).

Because the flag is written in a sub-frame of buyAndBurn, any revert of buyAndBurn also discards it, and there is no external call between markBuyback() and ROUTER.execute(), so no third-party swap can consume the exemption. Economic consequence to record as a trust/design assumption: under the baseline the buyback itself paid 2% (1% recycled to the vault, 1% to the treasury); under V2 the full amountIn is swapped and the treasury's 1% on buyback volume is gone.

Ordinary swaps are unchanged: fee = gross20000/1e6, lp = fee500000/1e6 to liquidityOwed (vault) and fee-lp to treasuryOwed, with the ERC-6909 mint equal to the sum, so no dust is lost and LP positions are never touched by the hook.

Verified live: hook proxy 0x15bb... is an OpenZeppelin v5 TransparentUpgradeableProxy (dispatch compares msg.sig to 0x278f7943<<1 == upgradeToAndCall) with immutable admin 0xf2ea... (ProxyAdmin v5, selector 0x9623609d upgradeAndCall) whose owner is the ClausAdministrator 0x979d...; managedTarget is true for the hook, the ProxyAdmin and the old vault, and ClausAdministrator.execute may be called by owner or operator with any selector except renounce/transferOwnership.

Therefore the operator key 0x8aca... alone can (a) upgrade the hook implementation, (b) call setLiquidityVault to hand markBuyback/fee-exempt authority to any contract, (c) call setFee / setFeeRecipient / setLiquidityShare, and (d) drain the old vault via recoverUnspentFees. The hook owner is the administrator, pendingOwner is zero, feePips == 20000, feeRecipient == 0xbb14... (treasury EOA), liquiditySharePips == 500000.

The CLAUS token 0x1630... is itself an ERC-1967 proxy (impl 0xd687...) with owner() == 0x979d..., so burn()/balanceOf semantics the vault relies on are upgradeable by the same administration. The router 0x204F... is an immutable UniversalRouter (no proxy slot, poolManager() == 0x8366...); its source was not available, but 0x8dc80656653ba5b wei of prior buybacks through the identical call path show the encoding executes.

These are intended powers, documented here as trust assumptions, not permission bypasses; storage of the V2 hook is unchanged (all state in ERC-7201/keccak namespaces, the new EXEMPT_SLOT is transient only), so the upgrade is storage-compatible.

The review context declares administrator 0x979d5810d32292358639f25294472f01c95bdc46 but vaultConstructorArgs[0] is 0x8aca8890d34086d7a30b9c06fae25e0c3cda4cfa. Live reads on chain 4663 (public RPC for Robinhood chain; block 0x67a256e): old vault 0x6be6...0dcd owner() = 0x979d..., hook proxy owner() = 0x979d..., ProxyAdmin 0xf2ea... owner() = 0x979d..., token owner() = 0x979d....

0x979d... is the ClausAdministrator contract (baseline/ClausAdministrator.sol, bytecode matched live): owner = 0xbb145ca8... (founder/treasury), operator = 0x8aca..., and its execute() deliberately blocks the operator from calling transferOwnership/renounceOwnership on managed targets so the founder keeps a recovery path.

Deploying ClausBuybackVaultV2 with the declared args makes the operator EOA the direct Ownable2Step owner: it gains transferOwnership/renounceOwnership, configure() and recoverUnspentFees() (which can send the vault's entire ETH balance anywhere) with no founder override, and the hook's liquidity share (50% of all 2% trading fees) would be redirected to a vault outside the governed administrator.

A compromise of the single operator key then yields permanent, unrecoverable control of the buyback vault and all fees it accrues, whereas today the founder can rotate the operator via ClausAdministrator.setOperator and keep the old vault. This contradicts the declared administrator and the 'constructor ownership' requirement; if the design intent really is EOA ownership it must be stated and accepted explicitly.

Live state (block 0x67a256e): hookProxy implementation slot = 0x23efc76d... (baseline MigrationFeeHookOriginal, runtime matched after metadata strip), allocation() = (500000, vault=0x6be6888c... old vault, liquidityOwed=0x49a5ab217913 wei, treasuryOwed=0), oldVault.enabled() == true, oldVault.totalEthSpent = 0x8dc80656653ba5b, 51 BuybackBurned events in the last 200k blocks. The context's claim of a 'disabled old vault' is not yet true.

The new vault's buyAndBurn calls markBuyback(), a selector the live implementation does not have, so if setLiquidityVault(newVault) is executed before ProxyAdmin.upgradeAndCall, every buyback reverts (old vault fails 'Fee destination changed', new vault fails with the proxy's empty revert) and the 50% liquidity share accrues unclaimable until the upgrade lands.

Conversely, upgrading first and leaving the old vault as allocation vault keeps the old vault working (it simply pays the 2% fee).

Required sequence: (1) upgrade hook via ClausAdministrator -> ProxyAdmin(0xf2ea...).upgradeAndCall, (2) setLiquidityVault(newVault) (redirects the 0x49a5ab217913 wei already owed), (3) oldVault.configure(keeper, maxBatch, false). The old vault holds 0 ETH and 0 CLAUS, so nothing needs recovery there.

Verified: baseline/MigrationFeeHookOriginal.sol and baseline/ClausBuybackVault.sol compiled with solc 0.8.26, cancun, viaIR, 200 runs produce runtime bytecode byte-identical to the live code at 0x23efc76d... and 0x6be6888c... after removing the CBOR metadata trailer; live keccak of 0x979d58... equals the declared administratorRuntimeHash.

Not verified: the context's component runtimeHash values (hook 0x6cd4d064..., vault 0x8477800a...) and artifactHash values. Compiling the two entry files with the declared settings yields keccak 0x42134852... / 0x9982c646... / 0xc6c816fa... for the hook depending on source path and remappings embedded in metadata, none equal to the declared value, and no artifact is in the tree to compare metadata-stripped.

The declared hashes therefore remain an unverified assertion; the deployer must compare metadata-stripped runtime of the artifact actually deployed against a fresh build of this snapshot (sha256 of flatmin/MigrationFeeHookV2.sol = 51128fd4..., flatmin/ClausBuybackVaultV2.sol = c98e2735...).

Storage layout compatibility is verified: V2 declares no storage variables (layout empty, same as the live implementation) and uses the same namespaced slots (test.hook.settings.v1, claus.migration.fee-allocation.v1, OZ ERC-7201 Ownable/Ownable2Step/Initializable); the only new state is the transient EXEMPT_SLOT.

Live dependency facts (chain 4663, block 0x67a256e): hook proxy admin = ProxyAdmin 0xf2ea... owned by ClausAdministrator 0x979d...; ClausAdministrator.managedTarget() is true for hookAdmin, hookProxy, oldVault, token and the token's ProxyAdmin 0xcbc4..., and execute() only blocks transferOwnership/renounceOwnership.

Hence the operator EOA 0x8aca... alone can call upgradeAndCall on both proxies, setFee/setLiquidityShare/setFeeRecipient/setLiquidityVault on the hook, and recoverUnspentFees on the vault. CLAUS (0x1630...) is a TransparentUpgradeableProxy (implementation 0xd68727dd...); the vault relies on burn() reducing totalSupply exactly and transfer having no fee (lines 236-240 revert otherwise).

Router 0x204FAca1... is a Universal Router fork (ExactInputSingleParams carries an extra minHopPriceX36 field); its command/action encoding (0x10; 06 SWAP_EXACT_IN_SINGLE, 0c SETTLE_ALL(native, amountIn), 0e TAKE(token, vault, OPEN_DELTA)) is unchanged from the baseline vault and is evidenced by 51 successful BuybackBurned events, but its source was not available for review.

Pool slot0 shows protocolFee = 0 and lpFee = 0 (hook override 0x400000), liquidity 0x979f97c03cfd2286419; manager owner 0x2bad... and protocolFeeController 0x6d00... could introduce a protocol fee (max 0.1%) which would reduce buyback output but not break the exact-input PartialFill checks. These are powers by design, not defects; they bound the guarantees of this review.

Verified with a mock-manager Foundry harness (7 tests, all pass) and by reading PoolManager/Hooks semantics: user swaps still pay feePips 20000 (2%) on the ETH leg (gross on exact-input ETH, net-grossed-up on exact-output ETH), afterSwap mints exactly fee as ERC-6909 to the hook and credits liquidityOwed += fee*500000/1e6 and treasuryOwed += fee - that, so MANAGER.balanceOf(hook,0) == liquidityOwed + treasuryOwed (holds live: both 0x49a5ab217913).

Claims burn exactly the owed amount and take native to the vault/recipient. The exempt path requires msg.sender == allocation().vault and manager locked, applies only to the next zeroForOne exact-input swap in the same transaction, enforces nativeAmount == amountSpecified (full expenditure; partial fill reverts the whole buyback), clears the flag in afterSwap, and does not apply to sells or exact-output buys.

LP principal is never touched (all liquidity callbacks return zero deltas). Economic consequence to confirm with the requester: previously each buyback of X ETH paid 0.02X fee of which 0.01X went to treasury and 0.01X back to the vault; after the upgrade the treasury receives nothing from buyback volume (historical buyback volume 0.6385 ETH => about 0.0064 ETH less to treasury at that scale) and 100% of the batch is spent on burn.

This matches the stated design but is a change to the treasury's realised income, not just an efficiency gain.

The review context binds each component to a runtimeHash (hook 0x6cd4d064...292b78, vault 0x8477800a...064023) and artifact/build ids. Compiling the two entry files with the declared settings (solc 0.8.26, viaIR, optimizer 200 runs, evm cancun, ipfs metadata) does not produce those hashes, neither for the full runtime nor for the runtime with the CBOR metadata trailer stripped.

The same toolchain and settings reproduce the live baseline exactly (baseline/MigrationFeeHookOriginal.sol -> stripped keccak 0x03ecadeb...8dfb == code at 0x23efc76d...3eb7 stripped; baseline/ClausBuybackVault.sol -> 0xdd18ec38...f427 == code at 0x6be6888c...0dcd stripped), so the settings are right and the gap is in the V2 evidence. Compiling without viaIR fails with stack-too-deep, so no other declared-compatible setting exists.

Consequently the artifact that would be deployed/upgraded to cannot be tied to the reviewed source; the sourceHash sha256:ab2355c0... also matches neither entry file (sha256 51128fd4... hook, c98e2735... vault), their concatenation, nor a tar of flatmin/. This is a blocking evidence gap for activation, not a code defect: the approval marker must not be issued until the artifact hashes are regenerated from exactly these sources and re-declared.

The review context names administrator 0x979d5810d32292358639f25294472f01c95bdc46 (ClausAdministrator) and says the new vault is owned by the existing execution wallet, but vaultConstructorArgs[0] is 0x8aca8890d34086d7a30b9c06fae25e0c3cda4cfa. On chain 4663 that address is an EOA (no code, nonce 16) and is the operator of ClausAdministrator 0x979d..., whose owner is the treasury/founder 0xbb145ca8....

The live hook proxy owner, the ProxyAdmin 0xf2eaa097... owner, the CLAUS token proxy owner and the old vault owner are all 0x979d... . ClausAdministrator.execute blocks renounceOwnership and lets only the founder call transferOwnership on managed targets, giving founder recovery over every component.

Deploying the V2 vault with 0x8aca... as owner removes that layer for the new vault only: a single hot key can call configure(), recoverUnspentFees(anyone, fullBalance), buyAndBurn(), transferOwnership(), and renounceOwnership() (not blocked in ClausBuybackVaultV2), and the founder cannot recover unspent buyback ETH or re-point automation if that key is lost or compromised.

Because the hook will push 50% of all trading fees (liquidityOwed) to this vault permissionlessly, all future buyback ETH sits under the weaker owner.

Fix: pass 0x979d5810d32292358639f25294472f01c95bdc46 as administrator, and register the new vault as a managedTarget in ClausAdministrator after deployment (setTarget requires code, so it must follow the deploy). If owning it from the operator EOA is intended, the context and README must say so and the trust model must be re-approved.

Trust-gap (access x economics), unchanged from the live baseline vault. The drift guard compares the pool tick with p.quotedTick, and the slippage guard uses p.minBuyOutput, both chosen by the caller; the quoteBlock/quoteBlockHash anchor only proves recency, not that quotedTick was observed at that block.

There is no cooldown, nonce or per-period budget, so maxBatch (0.5 ETH) does not cap exposure: the keeper can loop buyAndBurn with amountIn=maxBatch until the balance is exhausted in one block. A compromised or malicious keeper (hot automation key 0xAc79...CBc5) can therefore spend all accrued buyback ETH at an arbitrary price and capture it with a sandwiching account; the only on-chain protections are PartialFill atomicity and burned>=minBuyOutput, which it sets to 1.

Reported as a documented trust assumption on the keeper, not a permission bypass: owner can disable via configure(). Minimal hardening that keeps the design: enforce a minimum minBuyOutput derived from the current sqrtPriceX96 (e.g. >= 99% of the spot quote for amountIn) and/or a per-block or per-interval spend limit.

markBuyback() is authenticated only by equality with _allocation().vault, which setLiquidityVault(address) (onlyOwner outsideSwap, any address with code) sets.

V2 therefore adds a new owner power: whatever contract is set as the liquidity vault can mark and then perform fee-free zeroForOne exact-input swaps of any size in the same transaction (beforeSwap charges 0, afterSwap only enforces exactInput and full fill), bypassing the 2% fee, and it also receives the 50% liquidityOwed share.

Live, the hook owner is 0x979d... whose execute() is callable by founder 0xbb14... or operator 0x8aca...; the same path can setFee up to 999,999 pips, setFeeRecipient (moving already-accrued treasuryOwed to the new recipient), setLiquidityShare 0..100%, and upgrade the proxy through ProxyAdmin 0xf2eaa097... (v5.0.0, owner 0x979d...).

The CLAUS token 0x1630... is itself an ERC1967 proxy (impl 0xd68727dd..., admin 0xcbc4bbd3...) owned by 0x979d..., so burn()/totalSupply semantics are also owner-upgradeable.

These are intended privileges, documented here so the exemption's blast radius is explicit; no unprivileged amplifier was found: setLiquidityVault/markBuyback are outsideSwap, the flag is transient and cleared by the first exempt afterSwap, and with the real vault the only caller of markBuyback is buyAndBurn immediately before its own swap.

Live state at block 108670970: proxy 0x15bb... implementation slot = 0x23efc76d... (baseline, no markBuyback selector), admin slot = 0xf2eaa097..., allocation() = (500000, oldVault 0x6be6888c..., liquidityOwed 80975889529107 wei, treasuryOwed 0), feePips 20000, feeRecipient 0xbb145ca8... (EOA), launched true, poolId 0x51c9a331... which equals keccak256(abi.encode(key)) for the declared constructor key (ETH, CLAUS, 0x800000, 60, proxy); slot0 shows lpFee 0 and protocolFee 0.

Old vault: owner 0x979d..., keeper 0xAc79...CBc5, maxBatch 5e17, enabled, balance 0, totalEthSpent 638526420176583259, totalTokensBurned 1080897189420314770408781.

Sequencing consequences: (1) until the proxy is upgraded, newVault.buyAndBurn reverts inside hook.markBuyback() (selector absent in 0x23ef...); (2) until setLiquidityVault(newVault), buyAndBurn reverts 'Fee destination changed' and markBuyback reverts InvalidCaller; (3) after setLiquidityVault, oldVault.buyAndBurn reverts 'Fee destination changed' permanently (disabled as required), the pending 80975889529107 wei is redirected to the new vault on its first claim, and any ETH later stranded in the old vault remains recoverable by its owner via recoverUnspentFees.

Storage compatibility verified: V2 adds no storage variables (both contracts have an empty storage layout except the vault's own slots, which are identical to the live baseline layout in review-context.json); Settings and Allocation structs and their namespaced slots are byte-identical to the baseline; the only new slot is the transient EXEMPT_SLOT. V2 constructor has _disableInitializers(); initialize() on the proxy is blocked (initialized==1 with code present).

ROUTER 0x204FAca1... answers poolManager() == 0x8366a39C... and V4_POSITION_MANAGER() == 0x58daec31..., consistent with a Uniswap UniversalRouter v2, and the old vault has completed buybacks with the identical command/action encoding (0x10 / 06 0c 0e, ExactInputSingleParams with the extra minHopPriceX36 field), so the encoding is accepted live; but the router's source was not available, so SETTLE_ALL/TAKE semantics (no ETH left in the router, OPEN_DELTA take to the vault) are inferred from the public UniversalRouter implementation and the live history, not read.

CLAUS 0x1630... is a 720-byte ERC1967 proxy; its implementation 0xd68727dd... was not reviewed, so burn() reducing totalSupply, absence of transfer hooks and absence of fee-on-transfer are assumptions. The vault's post-burn check (balance restored and totalSupply + burned == supplyBefore) converts a violated assumption into a revert, not a loss.

CLOCK = address(100) (ArbSys) is assumed to exist on this Arbitrum-Orbit chain; arbBlockHash reverts for blocks older than 256, within the 128-block window used. The fee-split arithmetic (fee*500000/1e6 to buyback, remainder to treasury) and the 20000-pip rate were verified unchanged against the live hook settings.

The review context names administrator 0x979d5810d32292358639f25294472f01c95bdc46 but vaultConstructorArgs[0] is 0x8aca8890d34086d7a30b9c06fae25e0c3cda4cfa.

Verified live on chain 4663 (block 0x67a6aab, Robinhood public RPC): eth_getCode(0x8aca...) == 0x (EOA, nonce 0x10); ClausAdministrator(0x979d...).operator() == 0x8aca...; ClausAdministrator.owner() == 0xbb145ca83272c3806d4ddc75ca1d5514789cf1c5 (treasury/founder); old vault 0x6be6...0dcd owner() == 0x979d...; hook proxy owner() == 0x979d...; ProxyAdmin 0xf2ea... owner() == 0x979d...; CLAUS token owner() == 0x979d...; managedTarget() is true for hook proxy, ProxyAdmin, old vault and token. baseline/ClausAdministrator.sol lines 405, 431-432: renounceOwnership reverts CannotRenounce and execute() blocks renounceOwnership on managed targets and allows transferOwnership only from the founder, so today the founder can rotate the operator (setOperator) and recover every component.

Deploying ClausBuybackVaultV2 with the declared args makes the operator hot key the direct Ownable2Step owner (line 181 passes the first constructor argument straight to Ownable).

That key alone then controls configure() (keeper/maxBatch/enabled), recoverUnspentFees(anyRecipient, anyAmount) over all ETH the hook pushes to the vault (50% of every 2% trading fee, pushed permissionlessly by claimLiquidityFees), transferOwnership() and renounceOwnership(), with no founder override.

This contradicts the context's 'administrator' field and is a weaker custody model than the live vault's; the bound invariant 'constructor ownership' is not met by the declared inputs. The README's 'owned by the existing execution wallet' wording suggests it may be intended; if so the context must say so and the trust change must be accepted explicitly.

Fix (requester scope decision): pass 0x979d5810d32292358639f25294472f01c95bdc46 as the first constructor argument and register the new vault via ClausAdministrator.setTarget after deployment (setTarget requires code), or re-declare the intended owner as 0x8aca... and accept the loss of founder recovery. Merged from audit_flow, audit_math, audit_economics and audit_permissions.

vaultConstructorArgs[2] in the review context is "0xac796f7ac40c0ce9cdc0dbe61d8bc7c98dc5cb5": 39 hex digits (verified with wc -c), not a valid 20-byte address; cast abi-encode rejects it ('parser error'). The live keeper of the old vault is 0xac796f7ac40c0ce9cdc0dbe61d8bc7c98dc5cbc5 (oldVault.keeper() via eth_call; 40 digits, nonce 0x31e, i.e. the active automation key). The declared string is missing a 'c' before the final 'b5', so it is not a truncation of the live value.

If the deployment tool rejects it, deployment fails; if it left-pads it, the keeper becomes 0x0ac796f7ac40c0ce9cdc0dbe61d8bc7c98dc5cb5 (nonce 0, no code, nobody known to control it). _configure (line 197) only requires a non-zero keeper and non-zero maxBatch, so the wrong value is accepted silently and the vault deploys enabled with a keeper that cannot act; buyAndBurn (line 209) reverts 'Keeper only' for the real automation key and only the owner can trigger buybacks until configure() is called.

No funds are lost, but the bound invariant 'keeper rights' (README: 'with the original keeper') cannot be confirmed from the declared context.

Fix: correct the argument to 0xAc796F7ac40c0CE9cdc0Dbe61d8bc7C98dC5CBc5 and have deployment assert newVault.keeper() == oldVault.keeper(). Merged from audit_flow, audit_math, audit_economics and audit_permissions.

The context binds the hook to runtimeHash 0x6cd4d064b20618060be82611ae8959bbe9ff13632380c6d79dcc576adb292b78 and the vault to 0x8477800a55ac2bcc949c1a388c14004cd91c0a7ddc1716d0ef42ed14dc064023, plus artifactHash/buildId sha256 values and sourceHash sha256:ab2355c0....

Rebuilding the two entry files with the declared settings (solc 0.8.26, via_ir, optimizer 200 runs, evm cancun, ipfs bytecode hash) yields keccak256(deployedBytecode) 0x67e22526b08d9f741755b987fbced44521084f0a34b37fd77dbc02b57876cd59 (hook) and 0xd305cb6eca3f1a25fb7d54cae7e2de6956a93e50b88d35a49372c20babe400b1 (vault); with the CBOR metadata trailer stripped: 0x6257a5572e8b96d8554dc0e30ab4bd6d3316a1a5812753e73902a3d94b60543f and 0x3b65056c1699a35db35beb438ea136679f42d1b4102201dc4c19820dbd2a7ca9.

None equals a declared value. The toolchain is correct: the same settings on baseline/MigrationFeeHookOriginal.sol and baseline/ClausBuybackVault.sol give stripped runtimes 0x03ecadeb...8dfb and 0xdd18ec38...f427 that are byte-identical to the live code at 0x23efc76d... and 0x6be6888c... after stripping, and the live full hashes equal review-context.json's liveRuntimeHash values.

The sourceHash also matches neither entry file (sha256 51128fd4... hook, c98e2735... vault), their concatenation in either order, nor a deterministic tar of flatmin/. The artifacts behind artifactHash/buildId are not in the tree, so it cannot be determined whether the gap is metadata-only or a different source. Code review covers the source as read; the binding between that source and the declared deployable artifact is unverified.

This is a blocking evidence gap for activation, not a code defect: the approval marker cannot be issued until the hashes are regenerated from exactly these sources (preferably metadata-stripped runtime hashes) and re-declared. Merged from audit_flow, audit_economics and audit_permissions.

Live state (chain 4663, block 0x67a6aab): hook proxy 0x15bb... implementation slot = 0x23efc76d... (baseline, no markBuyback selector), admin slot = 0xf2eaa097...; allocation() == (500000, vault = 0x6be6888c... old vault, liquidityOwed = 0x4f1876c3e98 wei, treasuryOwed = 0); feePips 20000; old vault enabled() == true, maxBatch 0.5 ETH, balance 0, totalEthSpent 0x8f4d01a7b6ff2f2, totalTokensBurned 0xe7d6c0395493aea6cf81.

Nothing in the V2 sources disables the old vault, so 'disabled old vault' is an unmet activation precondition, not a verified property.

Sequencing consequences verified against the code: (1) while the proxy still runs 0x23ef..., newVault.buyAndBurn reverts inside hook.markBuyback() (line 234; selector absent, no fallback); (2) until setLiquidityVault(newVault), buyAndBurn reverts 'Fee destination changed' (line 222) and markBuyback reverts InvalidCaller; (3) if setLiquidityVault(newVault) is executed before the upgrade, both vaults are dead (old: 'Fee destination changed'; new: markBuyback revert) and the liquidity share accrues unclaimable until the upgrade lands, with no fund loss; (4) after setLiquidityVault, the old vault's buyAndBurn reverts permanently at its own destination check, so it is disabled regardless of its enabled flag, and its owner keeps recoverUnspentFees for later dust; the pending liquidityOwed is redirected to the new vault on the first claim.

The hook's ERC-6909 ETH balance (0x4f1876c3e98) equals liquidityOwed + treasuryOwed exactly, so no accrued fee is stranded.

Required order: upgrade via ClausAdministrator -> ProxyAdmin(0xf2ea...).upgradeAndCall, then setLiquidityVault(newVault), then oldVault.configure(keeper, maxBatch, false). Merged from audit_flow, audit_math, audit_economics and audit_permissions.

The drift guard compares the pool tick with p.quotedTick and the slippage guard uses p.minBuyOutput, both chosen by the caller; the quoteBlock/quoteBlockHash anchor (lines 212-214) only proves the plan is at most 128 blocks old, not that quotedTick was observed. There is no cooldown, nonce or per-period budget, so maxBatch (0.5 ETH) does not cap exposure: buyAndBurn can be called repeatedly in one block with amountIn = maxBatch until the balance is exhausted.

A compromised or malicious keeper (hot automation key 0xAc79...CBc5) can therefore spend all accrued buyback ETH at a manipulated price and capture the difference by sandwiching; the only on-chain protections are PartialFill atomicity and burned >= minBuyOutput, which the keeper sets to 1. Unchanged from baseline/ClausBuybackVault.sol and reported as a documented trust assumption on the keeper role, not a permission bypass: the owner can disable automation via configure().

Minimal hardening that keeps the design: derive a floor for minBuyOutput from the current sqrtPriceX96 (e.g. >= 99% of the spot quote for amountIn) and/or add a per-block or per-interval spend limit. From audit_permissions.

Verified by reading the diff against baseline/MigrationFeeHookOriginal.sol (the only changes are the EXEMPT_SLOT flag, markBuyback(), _exempt() and the two exempt branches in beforeSwap/afterSwap; the vault diff adds only hook.markBuyback() at line 234) and by a judge-run mock-manager Foundry harness (hook behind a minimal proxy, mock manager etched at 0x8366a39C..., driver contract calling markBuyback then beforeSwap/afterSwap in one call; 7 tests pass: exempt full fill charges 0 and clears the flag, exempt partial fill reverts PartialFill, exempt swap presenting the non-exempt 0.98e18 delta reverts PartialFill, exempt exact-output reverts PartialFill, a sell after mark still pays 2%, unmarked swap splits 0.02e18 into 0.01e18/0.01e18 with ERC-6909 mint equal to the sum, and a reverted marked call leaves no flag behind; markBuyback reverts InvalidCaller for non-vault callers and while the manager is unlocked): markBuyback() (line 761) is callable only by _allocation().vault while the manager is locked and sets a transient flag; _exempt requires the flag and zeroForOne; beforeSwap then charges 0 (line 827-831) and afterSwap clears the flag (line 843) and reverts PartialFill unless the swap is exact-input and the pool consumed exactly _specified(p) ETH (line 845), so a partial fill rolls back the whole keeper transaction; the vault's require(burned >= minBuyOutput) and the router's amountOutMinimum are second and third guards.

The flag is written in a sub-frame of buyAndBurn, so any revert of buyAndBurn discards it, and no external call sits between markBuyback() (vault line 234) and ROUTER.execute() (line 235), so no third-party swap can consume the exemption; exact-output or oneForZero swaps are never exempt.

Ordinary swaps are unchanged: fee = gross20000/1e6, lp = fee500000/1e6 to liquidityOwed, fee-lp to treasuryOwed, ERC-6909 mint equals the sum (live: MANAGER.balanceOf(hook,0) == liquidityOwed + treasuryOwed == 0x4f1876c3e98), no dust lost; all liquidity callbacks return zero deltas so LP principal is never touched.

Economic consequence to confirm with the requester: under the baseline each buyback of X ETH paid 0.02X fee (0.01X to treasury, 0.01X recycled to the vault); under V2 the full amountIn is swapped and the treasury receives nothing from buyback volume.

Storage compatibility verified: V2 adds no storage variables, Settings/Allocation structs and their namespaced slots are byte-identical to the baseline, the only new state is the transient EXEMPT_SLOT, and the constructor keeps _disableInitializers(). Merged from audit_flow and audit_economics.

markBuyback() is authenticated only by equality with _allocation().vault, which setLiquidityVault(address) (onlyOwner outsideSwap, any address with code, line 881) sets. V2 therefore adds a new owner power: whatever contract is set as the liquidity vault can mark and then perform fee-free zeroForOne exact-input swaps of any size in the same transaction, and it also receives the 50% liquidityOwed share.

Verified live: hook proxy owner is ClausAdministrator 0x979d..., whose execute() is callable by founder 0xbb14... or operator 0x8aca... for any selector except renounce/transferOwnership on managed targets; managedTarget is true for the hook proxy, ProxyAdmin 0xf2ea... (owner 0x979d...), old vault and the CLAUS token 0x1630... (an ERC-1967 proxy, implementation 0xd68727dd..., owner 0x979d...).

So the operator EOA alone can upgrade the hook implementation, call setLiquidityVault/setFee (up to 999,999 pips)/setFeeRecipient/setLiquidityShare, upgrade the token whose burn()/totalSupply semantics the vault relies on, and drain the old vault via recoverUnspentFees.

These are intended privileges documented as trust assumptions, not permission bypasses; no unprivileged amplifier was found (setLiquidityVault and markBuyback are outsideSwap, the flag is transient and cleared by the first exempt afterSwap). Merged from audit_flow, audit_economics and audit_permissions.

ROUTER 0x204FAca1... answers poolManager() == 0x8366a39C... (the vault's MANAGER) and has about 24 KB of code, consistent with a Uniswap UniversalRouter fork, but its source is not available, so SETTLE_ALL/TAKE semantics (no ETH left in the router, OPEN_DELTA take to the vault) are inferred from the public implementation and from the live history: the old vault executed the identical command/action encoding (0x10 / 06 0c 0e) for totalEthSpent 0x8f4d01a7b6ff2f2 wei.

The vault's IV4Router.ExactInputSingleParams carries a sixth field minHopPriceX36 that the upstream v4-periphery struct lacks; against a standard V4Router the zero value happens to decode as an empty hookData, so the encoding is tied to this specific router and any non-zero minHopPriceX36 would mis-decode.

CLAUS 0x1630... is an ERC-1967 proxy whose implementation 0xd68727dd... was not reviewed; burn() reducing totalSupply, absence of transfer hooks and fee-on-transfer are assumptions that the vault's post-burn check (lines 239-240) converts into a revert rather than a loss. CLOCK = address(100) (ArbSys) is assumed to exist on this Arbitrum-Orbit chain; arbBlockHash reverts for blocks older than 256, within the 128-block window used. No Slither run (not installed).

Merged from audit_flow and audit_permissions.