Liquidity management hook on Robinhood Chain

Uniswap v4 Hook Contract 0xbef9c77ec3c1a0d92c4cb6264f8923b37a63eae0 on Robinhood Chain · Liquidity management

Volume (24h)
$95.35K
Value locked (TVL)
$3.37K
All-time volume
$195.08K
Pools using this hook
1
Swaps (24h)
4,681 (91 traders)
Total swaps
8,844

What it does

A liquidity-management hook that seeds and manages protocol-owned liquidity for a Uniswap v4 pool, tracking walls, genesis positions and fee-token burns while observing swaps and liquidity changes.

How it works step by step

  • Seeds a genesis protocol-owned liquidity position between genesisLowerTick and genesisUpperTick via initializeGenesis and settleGenesis.
  • Tracks a moving anchorTick and referenceTick and updates wall and depth configuration (walls, weights, depthTicks, WALL_WIDTH_TICKS).
  • Collects fees into pendingFeeTokens and routes them toward a burn accounting flow (feeTokensForBurn, totalFeeTokensBurned).
  • Periodically poked (poke, nextPoke, POKE_INTERVAL) to advance state and rebalance.
  • Uses the PoolManager unlock/unlockCallback pattern to take and settle currency during its own operations.
  • Exposes view getters for pool state (spot, currentFeeBps, polDeposited, totalWallSpent, wallQuoteTotal).
Swap behaviour
beforeSwap and afterSwap are enabled; the hook updates anchor and reference tick state, applies a tracked fee (currentFeeBps), and may rebalance walls and protocol liquidity around each swap.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity are all enabled, indicating the hook observes and likely manages protocol-owned liquidity (polDeposited, baseLiquidity, walls, depthTicks, genesisMinted), including a genesis liquidity position with defined lower and upper ticks.
Fee behaviour
Fees are tracked internally via currentFeeBps, FEE_BPS, LP_FEE_PIPS, totalFees, pendingFeeTokens and feeTokensForBurn; the hook appears to collect fee tokens and route them to a burn/accounting flow (totalFeeTokensBurned, totalBurned), but the exact fee rate and split cannot be determined without source.
Owner & admin controls
No owner or admin selector was decoded (no owner(), setOwner, pause or upgrade functions found). Operational entry points are open: initializeGenesis(), poke(), flushPol(), harvest() and harvest(uint256) are nonpayable and appear callable by anyone, and their gating (if any) cannot be confirmed from bytecode alone.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeRemoveLiquidity, beforeSwap, afterSwap, beforeDonate

beforeInitialize sets up pool and anchor state; beforeAddLiquidity and beforeRemoveLiquidity gate or inspect liquidity changes; afterAddLiquidity and afterRemoveLiquidity record liquidity accounting; beforeSwap and afterSwap adjust fees, anchor/reference tick and wall state around each trade; beforeDonate and afterDonate are enabled and inspected but their specific use is unclear.

Security & trust assessment

Risk level: medium (decoded bytecode, low confidence).

Who controls it: Cannot be fully assessed without source. Several selectors suggest a self-driven state machine (poke, nextPoke, POKE_INTERVAL, unlockCallback) where the hook calls the PoolManager itself to move funds, so any privileged role over those functions or the funding flows (takeWallFunding, settleGenesis) would materially control pool liquidity.

Risk to user funds: The hook holds and moves protocol-owned liquidity and fee tokens via PoolManager take/settle and ERC-20 transfers, and beforeSwap/beforeAddLiquidity/beforeRemoveLiquidity hooks can influence whether and how swaps and liquidity changes execute. Without source, the exact conditions under which user funds could be blocked or misdirected cannot be confirmed.

Security findings

  • [high] Hook moves currency via self-unlock: The hook decodes and calls take, settle and unlock on the PoolManager (take(address,address,uint256), unlock(bytes), unlockCallback) and transfers ERC-20 tokens (transfer, balanceOf), so it can move pool and hook-held funds.
  • [medium] Multiple externally callable state-changing entry points: Multiple state-changing functions (initializeGenesis, poke, flushPol, harvest, harvest(uint256), settleGenesis, takeWallFunding) are nonpayable with no access-control selectors (owner, role checks) found in the dispatch table, so unauthorized callers may be able to trigger fund-moving or state-advancing actions; the exact guards require source to confirm.
  • [info] Explicit reentrancy and invariant guards present: Reentrancy-related and invariant custom errors (Reentered, InvariantViolation, Closed, TooSoon, PartialBuyFill, PartialSellFill) suggest the author implemented explicit guards and sanity checks, which is a positive signal but not proof of correctness.
  • [info] No admin or upgrade selectors found: No upgrade proxy, owner, pause or admin setter selectors were decoded, so this hook appears non-upgradeable and without an obvious admin kill switch, based on the dispatch table alone.

Contract details

Verified source
No
Bytecode size
24,051 bytes
Upgradeable proxy
No
Detected patterns
moves-currency, self-unlock

Pools using Liquidity management hook