Firmare un ordine autorizza uno scambio a condizioni specifiche. Non significa che lo scambio sia avvenuto. L’API può accettarlo, il libro abbinarne una parte e la transazione di regolamento può comunque fallire.
Il quinto articolo di Come funzionano Polymarket e Kuest segue l’autorizzazione dietro i libri YES e NO collegati. Attraversiamo i livelli distinti del sistema: cosa firma il partecipante, cosa applica il servizio di abbinamento e cosa registra davvero la blockchain.
Parti dall’istruzione, poi segui gli asset
Manteniamo la domanda ipotetica: «L’osservatorio A pubblicherà almeno 30,0 °C per la città B alle 12:00 UTC della data C?» Comprare YES significa acquisire l’asset di esito specificato; firmare un BUY ne autorizza soltanto l’acquisizione.
Usiamo un mercato binario standard Conditional Tokens Framework (CTF) e unità generiche di collaterale. Gli esempi assumono sei decimali, fondi e permessi sufficienti e nessun costo di gas o finanziamento; le commissioni sono separate dove indicate.
Le spiegazioni usano standard pubblici di firma, esempi pubblici CTF Exchange e movimenti ipotetici. Wallet, tipi di ordine e commissioni specifici devono provenire dalla documentazione pubblica attuale della piattaforma.
Tre autorizzazioni svolgono compiti diversi
Una firma dell’ordine autorizza una specifica istruzione di scambio. L’autenticazione API identifica un richiedente autorizzato presso il servizio. La firma di un batch del wallet autorizza un insieme separato di chiamate, come impostare un’autorizzazione di spesa.
Una credenziale API identifica un richiedente autorizzato al servizio; non è la chiave privata del partecipante e non sostituisce la firma dell’ordine. La guida pubblica a wallet e autenticazione di Polymarket offre un esempio documentato.
Oggetti separati, controlli separati. Il batch del wallet ha nonce e scadenza propri; quei campi non diventano parte dell’ordine di scambio.
EIP-712 definisce hash e firma di messaggi strutturati. Il dominio può legare un’istruzione a catena, nome dell’applicazione, versione e contratto verificatore, impedendo che una firma destinata a un dominio risulti valida in un altro.
Il codice pubblico di firma CTF Exchange V2 illustra un dominio EIP-712 specifico. Nome e versione appartengono al contesto firmato; non provano che un’altra piattaforma accetti lo stesso messaggio. I limiti al riutilizzo dipendono anche da stato e regole del contratto effettivo.
Gli importi contengono il prezzo
Nella definizione pubblica degli ordini CTF Exchange V2, l’istruzione firmata include token, lato, importi maker e taker e identità degli account, tra gli altri campi. La firma autorizza quel messaggio, non qualsiasi prezzo mostrato dall’interfaccia in seguito.
Qui maker indica l’account che fornisce asset, anche quando l’ordine prende subito liquidità. Il nome del campo differisce dal ruolo di maker, cioè un ordine che resta nel libro prima che un altro vi scambi contro.
Per BUY, makerAmount è il collaterale offerto e takerAmount le quote richieste. Offrire 60 per 100 YES codifica un limite 60 ÷ 100 = 0,60; per SELL che offre 100 YES per 60, il prezzo è invece takerAmount ÷ makerAmount.
Non c’è un campo prezzo firmato indipendente che prevalga sul rapporto. Cambiare il prezzo mostrato senza ricostruire e firmare gli importi corrispondenti non modifica le condizioni autorizzate.
Un timestamp può indicare quando è stato creato l’ordine senza essere una scadenza applicabile. L’integrazione deve distinguere campi firmati e istruzioni al servizio, verificandone il significato nella specifica pubblica attuale.
La validazione decide se l’ordine entra nel libro
Prima di inviare, verifica asset, limite di prezzo, quantità, account e tipo supportato. Controlli del client e conferma API non sostituiscono il regolamento riuscito nel contratto.
Il tick è l’incremento consentito fra prezzi. Controlla le specifiche pubblicate del mercato prima di firmare. Verifica del client, risposta del servizio e regola contrattuale dimostrano cose diverse; un minimo mostrato non prova da solo un vincolo on-chain.
Fondi e permessi sono controlli distinti: BUY richiede collaterale utilizzabile e autorizzazione di spesa sufficiente al contratto di regolamento; SELL richiede token e permesso di trasferimento. La firma da sola non fornisce nessuno dei due, e una verifica all’ammissione non congela ogni cambiamento successivo dell’account.
Post-only indica l’intenzione di aggiungere un ordine al libro anziché prendere subito liquidità. Controlla combinazioni e comportamenti di rifiuto documentati; l’etichetta non definisce ogni implementazione.
La validità temporale indica al servizio come trattare la quantità ineseguita:
- GTC — valido fino a cancellazione: lascia nel libro il residuo ammissibile.
- GTD — valido fino a una data: consenti che resti fino alla scadenza indicata.
- FAK — fill and kill: esegui subito il disponibile ed elimina il resto.
- FOK — fill or kill: richiedi l’eseguibilità dell’intera quantità oppure non eseguire nulla.
Un ordine del servizio con scadenza e un termine contrattuale firmato sono impegni diversi. Verifica dove venga applicata la scadenza e cosa accada alle transazioni già inviate. Un campo nella richiesta non dimostra di per sé una garanzia del contratto.
Un abbinamento richiede ancora un regolamento riuscito
Considera queste tappe didattiche: firmato → accettato/nel libro → abbinato → inviato → confermato. Un ordine può essere rifiutato prima dell’ammissione; un ordine accettato può generare più abbinamenti parziali e transazioni. Le etichette spiegano responsabilità, non un’enumerazione API universale.
Un abbinamento parziale lascia quantità per il futuro se la validità temporale lo consente. Un regolamento fallito richiede riconciliazione prima di riprovare.
Il contratto pubblico CTF Exchange V2 illustra abbinamento autorizzato e controlli prima di muovere asset. Gli esempi diretto, creazione e fusione dell’Articolo 4 spiegano movimenti possibili e fondi richiesti.
La transazione è atomica: se un trasferimento o controllo richiesto va in revert, le sue modifiche di stato vengono annullate. Non annulla un’altra transazione già riuscita, e una transazione annullata può comunque consumare gas.
Un hash identifica una transazione inviata, non un acquisto riuscito. Controlla ricevuta e conferme richieste dalla rete. Finché l’esito è incerto, l’interfaccia dovrebbe conservarne l’incertezza invece di dichiarare asset consegnati.
Nell’interfaccia dell’operatore conserva separati ID dell’ordine, quantità abbinata e riferimento della transazione. Se fallisce o resta incerta, riconcilia l’esito reale prima di riprovare; cambiare un’etichetta locale non sposta asset.
Le esecuzioni parziali consumano l’asset offerto
Supponi che un BUY nel libro offra 60 di collaterale per 100 YES, e il primo eseguito riceva 40 YES esattamente a 0,60. Senza commissioni consuma 24 di collaterale, lasciando 36 di capacità firmata in collaterale, equivalenti a 60 YES allo stesso prezzo.
Un SELL che offre 100 YES per 60 di collaterale consuma 40 YES e riceve 24. L’importo maker residuo è 60 quote, non 36 di collaterale. Entrambi hanno 60 YES ancora da negoziare, ma i contatori on-chain usano asset differenti.
Stesso eseguito di 40 quote, unità diverse nei contatori. Prezzo esattamente al limite, commissioni escluse.
L’aritmetica pubblica CTF Exchange V2 usa unità base intere. Nel modello proporzionale con arrotondamento per difetto usato qui, l’importo ricevuto è quello fornito × importo taker firmato ÷ importo maker firmato, arrotondato per difetto. La riconciliazione esatta richiede le regole del percorso reale.
Per esempio, vendere 1,000001 quote da un ordine firmato di 3 quote per 1,8 di collaterale calcola 1 000 001 × 1 800 000 ÷ 3 000 000, arrotondando a 600 000 unità base. Piccoli eseguiti e commissioni richiedono quindi le regole dell’implementazione; moltiplicare prezzi visualizzati arrotondati non basta.
Le commissioni hanno una contabilità propria
Supponi un acquisto diretto di 100 YES per 60 e una commissione ipotetica di 0,60 per partecipante. Al compratore servono 60,60 di collaterale; il venditore riceve 59,40. I restanti 1,20 sono commissioni totali, così tutto il denaro del compratore è riconciliato.
Commissioni ipotetiche, non tariffe attuali. Uscita 60,60 = incasso venditore 59,40 + commissioni 1,20; 100 token YES esistenti passano al compratore.
Nell’esempio esplicito, la commissione BUY si aggiunge ai fondi richiesti e quella SELL si sottrae all’incasso. Costi effettivi, destinatari e arrotondamento vanno controllati per piattaforma e percorso scelti; l’esempio non è un tariffario.
La cancellazione ha un confine
Rimuovere un ordine aperto riguarda la quantità residua ineseguita. Non annulla gli eseguiti completati. Tratta conferma di cancellazione e transazione di regolamento pendente come record separati; controlla entrambi prima di riutilizzare i fondi.
Se il regolamento è già inviato, cancellare dopo nel libro non promette di fermarlo. Verifica l’esito prima di considerare disponibili gli asset, soprattutto con un ordine originario parzialmente eseguito.
Cancellare il residuo e regolare un abbinamento precedente possono avvenire entrambi. Nessuna protezione ritardata annulla una transazione riuscita.
Una restrizione più ampia dell’account non equivale a cancellare un ordine. I controlli di recupero hanno ambiti, ritardi e autorità diversi. Usa documentazione pubblica di contratti e prodotto per l’account effettivo, senza presumere che ogni controllo sia un arresto immediato.
Deposit Wallet ha un periodo separato di pausa e attesa d’emergenza prima di prelievi d’emergenza o revoche. Nel codice citato, la pausa da sola non disabilita esecuzione dei batch o verifica della firma: non è un arresto istantaneo del trading.
I nomi delle versioni non definiscono un’integrazione
Il vecchio ordine CTF di Polymarket firmava taker, expiration, nonce e feeRateBps. Il distinto ordine CTF Exchange V2 li rimuove e aggiunge timestamp, metadata e builder; il prezzo resta un rapporto di importi.
Il repository V2 rimuove anche fillOrder/fillOrders, mantenendo l’abbinamento dell’operatore tramite matchOrders. Questo CTF Exchange V2 è distinto dall’architettura di posizioni Protocol V2 in polymarket-v2-external; Kuest non eredita automaticamente gli aggiornamenti di nessuno dei due repository.
L’assenza di expiration nella struttura del contratto non significa che il prodotto non offra ordini a scadenza. La documentazione attuale sul ciclo degli ordini descrive GTD a livello prodotto, e la guida alle posizioni distingue registri CTF e Protocol V2. Verifica il percorso del mercato reale prima di integrare.
Cosa dovrebbe dichiarare un operatore Kuest
La guida pubblica Kuest per gli operatori separa applicazione e servizi condivisi. Dichiara ai partecipanti percorso account supportato, stima completa delle commissioni e stati distinti di accettazione, abbinamento e conferma: requisiti osservabili del prodotto, non dettagli interni.
La documentazione pubblica delle commissioni Kuest descrive la partecipazione dell’operatore e la condivisione configurabile con affiliati. Allocare una commissione è diverso da aggiungere un costo sul nozionale. Spiega il pagamento del partecipante usando configurazione pubblica corrente e record di regolamento.
Per l’operatore è una decisione concreta di integrazione: conserva l’identità builder corretta, mostra il costo totale effettivo e riconcilia l’allocazione con i record. Un codice identificativo o frontend con brand da soli non garantiscono ammissione, diritto a commissioni o ricavi.
Lancia il tuo mercato predittivo con Kuest con una politica comprensibile: giurisdizioni del pubblico, regole precise e risoluzione, quantità richieste, percorso wallet supportato, commissioni e stati di accettazione, abbinamento e conferma separati.