Fee sharing hook on Robinhood Chain

Uniswap v4 Hook Contract 0xc578d7f3f310e52c4b51a71307f71448c4a75afc on Robinhood Chain · Fee sharing

Volume (24h)
$0
Value locked (TVL)
$1.76K
All-time volume
$0
Pools using this hook
1
Swaps (24h)
53 (27 traders)
Total swaps
53

What it does

A Uniswap v4 hook that appears to run a fee-sharing and oracle-tracking mechanism for registered pools, with swap and liquidity callbacks plus return-delta and claim-based currency accounting.

This read was written for the hook 0x69ed…9afc on Robinhood Chain and reused here: the two share a code shape, so constants such as fees, owners and addresses can differ.

How it works step by step

  • Registers pools and completes an opening phase tied to an oracle and a fixed opening sqrt price
  • Tracks oracle observations with cardinality growth and truncated observe queries
  • Gates liquidity additions and removals through position count and positions hash checks
  • Splits accrued fees into settled, pending, author and manager claims with treasury sweeps
  • Uses return-delta permissions and ERC-6909 mint and burn to settle currency during swaps and fee collection
Swap behaviour
beforeSwap and afterSwap are implemented, adjusting fees via swap-time logic, updating oracle observations, and using return deltas to route part of swap flows.
Liquidity behaviour
beforeAddLiquidity and beforeRemoveLiquidity are implemented and track positionCount and positionsHash per pool, with a liquidityLocker reference and expectedPositionCount, suggesting liquidity positions are monitored or restricted during pool opening.
Fee behaviour
Fees are not set by a static pool fee alone: the hook tracks settledFees, pendingFees, pendingTreasurySweeps and aggregateManagerClaims per pool and per recipient, uses an authorFeeBps constant and minimumHookFeePips, and calls checkpointFees and collectFees, indicating a fee split between authors, managers and treasury.
Owner & admin controls
Owner-style controls not directly decoded; the hook exposes registrar(), boundPoolId(), liquidityLocker(), oracleFactory(), core(), token() and deploymentConfigHash() as immutable or pure reads, and registerPool, completePoolOpening, collectFees, checkpointFees and increaseObservationCardinalityNext are state-changing entry points whose access restrictions could not be confirmed from bytecode alone.

Enabled Uniswap v4 callbacks

afterInitialize, beforeAddLiquidity, beforeRemoveLiquidity, beforeSwap, afterSwap, beforeDonate, afterDonate, beforeSwapReturnDelta, afterSwapReturnDelta

afterInitialize sets up oracle and pool state after pool creation; beforeAddLiquidity and beforeRemoveLiquidity gate or record liquidity changes; beforeSwap and afterSwap run swap-time fee and oracle logic; beforeDonate and afterDonate handle donation accounting; beforeSwapReturnDelta and afterSwapReturnDelta let the hook take or return currency deltas during swaps, which means it can move user or pool funds; afterDonate and afterSwap also write oracle observations.

Security & trust assessment

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

Who controls it: Not determinable with confidence from decoded bytecode; a privileged registrar or pool-opening role appears to control pool registration and opening, and a treasury role appears to control sweeps of pending fees.

Risk to user funds: The hook can hold and move pool and user currency through return deltas, take and mint or burn ERC-6909 claims, and it tracks pending and settled fee balances, so funds in the hook's custody could be affected by its logic or by privileged roles; the exact exposure cannot be fully determined without source.

Security findings

  • [medium] Return-delta swap permissions: The hook has both before and after swap return-delta permissions, so it can take or credit currency during swaps, which means fees or amounts can be diverted from the pool.
  • [medium] Self-unlock and currency movement: The bytecode contains an unlockCallback path and self-unlock and moves-currency tags, meaning the hook calls the pool manager unlock flow and transfers, minting or burning ERC-6909 claims on behalf of pools.
  • [medium] Unverified privileged entry points: Registration, pool opening and fee collection entry points exist and their caller restrictions were not confirmed from decoded bytecode.
  • [info] Unverified source: No verified source is available, so behaviour is inferred from selectors and storage access patterns and may be incomplete.

Contract details

Verified source
No
Bytecode size
24,043 bytes
Upgradeable proxy
No
Detected patterns
erc20, erc6909-claims, moves-currency, return-delta, self-unlock

Pools using Fee sharing hook