MEV protection hook on Robinhood Chain
Uniswap v4 Hook Contract 0xb52622fd03cdab48fa6b2d207cfbff944f2fe8cc on Robinhood Chain · MEV protection
- Volume (24h)
- $0
- Value locked (TVL)
- $0
- All-time volume
- $0
- Pools using this hook
- 1
- Swaps (24h)
- 861 (154 traders)
- Total swaps
- 861
What it does
This hook applies an MEV-protection module to Uniswap v4 pools that can raise the LP fee for early trades and takes a protocol cut, though exact per-trade pricing could not be confirmed from the bytecode alone.
How it works step by step
- Attaches an MEV module to pools, gated by per-pool mevModuleEnabled and mevModuleOperational flags set via initializeMevModule and mevModuleOperational.
- Runs a pool extension helper (_runPoolExtensionHelper) during swaps, with an allowlist of pool extensions (poolExtensionAllowlist) and per-pool poolExtension and poolExtensionSetup records.
- Maintains per-pool fee state (feeState, quoteFees, mevModuleSetFee) and a protocol fee numerator, with a MAX_MEV_LP_FEE cap on the MEV-period LP fee.
- Uses an EARLY_PERIOD window keyed off poolCreationTimestamp, so pool age appears to influence fee or MEV handling.
- Splits fees between LPs (LP_SHARE_BPS) and protocol (PROTOCOL_FEE_NUMERATOR, protocolFee, sweeper), and tracks a locker per pool.
- Returns deltas in beforeSwap and afterSwap, meaning the hook can alter the amounts a swap settles.
- Swap behaviour
- beforeSwap runs MEV-module logic (pool extension helper, dynamic fee and locker checks) and can return a delta, and afterSwap settles fees and possibly takes or returns a delta. Exact per-trade pricing rules could not be determined from bytecode; the MEV-period fee cap suggests trades in the early window may pay a higher fee than later trades.
- Liquidity behaviour
- beforeAddLiquidity may gate additions (via a stored flag per pool) and afterAddLiquidity/beforeRemoveLiquidity/afterRemoveLiquidity are present in the dispatch table but their effects could not be fully decoded. beforeDonate and afterDonate are also present.
- Fee behaviour
- Fees are dynamic: the LP fee is set per pool through mevModuleSetFee and feeState, capped by MAX_MEV_LP_FEE and MAX_DYNAMIC_FEE, with a protocol share taken and a share of fees paid to LPs (LP_SHARE_BPS). The exact fee formula is not determinable from the decoded bytecode.
- Owner & admin controls
- Privileged functions exist (initializeMevModule, mevModuleSetFee, mevModuleOperational, initializePool, initializePoolOpen, sweeper access) and the storage writes suggest an owner or operator role; the exact role check could not be confirmed from bytecode. The contract appears to have a sweeper for withdrawing accumulated funds.
Enabled Uniswap v4 callbacks
beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta
beforeInitialize: validates and initializes pool state before the pool is created. beforeAddLiquidity: checks liquidity additions against module state. beforeSwap: applies the dynamic fee and MEV logic and can return a delta. afterSwap: finalizes fee accounting and can return a delta. beforeSwapReturnDelta and afterSwapReturnDelta: allow the hook to take or give currency during swaps.
Security & trust assessment
Risk level: high, estimated (decoded bytecode, low confidence).
Who controls it: A privileged operator can configure the MEV module, set fees per pool, select extensions, and sweep funds, so users depend on that key.
Risk to user funds: The hook can hold and move funds through return deltas and fee accounting, and the sweeper can withdraw balances; swaps and liquidity actions may be affected by its gating.
Security findings
- [high] Return deltas on swaps: beforeSwapReturnDelta and afterSwapReturnDelta are enabled, so the hook can take or give currency on every swap and change what users settle.
- [medium] Privileged fee setting: mevModuleSetFee lets a privileged caller change the LP fee per pool, capped by MAX_MEV_LP_FEE and MAX_DYNAMIC_FEE, which can raise trader costs.
- [medium] Sweeper and protocol fee: A sweeper and a protocol fee numerator allow an operator to withdraw accrued funds from the hook.
- [medium] Pool extension execution: _runPoolExtensionHelper forwards swap context to allowlisted extension contracts; a malicious or compromised extension could affect swaps.
- [info] No source verification: The bytecode was analysed without verified source, so role checks and exact fee math are inferred and may be incomplete.
Contract details
- Verified source
- No
- Bytecode size
- 24,328 bytes
- Upgradeable proxy
- No
- Detected patterns
- access-control, dynamic-fee, fee-sharing, mev-protection, return-delta