globalOrdinal cursors for replay and reconciliation.
Ordering and replay
These feeds use two ordering layers: a transport order for messages on one websocket connection and a business-event order for updates inside one event family.| Identifier | Scope | Meaning | Client use |
|---|---|---|---|
sequence | Global server notification stream | Monotonically increasing notification number across all feeds and all connections | Useful for diagnosing cross-connection timing. One connection can observe gaps. |
Top-level ordinal | One websocket connection | Monotonically increasing message order across all subscribed feeds on that connection | Apply live websocket messages in this order, not by local arrival time. |
globalOrdinal | One update family | Stable, monotonically increasing identifier for one ORDER_UPDATE, STRATEGY_UPDATE, or TRADER_UPDATE record | Use for REST pagination and reconnect repair inside the same update family. Do not compare across different families. |
epochId | Exchange epoch | Epoch in which the underlying state transition was recorded | Useful for history inspection and support workflows, not as the primary replay cursor. |
txOrdinal | One epoch, REST history only | Transaction ordinal inside the epoch | Use with epochId and record-local ordinal when inspecting transaction-local ordering in history responses. |
Record-local ordinal | One transaction, REST history only | Ordinal of this row inside the underlying transaction | Distinguishes multiple rows produced by the same transaction. |
orderMatchOrdinal | One order-match outcome | Shared identifier for all ORDER_UPDATE rows produced by the same match outcome | Group multi-row trade, liquidation, and match-driven cancellation outcomes. |
subscriptionKey | One subscription | Normalized key for the subscribed filter set | Useful for logging and confirming which filtered stream produced a message. |
createdAt | One row | Time the event row was created in storage | Useful for display and diagnostics. Do not use as the authoritative replay key. |
| Message behavior | Meaning |
|---|---|
PARTIAL on ORDER_UPDATE, STRATEGY_UPDATE, and TRADER_UPDATE | Always empty. Bootstrap current state from REST before applying live updates. |
UPDATE | Carries one or more business updates in contents.data. |
| Decimal amounts and prices | Encoded as strings to preserve precision. |
Shared payload rules
The three user-data feeds share a few parsing rules even though their payloads differ.| Convention | Meaning |
|---|---|
| Sparse fields | Conditional fields appear only when that event type needs them. Null or absent fields mean “not applicable,” not “zero.” |
| REST history and websocket updates | The websocket payload exposes the live business event. REST history returns the same event families with pagination by globalOrdinal. |
| Rejection rows | Rejections are business events, not transport errors. A healthy connection can deliver them. |
| Empty bootstrap | Because the initial PARTIAL is empty, a reconnect-safe client needs both REST history and websocket updates. |
| What a strategy represents | A strategy is a cross-margined position container inside one account. |
What TRADER_UPDATE covers | TRADER_UPDATE covers trader-level DDX balance and profile state, not per-strategy collateral. |
ORDER_UPDATE
ORDER_UPDATE reports order posting, fills, liquidations, cancellations, and order-level rejections. When a match produces more than one row, the rows share orderMatchOrdinal.
ORDER_UPDATE fields
| Field | Present when | Meaning |
|---|---|---|
globalOrdinal | Always | Stable event identifier for this order-update family. |
epochId | Always | Epoch that contains the underlying outcome. |
reason | Always | Order update type. See codes below. |
symbol | Always | Market symbol such as ETHP or BTCP. |
makerOrderIntent | Always | Canonical order identity carried with the row. Includes orderHash, trader address, strategy hash, side, order type, nonce (the client-supplied unique request identifier), and original order attributes. |
createdAt | Always | Event creation timestamp. |
amount | Post, trade, liquidation, cancellation, some rejections | Base-asset quantity affected by the row. |
quoteAssetAmount | Trade, liquidation, cancellation, some rejections | Quote-asset amount associated with the affected quantity. |
price | Trade, liquidation, many rejection examples | Execution or reference price carried with the row. |
orderMatchOrdinal | Trade, liquidation, match-driven cancellation | Shared identifier for all rows from the same match outcome. |
Record-local ordinal | Trade, liquidation, match-driven cancellation, REST history | Position of this row inside the matched outcome or transaction-local batch. |
takerOrderIntent | Trade, match-driven cancellation | Opposing order for a trade path or a cancellation generated as part of a match outcome. |
lastExecutedAmount, lastExecutedPrice, lastQuoteAssetTransactedAmount | Rejection after earlier fills in the same lifecycle | Most recent executed slice before the rejection row. |
cumulativeFilledAmount, cumulativeQuoteAssetTransactedAmount | Trade, liquidation, some late-stage rejections | Running totals for the affected order lifecycle at this point. |
makerFeeCollateral, makerFeeDDX, takerFeeCollateral, takerFeeDDX | Trade rows that charge fees | Fee charged to the maker or taker in USDC or DDX. |
makerRealizedPnl, takerRealizedPnl | Trade and liquidation rows | Realized PnL for the maker or taker side, excluding fees. |
liquidatedTraderAddress, liquidatedStrategyIdHash | Liquidation rows | Strategy that was liquidated. |
orderRejection | reason = 4 | Order rejection code. |
cancelRejection | reason = 5 | Cancel or modify rejection code. |
ORDER_UPDATE reasons
| Code | Name | Meaning |
|---|---|---|
0 | Post | The order entered the book. No fill has occurred yet. |
1 | Trade | A fill occurred. Use orderMatchOrdinal to group all rows from the same match outcome. |
2 | Liquidation | A liquidation-driven fill occurred. Expect related strategy-side effects on STRATEGY_UPDATE. |
3 | Cancellation | Remaining size was removed. If takerOrderIntent is present, the cancellation was produced by a match outcome rather than by a standalone user cancel. |
4 | OrderRejection | An order request or later lifecycle step was rejected in the order domain. The row can appear after earlier fills, so treat it as part of the lifecycle, not as proof that nothing happened before it. |
5 | CancelRejection | A cancel or modify request was rejected. The existing order state may still be live. |
Order rejection codes
| Code | Name | Meaning |
|---|---|---|
0 | SelfMatch | Matching against resting liquidity from the same strategy was prevented. |
1 | SolvencyGuard | The order could not proceed without violating solvency constraints. |
2 | MaxTakerPriceDeviation | Matching would have exceeded the mark-price deviation guard. |
3 | NoLiquidity | No usable resting liquidity remained. |
4 | InvalidStrategy | The referenced strategy was invalid or missing. |
5 | PostOnlyViolation | A post-only order would have crossed immediately. |
Cancel rejection codes
| Code | Name | Meaning |
|---|---|---|
0 | InvalidOrder | The cancel or modify target could not be found. |
ORDER_UPDATE interpretation notes
| Situation | Interpretation |
|---|---|
One Trade row followed by one Cancellation row with the same orderMatchOrdinal | The match partially filled one side and canceled the residual in the same outcome group. |
OrderRejection row after earlier Trade rows | A later step failed after prior fills had already occurred. Preserve the earlier fills and apply the rejection to the remaining order state. |
| Fully rejected row with placeholder maker fields | Some makerOrderIntent fields can be empty strings, with placeholder enum values, because no full maker intent was created. Parsers must not treat those fields as complete order metadata. |
| Liquidation row | Treat as both an order outcome and an event that also changes account state. The definitive collateral and position update appears on STRATEGY_UPDATE. |
STRATEGY_UPDATE
STRATEGY_UPDATE reports collateral movement and strategy-level position effects in one strategy.
STRATEGY_UPDATE fields
| Field | Present when | Meaning |
|---|---|---|
globalOrdinal | Always | Stable event identifier for the strategy-update family. |
epochId | Always | Epoch that contains the underlying update. |
reason | Always | Strategy update type. See codes below. |
traderAddress | Always | Account that owns the strategy. |
strategyIdHash | Always | Strategy identifier. |
collateralAddress | Always | Collateral token address for the update. |
collateralSymbol | Always | Collateral symbol. Current public examples use USDC. |
createdAt | Always | Event creation timestamp. |
amount | Most rows | Signed amount added to or removed from the strategy. |
newAvailCollateral | Deposit, withdraw intent, funding, trade, fee, liquidation, ADL, some settlement flows | Available collateral after the update, when affected. |
newLockedCollateral | Withdraw, withdraw intent | Locked collateral after the update, when affected. |
positions | PnL settlement, trade, liquidation, ADL | Position state carried with the event. Use it to update strategy positions after the mutation. |
blockNumber | On-chain deposit, withdraw, and some rejection examples | Ethereum block number when the update was processed, if applicable. |
withdrawRejection | reason = 9 | Withdrawal rejection code. |
STRATEGY_UPDATE reasons
| Code | Name | Meaning |
|---|---|---|
0 | Deposit | Collateral increased through an on-chain deposit. |
1 | Withdraw | Locked collateral was reduced by a completed withdrawal claim. |
2 | WithdrawIntent | Collateral moved from available to locked in preparation for withdrawal. |
3 | FundingPayment | Funding moved value into or out of available collateral. |
4 | PnlSettlement | Periodic PnL realization updated collateral and can refresh position basis fields. |
5 | Trade | A fill changed strategy collateral and position state. Expect the paired order-domain outcome on ORDER_UPDATE. |
6 | Fee | Trading or stressed-path fees changed available collateral. |
7 | Liquidation | Liquidation resolved the strategy. Positions close or shrink, and available collateral can be driven to zero. |
8 | ADL | Auto-deleveraging adjusted positions and collateral during stressed resolution. |
9 | WithdrawRejection | A withdrawal attempt was rejected. No collateral move should be inferred from the rejection row itself. |
Withdrawal rejection codes
| Code | Name | Meaning |
|---|---|---|
0 | InvalidStrategy | The referenced strategy was invalid or missing. |
1 | InvalidInsuranceFundContribution | The insurance-fund contribution reference was invalid or missing. |
2 | MaxWithdrawalAmount | The requested amount exceeded the allowed maximum. |
3 | InsufficientInsuranceFundContribution | The withdrawal exceeded the contributed insurance-fund amount. |
4 | InsufficientRemainingInsuranceFund | The withdrawal would leave the insurance fund below the required level. |
STRATEGY_UPDATE interpretation notes
| Situation | Interpretation |
|---|---|
WithdrawIntent with both newAvailCollateral and newLockedCollateral | Funds moved between collateral buckets inside the strategy. |
Withdraw with only newLockedCollateral | A claim reduced locked collateral; available collateral does not increase at this stage. |
Trade plus Fee rows in the same sequence window | A fill changed the strategy and then charged fees as a separate strategy event. Apply both. |
Liquidation or ADL with positions | Position state after stressed resolution is carried on the strategy event. Reconcile positions from this feed, not from ORDER_UPDATE alone. |
TRADER_UPDATE
TRADER_UPDATE reports trader-level DDX balance changes and profile state.
TRADER_UPDATE fields
| Field | Present when | Meaning |
|---|---|---|
globalOrdinal | Always | Stable event identifier for the trader-update family. |
epochId | Always | Epoch that contains the underlying update. |
reason | Always | Trader update type. See codes below. |
traderAddress | Always | Trader account address. |
createdAt | Always | Event creation timestamp. |
amount | Balance-changing rows | Signed DDX amount added to or removed from the trader. |
newAvailDDXBalance | Deposit, withdraw intent, rewards, fees, distributions | Available DDX balance after the update, when affected. |
newLockedDDXBalance | Withdraw, withdraw intent | Locked DDX balance after the update, when affected. |
payFeesInDDX | Profile updates | Whether trading fees should be charged in DDX when possible. |
blockNumber | On-chain deposit examples | Ethereum block number when applicable. |
withdrawDDXRejection | reason = 9 | DDX withdrawal rejection code. |
TRADER_UPDATE reasons
| Code | Name | Meaning |
|---|---|---|
0 | DepositDDX | DDX increased through an on-chain deposit. |
1 | WithdrawDDX | Locked DDX was reduced by a completed withdrawal claim. |
2 | WithdrawDDXIntent | DDX moved from available to locked in preparation for withdrawal. |
3 | TradeMiningReward | Trade-mining rewards increased available DDX. |
4 | ProfileUpdate | Trader-level preferences changed, including the fee-payment preference. |
5 | FeeDistribution | Fee distribution credited DDX to the trader. |
6 | Admission | Trader access was granted. |
7 | Denial | Trader access was denied. |
8 | Fee | Fees charged in DDX reduced available balance. |
9 | WithdrawDDXRejection | A DDX withdrawal attempt was rejected. |
DDX withdrawal rejection codes
| Code | Name | Meaning |
|---|---|---|
0 | InvalidTrader | The referenced trader was invalid or missing. |
1 | InsufficientDDXBalance | The trader did not have enough DDX. |
TRADER_UPDATE interpretation notes
| Situation | Interpretation |
|---|---|
ProfileUpdate with payFeesInDDX only | Preference change without a balance mutation. |
WithdrawDDXIntent with both balance fields | DDX moved between available and locked buckets. |
Fee after trading activity | A trader elected to pay fees in DDX, so the DDX balance changed separately from strategy collateral. |
How to correlate events across feeds
These joins are the practical keys for reconciliation logic.| If you observe | Also expect | Join keys |
|---|---|---|
ORDER_UPDATE with reason = Trade | One or more STRATEGY_UPDATE rows for trade collateral and fee effects | Trader address, strategy hash, symbol, nearby createdAt, and the surrounding websocket-message ordinal window |
ORDER_UPDATE with reason = Liquidation | STRATEGY_UPDATE liquidation and possibly fee rows | Liquidated trader address, liquidated strategy hash, symbol, and nearby message ordering |
| Strategy-side withdrawal intent or claim | STRATEGY_UPDATE only | Trader address and strategy hash |
| DDX withdrawal intent, claim, reward, or fee | TRADER_UPDATE only | Trader address |
| Reconnect repair for one update family | REST history for the same family | Resume from the last applied globalOrdinal of that family |
ordinal order, use globalOrdinal for family-local replay, and use orderMatchOrdinal only inside ORDER_UPDATE batches that belong to one match outcome.