Limit orders hook on Base

Uniswap v4 Hook Contract 0xcb3af3db848165720e07e0f24ff1c46466fed040 on Base · Limit orders

Volume (24h)
$11
Value locked (TVL)
$91
All-time volume
$2.30K
Pools using this hook
9
Swaps (24h)
17 (9 traders)
Total swaps
596

What it does

A limit-order hook that lets makers place orders at a chosen tick, which fill as the pool price crosses that tick during swaps.

How it works step by step

  • Records the initial tick of each pool in afterInitialize and tracks tickLowerLast per position key.
  • Lets makers place limit orders at a specified tick and direction via place(), escrowing tokens in the PoolManager as ERC-6909 claims.
  • Fills orders in afterSwap when the pool price crosses their tick, settling the proceeds to epoch-based liquidity records.
  • Lets makers cancel unfilled orders through kill() and withdraw proceeds of filled epochs through withdraw().
  • Uses unlockCallback variants to perform the place, kill and withdraw flows inside PoolManager unlock sessions.
Swap behaviour
afterSwap runs after each swap to detect ticks crossed and fill resting limit orders at those ticks.
Liquidity behaviour
beforeAddLiquidity and beforeRemoveLiquidity are exposed but the hook is primarily a limit-order book; liquidity for orders is placed via place() and withdrawn via withdraw() and kill(), which move ERC-6909 claims and tokens through the PoolManager.
Fee behaviour
Uses the pool's static fee; the hook does not set or take fees itself.
Owner & admin controls
An owner() getter exists, but no owner-restricted setter was identified in the decoded selectors; no pause or upgrade functions found. Unverified, so privileged mutators cannot be confirmed.

Enabled Uniswap v4 callbacks

afterInitialize, afterSwap

afterInitialize records the starting tick for the pool; afterSwap checks ticks crossed by a swap and fills resting limit orders at the crossed tick epochs.

Security & trust assessment

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

Who controls it: The owner getter suggests an owner role, but no evident parameter-changing function was found; a privileged key's capabilities are unclear from the decoded input.

Risk to user funds: The hook holds order collateral and moves tokens during place, kill and fill operations; user funds are exposed to bugs in these paths since source is unverified.

Security findings

  • [medium] Hook custodies order collateral through the PoolManager: The hook can move user funds via transfer, transferFrom, mint and burn calls and the unlock/settle/take flow, so order escrow depends on correct accounting in the unlock callbacks.
  • [medium] Epoch accounting complexity: The unlockCallback paths handle place, kill and withdraw; incorrect epoch or liquidity bookkeeping in mapping-based storage could misallocate proceeds between makers.
  • [info] Owner role present: An owner() getter is present, indicating an owner role; no clear privileged mutator was identified from the selectors alone.
  • [info] Unverified source: Without verified source, function semantics, access checks and edge cases in the unlock callbacks cannot be fully confirmed.

Contract details

Verified source
No
Bytecode size
18,157 bytes
Upgradeable proxy
No
Detected patterns
erc6909-claims, moves-currency, self-unlock

Pools using Limit orders hook