اليوم نتحدث عن Builder Codes لدى @grvt_io: لا تكتفِ بـ «Open API»؛ إنها نقطة تحوّل في خيارات معماريّة GRVT. في العام الماضي كان الجدل في عالم DEX يدور حول: «مطابقة كاملة على السلسلة مقابل مطابقة خارج السلسلة + تسوية على السلسلة». اختارت GRVT المسار الثاني: يتم تشغيل CLOB خارج السلسلة لتقليل زمن التأخير حتى يصبح بمستوى CEX؛ لكن الثمن هو أن طبقة المطابقة تُبقيها مغلقة المصدر، وبالتالي لا يستطيع صانعو السوق وفِرق الاستراتيجيات سوى ضبط الأمور عبر الـ API الرسمي. تقوم Builder Codes بترقية المدخلات من الـ API إلى طبقة تفويض على السلسلة: يحصل builder خارجي على صلاحية وكيل المستخدم عبر تفويض on-chain واحد (ربط main_account_id و builder_account_id)، ثم يوقّع على نفس مسار التسوية الذري على السلسلة، ويجري المطابقة والتصفية، ويشارك الأرباح وفق تدفّق أوامر المستخدم. ماذا تغيّر؟ 1) انتقلت GRVT من تحديد نفسها كـ «بورصة مطابقة للصفقات» إلى «بنية تحتية للمطابقة»؛ يمكن لصانع السوق، وفِرق الاستراتيجيات، وفِرق المستخدمين النهائيين تخصيص تجربة التداول على الواجهة الأمامية. 2) المفتاح الخاص للمستخدم الرئيسي لا يُعرَض للخارج؛ يأخذ builder «مفتاح توقيع محدود» فقط، وتختلف حدود الاستضافة جذريًا عن ذلك المسار لدى Hyperliquid (L1 مستقل + إجماع خاص). 3) تُوسّع حلقة المطابقة من «تدفّق تملّكه الشركة» إلى «إجمالي تدفّق النظام البيئي»، وقد تم بالفعل دمج Tealstreet وHummingbot. في النهاية، يكون الـ trade-off الحقيقي هو: مركزية طبقة المطابقة، وتسوية كاملة على السلسلة مع الإشراف الذاتي للمستخدم—وهذه هي نقطة الانقسام الجوهريّة بينها وبين Hyperliquid. #grvt