Access control hook on Robinhood Chain

Uniswap v4 Hook Contract 0x041462041fcc1143e972f48ec18c8e2cd4b520cc on Robinhood Chain · Access control

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

What it does

This hook takes a configurable tithe from swaps through return deltas, so swappers receive slightly less output than a plain pool would give while the rest of the mechanism is not fully determinable from bytecode alone.

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

How it works step by step

  • Hook exposes an ERC20-style token interface (name, symbol, decimals, totalSupply, balanceOf, transfer, approve, transferFrom) alongside pool hook callbacks, indicating the hook issues its own token.
  • Uses beforeInitialize to record pool configuration into storage slots 7 to 8 and a set of quiver/tier parameters (slots 11 to 22).
  • beforeSwap and afterSwap read and write accounting slots (9, 11 to 14) and can return deltas, so the hook can modify swap amounts.
  • Maintains a titheBps / titheCollected / titheEmptied accounting scheme, suggesting a portion of swap flow is diverted (a 'tithe') to a designated recipient.
  • Uses a self-unlock pattern (unlockCallback and unlock(bytes) selectors plus take(address,address,uint256)) to move pool currency during callbacks.
  • Stores tiered 'quiver' and bearer-gated state (bearerOf, NotBearer error), so some functions are restricted to specific bearers.
Swap behaviour
beforeSwap and afterSwap both run on every swap and can return deltas and take currency through the pool manager; a configured share of swap flow is diverted to the hook's tithe accounting, so swappers receive less output than the pool would otherwise give. Which direction pays more cannot be determined from the bytecode alone.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity selectors are present but are view functions in the dispatch table, so they do not change state in those callbacks; the hook's liquidity flags are not among the enabled permissions. Liquidity provision is not directly gated.
Fee behaviour
The hook does not set a dynamic LP fee (no beforeSwap fee override is indicated by the enabled permissions); fees are taken as a tithe in basis points (titheBps, bounded by TITHE_MIN_BPS and TITHE_MAX_BPS) through return deltas, with credits tracked by creditsBps.
Owner & admin controls
Ownable: owner can call transferOwnership and renounceOwnership. Owner-only parameter changes are not identifiable from decoded selectors alone. Bearer-gated functions (bearerOf, quiver, empty) restrict some actions to designated bearers.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta

beforeInitialize records pool and tier configuration; beforeSwap applies the tithe and tier checks before the swap; afterSwap settles the tithe and updates accounting; beforeSwapReturnDelta and afterSwapReturnDelta allow the hook to take a share of swap amounts as deltas.

Security & trust assessment

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

Who controls it: The owner and any bearer can influence tithe parameters and tier state; without source the exact setters and their limits are unknown, so a privileged key could potentially change the tithe rate or the quiver configuration.

Risk to user funds: The hook can take a share of swap output through return deltas and hold tithe balances as ERC20-like accounting, so user swap proceeds are exposed to the tithe mechanism; it does not show direct custody of LP positions.

Security findings

  • [medium] Return-delta fee capture: beforeSwapReturnDelta and afterSwapReturnDelta are enabled and the hook calls take(), so it can extract a share of every swap; the rate is bounded by titheBps but the bound and the setter cannot be verified without source.
  • [low] Owner control over ownership: Ownable selectors (transferOwnership, renounceOwnership) mean a single key controls the contract's administrative state.
  • [medium] Bearer-gated state transitions: empty(uint8,uint256) and quiver parameters are gated by a bearer check (NotBearer); the bearer assignment mechanism is not visible in the decoded selectors.
  • [info] Self-unlock currency movement: unlockCallback and take() show the hook moves pool currency during its own unlock; this is standard for return-delta hooks but means the hook can affect user balances in pool accounting.

Contract details

Verified source
No
Bytecode size
8,148 bytes
Upgradeable proxy
No
Detected patterns
erc20, moves-currency, ownable, return-delta, self-unlock

Pools using Access control hook