Lambda Reference

A lambda program defines when to trigger and what to place. It is composed of a predicate (the trigger condition) and response parameters (how the underlying order is placed).

Predicate structure

A predicate has two parts: index data (which events to watch) and match data (the condition to satisfy).

Index data selects the event stream:

Field	Description
pred_side	Side of events to watch: ASK or BID.
pred_type	Event type: LIQ_ADD (liquidity arriving) or LIQ_RMD (liquidity leaving).
market_id	Market to monitor (can differ from the underlying order’s market).

Match data defines the trigger condition:

Field	Description
pred_qual	Liquidity removal qualifier (see below). Only applies when pred_type is LIQ_RMD; must be ANY on a LIQ_ADD predicate.
ticks_type	How to interpret the tick thresholds.
qty_type	How to interpret the quantity thresholds.
min_ticks / max_ticks	Tick range the event must fall within.
min_qty / max_qty	Quantity range the event must fall within.

Predicate tick types

Local and remote lambdas use different tick types:

Local lambdas:

Value	Description
ABS_TICKS	Match against the absolute tick price of the event.
DELTA_GT_BEST_ASK	Match against the event’s tick depth from the best price. Requires pred_side: ASK.
DELTA_LT_BEST_BID	Match against the event’s tick depth from the best price. Requires pred_side: BID.

Both delta types measure the same thing: distance in ticks from the top of the book named by pred_side, so each is only accepted alongside the side it is named for.

Remote lambdas:

Value	Description
ABS_TICKS	Match against the absolute tick price of the remote event.
MID_PX_CHANGE_ABS	Match against the absolute magnitude of mid-price change from ref_ticks.
MID_PX_CHANGE_SGN	Match against the signed mid-price change from ref_ticks (positive or negative).

The two lists do not overlap beyond ABS_TICKS: using either list’s tick types on the other kind of lambda is rejected with INVALID_ARGUMENT.

Predicate quantity types

Value	Description
LEVEL_QTY	Match against the total quantity at the event’s price level.
DELTA_QTY	Match against the change in quantity caused by the event.

Liquidity removal qualifiers

When pred_type is LIQ_RMD, pred_qual filters which removal events trigger the lambda:

Value	Description
ANY	Any removal event (execution or cancellation).
EX	Execution only, liquidity removed by a trade.
CX	Cancellation only, liquidity removed by order cancel.
XA	Execute and add, a crossing order that removes opposite-side liquidity and forms a new resting level.

Response parameters

Response parameters control how the underlying order is placed when the predicate triggers.

Quantity type (lr_qty_type) determines the order quantity. Available types differ between local and remote lambdas:

Local lambdas:

Value	Description
ENTIRE	Place the full quantity specified in the underlying order. Lambda is exhausted after triggering.
DELTA_QTY_RMD	Place a quantity equal to the liquidity delta from the triggering event, dribbling the underlying order onto the book across repeated triggers. Requires a LIQ_RMD predicate and a positive order quantity.

Remote lambdas:

Value	Description
ENTIRE	Place the full quantity specified in the underlying order. Lambda is exhausted after triggering.
MM_CX_PREV	Market-maker cancel-previous: cancels the previously placed resting order and places a fresh GTC order. Requires tif: GTC.

Ticks type (lr_ticks_type) determines the order price:

Value	Description
TICKS_ABS	Use the absolute tick price from the underlying order.

Other LRQtyType and LRTicksType values are declared in the API but not yet available, and a program using one is rejected with FAILED_PRECONDITION. Lambdas with an underlying cancel order must be submitted with tif: IOC.

Remote lambdas

Remote lambda programs trigger on data from external exchanges instead of local market events.

Remote lambdas are not available at this time.

Remote venues:

Value	Exchange
ANY_VENUE	Any available venue (wildcard match).
BN	Binance
CB	Coinbase
KN	Kraken
OKX	OKX
BYB	Bybit

Remote event types:

Value	Description
MIDPX	Mid-price tick on the remote venue.
TRADE	Trade execution on the remote venue.

Remote predicates use the ABS_TICKS, MID_PX_CHANGE_ABS and MID_PX_CHANGE_SGN tick types. The ref_ticks field sets the reference mid-price for delta calculations.

Status lifecycle

After submission, a lambda program moves through these states:

Status	Description
PENDING	Submitted, awaiting acceptance by the FPGA.
IN_FORCE	Active and evaluating on every matching event.
OUT_OF_FORCE	No longer active (quantity exhausted or canceled).
REJECTED	Refused. The reason explains why.

Lambda status updates (LSU) are delivered via WebSocket or GET /v1/lambda/status-updates. Each update includes a reason:

Reason	Description
PROGRAMMED	Lambda accepted and now in-force.
CANCELED	Lambda was explicitly canceled or auto-canceled.
MODIFIED	Lambda quantity was modified.
EXHAUSTED	All quantity has been triggered, lambda is out-of-force.
SYSTEM_RESTART	Lambda state reset due to system restart.
INSUFFICIENT_BALANCE	Refused: the account cannot fund the lambda.
DUPLICATE_CLIENT_ID	Refused: the client lambda id is already in use by a live lambda.
INVALID_LAMBDA	Refused: the lambda’s inputs are not valid.
EXCHANGE_ERROR	Refused: the lambda could not be accepted.

Each LSU contains a delta_qty field showing the quantity placed or canceled in that specific update, and an lsu_id identifying the update itself. A refusal is never recorded, so it reaches the WebSocket only: it has an lsu_id of its own, no lambda_id, and never appears here.