MEV protection hook on Arbitrum

Uniswap v4 Hook Contract 0xc3adb7bc26fa83156fed9acd3e70ab4a225be880 on Arbitrum · MEV protection

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

What it does

This hook tracks basefee and MEV statistics on swaps and routes accumulated revenue to a treasury, but the exact fee logic is not confirmed from the decoded bytecode, so it is unclear whether trades pay more or less.

How it works step by step

  • Runs in beforeInitialize, beforeSwap and beforeAddLiquidity callbacks, with afterSwap, afterAddLiquidity, afterRemoveLiquidity and related hooks decoded but not enabled in the address permissions
  • Tracks a basefee value (lastBasefee) and updates it during swaps or initialization, suggesting basefee-aware swap logic
  • Maintains a whitelist mapping of base tokens (isBaseToken, setBaseToken) that the hook consults
  • Accumulates MEV-related statistics and arbitrage profit (getMEVStats, totalArbProfit) and treasury revenue (totalTreasuryRevenue, collectRevenue)
  • Holds a treasury address and a protocol token address, with a collectRevenue function that moves accumulated revenue out via transfer
Swap behaviour
beforeSwap is non-view and updates storage (basefee-related state), so it runs on every swap. The exact fee or revenue calculation cannot be confirmed from the decoded bytecode, so whether trades pay more or less is not determined.
Liquidity behaviour
beforeAddLiquidity is gated by the hook; the decoded selectors for beforeRemoveLiquidity and afterAddLiquidity/afterRemoveLiquidity exist but are not enabled in the hook permissions, so liquidity removal is not hooked.
Fee behaviour
Likely adjusts a dynamic fee or shares revenue with a treasury based on basefee and base-token status, but the exact formula is not determinable from decoded bytecode.
Owner & admin controls
Owner (transferOwnership) can set the treasury, set the protocol token, and set base tokens. Collection of revenue is callable by anyone (collectRevenue is not visibly owner-restricted in decoded form, which needs confirmation).

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity, beforeSwap

beforeInitialize records initial state (lastBasefee and related storage). beforeSwap updates basefee and MEV tracking on each swap. beforeAddLiquidity gates liquidity additions.

Security & trust assessment

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

Who controls it: The owner can change the treasury, protocol token and base-token whitelist, and can transfer ownership, so a privileged key controls where revenue goes and which tokens are treated as base tokens.

Risk to user funds: The hook can hold and transfer ERC20 balances as treasury revenue and can take a cut of swap value; it does not appear to use return deltas to block swaps, but this is inferred from selectors only.

Security findings

  • [medium] Owner-controlled treasury and token addresses: setTreasury and setProtocolToken let the owner redirect where collected revenue is sent, which can divert fee income if the owner key is compromised.
  • [medium] Unrestricted revenue collection: collectRevenue is nonpayable with no decoded owner check, so the hook may transfer accumulated balances to the treasury at any time; verify whether an access check exists in bytecode.
  • [info] Hook takes revenue from swaps: The hook accumulates treasury revenue and transfers ERC20 tokens (transfer selector present), so it can hold and move tokens tied to pool activity.
  • [info] Basefee-dependent swap logic: beforeSwap mutates basefee state on each swap, so swap pricing depends on hook-maintained values that an external actor could influence through timing.

Contract details

Verified source
No
Bytecode size
6,385 bytes
Upgradeable proxy
No
Detected patterns
dynamic-fee, erc20, fee-sharing, mev-protection, ownable

Pools using MEV protection hook