Un mercato predittivo si risolve. La pagina mostra un vincitore. Sei settimane dopo torni a controllare qualcosa, e la pagina mostra ancora un vincitore, ma e lo stesso vincitore che mostrava il giorno della risoluzione? L'esito registrato e mai cambiato? E mai stato contestato? Su quasi ogni piattaforma di mercati predittivi non puoi rispondere a queste domande, perche la risoluzione e un singolo campo modificabile che mostra il valore di oggi e non conserva alcuna memoria del proprio passato. La liquidazione, tra tutte le cose, viene trattata come un fatto senza storia.
CoinRithm aggrega mercati predittivi su piu piattaforme e, da meta 2026, conserva qualcosa che quasi nessuna altra superficie fa: un registro append-only di provenienza della liquidazione, un registro permanente, per evento, di come l'esito di un mercato e stato deciso, rivisto e contestato nel tempo. Questo articolo spiega cos'e quel registro e perche "conservare le ricevute di una risoluzione" sia una promessa diversa, e piu concreta, rispetto alla domanda piu ampia se ci si possa fidare o meno della liquidazione di una piattaforma. Per quel quadro piu ampio, chi decide, su quali prove, quanto e contestabile, leggi ci si puo fidare della liquidazione dei mercati predittivi?; questo articolo riguarda la struttura dati che sta sotto.
TL;DR
- La maggior parte delle piattaforme di mercati predittivi memorizza una risoluzione come un singolo campo modificabile senza storia, cosi un esito cambiato o contestato non lascia traccia.
- CoinRithm registra la liquidazione come registro append-only: ogni osservazione dell'esito risolto e una voce permanente, e le revisioni sostituiscono invece di sovrascrivere.
- Il registro di ogni evento chiuso espone un esito corrente, un conteggio delle osservazioni, un conteggio delle revisioni, un metodo e uno stato di contestazione (non contestato, contestato, o contestazione risolta).
- Poiche le voci non vengono mai eliminate, una risoluzione che in seguito si ribalta e visibile come revisione, non riscritta silenziosamente: il registro mostra l'intero percorso, non solo il punto di arrivo.
- Si affianca ai segnali per evento di idoneita alla liquidazione e di tono di fiducia, cosi la domanda "e stato davvero pagato, in modo verificabile?" trova risposta con un solo sguardo.
- Ambito onesto: il registro copre gli eventi risolti dopo il suo rilascio, e oggi la maggior parte degli eventi mostra una singola decisione pulita e non contestata: il suo valore sta nell'audit trail che conserva per il giorno in cui non sara cosi.
Il problema: una liquidazione senza memoria
Tutto cio che precede la risoluzione ha una qualche nozione di storia. I prezzi si muovono e lasciano un grafico. Il volume si accumula. Gli order book si muovono. Ma il momento che decide davvero chi aveva ragione, la liquidazione, e, sulla maggior parte delle piattaforme, un singolo valore: outcome = Yes. Mostra lo stato attuale e nulla su come ci si sia arrivati. Se e stato registrato una volta e mai piu toccato, va bene. Se e stato registrato, e poi cambiato silenziosamente una settimana dopo in seguito a una contestazione, il campo appare identico in entrambi i casi. L'assenza di storia e il problema: non puoi distinguere una risoluzione pulita e definitiva al primo colpo da una contestata che si e ribaltata, perche la piattaforma ricorda solo l'ultima cosa scritta.
Questo conta piu di quanto sembri a prima vista, perche la liquidazione e esattamente il momento in cui la fiducia viene spesa, non solo promessa. Un mercato puo tradare magnificamente per mesi e poi risolversi in modo ambiguo, tardivo o contestato, e se il registro di quella risoluzione non ha memoria, ti ritrovi a discutere sulla base di screenshot e ricordi su cosa dicesse "in origine" l'esito. Il difetto non e solo che una risoluzione possa essere sbagliata. E che una risoluzione possa cambiare senza lasciare alcuna prova che lo abbia fatto.
I meccanismi con cui le diverse piattaforme arrivano innanzitutto a una risoluzione sono un argomento a se, oracoli, regole di exchange, valutatori, e li trattiamo in come si risolvono i mercati predittivi. Questo articolo riguarda cosa succede a quella risoluzione come dato, una volta che esiste: se viene conservata come un fatto con un passato, o come un campo senza.
Cosa cambia un registro append-only
La soluzione e un'idea ben nota, presa in prestito dalla contabilita e dal controllo di versione: mai sovrascrivere, solo aggiungere. Invece di un singolo campo per l'esito, ogni evento porta un registro di decisioni di liquidazione. Quando l'aggregatore osserva l'esito risolto da un provider, scrive una voce. Se l'esito viene poi rivisto, non modifica la vecchia voce: ne scrive una nuova che sostituisce esplicitamente la precedente, e la precedente viene marcata come superata dalla nuova. Nulla viene eliminato. La catena di "come e stato registrato l'esito, e quando" viene preservata dall'inizio alla fine.
Da questa storia append-only emergono naturalmente alcuni numeri di sintesi onesti, che CoinRithm mostra direttamente sulla pagina dell'evento:
- Esito corrente (Standing outcome): il risultato attualmente in vigore (la voce che nulla ha sostituito), con il timestamp di quando e stato registrato.
- Osservazioni (Observations): quante volte l'esito risolto e stato asserito per questo evento. Una risoluzione stabile accumula conferme; una instabile mostra ricambio.
- Revisioni (Revisions): quante volte l'esito corrente e effettivamente cambiato. Zero e il valore predefinito sano; qualsiasi valore superiore a zero e un segnale che ora puoi vedere, invece di uno tenuto nascosto.
- Metodo (Method): come e stata raggiunta la decisione (per esempio, un passaggio di resolution-watch sui dati del provider), cosi anche la provenienza della provenienza viene registrata.
- Stato di contestazione (Dispute state): se la decisione attuale e non contestata, contestata, o una contestazione risolta, mostrato come badge esplicito invece di essere lasciato all'inferenza.
Nessuno di questi elementi richiede di fidarsi di una narrazione. Vengono calcolati a partire da un registro che non puo essere riscritto silenziosamente, e quando nella storia c'e piu di una decisione, la pagina dell'evento mostra l'intera timeline: ogni esito registrato, il suo momento, il suo stato di contestazione, e se sia la voce corrente in vigore o una gia sostituita.
Leggere il registro sulla pagina di un evento
Su un evento chiuso che ha un registro registrato, la sezione di provenienza della liquidazione e compatta e diretta. Inizia con l'esito corrente e il momento in cui e stato registrato, poi mostra i conteggi di osservazioni e revisioni e il metodo, con un badge di contestazione se la decisione attuale e o e stata contestata. Se l'esito e mai stato rivisto, sotto compare un breve elenco storico, che percorre le decisioni in ordine e segna ciascuna come corrente o sostituita.
Il caso di tutti i giorni, onestamente, e poco drammatico: un'osservazione, zero revisioni, non contestato: un mercato risolto in modo pulito, una sola volta, come dovrebbe essere. Questo non e un punto debole della funzionalita; e cio che ha l'aspetto di una risoluzione sana, e mostrarlo chiaramente e proprio il punto. Il valore e asimmetrico. Quando la risoluzione procede senza intoppi, il registro e una conferma silenziosa. Quando non e cosi, una correzione tardiva, una decisione contestata, un esito che si ribalta, il registro e l'unica cosa che ti separa da una liquidazione che non puoi ricostruire. Si conservano le ricevute proprio perche il raro giorno storto sia verificabile, invece che affidato alla memoria.
Come si collega alle decisioni degli agenti
Il registro di liquidazione non e una funzionalita isolata. E l'ancora, sul lato risoluzione, di un livello di valutazione piu ampio e deliberatamente verificabile. Quando un agente IA di CoinRithm Arena assume una posizione su un mercato, quella decisione viene registrata come artefatto immutabile e sottoposto a hash, il tema di come verificare lo storico di un agente IA. Quando in seguito il mercato si liquida, l'artefatto dell'agente riceve un timbro di liquidazione che rimanda esattamente a questo registro. Cosi l'intera catena e verificabile dall'inizio alla fine: cosa ha deciso l'agente e quando (con impronta digitale), e come e stato infine risolto l'evento su cui ha scommesso (append-only). Nessuna delle due meta si fida ciecamente dell'altra; entrambe conservano il proprio registro a prova di manomissione.
Questo chiude un anello che la maggior parte delle classifiche di agenti lascia aperto. Una vittoria ha senso solo se la liquidazione che c'e dietro e reale e invariata, e qui la liquidazione dietro la vittoria di un agente e una voce di registro con una storia, non un campo modificabile che qualcuno avrebbe potuto ribaltare a posteriori.
Come si colloca rispetto a idoneita e tono di fiducia
La provenienza risponde a "cosa e stato registrato, ed e cambiato". Due segnali vicini rispondono alle domande strettamente correlate "questo esito e abbastanza affidabile da poterci valutare" e "e stato pagato in modo verificabile", e CoinRithm li mantiene distinti di proposito:
- Idoneita alla liquidazione (Settlement eligibility). Ogni evento attraversa un ciclo di vita definito, aperto, chiuso, in attesa di risoluzione, risolto, e porta flag su se il suo esito e la tempistica di liquidazione sono verificati dal provider, e se e idoneo a contare ai fini della calibrazione. Un mercato il cui registro dice "risolto, non contestato, verificato dal provider" e un mercato il cui risultato e abbastanza affidabile da poter valutare un agente o una piattaforma. Questo vincolo di idoneita e la spina dorsale del nostro lavoro onesto sull'accuratezza in quanto sono accurati i mercati predittivi.
- Tono di fiducia per evento (Per-event trust tone). Accanto al registro, le pagine degli eventi mostrano un tono di fiducia sulla risoluzione, verificato, limitato, in attesa, o non verificato, che dichiara chiaramente cosa CoinRithm puo effettivamente confermare su una liquidazione, invece di cosa dichiara una piattaforma. Questa etichettatura e trattata nel framework di fiducia, e il registro di provenienza e la prova concreta sotto quell'etichetta.
Messi insieme: il tono di fiducia ti dice il livello di certezza, i flag di idoneita ti dicono se si puo valutare, e il registro di provenienza ti mostra il registro sottostante da cui questi giudizi vengono calcolati. Livelli, non un vago "risolto" unico.
I limiti onesti
Questa e una struttura dati reale e in funzione, ed e anche giovane: vale la pena essere diretti su entrambi gli aspetti.
Primo, l'ambito. Il registro documenta le risoluzioni dei provider a partire dal momento in cui la funzionalita e stata rilasciata in avanti; gli eventi risolti prima che esistesse non hanno un registro, e la pagina dell'evento omette semplicemente la sezione, invece di inventare una storia retroattiva. Non si finge che un mercato di tre mesi fa abbia un audit trail che non ha mai avuto. L'affermazione onesta e "da qui in poi", non "sempre".
Secondo, il registro registra osservazioni, non un giudizio. CoinRithm non risolve i mercati, non valuta gli esiti e non arbitra le contestazioni: osserva cio che i provider riportano e conserva un registro append-only, a prova di manomissione, di quelle osservazioni. Se una piattaforma stessa prende una decisione sbagliata, il registro registrera fedelmente quella decisione ed eventuali correzioni successive; cio che garantisce e che il registro non possa essere riscritto silenziosamente, non che la risoluzione sottostante fosse corretta. Questa distinzione e la stessa che attraversa tutto il framework di fiducia nella liquidazione: un'informazione migliore riduce le sorprese, ma nessun registro puo costringere una piattaforma ad aver deciso correttamente. Cio che puo fare, e fa, e assicurarsi che qualsiasi cosa sia stata decisa venga ricordata onestamente, per intero, e da piu di una sola memoria di parte.
FAQ
Cos'e la provenienza della liquidazione in un mercato predittivo?
E la storia registrata di come e stato deciso l'esito di un mercato, non solo il risultato finale, ma ogni osservazione di quel risultato, eventuali revisioni, il metodo utilizzato e se sia stato contestato. CoinRithm la conserva come registro append-only per ogni evento chiuso, cosi una risoluzione viene memorizzata come un fatto con un passato, invece che come un singolo campo modificabile che dimentica come sia arrivato al suo valore attuale.
In cosa differisce un registro di liquidazione append-only da un normale campo di risoluzione?
Un normale campo di risoluzione mostra solo il proprio valore attuale; se l'esito cambia, il vecchio valore viene sovrascritto e scompare. Un registro append-only non sovrascrive mai: un esito rivisto viene scritto come una nuova voce che sostituisce la precedente, e nulla viene eliminato. Questo significa che una risoluzione che in seguito si ribalta e visibile nel registro come revisione, invece di svanire senza lasciare traccia.
Cosa significano "osservazioni" e "revisioni" nel registro?
Le osservazioni contano quante volte l'esito risolto e stato asserito per un evento: conferme ripetute di un risultato stabile. Le revisioni contano quante volte l'esito corrente e effettivamente cambiato. Una risoluzione pulita mostra tipicamente diverse osservazioni e zero revisioni; un conteggio di revisioni diverso da zero e un segnale che l'esito registrato si e mosso, e il registro lo rende visibile invece di nasconderlo.
Il registro di liquidazione significa che CoinRithm risolve i mercati?
No. CoinRithm non decide, non valuta e non arbitra gli esiti: osserva cio che il provider di ciascuna piattaforma riporta e registra quelle osservazioni in un registro append-only, a prova di manomissione. Se una piattaforma prende una decisione e poi la corregge, il registro documenta fedelmente entrambe. Garantisce l'onesta del registro, non la correttezza della decisione sottostante della piattaforma.
Perche la maggior parte degli eventi mostra una sola decisione non contestata?
Perche la maggior parte delle risoluzioni e pulita: l'esito viene registrato una volta, dai dati del provider, e non cambia mai. Un'unica osservazione non contestata con zero revisioni e esattamente l'aspetto di una liquidazione sana. Il valore del registro e asimmetrico: e una conferma silenziosa nei giorni normali, e l'unico audit trail affidabile nel raro giorno in cui una risoluzione e tardiva, corretta o contestata.
Ogni evento di mercato predittivo su CoinRithm ha un registro di provenienza?
Non ancora. Il registro copre gli eventi risolti dopo il rilascio della funzionalita a meta 2026; gli eventi risolti prima semplicemente non mostrano la sezione, invece di presentare una storia fabbricata. Con il tempo, man mano che altri mercati si risolvono, la copertura cresce, e il registro e onesto sul confine, invece di riempire retroattivamente una traccia che non e mai esistita.
