Likely oracle hook on Arbitrum

Uniswap v4 Hook Contract 0xa711dca8079653be7170c31863023996c0540040 on Arbitrum · Dynamic fee

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

What it does

This hook appears to hold user deposits, let them deposit and withdraw against a pool, and run custom logic after swaps, though its exact purpose cannot be fully confirmed without source.

How it works step by step

  • Holds per-address balances and exposes deposit(uint256) and withdraw(uint256) entry points.
  • Calls the pool manager unlock flow with unlockCallback, then uses take, settle and sync to move currency.
  • Runs state-changing logic in afterSwap, the only enabled hook callback.
  • Stores a pool key (two token addresses, fee tier, tick spacing, hooks address) in storage slots 2 to 4.
  • Exposes a poolStates(bytes32) view and a targetKey view for reading configured state.
  • Exposes USDC() and USDe() getters, suggesting the pool pairs against those stablecoins.
Swap behaviour
afterSwap runs custom logic after each swap; beforeSwap is a pure stub, and the swap callback writes to storage, so the effect on traders is not fully determinable from the input.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity are present as pure stubs that do not touch state; the hook uses deposit and withdraw functions keyed by address balances and calls modifyLiquidity through the pool manager unlock flow.
Fee behaviour
Hook does not appear to set or take a dynamic fee from the decoded selectors; fee handling cannot be confirmed from the input.
Owner & admin controls
Storage layout shows an address slot written by setter selector 0x2eb17089 (likely an initialization or key-setting call) and a bool flag; no owner or pause modifier is identifiable from the decoded input, so admin controls cannot be confirmed.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap is the only enabled callback and is used to run custom logic after each swap; it reads and writes poolStates-related storage at slot 0 and the mapping at slot 6.

Security & trust assessment

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

Who controls it: Cannot be determined without source; the bytecode suggests the hook can call modifyLiquidity and move tokens through take, settle and sync on the pool manager, so any privileged setter could redirect those flows.

Risk to user funds: Deposited balances are held by the hook and withdrawn via withdraw(uint256); the hook also moves tokens through the pool manager during unlock callbacks, so a bug or privileged misconfiguration could affect deposited funds.

Security findings

  • [medium] Hook moves currency via unlock callback: Heuristic tags flag self-unlock and currency movement, meaning the hook calls unlock on the pool manager and transfers tokens to or from itself during callbacks.
  • [medium] Hook custodies user deposits: The contract exposes deposit and withdraw entry points that credit and debit a per-address balance mapping, so user funds are held by the hook contract itself.
  • [info] Pool key appears configurable: Selector 0x2eb17089 is nonpayable and writes several config slots (addresses, fee tier, tick spacing, a bool), which suggests a configurable pool key that may be set after deployment.

Contract details

Verified source
No
Bytecode size
15,441 bytes
Upgradeable proxy
No
Detected patterns
moves-currency, self-unlock

Pools using Likely oracle hook