لا يمكن لبيتكوين تشغيل العقود الذكية، وهذا القيد هو التحدي التصميمي برمّته
إليك شيئًا يتجاوزه الناس. يعمل الاستيكينغ (إعادة الرهن) بنمط إيثيريوم لأن إيثيريوم لديه عقود ذكية تعبيرية. يمكنك برمجة منطق تجميد/إقصاء (slashing) معقّد، أو شروطًا تعسّفية، أو أي شيء تحتاجه الشبكة. لكن بيتكوين لا يملك شيئًا من ذلك. لغة سكربت بيتكوين محدودة عمدًا. لا توجد حلقات، ولا حالة غنية، ولا شيء يقترب مما يمكن أن تفعله العقود الذكية الحديثة.
لذلك كان على بابيلون حلّ الرهن من دون ثقة داخل نظام لم يُبنَ أصلًا لهذا النوع من التنسيق.
إنها مشكلة هندسية أصعب بكثير مما يَمنحها الناس حقها.
قوائم التوقيت (timelocks). إنشاءات تعدد التوقيعات (multisig). استخدام مدروس لما تسمح به بيتكوين فعلًا. لا توجد اختصارات عبر طبقة عقود ذكية لأنه لا توجد طبقة يمكن الاتكاء عليها.
أفكر باستمرار فيما يعنيه ذلك عمليًا. يمكن لإعادة الرهن في إيثيريوم أن تتطور بسرعة لأن المنطق يعيش داخل عقود مرنة. لا يستطيع بابيلون التحرك بهذه السرعة بحكم التصميم؛ فكل آلية يجب أن تتلاءم مع قيود بيتكوين، وهذا أبطأ لكنه أيضًا أصعب في كسره بطرق غير متوقعة، لأن مساحة ظهور الثغرات التي يمكن أن تختبئ فيها أقل.
أبطأ وأكثر صرامة، أم أبطأ وأكثر أمانًا؟ قد يكون هذان الشيئان الشيء نفسه هنا.
هل بناء الأمان على لغة برمجة سكربت محدودة عمدًا يجعل النظام كله أكثر جدارة بالثقة أم أنه يجعله أقل قابلية للتكيّف على المدى الطويل
الضمان الذي لا يغادر بيتكوين أبدًا قد يكون التفصيلة “المملة” التي تهم أكثر
ينشغل الجميع بالحماس تجاه عائد الستاكينغ وسرديات الأمان، لكن مشكلة الضمان في التمويل اللامركزي (DeFi) كانت دائمًا أعقد وأقلّ تداولًا. كل بروتوكول إقراض يريد التعرض لبيتكوين (BTC) ينتهي بالاعتماد على الرموز الملتفّة (wrapped)، وتحمل الرموز الملتفّة “ضريبة” صامتة؛ فأنت تثق بمن قام بإصدار (mint) هذا الأصل الملتف ليتأكد فعلًا أنه يحتفظ بما يدعمه. ينسى معظم الناس أن المخاطر موجودة إلى أن يحدث شيء ما وينكسر.
أعتقد أن “Trustless Bitcoin Vaults” هي الجزء من بايبليون (Babylon) الذي يُقلَّل من قيمته. ضمان للـDeFi دون التفاف، دون جسور (bridging)، ودون وجود جهة حافظة (custodian) تقف بين بيتكوين الخاص بك وبين القرض أو الموضع الذي تدعمه. هذه ليست ميزة لامعة، لكنها تعالج وضع الفشل نفسه الذي حرق الناس من قبل عندما تم استغلال جسر (bridge) أو تجمّدت عمليات السحب بواسطة جهة حافظة.
الشدّ المثير للاهتمام هنا هو ما إذا كانت بروتوكولات DeFi فعلًا تريد ضمانًا يبقى على طبيعته (native)، لأن جزءًا كبيرًا من البنية التحتية الحالية بُني على افتراضات مفادها التعامل مع الأصول الملتفّة مع مرونة قابلة للبرمجة. قد يعني الضمان الأصلي لـBTC عبر TBV قابلية أقل للتأليف (composability) مقابل افتراضات ثقة أقل.
أتساءل باستمرار إن كان صُنّاع المنتجات (builders) سيضحّون ببعض المرونة مقابل هذا الأمان، أم أن الراحة ستنتصر في النهاية.
#Bitcoin أغلقت الآن ثلاث شموع خضراء أسبوعية متتالية، لكن السعر لا يزال يتداول تحت مستوى المقاومة الأسبوعية الرئيسي عند 65,776 دولار. بالنسبة لي، يظل هذا المستوى بمثابة خط فاصل. حتى يتمكن $BTC من استعادة السيطرة وإغلاق أعلى من 65.8 ألف دولار على الإطار الأسبوعي، تظل تحيزاتي على المدى الأعلى هبوطية.
قد يؤدي الرفض من هنا إلى تراجع قصير المدى آخر. ومع ذلك، لست أتوقع حركة كبيرة قبل إغلاق شمعة الشهر.
لم تكن تجارة التجزئة تريد اللامركزية فعليًا؛ كنا نريد شبكة أمان
هذه الفكرة غير المريحة التي خطرت لي أثناء التداول على GRVT الأسبوع الماضي: أغلب متداولي التجزئة لا يهتمون بالحفاظ على التوصيل الذاتي (self custody) إلا لحظة يتعرضون فيها للأذى بسبب منصة مركزية، وعندها يكون الوقت قد فات ليتغير أي شيء. نتحدث كثيرًا عن رغبتنا بالتحكم بمفاتيحنا نحن، لكن عندما يصبح التنفيذ بطيئًا أو متعثرًا ولو قليلًا، نتخلى عن هذا المبدأ فورًا ونعود إلى ما يبدو سريعًا.
GRVT مبني حول هذا التناقض نفسه. محرك مطابقة بسرعة 600 ألف TPS يمنحني السرعة التي أحتاجها يوميًا فعليًا، بينما تأتي تسوية ZK في الخفاء تحت السطح؛ الشيء الذي لا أفكر فيه إلا عندما يحدث خطأ. أنا لا أتحقق من الإثباتات قبل كل صفقة، أنا أتحقق من سعر التنفيذ والانزلاق (slippage) تمامًا مثل أي جلسة أخرى.
لذا، السؤال الحقيقي هو: هل اللامركزية تهمنا فقط بأثر رجعي، كنوع من التأمين ننساه حتى نحتاجه؟ إذا كان هذا صحيحًا، فليست المنصات التي تفوز هي التي تَعِد بالاستقلالية وتُكثر الحديث عنها، بل تلك التي تكون سريعة بما يكفي كي لا نفكر في شبكة الأمان إطلاقًا، حتى تنقذنا عندما يلزم الأمر.
سقف $GRVT عند 1 مليار من المعروض يبدو وكأنه ثانوي تقريبًا مقارنةً بهذا اللغز السلوكي.
هل تفكر فعلًا في الحفظ الذاتي أثناء التداول، أم فقط بعد أن ينكسر شيء ما؟
السؤال الذي أعود إليه دائمًا هو: من الذي يحمل فعليًا مفاتيح الترقية؟
$NEWT
إن مخزن نيوتن (Newton Keystore) عبارة عن تجميعة (rollup) متخصصة، وكل تجميعة في هذه المرحلة عادةً ما يكون لديها بعض مفاتيح الـ multisig أو مفاتيح الإدارة التي يمكنها دفع الترقية أو إيقاف النظام إذا حدث خلل. هذا أمر طبيعي في المراحل المبكرة من البنية التحتية، لكنه يعني أيضًا أن نموذج أمان zk والصيغة الخاصة بالأجهزة الموثوقة (TEE) بالكامل يمكن أن يتم تجاوزه من قبل من يتحكم في هذا المفتاح. وكونها نسخة بيتا على الشبكة الرئيسية (Mainnet beta) يعني تقريبًا أن “عجلات التدريب” لا تزال موجودة، وأريد أن أعرف بالضبط من يوجد على ذلك الـ multisig وما هي العتبة (threshold) قبل أن أتعامل معها على أنها بلا ثقة (trustless). إن طبقة الأتمتة القابلة للتحقق ليست قابلة للتحقق بالكامل إذا كانت مجموعة صغيرة ما زالت تستطيع قلب مفتاح.
أنا لست ضد وجود مفاتيح الترقية في وقت مبكر، فهذا مجرد واقع بالنسبة للتجميعة (rollups) الجديدة. لكني أريد جدولًا زمنيًا عامًا يوضح متى يحدث فعليًا لا مركزية التحكم أو متى يتم التخلي عنه (renounced). مخاطر مفتاح الإدارة هي الشيء الوحيد الذي لا تطرحه المواد التسويقية أبدًا.
المقارنة بين نيوتن وشبكات القائمين بالتنفيذ ليست تلك التي كتبها أحد حتى الآن
أستمر في رؤية نيوتن يُطرح بجوار ضجيج الذكاء الاصطناعي العام بدلًا من منافسيه الحقيقيين. هذا كسول. المقارنة الحقيقية هي مع Gelato Network و Keep3r Network، وهما لاعبان راسخان يتعاملان مع تنفيذ المهام الأساسية عند الطلب. لا يتحقق أيٌّ منهما من أن فعل الوكيل يطابق فعليًا ما سمح به المستخدم؛ فهما فقط ينفّذان التفعيل ويثقـان بالسكريبت الذي كتبه. كامل عرض نيوتن هو سد هذه الفجوة تحديدًا عبر برهان تشفير بدلًا من الثقة العمياء في بوت القائم بالتنفيذ. الإلغاء هو المكان الذي تصبح فيه هذه العملية سهلة الاستخدام حقًا، وهو أمر لا يُقدَّر بما يكفي. يمكن للمستخدم الذي يمنح وكيلًا صلاحية عبر zkPermissions أن يُلغي تلك الصلاحية في أي لحظة. وبما أن القاعدة موجودة في Keystore وليست ضمن تسليم بمفتاح خاص، فإن إلغاءها لا يتطلب تدوير المحافظ أو نقل الأموال في أي مكان. ببساطة تحذف/تُوقف كائن صلاحية، فيفقد الوكيل ترخيصه فورًا—دون فوضى، وبدون نافذة تعرّض معلّقة. قارِن ذلك ببرنامج بوت تلغرام يحمل مفاتيحك الفعلية؛ فالإلغاء هناك يعني عمليًا أن تتمنى أن مشغّل البوت يستمع.
يعتمد نيوتن على TEE لفرض السياسة قبل التسوية، ويبدو الأمر محكمًا حتى تذكُر أن TEE ما زال عبارة عن عتاد تُصنّعه جهة مُورِّدة، ويعمل ببرنامج ثابت تتحكم به تلك الجهة. يفترض نموذج الأمان الكامل أن التوثيق/الاعتماد على مستوى العتاد لا يمكن تزويره أو اختراقه على مستوى الشريحة. لكن التاريخ يقول غير ذلك: توجد حالات واقعية تم فيها كسر بيئات التنفيذ الموثوقة عبر هجمات القنوات الجانبية التي لم يتنبّه لها أحد حتى وقع الأمر. لستُ أقول إن إعداد نيوتن ضعيف، بل أقول إن إثبات zk وTEE معًا لا يكونان أقوى إلا بقدر أضعف افتراضات العتاد المتضمَّنة في التصميم.
أريد أن أعرف أي مُورِّد لـTEE يستخدمونه بالفعل، وكيف تبدو سياسة الإفصاح لديهم إذا ظهرت ثغرة يومًا ما. يبقى تعريضي محدودًا حتى يصبح ذلك أمرًا منشورًا. الثقة في العتاد هي المتغير الوحيد في هذه السلسلة كاملة الذي لا أستطيع التحقق منه بنفسي.
إن أول وكيل حقيقي لدى نيوتن هو مجرد روبوت شراء متكرر، وبصراحة هذه هي الخطوة الذكية
إن أول وكيل حقيقي لدى نيوتن هو مجرد روبوت شراء متكرر، وبصراحة هذه هي الخطوة الذكية كان الجميع يتوقع أن يطلق نيوتن مجموعة تداول متعددة العوامل لافتة للنظر. لم يحدث ذلك. العامل الأول الذي يعمل على البروتوكول هو وكيل شراء متكرر (Recurring Buy Agent)، يتيح للمستخدمين أتمتة عمليات شراء العملات المشفرة المجدولة مباشرةً على السلسلة (onchain) بدل الاعتماد على وظيفة كرون الداخلية لدى بورصة مركزية. إنه ممل عن قصد، وكونه مملاً تمامًا هو ما تريده عندما تطلب من المستخدمين العاديين الثقة في نظام صلاحيات جديد تمامًا باستخدام محافظهم.
كنت أكره فكرة أن يكون رأس المال جالسًا في الهامش دون أي فائدة تمامًا بينما أنتظر إعدادًا ليتحقق. مشكلة «الوزن الميت» هذه هي ما تحله GRVT بالفعل بفضل رصيدها الموحد للهامش؛ فليس ضماني فقط متروكًا في مكانه، بل يتم توجيهه عبر Aave وCentrifuge لتحقيق عائد بينما يظل داعمًا لمراكز التداول المفتوحة.
وهذا يغيّر الحسابات عندما يتعلق الأمر بحجم الصفقات. عادةً تفصل بين مكدس كسب العائد وبين رأس مال التداول الفعّال لأن خلطهما يبدو محفوفًا بالمخاطر أو مزعجًا من الناحية التشغيلية. هنا، يكون الرصيد نفسه يقوم بالعملين معًا: تمويل تعرضي للعقود الآجلة الدائمة على الذهب أو النفط أو العملات المشفرة، وفي الخلفية يقوم بالتضاعف بهدوء.
الكفاءة الرأسمالية بهذا الشكل نادرة، لأن معظم المنصات تجبرك على الاختيار: إما أن أموالك تكون خاملة وآمنة أو تكون نشطة ومكشوفة. الحصول على الأمرين معًا دون نقل الأموال يدويًا بين محافظ أو بروتوكولات، هو نوع توجيه العائد الذي يراعي فعلاً كيف يفكر المتداولون في تكلفة الفرصة.
إن وجود $GRVT على سقف ثابت قدره <0-0/>, يضيف طبقة من الندرة إلى نظام لا يكتفي فيه البورصة بمطاردة حجم التداول من أجل كونه هدفًا بذاته، بل تبني منفعة فعلية في كيفية تحرك رأس المال.
أنا أتابع كيف يؤثر ذلك على TVL مع إدراك المزيد من الناس أن الأرصدة الخاملة لا يجب أن تظل خالية.
وليست لدي قناعة بأن السلسلة تستطيع تحمّل العبء قضيت عطلة نهاية الأسبوع في تمحيص بيتا شبكة نيوتن الرئيسية بدلًا من النوم. الفكرة الأساسية بسيطة. قبل أن يتم إدراج أي معاملة يقوم بها وكيل ذكاء اصطناعي في كتلة، يجب أن تمر عبر فرض سياسات ما قبل المعاملة تعمل داخل البيئات الموثوقة (TEEs) ومدعومة بحجج إثبات بالمعرفة الصفرية (ZKPs). هذا ليس خيارًا من واجهة المستخدم. بل هو قيد صارم يقع بين نية الوكيل والحالة المتغيّرة التي يتم تنفيذها فعليًا؛ بمعنى أن الصفقة إما أنها تستوفي كائن الأذونات، وإلا فلن تلامس الـ mempool على الإطلاق.
إليك ما يزعجني بشأن إعداد فرض السياسات قبل تنفيذ الصفقة. تقوم نيوتن بمراجعة المعاملة وفقًا للسياسة قبل التسوية، صحيح، لكن هذا الفحص نفسه يستغرق وقتًا، وأي نافذة زمنية على السلسلة هي نافذة يمكن لأي باحث/مستكشف استغلالها. إذا رأى بوت صفقتك المقصودة من وكيلك وهي تنتظر في قائمة التحقق، فبإمكانه القفز للأمام والقيام بالـ front run (السبق) لتنفيذ الصفقة الفعلية بمجرد أن تمر مرحلة التحقق. يثبت دليل zk أن المعاملة سليمة، لكنه لا يخفي المعاملة عن mempool أثناء حدوث هذا التأكيد. وهذه ثغرة لم أرَ أحدًا يعالجها بعد.
لستُ أقول إن كل شيء مكسور، بل أقول إن أحدًا لم يُظهر لي دليلًا على أن نافذة ترتيب العمليات هذه محمية فعلًا. تبقى حقائبي صغيرة إلى أن ينشر شخص ما بيانات حقيقية عن تعرّض mempool خلال خطوة التحقق هذه. سيروي تدفق الأوامر القصة الحقيقية بمجرد أن يرتفع حجم التداول على Base.
أتنقل بين أزواج السبوت والدفعات المستقبلية (perps) مثل كثيرين، وبصراحة كانت دائمًا تزعجني احتكاكات إدارة محافظ منفصلة للتعرض للأصول الواقعية (RWA) مقابل التعرض للعملات المشفرة. قامت GRVT بتجميع هذه المشكلة بالكامل في رصيد هامش موحد واحد. أستطيع الاحتفاظ بالذهب والزيت وبتعاملاتي المعتادة من perps المشفرة تحت نفس مجمع الضمان دون تحويل الأموال باستمرار أو متابعة ثلاث حسابات مختلفة.
الذي شد انتباهي فعلًا هو طبقة العائد التي تعمل بهدوء تحت السطح عبر Aave وCentrifuge. رصيدي الخامل لا يجلس فقط دون جدوى بينما أنتظر إعدادًا، بل يدرّ عائدًا مع بقاءه محسوبًا كـهامش أستطيع نشره فورًا. هذا النوع من كفاءة رأس المال عادةً لا يحلم به المتداولون إلا بعد أسبوع انزلاق (slippage) سيّئ.
محرك المطابقة البالغ 600k TPS هو الجزء الذي يمنح تجربة أقرب إلى إحساس بورصات CEX؛ التنفيذ سريع بما يكفي بحيث لا أبدأ بالشك في عمليات التنفيذ أثناء التذبذب. لكن الجزء الذي يجعلني أشعر فعليًا بالراحة عند الاحتفاظ بالحجم هنا هو البنية الأساسية للحفظ الذاتي. لا أُسلم أموالي لصندوق أسود فقط لأن الواجهة تبدو أنيقة.
يمنح العرض الثابت البالغ 1 مليار على GRVT الرمز حدًا واضحًا يمكن نمذجته مع نمو الفائدة المفتوحة. أنا لا أقول املأ القارب دون تفكير، لكن تركيبة RWA مع perps تحت نظام هامش واحد نادرة حقًا في الوقت الحالي، وأنا أتابعها عن كثب قبل المحطة التالية لنمو TVL.
بروتوكول نيوتن أصبح الآن في المسار الحرج بين أموالك و
لم يشرح أحد السوق وماذا يحدث عندما يتوقف تفشل معظم بنية البنية التحتية للـ DeFi بأمان. إذا تعطل مُجمّع الأسعار، فما زالت عملية المبادلة تُوجَّه، ربما بتنفيذ أسوأ، لكنها تُوجَّه. وإذا تعطل منتدى الحوكمة، ما زلت تستطيع التداول. وإذا توقف تحميل لوحة بيانات، فما زالت مراكزك تعمل. نيوتن لا يعمل على هذا النحو. عندما تستخدم صندوقًا مُدارًا بنيوتن أو تُخوِّل وكيلًا مُدارًا بواسطة نيوتن، فإن شبكة إنفاذ سياسات نيوتن تكون موجودة مباشرةً بين رأس مالك والتنفيذ؛ ما يعني أنه إذا فقدت شبكة مشغّل الـ TEE النصاب، أو تدهورت تحت حدها الأدنى، أو واجهت انقطاعًا في الخدمة، فلن تتمكن وكلاؤك المُخوَّلون من الحصول على إثباتات السياسات ولا من تنفيذ الصفقات. مراكزك لا تفشل بأمان إلى وضعٍ مُنخفض. بل تتجمد. وتتجمد في ظروف شبكية ضاغطة من النوع نفسه، مع ارتفاع أحجام المعاملات، وارتفاع أسعار الغاز، وتغيرات سريعة في السوق—وهي الظروف الأكثر احتمالًا لإحداث مشكلات في توفر المشغلين ابتداءً.
وجدت شيئًا في وثائق نِيوتن لا يتحدث عنه أحد: يمكن فعليًا أن تنتهي صلاحية إثبات سياسة قبل أن تستخدمه.
كنت أقرأ كيف تتحرك المهام عبر Newton Explorer، وهناك حالة اسمها expired (منتهية)، وهي منفصلة عن consumed (مستهلكة). وهذا ما يعنيه ذلك ببساطة. يتم فحص معاملتك مقابل القواعد، ويعطي نِيوتن ضوءًا أخضر، لكن هذا الضوء الأخضر ليس للأبد. إذا جلست عليه وقتًا طويلًا ولم تنفذه فعليًا، فتنتهي صلاحية الموافقة، وستحتاج إلى إجراء فحص جديد قبل المحاولة مرة أخرى.
هذا في الواقع ميزة أمان ذكية عندما تفكر في الأمر. يمكن أن تتغير الأوضاع على السلسلة بسرعة؛ فقاعدة كانت منطقية قبل خمس دقائق قد لا تكون صحيحة الآن، لذا فرض فحصٍ جديد بدلًا من ترك الموافقات القديمة معلقة إلى أجل غير مسمى أمر منطقي.
لكن هذا أيضًا يعني أن المطورين الذين يبنون على Newton بحاجة إلى التعامل بدقة مع نافذة انتهاء الصلاحية، أو قد تفشل المعاملات عشوائيًا لدرجة أن يبدو أنها تمت الموافقة عليها قبل ثوانٍ.
الفجوة بين مطابقة التداول وبين تسوية التداول فعليًا هي المكان الذي تكمن فيه المخاطر الحقيقية لدى GRVT.
عندما ترسل أمرًا، تقوم محرك GRVT خارج السلسلة بمطابقته فورًا—وهذا هو جوهر عرض الدقة خلال أقل من ثانيتين مليّثانية. لكن هذه المطابقة ليست نهائية بعد. يجب أن يتم تجميعها، ثم التحقق منها عبر دائرة ZK الخاصة بـ Validium، وأخيرًا تأكيدها على السلسلة قبل أن تصبح غير قابلة للعكس. كذلك فإن توليد الإثبات والتجميع لا يحدثان بشكل فوري، حتى على Hyperchain سريع. في الفترة بين المطابقة والنهائية، يكون لديك مركز تعرضه واجهة المستخدم على أنه “ممتلئ”، رغم أنه لم يصل بعد إلى التسوية. في أغلب الأحيان تُغلق هذه الفجوة بسرعة كافية لدرجة أن أحدًا لا يلاحظ ذلك. لكن تحت ضغطٍ كبير، عندما يقوم المُسلسِل (sequencer) بمعالجة طفرة في عدد المعاملات أثناء حركةٍ متقلبة، يمكن أن تتمدد هذه النافذة. وعندها قد يكون المركز الذي تعتقد أنه مُقفل—من الناحية التقنية—ما يزال بانتظار إثبات.
أنا لا أقول إن هذا خللٌ خفي؛ فكل تصميمات rollup المبنية على ZK تتضمن نوعًا من هذا التوازن بين التأكيد “المرن/الناعم” مقابل “النهائي الصلب”. ما أقوله هو أن كثيرًا من المتداولين يتعاملون مع المطابقة الفورية كأنها حقيقة مُطلقة وينسون أن هناك طبقة تسوية لا تزال تتأخر في اللحاق. لحظة اتساع هذه الفجوة خلال التقلبات الفعلية هي اللحظة التي تكتشف فيها مقدار ما كنت تثق به بالفعل في الواجهة الخلفية مقارنةً بالسلسلة.
نموذج توزيع حزمة سياسة بروتوكول Newton يشارك نفس ثغرة سلسلة توريد GitHub بالضبط
أن هذا الاختراق قد طاول عشرات أنظمة الإنتاج في 2025 آلية التوزيع هي سطح الهجوم. تُوزَّع تكاملات نِيوتن Oracle وحزم السياسة (policy packs) كحزم مفتوحة المصدر من خلال مؤسسة newt-foundation التابعة لمستودع GitHub، وبالتحديد عبر مستودعي newton-policy-packs وnewton-sdk اللذين يقوم المشغّلون بتنزيلهما وتشغيلهما داخل بيئات تقييم TEE الخاصة بهم أثناء فرض السياسات. وفي عام 2025 وحده، حدد الباحثون الأمنيون أكثر من 454,600 حزمة خبيثة جديدة عبر npm وPyPI وMaven Central وNuGet وHugging Face، وكان النمط السائد هو أن يعامل المهاجمون السجلات العامة كمنصات توزيع ويؤتمتوا النشر على نطاق واسع. ويُعد SDK الخاص بـ Newton جزءًا من البنية التحتية نفسها للتوزيع. إذ يمكن لبيانات اعتماد GitHub المخترَقة لمؤسسة newt-foundation، أو لطلب سحب خبيث يستغل سوء تهيئة في سير عمل Actions، أو لتبعية مُسمّمة ضمن مخطط الحزم الخاص بـ newton-sdk ذاته أن تنشر نسخة SDK مزروعة بأبواب خلفية (backdoored) يقوم المشغّلون بتثبيتها دون أن يدركوا أن منطق تقييم السياسات الذي يعمل داخل TEE الخاص بهم قد تم تعديله بهدوء. وإن TEE هي تحديدًا المكان الذي يوجّه فيه Newton بنيةً معمارية تحافظ على الخصوصية لتوجيه أكثر البيانات حساسية التي يتعامل معها: سمات الهوية، ودرجات مخاطر المحفظة (wallet risk scores)، ونتائج KYC، ومعلمات القيود المالية التي يضمن Newton صراحةً ألا تمس أي سجل عام (public ledger).