WLimitOrderHook on Ethereum

Uniswap v4 Hook Contract 0x5449a5cc317a6df2005d5369426e5009fa84d040 on Ethereum · Limit orders · Verified contract

Volume (24h)
$25
Value locked (TVL)
$93
All-time volume
$806.48K
Pools using this hook
9
Swaps (24h)
3 (2 traders)
Total swaps
534

What it does

A limit order hook that lets users place one-sided orders at a chosen tick in a pool, which fill automatically when the price moves through that tick, so traders can sell or buy at a target price without watching the market.

How it works step by step

  • placeOrder takes a pool key, a tick, a direction flag and an amount, and records the deposit as an order identified by getOrderId.
  • The order's liquidity is held by the hook inside the pool, so the user's deposit earns no fees until it fills.
  • afterInitialize records the starting tick-lower reference for the pool so later tick crossings can be detected.
  • afterSwap checks whether the swap crossed a tick that has resting orders and fills those orders by moving their liquidity out of the pool.
  • Filled orders can be claimed through withdraw, and unfilled orders can be removed through cancelOrder; both run through the pool manager's unlock callback.
  • getOrderInfo and getOrderLiquidity expose order status and remaining liquidity per owner.
Swap behaviour
afterSwap runs after every swap and fills any limit orders at ticks the swap crossed. The swap itself is not blocked or repriced by the hook.
Liquidity behaviour
No liquidity callbacks are enabled. Orders are added and removed through placeOrder, cancelOrder and withdraw, not through pool liquidity hooks.
Fee behaviour
Uses the pool's static fee. The hook does not set or take fees, and the decoded permissions do not include return-delta flags.
Owner & admin controls
No owner, pause, upgrade or parameter-setting functions appear in the ABI. The contract is not upgradeable (no proxy pattern in the source), so no privileged key is visible from this contract.

Enabled Uniswap v4 callbacks

afterInitialize, afterSwap

afterInitialize sets up the per-pool tick reference used to detect crossings. afterSwap detects crossed ticks and fills matching limit orders.

Security & trust assessment

Risk level: medium (verified source, medium confidence).

Who controls it: No admin role is visible. A privileged key is not evident from the ABI or the wrapper source, so user-facing centralization risk appears low, subject to review of the parent library.

Risk to user funds: The hook holds user liquidity as pool positions and settles fills and cancellations through the pool manager. It can move user funds only through the placeOrder, cancelOrder, withdraw and afterSwap paths, all of which are gated by the pool manager and order ownership in the parent code.

Security findings

  • [medium] Core logic is inherited and not in the verified files: The wrapper only calls the constructor and inherits everything from OpenZeppelin's LimitOrderHook. Order accounting, fill math and settlement are in the parent library, which was omitted from the input, so this review cannot confirm them.
  • [medium] Hook holds pool liquidity on behalf of users: Deposits are kept as liquidity positions owned by the hook address inside the pool. A bug in order bookkeeping in the parent contract could misattribute or strand these funds.
  • [info] Unused callbacks are present in the ABI: beforeSwap, beforeAddLiquidity and other callbacks are exposed in the ABI, but the address permissions enable only afterInitialize and afterSwap. The unused ones should revert with HookNotImplemented and are not a risk on their own.
  • [info] No privileged roles found: The ABI has no owner, admin or pause functions, so no single key can change parameters, pause the pool or move user orders.
  • [info] Dependence on tick-crossing logic in afterSwap: Order fills happen inside afterSwap, so fill correctness depends on accurate detection of crossed ticks, including when swaps cross several ticks at once or when tick spacing is unusual.

Contract details

Verified source
Yes (WLimitOrderHook)
Compiler
solc 0.8.33+commit.64118f21
Bytecode size
17,147 bytes
Upgradeable proxy
No
Detected patterns
limit-orders

Pools using WLimitOrderHook