من المبتدئ إلى إدارة المخاطر: دليل عملي للأمان من HIP-3 موجه للمطورين

HIP-3（اقتراح تحسين Hyperliquid 3） تم إطلاقه على الشبكة الرئيسية منذ حوالي 3 أشهر، ومنذ إطلاقه، تجاوز حجم التداول التراكمي للأسواق المخصصة من قبل أطراف ثالثة 13 مليار دولار، مما يعني أن عملية “الإضافة الجديدة” تتغير من كونها عملية داخلية في البورصة إلى قدرة بنية تحتية يمكن للمطورين الخارجيين استدعاؤها مباشرة.

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

الابتكار في HIP-3 يكمن في تحويل هذه العملية من “موافقة المنصة” إلى “واجهة برمجة التطبيقات المفتوحة”: طالما توافرت الشروط، يمكن لأطراف ثالثة نشر أسواق عقود دائمة جديدة على نفس منصة التداول والتسوية، مما يسمح بنقل حق الإضافة من النظام إلى المجتمع بشكل منهجي. هذا التحسين لا يقلل فقط من عتبة الابتكار، بل يعزز أيضًا قابلية التوسع في السوق. ومع ذلك، فإن المخاطر الأمنية المحتملة الناتجة عن واجهات برمجة التطبيقات المفتوحة لا يمكن تجاهلها، ويظل ضمان التشغيل القانوني لهذه الأسواق وخلوها من الأنشطة الخبيثة قضية رئيسية في تصميم HIP-3 تتطلب تدقيقًا صارمًا.

0x1 Hyperliquid: الأساس الخاص بـ HIP-3

Hyperliquid هو بنية تحتية للتداول الدائم تعمل على سلسلة خاصة بها. بالنسبة لـ HIP-3، النقطة الأهم هي: أن عمليات المطابقة والتسوية والتصفية توفرها منصة البروتوكول بشكل موحد، ويمكن إعادة استخدام قدرات السوق، بدلاً من بناء نظام تداول من الصفر.

اعتمد Hyperliquid على بنية ذات طبقتين: #HyperCore：为合约交易优化的定制化 L1 区块链，每秒可处理 20 万笔订单，并具备确定性最终性。#HyperEVM: طبقة التطبيق، والتي يمكنها تشغيل العقود الذكية، ومتوافقة مع EVM.

السوق الأصلية لـ Hyperliquid (عقود دائمة يديرها المدققون) لا تزال تشبه إلى حد كبير عمليات CEX التقليدية: حيث تقوم الجهات الرسمية بنشر العقود الدائمة بناءً على رغبة المجتمع، ويُقرر سحبها بواسطة تصويت من عقد المدققين.

سيقوم بروتوكول Hyperliquid بدعم العقود الدائمة التي ينشرها المطورون (HIP-3)، وهو معلم رئيسي نحو جعل عملية إدراج العقود الدائمة لامركزية بالكامل.

0x2 HIP-3: الأسواق التي ينشرها المطورون

مفهوم HIP-3 بسيط جدًا: دون تعديل منصة Hyperliquid الأساسية للتداول والتسوية، يتم فتح القدرة على “إضافة أسواق دائمة” للمطورين الذين يستوفون الشروط. يتحمل المطور مسؤولية تحديد المعلمات الرئيسية للسوق وعمليات التسعير/الصيانة، بينما يستخدم البروتوكول محرك ضمانات وتسوية موحد لتنفيذ العمليات وإدارة المخاطر؛ ومن هنا، تتحول عملية “الإضافة” من عملية داخلية في المنصة إلى واجهة برمجة تطبيقات قياسية يمكن استدعاؤها.

ببساطة: يمكن للمطور نشر سوق عقد دائم يعتمد على محرك HyperCore، ويقوم بتحديد الأسعار وتعديل معلمات السوق بنفسه.

حدود مسؤولية المطور: في HIP-3، يتحمل المطور مسؤولية سوق واحد من نوع perp (السوق) من نوعين: تعريف السوق وإدارته.

تعريف السوق (Market definition): يختصرها الرسميون إلى تعريف oracle + مواصفات العقد. على مستوى العمليات، يتضمن على الأقل:

تعريف oracle: يتضمن تحديد سعر oracle الابتدائي ومصدر السعر. عند تعريف السوق، يجب على المطور تحديد أصل أو مصدر بيانات واضح، يصعب التلاعب به وله جوهر اقتصادي؛ وعند تسجيل الأصل، يجب تقديم سعر oracle الابتدائي.

مواصفات العقد: يتم تحديد معلمات السوق مثل “رمز الأصل/الوحدة الدنيا للطلب/الرافعة القصوى” في واجهة API (مثل coin، szDecimals، maxLeverage).

اختيار DEX: يشرع المطور أولاً في نشر DEX لعقد دائم (كل DEX يملك ضمانات خاصة به، دفتر أوامر، وإعدادات من قبل المطور)، ويمكنه اختيار أي أصل عرض أسعار كضمان لهذا DEX (مثل USDC)، وكل سوق دائم يرتبط بـ DEX معين.

إدارة السوق (Market operation): يذكر الرسميون أن ذلك يشمل ضبط أسعار oracle / حدود الرافعة المالية / تسوية السوق عند الحاجة، بالتفصيل:

تحديث الأسعار: عبر واجهة setOracle لتزويد السوق بأسعار oracle بشكل مستمر.

حدود الرافعة المالية: عبر تخصيص جدول ضمانات للأصل (margin table) لتقييد الحد الأقصى للرافعة المالية — حيث يتم تحديد حدود الرافعة المالية حسب حجم المركز، بحيث تبقى ضمن النطاق المسموح.

التسوية عند الضرورة: يمكن للمطور إيقاف التداول عبر واجهة haltTrading، مما يؤدي إلى إلغاء جميع الأوامر وتسوية المراكز بسعر السوق الحالي (mark price)؛ ويمكن استخدام نفس الإجراء لاستئناف التداول.

حاليًا، يدعم سوق HIP-3 فقط المراكز المعزولة (isolated-only)، ومن المتوقع أن يدعم مستقبلاً المراكز الشاملة (cross).

عملية إطلاق السوق بالكامل

1. Stake: يتطلب الشبكة الرئيسية من المطور أن يودع 500 ألف HYPE؛ وحتى لو أوقف جميع أسواقه على DEX، يجب أن يظل الالتزام لمدة 30 يومًا.

2. Build: بعد استيفاء شرط الإيداع، يمكن للمطور نشر DEX لعقد دائم. كل DEX يمثل بيئة تداول مستقلة: ضمانات مستقلة، دفتر أوامر، وإعدادات من قبل المطور.

3. تعيين الضمانات: يمكن اختيار أي أصل عرض أسعار كضمان لهذا DEX، ولكن إذا فقد هذا الأصل صلاحيته كضمان بدون إذن (بقرار من التصويت من المدققين)، فسيتم تعطيل DEX الذي يستخدمه كضمان.

4. إضافة الأسواق: يمكن نشر أول 3 أسواق مباشرة؛ ولإضافة أسواق جديدة، يجب الحصول على “حصة” عبر مزاد هولندي.

5. تشغيل الأسواق: بعد إطلاق السوق، يتحول عمل المطور إلى “تشغيل السوق بشكل مستقر”، أي إدارة السوق.

6. إلغاء الالتزام: بعد تسوية جميع الأسواق على DEX، يمكن فك قفل الـ 500 ألف HYPE، وسيتم وضع الطلب في قائمة انتظار لمدة 7 أيام، وخلال هذه الفترة لا يزال الالتزام عرضة للعقوبات.

مزاد هولندي: الدورة الحالية تستمر 31 ساعة، وسعر البداية هو ضعف السعر النهائي (سعر الصفقة/السعر الأدنى).

setOracle: ثلاثة أنواع من مدخلات الأسعار

في HyperCore، يُستخدم سعر oracle بشكل رئيسي لربطه وحساب رسوم التمويل (funding)، بينما يُستخدم سعر السوق (mark price) كقيمة مرجعية لمواقف الضمان والتصفية (وأيضًا لتحفيز TP/SL).

في السوق الأصلية، لا يُعتبر سعر السوق نتيجة مباشرة لعملية تزويد الأسعار، بل هو الوسيط بين ثلاثة أسعار محسوبة:

oraclePx + EMA(midPx - oraclePx)

متوسط السعر الأفضل (أفضل عرض، أفضل طلب، آخر صفقة)( (أسعار دفتر الأوامر المحلي)

متوسط السعر الوسيط بين أسعار العقود الدائمة في عدة بورصات مركزية)perp mid prices(

أما في HIP-3، فإن وظيفة سعر oracle وسعر السوق لم تتغير، لكن آلية الحساب تغيرت:

1. مدخلات setOracle

a. oraclePx (يجب أن يكون)

يتوافق مع التعريف في HyperCore.

b. markPx )اختياري(

يمكن تقديم 0 إلى 2 مجموعة من أسعار السوق الخارجية كقيم مرشحة للسعر الحقيقي.

c. externalPerpPx (يجب أن يكون)

كمصدر مرجعي لسعر السوق، لمنع انحراف مفاجئ في سعر السوق.

غالبًا ما ينشر المطورون عقد relayer لتزويد الأسعار، حيث يتم حساب oraclePx بواسطة relayer استنادًا إلى مصادر خارجية، ويمثل markPx سعرًا يتم حسابه بواسطة خوارزمية مخصصة من قبل relayer، وexternalPerpPx هو المتوسط المرجح لأسعار السوق في عدة بورصات مركزية.

2. سعر السوق الحقيقي

سعر السوق في HIP-3 لا يُستخدم مباشرة من خلال سعر setOracle:

يتم حساب local mark: median)أفضل عرض، أفضل طلب، آخر صفقة(.

يتم دمج local mark مع مجموعة من 0 إلى 2 من markPx، ثم يُؤخذ الوسيط ليتم تحديد سعر السوق الجديد.

3. قيود setOracle

تواتر التحديث: يجب أن يكون بين كل استدعاء وآخر على الأقل 2.5 ثانية، وإذا لم يتم تحديث markPx خلال 10 ثوانٍ، يُعاد إلى قيمة local mark.

حدود التغير: لا يتجاوز التغير في markPx ±1% في كل مرة؛ كما يتم تقييد جميع الأسعار ضمن نطاق 10 أضعاف سعر افتتاح اليوم.

)# آلية التسعير على مدار 24 ساعة وغير 24 ساعة: الاختلافات

في HIP-3، يدعم سوق العقود الدائمة أي أصل يتم إطلاقه، ويمكن تصنيف الأصول إلى تلك التي تتداول على مدار 24 ساعة (مثل BTC) وتلك التي تتداول خلال فترات محددة فقط (مثل الأسهم، التي لا تتداول خارج أوقات السوق). يحدد توقيت التداول هذا طريقة الحصول على السعر.

بالنسبة للأصول التي تتداول على مدار 24 ساعة (مثل BTC)، يمكن الحصول على سعر ثابت من خلال بورصات مركزية/لامركزية أو من خلال مصادر موثوقة:

![图片]###https://img-cdn.gateio.im/webp-social/moments-b08d44279708b862b9599dc0464dec7e.webp(

أما للأصول غير التي تتداول على مدار 24 ساعة (مثل الأسهم)، فلا يمكن الحصول على سعر موثوق إلا خلال أوقات السوق، ويجب استخدام آلية تسعير مختلفة خلال فترات الإغلاق.

كمثال على سوق العقود الدائمة للأسهم على trade.xyz:

خلال أوقات السوق، يتم الاعتماد على أسعار موثوقة من مصادر خارجية مثل Pyth.

خلال الإغلاق، يتم تعديل السعر بناءً على سعر الإغلاق السابق، مع ضغط الطلب الداخلي، مع تحديد سعر السوق ضمن نطاق ±1 / max_leverage من سعر الإغلاق السابق (مثلاً، تسلا 10x -> 10%).

)# التصفية

يعتمد HIP-3 بشكل رئيسي على منطق التصفية الخاص بـ HyperCore، حيث يتم تفعيل التصفية عندما يكون صافي قيمة المركز (isolated position value) غير كافٍ لتغطية الحد الأدنى للضمانات.

تُستند قرارات التصفية إلى سعر السوق، وليس إلى سعر صفقة معين.

صيغة سعر التصفية:

![图片]###https://img-cdn.gateio.im/webp-social/moments-f74c534a2be0f8301c5cf678261fc04d.webp(

side = 1 (طويل)، -1 (قصير)

l: معدل الضمانات المستمر

![图片])https://img-cdn.gateio.im/webp-social/moments-43ed3e020660f17493f6412f8c8e651a.webp(

ويتم تحديد قيمة MAINTENANCE_LEVERAGE من خلال مستوى ضمانات المركز (margin tier): حيث يُقرأ معدل الضمانات المستمر (mmr) من المستوى المعني:

![图片])https://img-cdn.gateio.im/webp-social/moments-0f3e321d617792925cf80f0754b2fbbb.webp(

إذا كانت هناك مستويات (tiers)، فإن سعر التصفية يُحسب بناءً على مستوى القيمة الاسمية للمركز، ويُستخدم معدل الضمانات الخاص بذلك المستوى.

margin_available

isolated: isolated_margin - maintenance_margin_required

بعد دخول حالة التصفية، يُعطى الأولوية لإغلاق المركز عبر أوامر السوق؛ وإذا أمكن تقليل المخاطر إلى منطقة آمنة، فإن باقي الضمانات تظل ملكًا للمتداول.

لكن في حالات نقص العمق أو الفجوات السعرية، قد يكون سعر الإغلاق الفعلي أعلى أو أقل بشكل كبير من سعر السوق، مما يخلق “فجوة تصفية”.

قيمة المركز المعزول (Isolated position value): قيمة المركز المعزول الحالية عند سعر السوق (بعد احتساب الأرباح والخسائر، وخصم الضمانات المرتبطة بالمركز).

ADL (Auto-Deleveraging):

في حالات معينة، يمكن لنظام ADL)Auto-Deleveraging( أن يتدخل كآلية احتياطية:

عندما تصبح قيمة المركز المعزول سلبية، يتم تفعيل ADL، حيث يتم تقليل أو تصفية مراكز الخصم من طرف مقابل حسب الأرباح غير المحققة والرافعة المالية، على سعر السوق السابق، لملء الفجوة، وتجنب وقوع ديون سيئة.

يتم ترتيب المراكز وفقًا للمعايير التالية:

![图片])https://img-cdn.gateio.im/webp-social/moments-c56af6a39a50ee7b052f4b33e83a5eda.webp(

السعر السابق (previous mark price): السعر الذي سجله النظام قبل تفعيل ADL.

مثال:

قبل تفعيل ADL، كان سعر السوق = 3000.

بسبب قيود setOracle، يمكن أن يُحدّث سعر السوق إلى أقصى حد عند 2970 (-1%).

لكن، بعد تنفيذ أوامر السوق، قد يتم تنفيذ الصفقة بسعر 2910، وهو أقل بـ3% عن السعر السابق، مما قد يؤدي إلى أن قيمة المركز المعزول تصبح سلبية، وبالتالي تفعيل ADL.

يختار ADL مراكز من طرف مقابل (الخاسرون) ويقوم بتصفية أو تقليل مراكزهم بسعر السعر السابق، لملء الفجوة، مع تحويل الخسارة إلى ربح للمراكز الأخرى.

0x3 نظرة عامة على المخاطر: القيود والمسؤولية الرئيسية

آلية العقوبات (Slashing): صلاحيات المساءلة

يقوم HIP-3 بتفويض “حق الإضافة والإدارة” للمطورين، مع وضع قواعد عقابية قابلة للتنفيذ في البروتوكول: يجب على المطورين إيداع HYPE، وإذا ثبت سوء إدارة، يمكن للمحققين التصويت على العقوبة وحرق (burn) حصتهم.

متطلبات الإيداع

يتطلب الشبكة الرئيسية من المطورين إيداع 500 ألف HYPE، وحتى لو أوقف جميع أسواقه، يجب أن يظل الالتزام لمدة 30 يومًا (لا يُرفع فورًا عند الإيقاف).

آلية التصويت والقرار

عند وجود عمليات سوق خبيثة، يمكن للمحققين التصويت باستخدام وزن الالتزام (stake-weighted vote) لتقرير العقوبة على المطور.

مبادئ الحكم

يؤكد الرسميون أن العقوبات لا تميز بين “خبيث / نقص الكفاءة / سرقة المفاتيح”، وإنما تعتمد على ما إذا كانت تصرفات المطور أدت إلى حالة غير فعالة، أو توقف طويل، أو تدهور في الأداء.

نسبة العقوبة

تُحدد نسبة العقوبة عبر تصويت المحققين، مع حدود قصوى:

• الحالة غير الفعالة أو التوقف الطويل: حتى 100%

• التوقف المؤقت: حتى 50%

• تدهور الأداء: حتى 20%

يتم حرق الرموز المودعة كعقوبة، ولا تُعوض للمستخدمين المتضررين.

مخاطر إعداد المعلمات

setOracle

أسعار oracle عادةً تأتي من خوادم relayer التي يديرها المطور، وتوجد مخاطر مركزية، مثل تسرب المفاتيح أو هجمات DDoS، مما قد يؤدي إلى تلاعب خبيث بأسعار oracle أو فقدان التثبيت.

haltTrading

يمكن للمطور إيقاف التداول عبر haltTrading، مما يلغي جميع الأوامر ويغلق المراكز بالسعر الحالي.

يجب استخدام هذا بحذر، خاصة في الحالات التالية:

عند اكتشاف هجوم أو تلاعب، قد يؤدي إيقاف التداول إلى إغلاق المراكز بسعر السوق، مما قد يحقق أرباحًا للمهاجمين ويؤدي إلى خسائر غير متوقعة.

setMarginTableIds / InsertMarginTable

InsertMarginTable: يحدد جدول ضمانات جديد، يحدد متطلبات ضمانات فئة معينة وأقصى رافعة مالية.

setMarginTableIds: يربط سوق معين بجدول ضمانات معين.

بالنسبة لأسواق ذات سيولة منخفضة أو قدرة منخفضة على السوق، فإن تحديد رافعة عالية جدًا قد يزيد من احتمالية تفعيل ADL.

التحول المفاجئ إلى جدول ضمانات جديد قد يغير نسبة الضمانات اللازمة للمستخدمين، مما قد يؤدي إلى تحول العديد من الحسابات من وضع آمن إلى وضع قابل للتصفية بشكل مفاجئ، مما يسبب عمليات تصفية متسلسلة.

setMarginModes

حاليًا، يدعم HIP-3 فقط الهامش المعزول (isolated)، ومن المتوقع أن يدعم مستقبلاً الهامش الشامل (cross). وجود سوق ذات سيولة عالية وأخرى منخفضة داخل نفس DEX قد يؤدي إلى انتقال مخاطر الهامش الشامل إلى الأسواق ذات السيولة المنخفضة، لذلك، قبل وجود حلول ناضجة، لا يُنصح المطورون باستخدام وضع الهامش الشامل.

مخاطر مصادر البيانات الخارجية (oracle)

بالنسبة للأصول التي تتداول على مدار 24 ساعة، تتعلق المخاطر بدقة واستقرار مصادر oracle الخارجية، بالإضافة إلى مخاطر مركزية خوادم relayer.

أما للأصول غير التي تتداول على مدار 24 ساعة، فالمخاطر الأكبر تتعلق بالحصول على سعر oracle خلال فترات عدم التداول، أو حسابه بشكل صحيح.

على سبيل المثال، trade.xyz، خلال فترات الإغلاق، يعتمد على آخر سعر خارجي وداخل السوق، مع قيود على التذبذب (مثل 1/max_leverage). في حالات التلاعب أو نقص السيولة، قد يؤدي ذلك إلى تصفية واسعة أو تفعيل ADL.

في 14 ديسمبر 2025، تم التلاعب بسعر XYZ100-USDC على trade.xyz، حيث أنشأ المهاجم مركز بيع 398 XYZ100 بقيمة تقارب 10 ملايين USDC، مما أدى إلى فقدان التثبيت، وتصفية العديد من المراكز الطويلة، واستمرار انخفاض السعر، مما تسبب في تصفية حوالي 13 مليون USDC من المراكز الطويلة.

![图片])https://img-cdn.gateio.im/webp-social/moments-46485922603bcc451881e82987685518.webp(![图片])https://img-cdn.gateio.im/webp-social/moments-3f11b34efd760ad2a07f657c92b39ba7.webp(

https://x.com/bartdothl/status/2000292798755684839

من ناحية أخرى، عدم وجود سعر oracle ثابت وموثوق خلال فترات عدم التداول يجعل السوق يعتمد على آخر سعر خارجي وسعر داخلي محدود، مما قد يؤدي إلى فجوات سعرية كبيرة عند إعادة فتح السوق، ويزيد من احتمالية التصفية الواسعة وADL.

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

0x4 استراتيجيات مراقبة المخاطر

1. سعر oracle المستقر

بالنسبة للأصول غير التي تتداول على مدار 24 ساعة، تكمن الصعوبة في تحديد سعر ثابت خلال فترات الإغلاق: نقص الأسعار الموثوقة، وزيادة احتمالية التلاعب أو الانحراف.

الحلول الشائعة تشمل:

• إيقاف تحديث سعر oracle مؤقتًا، أو تقييد التداول خلال تلك الفترة، مثلما تفعل بروتوكولات مثل Lighter التي تسمح فقط بتقليل المراكز خلال الإغلاق. كما تقلل بروتوكولات مثل Optium من الحد الأقصى للرافعة خلال الإغلاق، وتقوم بعمليات تصفية قسرية للمراكز الخارجة عن الحد.

• اعتماد آلية تسعير داخلية مشابهة لـ trade.xyz، حيث تعتمد على السيولة الداخلية والخوارزميات للحفاظ على التشغيل عند غياب البيانات الخارجية.

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

خلال فترات الإغلاق، يجب تجنب أن يتحول البروتوكول إلى “سعر داخلي خالص”، وبدلاً من ذلك، يُفضل إدخال مرجع خارجي يمكن الاعتماد عليه لتقليل مخاطر الانفصال المفاجئ.

المصادر المقترحة:

• Blue Ocean ATS: سوق بعد التداول/ليلي يوفر سعرًا مستمرًا خلال الإغلاق، ويستخدم كمصدر مرجعي أو لمراقبة الانفصال.

• IG weekend CFD quotes: عروض CFD خلال عطلة نهاية الأسبوع، يمكن أن توفر إشارات سعر بديلة، وتساعد على اكتشاف احتمالية فجوات السوق عند الافتتاح.

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

2( التحقق من السعر

مصادر أسعار oracle في HIP-3 تأتي من خوادم relayer التي يديرها المطور، وتوجد مخاطر مركزية، مثل تسرب المفاتيح أو هجمات DDoS، مما قد يؤدي إلى تلاعب خبيث في الأسعار أو فقدان التثبيت.

لذلك، يُنصح المطورون ببناء آلية تحقق من صحة الأسعار، تتيح لأي مستخدم أو جهة خارجية التحقق من صحة وعدالة السعر على السلسلة، مثل RedStone، حيث يتم تجميع سعر البيانات مع مصدرها وتوقيعها على السلسلة.

البيانات المفتوحة:

• المواصفات الخوارزمية: الكشف عن التفاصيل الدقيقة للخوارزمية وآلية العمل.

• قائمة مصادر البيانات: يجب أن تكون المصادر عامة، غير خاضعة لتدخل المطور، مع توثيق كامل لواجهات API والمعلمات.

• معايير دفع الأسعار: صلاحيات استدعاء setOracle، وتواتر التحديث، وحدود التذبذب.

b. إثبات السعر

لكل عملية setOracle، يتم إنشاء إثبات مطابق، يتضمن:

• المدخلات: رد المصدر الأصلي عند ذلك الوقت (أو البيانات المعيارية)، والطابع الزمني.

• الحساب: القيم الوسيطة التي يمكن إعادة حسابها، والنتائج الوسيطة لكل خطوة.

• المخرجات: سعر oracle المرفوع على السلسلة.

يتم تسلسل الإثبات، وتوليد proofHash، وتوقيعها من قبل oracleUpdater.

c. نشر الإثبات على السلسلة

يتم الاحتفاظ بقائمة من إثباتات ProofHash، وتخزينها في شجرة Merkle، ويتم نشر MerkleRoot على السلسلة بشكل دوري (مثلاً كل ساعة أو يوم).

d. التحقق

توفر أدوات مفتوحة المصدر أو صفحات ويب، يمكن إدخال فيها طابع زمني أو tx hash لعملية setOracle، للتحقق من البيانات، والتوقيعات، وMerkleRoot، ومقارنة سعر oracle الموثق مع الحسابات.

3. مراقبة المخاطر

تحويل عملية التحقق من السعر إلى عملية “قابلة لإعادة الحساب، وقابلة للمراجعة”، يعالج مشكلة موثوقية تزويد الأسعار، لكنه لا يمنع السوق من الانزلاق أو فقدان السيطرة أثناء التشغيل — مثل انقطاع التزويد، أو انحراف الأسعار، أو تدهور العمق، خاصة مع وجود حجم مراكز مفتوحة كبير، مما قد يؤدي إلى مخاطر نظامية من نوع ADL أو تصفية جماعية.

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

1. جانب السعر

a. فشل تزويد الأسعار من oracle

مؤشرات المراقبة:

• قياس مباشر من البيانات على السلسلة، مثل:

مستويات thresholds:

الإجراءات:

• المستوى 1: فحص صحة relayer، وتبديله إلى relayer احتياطي، وإصدار تحذير يتضمن تقرير الحالة ومعلومات relayer.

• المستوى 2: تقليل سقف OI عبر setOpenInterestCaps.

b. انحراف السعر عن السعر المرجعي

مؤشرات المراقبة:

![图片])https://img-cdn.gateio.im/webp-social/moments-7c1c3c62517dea1a5e3d2212cf94d88e.webp(

مستويات thresholds:

• المستوى 1: عندما تتجاوز 2 من بين A، B، D الحد الأقصى.

• المستوى 2: عندما تتجاوز 3 من بين A، B، C، D الحد الأقصى، وتستمر لعدد معين من الثواني.

الإجراءات:

• المستوى 1: تقليل سقف OI عبر setOpenInterestCaps.

• المستوى 2: مع استمرار الانحراف، يتم تحديث جدول الضمانات تدريجيًا، وتقليل الرافعة المالية بشكل تدريجي، وتفعيل آلية clamp في relayer.

• المستوى 3: مع استمرار التحذيرات، يقرر المطور إيقاف السوق عبر haltTrading.

2. جانب دفتر الأوامر

a. استنزاف العمق

المراقبة:

depth_band)±x%): كمية الأوامر الحقيقية ضمن نطاق سعر معين حول السعر الوسيط.

spread = bestAsk - bestBid: فرق السعر، لقياس مدى تماسك السوق.

aggressiveVolume_Δt: حجم الأوامر المنفذة خلال Δt، حسب جانب الطلب.

impact_ratio = aggressiveVolume_Δt / depth_band: نسبة التأثير.

عند ظهور أنماط معينة، يرتفع الخطر:

• انخفاض depth_band، مع ارتفاع spread و impact_ratio.

الإجراءات:

• المستوى 1: تقليل سقف OI عبر setOpenInterestCaps.

• المستوى 2: تقليل الرافعة المالية عبر setMarginTableIds، وإجبار بعض مراكز الرافعة العالية على التصفية.

b. الأوامر الوهمية

المراقبة:

ارتفاع مفاجئ ثم انخفاض حاد في depth_band خلال فترة قصيرة.

الإجراءات:

• المستوى 1: تقليل سقف OI.

• المستوى 2: إذا صاحبه انحراف سعر كبير، يُوقف السوق.

3. جانب المراكز

هدف المراقبة هو التعرف على تحول السوق من التداول إلى المضاربة على المراكز: عندما تتراكم OI بسرعة، وتتركز المراكز، ويقترب الربح والخسارة من الحد الأقصى، فإن أي اضطراب خارجي قد يتسبب في تصفية جماعية أو ADL. لذلك، عادةً، تكون أولوية مراقبة المراكز أقل من السعر ودفتر الأوامر.

a. زيادة OI قصيرة الأمد

المراقبة:

• OI_notional: حجم المركز المفتوح.

• Volume_24h_notional: حجم التداول خلال 24 ساعة.

• نسبة OI_notional / Volume_24h_notional: ارتفاع سريع يدل على انتقال السوق من تداول قصير الأمد إلى مضاربة، ويشير إلى احتمال تقلبات حادة.

الإجراءات:

• المستوى 1: إصدار تنبيه عند الوصول للحد الأقصى.

b. الربح والخسارة للأغلبية

المراقبة:

• الجانب الغالب (Majority Side): الجانب الذي يضم أكبر عدد من المراكز.

• متوسط سعر الدخول للمراكز الغالبة (avgEntry_major).

• حجم المراكز الغالبة (size_major).

• الربح والخسارة للجانب الغالب:

![图片])https://img-cdn.gateio.im/webp-social/moments-99f20a460fd512544a4857f863e5b4b5.webp(

• نسبة الربح والخسارة للجانب الغالب:

![图片])https://img-cdn.gateio.im/webp-social/moments-bef3f769bd6715e3607d810b785185f8.webp(

الإجراءات:

• المستوى 1: إصدار تنبيه عند الوصول للحد الأقصى.

• المستوى 2: مع استمرار التكرار، يُفكر في تقليل سقف OI عبر setOpenInterestCaps.

)# الخاتمة

الجوهر في HIP-3 هو: تحويل عملية “الإضافة” من قرار فردي إلى قدرة بروتوكولية يمكن استدعاؤها عند استيفاء الشروط — حيث يمكن للمطورين عبر الإيداع أن يطلقوا DEX خاص بهم لعقود دائمة على HyperCore، ويبدأون بنشر عدد محدود من الأسواق مجانًا، ثم يشاركون في مزادات للحصول على المزيد من الحصص، مما يجعل توسع السوق يتحول من “انتظار الموافقة” إلى “توسعة وفقًا للقواعد”.

لكن من الواضح أيضًا أن HIP-3 لا يلغي المخاطر، بل يعيد تشكيل مكانها وشكلها. الأجزاء التي كانت سابقًا تحت إدارة إدارة المخاطر في المنصة، أصبحت الآن تعتمد بشكل أكبر على جودة إدخال المطورين وعمليات التشغيل: تزويد الأسعار وتكرارها، اختيار وتقييد سعر السوق، تقسيم الرافعة المالية عبر جداول الضمانات، آلية التسعير خلال فترات الإغلاق للأصول غير 7×24H، وصلاحية إيقاف التداول (haltTrading) التي يمكن أن تزيد من الخسائر.

أي خطأ في أي من هذه العمليات قد يتسبب في تصفية مركزة عند عمق منخفض، مما يؤدي إلى فجوات وADL بشكل أكبر — المشكلة لم تعد في “هل يمكن الإضافة”، بل في “هل يمكن التشغيل بشكل مستقر بعد الإضافة”.

النهج الأساسي في البروتوكول لمواجهة هذا “تعهيد المخاطر” هو تحويل الصلاحيات إلى صلاحيات قابلة للمساءلة: الإيداع + تصويت المحققين على العقوبات، مما يحدد تكلفة واضحة لسوء إدارة المطورين؛ بالإضافة إلى فرض قيود على السعر والرافعة المالية (مثل التقييد، فترات التحديث، حدود التذبذب، العزل المسبق)، بهدف تقليل الحالات الأكثر خطورة إلى نطاق يمكن السيطرة عليه. وبالتالي، يصبح التحدي الحقيقي لـ HIP-3 هو: التوسع من خلال الانفتاح، والأمان من خلال القيود، والاستدامة من خلال التحقق والمساءلة.

HIP-3 لا يهدف إلى جعل الإضافة أكثر حرية فحسب، بل إلى جعلها أكثر معيارية — يمكن نشرها، وإدارتها، والمساءلة عنها. ولضمان استقرار التشغيل، يعتمد ذلك بشكل كبير على جودة تنفيذ مصادر البيانات، والرافعة المالية، ومعايير إدارة المخاطر، والمراقبة أثناء التشغيل. إذا كنت تعمل على تصميم معايير دخول السوق، ونماذج المعلمات، وأنظمة الإنذار والطوارئ، أو تحتاج إلى تدقيق ودعم أمني مستمر، فلا تتردد في التواصل مع BlockSec.