شرح الخوارزمية الأساسية لـ Polymarket

العمل الأصلي: @MrRyanChi، @insidersdotbot مؤسس منصة تداول أسواق التنبؤ

مقدمة: الوجه الآخر لـ Polymarket الذي لا تعرفه

في الأشهر الستة الماضية، ظهرت مئات الملايين من مقالات أسواق التنبؤ على تويتر.

تسعون بالمائة منها تتحدث عن كيف يمكن لبرامج الكتابة بالذكاء الاصطناعي أن تقود إلى أسطورة الثراء السريع. هذا هو "اليوان" (Yuan)، الخطوة الأولى في تعرضك لهذا السوق الناشئ.

وتناقش 9% أخرى استراتيجيات تداول محددة، ومشاركة السوق، وتحليل استراتيجيات الأموال الذكية. هذا هو "الداو" (Dao)، الخطوة الأولى في استكشاف استراتيجيات التداول الخاصة بك والبدء في فهم عقلية جني الأرباح في أسواق التنبؤ.

ومع ذلك، فإن "الفاء" (Fa)، والتي تشير إلى التصميم الأساسي لتداول أسواق التنبؤ، وحسابات الأرباح والخسائر (PNL)، وقواعد تدفق الأموال، لا يناقشها سوى 1% من الناس، وغالباً ما تكون متناثرة عبر تغريدات موجزة. يبدو أن هؤلاء الخبراء المنعزلين غير راغبين، أو يفتقرون إلى الطاقة، لمشاركة أساليبهم الكاملة مع الجميع دفعة واحدة.

لذا، في اليوم الذي تم فيه إطلاق insiders.bot للتو وأكملت Polymarket تحديث الإصدار الثاني (v2) الخاص بها، أريد تفكيك "الفاء" لهذا السوق الذي نتداول فيه من التكنولوجيا الأكثر جوهرية.

في أكتوبر الماضي، كتبت نسخة مبسطة قدمت تقريباً العديد من المكونات الأساسية لـ Polymarket. هذه المرة، أريد أن أعرض حقاً كل تفاصيل التصميم التقني وشرحها بلغة بسيطة.

تحتوي هذه المقالة على العمل الشاق الذي قام به فريقنا على مدار الأشهر الثمانية الماضية.

خلال هذه الأشهر الثمانية، قام فريق @insidersdotbot بتشريح جميع العقود الذكية الأساسية وبنية الخوارزميات لـ Polymarket لتحقيق أسرع تداول وأدق حسابات للأرباح والخسائر. هذا شيء لا يمكن تحقيقه إلا من خلال واجهة برمجة التطبيقات (API) الخاصة بنا، وحتى يومنا هذا، لا يمكن لأحد آخر القيام بذلك.

لذا، أعتقد أننا قد نكون الأشخاص الأكثر قدرة على تشريح "الفاء" لـ Polymarket بدقة.

في هذه المقالة، سأساعدك على فهم كيفية تعامل العقد الذكي ctf-exchange-v2 الأساسي مع كل أموال، وكيف يساعدك الـ Relayer في دفع رسوم الغاز (Gas)، وكيف تضمن المخاطر السلبية (Negative Risk) رياضياً الحفاظ على القيمة.

هذه ليست مقالة علمية شعبية بسيطة. هذا تفكيك خوارزمي شامل للآليات الأساسية لـ Polymarket من منظور المطور.

لنبدأ من الأساسيات. أي، عندما تضع طلباً، ما الذي ترسله بالضبط؟

ملاحظة: تم تكييف هذه المقالة أيضاً في الأسلوب والهيكل بواسطة الذكاء الاصطناعي، لا تتردد في مشاركتها مع OpenClaw أو Manus أو Hermes أو أي وكيل ذكاء اصطناعي كمادة تدريبية!!!

الفصل الأول: ماذا يحدث من النقرة إلى السلسلة (On-chain)

1.1 الطلبات ليست معاملات، إنها "نوايا"

في البورصات اللامركزية التقليدية (مثل Uniswap)، عندما تتداول، تظهر محفظتك مربع تأكيد، وتحتاج إلى دفع رسوم الغاز، ثم إرسال معاملة إلى شبكة البلوكشين (Mempool) لانتظار قيام المعدنين بتجميعها.

لكن في Polymarket، عندما تضع طلباً، تظهر محفظتك عادةً طلب "توقيع"، بدلاً من طلب "معاملة". علاوة على ذلك، لا تحتاج إلى دفع أي رسوم غاز.

هذا ليس مجرد تحسين لتجربة المستخدم؛ إنه اختلاف جوهري في البنية التحتية الأساسية بأكملها.

في Polymarket، الطلب هو في الأساس جزء من بيانات منظمة تتوافق مع معيار EIP-712. تحتوي هذه البيانات على ما تريد القيام به:

• هل أنت صانع سوق (Maker) أم متلقي (Taker)؟ أي رمز (tokenId) تريد شراءه؟

• كم تريد أن تدفع (makerAmount)؟

• كم تريد أن تستلم (takerAmount)؟

عندما توقع، فأنت ببساطة تختم هذه البيانات بمفتاحك الخاص، لتثبت "أنا أريد حقاً القيام بذلك". بعد ذلك، يتم إرسال هذه البيانات الموقعة إلى خادم Polymarket المركزي وتخزينها في دفتر أوامر محدد مركزي (CLOB) خارج السلسلة.

في هذه المرحلة، لم يحدث شيء على البلوكشين. أموالك لا تزال في محفظتك، ولم يتم تحويل الرموز. طلبك مجرد سجل في قاعدة البيانات.

1.2 التعبير الضمني عن السعر

لنوقف الزمن في اللحظة التي ترسل فيها الطلب. إذا ألقيت نظرة فاحصة على هيكل الطلب للعقود الأساسية لـ Polymarket، ستجد شيئاً غير بديهي للغاية: لا يوجد حقل "سعر" في بيانات توقيع الطلب.

كيف يمكن ذلك؟ كيف يمكن أن تكون هناك تجارة بدون سعر؟

في التصميم الأساسي لبروتوكول Polymarket، السعر ضمني. يتم حسابه بناءً على المبلغ الذي ترغب في دفعه والمبلغ الذي تريد استلامه.

إذا كنت ترغب في شراء 100 عقد YES بسعر 0.60 دولار:

• تحتاج إلى دفع: 60 pUSD (makerAmount = 60)

• تريد استلام: 100 عقد YES (takerAmount = 100)

• السعر الضمني = makerAmount / takerAmount = 60 / 100 = 0.60 دولار

إذا كنت ترغب في بيع 100 عقد YES بسعر 0.60 دولار:

• تحتاج إلى دفع: 100 عقد YES (makerAmount = 100)

• تريد استلام: 60 pUSD (takerAmount = 60)

• السعر الضمني = takerAmount / makerAmount = 60 / 100 = 0.60 دولار

(ملاحظة: على الرغم من أنه في أحدث SDK للإصدار الثاني، يمكن للمطورين إدخال السعر والحجم مباشرة، إلا أن الـ SDK لا يزال يحولها إلى makerAmount و takerAmount أثناء التوقيع الأساسي. تكمن براعة هذا التصميم في أن العقد الذكي لا يحتاج إلى فهم ماهية "السعر"؛ بل يحتاج فقط إلى التعامل مع منطق "تبادل الأصل أ بأصل ب". هذا يبسط بشكل كبير منطق الحساب على السلسلة ويقلل من استهلاك الغاز.)

1.3 المشغل (Operator): "شرطي المرور" في Polymarket

بما أن الطلبات كلها خارج السلسلة، كيف تصبح تحويلات أصول حقيقية على السلسلة؟

هذا يقودنا إلى دور الصندوق الأسود الأكثر جوهرية في بنية Polymarket: المشغل (Operator).

في العقد الذكي ctf-exchange-v2، يوجد مُعدِّل حاسم: onlyOperator. هذا يعني أن عنواناً محدداً فقط تسيطر عليه Polymarket لديه السلطة لاستدعاء وظائف التنفيذ مثل matchOrders و fillOrder.

هذا يختلف تماماً عن التمويل اللامركزي (DeFi) التقليدي. في Uniswap، يمكن لأي شخص استدعاء عقد التوجيه. لكن في Polymarket، لا يمكنك مطابقة الصفقات على السلسلة بنفسك. يجب أن يتم تقديم جميع المطابقات بواسطة المشغل.

لماذا تم تصميم هذا بهذه الطريقة؟ للقضاء على MEV (قيمة قابلة للاستخراج من قبل المعدنين) والتداول المسبق (front-running).

في دفاتر الأوامر التقليدية على السلسلة، إذا وضع شخص ما طلباً كبيراً بسعر منخفض جداً، ستقوم جميع روبوتات المراجحة بالمزايدة بجنون في Mempool (زيادة رسوم الغاز) لمحاولة تجاوز الآخرين وتناول هذا الطلب. يؤدي هذا إلى ارتفاع رسوم الغاز وتجربة سيئة للمستخدمين العاديين.

في Polymarket، جميع الطلبات موجودة في CLOB خارج السلسلة. يقوم محرك مطابقة المشغل بحساب من يجب أن يتداول مع من على الخادم، ثم يجمع النتيجة في معاملة، يتم إرسالها إلى السلسلة بواسطة المشغل.

لأن المشغل فقط هو من يمكنه تقديم نتائج المطابقة، حتى لو رأت الروبوتات في Mempool هذه المعاملة، فإنها لا تستطيع التداول المسبق عليها لأنها لا تملك السلطة لاستدعاء وظائف التنفيذ.

هذه بنية نموذجية لـ "اللامركزية الهجينة". المطابقة والطلب مركزيان (يقررهما المشغل)، لكن التسوية وحفظ الأموال لامركزيان (يتم تنفيذهما بواسطة العقود الذكية).

يمكن للمشغل أن يقرر من يطابق أولاً ومن يطابق لاحقاً، لكنه بالتأكيد لا يستطيع سرقة أموالك لأنه يجب عليه تقديم بيانات EIP-712 الموقعة التي وقعتها أنت، وسيقوم العقد بالتحقق بدقة من التوقيع.

ملاحظة: ومع ذلك، يجب أن أذكر أن فريق @insidersdotbot الخاص بنا يبدو أنه اكتشف مؤخراً طريقة لاستغلال هذه الآلية، مما يسمح للمتابعين بالتداول المسبق أو تأخير المعاملات بشكل كبير. إذا كانت هناك أي تحديثات، فسنعلن عنها على الحساب الرسمي في أقرب وقت ممكن.

الفصل الثاني: اقتصاديات الـ Relayer

2.1 وهم "بدون غاز" (Gasless)

واحدة من أكبر نقاط البيع في Polymarket هي "المعاملات بدون غاز" للمستخدمين. تحتاج فقط إلى pUSD للتداول، دون الحاجة إلى شراء POL (سابقاً MATIC) للاحتفاظ بها في محفظتك.

لكن لا يمكن انتهاك القوانين الفيزيائية للبلوكشين: طالما أن هناك تغييراً في الحالة على Polygon (مثل تحويل الأصول)، يجب على شخص ما دفع رسوم الغاز.

بما أنك لم تدفع، فمن دفع؟ الجواب هو: Relayer.

2.2 شبكة الترحيل الخاصة بـ Relayer

لا تسمح Polymarket للمستخدمين بإرسال المعاملات بأنفسهم ولكنها نشرت بنية تحتية تسمى Relayer Client (relayer-v2.polymarket.com).

في البنية المبكرة، كانت مثل هذه الخدمات تعتمد عادةً على خدمات على مستوى المؤسسات مثل OpenZeppelin Defender Relay، مع الحفاظ على مجموعة توقيع لحل تعارضات nonce تحت التزامن العالي.

عندما ينشئ تطبيقك معاملة (مثل الموافقة على الرموز، استرداد الأرباح)، توقعها بمفتاحك الخاص وترسلها إلى Relayer. يعمل Relayer كـ "راعي معاملة"، حيث يقدم هذه المعاملة إلى السلسلة ويغطي رسوم الغاز من مجموعة أمواله الخاصة.

بنية Relayer والدورة الاقتصادية

2.3 هل الصوف يأتي من الخروف؟

في العديد من بنيات المعاملات الفوقية المبكرة، بعد أن يغطي Relayer الغاز، فإنه عادة ما يخصم رسوماً من إيداع المستخدم (مثل 0.3% أو بضعة دولارات ثابتة) لتعويض تكاليف الغاز.

لكن Polymarket عدوانية للغاية: في بنية V2 الحالية، هم يغطون المبلغ بالكامل حقاً من أجلك.

تنص الوثائق الرسمية بوضوح: "تدفع Polymarket الغاز لجميع العمليات الموجهة عبر الـ relayer." سواء كان ذلك نشر المحافظ، أو تفويض الرموز، أو التقسيم (Split)، أو الدمج (Merge)، أو الاسترداد (Redeem)، كلها بدون غاز ولا يتم فرض أي رسوم تشغيلية خفية.

لماذا Polymarket مستعدة لتحمل هذه الخسارة؟

لأن تكاليف الغاز على Polygon منخفضة جداً (عادة بضعة سنتات فقط)، وتجربة بدون غاز يمكن أن تجذب تدفقاً هائلاً من مستخدمي Web2. طالما أن المستخدمين يتحملون رسوم متلقي (Taker fee) صغيرة أثناء التداول (والتي ستتم مناقشتها لاحقاً)، فهي كافية لتغطية تكلفة الغاز المنخفضة للغاية هذه.

بمعرفة هذا، يطرح السؤال التالي نفسه بشكل طبيعي: ما هو التأثير الذي تحدثه هذه البنية "بدون غاز" على تداولنا؟

أكبر تكلفة خفية هي الكمون (latency). طلبك لا يمر فقط عبر محرك مطابقة Polymarket، ولكن إذا كانت عملية مباشرة على السلسلة، فيجب أن تمر أيضاً عبر تحقق Relayer، وتقدير الغاز، وتخصيص قائمة الانتظار.

الفصل الثالث: ثلاث طرق مطابقة، ولماذا يمكن للمشترين والمشترين التداول أيضاً؟

الآن ندخل الجزء الأكثر صرامة وغير بديهي من بنية Polymarket بأكملها.

في البورصات التقليدية (مثل دفتر أوامر Binance)، منطق المطابقة بسيط جداً: أليس تريد شراء رمز واحد مقابل 60 دولاراً، بوب يريد بيع رمز واحد مقابل 60 دولاراً. تطابق البورصة بينهما، ينتقل الرمز من بوب إلى أليس، وتنتقل الأموال من أليس إلى بوب. نهاية القصة.

لكن في Polymarket (بناءً على إطار الرموز المشروطة CTF)، الأمور مختلفة تماماً. لأنه هنا، يمكن "إنشاء الرموز من العدم" و"تدميرها من العدم".

عندما تفتح الكود المصدري لـ ctf-exchange-v2، ستجد ثلاثة مسارات تسوية أصول مختلفة تماماً: COMPLEMENTARY، MINT، و MERGE.

الهيكل العام لـ Complementary و Mint و Merge

3.1 COMPLEMENTARY (مطابقة تكميلية): التداول التقليدي المستعمل

هذه هي أسهل طريقة مطابقة للفهم والطريقة الوحيدة التي تمتلكها البورصات التقليدية.

السيناريو: السوق موجود منذ فترة، والجميع لديهم رقائق.

• أليس تريد شراء 100 YES مقابل 0.60 دولار.

• بوب لديه YES، ويريد بيع 100 YES مقابل 0.60 دولار.

يجد المشغل هذين الطلبين (شراء مقابل بيع) ويجمعهما على السلسلة. ينفذ العقد الذكي تحويلاً مباشراً من نظير إلى نظير:

1. تحويل 100 YES من عنوان بوب إلى أليس.

2. تحويل 60 pUSD من عنوان أليس إلى بوب.

تتمتع هذه الآلية بالخصائص الرياضية والهندسية التالية:

• لعبة صفرية: إجمالي عرض الرموز في النظام لم يتغير.

• الحد الأدنى من استهلاك الغاز: يتضمن فقط التحويلات الأساسية، دون العمليات المعقدة لـ CTF.

• التوحيد: في سوق ناضج وسائل، يتم إجراء الغالبية العظمى من التداولات اليومية بهذه الطريقة.

3.2 MINT (مطابقة السك): خلق السيولة من العدم

قد يكون هذا الابتكار الأكثر ثورية في Polymarket وحتى في التاريخ المالي بأكمله.

لشرح ذلك بشكل أفضل، يمكننا الرجوع إلى هذا السيناريو: سوق جديد تماماً تم إطلاقه للتو، ولا أحد لديه رموز YES أو NO.

• أليس متفائلة للغاية؛ تريد شراء 100 YES مقابل 0.60 دولار.

• بوب متشائم للغاية؛ يريد شراء 100 NO مقابل 0.40 دولار.

ملاحظة: كلاهما مشترٍ! لا أحد منهما يملك الرموز التي يريدها الآخر!

في دفتر أوامر تقليدي، لا يمكن لهذين الطلبين سوى التحديق في بعضهما البعض ولن يتمكنا أبداً من التنفيذ. في Polymarket، إذا حدث شراء مقابل شراء (والرموز متكاملة)، سيقوم المشغل بمطابقة هذين الطلبين معاً!

1. يخصم العقد الذكي 60 pUSD من حساب أليس.

2. يخصم العقد الذكي 40 pUSD من حساب بوب.

3. يأخذ العقد الذكي هذا الـ 100 pUSD، ويقفلها كضمان، ثم يستدعي وظيفة _mintلإنشاء 100 YES و 100 NO من العدم.

4. يرسل 100 YES إلى أليس.

5. يرسل 100 NO إلى بوب.

يجب أن يستند تشغيل هذه الآلية إلى شرط رياضي صارم: يجب أن يكون مجموع عطاءات المشترين أكبر من أو يساوي 1.00 دولار.

إذا قدمت أليس 0.60 دولار مقابل YES وقدم بوب 0.35 دولار مقابل NO، فإن المجموع هو 0.95 دولار فقط. لا يستطيع العقد الذكي سك زوج رموز كامل بقيمة 1.00 دولار بـ 0.95 دولار. ستفشل هذه المطابقة مباشرة.

آلية مطابقة MINT

من منظور صانع السوق، هذه الآلية هي السلاح النهائي لحل مشكلة "البداية الباردة". عندما يفتح السوق للتو، لا يحتاج صناع السوق إلى إنفاق المال لسك مجموعة من الرموز للاحتفاظ بها (مما سيشغل الكثير من الأموال). يحتاجون فقط إلى وضع أوامر شراء على جانبي YES و NO في وقت واحد (على سبيل المثال، 0.49 دولار لـ YES، و 0.49 دولار لـ NO). عندما يأتي مستثمرو التجزئة للبيع، سيؤدي ذلك إلى تشغيل منطق السك.

3.3 MERGE (مطابقة الدمج): إبادة السيولة

حيثما يوجد خلق، يوجد تدمير. MERGE هي العملية العكسية لـ MINT.

لنلقِ نظرة على حالة عكسية. السوق على وشك الإغلاق، والجميع يغلقون مراكزهم.

• أليس لديها 100 YES، وتريد البيع بسعر 0.60 دولار.

• بوب لديه 100 NO، ويريد أيضاً البيع بسعر 0.40 دولار.

ملاحظة: كلاهما بائع! لا أحد يرغب في دفع pUSD لشراء رموزهم.

في هذه المرحلة، ستعمل آلية Polymarket مرة أخرى. عند مواجهة بيع مقابل بيع، سيقوم المشغل بسحره مرة أخرى:

1. يأخذ العقد الذكي 100 YES من أليس.

2. يأخذ العقد الذكي 100 NO من بوب.

3. يستدعي العقد الذكي وظيفة _merge لتدمير هذه الأزواج المائة من YES+NO تماماً وفتح 100 pUSD من الخزانة.

4. يرسل 60 pUSD إلى أليس.

5. يرسل 40 pUSD إلى بوب.

تتمتع آلية الدمج بالخصائص الرياضية والمالية التالية:

• آلية انكماشية: ينخفض إجمالي عرض الرموز في النظام.

• قناة الخروج: تضمن أنه حتى بدون "مشترٍ"، طالما أن أسعار بيع YES و NO يمكن أن تصل إلى 1.00 دولار (في الواقع، التخلي عن 1.00 دولار من المساحة)، لا يزال بإمكان الجميع صرف النقود.

فهم طرق المطابقة الثلاث هذه يمنحك نظرة ثاقبة على دورة حياة سوق Polymarket:

• المرحلة المبكرة (MINT مهيمن): السوق قد فتح للتو، ولا توجد رموز. يقوم كل من الجانبين الصعودي والهبوطي بضخ الأموال باستمرار في النظام من خلال آلية MINT مقابل الحصول على رموز. يرتفع إجمالي العرض بسرعة.

• المرحلة المتوسطة (COMPLEMENTARY مهيمن): يتمتع السوق بسيولة وافرة، ومعظم التداولات هي تبادلات للرموز الموجودة. يستقر إجمالي العرض.

• المرحلة المتأخرة (MERGE مهيمن): تصبح النتائج أكثر وضوحاً، ويبدأ الجميع في إغلاق مراكزهم. يقوم كل من الجانبين الصعودي والهبوطي بتدمير الرموز من خلال آلية MERGE لصرف النقود. ينخفض إجمالي العرض.

يرجى ملاحظة أن هذه المسارات الثلاثة لا يختارها المشغل ذاتياً ولكن يتم تحديدها بصرامة من قبل قواعد توجيه العقد الذكي بناءً على اتجاه الطلبات (شراء مقابل بيع).

دورة حياة السوق

الفصل الرابع: التقسيم/الدمج/الاسترداد، ولماذا أرباحك وخسائرك خاطئة؟

بعد فهم آلية المطابقة، دعونا نلقي نظرة على ثلاث عمليات أساسية قد تستخدمها كل يوم ولكنك لم تفهم حقاً تأثيرها المالي: التقسيم (Split)، الدمج (Merge)، و الاسترداد (Redeem).

هذه العمليات الثلاث هي عمليات على المستوى الذري لـ Polymarket. إنها ليست "تداولات" (لا تمر عبر دفتر الأوامر، ولا تتكبد رسوماً)، ولكنها تتفاعل مباشرة مع العقد الذكي لتحويل الأصول.

• التقسيم: تعطي العقد 1 pUSD، ويعطيك العقد 1 YES و 1 NO. التكلفة دائماً بالضبط 1 دولار.

• الدمج: تعطي العقد 1 YES و 1 NO، ويعيد العقد 1 pUSD إليك. الربح دائماً بالضبط 1 دولار.

• الاسترداد: بعد أن يحدد السوق الفائز والخاسر، يتم استبدال الرمز الفائز بـ 1 pUSD، ويتم تصفير الرمز الخاسر.

مقارنة قبل وبعد عملية التقسيم

4.1 من يستخدم هذه العمليات؟

• صناع السوق: هم أكبر مستخدمي التقسيم. يحتاج صناع السوق إلى وضع أوامر على كلا الجانبين في وقت واحد، لكنهم لا يريدون شراء رموز في السوق (مما يتكبد رسوماً). يقومون بتقسيم 100,000 دولار مباشرة إلى 100,000 YES و 100,000 NO، ثم يضعونها في دفتر الأوامر.

• المراجحون: هم أكبر مستخدمي الدمج. عندما يعاني السوق من تسعير خاطئ مؤقت، مثل انخفاض YES إلى 0.40 دولار وانخفاض NO إلى 0.55 دولار، سيقوم المراجحون بسرعة بشراء 1 YES و 1 NO (التكلفة الإجمالية 0.95 دولار) ثم استدعاء الدمج فوراً لاستعادة 1 دولار، محققين ربحاً صافياً خالياً من المخاطر قدره 0.05 دولار. الشرط الرياضي واضح جداً: عندما يكون السعر(YES) + السعر(NO) < 1 - الرسوم، فمن البديهي الشراء والدمج.

لذا، عندما تحاول متابعة الأموال الذكية لمراجح أو الأموال الذكية لصانع سوق، يجب عليك تقييم تأثير التقسيم/الدمج على الأرباح والخسائر بدقة. خلاف ذلك، فهي ليست "أموالاً ذكية" تستحق الرجوع إليها.

حالياً، بما في ذلك Polymarket نفسها، لا يمكن لأحد حل مشكلة حساب الأرباح والخسائر. بالطبع، ربما خمنت ذلك - لقد حل insiders.bot هذه المشكلة بالفعل في حسابات الأرباح والخسائر ومتصفحات الأموال الذكية.

4.2 فخ الأرباح والخسائر: لماذا ربحك خاطئ؟

كما ذكرنا أعلاه، هذا هو الخطأ الأكثر شيوعاً في نظام Polymarket البيئي بأكمله. تعثرت جميع أدوات تتبع الأرباح والخسائر التابعة لجهات خارجية تقريباً، بما في ذلك بعض واجهات برمجة التطبيقات الرسمية، هنا.

دعني أحسب مثالاً لك، وسترى مدى عمق هذا الفخ.

الخطوة 0: افترض أن لديك رأس مال قدره 100 دولار. أنت متفائل بشأن سوق "كسر إيثيريوم حاجز 5000 دولار".

الخطوة 1: تنفق 50 دولاراً لتنفيذ تقسيم. الآن لديك 50 YES و 50 NO. يبقى نقودك 50 دولاراً.

الخطوة 2: تشعر أن 50 YES ليست كافية، لذا تذهب إلى السوق وتشتري 50 YES بسعر 0.40 دولار. تكلف 20 دولاراً. تبقى النقود 30 دولاراً.

الخطوة 3: تبيع الـ 50 NO التي لديك بسعر 0.35 دولار. تسترد 17.50 دولاراً. تصبح النقود 47.50 دولاراً.

الآن، لديك 100 عقد YES. ما هي تكلفتك الفعلية؟

كيف تحسب معظم لوحات المتصدرين (خوارزمية خاطئة):

ينظرون فقط إلى سجلات "التداول" الخاصة بك. يرون أنك اشتريت 50 YES، بتكلفة 20 دولاراً. يتجاهلون تماماً التقسيم (لأن ذلك ليس تداولاً).

لذا يعتقدون أن تكلفتك هي: 20 دولاراً / 50 = 0.40 دولار لكل منها.

إذا ارتفع سعر السوق الحالي لـ YES إلى 0.60 دولار، فسيظهرون ربحك كـ: 100 × 0.60 دولار - 20 دولاراً = 40 دولاراً.

كيف يجب أن تحسب فعلياً (خوارزمية صحيحة، وهي التي يستخدمها insiders.bot):

إجمالي تدفقك النقدي الخارج: 50 دولاراً (تقسيم) + 20 دولاراً (شراء) = 70 دولاراً.

إجمالي تدفقك النقدي الداخل: 17.50 دولاراً (بيع NO)

استثمارك الصافي: 70 دولاراً - 17.50 دولاراً = 52.50 دولاراً

تكلفتك الفعلية: 52.50 دولاراً / 100 = 0.525 دولار لكل منها.

إذا كان سعر السوق الحالي لـ YES هو 0.60 دولار، فإن ربحك الفعلي هو: 100 × 0.60 دولار - 52.50 دولاراً = 7.50 دولاراً.

هل ترى الفرق؟ تظهر لوحة المتصدرين أنك ربحت 40 دولاراً، لكنك في الواقع ربحت 7.50 دولاراً فقط. الـ 32.50 دولاراً من "الربح الوهمي" بينهما هو لأن النظام لم يتعامل بشكل صحيح مع تكلفة التقسيم وإيرادات بيع NO.

يجب أن تكون الصيغة الرياضية الصحيحة للأرباح والخسائر:

إجمالي الأرباح والخسائر = Σ(دخل البيع) + Σ(دخل الدمج) + Σ(دخل الاسترداد) - Σ(نفقات الشراء) - Σ(نفقات التقسيم) + القيمة السوقية للمركز الحالي

هذا هو السبب في أنك ترى بعض اللاعبين الكبار على لوحة المتصدرين يظهرون خسائر بالملايين، لكنهم في الواقع يجنون ثروة. لأن المراكز الرابحة، بعد استردادها، ستقوم العديد من الأدوات "بمسح" هذه المراكز من السجلات التاريخية، تاركة فقط تلك التي لا تزال في خسارة.

فخ حساب الأرباح والخسائر

الفصل الخامس: منحنى الرسوم

إذا كنت تتداول بشكل متكرر، ستجد أن رسوم Polymarket ليست نسبة مئوية ثابتة. أحياناً يتم فرض رسوم قدرها 10 دولارات لشراء عقد بقيمة 1000 دولار، وأحياناً 2 دولار فقط.

لماذا؟ دعونا نلقي نظرة على صيغة الرسوم المخبأة في عمق الكود:

الرسوم = C × معدل الرسوم × p × (1 - p) (حيث C هو مبلغ المعاملة، p هو السعر)

5.1 لماذا p(1-p)؟

افترض أنك تريد شراء 100 YES بمعدل 2%:

• إذا كان سعر YES هو 0.50 دولار: الرسوم = 100 × 2% × 0.50 × 0.50 = 0.50 دولار

• إذا كان سعر YES هو 0.90 دولار: الرسوم = 100 × 2% × 0.90 × 0.10 = 0.18 دولار

• إذا كان سعر YES هو 0.10 دولار: الرسوم = 100 × 2% × 0.10 × 0.90 = 0.18 دولار

هل ترى النمط؟ تكون الرسوم في أعلى مستوياتها عندما يكون السعر عند 0.50 (متطابق بالتساوي). عندما يقترب السعر من 0 أو 1 (النتيجة مؤكدة تقريباً)، تكون الرسوم منخفضة للغاية.

والأهم من ذلك، هناك تماثل. شراء YES بسعر 0.90 دولار وشراء NO بسعر 0.10 دولار متكافئان رياضياً. إذا تم فرض رسوم عالية عليك لشراء YES بسعر 0.90 دولار ورسوم منخفضة لشراء NO بسعر 0.10 دولار، فسيجن المراجحون بشراء NO ثم المراجحة من خلال آلية MINT. يضمن تصميم p(1-p) أنه بغض النظر عن الجانب الذي تعبر فيه عن رأيك، فإن تكاليف الاحتكاك التي يفرضها النظام متماثلة تماماً.

5.2 الجمال الرياضي الخفي

إذا كنت قد درست الإحصاء، فستكون على دراية كبيرة بالصيغة p(1-p). إنها صيغة التباين لتوزيع برنولي (رمي العملة).

في تصميم النظام بأكمله لـ Polymarket، p(1-p) هي "صيغة الله":

1. إنه منحنى الرسوم: كلما زاد عدم اليقين (التباين)، زادت الرسوم التي يفرضها النظام.

2. يعكس إنتروبيا المعلومات: عندما تراهن بنسبة 50%، فإنك تقدم أكبر قدر من المعلومات الجديدة للسوق، لذا فإن تكلفتك هي الأعلى.

من يدفع الرسوم؟ إنه دائماً المتلقي (Taker). الصانع (Maker) معفى دائماً من الرسوم.

تتوافق هذه الآلية تماماً مع الحوافز: عندما يكون السوق في أكثر حالاته عدم يقين (50/50)، سيتم فرض أعلى الرسوم على الداخلين الأوائل، مما يحمي صناع السوق من الصدمات غير الضرورية؛ بينما عندما يكون السوق مؤكداً تقريباً، تشجع الرسوم المنخفضة للغاية المراجحين على الدخول ودفع الأسعار نحو 1 أو 0 النهائي.

منحنى الرسوم

الفصل السادس: المخاطر السلبية (Negative Risk)، أو السحر الأكثر أناقة في التمويل اللامركزي

إذا كنت قد لعبت في أسواق متعددة النتائج مثل الانتخابات، أو الأوسكار، أو الأحداث الرياضية على Polymarket، فلا بد أنك واجهت أسواق المخاطر السلبية.

هذا هو الجزء الأكثر إرهاقاً للعقل في المقالة بأكملها، ولكنه يعكس أيضاً بشكل أفضل جماليات هندسة العقود الذكية.

ملاحظة: هذا هو أيضاً الجزء الذي حله مؤسسنا المشارك @DakshBigShit بعد ماراثون استمر 36 ساعة أثناء تطوير واجهة برمجة التطبيقات الخاصة بنا.

6.1 نقاط الألم في أسواق النتائج المتعددة التقليدية

افترض أن هناك أربعة مرشحين: A، B، C، D. أنت تكره A تماماً ومتأكد من أن A لا يمكنه الفوز. تريد "بيع" (short) A.

في سوق ثنائي تقليدي، تحتاج فقط إلى شراء عقد NO الخاص بـ A. ولكن في سوق متعدد النتائج، إذا خسر A، فهذا يعني أن واحداً من B أو C أو D يجب أن يفوز. لذا، "بيع A" يكافئ رياضياً وبصرامة "الشراء الطويل لـ B + الشراء الطويل لـ C + الشراء الطويل لـ D." (هذه الجملة مهمة جداً؛ اقرأها مراراً وتكراراً حتى تفهمها.)

إذا ذهبت إلى السوق واشتريت عقود YES لـ B و C و D بشكل منفصل، فستواجه مشكلة كبيرة: كفاءة رأس مال منخفضة جداً. لأنك تحتاج إلى دفع ثلاثة مبالغ منفصلة، وإذا كان مجموع أسعار هذه الثلاثة أكثر من 1.00 دولار، فقد تتكبد خسارة.

6.2 سحر محول المخاطر السلبية (NegRiskAdapter)

نشرت Polymarket عقداً ذكياً مخصصاً NegRiskAdapter لحل هذه المشكلة. يوفر وظيفة تسمى convertPositions.

الغرض من الوظيفة هو تحويل عقود NO الخاصة بك فوراً إلى عقود YES لجميع المرشحين الآخرين وإعادة مبلغ نقدي إليك.

دعونا نثبت رياضياً لماذا هذا التحويل يحافظ على القيمة.

إعداد السيناريو: هناك n من المرشحين.

• لديك A حصة من عقود NO للمرشح 1 و A حصة من عقود NO للمرشح 2 (أنت تبيع كلاً من 1 و 2).

• أنت تمتلك ما مجموعه m من عقود NO مختلفة (هنا m=2).

قبل التحويل، القيمة الحقيقية لممتلكاتك (عبر جميع الجداول الزمنية الممكنة):

• إذا فاز المرشح 1: يصبح NO_1 بلا قيمة، NO_2 يساوي 1 دولار. القيمة الإجمالية = A.

• إذا فاز المرشح 2: NO_1 يساوي 1 دولار، يصبح NO_2 بلا قيمة. القيمة الإجمالية = A.

• إذا فاز المرشح 3 (أي شخص لم تقم ببيعه): NO_1 يساوي 1 دولار، NO_2 يساوي 1 دولار. القيمة الإجمالية = 2A.

ما الذي يعطيك إياه العقد بعد استدعاء convertPositions؟

الصيغة هي: يعيد A × (m-1) نقداً، بالإضافة إلى A حصة من عقود YES للمرشحين 3، 4، ... n.

في هذا المثال، يعيد: A × (2-1) = A نقداً! بالإضافة إلى A حصة من YES للمرشح 3، A حصة من YES للمرشح 4...

بعد التحويل، القيمة الحقيقية لممتلكاتك (عبر جميع الجداول الزمنية الممكنة):

• إذا فاز المرشح 1: تصبح YES_3 و YES_4 الخاصة بك بلا قيمة. لديك فقط نقداً A. القيمة الإجمالية = A. (تساوي ما قبل التحويل!)

• إذا فاز المرشح 2: تصبح YES_3 و YES_4 الخاصة بك بلا قيمة. لديك فقط نقداً A. القيمة الإجمالية = A. (تساوي ما قبل التحويل!)

• إذا فاز المرشح 3: YES_3 الخاصة بك تساوي 1 دولار، والآخرون يصبحون بلا قيمة. بالإضافة إلى نقداً A. القيمة الإجمالية = A + A = 2A. (تساوي ما قبل التحويل!)

Q.E.D. بغض النظر عن كيفية تطور العالم، فإن القيمة قبل وبعد التحويل متساوية تماماً.

الإثبات الرياضي لتحويل المخاطر السلبية

6.3 لماذا هذه عملية زيادة إنتروبيا "غير قابلة للعكس في اتجاه واحد"؟

تتمتع آلية التحويل هذه بخاصية فيزيائية ساحرة للغاية: إنها في اتجاه واحد وغير قابلة للعكس.

يمكنك تحويل NO إلى YES + نقداً. لكن لا يمكنك أبداً تحويل YES + نقداً مرة أخرى إلى NO.

لماذا؟ لأنه على المستوى الأساسي للعقد الذكي، عندما تحول NO إلى YES، يقوم العقد في الواقع بإرسال عقود NO الخاصة بك إلى عنوان ثقب أسود (Burn)، ثم يستخدم مساحة الضمان التي تم تحريرها من هذا "لتصنيع" عقود YES جديدة. هذا لا يتطلب ضخ أموال خارجية جديدة.

ولكن إذا كنت تريد عكس ذلك وتحويل YES إلى NO، فأنت بحاجة إلى إنشاء ضمان جديد من العدم (لأن عقود NO تغطي نطاقاً أوسع بكثير من YES). لا يملك المحول السلطة لاستخدام أموال الخزانة.

هذا مثل كسر بيضة. NO هي البيضة الكاملة، التي تحتوي على كل الاحتمالات. عملية التحويل تشبه كسر البيضة، وفصلها إلى صفار (YES) وبياض بيض (نقداً). العملية تحافظ على القيمة، لكنك لا تستطيع أبداً تجميعها مرة أخرى في بيضة كاملة.

هناك فرصة مراجحة ضخمة هنا: إذا وجدت أن سعر NO لمرشح معين أكبر من إجمالي سعر YES لجميع المرشحين الآخرين، يمكنك شراء ذلك NO، واستدعاء convertPositions للحصول على نقود ومجموعة من YES، ثم بيع YES تلك فوراً. هذه هي أعلى مستوى من استراتيجية المراجحة الخالية من المخاطر في الأسواق متعددة النتائج.

الفصل السابع: المتطرفات الفيزيائية للسرعة

أخيراً، دعونا نتحدث عن البعد الأكثر وحشية للتداول: الوقت.

في التداول عالي التردد التقليدي، نناقش الميكروثانية (أجزاء من المليون من الثانية). في Polymarket، نناقش الملي ثانية. ولكن هناك تفاوت هيكلي ضخم هنا.

إذا كنت قد اختلطت في قسم التداول الخوارزمي على Reddit، فستجد أن جميع المبرمجين الذين يطورون روبوتات Polymarket اشتكوا من نفس الشيء: "لماذا يجب أن أنتظر دائماً 300 ملي ثانية لأوامر المتلقي (Taker)، بينما تستغرق أوامر الصانع (Maker) 25 ملي ثانية فقط؟"

7.1 لماذا أوامر الصانع سريعة وأوامر المتلقي بطيئة؟

• عندما تضع صانعاً (طلب محدد): يتم إرسال طلبك (بيانات التوقيع) إلى خادم Polymarket. يتحقق الخادم من صحة التوقيع ويدرج هذا السجل مباشرة في قاعدة بيانات CLOB (دفتر الأوامر) في الذاكرة. ثم يعيد إليك ACK (إقرار) فوراً. تحدث العملية بأكملها بالكامل خارج السلسلة وتتطلب كتابة واحدة فقط في قاعدة البيانات. الوقت المستغرق: ~25 ملي ثانية.

• عندما تضع متلقياً (طلب سوق): يتم إرسال طلبك إلى الخادم. يجد محرك المطابقة أن طلبك يمكن أن يتطابق مع صانع في دفتر الأوامر. في هذه المرحلة، يجب على المشغل بدء خط أنابيب تسوية معقد:

  1. تقرير مسار المطابقة الذي يجب استخدامه (COMPLEMENTARY، MINT، أو MERGE).

  2. بناء بيانات معاملة على السلسلة تحتوي على توقيعات من كلا الطرفين.

  3. إرسال المعاملة إلى الـ Relayer.

  4. يقوم الـ Relayer بتقدير الغاز وتخصيص Nonce.

  5. بث المعاملة إلى عقد Polygon.

  6. انتظار تأكيد العقد بأن هذه المعاملة لن تتراجع بسبب عدم كفاية الرصيد أو لأسباب أخرى.

  تمتد العملية بأكملها عبر خدمات مصغرة متعددة وحتى تلمس حواف البلوكشين. الوقت المستغرق: ~250 إلى 300 ملي ثانية.

7.2 ماذا يعني هذا الـ 250 ملي ثانية؟

هذه الفجوة الفيزيائية البالغة 250 ملي ثانية تشكل بعمق نظام Polymarket البيئي.

أولاً، من الصعب جداً التداول المسبق على Polymarket. لأن جميع أوامر المتلقي يجب أن تصطف في انتظار قيام المشغل بالمعالجة، لا يمكنك قطع الصف عن طريق زيادة رسوم الغاز. التداول المسبق في Mempool ليس مشكلة هنا مؤقتاً.

ثانياً، الميزة المطلقة لاستراتيجيات الصانع. لأن الإلغاء (Cancel) وأوامر الصانع كلاهما عمليات خارج السلسلة، فهي تستغرق 25 ملي ثانية فقط. عندما تظهر أخبار عاجلة، يمكن لصناع السوق الأذكياء استخدام فرق الوقت البالغ 250 ملي ثانية لإلغاء أوامرهم قبل تسوية أوامر المتلقي (يسمى هذا تجنب الاختيار المعاكس).

7.3 وقت التوقف لمدة 90 ثانية كل صباح ثلاثاء

هناك تفصيل آخر غير معروف عن الوقت. وفقاً للوثائق الرسمية، كل يوم ثلاثاء في الساعة 7:00 صباحاً بالتوقيت الشرقي، يعيد محرك مطابقة Polymarket التشغيل. خلال هذه الـ 90 ثانية تقريباً، يتوقف النظام عن معالجة أي مطابقات، وتعيد واجهة برمجة التطبيقات خطأ HTTP 425 (مبكر جداً).

والأكثر قسوة، قدم الإصدار الثاني آلية نبض القلب (Heartbeat). إذا لم يتلق الخادم نبض قلب من العميل في غضون 10 ثوانٍ، فسيقوم تلقائياً بإلغاء جميع الطلبات المفتوحة لهذا المستخدم. خلال هذه الـ 90 ثانية من إعادة التشغيل، يتم مقاطعة نبضات قلب صناع السوق قسراً، وسيتم مسح أوامرهم بشكل جماعي بواسطة النظام.

تمثل هذه الـ 90 ثانية "فراغ سيولة" حقيقياً في النظام. بالنسبة لنماذج تسعير الخيارات، كيفية تسعير ثيتا (تضاؤل الوقت) لهذه الـ 90 ثانية، وكيفية الاستيلاء على السوق عندما يستأنف المحرك العمل في الثانية 91، هو اللغز النهائي لأفضل المنصات واستوديوهات الكميات.

مقارنة الجدول الزمني للتأخير

الفصل الثامن: إعادة الهيكلة الملحمية للإصدار الثاني والمعركة النهائية ضد "التعبئة الوهمية"

إذا كنت قد قرأت حتى الآن، فقد استوعبت الإطار الأساسي لـ Polymarket. ولكن إذا كنت ترغب في الاستمرار في جني الأموال في هذا السوق في عام 2026، فيجب أن تفهم الزلزال الكبير الذي حدث للتو.

بين فبراير ومايو 2026، خضعت Polymarket بهدوء لترقية ملحمية لبنية الإصدار الثاني. لم تقم هذه الترقية بإعادة هيكلة الضمانات وصيغ الرسوم فحسب، بل الأهم من ذلك، أنها أطلقت المعركة النهائية لحل الخطأ الأكثر شهرة في أسواق التنبؤ، وهو التعبئة الوهمية (Ghost Fill).

8.1 ما هي التعبئة الوهمية؟ انقطاع الحالة بين السلسلة وخارجها

قبل ترقية Polymarket V2، كان عدد لا يحصى من صناع السوق والروبوتات الكمية يعانون من ظاهرة: يلتقط روبوتك فرصة رائعة في سوق على مستوى 5 دقائق (مثل BTC صعود/هبوط 5 دقائق) ويرسل فوراً طلب متلقٍ. تعيد واجهة برمجة تطبيقات Polymarket فوراً: "تمت المطابقة! نجاح!" تنبثق تنبيهات Telegram الخاصة بك أيضاً بحماس "تمت التعبئة". ولكن عندما تفتح Polygonscan للتحقق من مستكشف البلوكشين، تجد أن هذه المعاملة مميزة كـ REVERTED (فاشلة)، مما يضيع رسوم الغاز دون جدوى. ويبقى مركزك دون تغيير.

يظهر دفتر الأوامر بوضوح تطابقاً، لكن البلوكشين يقول إن شيئاً لم يحدث. هذه هي التعبئة الوهمية (Ghost Fill).

لفهم جوهر هذا الخطأ، نحتاج إلى العودة إلى البنية التحتية التي تمت مناقشتها في الفصل الأول: مطابقة خارج السلسلة + تسوية على السلسلة.

عندما يتطابق طلب شراء أليس وطلب بيع بوب في دفتر الأوامر المحدد المركزي (CLOB) خارج السلسلة، يرسم النظام فقط علامة يساوي بين هذين الطلبين في قاعدة البيانات. يتطلب تحويل الأصول الفعلي قيام المشغل بتجميع توقيعات الطرفين وتقديمها إلى سلسلة Polygon لتنفيذ TransferFrom.

هذا يخلق فجوة زمنية قاتلة. خلال هذه الفجوة الزمنية، قد تتغير حالة محفظة المستخدم.

8.2 مساران للهجوم للتعبئة الوهمية

في الإصدار الأول المبكر والإصدار الثاني الذي تم إطلاقه للتو، استغل المتسللون وصناع السوق الخبيثون هذه الفجوة الزمنية لابتكار طريقتين للهجوم مدمرتين للغاية:

• أولاً: هجوم incrementNonce منخفض التكلفة (عصر V1)

  في بنية V1، كانت حالات الطلب تدار بواسطة nonce عالمي (رقم عشوائي). يمكن للاعبين الخبيثين نشر طلبات وهمية جذابة للغاية بجنون (Spoofing) خارج السلسلة. عندما يعض مشترٍ حقيقي، ويظهر الطلب تطابقاً خارج السلسلة، يمكن للاعب الخبيث استدعاء وظيفة incrementNonce على السلسلة قبل أن يقدمها المشغل.

  تكلف هذه العملية القليل جداً (بضعة سنتات في الغاز) ولكن يمكنها إبطال جميع طلبات nonce القديمة لهذا العنوان فوراً. عندما يقدم المشغل المعاملة المطابقة على السلسلة، يجد العقد الذكي أن nonce غير صحيح ويتراجع مباشرة. يهرب المهاجم دون أن يصاب بأذى، بينما لا يفوت المشتري الحقيقي فرصة التداول فحسب، بل قد يتم تضليله أيضاً بواسطة دفتر الأوامر الوهمي.

• ثانياً: "طلبات الزومبي" من المحافظ الفارغة (بداية V2)

  أزالت ترقية V2 الـ nonce العالمي واستخدمت تجزئة طلب واحدة لإدارة حالات الإلغاء، مما أدى إلى حظر المسار الأول. لكن المتسللين اكتشفوا بسرعة ثغرة أعمق: خداع الرصيد. يمكن لمستخدم خبيث إيداع 1000 دولار في محفظة، وتوقيع مجموعة من أوامر الحد بقيمة إجمالية قدرها 10,000 دولار، ثم تحويل كل الأموال خارج المحفظة فوراً. لأن طلبات Polymarket موقعة دون اتصال، طالما أن التوقيع صالح ولم يتم إلغاء موافقة الرمز (Approval)، تبدو هذه الطلبات "شرعية" لمحرك المطابقة خارج السلسلة. ولكن في الواقع، رصيد هذه المحفظة هو 0.

  عندما يأكل روبوتك "طلبات الزومبي" هذه، ويقدم المشغل على السلسلة، ستطرح وظيفة مكتبة Solady الأساسية TransferFrom خطأ (رمز الخطأ 0x7939f424) بسبب عدم كفاية الرصيد على الجانب الآخر. تتراجع معاملتك مرة أخرى.

8.3 لماذا لا تواجه البورصات التقليدية هذه المشكلة؟

قد تسأل: لماذا لا تواجه Binance أو البورصات اللامركزية التقليدية (مثل Uniswap) هذه المشكلة؟

لأن Binance مركزية تماماً؛ أموالك موجودة في قاعدة بياناتها، ولديها سيطرة مطلقة. تحدث المطابقة والخصم بشكل ذري. وUniswap لامركزية تماماً على السلسلة؛ يتم إكمال المطابقة والخصم في نفس المعاملة لعقد ذكي، أيضاً بشكل ذري.

لكن Polymarket اختارت بنية هجينة: المطابقة خارج السلسلة تسعى للسرعة، بينما التسوية على السلسلة تسعى للشفافية. في الوقت نفسه، يتم تخزين أموال المستخدمين في محافظ ذاتية الحفظ تماماً (مثل EOA أو Gnosis Safe)، حيث يتمتع المستخدمون بحقوق تصرف مطلقة ويمكنهم تحويل الأموال في أي وقت.

طالما أن حالات التمويل على طرفي المطابقة مرتبطة بمحفظة المستخدم ذاتية الحفظ والحرة حقاً، فسيظل "انقطاع الحالة" موجوداً دائماً.

8.4 الحل النهائي: محفظة الإيداع (الخزانة المرتبطة)

في 4 مايو 2026، أعلنت Polymarket رسمياً عن تحديث رئيسي على مستوى البروتوكول الأساسي، مما قلل مباشرة من نسبة التعبئة الوهمية من ذروة بلغت 30% إلى 0.17%، وتتجه نحو الصفر.

كيف فعلوا ذلك؟ الجواب هو إدخال محفظة الإيداع (الخزانة المرتبطة).

أدركت Polymarket أخيراً أن الطريقة الأساسية لحل التعبئة الوهمية هي تقييد "الحرية المطلقة" للمستخدمين في الأموال. بموجب البنية الجديدة، لم يعد بإمكان المستخدمين المشاركة مباشرة في المطابقة خارج السلسلة بمحافظهم الأصلية (EOA). يجب عليك أولاً إيداع الأموال في محفظة إيداع تسيطر عليها عقد ذكي.

في هذه الخزانة:

• لديك ملكية ولكن ليس لديك حقوق تصرف فورية مطلقة.

• عندما تضع طلباً خارج السلسلة، تقفل الخزانة منطقياً الرصيد المتاح المقابل.

• إذا كنت ترغب في سحب الأموال من الخزانة، فإن عملية السحب هذه (إلغاء الحالة) نفسها يتم تعيين تكلفة زمنية فيزيائية لها. يجب أن تخضع للتحقق من قبل العقد الذكي للتأكد من أنه ليس لديك طلبات معلقة قيد المطابقة.

من خلال إدخال طبقة التخزين المؤقت هذه، تربط Polymarket قسراً حالة المطابقة خارج السلسلة وحالة التمويل على السلسلة معاً، مما يلغي تماماً إمكانية "طلبات المحفظة الفارغة". هذا ليس مجرد انتصار هندسي بل هو أيضاً تسوية عميقة وإعادة بناء للتناقض بين "الحفظ الذاتي" و"كفاءة التداول" في التمويل اللامركزي.

8.5 ترقيات جوهرية أخرى في الإصدار الثاني

بالإضافة إلى الحل النهائي للتعبئة الوهمية، تتضمن بنية الإصدار الثاني العديد من الترقيات العميقة التي تغير مشهد السوق:

• نقل قوة pUSD: في 28 أبريل، تحولت الضمانات الأساسية بالكامل من USDC.e إلى pUSD. سمح هذا لـ Polymarket باكتساب السيطرة على الأصول الأساسية ذات العائد، مما مكنها من تزويد المستخدمين بمكافآت احتفاظ سنوية تصل إلى 4.00%. أصبحت pUSD البنية التحتية الجديدة لكفاءة رأس المال.

• تنفيذ الصيغة المثالية p(1-p): تم التخلي عن التقريب التقريبي لـ min(p, 1-p) من عصر الإصدار الأول، وتم تعديل صيغة الرسوم مباشرة إلى صيغة تباين برنولي المثالية p × (1-p). تسمح النعومة المطلقة رياضياً لنماذج تسعير المراجحين بأن تكون أكثر دقة.

• إزالة مطبات السرعة الاصطناعية: في الأيام الأولى، لحماية صناع السوق من الضرب بواسطة روبوتات واجهة برمجة التطبيقات، قام الكود بترميز تأخير للمتلقي يصل إلى 500 ملي ثانية. مع تحسن أداء محرك الإصدار الثاني وإدخال آلية نبض القلب (قطع الاتصال لمدة 10 ثوانٍ يمسح الطلبات)، أزال الفريق الرسمي تماماً مطبة السرعة الاصطناعية هذه في نهاية فبراير، معلناً أن Polymarket دخلت رسمياً في معركة التداول عالي التردد (HFT) على مستوى الميكروثانية. (هذا هو السبب أيضاً في أننا في insiders.bot نستعد لفتح مصدر واجهة برمجة التطبيقات قريباً للانضمام إلى هذه المعركة.)

الخلاصة: الرؤية من خلال هذه الآلة من الصفر

من اللحظة التي تنقر فيها لوضع طلب:

• يتم إرسال توقيعك إلى دفتر الأوامر خارج السلسلة.

• يحرق الـ Relayer غازه لتمهيد الطريق لك.

• يبحث المشغل عن مسار المطابقة الأمثل لك من بين COMPLEMENTARY و MINT و MERGE.

• يستخرج منحنى الرسوم بأناقة تكاليف احتكاك ضئيلة باستخدام الصيغة p(1-p).

• إذا كانت عمليتك معقدة، سيقوم NegRiskAdapter حتى بأداء كيمياء الحفاظ على المواد من أجلك.

في النهاية، يتم تسوية كل شيء خلال تلك الـ 250 ملي ثانية الحاسمة. (هذا هو السبب أيضاً في أن insiders.bot تعتبر شفافية وسرعة متابعة التداولات أمراً حاسماً.)

أموالك لم تختفِ. إنها تتبع فقط بصرامة القوانين الفيزيائية لهذه الآلة الدقيقة المسماة ctf-exchange-v2، وتتدفق إلى حيث يجب أن تذهب.

في المرة القادمة التي ترى فيها احتمالات شائنة أو فرصة مراجحة مغرية على Polymarket، لا تتسرع في النقر على شراء. أولاً، قم بتشغيل تروس هذه الآلة في عقلك.

بفهم هذه "الفاء" الأساسية، جنباً إلى جنب مع "الداو" الصحيح، ستكون بالتأكيد لا تقهر.

ملاحظة: نسخة PDF من هذه المقالة جاهزة أيضاً. تابع @insidersdotbot وأرسل رسالة مباشرة بكلمة "PDF" للحصول عليها بسرعة.

المراجع

[1] وثائق Polymarket الرسمية: إعادة تشغيل محرك المطابقة وآلية نبض القلب.

[2] وثائق Polymarket الرسمية: الرسوم وصيغة حساب p(1-p).

[3] الكود المصدري للعقد الذكي Polymarket/ctf-exchange-v2 (GitHub).

[4] NegRiskAdapter.sol: التنفيذ الرياضي للتحويلات متعددة النتائج.

[5] leolabs.me: "لماذا أرباحك وخسائرك في Polymarket خاطئة" (تحليل محاسبة التقسيم/الدمج).

[6] Reddit r/algotrading & Binance Square: إعلانات إزالة تأخير المتلقي في Polymarket (فبراير 2026).

[7] دليل ترحيل Polymarket V2: الانتقال من USDC.e إلى pUSD (أبريل 2026).