أعود باستمرار إلى إحساسٍ بسيط بعدم الارتياح في عالم العملات المشفّرة: فقد بنينا أنظمة يمكنها نقل القيمة بسرعة مذهلة، لكننا ما زلنا نعجز عن الإجابة عن سؤالٍ أبطأ وأكثر إنسانية — من المسموح له بنقلها، وتحت أي شروط، وكيف نثبت صحة الإجابة بعد حدوث الأمر؟ كانت هذه الفجوة واضحة منذ زمن طويل في التمويل اللامركزي المؤسسي وعمليات العملات المستقرة، والآن في التمويل الوكيلي، حيث يمكن للبرمجيات أن تعمل بشكل مستمر بينما تبقى القواعد المحيطة بها متفرقة عبر لوحات المعلومات وفحوصات خارج السلسلة والذاكرة البشرية. يضع بروتوكول نيوتن نفسه داخل هذه الفجوة باعتباره طبقة تفويض للمعاملات على السلسلة، تُطبَّق فيها القواعد قبل التسوية بدلًا من شرحها بعد ذلك.

يهم هذا التأطير لأن المشكلة لم تظهر فجأة. كانت تعود للظهور كلما حاولت العملات المشفرة الخروج من حافة الاستخدام بالتجزئة (retail) والانتقال إلى البنية التحتية الجادة. كانت الصناديق تريد حدود الإنفاق. وكانت البروتوكولات تريد فحص العقوبات. وكان مُصدرو الستيبلكوين يريدون قواعد التحويل. وكان المطورون الذين يبنون وكلاء ذكاء اصطناعي يريدون سياجًا أكثر متانة من مجرد «مُلحق تعليمات/برومبت» وأوضح من مراجعة يدوية. عمليًا، واجه كل محاولة لضمّ الامتثال أو السياسات إلى أنظمة البلوكشين الضعف نفسه: منطق السياسة كان موجودًا خارج مسار التنفيذ، ما يعني أنه يمكن الالتفاف عليه أو تجزئته أو إعادة كتابته بسرعة. يدّعي Newton الأساسي أن السياسة لا ينبغي أن تكون فكرة لاحقة. يجب أن تكون جزءًا من دورة حياة المعاملة نفسها.

أظن أن أقوى سبب لاتخاذ المشروع على محمل الجد، حتى لو بقي المرء متشككًا بشأن الطموح، هو أن Newton بُني كـ EigenLayer AVS ويُقدَّم كـمحرك سياسات لا مركزي لتفويض المعاملات على السلسلة. في الوثائق الرسمية، اللغة مباشرة: المقصود ترميز وإنفاذ حدود الإنفاق، وفحص العقوبات، ومنع الاحتيال، وقواعد الامتثال داخل العقود الذكية. التصميم لا يحاول استبدال التسوية. بل يحاول إدراج نقطة قرار قبل التسوية، حيث يمكن الموافقة على المعاملة أو حظرها وفق سياسة مكتوبة مسبقًا. يبدو ذلك متواضعًا على الورق، لكن في البنية التحتية للعملات المشفرة، تغييرات بسيطة في ترتيب العمليات غالبًا ما تهم أكثر من الشعارات الكبيرة.

البنية واضحة بما يكفي لأشرحها دون كثير من المراسم. يقوم مستخدم أو قيّم (curator) بكتابة سياسة في Rego، أو يختار واحدة من مكتبة قوالب. يمكن لهذه السياسة أن تتضمن إشارات على السلسلة (onchain) وخارج السلسلة (offchain) مثل الهوية أو قوائم الحظر/العقوبات أو حدود المخاطر أو قيود خاصة ببروتوكول بعينه. يتكامل العقد مع مقطع خفيف الوزن أو خطاف SDK. ثم، قبل أن تُسوى المعاملة، يقوم مشغّل شبكة Newton بتقييم السياسة وإصدار إثبات/إقرار تشفيري (cryptographic attestation). من المفترض أن تكون النتيجة قابلة للتحقق على السلسلة عبر وصل (receipt) أو سجل في مستكشف (explorer)، مع الحفاظ على البيانات الحساسة خاصة. بمعنى آخر، يحاول Newton جعل التفويض مفهومًا بدون أن يجعل البيانات الأساسية عامة.

هذا اختيار تصميمي مثير للاهتمام لأنه يكشف عن الوعد والتوتر معًا. تحتفل العملات المشفرة منذ وقت طويل بالشفافية، لكن التمويل في العالم الحقيقي لا يعمل على رؤية كاملة. بل يعمل على رؤية مقيدة، وتحكم قابل للتدقيق، وإفصاح انتقائي. يحاول Newton التوفيق بين هذه الحقائق مع تدفقات تحافظ على الخصوصية. تصف وثائقه ثلاثة أنماط للخصوصية — الهوية (identity) والسرّي/الملفوظ (confidential) والمؤقت/الزائل (ephemeral) — جميعها تستخدم مراجع بيانات مشفّرة واحدة، مع اختلاف من يقوم برفع البيانات وكيف تُحال إليها ضمن تقييم السياسة. هذا ليس تفصيل تنفيذ صغيرًا. إنه الفرق بين طبقة سياسات قد تتبناها المؤسسات فعلاً وبين طبقة تُرفض لأنها تُسرّب أكثر مما تحمي.

أعتقد أيضًا أن تركيز Newton على وكلاء الذكاء الاصطناعي (AI agents) توقيته استراتيجي. تؤطر الوثائق البروتوكول صراحةً حول أمن الوكلاء، مع سياسات لحدود الإنفاق لكل معاملة، وقوائم السماح للعقود، وقيود على مستوى الوظائف، إضافة إلى تقييد قائم على الوقت أو المعدّل. كما تضع الصفحة الرئيسية «التمويل الوكيل/الوظيفي» (agentic finance) ضمن أبرز حالات الاستخدام، وتصف سياج حماية للوكلاء المستقلين، ودُفعات/مستفيدين معتمدين (approved payees)، وإنفاذ الالتزامات (mandate enforcement)، والدفاع ضد هجمات حقن الأوامر (prompt-injection). هذا اختيار لغوي دال. يوحي بأن الفريق يرى مستقبلًا تُفوَّض فيه نوايا البشر بشكل متزايد إلى البرمجيات، لكن تكون فيه التفويض دون إنفاذ عبئًا. في ذلك العالم، السؤال المثير للاهتمام ليس ما إذا كان الوكيل يستطيع التداول أو الدفع أو إعادة التوازن. السؤال هو ما إذا كان يستطيع القيام بذلك داخل تفويض (mandate) يصمد أمام الضغط والارتباك والتلاعب.

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

هناك أيضًا المسألة الأصعب: احتكاك التبني. أي بروتوكول يجلس بين النية (intent) والتسوية (settlement) يضيف تبعية جديدة، والتبعيات الجديدة ليست مجانية أبدًا. قد تتحول إلى تأخير (latency)، وتعقيد تشغيلي، وكلفة دمج إضافية، ونقطة فشل ثالثة في مكدس (stack) يطلب أصلًا من المطورين إدارة المحافظ (wallets) والسلاسل (chains) والجسور (bridges) والـoracles وإدخالات الامتثال وتجربة المستخدم. يقول Newton إنه يعمل عبر الخزائن والستيبلكوينز وRWA والحسابات الذكية (smart accounts) والجسور، وأنه يمكن تشغيله مع سياسات مُعدّة مسبقًا وSDK يعمل كإضافة جاهزة (drop-in). ومع ذلك، تبقى العبء العملي: يجب أن يثق شخصٌ ما بمجموعة المشغلين (operator set)، وبمصادر السياسات، وبالإثباتات/الإقرارات، وأن يقبل البروتوكول كحارس بوابة شرعي بدل أن يكون مجرد قيد لإيجاد بدائل الالتفاف عليه.

أجد أقوى حالة استخدام للجهات المؤسسية هي الخزائن (vaults)، لأنها أوضح تجسيد للمشكلة التي يريد Newton حلها. مشغلو الخزائن يتخذون بالفعل قرارات تؤثر على كثير من المستخدمين، وهم يحتاجون أيضًا إلى ضوابط واضحة حول الأهلية، والأطراف المقابلة، وحدود التركيز، والـdrawdowns، ومراقبة المخاطر. تستهدف مواد إطلاق Newton هذا المجال صراحةً، قائلة إن السياسة تُفرض قبل تسوية المعاملات، وإن القيّمين يستلمون وصلات على السلسلة موقعة يمكن التحقق منها من قبل موزعين (allocators) أو جهات تنظيم. هذا تحول ذو معنى من «نَعِد بأن لدينا ضوابط» إلى «تم إنفاذ الضوابط هنا ضمن هذه القواعد، وفي هذه اللحظة». ومع ذلك، حتى هنا، يعمل النموذج فقط إذا احترمت القواعد عبر دورة حياة رأس المال كاملة، وليس فقط خلال اللحظات النظيفة عندما يتم عرض النظام.

أعتقد أيضًا أن الفكرة الأوسع للمشروع، سوق «إنترنت السياسات»، طموح أكثر من مجرد سطح المنتج الفوري. تقول المدونة الرسمية إن طبقة التفويض ستمتد خارج الخزائن (vaults) إلى الأصول الممثلة بالواقع (RWAs) والستيبلكوينز (stablecoins) والتجارة الوظيفية/الوكيلة (agentic commerce)، بحيث يمكن اكتشاف السياسات وإعادة استخدامها عبر هذا السوق. هذه رؤية جذابة لأنها تتعامل مع السياسة كبنية تحتية قابلة للتراكيب بدل كونها مجرد تجهيزات قانونية لمرة واحدة. لكن هذا يثير أيضًا أقدم سؤال في البنية التحتية داخل عالم العملات المشفرة: ما الذي يصبح معيارًا، وما الذي يبقى عرفًا محليًا؟ قد تكون السياسة التي تعمل لولاية قضائية واحدة أو لبنية صندوق واحدة أو داخل لجنة مخاطر محددة عديمة الفائدة في مكان آخر. إن قابلية إعادة الاستخدام قد تقلل الجهد، لكنها قد تسطّح أيضًا الفروق الدقيقة. لا يصبح السوق ذا معنى إلا إذا استطاع الحفاظ على السياق مع بقائه قابلًا للنقل.

لذلك عندما أبتعد للخلف، لا أرى Newton كإجابة أنيقة لمشكلة أنيقة. أراه محاولة جادة لتحريك العملات المشفرة طبقة واحدة أقرب إلى الأنظمة الخاضعة للحوكمة بدل أن تكون مجرد أنظمة قابلة للتنفيذ. هذا فرق حقيقي. يحاول المشروع إنشاء مسار تفويض قابل للتحقق، ومراعي للخصوصية، وقابل للبرمجة، مع البقاء مفيدًا للمؤسسات التي لا يمكنها التعامل مع كل معاملة كتجربة حرة الصياغة. إذا نجح، فغالبًا سيكون المستفيدون قيّمي الخزائن، وموزعي المؤسسات، ومشغلي الستيبلكوين، ومُصدري RWA، والفرق التي تبني وكلاء مستقلين تحتاج إلى حدود صارمة بدل توقعات مرنة. لكن الحدود مهمة أيضًا بقدر ذلك: قد يظل النظام ثقيلًا جدًا على المطورين الأصغر، أو شديد التحيز لذوي الموقف المتشدد من الحوسبة غير المصرح بها (permissionless)، أو شديد الاعتماد على انضباط الحوكمة بحيث لا يمكن افتراض أنه موثوق افتراضيًا. ما زلت أتساءل عما إذا كانت مستقبل التمويل على السلسلة ينتمي أكثر إلى التنفيذ، أم إلى الطبقة الهادئة التي تقرر ما الذي يُسمح للتنفيذ أن يصبح عليه.

@NewtonProtocol #Newt $NEWT