Un bot di arbitraggio dei contratti su eventi deve gestire il periodo in cui una combinazione proposta è solo parzialmente reale. Uno scanner può identificare prezzi che sembrano attraenti insieme, ma un conto riceve singoli ordini ed esecuzioni. Un ordine può essere accettato mentre un altro viene rifiutato. Un annullamento può arrivare dopo un'ulteriore esecuzione. Una risposta può scomparire anche se la sede ha accettato la richiesta. Il bot deve descrivere tali stati senza fingere che la coppia prevista esista già.
Il problema progettuale centrale è il coordinamento nell'incertezza. Riserva la capacità necessaria per entrambe le gambe, conservane le identità e misura l'esposizione residua quando non procedono insieme. Gli esempi fittizi qui usano pagamenti binari da un dollaro esplicitamente compatibili. Illustrano controlli di esecuzione, non affermano che una reale operazione tra sedi possa essere completata atomicamente o che un arbitraggio apparente non abbia rischi.
Le riserve del bot di arbitraggio partono da una coppia approvata
Il motore di esecuzione dovrebbe ricevere una definizione esaminata della coppia anziché due nomi di mercato vagamente collegati. Tale definizione include contesto di ogni sede, identificatore del contratto, lato dell'esito, versione delle regole e relazione tra pagamenti. Dovrebbe anche dichiarare quali esiti eccezionali siano stati considerati e quali condizioni invalidino la corrispondenza. Una coppia di contratti il cui significato resta irrisolto appartiene alla ricerca, non alla coda pronta dell'esecutore.
L'istruzione candidata aggiunge quantità attuali, tetti di prezzo, stime delle commissioni e orari di osservazione. Indica il costo combinato massimo accettabile e la quantità di esposizione non abbinata che il conto è disposto a tollerare. Questi limiti sono distinti. Una coppia può essere sostenibile se completata mentre la prima gamba crea un'esposizione direzionale temporanea eccessiva per il conto. Entrambe le domande richiedono risposta prima dell'invio di qualsiasi ordine.
Usa un identificatore persistente del caso per collegare definizione, raccomandazione, autorizzazione e ordini finali. Ogni gamba dovrebbe avere anche una propria identità stabile dell'istruzione. L'identificatore della coppia spiega perché gli ordini appartengano insieme; quelli delle gambe permettono al sistema di indagare un singolo invio. Nessuno dovrebbe essere sostituito soltanto perché una richiesta di rete va in timeout o un processo si riavvia.
Il precedente articolo sul bot di arbitraggio dei mercati predittivi fornisce la relazione più ampia tra un'opportunità rilevata e un processo di trading. Questo disegno parte dal punto in cui l'analisi dei pagamenti è già stata esaminata. Il suo compito è assicurare che la combinazione effettiva del conto resti visibile mentre gli ordini attraversano stati diversi.
Riserva fondi locali e capacità di rischio condivisa
Supponiamo che una coppia fittizia richieda 500 unità di A Sì a un massimo di $0,37 e 500 unità di B No a un massimo di $0,60. Presumiamo che le regole rendano un'unità di ciascuno un pagamento combinato di un dollaro negli esiti modellati. Gli importi di acquisto totalizzerebbero $185 e $300. Con commissioni ipotetiche di $3 e $4, il costo totale di acquisizione è $492, lasciando $8 sotto il pagamento ipotizzato di $500.
Il bot necessita di $188 disponibili per A e $304 per B secondo tali ipotesi. Se le gambe usano conti separati, l'esistenza di $492 da qualche parte nel portafoglio complessivo non basta. Ogni conto necessita della propria capacità utilizzabile prima dell'esecuzione. La riserva dovrebbe includere gli oneri appropriati e ogni margine aggiuntivo di recupero scelto dall'operatore. Il margine è una politica di controllo, non parte del profitto previsto salvo che venga effettivamente speso.
A livello di portafoglio, riserva l'esposizione pertinente all'evento oltre al denaro. Più coppie candidate possono dipendere tutte dallo stesso evento o dalla stessa sede della seconda gamba. Permettere a ogni caso di riservare fondi indipendentemente senza controllare limiti condivisi può creare un accumulo eccessivo di prime gambe incompiute. Un servizio comune del rischio o un altro metodo coerente di coordinamento deve impedire che tali casi rivendichino la stessa capacità residua.
Le riserve dovrebbero persistere nell'incertezza. Un ordine rifiutato con conferma autorevole può liberare l'importo inutilizzato. Un ordine la cui risposta manca non può. Un riavvio del processo dovrebbe ricaricare le riserve irrisolte prima di accettare nuovi casi. Altrimenti il programma può sembrare avere un budget nuovo mentre i conti contengono ancora impegni creati nella sessione precedente.
Scegli deliberatamente una sequenza di esecuzione
Inviare entrambe le gambe quasi contemporaneamente riduce alcuni ritardi di sequenza, ma non garantisce accettazione o esecuzione simultanee. Inviare prima una gamba può semplificare il coordinamento, ma crea un periodo di esposizione direzionale nota. Un sistema dovrebbe scegliere la sequenza in base a liquidità osservata, comportamento delle sedi ed esposizione consentita del conto, poi valutare i risultati di tale scelta anziché trattarla come un dettaglio implementativo.
Una tentazione comune è eseguire prima la gamba più difficile. Può essere ragionevole per un flusso verificato, ma necessita comunque di una risposta definita se la gamba più facile scompare. Un altro approccio usa un ordine in attesa nel libro per un lato e reagisce alle sue esecuzioni. Ciò può migliorare il prezzo quotato di ingresso aumentando però la possibilità che il prezzo complementare cambi prima della risposta. La misura pertinente è la combinazione completata e i suoi casi incompiuti.
Le istruzioni di esecuzione di un singolo ordine non creano una transazione tra sedi. Per esempio, un'istruzione tutto o niente può vincolare una gamba in una sede che la supporta, ma non costringe un'altra sede a eseguire il proprio ordine corrispondente. La documentazione sul ciclo di vita degli ordini di Polymarket descrive diversi comportamenti dei singoli ordini. Il bot deve verificare il comportamento effettivamente supportato per ogni gamba ed evitare di estendere una garanzia locale all'intera coppia.
Documenta la sequenza scelta nel registro del caso. Registra quando sia stata creata ogni autorizzazione, quando sia stata inviata ogni richiesta e quali informazioni fossero disponibili prima del secondo invio. Queste evidenze permettono confronti successivi delle politiche di sequenza. Senza di esse, una coppia riuscita può nascondere la stessa debolezza temporale che causa una costosa esecuzione parziale nel caso successivo.
Segui le quantità in ogni fase
Per ogni gamba, distingui quantità richieste, accettate, eseguite, annullate e ancora incerte. Questi numeri rispondono a domande diverse. La quantità richiesta esprime l'intento. Quella eseguita stabilisce una posizione. Quella aperta può ancora aumentare tale posizione. La quantità incerta rappresenta esposizione non ancora risolta dal sistema locale. Combinarle in un'unica percentuale di completamento può nascondere direzione e dimensione del rischio residuo.
Una quantità abbinata è quella per cui le posizioni richieste sono state effettivamente acquisite in proporzioni compatibili. Nel semplice esempio uno a uno, se A ha 500 eseguiti e B ne ha 300, la quantità abbinata è 300 e quella A non abbinata è 200. Se un pagamento più complesso richiede un rapporto diverso, il calcolo dell'abbinamento deve seguire quel rapporto esaminato anziché presumere uguaglianza.
Mantieni il calcolo delle quantità indipendente dai saldi monetari. Una variazione del saldo può includere commissioni, trasferimenti o operazioni estranee, quindi è un sostituto debole dei registri delle esecuzioni. Memorizza identificatore, lato, quantità e prezzo di ogni esecuzione e deduplica le consegne ripetute della stessa. Un evento riprodotto dovrebbe confermare informazioni esistenti anziché creare una seconda voce di posizione.
La precedente guida al bot di arbitraggio Kalshi può aiutare a inquadrare i registri del conto per un'implementazione specifica della sede. La regola generale è che il completamento della coppia deve derivare dalle quantità effettive delle gambe. Una quotazione combinata positiva, un gruppo inviato o due richieste confermate non possono stabilire da soli la posizione completata.
Le esecuzioni parziali del bot di arbitraggio creano una nuova decisione
Continua l'esempio fittizio con tutte le 500 unità A eseguite a $0,37, ma soltanto 300 unità B eseguite a $0,60. Gli importi di acquisto sono $185 e $180, per un totale di $365 prima degli oneri. Trecento unità formano coppie complete, con un costo di $291 prima degli oneri. Le restanti 200 unità A costano $74 e hanno esposizione direzionale. Il risultato netto originariamente previsto di $8 per 500 coppie complete non descrive più questo stato del conto.
Il bot dovrebbe smettere di valutare il caso soltanto in base al suo punteggio originario di opportunità. Ora necessita di una decisione di recupero usando quotazioni attuali e limiti espliciti. È possibile acquisire altre 200 unità B entro un costo totale autorizzato? È possibile vendere le unità A non abbinate entro una perdita consentita? È permesso mantenerle temporaneamente e per quanto tempo? Ogni opzione dovrebbe usare la posizione effettiva esistente e le quantità eseguibili dal vivo.
Supponiamo che la regola scritta dell'operatore permetta di ridurre A non abbinato a un denaro non inferiore a $0,34 dopo la conferma dell'annullamento dell'ordine B residuo. Vendere 200 unità A a tale prezzo produce $68. Il conto detiene poi 300 coppie complete, che pagano $300 secondo le ipotesi dell'esempio. I proventi combinati sono $368 contro l'importo di acquisto di $365, lasciando $3 prima degli oneri. Se gli oneri totali effettivi per questo percorso sono $5, il risultato finale è una perdita di $2.
Tale perdita non è evidenza che il calcolo per una coppia da $492 interamente completata fosse sbagliato. Mostra che l'esecuzione prevista non si è verificata e il recupero ha avuto un costo. Il registro dovrebbe conservare entrambi i calcoli. Valutare soltanto coppie favorevoli completate escludendo i casi parziali recuperati sovrastimerebbe l'utilità della politica di esecuzione.
Presenta nuovi clienti e guadagna USDC
Presenta nuovi clienti e guadagna USDCIl nostro programma di affiliazione paga in tempo reale.
Un timeout dell’invio deve conservare la propria identità
Quando una richiesta va in timeout, il bot sa che la comunicazione locale è fallita. Non sa necessariamente se la sede abbia accettato l'ordine. Porta la gamba in uno stato incerto, conservane la riserva e interroga i registri supportati di ordini e conto. Usa gli identificatori originari del client o della sede dove disponibili. Se tali registri non possono risolvere subito il tentativo, l'incertezza resta parte del calcolo dell'esposizione.
Non creare un nuovo ordine soltanto perché la quantità desiderata non è ancora visibile nella posizione locale. L'ordine originario potrebbe essere in attesa nel libro, parzialmente eseguito o in attesa in una fase di elaborazione specifica della sede. Una seconda istruzione può duplicare la quantità prevista. In un sistema abbinato, ciò può produrre una gamba eseguita in eccesso anche dopo il completamento dell'altro lato, trasformando di nuovo un caso nominalmente abbinato in esposizione direzionale.
Il recupero del bot di arbitraggio dei contratti su eventi richiede una condizione di escalation. Dopo un periodo definito o un particolare errore, il sistema può disabilitare nuovi casi nel conto interessato e richiedere una revisione dell'operatore. È una risposta di controllo a evidenze mancanti, non una dichiarazione che la sede abbia perso l'ordine. Il registro dovrebbe dichiarare esattamente cosa resti sconosciuto e quali query o istantanee del conto siano state esaminate.
Quando il tentativo viene infine risolto, aggiorna il caso originario anziché nasconderlo dietro un registro sostitutivo. Se è stato rifiutato, libera la riserva inutilizzata. Se è stato eseguito, incorpora le esecuzioni e ricalcola la quantità abbinata. Se resta aperto, decidi se mantenerlo o annullarlo usando lo stato attuale del caso. Ogni esito dovrebbe conservare il collegamento all'autorizzazione originaria.
Annullamento e sostituzione richiedono un proprio confine
Annullare un ordine non inverte le esecuzioni già avvenute. Non stabilisce neppure che non si sia verificata un'esecuzione mentre la richiesta di annullamento era in transito. Il bot dovrebbe continuare a monitorare la gamba finché abbia evidenze autorevoli sufficienti a determinare la quantità finale eseguita e quella non più eseguibile. Liberare l'intera riserva subito dopo l'invio dell'annullamento può sottostimare l'impegno del conto.
Un ordine sostitutivo introduce un problema simile. Se il vecchio ordine potrebbe essere ancora attivo, inviare di nuovo l'intera quantità prevista può temporaneamente raddoppiare l'importo eseguibile. L'esecutore necessita di una politica documentata di sostituzione coerente con il comportamento effettivo della sede. Tale politica può richiedere conferma prima della sostituzione o una riserva per ogni sovrapposizione supportata. Non dovrebbe mai affidarsi al fatto che l'interfaccia locale nasconda il vecchio ordine come prova che la sede lo abbia rimosso.
Nell'esempio 500 contro 300, supponiamo che altre 40 unità B vengano eseguite durante l'annullamento. La quantità abbinata diventa 340 e A non abbinato scende a 160. Una vendita di recupero di 200 unità A basata sull'istantanea precedente correggerebbe eccessivamente il caso, lasciando esposizione B in eccesso. La decisione di recupero deve quindi usare uno stato riconciliato delle quantità oppure considerare esplicitamente l'incertezza restante.
Il correlato articolo sul bot di trading dei mercati degli eventi esamina più ampiamente interruzioni e modifiche programmate. L'esecuzione abbinata aggiunge un requisito specifico: un'azione di controllo su una gamba può cambiare ciò che dovrebbe accadere sull'altra. Il sistema deve coordinare tali aggiornamenti attraverso uno stato condiviso del caso anziché lasciare che ogni gamba operi come un programma di trading scollegato.
Conserva un budget di recupero senza inseguire il completamento
Un budget di recupero definisce quanto costo o perdita aggiuntivi il sistema possa accettare per ridurre un'esposizione incompiuta. Dovrebbe essere distinto dalla soglia originaria di ingresso. Il conto può razionalmente accettare una perdita limitata dopo un'esecuzione parziale per evitare di mantenere un rischio maggiore sull'evento, ma tale permesso dovrebbe essere esplicito. Altrimenti un bot può giustificare quasi qualsiasi prezzo affermando di completare un arbitraggio.
Imposta il budget in termini verificabili dall'operatore: costo massimo di acquisizione non abbinato, costo massimo aggiuntivo di completamento, perdita massima consentita nella riduzione e condizioni che richiedono giudizio umano. Un tetto di prezzo per la seconda gamba può essere ricalcolato dal costo effettivo della prima e dall'esito consentito. Il calcolo dovrebbe includere oneri effettivi già sostenuti e stime prudenti per l'azione restante.
Un budget non è un'istruzione a spendere l'intero importo consentito. Confronta le alternative disponibili usando quantità eseguibili attuali. Se un annullamento e una piccola riduzione ripristinano una posizione accettabile, il sistema non deve forzare il completamento della dimensione originaria. Se nessuna alternativa rispetta i confini approvati, sospendi e mostra chiaramente la posizione irrisolta. Il rischio residuo del conto dovrebbe essere visibile anche quando il bot non riesce a risolverlo automaticamente.
La precedente trattazione del bot di arbitraggio automatizzato Polymarket offre contesto per tale separazione tra rilevamento e azione controllata. La logica di recupero merita un proprio insieme di dati di valutazione perché interviene in condizioni diverse dall'ingresso ordinario. Il comportamento che funziona in istantanee tranquille può fallire quando la liquidità scompare proprio mentre viene eseguita la prima gamba.
Le consistenze possono accumularsi tra più casi
Un bot può gestire molte coppie contemporaneamente, ma il conto subisce le loro consistenze combinate. Due casi incompiuti possono lasciare esposizione allo stesso esito anche se gli identificatori delle coppie differiscono. Aggrega posizioni e impegni aperti per evento e per scenario avverso pertinente. Non presumere che registri separati dei casi creino limiti di rischio indipendenti.
Un market maker dei contratti su eventi usa le consistenze per orientare ulteriori decisioni di quotazione. Un bot abbinato beneficia della stessa consapevolezza quando gambe incompiute restano nel conto. Nuovi casi potrebbero ridurre uno squilibrio esistente, aumentarlo o creare un'esposizione diversa negli esiti eccezionali. Il controllo del rischio dovrebbe valutare il portafoglio risultante anziché trattare ogni coppia proposta come automaticamente neutrale.
Se il bot partecipa anche al market making sui contratti su eventi, le sue quotazioni in attesa nel libro appartengono allo stesso modello di esposizione. Una quotazione creata per fornire liquidità può essere eseguita mentre il motore di arbitraggio riserva capacità per una seconda gamba. Budget separati che si ignorano possono entrambi superare i controlli locali fallendo a livello di conto. Riserve condivise e riconciliazione coerente sono necessarie anche quando le strategie hanno obiettivi diversi.
La riconciliazione periodica dovrebbe confrontare il modello locale combinato con posizioni, ordini e oneri autorevoli. Un caso può essere segnato come operativamente chiuso soltanto quando i suoi ordini sono risolti e la posizione residua è assegnata correttamente. Se una posizione residua deliberata viene trasferita a un'altra strategia, registra tale trasferimento di responsabilità. Rimuovere il caso da una schermata non dovrebbe rimuoverne il rischio dal registro.
Verifica i casi che cambierebbero la decisione
Usa riproduzioni di incidenti che esercitino il coordinamento, non soltanto l'invio riuscito degli ordini. Un test dovrebbe accettare A e rifiutare B. Un altro dovrebbe eseguire parzialmente B durante un annullamento. Un terzo dovrebbe consegnare due volte la stessa esecuzione. Un quarto dovrebbe riavviare il processo dopo una richiesta inviata ma prima della registrazione della risposta. Il risultato atteso dovrebbe specificare quantità, riserve, prossime azioni consentite ed eventuale pausa richiesta.
Per il caso svolto di esecuzione parziale, verifica indipendentemente il calcolo: $365 spesi, $68 recuperati riducendo 200 unità A non abbinate, $300 ricevuti dalle coppie compatibili residue e $5 di oneri effettivi ipotizzati producono una perdita di $2. Il test non dovrebbe etichettare il caso come una coppia redditizia da 500 unità soltanto perché quella era la raccomandazione originaria. Dovrebbe conservare la ragione per cui il risultato differisce dal piano.
Verifica anche la decisione di non iniziare. Rifiuta una coppia con regole non corrispondenti, fondi locali insufficienti, profondità obsoleta o stato irrisolto del conto. Questi rifiuti fanno parte del comportamento previsto del bot. Un sistema che supera soltanto test di esecuzione attiva può comunque essere insicuro perché non ha mai dimostrato di rispettare le condizioni in cui l'esecuzione dovrebbe essere sospesa.
La revisione finale dovrebbe poter ricostruire ogni caso dalla relazione approvata dei pagamenti al risultato riconciliato del conto. Un bot a gambe abbinate è utile quando rende esplicite le combinazioni incomplete, ne limita le conseguenze e conserva evidenze sufficienti a spiegare il recupero. È lo standard pratico per l'automazione in un processo in cui due prezzi attraenti non garantiscono due operazioni completate.