Il sito di un mercato predittivo è l’ingresso a un sistema con diversi compiti. L’interfaccia presenta il mercato, il sistema di scambio abbina gli ordini, i contratti regolano i movimenti degli asset e i servizi dati rendono leggibile il risultato. Un oracolo fornisce la risposta finale attraverso la procedura di risoluzione configurata.
Questi compiti avvengono in luoghi diversi. Cliccare un pulsante, avere un ordine accettato e completare il regolamento di uno scambio sono traguardi distinti. Capirne i confini spiega perché un mercato possa essere visibile ma non negoziabile, o perché una transazione completata impieghi tempo ad apparire nel portafoglio.
Questo è il secondo articolo di Come funzionano Polymarket e Kuest. Se prezzi e pagamenti sono concetti nuovi, parti da cosa significa davvero il prezzo di un mercato predittivo.
Quattro livelli, quattro responsabilità
| Livello | Ruolo |
|---|---|
| Interfaccia | Presentare domande, regole e controlli dell’account |
| Sistema di scambio | Validare gli ordini e trovare proposte compatibili |
| Contratti | Applicare le regole su asset e permessi del percorso scelto |
| Servizi dati | Organizzare metadati, saldi e attività per le applicazioni |
La panoramica delle API di Polymarket riflette la separazione: Gamma supporta la scoperta, CLOB gli ordini e lo stato del mercato in tempo reale, Data API le attività di account e mercati. Le WebSocket forniscono aggiornamenti, ma non sostituiscono le regole di regolamento sottostanti.
Una pagina non è un identificatore di posizione
Un evento raggruppa mercati correlati per presentarli. Un mercato binario pone una domanda specifica risolvibile e offre esiti YES e NO separati. Un evento può contenere più mercati, quindi l’indirizzo della pagina non basta a specificare un ordine. Vedi il modello di mercati ed eventi di Polymarket.
Nel Conditional Tokens Framework, o CTF, l’ID della domanda identifica l’input di risoluzione. L’ID della condizione deriva dall’indirizzo dell’oracolo, dall’ID della domanda e dal numero di slot degli esiti. L’ID di una posizione dipende anche dal collaterale e dal percorso della collezione. Questi identificatori non possono essere sostituiti l’uno con l’altro senza verifica.
Una mappa di raggruppamento, non una formula di hash. Scegli mercato ed esito esatti prima di leggere il libro o inviare un ordine.
La guida di Polymarket ai dati on-chain distingue queste derivazioni CTF dagli identificatori Protocol V2. Un titolo uguale su un altro sito non dimostra che l’asset sia lo stesso.
Segui un ordine attraverso il sistema
Prima l’interfaccia trova un mercato e ottiene identificatori degli esiti e configurazione di trading. Il client prepara l’ordine e il firmatario pertinente ne autorizza le condizioni. Firmare un ordine non equivale a trasmettere una transazione blockchain.
L’istruzione firmata raggiunge il libro centrale degli ordini limite, o CLOB. Il servizio verifica l’ammissibilità e cerca ordini compatibili. Un ordine ammesso può restare aperto se non è eseguibile subito; un abbinamento è un accordo di scambio secondo le regole della piattaforma, non ancora la prova della consegna degli asset.
Poi avviene il regolamento. Un servizio di esecuzione invia una transazione ai contratti pertinenti su Polygon. Il percorso valida lo scambio autorizzato e aggiorna gli asset se l’esecuzione riesce. Una transazione fallita non diventa un acquisto riuscito solo perché l’API aveva già segnalato l’abbinamento.
Le frecce continue seguono l’istruzione verso il regolamento. Quelle tratteggiate mostrano dati registrati che tornano all’interfaccia; non spostano collaterale.
Polymarket documenta il ciclo di vita degli ordini e invita separatamente le integrazioni ad attendere il regolamento dell’eseguito prima di controllare la posizione risultante. Contano inclusione della transazione e stato di conferma richiesto; il solo ID dell’ordine non basta.
Infine gli indicizzatori elaborano i cambiamenti registrati e le API servono viste aggiornate. L’interfaccia può mostrare posizione e attività. Servono messaggi di stato distinti per queste fasi, non un unico ambiguo «successo».
I contratti sono una famiglia, non un solo blocco
Un sistema basato su CTF divide i compiti fra diverse famiglie di contratti. I nomi seguenti descrivono ruoli; contratti e permessi esatti dipendono dal percorso.
Una mappa di responsabilità. Non significa che ogni transazione chiami tutte e cinque le famiglie.
| Famiglia | Ruolo |
|---|---|
| Wallet, factory e infrastruttura di aggiornamento | Custodire asset e applicare regole di proprietà, firma e implementazione |
| CTF Exchange o percorso di scambio a rischio negativo | Validare e regolare gli ordini abbinati pertinenti |
| Conditional Tokens | Registrare i saldi degli esiti CTF e supportare divisione, fusione e riscatto |
| Adapter degli oracoli e percorsi di risoluzione | Collegare una risposta accettata al pagamento registrato per una condizione |
| Supporto per commissioni, ricompense ed escrow | Gestire procedure aggiuntive di contabilità, incentivi o finanziamento se configurate |
Regolamento e risoluzione rispondono a domande diverse. Il regolamento chiede se lo scambio può muovere asset; la risoluzione quale pagamento implichino le regole del mercato. La documentazione di risoluzione attuale di Polymarket distingue i mercati UMA dai mercati su rialzo e ribasso Chainlink TWAP. Il motore di abbinamento non decide il risultato scegliendo un prezzo di scambio.
La versione conta. Polymarket documenta oggi sia CTF sia Protocol V2 per le posizioni. Protocol V2 usa PositionManager, CTF usa Conditional Tokens. Il registro dei contratti elenca componenti di regolamento diversi. «Exchange V2» non è sinonimo di «Protocol V2»: identifica sempre insieme versione del mercato, registro e percorso.
I dati rendono utilizzabile il registro, ma possono essere in ritardo
Un indicizzatore trasforma eventi dei contratti in record consultabili. Un’API può combinarli con metadati, prezzi o calcoli. Sono dati utili all’applicazione, ma il loro aggiornamento può differire dalla ricevuta della transazione o dal flusso degli ordini in tempo reale.
La guida di Polymarket ai dati on-chain descrive eventi di trasferimento e di esecuzione degli scambi. Questi record non contengono ogni ordine off-chain ancora aperto. Allo stesso modo, chiamare un indicizzatore «subgraph del libro ordini» non lo rende il libro in tempo reale. Una quotazione corrente e un eseguito storico appartengono a record diversi.
Se il portafoglio sembra fermo, confronta l’aggiornamento con la transazione e il registro pertinente. Se una quotazione sparisce, esamina il libro corrente. Sono indagini diverse: aggiornare il catalogo non dimostra né un ordine ineseguito né fondi mancanti.
Un relayer aiuta a inviare transazioni, ma non elimina le dipendenze
Un relayer può inviare azioni del wallet supportate, come deploy o autorizzazioni. La documentazione wallet di Polymarket descrive azioni sponsorizzate che permettono all’account di operare senza detenere il token nativo del gas per quelle chiamate. Il gas viene comunque consumato; il costo viene pagato altrove.
Il relayer del wallet e i servizi di abbinamento e regolamento hanno compiti diversi. Contano disponibilità, chiamate supportate e politiche di sponsorizzazione. Non presumere che ogni scambio passi da un relayer del wallet, né che la sponsorizzazione dimostri custodia, autorità di aggiornamento o correttezza dell’oracolo.
La differenza di Kuest: cambia il sito, il percorso può essere condiviso
La guida pubblica all’architettura di Kuest distingue brand e catalogo dell’operatore dall’infrastruttura condivisa di trading. Gli operatori scelgono mercati per il loro pubblico usando servizi comuni compatibili.
L’esecuzione condivisa richiede servizi, rete e asset corrispondenti. Un brand separato non crea né garantisce liquidità.
Due siti con gli stessi servizi e asset Kuest possono mostrare cataloghi diversi e accedere agli stessi ordini. Per l’operatore significa riutilizzare l’infrastruttura di esecuzione mentre cura un’esperienza mirata per il proprio pubblico.
L’operatore presenta il mercato ai trader; un market maker offre proposte di scambio tramite ordini. Questi ruoli sono distinti dai servizi che abbinano e regolano gli scambi. Creare un mercato non procura da solo controparti disponibili o quantità eseguibili.
I servizi condivisi Kuest non fondono il suo libro con Polymarket e una domanda mirror non rende trasferibili i saldi fra le piattaforme.
Le famiglie di contratti spiegano responsabilità, non un inventario completo del deploy. Prima di operare verifica rete effettiva, indirizzi, codice pubblicato, permessi e sistema di posizioni supportato. Un audit del progetto originario non copre automaticamente un altro deploy o modifiche personalizzate.
La verifica utile per l’operatore è concreta: quali asset mostra il sito, quali servizi accettano gli ordini, quali contratti li regolano e quanto sono aggiornati i record mostrati? Un nuovo brand dovrebbe rendere le risposte più facili da trovare.
Vuoi costruire questa esperienza per il tuo pubblico? Crea il tuo mercato predittivo tramite la configurazione guidata di Kuest.