خلال اليومين الماضيين شاهدت نقاشات حول قيام المؤسسات بإدخال رأس المال إلى السلسلة (On-Chain)، وأكبر إحساسي هو: ليس أن الجميع لا يريدون الاستفادة من كفاءة البلوكشين، بل إنهم لا يجرؤون على تسليم مبالغ كبيرة إلى نظام «يُوقَّع ويُنفَّذ فورًا، ثم تُجرى إعادة المراجعة بعد حدوث الخطأ». إذا تعطل محفظة المستثمرين الأفراد، فعندئذٍ قد يخسرون وحدهم ويتحملون المسؤولية؛ لكن إذا أخطأ الأمر مع المؤسسات أو الـ Vault أو RWA أو مدفوعات العملات المستقرة، فستمتد التبعات إلى التدقيق (Audit)، والامتثال (Compliance)، وتحديد المسؤولية، وأمان أصول العملاء. مع إطلاق Newton Protocol لنسخة Mainnet Beta هذه المرة، برأيي أن الجوهر ليس مجرد تقديم مفهوم «وكيل AI» جديد، بل هو سدّ أشد نقصٍ في الأتمتة على السلسلة، وهو «التحقق قبل التنفيذ». منطقها واضح نسبيًا: يقوم المطور أو الـ curator بإعداد القواعد مسبقًا عبر Policy، مثل أهلية المستثمرين، وحدود المراكز، عناوين التفويض، انحراف السعر، فحص القائمة السوداء، وحدود المبالغ لكل صفقة... ثم وقبل أن يتم تسوية المعاملة فعليًا، يقوم ويُقيمها شبكة Newton أولًا. إذا تطابقت مع القواعد تم السماح بالمرور، كما تُولَّد attestation قابلة للتحقق على السلسلة؛ وإذا لم تتطابق، يتم حظرها مباشرة. في السابق كانت كثير من السكربتات الآلية وkeeper تعمل أولًا ثم تُعالج المشكلات لاحقًا عبر المراقبة والتدخل اليدوي؛ أما Newton فيشبه إدخال التحكم بالمخاطر داخل مسار تنفيذ وقت التشغيل (runtime). بعد صدور VaultKit SDK، لا يحتاج الـ curator إلى كتابة كامل وحدة التحكم بالمخاطر من الصفر، بل يمكنه تجميع policy pack وربطها مباشرة مع الاستراتيجية. بدأت Base وEthereum أولًا، وبعدها—عندما يتم إدخال المزيد من الـ Vault وRWA وسيناريوهات الدفع—ستكون المنطقة التي تستحق الملاحظة فعلًا. طبعًا لا تتسرعوا في تقديس الأمور في مرحلة الـ Beta؛ فما زالت الكلفة والتأخير واستقرار الـ Operator ومعايير إعداد الاستراتيجيات تحتاج إلى اختبار عملي. لكن الاتجاه برأيي صحيح: التمويل على السلسلة يجب أن يكون قادرًا على استيعاب مبالغ كبيرة، ولا ينبغي أن يقتصر الأمر على السرعة فقط؛ بل يجب أيضًا أن نعرف ما هي المعاملات التي ينبغي اعتراضها. ما رأيكم: هل ستصبح صلاحيات onchain هذه معيارًا افتراضيًا (DeFi) للمؤسسات؟
@NewtonProtocol $NEWT #Newt