LibJitKeep on Base

Uniswap v4 Hook Contract 0x4f573870eb41d219ea9ab42559f1207918f9f8c0 on Base · Liquidity management · Verified contract

Volume (24h)
$215
Value locked (TVL)
$275
All-time volume
$3.45K
Pools using this hook
19
Swaps (24h)
18 (1 traders)
Total swaps
228

What it does

This hook keeps protocol-owned liquidity around the vault's NAV so that trades fill against its band and backstop, with the issuer rail taking larger legs when its certified capacity and premium bounds allow; which trades pay more or less depends on the live NAV and the rail's measured premium, which the source computes at runtime.

How it works step by step

  • On first initialization and pool setup, the hook registers pool configuration and tracks a NAV-anchored band (navTick, tickLower, tickUpper) for protocol-owned liquidity.
  • On the first swap of each block, the hook runs vault upkeep via an external linked library: accrues interest, records third-party liquidations, and partially deleverages a position past LLTV or max leverage back toward the ripcord.
  • Before each swap, the hook may re-pin the band to the current vault NAV using zero-volume price moves, then routes eligible swap legs to the issuer (rail) when the issuer's certified capacity and premium bounds allow.
  • Protocol-owned liquidity is placed as a concentrated NAV band, a full-range backstop, and a one-sided spill position beyond the issuer's worst structural price.
  • Accrued LP fees on the resting positions are collected and forwarded to a fee router that funds buybacks, and share-denominated fees are converted to USDC with a slippage floor.
  • Before liquidity is added, the hook can adjust its positions, and deferred sell claims and fee claims are retired back into protocol float.
Swap behaviour
Swaps are routed through the hook's own resting band, backstop and spill liquidity, with the issuer rail filling any remainder when its certified capacity and premium bound allow. The first swap of each block also triggers vault upkeep, and a re-pin may run before a swap when the price has drifted outside the band. Trades inside the band fill at prices derived from the rail's measured premium, so which direction pays more depends on the current NAV and premium inputs.
Liquidity behaviour
beforeAddLiquidity is a gate that only permits liquidity changes through the hook's own resting positions; external liquidity additions are not the hook's core function. The hook keeps its own band and backstop positions, and liquidity is withdrawn into float during clear/re-pin operations.
Fee behaviour
The pool's LP fee is set via dynamic-fee mirroring into slot0 (lpFeePips); the rail charges railFeeBps on issuer legs. LP fee revenue from the hook's positions is collected and sent to a fee router, and liquidation fee shares are converted to USDC for buybacks.
Owner & admin controls
Owner can set band geometry and premium parameters (bounded to 2000 bps premiums, 500 bps band epsilon, 10000 bps backstop) and toggle a rail kill switch that disables the issuer leg while swaps continue on the pool. The implementation is behind an upgradeable proxy, so the implementation address can be changed by the proxy admin. Pool retirement and withdrawal functions exist with recipient selection by privileged roles.

Enabled Uniswap v4 callbacks

beforeInitialize, afterInitialize, beforeAddLiquidity, beforeSwap, afterSwap

beforeInitialize: records and validates pool configuration at pool creation. afterInitialize: completes pool setup and seeds the band state. beforeAddLiquidity: restricts liquidity additions to the hook's own positions. beforeSwap: runs vault upkeep, re-pins the band, and routes swap legs to the issuer rail. afterSwap: updates band and fee accounting after each swap.

Security & trust assessment

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

Who controls it: A proxy admin or owner key could upgrade the implementation to drain or redirect protocol float and LP principal, change band and premium parameters to move execution prices against traders, or disable the rail leg; these privileges are not described as timelocked in the provided source.

Risk to user funds: The hook can hold and move pool principal and LP fee balances via PoolManager settlements, and an upgrade or parameter change could block or reprice swaps and liquidity operations for users.

Security findings

  • [high] Upgradeable proxy controls all hook logic: The hook delegates every call to implementation 0xc0ff3590d8564d86c9ff5e77d0f790db19747c7a, so whoever controls the proxy admin can replace the entire swap, liquidity and fee logic, including what the hook does with pooled funds.
  • [high] Hook holds and moves protocol principal: The hook takes and settles token balances via PoolManager (take, settle, mint, burn), keeps usdgFloat and perpFloat principal, and can withdraw or retire band liquidity into float, so it directly custodies and moves pool and LP funds.
  • [medium] Owner can disable rail and reshape band: Owner-set parameters (premiums, band epsilon, backstop share, railOff) change where liquidity sits and whether the issuer leg fills, which can alter execution prices for traders and LP positions.
  • [medium] Swap path depends on external vault and rail calls: Swaps call into external vault, Morpho oracle and rail contracts in beforeSwap; an oracle outage or failed rail quote falls back to pool-only liquidity, and repeated failed upkeep sets backoff windows that can leave a position undeleveraged.
  • [info] Deliberately loose pin and swap accounting: Pin and sweep routines use zero-volume swaps and claim-based accounting (perpClaim, feeClaim, deferredClaim) to handle short physical balances, which adds complexity and relies on correct tracking across many code paths.

Contract details

Verified source
Yes (LibJitKeep)
Compiler
solc 0.8.26+commit.8a97fa7a
Bytecode size
24,281 bytes
Upgradeable proxy
Yes
Detected patterns
liquidity-management, mev-protection, upgradeable

Pools using LibJitKeep