Fee sharing hook on Robinhood Chain
Uniswap v4 Hook Contract 0x4120530de23bf6c9448ad39f8018c01351f7e0cc on Robinhood Chain · Fee sharing
- Volume (24h)
- $0
- Value locked (TVL)
- $0
- All-time volume
- $0
- Pools using this hook
- 3
- Swaps (24h)
- 4 (3 traders)
- Total swaps
- 4
What it does
This hook takes a fee on swaps in the pool and splits it between the protocol and the pool creator, while holders of a valid signed pass may pay a reduced fee on their trades.
How it works step by step
- Registers pools at initialization through beforeInitialize and records a per-pool value in a mapping keyed by pool id, then exposes poolFees(bytes32) to read it back.
- On each swap (beforeSwap) it computes a hook fee and accumulates it as pending protocol fees and pending creator fees, tracked in storage slots and per-address mappings.
- Uses beforeSwapReturnDelta and afterSwapReturnDelta, so the hook can take a portion of the swap amount as a delta, which moves currency out of the pool accounting to the hook.
- Provides claimProtocolFees() and claimCreatorFees(address) so accrued fees can be withdrawn; these call back into the pool manager through unlock/unlockCallback and take().
- Includes a pass-based gate: passUsed(uint256) tracks used pass nonces and PASS_TYPEHASH with eip712Domain indicates EIP-712 signed passes checked against passSigner, which can reduce or waive fees for holders of valid signed passes.
- Liquidity callbacks (beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity) are present as selectors but the bytecode indicates they are not used for custom logic beyond pass-through behaviour.
- Swap behaviour
- On beforeSwap and afterSwap the hook reads the pool's fee configuration, computes a fee amount from the swap, and takes it via return deltas, accruing it to protocol and creator balances. Trades presenting a valid pass may pay a different (lower or zero) fee, while other trades pay the full hook-computed fee; the exact split is not recoverable without source.
- Liquidity behaviour
- Liquidity callbacks exist in the dispatch table but no state-changing logic was identified beyond the standard hook return values, so liquidity providers appear to be unaffected aside from their share of pool fees.
- Fee behaviour
- Fees are set per pool at initialization and capped by MAX_FEE_BPS (FeeTooHigh error exists). The hook takes a share of swap volume as a protocol fee and a creator fee, accumulates both in storage, and lets them be claimed later; a pass signed by passSigner can alter the fee charged to that trade.
- Owner & admin controls
- setFactory(address) and setPassSigner(address) change configuration that governs where pools are accepted and which key validates passes. A privileged deployer (NotDeployer error present) gates some of these functions. claimProtocolFees() is callable by the protocol side to withdraw accrued protocol fees. Whether these are behind a timelock, multisig or upgradeable proxy cannot be determined from the bytecode.
Enabled Uniswap v4 callbacks
beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta
beforeInitialize registers each pool's fee settings. beforeSwap computes and takes the hook fee before the swap. afterSwap settles accrued fees after the swap. beforeSwapReturnDelta and afterSwapReturnDelta let the hook take currency as part of the swap accounting. Liquidity and donate callbacks are declared in the table but do not appear to carry custom logic.
Security & trust assessment
Risk level: medium, estimated (decoded bytecode, medium confidence).
Who controls it: A privileged key controls the pass signer and factory address, and may claim protocol fees. A malicious or compromised key could issue free-fee passes or redirect configuration, but could not directly seize pool reserves beyond accrued fees.
Risk to user funds: The hook holds accrued fee balances and performs currency takes during swaps and fee claims, so it does touch user-generated flow. It cannot be confirmed from bytecode whether it can block swaps or move reserves beyond the fee amounts.
Security findings
- [info] Hook takes currency via return deltas: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook removes part of each swap's amount from the pool flow; users receive less than the pure AMM output by the hook fee.
- [medium] Pass signer controls fee exemption: setPassSigner can replace the key that validates EIP-712 passes; a compromised or malicious signer could issue passes that bypass the fee on trades.
- [medium] Admin can reconfigure factory and signer: setFactory and setPassSigner are state-changing admin functions; a privileged key can redirect which factory is trusted and which signer is accepted without user consent.
- [info] Fee cap enforced by MAX_FEE_BPS: The presence of MAX_FEE_BPS and FeeTooHigh indicates an upper bound on the fee, which limits how far fees can be raised.
- [low] Self-unlock accounting path: The hook calls unlock on the pool manager to claim fees; correctness depends on the unlockCallback enforcing the caller and amounts, which cannot be verified from bytecode alone.
Contract details
- Verified source
- No
- Bytecode size
- 7,930 bytes
- Upgradeable proxy
- No
- Detected patterns
- fee-sharing, moves-currency, return-delta, self-unlock