Skip to main content
combo_status_update is emitted after a combo transaction is mined. Match its tx_hash to a pending combo_execution; then use confirmed_fills[] as the on-chain result. The fill rows use the same maker-perspective schema as combo_execution.data.trades[]: size is shares, amount_usdc is dollars, and price is the actual execution price. Receipt-only lifecycle activity can appear in lifecycle_events[] even when PolyNode did not observe a pending transaction. This includes combo-native AutoRedeemer activity. Standard redemption subscribers continue to receive the corresponding stable redemption event where applicable.

Example

The example omits empty optional arrays for readability. Each leg carries the same market object as a combo_execution leg, whose token_ids are the market’s CLOB token IDs in outcome order. combo_status_update is receipt-backed. Its current terminal statuses are: Both values match a subscription filter of status: "confirmed" because both are on-chain receipt results. Do not label every status update successful; always inspect execution_status. If PolyNode did not observe the transaction in the mempool, the receipt event can arrive without pending-only context. In that case pending_detected_at, latency_ms, combo identifiers, decoded legs, and pending-derived wallet/value fields are omitted.

Fields

Confirmation

Top-level maker_address, signer_address, taker_address, amount_usdc, and notional_usdc can also be present when they are recoverable from the pending execution or receipt. For individual fills, use confirmed_fills[].

Confirmed fill

Subscribe

combo_status_update is included in the default combo stream: