توقيع الأمر يمنح إذناً بالتداول وفق شروط محددة، ولا يعني حدوث الصفقة. قد تقبله API، وقد يطابق الدفتر جزءاً منه، ثم تفشل معاملة التسوية رغم ذلك.
يتتبّع المقال الخامس من آلية عمل Polymarket وKuest التفويض وراء دفتري YES وNO المترابطين. نمر عبر طبقات النظام المنفصلة: ما يوقّعه المشارك، وما تفرضه خدمة المطابقة، وما تسجله البلوكشين فعلياً.
ابدأ بتعليمات، ثم تتبّع الأصول
نحتفظ بسؤالنا الافتراضي: «هل سيعلن المرصد A درجة حرارة للمدينة B تبلغ 30.0°C على الأقل عند 12:00 UTC في التاريخ C؟» شراء رمز YES يعني اقتناء أصل النتيجة المحدد، أما توقيع أمر BUY فيجيز اقتناءه فقط.
نستخدم سوقاً ثنائية قياسية من Conditional Tokens Framework، أو CTF، ووحدات ضمان عامة. تفترض أمثلة المبالغ ست منازل عشرية وكفاية الأموال والصلاحيات، وتستبعد الغاز والتمويل؛ وتظهر الرسوم منفصلة حين تُذكر.
تستخدم الشروح التالية معايير توقيع عامة وأمثلة CTF Exchange عامة وتدفقات أصول افتراضية. يجب أخذ المحافظ وأنواع الأوامر والرسوم المدعومة لكل منصة من وثائق تكاملها العامة الحالية.
ثلاثة أنواع تفويض تؤدي أعمالاً مختلفة
يجيز توقيع الأمر تعليمات تداول محددة. وتعرّف مصادقة API الخدمة بطالب مخوّل. أما توقيع دفعة المحفظة فيجيز مجموعة مستقلة من استدعاءات المحفظة، مثل تحديد سماح إنفاق.
تعرّف بيانات اعتماد API الخدمة بطالب مخوّل؛ وهي ليست المفتاح الخاص للمشارك ولا تستبدل توقيع الأمر. يوفر دليل المحافظ والمصادقة العام في Polymarket مثال منتج موثقاً.
كائنات منفصلة وفحوص منفصلة. لدفعة المحفظة nonce وموعد نهائي خاصان بها؛ لا يصبح هذان الحقلان جزءاً من أمر التداول.
يحدد EIP-712 تجزئة الرسائل المنظمة وتوقيعها. يمكن لنطاقه ربط التعليمات بسلسلة واسم تطبيق وإصدار وعقد تحقق، لمنع قبول توقيع موجّه لنطاق في نطاق آخر.
توضح شفرة توقيع CTF Exchange V2 العامة نطاق EIP-712 خاصاً بالتطبيق. اسم النطاق أو إصداره جزء من السياق الموقّع، لا دليل على قبول منصة أخرى الرسالة نفسها. وتعتمد حدود إعادة الاستخدام أيضاً على حالة العقد الفعلية وقواعد التحقق فيه.
المبالغ تتضمن السعر
في تعريف أمر CTF Exchange V2 العام، تشمل التعليمات الموقّعة الرمز والجانب ومبلغي maker وtaker وهويات الحسابات، إلى جانب حقول أخرى. يجيز التوقيع الرسالة المحددة، لا أي سعر تصادف أن تعرضه الواجهة لاحقاً.
يسمّي maker هنا الحساب الذي يوفر الأصول، حتى حين يأخذ أمره السيولة فوراً. يختلف اسم الحقل عن دور التداول maker، أي الأمر الذي يبقى معلّقاً قبل أن يتداول أمر آخر مقابله.
في BUY، يمثل makerAmount الضمان المعروض ويمثل takerAmount الحصص المطلوبة. عرض 60 مقابل 100 YES يشفّر حداً 60 ÷ 100 = 0.60؛ وفي SELL الذي يعرض 100 YES مقابل 60، يصبح السعر takerAmount ÷ makerAmount.
لا يوجد حقل سعر موقّع مستقل يتجاوز هذه النسبة. تغيير السعر الظاهر دون إعادة بناء المبالغ المقابلة وتوقيعها لا يغير الشروط المصرّح بها.
قد يصف الطابع الزمني وقت إنشاء الأمر دون أن يكون موعد انتهاء قابلًا للفرض. يجب على التكامل التمييز بين الحقول الموقّعة وتعليمات الخدمة، وفحص معانيها في مواصفة الأمر العامة الحالية.
التحقق يقرر إمكان دخول الأمر إلى الدفتر
قبل تقديم الأمر، تحقق من الأصل المقصود وحد السعر والكمية والحساب ونوع الأمر المدعوم. لا تُغني فحوص العميل وإقرار API عن نجاح تسوية العقد.
خطوة السعر هي الزيادة المسموح بها بين الأسعار المعروضة. افحص مواصفات السوق المنشورة الحالية قبل التوقيع. يثبت فحص العميل ورد الخدمة وقاعدة العقد أشياء مختلفة؛ عرض حد أدنى وحده لا يثبت قيداً على السلسلة.
الأموال والصلاحيات فحصان مختلفان: يحتاج BUY ضماناً قابلاً للاستخدام وسماح إنفاق كافياً لعقد التسوية، ويحتاج SELL رموز النتيجة والموافقة على نقلها. التوقيع وحده لا يوفر أياً منهما، وفحص الرصيد عند القبول لا يجمّد كل تغيير لاحق في الحساب.
تعني Post-only أن التعليمات تستهدف إضافة أمر معلّق لا أخذ السيولة فوراً. افحص التركيبات وسلوك الرفض الموثقين للمنصة؛ التسمية وحدها لا تحدد كل تنفيذ برمجي.
تخبر مدة سريان الأمر خدمة المطابقة بما تفعله بالكمية غير المنفذة:
- GTC — صالح حتى الإلغاء: أبقِ الكمية المتبقية المؤهلة في الدفتر.
- GTD — صالح حتى موعد: اسمح ببقائها إلى انتهاء محدد.
- FAK — نفّذ المتاح وألغِ الباقي: نفّذ الكمية المتاحة فوراً وتخلّص من الباقي.
- FOK — نفّذ الكل أو ألغِ: اشترط إمكانية تنفيذ كامل الكمية المطلوبة أو لا تنفّذ شيئاً.
أمر الخدمة ذي الانتهاء وموعد العقد الموقّع التزامان مختلفان. تحقق من موضع فرض الانتهاء في المواصفة الحالية، ومصير المعاملات المرسلة بالفعل. وجود حقل في الطلب لا يثبت بحد ذاته ضماناً من العقد.
المطابقة لا تزال تحتاج تسوية ناجحة
لنفكر في نقاط التحقق التعليمية هذه: موقّع، ثم مقبول أو معلّق، ثم مطابق، ثم مرسل، ثم مؤكّد. قد يُرفض الأمر قبل القبول؛ وقد ينتج الأمر المقبول عدة مطابقات جزئية ومعاملات تسوية. تشرح التسميات المسؤوليات ولا تعرّف تعداد API عاماً.
تترك المطابقة الجزئية كمية لمطابقة لاحقة إن سمحت مدة السريان. وتحتاج التسوية الفاشلة إلى مطابقة الحالة الفعلية قبل إعادة المحاولة.
يوضح عقد CTF Exchange V2 العام المطابقة المخولة وفحوص العقد قبل نقل الأصول. وتشرح أمثلة التداول المباشر والسكّ والدمج في المقال 4 تحركات الأصول الممكنة ومتطلبات تمويلها.
المعاملة ذرية: إذا تراجع تحويل أو فحص لازم، تعود تغييرات حالتها. لا يلغي ذلك معاملة أخرى نجحت بالفعل، وقد تستهلك المعاملة المتراجعة غازاً رغم ذلك.
تحدد تجزئة المعاملة معاملة مرسلة، لا شراءً ناجحاً. افحص إيصالها وحالة التأكيد المطلوبة في الشبكة المختارة. إلى أن تُعرف النتيجة، ينبغي للواجهة الحفاظ على عدم اليقين بدلاً من إعلان تسليم الأصول.
احتفظ في واجهة المشغّل بمعرّف الأمر والكمية المطابقة ومرجع المعاملة منفصلة. إذا فشلت معاملة أو بقيت نتيجتها مجهولة، فتحقق من مآلها الفعلي قبل الإعادة؛ تغيير تسمية محلية لا ينقل الأصول.
التنفيذ الجزئي يستهلك الأصل المعروض
لنفترض أن BUY المعلّق يعرض 60 ضماناً مقابل 100 YES، وأن أول تنفيذ يحصل على 40 YES عند 0.60 تماماً. دون الرسوم، يستهلك 24 ضماناً ويترك 36 ضماناً من السعة الموقّعة، أي ما يعادل 60 YES بالسعر نفسه.
ويستهلك SELL المعلّق الذي يعرض 100 YES مقابل 60 ضماناً مقدار 40 YES في ذلك التنفيذ ويتلقى 24 ضماناً. مبلغ maker المتبقي هو 60 حصة، لا 36 ضماناً. لدى الأمرين 60 YES متبقية للتداول، لكن عداديهما المتبقيين على السلسلة يستخدمان أصلين مختلفين.
التنفيذ نفسه لـ40 حصة، لكن وحدتي العداد مختلفتان. التنفيذ عند الحد بالضبط، والرسوم مستبعدة.
تعمل حسابات CTF Exchange V2 العامة بوحدات أساسية صحيحة. وفق نموذج القسمة التناسبية إلى أسفل المستخدم أدناه، يساوي المبلغ المأخوذ المبلغ المقدّم مضروباً في مبلغ taker الموقّع ومقسوماً على مبلغ maker الموقّع، مع التقريب إلى أسفل. تحتاج المطابقة الدقيقة قواعد التقريب للمسار الفعلي.
مثلاً، بيع 1.000001 حصة من أمر موقّع يعرض 3 حصص مقابل 1.8 ضمان يحسب 1,000,001 × 1,800,000 ÷ 3,000,000 ويقرّب إلى 600,000 وحدة ضمان أساسية. لذلك تحتاج التنفيذات الصغيرة والرسوم قواعد تقريب التنفيذ البرمجي؛ ضرب أسعار العرض المقربة لا يكفي للمطابقة الدقيقة.
للرسوم سجل مستقل
نفترض شراءً مباشراً لـ100 YES مقابل 60 ضماناً، ورسماً افتراضياً 0.60 على كل مشارك. يحتاج المشتري 60.60 ضماناً، ويتلقى البائع 59.40. المتبقي 1.20 هو مجموع الرسوم، فتُحتسب كل أموال المشتري.
رسوم افتراضية لا معدل حالي. خروج المشتري 60.60 = استلام البائع 59.40 + مجموع الرسوم 1.20؛ وتنتقل 100 YES موجودة إلى المشتري.
في هذا المثال المحدد، تُضاف رسوم BUY إلى حاجة المشتري النقدية، وتُخصم رسوم SELL من الحصيلة. يجب فحص الرسوم الفعلية ومستلميها وتقريبها للمنصة والمسار المختارين؛ المثال ليس جدول رسوم.
للإلغاء حدوده
يتعلق طلب إزالة أمر مفتوح بكميته المتبقية غير المنفذة، ولا يعكس تنفيذات مكتملة. تعامل مع تأكيد الإلغاء وأي معاملة تسوية معلّقة كسجلين منفصلين؛ وافحصهما قبل إعادة استخدام الأموال.
إذا أُرسلت التسوية بالفعل، فلا يمكن لإلغاء لاحق في الدفتر أن يعد بإيقافها. افحص نتيجة المعاملة قبل افتراض بقاء الأصول متاحة، خصوصاً إذا نُفذ الأمر الأصلي جزئياً.
يمكن أن يحدث إلغاء الباقي وتسوية مطابقة أقدم معاً. لا تعكس أي من الحمايتين المؤجلتين معاملة ناجحة.
تقييد الحساب على نطاق أوسع ليس إلغاء أمر واحد. قد تختلف ضوابط الاستعادة في النطاق والتأخير والجهة المخولة. استخدم وثائق العقد والمنتج المنشورة للحساب الفعلي بدلاً من افتراض أن كل أداة توقف فوري.
لدى Deposit Wallet فترة تعليق وانتظار للطوارئ مستقلة قبل سحب الطوارئ أو إلغاء الموافقات. تعليق المحفظة وحده لا يعطّل تنفيذ الدفعات أو التحقق من التوقيع في تلك الشفرة؛ فهو ليس مفتاح إيقاف تداول فوري.
أسماء الإصدارات لا تعرّف التكامل
كان أمر CTF القديم في Polymarket يوقّع taker وexpiration وnonce وfeeRateBps. يزيل أمر CTF Exchange V2 المنفصل هذه الحقول ويضيف timestamp وmetadata وbuilder؛ ويبقى السعر نسبة مبالغ.
كما يزيل مستودع V2 الدالتين fillOrder/fillOrders، مع الإبقاء على مطابقة المشغّل عبر matchOrders. يختلف CTF Exchange V2 هذا عن بنية مراكز Protocol V2 في polymarket-v2-external؛ ولا ترث Kuest تحديثات أي من المستودعين تلقائياً.
غياب حقل انتهاء من بنية العقد لا يعني غياب الأوامر المنتهية من المنتج. تصف وثائق دورة الحياة الحالية في Polymarket نوع GTD على مستوى المنتج، ويميّز دليل المراكز سجلي CTF وProtocol V2. تحقق من مسار السوق الفعلي قبل بناء التكامل.
ما الذي ينبغي أن يفصح عنه مشغّل Kuest؟
يفصل دليل التشغيل العام في Kuest تطبيق المشغّل عن الخدمات المشتركة. أفصح للمشاركين عن مسار الحساب المدعوم وتقدير الرسوم الكامل وحالات القبول والمطابقة والتأكيد المنفصلة؛ هذه متطلبات منتج قابلة للرصد، لا تفاصيل تنفيذ داخلي.
تصف وثائق الرسوم العامة في Kuest مشاركة المشغّل في رسوم التداول وإمكان ضبط تقاسمها مع الشركاء المحيلين. توزيع رسم يختلف عن فرض رسم إضافي على القيمة الاسمية للصفقة. استخدم الإعداد العام الحالي وسجلات التسوية لشرح ما يدفعه المشارك.
للمشغّل ذي العلامة، هذا قرار تكامل محدد: الحفاظ على هوية builder الصحيحة، وعرض إجمالي التكلفة الفعلي، ومطابقة توزيعه مع سجلات التسوية. الرمز التعريفي أو الواجهة بعلامة وحدهما لا يضمنان القبول أو استحقاق رسوم أو إيراداً.
أطلق سوق توقعات خاصاً بك عبر Kuest بسياسة تنفيذ يفهمها المشاركون: الولايات القضائية للجمهور، وقواعد السوق ومسار الحسم الدقيقان، والكميات المطلوبة، ومسار المحفظة المدعوم، والإفصاح عن الرسوم، وحالات القبول والمطابقة والتأكيد المنفصلة.