Limit orders hook on Base

Uniswap v4 Hook Contract 0x4b44a9132d66155c00d8b2257a2f00d330589040 on Base · Limit orders

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 limit-order hook that lets users place single-sided orders at a tick and fills them as the pool price crosses that tick, with withdrawal available once filled.

How it works step by step

  • Records the initial tick of each pool in afterInitialize.
  • Lets users place single-tick limit orders via place, tracked by epoch and direction.
  • Advances epochs in afterSwap when the pool tick crosses an order tick.
  • Lets users withdraw filled proceeds or cancel via withdraw and kill.
  • Uses PoolManager unlock callbacks to settle token flows and mint or burn ERC-6909 claims.
Swap behaviour
afterSwap runs after each swap to check whether the tick has moved past placed order ticks and to advance epoch state so the orders can be filled.
Liquidity behaviour
beforeAddLiquidity and beforeRemoveLiquidity are exposed as view stubs with no state changes; afterInitialize records tick lower values per pool. Order liquidity is tracked per epoch and per user in storage (place, withdraw, kill).
Fee behaviour
Uses the pool's static fee; no fee override or fee-sharing logic was identified.
Owner & admin controls
An owner() getter exists and the hook has an owner-gated kill path, but no ownership transfer or pause function was identified from the decoded selectors; owner-only restrictions could not be confirmed without source.

Enabled Uniswap v4 callbacks

afterInitialize, afterSwap

afterInitialize records the starting tick state for each pool. afterSwap reads tick data and advances epoch state, which is used to fill placed orders when price crosses a tick. Other callbacks are present in the selector table but are not enabled in the address permissions.

Security & trust assessment

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

Who controls it: An owner-gated kill function appears to be able to cancel or close epochs for a pool; the scope of owner powers could not be fully confirmed without verified source.

Risk to user funds: User-deposited order tokens are held in PoolManager claims and tracked in the hook's epoch-liquidity mapping. Users can withdraw through withdraw; a privileged kill path may affect funds still sitting in open epochs.

Security findings

  • [info] Hook moves currency through PoolManager: Hook uses PoolManager unlock callbacks and take/settle/mint/burn/transfer calls to move user tokens and ERC-6909 claims during order placement, withdrawal and kill.
  • [medium] Privileged kill of epochs: Kill path decodes an owner-style access check alongside a kill entrypoint, which could allow an admin to close or cancel user-placed orders.
  • [low] Epoch accounting not verifiable: Order liquidity is stored in a per-epoch mapping keyed by user; correctness of withdrawal depends on epoch accounting, which could not be verified without source.

Contract details

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

Pools using Limit orders hook