Fee sharing hook on Robinhood Chain

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

Volume (24h)
$1.48K
Value locked (TVL)
$566
All-time volume
$68.10K
Pools using this hook
1
Swaps (24h)
33 (16 traders)
Total swaps
835

What it does

A fee-sharing hook that skims a portion of each swap and splits it between a treasury, burns, liquidity and reward vaults, with splits that depend on a weather oracle.

How it works step by step

  • Takes a configurable fee in basis points on swaps via afterSwap with a return delta
  • Splits collected fees into treasury, burn, liquidity and FOMO/NFT vault shares
  • Tracks pending ETH and token amounts for later liquidity addition and cumulative burns
  • Switches share percentages between raining and dry states using a weather oracle
  • Enforces caps on burn share and lifetime burn as a share of supply
  • Operates behind an upgradeable proxy with a platform owner and identity admin
Swap behaviour
After each swap the hook takes a fee portion via its return delta and accrues it to treasury, burn, liquidity and FOMO/NFT vault buckets, with rain or dry share variants selected by the weather state.
Liquidity behaviour
Tracks pending liquidity amounts in ETH and token (pendingLiquidityEth, pendingLiquidityToken) and cumulative burn accounting, suggesting it accumulates fee-derived amounts that are later added to liquidity; no add or remove liquidity callbacks are enabled.
Fee behaviour
Fee parameters (feeBps, treasuryShareBps, burnShareBps, liquidityShareBps, rain and dry share variants, fomoShareBpsOfTreasury, nftVaultShareBpsOfTreasury) are stored in packed storage and exposed through view getters; fees appear to be split between treasury, burn, liquidity and FOMO/NFT vault buckets, with weather-dependent (raining or dry) share variants. The exact split logic is not verifiable from the decoded input.
Owner & admin controls
Owner-style controls exist via upgradeTo(address) on an upgradeable proxy pattern (implementation slot read via implementation()); the upgrade authority is not identifiable from bytecode alone. Platform owner (platformOwner) and identity admin (identityAdmin) addresses are stored. Parameter-level setters (fee, shares) are not among the dispatched selectors, so parameters appear fixed or set at deployment, but this cannot be fully confirmed without source.

Enabled Uniswap v4 callbacks

afterSwap, afterSwapReturnDelta

afterSwap: runs logic after each swap to accrue fees and allocate them to treasury, burn, liquidity and reward buckets. afterSwapReturnDelta: lets the hook take a share of the swap output as a return delta, meaning it takes a portion of traded tokens from the pool flow.

Security & trust assessment

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

Who controls it: The proxy upgrade function (upgradeTo) and the platform owner role could replace the hook logic entirely, changing fee splits, redirecting treasury or burn allocations, or altering weather oracle inputs. A privileged key therefore controls where taken fees flow.

Risk to user funds: The hook can take a share of swap output through its return delta and route it to treasury, burn, liquidity and reward accounts; an upgrade could change these routes, so user funds in swaps are exposed to the hook's current and future logic.

Security findings

  • [high] Upgradeable proxy with upgrade function: upgradeTo(address) is callable and the contract stores an implementation slot, so the logic can be swapped by whoever controls upgrade rights.
  • [medium] Hook takes swap value via return delta: afterSwapReturnDelta lets the hook take part of each swap's output, so fee extraction and redirection affect every swapper and LP directly.
  • [medium] Oracle-driven parameter switching: A weather oracle address and rain/dry flags alter share percentages, so an oracle or its operator can shift fee distribution between buckets.
  • [info] Parameter mutability unclear: Fee and share parameters are exposed as getters; the presence or absence of setters could not be confirmed, so parameter mutability is uncertain.
  • [info] No verified source: Source is unverified, so behaviour is inferred from selectors and storage layout only.

Contract details

Verified source
No
Bytecode size
3,912 bytes
Upgradeable proxy
No
Detected patterns
return-delta, upgradeable

Pools using Fee sharing hook