Sur les marchés de prédiction avec N résultats, j'ai entendu dire qu'ils gèrent un carnet de commandes séparé OUI/NON pour chaque résultat, et s'appuient sur des arbitragistes pour "équilibrer" ces marchés. Si c'est le cas, pourquoi ? Pourquoi les échanges ne font-ils pas le matching implicite de manière atomique pour augmenter la liquidité ?

Par exemple, s'il y a 3 résultats et que je soumets un ordre limite NON avec une probabilité de 30 % pour chaque résultat, alors ces ordres resteront là jusqu'à ce qu'un arbitragiste les associe tous les 3 pour un total de 90 cents. Après avoir passé les deux premiers ordres, l'échange devrait plutôt afficher un ordre implicite OUI à 40 cents sur le troisième résultat, et m'empêcher de passer mon troisième ordre. Cela semble strictement augmenter la liquidité pour les utilisateurs, leur offrant de meilleurs prix, des spreads plus serrés, et également un volume plus élevé pour l'échange puisque chaque ordre qui peut être associé le sera. De plus, les arbitragistes ne réaliseront pas d'échanges implicites à gain net nul puisque cela n'apporte aucun gain sur l'arbitrage, tandis que les échanges le feront avec plaisir.

Enfin, cela ne semble pas particulièrement complexe sur le plan computationnel pour le moteur de correspondance. Pour un seul marché de prédiction, il peut simplement maintenir la somme actuelle des meilleures offres et la somme actuelle des meilleures demandes pour chacun des N résultats. C'est une opération O(1) lors de la passation de commande. Si la somme des meilleures offres dépasse 1, ou si la somme des meilleures demandes dépasse N-1, alors il faut faire correspondre les ordres à travers tous les résultats dans un échange implicite. C'est O(N) mais vous faites correspondre N ordres.

Je ne peux actuellement pas penser à un moyen de servir efficacement le "livre de commandes implicite" complet, mais au moins le prix de contact peut être servi de manière extrêmement efficace avec un minimum de surcharge. Le montant de contact pourrait être servi si un min-heap (sur la taille de commande au contact) est maintenu, bien que cela soit moins efficace que O(1) par commande (cela pourrait être O(log n)).