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
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:

