Liquidity management hook on Polygon

Uniswap v4 Hook Contract 0xf4c38a7ea6a77c762fa08bcf5f9593c4e6b8c040 on Polygon · Liquidity management

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

A Uniswap v4 hook that runs custom logic after each swap and manages its own liquidity positions, with the mechanism inferred only from decoded bytecode.

How it works step by step

  • Executes custom logic in afterSwap after each swap completes
  • Uses the unlock and unlockCallback pattern to access the pool manager during callbacks
  • Transfers and takes currency via take, transfer and transferFrom calls
  • Maintains an internal positions structure exposed through getPositions and poke
  • Exposes an owner() getter, indicating an owner-controlled role
Swap behaviour
Runs afterSwap logic after each swap, which may use a return delta to settle currency with the pool; the specific accounting cannot be confirmed without source.
Liquidity behaviour
No liquidity callbacks are enabled by the permission flags; liquidity-related selectors (beforeAddLiquidity, afterRemoveLiquidity and similar) are present in the dispatcher but are not enabled by the address permissions.
Fee behaviour
Hook only implements afterSwap with a return delta request; fee handling is not determinable from decoded selectors, so the pool's static fee is assumed unless the afterSwap logic alters it.
Owner & admin controls
An owner() getter exists and the storage layout shows owner-style reads, but without verified source the exact owner-gated setters cannot be confirmed; no pause or upgrade mechanism was identified from selectors.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap is the only enabled callback, used to run custom logic after each swap and likely to adjust balances through a return delta.

Security & trust assessment

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

Who controls it: An owner() getter and an unlockCallback path suggest a privileged role may control positions or parameters; the extent of owner-only actions cannot be confirmed without source.

Risk to user funds: Because the hook takes currency through unlock and take, and holds positions in its own storage, it can move or hold pool funds; the exact conditions under which user funds are at risk cannot be determined without source.

Security findings

  • [medium] Hook moves pool currency: The bytecode references take, transferFrom, transfer and balanceOf, and the hook calls unlock with a self-unlock pattern, so it can move pool currency during its callbacks.
  • [medium] Hook manages its own positions: getPositions and poke selectors plus a stored positions structure indicate the hook manages its own liquidity positions on behalf of the pool.
  • [info] Owner role present: The owner() getter exists, but no verified source confirms which setters are restricted to the owner or whether any upgrade path exists.
  • [info] Unverified source: Only decoded bytecode is available, so function semantics and parameter effects are inferred from selectors and storage access patterns.

Contract details

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

Pools using Liquidity management hook