Likely oracle hook on Avalanche

Uniswap v4 Hook Contract 0x13fbd39b800d4dbc3908239c6720737677960040 on Avalanche · Access control

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

What it does

An unverified afterSwap hook on Avalanche that appears to manage its own liquidity positions and move currency through the pool manager after swaps.

How it works step by step

  • Enables only the afterSwap callback
  • Calls unlock on the pool manager to perform self-unlocked accounting
  • Uses take and transfer to move tokens after swaps
  • Stores pool key, tick range and position data in contract storage
  • Exposes getPositions, getConfig and owner views
Swap behaviour
afterSwap runs after each swap and appears to take or move currency through the pool manager using unlock and token transfers; exact logic is not confirmed.
Liquidity behaviour
Liquidity callbacks (beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity) are present as selectors, and the hook uses unlock/take/transfer patterns and tracks position-like state, suggesting it manages its own liquidity positions in the pool via self-unlock.
Fee behaviour
The hook does not override fees in any callback (beforeSwap returns no fee override in the decoded selectors); fee behaviour is unclear from bytecode alone.
Owner & admin controls
An owner() getter exists and the hook stores an owner slot written during setup functions (0x604a57e1, 0xaf8c72ad, 0xeb0b7605, 0xf243b5d0 write slots 0 through 5). Whether these setup selectors are owner-gated or callable by anyone cannot be confirmed without source.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap is the only enabled hook permission and is used to run logic after each swap, which in this contract appears to involve moving currency via the pool manager (take/transfer) and updating stored position state.

Security & trust assessment

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

Who controls it: An owner address is stored and setup selectors are present; an owner with control over these functions could redirect or reconfigure the hook's positions and parameters, but the exact scope is unverified.

Risk to user funds: Because the hook can call unlock, take and transfer on the pool manager during afterSwap, it can in principle move tokens held by or for the pool; the extent depends on logic not visible without source.

Security findings

  • [medium] Hook moves currency during swaps: The hook calls unlock on the pool manager and performs take and transfer operations, so it can move pool and user-related tokens during swaps.
  • [medium] Mutable configuration stored in hook: Several storage slots (pool key fields, tick bounds, uint128 amounts) are written by setup selectors, indicating mutable configuration that could change pool behaviour after deployment.
  • [medium] Owner-controlled setup not verified: The contract exposes owner() and writes an owner slot, but no source is available to confirm access control on the setup functions.
  • [info] Unverified source limits confidence: Analysis is based on decoded bytecode only; the purpose of the position and tick storage cannot be confirmed without verified source.

Contract details

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

Pools using Likely oracle hook