VolatilePairHook on Ethereum

Volume (24h)

$2.00M

Value locked (TVL)

$1.33M

All-time volume

$3.58M

Pools using this hook

1

Swaps (24h)

1,154 (402 traders)

Total swaps

2,553

What it does

A dynamic-fee hook for volatile token pairs that charges different swap fees depending on price movement within each block, so arbitrageurs who push the price pay more while the LP side is compensated.

How it works step by step

• Sets a per-pool resting spread split into an ask fee and a bid fee, which step with the price impact observed between blocks, capped by maxSkew and maxSkewStep.
• Charges a one-block temporary fee on the backrun side when the price moved beyond configured thresholds, to capture arbitrage profit for LPs.
• Applies a continuation fade to swaps that push the price further in the direction of the in-block displacement from the block open, capped by maxMidFade.
• Restricts pool creation through this hook to the POOL_INITIALIZER_ROLE and enforces dynamic fee and correct hook address on initialization.
• Exposes getFee view for quoting both directional fees and emits state update events when a new block's top-of-block state is persisted.

Swap behaviour

Before every swap the hook loads the pool's fee state, advances it on the first swap of a new block, computes a directional fee (backrun fee against the displacement from the block open, or a continuation fade in the same direction) and returns it with the override flag. Swap amounts and deltas are not altered.

Liquidity behaviour

No liquidity callbacks are used for fees; beforeAddLiquidity and afterAddLiquidity return their selectors without changing state or deltas. Liquidity removal and donation are not hooked, so exits cannot be blocked by this hook.

Fee behaviour

Each swap direction is charged a dynamic LP fee set via the override flag. Fees are a permanent per-block skew (ask/bid split of a resting spread that steps with price impact, capped by maxSkew) plus a one-block temporary backrun fee on the side opposite the price move, plus a continuation fade on the same side as the displacement from the block's opening price, all clamped to MAX_FEE_E6 (999998 pips). Fees are LP fees only; protocol fees are added by the pool on top.

Owner & admin controls

Proxy admin (DEFAULT_ADMIN_ROLE holder) can upgrade the implementation via upgradeToAndCall and grant or revoke all roles. CONFIG_MANAGER_ROLE can update any pool's fee configuration (spread, skew rate, caps, backrun and restore fractions and thresholds) at any time, which resets the pool's fee state. POOL_INITIALIZER_ROLE can create pools that use this hook.

Enabled Uniswap v4 callbacks

beforeInitialize, afterInitialize, beforeAddLiquidity, afterAddLiquidity, beforeSwap, afterSwap

beforeInitialize reverts direct PoolManager initialization so pools must go through initializePool. afterInitialize is enabled but never runs in practice. beforeAddLiquidity and afterAddLiquidity are inert defaults. beforeSwap computes and overrides the swap fee and persists top-of-block state on the first swap of each block. afterSwap is an inert default returning zero.

Security & trust assessment

Risk level: medium (verified source, high confidence).

Who controls it: A DEFAULT_ADMIN_ROLE holder can upgrade the implementation to arbitrary code that controls every pool using this hook, including swap fees, pool state and whatever the hook may hold. A CONFIG_MANAGER_ROLE holder can set fees within bounds (up to nearly 100% per side) for any initialized pool at any time, which can make swaps prohibitively expensive for traders. Roles are held by off-chain or multisig keys whose identities are not visible from the input.

Risk to user funds: The hook does not hold or transfer tokens and cannot block liquidity removal. However, an admin upgrade or a config manager fee change can make swaps on affected pools arbitrarily expensive or redirect hook logic, indirectly affecting trader and LP outcomes.

Security findings

• [high] Upgradeable proxy controlled by admin role: ERC1967 proxy with UUPS upgrade authorized only by DEFAULT_ADMIN_ROLE. Implementation can be replaced at any time, changing all hook logic for existing pools.
• [medium] Fee parameters can be changed unilaterally: CONFIG_MANAGER_ROLE can call updateFeeConfig or batchUpdateFeeConfig at any time. Bounds allow a resting spread up to about 2e6 and per-side fees up to MAX_FEE_E6, so a manager can raise fees to near 100% and effectively block swaps on any pool with this hook. Each update also resets the pool's fee state.
• [info] No timelock or governance delay evident: Hook delegates to an implementation whose code is not visible in the decoded bytecode beyond the verified source. Upgrade authority is not documented as timelocked or multisig-gated in the provided input.
• [info] No direct custody of funds: Hook takes no tokens and returns zero deltas on all callbacks (return-delta flags are off), so it cannot custody or directly move pool or user funds. Exposure is limited to fee manipulation and proxy upgrade risk.

Contract details

Verified source

Yes (VolatilePairHook)

Compiler

solc 0.8.26+commit.8a97fa7a

Bytecode size

135 bytes

Upgradeable proxy

Yes

Detected patterns

dynamic-fee, upgradeable

Pools using VolatilePairHook

• ETH / USDC (Dynamic fee) — 24h volume $2.00M, TVL $1.33M, 1,154 swaps today