Nei mercati delle previsioni con N risultati, ho sentito che gestiscono un libro ordini separato YES/NO per ciascun risultato e si affidano agli arbitraggi per "bilanciare" tali mercati. Se questo è il caso, perché? Perché gli scambi non effettuano il matching implicito in modo atomico per aumentare la liquidità?
Ad esempio, se ci sono 3 risultati e invio un limite NO con una probabilità del 30% che ciascun risultato si verifichi, allora quegli ordini rimarranno lì finché un arbitraggista non abbina tutti e 3 per un totale di 90 centesimi. Dopo aver piazzato i primi due ordini, l'exchange dovrebbe invece mostrare un ordine implicito di YES per 40 centesimi sul terzo risultato, e impedirmi di piazzare il mio terzo ordine. Questo sembra aumentare notevolmente la liquidità per gli utenti, offrendo loro prezzi migliori, spread più stretti e anche un volume maggiore per l'exchange, poiché ogni ordine che può essere abbinato verrà abbinato. Inoltre, gli arbitraggisti non abbineranno scambi impliciti a guadagno netto zero poiché non c'è guadagno sull'arbitraggio, mentre gli exchange lo faranno felicemente.
Infine, questo non sembra particolarmente complesso dal punto di vista computazionale per il motore di abbinamento. Per un singolo mercato delle previsioni, può semplicemente mantenere la somma attuale delle migliori offerte e la somma attuale delle migliori richieste per ciascuno dei N risultati. Questa è un'operazione O(1) al momento dell'inserimento dell'ordine. Se la somma delle migliori offerte superasse 1, o la somma delle migliori richieste superasse N-1, allora abbina gli ordini su tutti i risultati in un'operazione implicita. Questo è O(N) ma stai abbinando N ordini.
Attualmente non riesco a pensare a un modo per servire in modo efficiente il "libro ordini implicito" completo, ma almeno il prezzo di contatto può essere servito in modo estremamente efficiente con un sovraccarico minimo. L'importo di contatto potrebbe essere servito se viene mantenuto un min-heap (sulla dimensione dell'ordine al contatto), anche se questo è meno efficiente di O(1) per ordine (potrebbe essere O(log n)).
1,78K