في أي لحظة، تُتداول Bitcoin بأسعار مختلفة قليلًا على عشرات المنصّات. فقد يختلف السعر على Binance عن Coinbase ببضعة دولارات، والذي يختلف عن Kraken ببضعة دولارات أخرى. وتحتاج أدوات تجميع بيانات السوق مثل CoinGecko وCoinMarketCap ومختلف مزوّدي البيانات المحترفين إلى جمع كلّ هذه الأسعار وإنتاج سعر مرجعي وحيد يعكس القيمة السوقية الحقيقية.
طبقة جمع البيانات هي الأساس. تحافظ أدوات التجميع على اتصالات مع واجهات برمجة تطبيقات كل منصّة كبرى، مستخدمةً عادةً اتصالات WebSocket لبيانات الصفقات ودفاتر الأوامر في الوقت الفعلي. وبالنسبة إلى أداة تجميع شاملة، يعني ذلك المحافظة على مئات الاتصالات المتزامنة، لكلّ منها تنسيق بيانات خاصّ وحدود معدّل وخصائص موثوقية. فبعض المنصّات تدفع البيانات بموثوقية. وأخرى تعاني من انقطاعات متكرّرة وتحتاج إلى منطق إعادة اتصال دائم.
التوحيد هو التحدّي التالي. فلكلّ منصّة اصطلاحات تسمية خاصّة وتنسيقات طوابع زمنية وهياكل بيانات. فقد تسمّي منصّة الأصل BTC/USDT، بينما تسمّيه أخرى BTCUSDT أو XBT/USD. وقد تكون أحجام الصفقات بالعملة الأساس في منصّة وبعملة التسعير في أخرى. وتحتاج طبقة التوحيد إلى ترجمة كلّ ذلك إلى تنسيق داخلي متّسق قبل أن يتمكّن أي تجميع ذي معنى من الحدوث.
حساب السعر المرجعي أعقد من مجرّد متوسّط بسيط. فمتوسّط السعر المُرجَّح بالحجم عبر المنصّات نهج شائع، يعطي وزنًا أكبر للمنصّات ذات حجم التداول الأعلى. لكن الحجم نفسه قد يكون غير موثوق. فتداول الغسيل يُضخّم الأحجام المُبلَّغ عنها في بعض المنصّات، ما يُشوّه حساب VWAP الساذج. وتطبّق أدوات التجميع المتقدّمة كشف القيم الشاذّة وتعديل الحجم لتصفية تداول الغسيل المشتبه به.
يتفاوت التأخّر تفاوتًا كبيرًا عبر خط أنابيب البيانات. فقد تُدخل واجهة برمجة التطبيقات للمنصّة تأخيرًا يتراوح بين 10 و100 ميلّي ثانية. ويُضيف العبور الشبكي المزيد. وتُضيف المعالجة والتجميع بضعة ميلّي ثوانٍ أخرى. وبحلول نشر السعر المرجعي، قد يكون متأخّرًا 50 إلى 500 ميلّي ثانية عن السوق الفعلية. وبالنسبة إلى متداول تجزئة ينظر إلى مخطّط سعر، يكون هذا غير مرئي. أما بالنسبة إلى نظام خوارزمي يتّخذ قرارات في كسر الثانية، فقد يكون كبيرًا.
تجميع دفتر الأوامر أعقد من تجميع الصفقات. فدفتر الأوامر المُجمَّع الحقيقي يُظهر السيولة الإجمالية المتاحة عبر كل المنصّات عند كل مستوى سعر. وهذا يتطلّب الحفاظ على رؤية في الوقت الفعلي لكل دفتر أوامر في كل منصّة ودمجها. والتحدّي هو أن دفاتر الأوامر تتغيّر آلاف المرات في الثانية، وكل منصّة ترسل تحديثات بمعدّلات مختلفة. والرؤية المُجمَّعة هي دائمًا تقريب قديم قليلًا.
تُجرى مراقبة جودة البيانات باستمرار خلف الكواليس. فإذا أبلغت منصّة عن صفقة بسعر بعيد عن التوافق، فقد تكون شذوذًا مشروعًا أو خطأً في البيانات. وتستخدم أدوات التجميع طرقًا إحصائية للكشف عن هذه الحالات ومعالجتها، مُشيرةً إلى الصفقات التي تنحرف ما وراء عتبة معيّنة عن السعر المرجعي أو مستثنيةً إيّاها. يمنع ذلك صفقة خاطئة واحدة في منصّة منخفضة الحجم من تحريك السعر المُجمَّع.
تخزين البيانات التاريخية واسترجاعها هما الوجه الآخر للمشكلة. فتخزين كل صفقة من كل منصّة بدقّة كاملة يُولّد تيرابايتات من البيانات سنويًّا. ويحتاج المستخدمون المختلفون إلى دقّات مختلفة. فقد يحتاج باحث يحلّل الاتجاهات الطويلة الأجل إلى شموع OHLCV يومية. ويحتاج مُختبر الاستراتيجيات إلى بيانات دقيقة أو فرعية. وتحتاج بنية البيانات التحتية إلى دعم الاستعلامات الفعّالة عبر كل هذه المقاييس الزمنية.
لا يزال مشهد بيانات السوق في العملات المشفّرة ينضج مقارنةً بالتمويل التقليدي، حيث تضمن متطلّبات الشريط المُوحَّد تغذية سعر مرجعي وحيد. وفي العملات المشفّرة، لا يوجد تكليف تنظيمي ببيانات مُوحَّدة، مما يعني أن كل أداة تجميع تتّخذ خيارات مختلفة قليلًا بشأن المنصّات التي تُدرجها وكيف تُرجّحها وكيف تُعالج الحالات الحدّية. والأسعار التي تراها على منصّات مختلفة ستختلف دائمًا قليلًا نتيجة لذلك.