General

Sets the PoolManager address and the getBlockNumberOffset.

Tracks lastAddedLiquidityBlock and withholds feeDelta if liquidity was added within the blockNumberOffset period. See _afterRemoveLiquidity for claiming the withheld fees back.

Penalizes the collection of LP feesDelta and withheldFees after liquidity removal if liquidity was recently added to the position.

Returns the current block number.

Updates the lastAddedLiquidityBlock for a liquidity position.

Takes feeDelta from a liquidity position as withheldFees into this hook.

Returns withheldFees from this hook to the liquidity provider.

Calculates the penalty to be applied to JIT liquidity provisioning.

The penalty is calculated as a linear function of the block number difference between the lastAddedLiquidityBlock and the currentBlockNumber.

The formula is: liquidityPenalty = feeDelta * ( 1 - (currentBlockNumber - lastAddedLiquidityBlock) / blockNumberOffset)

The penalty is 100% at the block where liquidity was last added and 0% after the blockNumberOffset block.

The minimum time window (in blocks) that must pass after adding liquidity before it can be removed without penalty. During this period, JIT attacks are deterred through fee withholding and penalties. Higher values provide stronger JIT protection but may discourage legitimate LPs.

Tracks the withheldFees for a liquidity position.

withheldFees are UniswapV4’s feesAccrued retained by this hook during liquidity addition if liquidity has been added within the blockNumberOffset time window. This is intended to disable fee collection during JIT liquidity provisioning attacks. See _afterRemoveLiquidity for claiming the fees back.

Returns the withheldFees for a liquidity position.

Set the hooks permissions, specifically afterAddLiquidity, afterAddLiquidityReturnDelta, afterRemoveLiquidity and afterRemoveLiquidityReturnDelta.

The hook was attempted to be constructed with a blockNumberOffset lower than MIN_BLOCK_NUMBER_OFFSET.

A penalty was attempted to be applied and donated to LP’s in range, but there aren’t any.

Handles the before swap hook.

For the first swap in a block, it saves the current pool state as a checkpoint.

For subsequent swaps in the same block, it calculates a target output based on the beginning-of-block state, and sets the inherited _targetOutput and _applyTargetOutput variables to enforce price limits in _afterSwap.

Handles the after swap hook.

Caps the obtained output from the swap to the target output determined during the _beforeSwap hook. Handles the excess output afterwards via _afterSwapHandler.

Returns the current block number.

Calculates the output amount based on the pool state at the beginning of the block. This prevents sandwich attacks by ensuring trades can’t get better prices than what was available at the start of the block. Note that the calculated output could either be input or output, depending if it’s an exactInput or outputOutput swap. In cases of zeroForOne == true, the target output is not applicable, and the max uint256 value is returned as a flag only.

The anti-sandwich mechanism works such as:

Handles the excess tokens collected during the swap due to the anti-sandwich mechanism. When a swap executes at a worse price than what’s currently available in the pool (due to enforcing the beginning-of-block price).

Handles the fees collected via the anti-sandwich protection in _afterSwap.

Set the hook permissions, specifically beforeSwap, afterSwap, and afterSwapReturnDelta.

Set the PoolManager address.

Hooks into the afterInitialize hook to set the last tick lower for the pool.

Hooks into the afterSwap hook to get the ticks crossed by the swap and fill the orders that are crossed, filling them.

Places a limit order by adding liquidity out of range at a specific tick. The order will be filled when the pool price crosses the specified tick. Takes a PoolKey key, target tick, direction zeroForOne indicating whether to buy currency0 or currency1, and amount of liquidity to place. The interaction with the poolManager is done via the unlock function, which will trigger the unlockCallback function.

Cancels a limit order by removing liquidity from the pool. Takes a PoolKey key, tickLower of the order, direction zeroForOne indicating whether it was buying currency0 or currency1, and recipient address to for the removed liquidity. Note that partial cancellation is not supported - the entire liquidity added by the msg.sender will be removed. Note also that cancelling an order will cancel the order placed by the msg.sender, not orders placed by other users in the same tick range. The interaction with the poolManager is done via the unlock function, which will trigger the unlockCallback function.

Withdraws liquidity from a filled order, sending it to address to. Takes an OrderId orderId of the filled order to withdraw from. Returns the withdrawn amounts as (amount0, amount1). Can only be called after the order is filled - use cancelOrder to remove liquidity from unfilled orders. The interaction with the poolManager is done via the unlock function, which will trigger the unlockCallback function.

Handles callbacks from the PoolManager for order operations. Takes encoded rawData containing the callback type and operation-specific data. Returns encoded data containing fees accrued for cancel operations, or empty bytes otherwise. Only callable by the PoolManager.

Internal handler for place order callbacks. Takes placeData containing the order details and adds the specified liquidity to the pool out of range. Reverts if the order would be placed in range or on the wrong side of the range.

Internal handler for cancel order callbacks. Takes cancelData containing the cancellation details and removes liquidity from the pool. Returns accrued fees (amount0Fee, amount1Fee) which are allocated to remaining limit order placers, or to the cancelling user if they’re removing all liquidity.

Internal handler for withdraw callbacks. Takes withdrawData containing withdrawal amounts and recipient, burns the specified currency amounts from the hook, and transfers them to the recipient address.

Internal handler for filling limit orders when price crosses a tick. Takes a PoolKey key, target tickLower, and direction zeroForOne. Removes liquidity from filled orders, mints the received currencies to the hook, and updates order state to track filled amounts.

Internal helper that calculates the range of ticks crossed during a price change. Takes a PoolId poolId and tickSpacing, returns the current tickLower and the range of ticks crossed (lower, upper) that need to be checked for limit orders.

Returns the last recorded lower tick for a given pool. Takes a PoolId poolId and returns the stored tickLowerLast value.

Retrieves the order id for a given pool position. Takes a PoolKey key, target tickLower, and direction zeroForOne indicating whether it’s buying currency0 or currency1. Returns the {OrderId} associated with this position, or the default order id if no order exists.

Get the liquidity of an order for a given order id and owner. Takes an {OrderId} orderId and owner address and returns the amount of liquidity the owner has contributed to the order.

Get the next order id.

Get the hook permissions for this contract. Returns a Hooks.Permissions struct configured to enable afterInitialize and afterSwap hooks while disabling all other hooks.

Tracks the order info for each order id.

Emitted when an owner places a limit order with the given orderId, in the pool identified by key, at the given tickLower, zeroForOne indicating the direction of the order, and liquidity the amount of liquidity added.

Emitted when a limit order with the given orderId is filled in the pool identified by key, at the given tickLower, zeroForOne indicating the direction of the order.

Emitted when an owner cancels a limit order with the given orderId, in the pool identified by key, at the given tickLower, zeroForOne indicating the direction of the order, and liquidity the amount of liquidity removed.

Emitted when an owner withdraws their liquidity from a limit order with the given orderId, in the pool identified by key, at the given tickLower, zeroForOne indicating the direction of the order.

Zero liquidity was attempted to be added or removed.

Limit order was placed in range.

Limit order placed on the wrong side of the range.

Limit order was already filled.

Limit order is not filled.

The zero bytes.