Liquidity management hook on Polygon

Uniswap v4 Hook Contract 0xf07d390d4fb1af09569d28b3852e27777d7ac040 on Polygon · Liquidity management

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

What it does

Appears to be a liquidity-management hook that repositions or manages its own positions after swaps on the pool, with the owner controlling its configuration.

This read was written for the hook 0x3b1f…0040 on Avalanche 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

  • Runs afterSwap logic on every swap in the pool
  • Tracks its own positions via getPositions and storage slots holding tick ranges and liquidity
  • Uses unlock and unlockCallback to perform self-initiated PoolManager operations
  • Moves tokens via take and ERC20 transfer/transferFrom calls
  • Exposes owner() and getConfig() for an owner-managed configuration
Swap behaviour
After each swap the hook's afterSwap runs and may rebalance its managed positions through the PoolManager unlock flow; it does not override swap fees or block swaps.
Liquidity behaviour
The hook exposes getPositions and stores several position-like records in storage slots 7, 8 and 9 (int24 ticks, uint128 liquidity, bool-like flags), suggesting it manages its own liquidity positions and runs unlock-based self-calls (unlockCallback, unlock, take) to move tokens against the PoolManager.
Fee behaviour
Not determinable from decoded bytecode; the hook only has an afterSwap permission and no beforeSwap fee override is enabled, so fees are likely the pool's configured fee plus any amounts the hook takes after the swap.
Owner & admin controls
An owner() getter exists, so an owner address is stored; the decoded bytecode shows no clear pause or upgrade function, and parameter-setting functions could not be identified by name. Owner-only write paths were not confirmed.

Enabled Uniswap v4 callbacks

afterSwap

afterSwap is the only enabled hook permission and is used to run logic after each swap, most likely to rebalance or reposition the hook's managed liquidity.

Security & trust assessment

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

Who controls it: The owner can likely influence the hook's configuration and positions through owner-gated functions. Exact powers could not be confirmed without source.

Risk to user funds: The hook can hold and move tokens it manages on the PoolManager through take and transfer calls triggered by afterSwap and its unlock callback; a misbehaving or compromised owner could affect managed liquidity, but direct user funds are not expected to be held by the hook.

Security findings

  • [medium] Hook moves currency via PoolManager unlock flow: The hook calls take, transferFrom and transfer and performs unlock/unlockCallback flows, so it can move pool and user-adjacent tokens during afterSwap.
  • [medium] Owner-controlled configuration and positions: A storage slot holds an owner address and getConfig/getPositions expose mutable configuration, which likely gives a single key control over hook behaviour.
  • [info] Reentrancy guard present: Bytecode references ReentrancyGuard errors, so the contract appears to use a reentrancy guard around its unlock callbacks.
  • [info] Unverified source: No verified source is available, so function semantics and access control are inferred from selectors and storage only.

Contract details

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

Pools using Liquidity management hook