"lifecycle") delivers three event types: condition_prepared, token_registered, and condition_resolution.
V1 vs V2:
condition_prepared fires for both V1 and V2 markets (new market signal from ConditionalTokens). token_registered is V1-only - V2 exchanges no longer emit it. Use condition_prepared as your “new market” signal to cover both. See the V2 Migration Guide.condition_prepared
Emitted when a new condition is created on the sharedConditionalTokens contract. Fires for both V1 and V2 markets.
For binary markets (outcome_slot_count === 2), token IDs are derived deterministically from (condition_id, is_neg_risk) using the CTF Gnosis formula and included in the tokens array. For non-binary markets, tokens is null - query Gamma or CLOB by condition_id to resolve them.
- Metadata fields (
title,market_slug,market_id,image) are alwaysnullat prepare time. tokensis populated for binary markets (outcome_slot_count === 2) with derived token IDs.nullotherwise.- Token labels (
"Yes"/"No") are placeholders - clients should resolve canonical labels via Gamma/CLOB once market metadata is indexed. is_neg_riskis derived from the oracle address (trueif oracle =NegRiskAdapter).outcome_slot_countis the number of outcomes for the condition (typically2).
token_registered
Emitted when a new V1 market’s outcome tokens are registered on-chain. Metadata fields (title, market_slug, etc.) may be null for brand-new markets since off-chain metadata may not yet be available.
condition_resolution
Emitted when a market resolves. Thetokens array includes a won field indicating which outcome won. For voided or non-standard resolutions, the is_invalid field is set to true and all token won fields are false.
is_invalid behavior
When Polymarket resolves a market with a non-standard payout vector (anything other than [0,1] or [1,0]), the event includes is_invalid: true and all token won fields are set to false. This covers voided markets, split resolutions (e.g. 50/50 refunds), and other non-standard outcomes.
