«Raggiungerà 30 gradi?» lascia spazio a scambi diversi. La previsione arrotondata di un’app, la misura di una stazione e un rapporto ufficiale successivo possono divergere. Prima che qualcuno compri YES o NO, il mercato deve stabilire quale determini il pagamento.
Il sesto articolo di Come funzionano Polymarket e Kuest rende la domanda verificabile e ne segue le prove attraverso i livelli distinti del sistema. Una pagina leggibile, i byte di risoluzione fissati e un documento di metadati accessibile dimostrano cose diverse.
Riscrivi la domanda finché due lettori ottengono la stessa risposta
Manteniamo osservatorio A, città B e data C immaginari. «Alle 12:00» deve indicare l’osservazione o il termine di pubblicazione: sono eventi diversi. Riscrivi il titolo: «L’osservazione dell’osservatorio A per la città B alle 12:00 UTC della data C sarà almeno 30,0 °C?» Poi specifica le prove:
Usa il CSV ufficiale delle osservazioni giornaliere dell’osservatorio A, stazione B-01, per la data C. Leggi il campo della temperatura dell’aria in gradi Celsius del record con timestamp 12:00:00 UTC. Usa l’ultima revisione ufficiale disponibile entro le 13:00:00 UTC della data C, inclusa una pubblicata esattamente al termine. Confronta direttamente il valore numerico pubblicato con 30,0, senza arrotondarlo di nuovo. Un valore valido pari o superiore a 30,0 significa YES; uno inferiore NO. Ignora previsioni, altre stazioni e revisioni successive. Se al termine il record è ritirato, record discordanti non hanno un ordine autorevole di revisione o manca un record valido, usa l’esito previsto per dati non disponibili.
In un mercato reale sostituisci ogni nome e data fittizi con URL preciso della fonte, ID della stazione, data e definizione del campo. «Sito ufficiale» lascia ai lettori la scelta tra pagine, mirror e revisioni. Anche una fonte di riserva richiede una priorità dichiarata, altrimenti aggiunge una scelta dopo che il risultato è noto.
Qui 29,96 significa NO anche se un’app mostra 30,0. Una correzione da 29,9 a 30,1 prima del termine significa YES; la stessa correzione dopo non cambia l’osservazione selezionata. L’uguaglianza è esplicitamente YES, quindi la soglia non lascia un pareggio irrisolto.
L’ora dell’osservazione seleziona il record, il termine la revisione, la politica di pagamento gestisce le prove mancanti.
L’esito per dati non disponibili deve corrispondere al percorso contrattuale scelto. Per l’esempio supponiamo un adapter binario standard che supporti UNKNOWN: con YES paga un’unità il token YES e zero NO, con NO l’inverso, con UNKNOWN metà ciascuno. È un’ipotesi esplicita, non una regola universale di cancellazione o una politica NegRisk.
Mezza unità per token non rimborsa il prezzo d’acquisto. Chi ha pagato 0,80 per YES riceve 0,50 nell’esito ipotizzato. Le meccaniche di divisione e riscatto determinano il pagamento; le regole stabiliscono quale risultato supportato riportare.
Termine della fonte, fine trading e risoluzione hanno scopi diversi. Il primo seleziona prove, il secondo controlla l’ammissione degli ordini, la terza registra il risultato. Gli ordini potrebbero fermarsi alle 11:55 UTC mentre le revisioni restano ammesse fino alle 13:00; la risoluzione segue dopo. L’operatore configura il trading separatamente e una transazione in ritardo non estende il termine delle prove.
Segui due tipi di prove
Un mercato richiede una domanda di risoluzione definita e informazioni di supporto leggibili. Gli ancillary data sono byte aggiuntivi della domanda usati da una specifica integrazione oracolo; i metadati descrittivi possono includere immagini, etichette e link. Hanno scopi diversi e non sono impegni intercambiabili.
L’adapter CTF pubblico di Polymarket è un esempio di dati della domanda registrati secondo una codifica precisa. Ricalcolare l’impegno richiede quella codifica, non un paragrafo visivamente simile. Controlla l’interfaccia pubblicata del deploy scelto senza generalizzare a ogni famiglia di adapter.
L’impegno della domanda e un documento esterno sostengono controlli diversi; un riferimento da solo non dimostra integrità o disponibilità.
Il contratto Conditional Tokens di Kuest verificato pubblicamente registra creatore e riferimento esterno ai metadati. Un riferimento localizza informazioni, ma non dimostra che il documento sia disponibile, immutabile o identico all’impegno di risoluzione originario. Recupera i documenti e confrontali con le prove registrate.
La documentazione pubblica di creazione mercati Kuest descrive l’interfaccia supportata. Documento caricato, condizione preparata e mercato negoziabile sono osservazioni separate. Conferma i record appropriati senza dedurre tutti e tre da una schermata riuscita.
Identificatori simili svolgono compiti diversi
Uno slug localizza una pagina. Un ID domanda identifica la domanda secondo lo schema dell’adapter. Un ID condizione combina oracolo, domanda e numero degli esiti nella costruzione pubblica CTF. Gli input esatti contano: un testo simile non prova condizioni identiche.
Un ID posizione identifica l’asset detenuto e scambiato. In CTF dipende anche da collaterale e collezione che rappresenta gli esiti. Titoli o slug uguali non stabiliscono asset identici. Il creatore registra attribuzione e certi permessi; l’identificatore esterno localizza contenuti descrittivi. Nessuno sostituisce ID di condizione o posizione.
Persino «ID domanda» non è una codifica universale. Nella specifica NegRiskIdLib di Polymarket, la domanda condivide i primi 31 byte dell’ID del mercato e usa l’ultimo per l’indice della domanda. Applica questa regola solo a quella famiglia, non a ogni domanda oracolo.
Il campo metadata in un ordine firmato è un altro oggetto. Per esempio la definizione pubblica CTF Exchange V2 include un bytes32 metadata a livello ordine. La presenza non prova che la firma fissi il documento mostrato dal mercato.
Un aggiornamento tracciabile resta un aggiornamento
L’estensione Conditional Tokens di Kuest registra creatore e riferimento esterno corrente. Il creatore o un amministratore CTF può sostituirlo. Ogni chiamata riuscita incrementa un contatore ed emette ID della condizione, vecchio riferimento, nuovo riferimento e indirizzo di chi aggiorna.
La funzione esaminata non congela gli aggiornamenti alla risoluzione e non verifica che la nuova stringa punti a contenuti disponibili e non vuoti. Un ID condizione invariato non significa quindi una descrizione mai modificata. Un aggiornamento può aggiungere una fonte o correggere un’immagine: confronta i documenti prima di decidere se la proposizione è cambiata.
Aggiornare il riferimento può arricchire il documento o cambiarne la descrizione. L’evento rivela chi ha modificato il puntatore; confronta i contenuti.
Cambiare il puntatore non riscrive i byte originali della domanda e non concede un nuovo diritto di riportare pagamenti. La funzione di segnalazione CTF deriva la condizione usando il chiamante come oracolo. Adapter e percorso configurato governano come il risultato raggiunge la funzione; modificare metadati è un potere distinto.
Supponi che la versione A dica 30,0 °C e la B 31,0 °C. Un evento storico rende visibile la sostituzione, ma non dimostra che 31,0 sia diventata la soglia legittima. Confrontale entrambe con i byte ancillary originali e la politica applicabile prima di interpretare il cambiamento.
I chiarimenti richiedono autore e politica
Polymarket ha già impegni delle domande on-chain. La versione fissata dell’adapter UMA CTF calcola l’hash e memorizza ancillary data ampliati; la bacheca registra aggiornamenti attribuiti. Sono meccanismi specifici di adapter CTF, non un’affermazione sull’ABI di ogni percorso attuale.
Un chiarimento richiede anche autore identificabile e politica applicabile. Nell’esempio pubblico, un post attribuito non riscrive gli ancillary data originali. Non trattare una dichiarazione qualsiasi che menzioni la domanda come una modifica ufficiale.
La documentazione attuale di risoluzione Polymarket dice che il contesto dei chiarimenti deve preservare l’intento fondamentale. Identificare una colonna CSV rinominata può chiarire le prove; sostituire 30,0 con 31,0 cambia la proposizione. Un timestamp prova quando è registrata una dichiarazione, non la sua autorità legittima.
Verifica il percorso dal riferimento allo schermo
Una revisione pratica segue le prove in ordine:
- Identifica il deploy. Registra rete, indirizzi, famiglia dell’adapter e riferimento a un blocco. Ottieni ricevuta di creazione, byte originali, identità dell’oracolo, creatore e ID condizione.
- Ricalcola gli identificatori corretti. Usa codifica, trattamento dell’inizializzazione e numero degli esiti di quell’implementazione. Verifica le posizioni contro collaterale e mappatura effettivi.
- Segui la storia dei metadati. Leggi riferimento iniziale, corrente, contatore e log. Recupera documenti originari e sostitutivi, poi confronta cambiamenti e autori.
- Verifica separatamente integrità e disponibilità. Valida i contenuti con lo schema effettivo di transazione o impegno dello storage. Conserva byte esatti e provenienza: un riferimento registrato non serve un documento irrecuperabile.
- Confronta cosa vedono i partecipanti. Abbina fonte, date, regole ed etichette mostrate ai dati originali di risoluzione e al contesto autorizzato. Un’interfaccia leggibile non è una verifica indipendente di integrità.
Documento raggiungibile, provenienza valida e visualizzazione corrispondente sono controlli separati. Nessuno da solo dimostra la corretta risoluzione.
Per l’operatore, l’aggiunta concreta di Kuest è riferimenti ai metadati legati al creatore e cronologia visibile accanto ai dati di risoluzione originali. Favorisce un catalogo verificabile e pubblicazioni attribuibili, ma non mette tutte le informazioni on-chain, non garantisce documenti disponibili e non decide controversie sul significato.
Lancia il tuo mercato predittivo con Kuest portando pubblico e giurisdizioni definiti, regole provate, politiche su fonti e correzioni, risoluzione supportata e un piano per conservare prove accessibili. Testa gli input su casi ambigui prima di accettare scambi.