Fee sharing hook on Robinhood Chain

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

Volume (24h)
$0
Value locked (TVL)
$24.76K
All-time volume
$0
Pools using this hook
1
Swaps (24h)
64 (45 traders)
Total swaps
2,171

What it does

A Uniswap v4 hook that takes a configurable fee on swaps in its pool and accrues it for a treasury and fee recipient.

How it works step by step

  • Validates pool initialization through beforeInitialize
  • Reads configured fee values from storage on each swap
  • Takes a fee through beforeSwap and afterSwap return deltas
  • Accumulates pending fees in contract balances
  • Routes a treasury share and collects accrued fees to the fee recipient when the threshold is met
Swap behaviour
beforeSwap and afterSwap run on every swap, reading fee settings, taking a fee via return deltas, and recording pending fees.
Liquidity behaviour
No liquidity callbacks.
Fee behaviour
Fees are tracked in storage slots 2 and 3 (set via setFees with two uint256 arguments, bounded by an InvalidFees error and MAX_FEE_BPS). Swaps read these values and accumulate pending fees; treasuryFeeBps and a treasury address exist, suggesting a portion of the fee is routed to a treasury, with collectFees() and a collection threshold controlling when accrued fees are settled to the fee recipient. Exact split and rounding cannot be determined without source.
Owner & admin controls
Owner-style admin functions exist: setFees(uint256,uint256) and setCollectionThreshold(uint256) and setFeeRecipient(address) are nonpayable setters with no verified access check visible in input; the fee recipient slot (slot 0, address) is writable by setFeeRecipient. An unverified selector (0x70c9af24, takes uint256) is also nonpayable and reads/writes fee-related storage slots. Pause-style selectors (activityPaused) appear only as external references, so a pause mechanism is not confirmed as hook-internal.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize records pool initialization data and validates the pool; beforeSwap and afterSwap move currency and adjust deltas for fee taking; beforeSwapReturnDelta and afterSwapReturnDelta enable the hook to take a specified-amount delta so it can skim fees from swaps.

Security & trust assessment

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

Who controls it: A privileged key can change fee parameters (setFees), the collection threshold, and the fee recipient address, redirecting future accrued fees. Changing fees affects every swap in the pool.

Risk to user funds: The hook can take a portion of swap input or output through return deltas and can accrue fees in its own balances before forwarding them to the fee recipient. Swap amounts for users are affected by the configured fee, and accrued fee balances are held by the contract until collectFees is called.

Security findings

  • [medium] Hook takes currency via return deltas: Hook uses return deltas and calls take/settle through unlock, so it can extract value from every swap it is attached to.
  • [high] Privileged fee and recipient setters: setFees and setFeeRecipient are nonpayable and no access-control check is decodable from input; if unrestricted or key-controlled, fees can be set arbitrarily high within the bounds checked.
  • [low] Unlock-based settlement flow: Only the fee-related setter and balance logic were recovered; a reentrancy guard error and unlock callback are present, which mitigates reentrancy but relies on correct unlock handling.
  • [info] Unverified source: Source is not verified, so exact access controls and fee math are inferred from selectors and storage only.

Contract details

Verified source
No
Bytecode size
7,226 bytes
Upgradeable proxy
No
Detected patterns
moves-currency, return-delta, self-unlock

Pools using Fee sharing hook