Liquidity management hook on Robinhood Chain

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

Volume (24h)
$0
Value locked (TVL)
$2.70
All-time volume
$0
Pools using this hook
3
Swaps (24h)
0 (0 traders)
Total swaps
0

What it does

This hook runs a managed liquidity vault with share tokens, an oracle, and an admin-set dynamic swap fee within fixed bounds, so all traders pay the current pool fee and LPs must deposit and withdraw through the hook.

How it works step by step

  • Manages pool liquidity itself: LPs deposit through the hook and receive share tokens (deployed by a share deployer) instead of adding liquidity directly to the pool.
  • Blocks direct add and remove liquidity calls on the pool, so liquidity flows only through the hook's own deposit and withdraw functions.
  • Uses a dynamic LP fee that an admin can set between hard-coded minimum and maximum values, plus a treasury fee share capped by a hard-coded maximum.
  • Records price observations on each swap, acting as a built-in price oracle.
  • Has an admin with two-step transfer, a treasury address setting, and a rescue function.
Swap behaviour
Before each swap the hook updates its oracle observations and pool state, and after the swap it updates internal accounting. It cannot take tokens from swaps via return deltas; traders pay the pool's dynamic LP fee.
Liquidity behaviour
Direct add and remove liquidity on the pool appear to be blocked by the hook, so LPs deposit and withdraw through the hook's own functions, which mint and burn share tokens. Withdrawal is done through the hook, and whether it can ever be restricted cannot be fully verified from bytecode.
Fee behaviour
Dynamic LP fee set per pool by the admin within hard-coded MIN_LP_FEE and MAX_LP_FEE bounds, whose exact values are not visible in the decoded data. A treasury share of fees, with a default and a hard-coded maximum, goes to the treasury address.
Owner & admin controls
The admin can set LP fees within the hard-coded min and max, set the treasury and factory addresses, transfer the admin role, and call rescue for tokens. The exact fee caps and the scope of rescue cannot be confirmed from bytecode.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeRemoveLiquidity, beforeSwap, afterSwap

beforeInitialize: sets up pool state and checks the pool config; beforeAddLiquidity: likely blocks direct deposits that bypass the hook; beforeRemoveLiquidity: likely blocks direct withdrawals that bypass the hook; beforeSwap: updates oracle observations and fee state; afterSwap: updates accounting after trades.

Security & trust assessment

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

Who controls it: A single admin, transferable in two steps, controls LP fees within fixed bounds, the treasury and factory addresses, and the rescue function.

Risk to user funds: The hook holds LP liquidity positions and cannot take swap tokens via deltas. Fee caps and rescue limits cannot be verified from unverified bytecode, and LP exit depends on the hook's own withdraw path.

Security findings

  • [medium] Liquidity custody through hook: LP positions are owned by the hook and represented by share tokens, and direct pool withdrawals appear to be blocked. LPs depend on the hook's withdraw logic to exit.
  • [medium] Admin rescue function: A rescue function exists that reads the share and pool mappings. Its limits on which tokens it can move are unverified.
  • [info] Bounded dynamic fee: Admin fee changes are checked against hard-coded MIN_LP_FEE and MAX_LP_FEE constants, and the treasury share against MAX_TREASURY_FEE_BPS.

Contract details

Verified source
No
Bytecode size
21,225 bytes
Upgradeable proxy
No
Detected patterns
dynamic-fee, erc20, moves-currency, self-unlock

Pools using Liquidity management hook