Likely oracle hook on Polygon

Uniswap v4 Hook Contract 0x006b0647c176c3352426e4c0b04b9441044b0040 on Polygon · Dynamic fee

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

What it does

A Polygon Uniswap v4 hook that reacts after each swap and manages its own stored liquidity positions, moving tokens through the PoolManager, but its exact strategy is not verifiable without source.

How it works step by step

  • Runs logic in afterSwap, the only enabled hook permission
  • Tracks its own liquidity positions in storage (getPositions, tick and liquidity slots)
  • Uses unlockCallback with the PoolManager unlock/take flow to settle token movements
  • Transfers ERC20 tokens to and from the hook via transfer and transferFrom
  • Exposes an owner() getter, implying an administrative address
  • Exact strategy (rebalancing, fee capture, or similar) is not identified from bytecode
Swap behaviour
After each swap, the afterSwap callback runs and can update the hook's stored positions and move tokens through the PoolManager; the precise logic cannot be determined from the decoded bytecode.
Liquidity behaviour
The hook enables afterAddLiquidity and afterRemoveLiquidity-related selectors and stores position data (getPositions, slots 7-9 with int24 ticks and uint128 amounts). It appears to manage its own positions via unlockCallback and the poolManager (unlock, take, transfer selectors are referenced), i.e. it likely moves liquidity into and out of the pool on behalf of its stored positions.
Fee behaviour
Fees are not set by the hook through a dynamic fee callback (beforeSwap returns are not identified as fee overrides). The pool's static fee is used unless the hook's internal logic routes fees, which cannot be confirmed.
Owner & admin controls
An owner() getter exists (0x8da5cb5b) but no owner-only setters were decoded; storage slot 0 is written by several state-changing selectors (af8c72ad, db3f1516, eb0b7605, f243b5d0), so administrative or position-configuration writes likely exist but their authorization checks cannot be confirmed from bytecode alone.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap is the only enabled hook permission per the address flags; afterSwap (0xb47b2fb1) is the callback that performs logic after each swap, most likely rebalancing or repositioning the hook's own liquidity.

Security & trust assessment

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

Who controls it: An owner address is exposed; if it can alter position configuration or trigger withdrawals through the unlock flow, it could move liquidity the hook holds, but this is not confirmed.

Risk to user funds: The hook holds and moves pool-related tokens through the PoolManager (take, transfer, transferFrom) and tracks its own positions in storage, so funds it controls could be affected by bugs in those flows or by privileged writers; exact exposure cannot be confirmed without source.

Security findings

  • [medium] Hook moves currency via the PoolManager: The hook calls unlock, take and ERC20 transfer/transferFrom, so it moves pool tokens itself rather than only returning deltas.
  • [medium] Position state writable by several selectors: Storage slots 0 and 2 to 9 are written by functions that create and modify positions; the access control on these writers is not identified.
  • [low] Self-unlock callback pattern: unlockCallback is nonpayable and reached through self-unlock, so correctness of the callback's caller check matters; the check could not be verified from bytecode.
  • [info] Owner present, control scope unclear: Only an owner() getter was decoded; whether the contract is upgradeable or has a pause mechanism is unknown.

Contract details

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

Pools using Likely oracle hook