Likely fee sharing hook on Robinhood Chain

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

Volume (24h)
$642
Value locked (TVL)
$829
All-time volume
$9.87K
Pools using this hook
1
Swaps (24h)
10 (10 traders)
Total swaps
155

What it does

This hook takes a fee from every swap and splits it among token burns, liquidity additions, a treasury, FOMO wallet, NFT vault and platform owner, with splits that change based on a weather oracle, and its logic can be upgraded by an admin while LPs remain free to withdraw.

This read was written for the hook 0x27c6…c044 on Robinhood Chain and reused here: the two run the same code.

How it works step by step

  • Takes a fee from swap output after each trade using its afterSwap return-delta permission.
  • Splits collected fees between token burns, pending liquidity additions, a treasury, a FOMO wallet and an NFT vault, plus amounts owed to a platform owner.
  • Uses a 'weather oracle' to change the split between rainy and dry periods (different burn and liquidity shares).
  • Caps the lifetime amount of token that can be burned via a maximum burn share of supply.
  • Has an upgradeTo function and an implementation address, so the logic it points to can be changed by an admin.
Swap behaviour
After each swap the hook can take a fee from the swap amount via a return delta and record it for burns, liquidity, treasury and other recipients. The exact fee is stored as feeBps with a MAX_FEE_BPS constant, but the cap's value cannot be read from bytecode alone.
Liquidity behaviour
No liquidity callbacks; LPs can add and withdraw freely. The hook accumulates pending ETH and token to add as liquidity on its own, but cannot block withdrawals.
Fee behaviour
A swap fee set by feeBps (bounded by an unverified MAX_FEE_BPS) is taken after swaps and split among burn, liquidity, treasury (with sub-shares to a FOMO wallet and NFT vault) and the platform owner, with the split shifting based on a weather oracle report. Exact percentages are unknown from bytecode.
Owner & admin controls
An admin (stored identity admin) can call upgradeTo to change the implementation address, which may change the fee logic; fee and share settings appear configurable within MAX constants whose values are not verified. A weather oracle controls which fee split applies.

Enabled Uniswap v4 callbacks

afterSwap, afterSwapReturnDelta

afterSwap: runs fee accounting and distribution logic after each trade; afterSwapReturnDelta: lets the hook deduct its fee from the swap amount.

Security & trust assessment

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

Who controls it: An identity admin can upgrade the implementation and a weather oracle influences fee splits; platform owner and treasury addresses receive fee shares. The worst case is the admin changing logic to raise how much is taken from swaps.

Risk to user funds: The hook can take a portion of each swap's output; the cap is a stored MAX_FEE_BPS that cannot be verified from bytecode and could change via upgrade. LP principal in the pool cannot be locked because withdrawal callbacks are disabled.

Security findings

  • [high] Upgradeable implementation: The contract exposes upgradeTo(address) and implementation(), writing a new implementation address checked against an admin, so an admin can likely change the logic that takes fees from swaps.
  • [medium] Swap fee via return delta: The hook can deduct tokens from swap output; the fee is bounded by MAX_FEE_BPS but its value cannot be confirmed from bytecode.
  • [info] LP withdrawals unrestricted: Remove-liquidity callbacks are disabled, so LPs can always withdraw their principal.

Contract details

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

Pools using Likely fee sharing hook