Likely oracle hook on Polygon

Uniswap v4 Hook Contract 0xc6079d21dacce26449f907b5b39c3242e3cc0040 on Polygon · 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 Uniswap v4 hook that runs logic after swaps and tracks stored position data, and whose exact trader and LP effects cannot be fully confirmed from bytecode alone.

This read was written for the hook 0x5f27…0040 on BNB Chain and reused here: the two share a code shape, so constants such as fees, owners and addresses can differ.

How it works step by step

  • Enables only the afterSwap callback according to the address permissions
  • Reads hook config and stored pool or position state (getConfig, getPositions and related slots)
  • Uses the pool manager unlock flow (unlock and unlockCallback) to perform currency operations
  • Performs token transfers and balance checks (transfer, transferFrom, balanceOf, take) during those operations
  • Exposes an owner() getter, indicating an owner role exists
Swap behaviour
Runs afterSwap logic after each swap; the specific effect on swap outcomes or balances cannot be confirmed from the decoded bytecode.
Liquidity behaviour
Has afterAddLiquidity and afterRemoveLiquidity callbacks that appear to read or record position data stored in the hook (getPositions, slots 6 to 8); the hook also moves currency and self-unlocks the pool manager, so it may act on liquidity it manages.
Fee behaviour
Uses the pool's static fee as far as can be determined; no fee-setting function was decoded.
Owner & admin controls
An owner() getter exists and the storage layout has an owner-style slot, but no explicit owner-gated setter is confirmed from the decoded functions; pausing or parameter changes cannot be confirmed.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap is the only enabled callback in the address permissions and is used to run post-swap logic that reads stored pool and position state; the liquidity and other callbacks present in the bytecode are not enabled by address permissions.

Security & trust assessment

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

Who controls it: Unclear from decoded functions; an owner getter exists, so a privileged key may control hook state or parameters, but the exact powers cannot be confirmed without source.

Risk to user funds: The hook can take and transfer tokens through the pool manager during its unlock callback, so it may hold or move pool or user-related funds; the precise conditions are not determinable from bytecode alone.

Security findings

  • [medium] Hook moves currency via self-unlock: The bytecode contains transfer, transferFrom and take selectors together with unlock and unlockCallback, so the hook can move pool-manager currency and self-unlock the pool manager.
  • [low] Owner role present but powers unclear: The owner() getter and an owner-style storage slot are present, but no setter was confirmed, so the scope of owner privileges is unknown.
  • [info] Source unverified: Without verified source, the purpose of stored position and config data and the exact logic of afterSwap cannot be fully established.

Contract details

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

Pools using Likely oracle hook