DepthFeed/Both venues·مقارنة

بيانات Polymarket مقابل Kalshi: ما المتاح فعلاً، وكيف تستخدم المنصتين معاً

تبدو Polymarket وKalshi متشابهتين من الخارج، لكنهما تتيحان بيانات مختلفة جذرياً في الداخل. إليك التفصيل الصادق لكل منصة على حدة.

DepthFeed··8 min

Polymarket هي دفتر أوامر محدّد مركزي (CLOB) على سلسلة Polygon، مع WebSocket يبث دفاتر الأوامر الحية لكنه لا يوفّر أرشيفاً تاريخياً لدفتر الأوامر؛ أما Kalshi فهي بورصة أمريكية خاضعة لتنظيم CFTC تقدّم واجهة REST API نظيفة ودفتر yes/no يصل إلى 100 levels لكل جانب، لكنها هي الأخرى لا تشحن عمق دفتر الأوامر التاريخي. كلتاهما تمنحك الدفتر الحي، ولا واحدة منهما تقدّم تاريخ العمق الخاص بها — وهذه هي الفجوة التي يسدّها الالتقاط من طرف ثالث.

مقارنة جنباً إلى جنب

PolymarketKalshi
النوعدفتر أوامر CLOB على السلسلة (Polygon)بورصة أمريكية خاضعة لتنظيم CFTC
بيانات السوق الحيةCLOB WebSocket + RESTREST (دفتر الأوامر، الشموع، الصفقات)
شكل الدفترعرض/طلب لكل نتيجةyes/no، حتى 100 levels لكل جانب
دفتر الأوامر التاريخيلا تقدّمه البورصةلا تقدّمه البورصة
أسواق الكريبتوصعود/هبوط، 5m–24h15m، ساعية، يومية، أسبوعية
التسويةحسم / oracleسعر مرجعي منشور عند انتهاء الصلاحية

Polymarket: بيانات حية غنية، بلا تاريخ للعمق

تشغّل Polymarket دفتر أوامر محدّد مركزي على سلسلة Polygon. يبث CLOB WebSocket الخاص بها تحديثات الدفتر والسعر الحية، وتكشف واجهة REST API الأسواق والصفقات ونقطة نهاية لتاريخ الأسعار (prices-history). ما لا توفّره هو أرشيف تاريخي للقطات دفتر الأوامر — فبمجرد مرور تحديث الدفتر، لا تتيح لك البورصة إعادة تشغيله. ولاختبار رجعي يعتمد على الدفتر الساكن، تحتاج إلى مزوّد التقط بث WebSocket بشكل متواصل.

Kalshi: منظَّمة، REST نظيف، ومع ذلك لا أرشيف للعمق

Kalshi بورصة خاضعة لتنظيم CFTC، وهذا ما يشكّل بياناتها: واجهة REST API نظيفة بها الأسواق والشموع والصفقات ونقطة نهاية لدفتر الأوامر الحالي، مقسّمة إلى طبقتين حية وتاريخية. لكن الطبقة التاريخية تغطّي الصفقات والشموع، لا عمق دفتر الأوامر الكامل عبر الزمن — ونقطة نهاية دفتر الأوامر العامة تعكس الحالة الراهنة فقط. لذا، وكما هو الحال مع Polymarket، فإن إعادة تشغيل دفتر yes/no الخاص بـ Kalshi كما كان تتطلب التقاطاً متواصلاً من طرف ثالث.

العمل بالمنصتين معاً ضمن مخطط واحد

تختلف المنصتان في الشكل — عرض/طلب لكل نتيجة في Polymarket مقابل سُلّم yes/no في Kalshi — لذا فإن دمجهما بنفسك يعني مُحمّليْن (loaders) ونموذجَي تسوية. يوحّد DepthFeed كلتيهما في مخطط عمودي واحد: مصفوفات سعر وحجم العرض/الطلب، طوابع زمنية للبورصة وللاستلام بصيغة epoch-millis، وسعر مرجعي للأصل الأساسي مربوط لكل لقطة، عبر أصول الكريبتو السبعة جميعها. ونفس كود الاختبار الرجعي يقرأ أي من المنصتين.

يختلف الالتقاط بحسب المنصة، لكن صيغة الإخراج لا تختلف: تُلتقط Polymarket مدفوعةً بالأحداث من CLOB WebSocket (وسيط زمن تسليم حي ~10 ms، مقيس)؛ بينما تُستطلَع Kalshi باستمرار بالعمق الكامل (كل 1.5 ثانية تقريباً). وكلتاهما تصل كنفس الـ JSON عبر REST API وبث WebSocket الحي.

Key takeaways

  • 01Polymarket دفتر أوامر CLOB على السلسلة (Polygon)؛ وKalshi بورصة أمريكية خاضعة لتنظيم CFTC.
  • 02كلتاهما تبث أو تقدّم الدفتر الحي؛ ولا واحدة منهما تقدّم عمق دفتر الأوامر التاريخي الخاص بها.
  • 03دفاتر Kalshi من نوع yes/no حتى 100 levels لكل جانب؛ ودفاتر Polymarket عرض/طلب لكل نتيجة.
  • 04يوحّد DepthFeed كلتيهما في مخطط واحد بحيث يقرأ اختبار رجعي وحيد أي من المنصتين.

تبدو Polymarket وKalshi متشابهتين من الخارج، لكنهما تتيحان بيانات مختلفة جذرياً في الداخل. إليك التفصيل الصادق لكل منصة على حدة.

ابدأ مجانًا

أسئلة، مُجابة.

لا واحدة منهما تقدّم عمق دفتر الأوامر التاريخي الخاص بها. يبث WebSocket الخاص بـ Polymarket الدفتر الحي، وتُرجع REST API الخاصة بـ Kalshi دفتر الأوامر الحالي، لكن لإعادة تشغيل الدفتر الساكن كما كان في لحظة ماضية تحتاج إلى طرف ثالث التقطه بشكل متواصل، مثل DepthFeed.