Likely oracle hook on Polygon

Uniswap v4 Hook Contract 0xa80f1be1e9ddbddfafd865e45be9a849ff7dc040 on Polygon · Access control

Volume (24h)
$48
Value locked (TVL)
$150
All-time volume
$7.93K
Pools using this hook
1
Swaps (24h)
6 (2 traders)
Total swaps
468

What it does

A Uniswap v4 hook on Polygon that runs an after-swap routine which moves tokens through the pool manager, with its exact purpose undetermined without source.

How it works step by step

  • Enables only the afterSwap callback according to the hook address permission bits
  • Uses unlock and unlockCallback to run pool manager operations during swaps
  • Calls take and transfer to move currency between the pool manager and recipients
  • Maintains owner-written configuration in storage slots 0 to 5 that shape pool key and state
  • Exposes owner() and getConfig() views, indicating an admin-configured design
Swap behaviour
After each swap, afterSwap runs and can trigger an unlock callback that takes or transfers currency through the pool manager, though the specific logic cannot be confirmed from bytecode alone.
Liquidity behaviour
Liquidity callbacks beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity are dispatched, but the hook permissions list only afterSwap, so these are likely unused stubs; the hook also uses unlockCallback with take and transfer calls, which suggests it may move currency on its own behalf.
Fee behaviour
No fee logic was identified from the decoded functions; the hook only exposes afterSwap with a delta-return style signature, so any fee or accounting effect cannot be determined from the input.
Owner & admin controls
Owner-gated functions are present (owner() view is exposed, and selectors 0x604a57e1, 0xaf8c72ad, 0xeb0b7605, 0xf243b5d0 are nonpayable writers to slots 0-5 that look like config/pool-key setup), but the exact access checks cannot be confirmed without source. Storage slot 0 is written by four nonpayable functions and read by unlockCallback and afterSwap, suggesting an owner-set configuration that the owner can change.

Enabled Uniswap v4 callbacks

afterSwap

Only afterSwap is enabled by the address permission bits; it is the one callback the pool manager will invoke. unlockCallback is used to perform pool manager actions (take/transfer) via a self-initiated unlock flow.

Security & trust assessment

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

Who controls it: An owner, if one exists, can likely change the stored configuration and pool key references used by unlockCallback and afterSwap, which could redirect currency movements; exact powers are unverified.

Risk to user funds: The hook can take and transfer tokens through the pool manager during afterSwap-triggered unlock flows, so it can move pool-related funds; it does not appear to hold a permanent balance from the selectors alone, but the exact flow is unverified.

Security findings

  • [medium] Hook moves currency via self-initiated unlock: The hook calls unlock and then take/transfer inside unlockCallback, meaning it moves currency during swaps; if the stored parameters are changed by an owner, funds routed through the hook could be redirected.
  • [medium] Privileged configuration writers present: Owner-like nonpayable setters write storage slots 0 to 5 and the owner() view is exposed; no pause or upgrade mechanism was identified from the selectors.
  • [info] Reentrancy guard present: Selector set includes ReentrancyGuardReentrantCall, indicating a reentrancy guard on at least some functions.
  • [info] Unused liquidity callbacks: Liquidity callback selectors are dispatched but only afterSwap is enabled by permissions, so those paths are not reachable through the pool manager.

Contract details

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

Pools using Likely oracle hook