Access control hook on Robinhood Chain

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

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

What it does

A small Uniswap v4 hook that only runs at pool initialization and records authorization state, with no visible effect on swaps, liquidity or fees for traders and LPs.

How it works step by step

  • Enables only the beforeInitialize callback at pool creation
  • Stores a deployer address in storage slot 0 set through a one-time setter
  • Tracks per-key initialization or authorization flags in a uint256-keyed mapping
  • Exposes authorize(bytes32) gated to the deployer to record authorizations
  • Exposes view stubs for swap, liquidity and donate callbacks that are not enabled by permissions
Swap behaviour
No swap callbacks.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity are exposed by selector but the decoded bytecode indicates they are view stubs with no state changes evident.
Fee behaviour
Does not set or take fees in any callback; uses the pool's static fee.
Owner & admin controls
A deployer address (slot 0) is set once via a setter (selector 0x191d618f) and gates authorize(bytes32) and reads through 0x6e051849; OnlyDeployer and AdapterAlreadySet errors suggest the deployer can register a single adapter/authorization key, but no pausing or parameter-change functions were found.

Enabled Uniswap v4 callbacks

beforeInitialize

beforeInitialize is the only enabled callback, used to record a per-pool initialization flag in a mapping keyed by uint256 and to validate initialization against the deployer-set address.

Security & trust assessment

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

Who controls it: The deployer-set address controls authorization through authorize(bytes32); a compromised deployer could authorize arbitrary keys, but the hook cannot directly move pool funds from the decoded logic.

Risk to user funds: Based on the decoded bytecode the hook does not take, hold or move user or pool tokens and does not return deltas, so direct user funds exposure appears minimal.

Security findings

  • [info] Single privileged deployer address: The hook registers a single privileged deployer address in storage slot 0 that gates authorization logic.
  • [info] Narrow callback surface: Only beforeInitialize is enabled by permissions, so the hook cannot intercept swaps, liquidity changes or fees at runtime.
  • [low] Unimplemented callbacks present: Bytecode contains revert paths such as HookNotImplemented and Panic, typical of stubbed view callbacks that revert if invoked directly.

Contract details

Verified source
No
Bytecode size
1,801 bytes
Upgradeable proxy
No

Pools using Access control hook