Polymarket resolution explained

Polymarket resolution explained: questa guida spiega il ciclo end-to-end dal reporting al riscatto dei token di outcome, la fase di disputa con l'optimistic oracle UMA e le implicazioni pratiche per i trader. Imparerai cosa succede on-chain e off-chain, quali passaggi sono gasless per gli utenti e i tempi e i rischi che contano per l'arbitraggio e la gestione delle posizioni.

Key takeaways

• La risoluzione inizia con un report di outcome e può entrare in una finestra di disputa ottimistica di UMA prima della liquidazione finale.
• Pur essendo i token di outcome asset ERC-1155 CTF, split/merge/redeem e l'invio di ordini sono gasless per gli utenti tramite il Relayer.
• Dispute, ritardi dell'oracolo, fill parziali e tempi di liquidazione creano rischi reali anche quando i prezzi implicano un edge matematico.
• Conosci la sequenza: report → finestra di disputa (UMA) → finalizzazione → redeem dei token vincenti per pUSD.

What "resolution" means on Polymarket

Su Polymarket, la risoluzione è il processo che converte i token di outcome negoziabili in fondi liquidabili. Per i mercati binari e multi-outcome, un oracolo determina in ultima istanza quale(i) outcome risolve(no) come YES. Quando un outcome è definitivo, ogni token vincente diventa liquidabile per $1.00 di pUSD; i token perdenti sono privi di valore.

I mercati usano il Gnosis Conditional Token Framework (CTF) per i token di outcome. Questi token si comportano come qualsiasi possesso ERC-1155: puoi scambiarli sul CLOB, trasferirli o combinarli con operazioni di split/merge. La differenza chiave alla risoluzione è che il report finale dell'oracolo sblocca il flusso di redeem CTF che converte i token vincenti in pUSD.

The reporting step: who reports and why it matters

La risoluzione inizia quando un reporter invia un outcome al sistema dell'oracolo. Polymarket usa l'optimistic oracle UMA per il reporting. Un report inviato indica l'outcome che il reporter considera corretto e avvia il conteggio per la fase successiva.

Perché è importante:

• Il report è il primo segnale pubblico che l'evento del mercato ha raggiunto uno stato risolvibile. I trader che monitorano i book possono rispondere immediatamente.
• I report sono visibili nell'interfaccia di Polymarket e tramite la Gamma API, quindi bot di arbitraggio e trader umani possono rilevarli in modo programmatico.

UMA optimistic-oracle dispute window (what it is, not how long)

Dopo che un report è pubblicato, il modello ottimistico di UMA consente una finestra di disputa durante la quale i contestatori possono presentare contro-evidenze. Se viene sollevata una disputa, il flusso ottimistico si mette in pausa e UMA risolve la controversia secondo il suo processo.

Punti pratici importanti:

• La finestra di disputa introduce incertezza. Un mercato che sembra risolto può essere riaperto per indagine se UMA riceve una disputa.
• Poiché la tempistica esatta e i dettagli di implementazione delle procedure di UMA sono esterni a Polymarket, i trader dovrebbero considerare qualsiasi mercato dentro o vicino alla fase di disputa come soggetto a rischio di risoluzione.

Note: il prompt di sistema specifica che si usa UMA ma non fornisce la durata della finestra di disputa. Vedi la sezione Notes per questa lacuna.

Finalization and redeeming CTF tokens

Una volta che il processo dell'oracolo è completato e l'outcome è definitivo, il mercato viene finalizzato on-chain. A quel punto gli utenti possono redeemare i token ERC-1155 vincenti per pUSD tramite l'operazione di redeem del CTF.

Praticamente su Polymarket:

• Le operazioni CTF (split / merge / redeem) sono gestite tramite il Polymarket Relayer, quindi sono gasless per te.
• Il redeem trasforma ogni token vincente in $1.00 di pUSD, che poi puoi ritirare o usare per creare nuove posizioni tramite split.

Se detieni un set completo di token di outcome prima della risoluzione, il riscatto è semplice: riceverai pUSD solo per la/e branca/e vincente/i. Se detieni posizioni parziali, solo i token vincenti corrispondenti saranno riscattabili.

Common resolution edge-cases traders see

• Finalizzazioni disputate: le dispute UMA possono ritardare la liquidazione e temporaneamente impedire il redeem. Questo influenza la liquidità e può bloccare capitale.
• Fill parziali ed esecuzione degli ordini: un ordine riempito parzialmente prima della risoluzione può lasciarti long su certi token e short su altri; controlla i fill per evitare esposizioni inaspettate.
• Tick-size e aggiornamenti di prezzo: le variazioni del tick size vicino alla risoluzione possono modificare gli ordini disponibili; il WebSocket emette eventi tick_size_change che sono rilevanti per i bot.
• Effetti di fee e ricompense: le maker fee sono zero; le taker fee variano per categoria. Fee e builder-attribution (se instradi tramite un Builder) influiscono sul risultato netto ma non cambiano il processo di liquidazione dell'oracolo.

Non dare mai per scontato che un mercato liquidato non possa essere riaperto se UMA avvia un flusso di disputa. Verifica sempre lo stato del mercato prima di iniziare qualsiasi operazione di redeem CTF o grossi trasferimenti.

How this affects arbitrage and endgame strategies

Per l'arbitraggio intra-market (comprare un set quando Σ bestAsk < $1.00), le meccaniche di risoluzione sono centrali: il tuo profitto teorico si converte in pUSD solo dopo la finalizzazione e il redeem. Questo significa che il timing, il rischio di disputa dell'oracolo e i ritardi di liquidazione contano tanto quanto l'esecuzione dell'ordine.

Regole pratiche di massima:

• Considera lo spread come un edge matematico solo dopo aver contabilizzato fee, slippage e rischi di disputa. Elenca sempre questi rischi prima di etichettare un'operazione come arbitraggio.
• Per strategie endgame (prezzi vicino alla risoluzione come $0.95–$0.99), sii particolarmente cauto: margini ridotti e dispute UMA possono trasformare un'operazione a breve termine in una perdita.
• Usa le API di Polymarket e il Market WebSocket per monitorare in tempo reale report, tick_size_change, best_bid_ask e last_trade_price.

Monitoring resolution programmatically

API e feed da sorvegliare:

• Gamma API (https://gamma-api.polymarket.com): metadati di mercato ed evento, inclusi i campi correlati alla risoluzione. Usa l'endpoint /markets con paginazione basata su cursor.
• Data API (https://data-api.polymarket.com): posizioni, trade e open interest per tracciare fill ed esposizione.
• Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market): book in tempo reale, price_change, best_bid_ask, last_trade_price e tick_size_change. PING ogni 10s; sottoscrivi con custom_feature_enabled per ricevere best_bid_ask.

Combina questi feed per rilevare un report, sorvegliare segnali di disputa UMA nell'interfaccia o nel feed dati e rimandare il conteggio finale fino a quando lo stato del mercato non è definitivo.

Checklist: what to do when a market reports

• Conferma l'outcome segnalato su Gamma e nell'interfaccia di Polymarket.
• Metti in pausa l'automazione che assume la finalità immediata fino al completamento della fase di disputa UMA.
• Monitora ordini aperti e fill; cancella o aggiusta per evitare esposizioni indesiderate.
• Dopo la finalizzazione, redeema i token vincenti tramite l'interfaccia, l'SDK o il tuo flusso integrato con il Relayer.

How this affects your trading

La risoluzione è il collo di bottiglia finale tra l'esecuzione del trade e il pUSD realizzato. Per trader attivi e arbitrageur, questo significa che devi gestire tre rischi collegati: esecuzione (fill e slippage), risoluzione dell'oracolo (report e dispute) e tempi di liquidazione (redeem e prelievi). Un'esecuzione di successo richiede sia strumenti lato mercato veloci sia assunzioni conservative sul rischio di disputa.

Se costruisci automazioni, registra ogni fill e monitora i canali WebSocket indicati sopra. Considera i mercati dentro o vicino a uno stato reportato come a rischio maggiore finché UMA non li libera.

Closing note: Polymarket resolution explained dovrebbe darti la checklist operativa e il modello mentale per gestire il rischio di liquidazione. Usa le API e il WebSocket per monitorare eventi, ricordati che il redeem CTF è gasless tramite il Relayer e conta sempre le finestre di disputa prima di presumere che un trade si sia convertito in pUSD.

Frequently asked questions

Who reports outcomes on Polymarket?

Polymarket usa l'optimistic oracle UMA per il reporting degli outcome. I report vengono inviati a UMA e sono visibili nell'interfaccia e nelle API di Polymarket; UMA gestisce eventuali dispute successive secondo il suo processo.

What happens during the UMA dispute window?

Dopo un report, UMA consente un periodo di disputa in cui i contestatori possono contestare l'outcome riportato. Se viene contestato, UMA mette in pausa la liquidazione ottimistica e procede con il suo flusso di risoluzione delle dispute, il che può ritardare il redeem dei token vincenti.

Are CTF operations gasless on Polymarket?

Sì. Polymarket sponsorizza il gas tramite il suo Relayer. Split, merge, redeem, trasferimenti e invio ordini sono gasless per l'utente finale perché instradati tramite il Relayer.

Can a market be reopened after it looks resolved?

Sì. Se UMA riceve una disputa, un mercato che sembrava risolto può essere riaperto o ritardato in attesa della risoluzione di UMA. Considera qualsiasi mercato dentro o vicino alla fase di disputa come soggetto a rischio di risoluzione.

How can I programmatically detect a report or dispute?

Usa la Gamma API per i metadati del mercato e il Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) per eventi in tempo reale come price_change, best_bid_ask, last_trade_price e tick_size_change. Combina questi feed con gli endpoint della Data API per monitorare posizioni e fill.