Likely oracle hook on Polygon

Uniswap v4 Hook Contract 0xc5e436ecfcf6eb26b289cea39d0b28bbaf574040 on Polygon · Access control

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

What it does

An unverified Uniswap v4 hook that runs logic after swaps and tracks positions, appearing to move tokens itself through the pool manager, but its exact purpose cannot be confirmed from bytecode alone.

This read was written for the hook 0xc322…8040 on Polygon and reused here: the two run the same code.

How it works step by step

  • Enables only the afterSwap callback among hook permissions.
  • Implements liquidity add and remove hooks, with position tracking exposed via getPositions.
  • Exposes config and pool manager getters (getConfig, poolManager, owner).
  • Calls unlock and token take/transfer functions, so it settles balances itself through the pool manager.
  • Stores pool key fields and configuration parameters in fixed storage slots.
Swap behaviour
afterSwap runs after each swap; beforeSwap is a view stub. Exact action taken in afterSwap cannot be determined without source.
Liquidity behaviour
Implements beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity callbacks as view stubs; the hook appears to track positions (getPositions selector present) and move currency through the pool manager unlock flow.
Fee behaviour
Not determinable from the decoded functions; the hook does not clearly override fees in beforeSwap, and afterSwap is the only swap-related callback enabled.
Owner & admin controls
An owner() getter exists and storage slot 0 is read/written by pool-setup functions, suggesting an owner-gated configuration path, but the exact setters and their parameters cannot be confirmed without source. No pause or upgrade function was identified.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap is enabled and is the only permission bit set; it is the hook's active callback and performs a state write path (selector 0xb47b2fb1) that reads pool config and position storage.

Security & trust assessment

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

Who controls it: An owner address controls storage slot 0, which is written by the pool setup path. Without source the exact privileges are unknown, so the owner may be able to reconfigure pool parameters that the hook depends on.

Risk to user funds: The hook can take and transfer tokens through the pool manager during afterSwap and unlock callbacks, so user and pool funds could be moved or affected by hook logic; the exact conditions cannot be verified without source.

Security findings

  • [medium] Hook moves currency via self-unlock: The hook uses unlock and take/transfer selectors and an unlockCallback, meaning it moves token balances itself via the pool manager during afterSwap and pool-setup flows.
  • [medium] Owner-gated configuration: Storage slot 0 is written by the ownership and pool-setup functions and an owner() getter exists, so a single key may control hook configuration.
  • [high] No verified source: The contract is unverified, so function behaviour, access checks and arithmetic cannot be audited; the analysis relies only on selectors and storage inference.
  • [info] Complex unverified logic: Bytecode is around 21 KB with a broad set of position, config and liquidity selectors, which suggests a custom accounting or rebalancing design rather than a simple fee hook.

Contract details

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

Pools using Likely oracle hook