Fee sharing hook on Robinhood Chain

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

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

What it does

This hook takes a return-delta fee on swaps and routes accumulated fees to a hub, referral and carry accounting, with the exact rate and which trades pay more or less not determinable from decoded bytecode.

How it works step by step

  • Proxy hook: all calls delegate to implementation 0x74efe2f95626c794a474ea5d10714bf33e8dee31, which is upgradeable through an initializer and proxy-style storage.
  • Uses return deltas on both beforeSwap and afterSwap, so it can take a share of swap input or output as a hook-level delta.
  • Tracks per-session data (tickers, ticks, timestamps, bool flags and amounts) in mappings keyed by session id, indicating a time-windowed mechanism with qualify and release periods.
  • Accrues carry amounts (addCarry) and collects or compounds fees for the hub and referral addresses.
  • Liquidity callbacks (afterAddLiquidity, afterRemoveLiquidity) update the same session accounting, and afterDonate also updates it.
  • Exposes a hub, referrals, market router and USDG token binding, indicating it is part of a larger protocol with a separate fee and referral routing layer.
Swap behaviour
beforeSwap and afterSwap are both active and return deltas are enabled, so the hook can adjust the amount a swap settles and take a portion of the swap as fees before and after execution; the exact split between traders and the hub cannot be determined from the decoded bytecode.
Liquidity behaviour
afterAddLiquidity and afterRemoveLiquidity update session and ticker storage; they do not return deltas, so they only record accounting rather than moving tokens directly.
Fee behaviour
Fees are taken through hook return deltas and routed to hub, referral and carry accounting via collectFees, compound and recentre; the exact rate and which trades pay more or less are not determinable from decoded bytecode, and the implementation's pool fee handling is not visible.
Owner & admin controls
Storage slot 0 and slot 2 hold addresses written by bindHub, bindMarketRouter, bindReferrals and initializeProxy, and the proxy upgrade path via slot 0x6c04... and the initializer guard (uint64 and bool at slot f0c5...) suggest an owner or admin who can rebind the hub, referrals and router and upgrade the implementation; the exact access control check cannot be confirmed from decoded bytecode.

Enabled Uniswap v4 callbacks

beforeInitialize, afterAddLiquidity, afterRemoveLiquidity, beforeSwap, afterSwap, afterDonate, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize validates pool setup and session creation; afterAddLiquidity and afterRemoveLiquidity record liquidity events; beforeSwap and afterSwap apply fee logic and return deltas; afterDonate records donation accounting; beforeSwapReturnDelta and afterSwapReturnDelta allow the hook to alter swap settlement amounts.

Security & trust assessment

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

Who controls it: A privileged key controlling the proxy upgrade path, hub, referrals or market router bindings could change how fees are computed, where they are sent, and which pools or sessions are accepted, with effect on all users of the pool.

Risk to user funds: The hook can take value from swaps through return deltas and can route accumulated fees to the hub and referral addresses; it can hold accrued carry balances, and an upgrade or rebind could redirect or lock those funds.

Security findings

  • [high] Upgradeable proxy: The hook delegates all calls to an implementation address and has initializer state (uint64 and bool in a fixed slot), so the implementation can be replaced by whoever controls the upgrade path, changing all swap and fee logic.
  • [high] Return deltas on swaps: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook can alter the amounts settled on every swap, meaning it can take tokens from traders or pools.
  • [medium] Rebindable external addresses: Functions bindHub, bindReferrals and bindMarketRouter write to storage addresses that the fee and swap logic depend on; a privileged caller that can rebind these could redirect fees to a different destination.
  • [info] Session-based time windows: Session timing (qualify and release durations, closeAt, nextSession) indicates time-gated behaviour that may restrict when fees or claims are possible; the exact rules are not determinable from bytecode.

Contract details

Verified source
No
Bytecode size
793 bytes
Upgradeable proxy
Yes
Detected patterns
erc20, fee-sharing, liquidity-management, return-delta, self-unlock, tax, upgradeable

Pools using Fee sharing hook