Bitcoin est BTC sur la plupart des plateformes, mais c'est XBT sur certaines, et les paires de trading sont formatées différemment partout. BTCUSDT, BTC/USDT, BTC-USDT, tBTCUSD. Ces incohérences de nommage semblent triviales mais elles constituent la première barrière à toute analyse multiplateforme. Un système qui compare les prix entre plateformes a besoin d'une couche de mappage qui traduit chaque convention de nommage de plateforme en un format canonique.
Le défi devient plus difficile avec les actifs moins établis. Un token peut être listé sous différentes adresses de contrat sur différentes chaînes, avec différents symboles de ticker sur différentes plateformes. Certaines plateformes listent des versions wrappées. D'autres listent des versions natives. Un token appelé ABC sur une plateforme peut être un projet complètement différent de ABC sur une autre. Un appariement multiplateforme fiable nécessite une combinaison de vérification d'adresse de contrat, d'appariement de symboles et de curation manuelle.
La synchronisation des horodatages est un autre défi fondamental. Les plateformes rapportent les horodatages dans différents formats et avec différents niveaux de précision. Certaines rapportent en millisecondes depuis l'epoch, d'autres au format ISO 8601. Certaines utilisent UTC, d'autres l'heure locale. Et la latence entre le moment où une transaction se produit et celui où elle est rapportée via l'API varie selon les plateformes. Aligner les données sur une référence temporelle commune est essentiel pour toute analyse multiplateforme comme la détection d'arbitrage ou la comparaison de volumes.
La normalisation des prix va au-delà de la simple conversion de devises. Différentes plateformes ont différentes structures de frais qui affectent le prix effectif. Les modèles de frais maker-taker signifient que le coût réel d'une transaction dépend du fait que vous ajoutez ou retirez de la liquidité. Un prix qui ressemble à une opportunité d'arbitrage peut disparaître entièrement une fois que vous tenez compte des frais des deux côtés de la transaction.
La comparaison de la profondeur du carnet d'ordres est particulièrement délicate. Différentes plateformes rapportent les carnets d'ordres à différents niveaux de granularité. Certaines fournissent le carnet d'ordres complet avec des ordres individuels. D'autres agrègent en niveaux de prix. Le nombre de niveaux fournis varie. Comparer la liquidité entre plateformes nécessite de normaliser ces différentes représentations dans un format comparable, généralement agrégé par niveau de prix avec le volume total à chaque niveau.
L'appariement multiplateforme pour les marchés de prédiction ajoute une autre dimension. La même question peut être listée sur Polymarket, Kalshi et d'autres plateformes avec une formulation légèrement différente, des dates d'expiration différentes ou des critères de résolution différents. Les apparier nécessite une compréhension sémantique, pas seulement un appariement de chaînes de caractères. Une question sur les changements de taux de la banque centrale sur une plateforme pourrait être formulée très différemment sur une autre, mais un algorithme d'appariement naïf ne les reconnaîtrait pas comme équivalentes.
Les scores de qualité des données aident à gérer l'écart de fiabilité entre les plateformes. Un système d'appariement peut attribuer une plus grande confiance aux données provenant de plateformes ayant de meilleurs antécédents de rapports précis et une moindre confiance aux données provenant de plateformes connues pour des flux retardés ou peu fiables. Ces scores de qualité peuvent pondérer les données appariées, de sorte que l'analyse ne soit pas influencée de manière disproportionnée par des sources de faible qualité.
La déduplication est nécessaire lorsque la même transaction apparaît dans plusieurs sources de données. Les agrégateurs qui tirent à la fois des API directes des plateformes et des fournisseurs de données tiers peuvent finir par compter la même transaction deux fois. La déduplication utilise généralement une combinaison d'horodatage, de prix, de volume et d'ID de transaction pour identifier les doublons, mais les horodatages imprécis et les différents niveaux de granularité rendent cela plus difficile qu'il n'y paraît.
Les systèmes qui le font bien ont tendance à être construits de manière itérative. Vous commencez avec le mappage de symboles pour les actifs majeurs, ajoutez des adaptateurs spécifiques aux plateformes un par un, construisez une surveillance de qualité pour détecter les problèmes de données et étendez lentement la couverture. Il n'y a pas de raccourci pour gérer la longue traîne de cas limites qui émergent lorsque vous essayez de créer une vue unifiée d'un marché fragmenté.