> ## Documentation Index > Fetch the complete documentation index at: https://docs.derivadex.com/llms.txt > Use this file to discover all available pages before exploring further. # Order and Account Event Reference > DerivaDEX user-data event reference for ORDER_UPDATE, STRATEGY_UPDATE, and TRADER_UPDATE fields, ordering rules, what each update means, and the identifiers used to correlate related events. DerivaDEX user-data events report order outcomes and account changes after sequencing, with per-feed `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 | Apply websocket messages in top-level `ordinal` order, use `globalOrdinal` for family-local replay, and use `orderMatchOrdinal` only inside `ORDER_UPDATE` batches that belong to one match outcome. ## Related references * [Product and Trading Specifications](/reference-public/product-and-trading-specifications) * [Error Reference](/reference-public/error-reference)