Mustafa 92
115 منشورات
Mustafa 92
إبلاغ
حظر المُستخدم
52 تتابع
102 المتابعون
75 إعجاب
منشورات
·
--
جعلتني عبارة «يقين المعدل» بجوار Nillion أتوقف، لأن طريقة عمل $NIL لا تتعلق بالمعدلات. تبيع الشبكة الحوسبة العمياء، أي إن الحوسبة متعددة الأطراف (MPC) والتخزين المشفّر يعملان عبر عناقيد Petnet، ومثالها في DeFi يشبه دفتر أوامر خاصًا، حيث يعني اليقين أن تظل نيتك مخفية حتى التنفيذ، لا أن يبقى العائد ثابتًا. هذه فجوة مختلفة عمّا يوحي به العنوان. #Nillion @nillionnetwork تعتبر الخصوصية بنية تحتية للمطوّرين، ومهمة الرمز هي الدفع مقابل الحوسبة والتخزين، مع وجود التخزين المُرهَن وجدول تضخم سنوي بنسبة 1% في الأساس. لذلك يعتمد الطلب على $NIL على استخدام التطبيقات للشبكة فعليًا، لا على سعي المودعين وراء رقم معين. واجهت مشاريع مثل $SCRT و$ROSE السؤال نفسه لسنوات: من السهل الإعجاب بالحوسبة الخاصة، لكن يصعب العثور عليها في تدفق الرسوم اليومية. أكثر ما أعود للتفكير فيه هو مدى سهولة تمدد تسمية «DeFi» لتشمل مشروعًا يبدو أن أوائل عملائه أقرب إلى فرق الذكاء الاصطناعي والبيانات منهم إلى المقرضين. إذا كان اليقين المعروض هو السرية، فمن في DeFi يدفع مقابلها اليوم بالفعل؟
@nillionnetwork #nillion $NIL
جعلتني عبارة «يقين المعدل» بجوار Nillion أتوقف، لأن طريقة عمل $NIL لا تتعلق بالمعدلات. تبيع الشبكة الحوسبة العمياء، أي إن الحوسبة متعددة الأطراف (MPC) والتخزين المشفّر يعملان عبر عناقيد Petnet، ومثالها في DeFi يشبه دفتر أوامر خاصًا، حيث يعني اليقين أن تظل نيتك مخفية حتى التنفيذ، لا أن يبقى العائد ثابتًا. هذه فجوة مختلفة عمّا يوحي به العنوان. #Nillion @Nillion تعتبر الخصوصية بنية تحتية للمطوّرين، ومهمة الرمز هي الدفع مقابل الحوسبة والتخزين، مع وجود التخزين المُرهَن وجدول تضخم سنوي بنسبة 1% في الأساس. لذلك يعتمد الطلب على $NIL على استخدام التطبيقات للشبكة فعليًا، لا على سعي المودعين وراء رقم معين. واجهت مشاريع مثل $SCRT و$ROSE السؤال نفسه لسنوات: من السهل الإعجاب بالحوسبة الخاصة، لكن يصعب العثور عليها في تدفق الرسوم اليومية. أكثر ما أعود للتفكير فيه هو مدى سهولة تمدد تسمية «DeFi» لتشمل مشروعًا يبدو أن أوائل عملائه أقرب إلى فرق الذكاء الاصطناعي والبيانات منهم إلى المقرضين. إذا كان اليقين المعروض هو السرية، فمن في DeFi يدفع مقابلها اليوم بالفعل؟
@Nillion #nillion $NIL
@Nillion #nillion $NIL
138
·
--
#newt $NEWT @NewtonProtocol
«تشكيل منظومة الغد» يوحي بوجود شيء يؤثر في محيطه، لذلك بحثت عن أدلة على هذا التأثير، لا عن ميزات داخلية فحسب. يقدّم Newton Protocol و$NEWT و#NewtonProtocol و@NewtonProtocol frames أنفسها على أنها تسهم في تشكيل منظومة التمويل اللامركزي الأوسع، لكن كل ما استطعت ملاحظته فعليًا خلال المهمة كان محصورًا في البروتوكول نفسه: قرارات وآليات أثّرت في تجربتي ضمن هذا البروتوكول وحده، من دون أي شيء ظاهر يمتد إلى مشاريع أخرى أو معايير أو إلى المنظومة ككل. فالتشكيل يعني أن الأشياء الأخرى تنحني حولك؛ أما ما رأيته فهو نظام يحسّن أداء ركنه الخاص على نحو جيد، وهذا ادعاء مختلف وأضيق بكثير. لا أظن أن هذا انتقاد بالضبط؛ فمعظم المشاريع تعمل بهذه الطريقة، لكن عبارة «تشكيل المنظومة» تستعير نطاقًا من التأثير لا يستحقه تلقائيًا منتج واحد متقن لمجرد وجوده ضمن مساحة أكبر. لاحظت أنني استوعبت هذا التصوير على مستوى المنظومة من دون أن أرى قط أي شيء يتجاوز هذه الواجهة الواحدة. إنها فجوة صغيرة بين وصف منتجك جيدًا ووصف تأثيرك في كل ما يحيط به، لكنها من نوع الفجوات التي يسهل التوقف عن ملاحظتها بعد رؤية العبارة مرات كافية. لست متأكدًا متى يبدأ «التشكيل» فعلًا، أو ما إذا كان يصف الطموح دائمًا لا الأثر المرصود.
#newt $NEWT @NewtonProtocol
«تشكيل منظومة الغد» يوحي بوجود شيء يؤثر في محيطه، لذلك بحثت عن أدلة على هذا التأثير، لا عن ميزات داخلية فحسب. يقدّم Newton Protocol و$NEWT و#NewtonProtocol و@NewtonProtocol frames أنفسها على أنها تسهم في تشكيل منظومة التمويل اللامركزي الأوسع، لكن كل ما استطعت ملاحظته فعليًا خلال المهمة كان محصورًا في البروتوكول نفسه: قرارات وآليات أثّرت في تجربتي ضمن هذا البروتوكول وحده، من دون أي شيء ظاهر يمتد إلى مشاريع أخرى أو معايير أو إلى المنظومة ككل. فالتشكيل يعني أن الأشياء الأخرى تنحني حولك؛ أما ما رأيته فهو نظام يحسّن أداء ركنه الخاص على نحو جيد، وهذا ادعاء مختلف وأضيق بكثير. لا أظن أن هذا انتقاد بالضبط؛ فمعظم المشاريع تعمل بهذه الطريقة، لكن عبارة «تشكيل المنظومة» تستعير نطاقًا من التأثير لا يستحقه تلقائيًا منتج واحد متقن لمجرد وجوده ضمن مساحة أكبر. لاحظت أنني استوعبت هذا التصوير على مستوى المنظومة من دون أن أرى قط أي شيء يتجاوز هذه الواجهة الواحدة. إنها فجوة صغيرة بين وصف منتجك جيدًا ووصف تأثيرك في كل ما يحيط به، لكنها من نوع الفجوات التي يسهل التوقف عن ملاحظتها بعد رؤية العبارة مرات كافية. لست متأكدًا متى يبدأ «التشكيل» فعلًا، أو ما إذا كان يصف الطموح دائمًا لا الأثر المرصود.
«تشكيل منظومة الغد» يوحي بوجود شيء يؤثر في محيطه، لذلك بحثت عن أدلة على هذا التأثير، لا عن ميزات داخلية فحسب. يقدّم Newton Protocol و$NEWT و#NewtonProtocol و@NewtonProtocol frames أنفسها على أنها تسهم في تشكيل منظومة التمويل اللامركزي الأوسع، لكن كل ما استطعت ملاحظته فعليًا خلال المهمة كان محصورًا في البروتوكول نفسه: قرارات وآليات أثّرت في تجربتي ضمن هذا البروتوكول وحده، من دون أي شيء ظاهر يمتد إلى مشاريع أخرى أو معايير أو إلى المنظومة ككل. فالتشكيل يعني أن الأشياء الأخرى تنحني حولك؛ أما ما رأيته فهو نظام يحسّن أداء ركنه الخاص على نحو جيد، وهذا ادعاء مختلف وأضيق بكثير. لا أظن أن هذا انتقاد بالضبط؛ فمعظم المشاريع تعمل بهذه الطريقة، لكن عبارة «تشكيل المنظومة» تستعير نطاقًا من التأثير لا يستحقه تلقائيًا منتج واحد متقن لمجرد وجوده ضمن مساحة أكبر. لاحظت أنني استوعبت هذا التصوير على مستوى المنظومة من دون أن أرى قط أي شيء يتجاوز هذه الواجهة الواحدة. إنها فجوة صغيرة بين وصف منتجك جيدًا ووصف تأثيرك في كل ما يحيط به، لكنها من نوع الفجوات التي يسهل التوقف عن ملاحظتها بعد رؤية العبارة مرات كافية. لست متأكدًا متى يبدأ «التشكيل» فعلًا، أو ما إذا كان يصف الطموح دائمًا لا الأثر المرصود.
3
551
·
--
يوفر بروتوكول نيوتن إطار عمل أمنيّ أكثر ذكاءًقضيت جزءًا من بعد الظهر في إعداد التحقق بخطوتين (2FA) على حساب كنت أؤجل تأمينه منذ أشهر، وهي إحدى تلك المهام التي لا تحدث إلا بعد أن تقرأ عن شخص آخر تم استنزاف حسابه. مملة، لكن مُرضية بمجرد إنجازها—ذلك الارتياح الصغير بإغلاق باب كنت تعرف أنه مفتوح.
كان ذلك النوع من التفكير ما يزال حاضرًا عندما فتحت مواد بروتوكول نيوتن بعد ذلك، و"إطار عمل أمنيّ أكثر ذكاءً" صادفني بشكل مختلف عما قد يحدث في يوم عادي، لأنني كنت قد قضيت ساعة أفكر بشكل ملموس في ما الذي يجعل الأمن فعّالًا حقًا مقابل ما يبدو مُطمئنًا فقط.
يوفر بروتوكول نيوتن إطار عمل أمنيّ أكثر ذكاءً
قضيت جزءًا من بعد الظهر في إعداد التحقق بخطوتين (2FA) على حساب كنت أؤجل تأمينه منذ أشهر، وهي إحدى تلك المهام التي لا تحدث إلا بعد أن تقرأ عن شخص آخر تم استنزاف حسابه. مملة، لكن مُرضية بمجرد إنجازها—ذلك الارتياح الصغير بإغلاق باب كنت تعرف أنه مفتوح.
كان ذلك النوع من التفكير ما يزال حاضرًا عندما فتحت مواد بروتوكول نيوتن بعد ذلك، و"إطار عمل أمنيّ أكثر ذكاءً" صادفني بشكل مختلف عما قد يحدث في يوم عادي، لأنني كنت قد قضيت ساعة أفكر بشكل ملموس في ما الذي يجعل الأمن فعّالًا حقًا مقابل ما يبدو مُطمئنًا فقط.
كان ذلك النوع من التفكير ما يزال حاضرًا عندما فتحت مواد بروتوكول نيوتن بعد ذلك، و"إطار عمل أمنيّ أكثر ذكاءً" صادفني بشكل مختلف عما قد يحدث في يوم عادي، لأنني كنت قد قضيت ساعة أفكر بشكل ملموس في ما الذي يجعل الأمن فعّالًا حقًا مقابل ما يبدو مُطمئنًا فقط.
1
78
·
--
بروتوكول نيوتن يبني بنية مالية أكثر ذكاءًكان لدي تطبيق التداول مفتوحًا في تبويب واحد، ونشرة إخبارية عشوائية في تبويب آخر—نوعٌ من التشتت بين الانتباه لا يجعلك تقوم بأي من الأمرين على نحو جيد. كانت النشرة تذكر رقمًا عن أن المعاملات الفاشلة تكلف المستخدمين أموالًا بسبب رسوم الغاز وحدها، دون أي نتيجة تُنجَز أصلًا؛ مجرد رسوم مُهدَرة. بقي هذا الرقم في ذهني أكثر من أي شيء آخر في المقالة.
لذلك ذهبت إلى البحث عن بروتوكول نيوتن بعد ذلك، وبشكلٍ أساسي لأن عبارة "بنية مالية أكثر ذكاءً" كانت مرتبطة به، وأردت أن أعرف إن كان المقصود بالذكاء يعني ما يشبه منع ذلك النوع نفسه من الهدر، أم شيئًا مختلفًا تمامًا.
بروتوكول نيوتن يبني بنية مالية أكثر ذكاءً
كان لدي تطبيق التداول مفتوحًا في تبويب واحد، ونشرة إخبارية عشوائية في تبويب آخر—نوعٌ من التشتت بين الانتباه لا يجعلك تقوم بأي من الأمرين على نحو جيد. كانت النشرة تذكر رقمًا عن أن المعاملات الفاشلة تكلف المستخدمين أموالًا بسبب رسوم الغاز وحدها، دون أي نتيجة تُنجَز أصلًا؛ مجرد رسوم مُهدَرة. بقي هذا الرقم في ذهني أكثر من أي شيء آخر في المقالة.
لذلك ذهبت إلى البحث عن بروتوكول نيوتن بعد ذلك، وبشكلٍ أساسي لأن عبارة "بنية مالية أكثر ذكاءً" كانت مرتبطة به، وأردت أن أعرف إن كان المقصود بالذكاء يعني ما يشبه منع ذلك النوع نفسه من الهدر، أم شيئًا مختلفًا تمامًا.
لذلك ذهبت إلى البحث عن بروتوكول نيوتن بعد ذلك، وبشكلٍ أساسي لأن عبارة "بنية مالية أكثر ذكاءً" كانت مرتبطة به، وأردت أن أعرف إن كان المقصود بالذكاء يعني ما يشبه منع ذلك النوع نفسه من الهدر، أم شيئًا مختلفًا تمامًا.
3
66
·
--
عرض الترجمة
@NewtonProtocol #Newt $NEWT
"Defining the next era" and "intelligent solutions" are both big words, so I picked the one thing they had in common and looked for it specifically: some sign of the system actually reasoning, not just executing a rule. Newton Protocol, $NEWT, #NewtonProtocol, @NewtonProtocol leans on "intelligent" as its core descriptor, but what I could actually observe during the task behaved like fixed pattern-matching — a transaction either fit a known category or it didn't, with the same response every time a given pattern appeared. Intelligence, as a word, implies weighing context and adjusting; what I saw was closer to a lookup, competent but unchanging. That's not a small gap when the entire framing rests on the word doing more conceptual work than the mechanism actually performs. I noticed I'd started describing the behavior as "smart" in my own head before I'd actually confirmed anything adaptive was happening, just from repeated exposure to the label. It's a strange thing, watching your own vocabulary get borrowed by a project's marketing without noticing the swap happen. Not sure where the line sits between well-designed rules and something that actually deserves to be called intelligent.
@NewtonProtocol #Newt $NEWT
"Defining the next era" and "intelligent solutions" are both big words, so I picked the one thing they had in common and looked for it specifically: some sign of the system actually reasoning, not just executing a rule. Newton Protocol, $NEWT , #NewtonProtocol, @NewtonProtocol leans on "intelligent" as its core descriptor, but what I could actually observe during the task behaved like fixed pattern-matching — a transaction either fit a known category or it didn't, with the same response every time a given pattern appeared. Intelligence, as a word, implies weighing context and adjusting; what I saw was closer to a lookup, competent but unchanging. That's not a small gap when the entire framing rests on the word doing more conceptual work than the mechanism actually performs. I noticed I'd started describing the behavior as "smart" in my own head before I'd actually confirmed anything adaptive was happening, just from repeated exposure to the label. It's a strange thing, watching your own vocabulary get borrowed by a project's marketing without noticing the swap happen. Not sure where the line sits between well-designed rules and something that actually deserves to be called intelligent.
"Defining the next era" and "intelligent solutions" are both big words, so I picked the one thing they had in common and looked for it specifically: some sign of the system actually reasoning, not just executing a rule. Newton Protocol, $NEWT , #NewtonProtocol, @NewtonProtocol leans on "intelligent" as its core descriptor, but what I could actually observe during the task behaved like fixed pattern-matching — a transaction either fit a known category or it didn't, with the same response every time a given pattern appeared. Intelligence, as a word, implies weighing context and adjusting; what I saw was closer to a lookup, competent but unchanging. That's not a small gap when the entire framing rests on the word doing more conceptual work than the mechanism actually performs. I noticed I'd started describing the behavior as "smart" in my own head before I'd actually confirmed anything adaptive was happening, just from repeated exposure to the label. It's a strange thing, watching your own vocabulary get borrowed by a project's marketing without noticing the swap happen. Not sure where the line sits between well-designed rules and something that actually deserves to be called intelligent.
8
4
219
·
--
#newt $NEWT @NewtonProtocol
"تغيير طريقة عمل التمويل اللامركزي" جعلني أتوقع تسلسلاً مختلفاً من الخطوات، وليس مجرد إحساس مختلف حول نفس الخطوات، لذلك قارنت مسار النقر الفعلي بما اعتدت القيام به دائماً. بدت بروتوكول نيوتن، $NEWT، #NewtonProtocol، @NewtonProtocol frames كأنها تغيّر نموذج تشغيل التمويل اللامركزي، لكن تدفق المعاملة الذي مررت به أثناء المهمة اتبع نفس الترتيب الذي اتبعته في عشرات البروتوكولات الأخرى — توصيل المحفظة، اختيار الإجراء، المراجعة، التأكيد — مع الاختلاف الذي تمحور بالكامل في المعلومات التي ظهرت أثناء خطوة المراجعة، وليس في التسلسل نفسه. هذا نوع أضيق من التغيير مما توحي به كلمة "يعمل". يشير التشغيل إلى تغيّر الآليات؛ لكن الذي تغيّر فعلاً هو المحتوى المضاف فوق آليات ظلت كما هي. لا أعتقد أن هذا أمرٌ بسيط؛ فمعلومات أفضل في خطوة المراجعة مفيدة حقاً، لكنها أقرب إلى تحسين عملية موجودة منها إلى تغيير في كيفية عمل التمويل اللامركزي كفئة. لاحظت أنني كنت أتوقع شيئاً مختلفاً بنيوياً عند البدء، واضطررت إلى فصل "معلومات جديدة" عن "عملية جديدة" بمجرد أن أصبحت داخل التجربة فعلياً. لست متأكداً كم تبعد المسافة بين تحسين خطوة وتغيير العملية.
#newt $NEWT @NewtonProtocol
"تغيير طريقة عمل التمويل اللامركزي" جعلني أتوقع تسلسلاً مختلفاً من الخطوات، وليس مجرد إحساس مختلف حول نفس الخطوات، لذلك قارنت مسار النقر الفعلي بما اعتدت القيام به دائماً. بدت بروتوكول نيوتن، $NEWT ، #NewtonProtocol، @NewtonProtocol frames كأنها تغيّر نموذج تشغيل التمويل اللامركزي، لكن تدفق المعاملة الذي مررت به أثناء المهمة اتبع نفس الترتيب الذي اتبعته في عشرات البروتوكولات الأخرى — توصيل المحفظة، اختيار الإجراء، المراجعة، التأكيد — مع الاختلاف الذي تمحور بالكامل في المعلومات التي ظهرت أثناء خطوة المراجعة، وليس في التسلسل نفسه. هذا نوع أضيق من التغيير مما توحي به كلمة "يعمل". يشير التشغيل إلى تغيّر الآليات؛ لكن الذي تغيّر فعلاً هو المحتوى المضاف فوق آليات ظلت كما هي. لا أعتقد أن هذا أمرٌ بسيط؛ فمعلومات أفضل في خطوة المراجعة مفيدة حقاً، لكنها أقرب إلى تحسين عملية موجودة منها إلى تغيير في كيفية عمل التمويل اللامركزي كفئة. لاحظت أنني كنت أتوقع شيئاً مختلفاً بنيوياً عند البدء، واضطررت إلى فصل "معلومات جديدة" عن "عملية جديدة" بمجرد أن أصبحت داخل التجربة فعلياً. لست متأكداً كم تبعد المسافة بين تحسين خطوة وتغيير العملية.
"تغيير طريقة عمل التمويل اللامركزي" جعلني أتوقع تسلسلاً مختلفاً من الخطوات، وليس مجرد إحساس مختلف حول نفس الخطوات، لذلك قارنت مسار النقر الفعلي بما اعتدت القيام به دائماً. بدت بروتوكول نيوتن، $NEWT ، #NewtonProtocol، @NewtonProtocol frames كأنها تغيّر نموذج تشغيل التمويل اللامركزي، لكن تدفق المعاملة الذي مررت به أثناء المهمة اتبع نفس الترتيب الذي اتبعته في عشرات البروتوكولات الأخرى — توصيل المحفظة، اختيار الإجراء، المراجعة، التأكيد — مع الاختلاف الذي تمحور بالكامل في المعلومات التي ظهرت أثناء خطوة المراجعة، وليس في التسلسل نفسه. هذا نوع أضيق من التغيير مما توحي به كلمة "يعمل". يشير التشغيل إلى تغيّر الآليات؛ لكن الذي تغيّر فعلاً هو المحتوى المضاف فوق آليات ظلت كما هي. لا أعتقد أن هذا أمرٌ بسيط؛ فمعلومات أفضل في خطوة المراجعة مفيدة حقاً، لكنها أقرب إلى تحسين عملية موجودة منها إلى تغيير في كيفية عمل التمويل اللامركزي كفئة. لاحظت أنني كنت أتوقع شيئاً مختلفاً بنيوياً عند البدء، واضطررت إلى فصل "معلومات جديدة" عن "عملية جديدة" بمجرد أن أصبحت داخل التجربة فعلياً. لست متأكداً كم تبعد المسافة بين تحسين خطوة وتغيير العملية.
2
142
·
--
بروتوكول نيوتن يجعل تطبيق السياسات عمليًااستيقظت على رسالة من صديق أرسل لي فيها لقطة شاشة لتحليل ما بعد اختراق في أحد تطبيقات التمويل اللامركزي، من تلك التحليلات التي تشرح بالتفصيل كيف خرجت الأموال، والتي تتداول كل بضعة أسابيع. لم أتفاعل معها كثيرًا، اكتفيت بإلقاء نظرة سريعة ثم انتقلت إلى غيرها، وأعددت القهوة وتصفحت ما اعتدت تصفحه صباحًا.
لاحقًا، وبموضوع لا صلة له كثيرًا بما سبق، انتهى بي الأمر إلى الاطلاع على بروتوكول نيوتن، ويرجع ذلك أساسًا إلى أنني رأيت عبارة «يجعل تطبيق السياسات عمليًا» في مكان ما، وظلت كلمة «عملي» عالقة في ذهني. «عملي» ادعاء محدد. لا يعني مجرد أنه «ممكن»، بل إنه «قابل للاستخدام من دون كثير من التعقيدات». لذلك أردت أن أرى إن كان هذا الادعاء يصمد أمام التدقيق.
بروتوكول نيوتن يجعل تطبيق السياسات عمليًا
استيقظت على رسالة من صديق أرسل لي فيها لقطة شاشة لتحليل ما بعد اختراق في أحد تطبيقات التمويل اللامركزي، من تلك التحليلات التي تشرح بالتفصيل كيف خرجت الأموال، والتي تتداول كل بضعة أسابيع. لم أتفاعل معها كثيرًا، اكتفيت بإلقاء نظرة سريعة ثم انتقلت إلى غيرها، وأعددت القهوة وتصفحت ما اعتدت تصفحه صباحًا.
لاحقًا، وبموضوع لا صلة له كثيرًا بما سبق، انتهى بي الأمر إلى الاطلاع على بروتوكول نيوتن، ويرجع ذلك أساسًا إلى أنني رأيت عبارة «يجعل تطبيق السياسات عمليًا» في مكان ما، وظلت كلمة «عملي» عالقة في ذهني. «عملي» ادعاء محدد. لا يعني مجرد أنه «ممكن»، بل إنه «قابل للاستخدام من دون كثير من التعقيدات». لذلك أردت أن أرى إن كان هذا الادعاء يصمد أمام التدقيق.
لاحقًا، وبموضوع لا صلة له كثيرًا بما سبق، انتهى بي الأمر إلى الاطلاع على بروتوكول نيوتن، ويرجع ذلك أساسًا إلى أنني رأيت عبارة «يجعل تطبيق السياسات عمليًا» في مكان ما، وظلت كلمة «عملي» عالقة في ذهني. «عملي» ادعاء محدد. لا يعني مجرد أنه «ممكن»، بل إنه «قابل للاستخدام من دون كثير من التعقيدات». لذلك أردت أن أرى إن كان هذا الادعاء يصمد أمام التدقيق.
74
·
--
بروتوكول Newton يقود المرحلة التالية من نمو التمويل اللامركزيكانت الرسوم البيانية خضراء اليوم، لكن شعرت وكأن أحدًا لا يصدق ذلك فعلًا؛ ذلك النوع من اللون الأخضر الذي لا تدعمه أحجام التداول مع الشمعة. لم أكن أتعامل مع الأمر بجدية في التداول. كنت في الغالب أتصفح بعض لوحات معلومات DeFi، بنصف انتباه، وأتحقق من مركز عائد كنت قد نسيت إغلاقه قبل أسابيع.
وأثناء وجودي هناك، انتهى بي الأمر إلى الدخول في أشياء تتعلق ببروتوكول Newton، غالبًا لأن «المرحلة التالية من نمو DeFi» عبارة رأيتها مرتبطة بنحو اثنتي عشرة مشروعًا هذا العام وحده، وأردت أن أرى إلى ماذا يشير «النمو» فعلًا في هذا الوقت.
بروتوكول Newton يقود المرحلة التالية من نمو التمويل اللامركزي
كانت الرسوم البيانية خضراء اليوم، لكن شعرت وكأن أحدًا لا يصدق ذلك فعلًا؛ ذلك النوع من اللون الأخضر الذي لا تدعمه أحجام التداول مع الشمعة. لم أكن أتعامل مع الأمر بجدية في التداول. كنت في الغالب أتصفح بعض لوحات معلومات DeFi، بنصف انتباه، وأتحقق من مركز عائد كنت قد نسيت إغلاقه قبل أسابيع.
وأثناء وجودي هناك، انتهى بي الأمر إلى الدخول في أشياء تتعلق ببروتوكول Newton، غالبًا لأن «المرحلة التالية من نمو DeFi» عبارة رأيتها مرتبطة بنحو اثنتي عشرة مشروعًا هذا العام وحده، وأردت أن أرى إلى ماذا يشير «النمو» فعلًا في هذا الوقت.
وأثناء وجودي هناك، انتهى بي الأمر إلى الدخول في أشياء تتعلق ببروتوكول Newton، غالبًا لأن «المرحلة التالية من نمو DeFi» عبارة رأيتها مرتبطة بنحو اثنتي عشرة مشروعًا هذا العام وحده، وأردت أن أرى إلى ماذا يشير «النمو» فعلًا في هذا الوقت.
2
51
·
--
عرض الترجمة
#newt $NEWT @NewtonProtocol
"Policy enforcement" sounded like something with teeth, so I went looking for where the enforcement actually bites versus where it just observes. Newton Protocol, $NEWT, #NewtonProtocol, @NewtonProtocol talks about bringing policy enforcement to DeFi, but during the task the "enforcement" mostly showed up as visibility, not restriction — the system surfaced information about a transaction's risk profile, but nothing actually blocked or altered my ability to proceed if I ignored it. That's a meaningful gap between the word and the behavior. Enforcement implies a rule that holds regardless of the user's choice; what I experienced was closer to a strongly worded suggestion that I was free to override without friction. It's not nothing, better visibility does change behavior for some people, but it's also not policy in the sense the term usually carries. I noticed I still felt reassured by the label even after realizing nothing was actually stopping me, which says something about how much weight a word like "enforcement" carries on its own. Curious whether real enforcement shows up later, or whether visibility was always the actual plan.
#newt $NEWT @NewtonProtocol
"Policy enforcement" sounded like something with teeth, so I went looking for where the enforcement actually bites versus where it just observes. Newton Protocol, $NEWT , #NewtonProtocol, @NewtonProtocol talks about bringing policy enforcement to DeFi, but during the task the "enforcement" mostly showed up as visibility, not restriction — the system surfaced information about a transaction's risk profile, but nothing actually blocked or altered my ability to proceed if I ignored it. That's a meaningful gap between the word and the behavior. Enforcement implies a rule that holds regardless of the user's choice; what I experienced was closer to a strongly worded suggestion that I was free to override without friction. It's not nothing, better visibility does change behavior for some people, but it's also not policy in the sense the term usually carries. I noticed I still felt reassured by the label even after realizing nothing was actually stopping me, which says something about how much weight a word like "enforcement" carries on its own. Curious whether real enforcement shows up later, or whether visibility was always the actual plan.
"Policy enforcement" sounded like something with teeth, so I went looking for where the enforcement actually bites versus where it just observes. Newton Protocol, $NEWT , #NewtonProtocol, @NewtonProtocol talks about bringing policy enforcement to DeFi, but during the task the "enforcement" mostly showed up as visibility, not restriction — the system surfaced information about a transaction's risk profile, but nothing actually blocked or altered my ability to proceed if I ignored it. That's a meaningful gap between the word and the behavior. Enforcement implies a rule that holds regardless of the user's choice; what I experienced was closer to a strongly worded suggestion that I was free to override without friction. It's not nothing, better visibility does change behavior for some people, but it's also not policy in the sense the term usually carries. I noticed I still felt reassured by the label even after realizing nothing was actually stopping me, which says something about how much weight a word like "enforcement" carries on its own. Curious whether real enforcement shows up later, or whether visibility was always the actual plan.
6
2
173
·
--
#newt $NEWT @NewtonProtocol
"الأذكى" يوحي بأن النظام يتعلّم أو يحكم على شيء ما، لذلك انتبهت إلى أين تجسّدت “الذكاء” فعليًا مقارنةً بما كان مجرد قاعدة ثابتة. بروتوكول نيوتن، $NEWT، #NewtonProtocol، @NewtonProtocol إطارًا لأمن البلوك تشين كونه أكثر ذكاءً، لكن ما رأيته أثناء تنفيذ المهمة بدا أقرب إلى عتبات ثابتة من كونه حكمًا تكيفيًا — فالمعاملة إما تطابق نمط مخاطرة معروفًا ويتم وسمها، أو لا تفعل ذلك، دون أي سببٍ ظاهر بينهما أو تسجيل درجات سياقية يُعرض للمستخدم. طبقة الأمان عملت، بالمعنى الضيّق، إذ التقطت ما صُممت لالتقاطه، لكن "الأذكى" يوحي بشيء أكثر استجابة من مجرد قائمة تحقق تعمل بهدوء في الخلفية. ما بدا “ذكيًا” فعليًا لم يكن الكشف نفسه، بل طريقة تأطيره — تقديم ضمانٍ ثابت كأنه يتطور يغيّر مقدار الثقة التي يمنحها المستخدم دون تغيير ما الذي يحميه فعليًا. وجدت نفسي أُصدّق الوسم أكثر بسبب اختيار الكلمات، قبل أن أرى فعليًا أنه يتعامل مع أي شيء ملتبس. هل من المثير للفضول ما إذا كان "الأذكى" هنا يعني أن النظام كذلك، أم أن الأمر مجرد قصة تُروى عنه؟
#newt $NEWT @NewtonProtocol
"الأذكى" يوحي بأن النظام يتعلّم أو يحكم على شيء ما، لذلك انتبهت إلى أين تجسّدت “الذكاء” فعليًا مقارنةً بما كان مجرد قاعدة ثابتة. بروتوكول نيوتن، $NEWT ، #NewtonProtocol، @NewtonProtocol إطارًا لأمن البلوك تشين كونه أكثر ذكاءً، لكن ما رأيته أثناء تنفيذ المهمة بدا أقرب إلى عتبات ثابتة من كونه حكمًا تكيفيًا — فالمعاملة إما تطابق نمط مخاطرة معروفًا ويتم وسمها، أو لا تفعل ذلك، دون أي سببٍ ظاهر بينهما أو تسجيل درجات سياقية يُعرض للمستخدم. طبقة الأمان عملت، بالمعنى الضيّق، إذ التقطت ما صُممت لالتقاطه، لكن "الأذكى" يوحي بشيء أكثر استجابة من مجرد قائمة تحقق تعمل بهدوء في الخلفية. ما بدا “ذكيًا” فعليًا لم يكن الكشف نفسه، بل طريقة تأطيره — تقديم ضمانٍ ثابت كأنه يتطور يغيّر مقدار الثقة التي يمنحها المستخدم دون تغيير ما الذي يحميه فعليًا. وجدت نفسي أُصدّق الوسم أكثر بسبب اختيار الكلمات، قبل أن أرى فعليًا أنه يتعامل مع أي شيء ملتبس. هل من المثير للفضول ما إذا كان "الأذكى" هنا يعني أن النظام كذلك، أم أن الأمر مجرد قصة تُروى عنه؟
"الأذكى" يوحي بأن النظام يتعلّم أو يحكم على شيء ما، لذلك انتبهت إلى أين تجسّدت “الذكاء” فعليًا مقارنةً بما كان مجرد قاعدة ثابتة. بروتوكول نيوتن، $NEWT ، #NewtonProtocol، @NewtonProtocol إطارًا لأمن البلوك تشين كونه أكثر ذكاءً، لكن ما رأيته أثناء تنفيذ المهمة بدا أقرب إلى عتبات ثابتة من كونه حكمًا تكيفيًا — فالمعاملة إما تطابق نمط مخاطرة معروفًا ويتم وسمها، أو لا تفعل ذلك، دون أي سببٍ ظاهر بينهما أو تسجيل درجات سياقية يُعرض للمستخدم. طبقة الأمان عملت، بالمعنى الضيّق، إذ التقطت ما صُممت لالتقاطه، لكن "الأذكى" يوحي بشيء أكثر استجابة من مجرد قائمة تحقق تعمل بهدوء في الخلفية. ما بدا “ذكيًا” فعليًا لم يكن الكشف نفسه، بل طريقة تأطيره — تقديم ضمانٍ ثابت كأنه يتطور يغيّر مقدار الثقة التي يمنحها المستخدم دون تغيير ما الذي يحميه فعليًا. وجدت نفسي أُصدّق الوسم أكثر بسبب اختيار الكلمات، قبل أن أرى فعليًا أنه يتعامل مع أي شيء ملتبس. هل من المثير للفضول ما إذا كان "الأذكى" هنا يعني أن النظام كذلك، أم أن الأمر مجرد قصة تُروى عنه؟
67
·
--
عرض الترجمة
Newton Protocol Delivers a New Layer of Blockchain TrustMarket felt weirdly quiet today. Not dead-quiet, just that low-hum, nobody's-committing kind of quiet where you refresh charts out of habit more than curiosity. I wasn't planning to look at anything new. I was actually trying to clean up a wallet full of old approvals, half-annoyed at how many permissions I'd granted to contracts I don't even remember using anymore.
So while I was doing that, I ended up going down a small rabbit hole on Newton Protocol, mostly because the phrase "new layer of trust" kept showing up and I wanted to know what that actually meant mechanically, not just as a tagline.
Here's the thing that caught me. I went in assuming "trust layer" meant some new verification step added on top of a transaction — like an extra checkpoint before something executes. That's the mental model most people carry around, I think, because that's how most security add-ons in crypto have worked so far. Flag it, pause it, confirm it. But that's not really what's happening here. What Newton seems to be doing is closer to restructuring how the transaction is evaluated before it even reaches you, not after. It's less "here's a warning" and more "here's a transaction that's already been shaped by context you didn't see." Small distinction, but it changes who's actually in control of the decision.
And this is the part I keep chewing on. If the trust layer operates before you see the outcome, then trust isn't really something you're choosing to extend anymore — it's something you're inheriting from a process you didn't watch happen. I thought that would bother me more than it did, honestly. I expected to feel resistant to it, the way I usually do with anything that quietly removes a decision point from the user. But in practice it felt less invasive than I assumed, mostly because most of my transactions are boring and repetitive anyway. Approve, swap, bridge, repeat. Still, "less invasive because my activity is unremarkable" isn't the same as "safe by design," and I noticed myself doing that substitution without meaning to.
JimHere's the part that bothers me, though. Systems that pre-shape trust work great until the moment they meet something genuinely unusual — a new contract, an edge-case interaction, something nobody's pattern-matched yet. That's exactly when you'd want the extra scrutiny, and it's exactly the moment these background systems are least tested. I'm not fully convinced this holds up under real pressure, the kind that only shows up during a chaotic market, not a quiet Tuesday like today. Everything looks smart when the inputs are calm.
There's also a smaller thing nagging at me — if trust is being constructed upstream, invisibly, then the language of "trust" almost does more work than the mechanism itself. It reassures you before you've had a reason to feel reassured. I'm not saying that's dishonest. I just noticed I trusted the phrase before I understood what was producing it, and that's a strange order to do things in, even for someone who spends a lot of time looking at this stuff.
Who this actually matters for, I think, isn't the people already deep in DeFi who read every transaction line by line — it's the much larger group who click through fast and rely on the interface to catch what they'd miss. For them this could genuinely matter. For power users, it might feel like a layer they didn't ask for, sitting quietly underneath decisions they thought were fully theirs.
Anyway. Market's still sitting in that same flat, waiting mood. I'll probably keep an eye on how this behaves the next time something actually stress-tests it, because a quiet day tells you very little about a system built for the messy ones.
@NewtonProtocol #Newt $NEWT
Newton Protocol Delivers a New Layer of Blockchain Trust
Market felt weirdly quiet today. Not dead-quiet, just that low-hum, nobody's-committing kind of quiet where you refresh charts out of habit more than curiosity. I wasn't planning to look at anything new. I was actually trying to clean up a wallet full of old approvals, half-annoyed at how many permissions I'd granted to contracts I don't even remember using anymore.
So while I was doing that, I ended up going down a small rabbit hole on Newton Protocol, mostly because the phrase "new layer of trust" kept showing up and I wanted to know what that actually meant mechanically, not just as a tagline.
Here's the thing that caught me. I went in assuming "trust layer" meant some new verification step added on top of a transaction — like an extra checkpoint before something executes. That's the mental model most people carry around, I think, because that's how most security add-ons in crypto have worked so far. Flag it, pause it, confirm it. But that's not really what's happening here. What Newton seems to be doing is closer to restructuring how the transaction is evaluated before it even reaches you, not after. It's less "here's a warning" and more "here's a transaction that's already been shaped by context you didn't see." Small distinction, but it changes who's actually in control of the decision.
And this is the part I keep chewing on. If the trust layer operates before you see the outcome, then trust isn't really something you're choosing to extend anymore — it's something you're inheriting from a process you didn't watch happen. I thought that would bother me more than it did, honestly. I expected to feel resistant to it, the way I usually do with anything that quietly removes a decision point from the user. But in practice it felt less invasive than I assumed, mostly because most of my transactions are boring and repetitive anyway. Approve, swap, bridge, repeat. Still, "less invasive because my activity is unremarkable" isn't the same as "safe by design," and I noticed myself doing that substitution without meaning to.
JimHere's the part that bothers me, though. Systems that pre-shape trust work great until the moment they meet something genuinely unusual — a new contract, an edge-case interaction, something nobody's pattern-matched yet. That's exactly when you'd want the extra scrutiny, and it's exactly the moment these background systems are least tested. I'm not fully convinced this holds up under real pressure, the kind that only shows up during a chaotic market, not a quiet Tuesday like today. Everything looks smart when the inputs are calm.
There's also a smaller thing nagging at me — if trust is being constructed upstream, invisibly, then the language of "trust" almost does more work than the mechanism itself. It reassures you before you've had a reason to feel reassured. I'm not saying that's dishonest. I just noticed I trusted the phrase before I understood what was producing it, and that's a strange order to do things in, even for someone who spends a lot of time looking at this stuff.
Who this actually matters for, I think, isn't the people already deep in DeFi who read every transaction line by line — it's the much larger group who click through fast and rely on the interface to catch what they'd miss. For them this could genuinely matter. For power users, it might feel like a layer they didn't ask for, sitting quietly underneath decisions they thought were fully theirs.
Anyway. Market's still sitting in that same flat, waiting mood. I'll probably keep an eye on how this behaves the next time something actually stress-tests it, because a quiet day tells you very little about a system built for the messy ones.
@NewtonProtocol #Newt $NEWT
So while I was doing that, I ended up going down a small rabbit hole on Newton Protocol, mostly because the phrase "new layer of trust" kept showing up and I wanted to know what that actually meant mechanically, not just as a tagline.
Here's the thing that caught me. I went in assuming "trust layer" meant some new verification step added on top of a transaction — like an extra checkpoint before something executes. That's the mental model most people carry around, I think, because that's how most security add-ons in crypto have worked so far. Flag it, pause it, confirm it. But that's not really what's happening here. What Newton seems to be doing is closer to restructuring how the transaction is evaluated before it even reaches you, not after. It's less "here's a warning" and more "here's a transaction that's already been shaped by context you didn't see." Small distinction, but it changes who's actually in control of the decision.
And this is the part I keep chewing on. If the trust layer operates before you see the outcome, then trust isn't really something you're choosing to extend anymore — it's something you're inheriting from a process you didn't watch happen. I thought that would bother me more than it did, honestly. I expected to feel resistant to it, the way I usually do with anything that quietly removes a decision point from the user. But in practice it felt less invasive than I assumed, mostly because most of my transactions are boring and repetitive anyway. Approve, swap, bridge, repeat. Still, "less invasive because my activity is unremarkable" isn't the same as "safe by design," and I noticed myself doing that substitution without meaning to.
JimHere's the part that bothers me, though. Systems that pre-shape trust work great until the moment they meet something genuinely unusual — a new contract, an edge-case interaction, something nobody's pattern-matched yet. That's exactly when you'd want the extra scrutiny, and it's exactly the moment these background systems are least tested. I'm not fully convinced this holds up under real pressure, the kind that only shows up during a chaotic market, not a quiet Tuesday like today. Everything looks smart when the inputs are calm.
There's also a smaller thing nagging at me — if trust is being constructed upstream, invisibly, then the language of "trust" almost does more work than the mechanism itself. It reassures you before you've had a reason to feel reassured. I'm not saying that's dishonest. I just noticed I trusted the phrase before I understood what was producing it, and that's a strange order to do things in, even for someone who spends a lot of time looking at this stuff.
Who this actually matters for, I think, isn't the people already deep in DeFi who read every transaction line by line — it's the much larger group who click through fast and rely on the interface to catch what they'd miss. For them this could genuinely matter. For power users, it might feel like a layer they didn't ask for, sitting quietly underneath decisions they thought were fully theirs.
Anyway. Market's still sitting in that same flat, waiting mood. I'll probably keep an eye on how this behaves the next time something actually stress-tests it, because a quiet day tells you very little about a system built for the messy ones.
@NewtonProtocol #Newt $NEWT
1
69
·
--
#newt $NEWT @NewtonProtocol
قارنتُ النسبة الفعلية من إجمالي القيمة المقفلة في بروتوكول نيوتن إلى الاهتمام المحيط به مع زوجٍ من رموز الأتمتة الأخرى التي كانت تحظى بهيب مماثل، وهما GEL وLINK، وذلك في مهمة على CreatorPad بعنوان "لماذا يهم نيوتن للأجيال القادمة من التمويل اللامركزي". كنتُ أتساءل إن كان نصيب الاهتمام (mindshare) ورأس المال الحقيقي الملتزم يتحركان معًا. $NEWT، #NewtonProtocol، @NewtonProtocol. ما برز لي هو أن الإشارات الاجتماعية والمحتوى على نمط CreatorPad حول نيوتن قد نما بشكل أسرع بكثير من القيمة المقفلة فعليًا أو الأتمتة التي يتم تنفيذها بشكل نشط عبر البروتوكول. وقد مرّت كلٌّ من GEL وLINK بهذا الفارق أيضًا في وقت مبكر، لكنهما في النهاية أغلقتا الفجوة مع الوقت عندما لحق الاستخدام بالسرد. تبدو فجوة نيوتن الآن أوسع من فجوة أيٍّ منهما في مرحلة مماثلة، على الأقل استنادًا إلى ما استطعتُ مقارنته. لذا فإن "الجيل القادم من التمويل اللامركزي" يدور ويتداول على نطاق واسع قبل أن تختبر رأس المال فعليًا ما إذا كانت هذه الأجيال تعمل على نطاق واسع. ليس ذلك أمرًا غير معتاد في هذه المرحلة؛ فمعظم البنية التحتية يُتحدث عنها قبل استخدامها، لكن حجم الفجوة جعلني أرغب في متابعتها فعليًا بدلًا من افتراض أنها ستغلق بالطريقة نفسها التي حدثت مع فجوة GEL أو LINK. أتساءل: كم من الوقت يستغرق الأمر حتى يلحق الاستخدام فعليًا بالقدر الكبير الذي يتم الحديث عنه بالفعل؟
#newt $NEWT @NewtonProtocol
قارنتُ النسبة الفعلية من إجمالي القيمة المقفلة في بروتوكول نيوتن إلى الاهتمام المحيط به مع زوجٍ من رموز الأتمتة الأخرى التي كانت تحظى بهيب مماثل، وهما GEL وLINK، وذلك في مهمة على CreatorPad بعنوان "لماذا يهم نيوتن للأجيال القادمة من التمويل اللامركزي". كنتُ أتساءل إن كان نصيب الاهتمام (mindshare) ورأس المال الحقيقي الملتزم يتحركان معًا. $NEWT ، #NewtonProtocol، @NewtonProtocol. ما برز لي هو أن الإشارات الاجتماعية والمحتوى على نمط CreatorPad حول نيوتن قد نما بشكل أسرع بكثير من القيمة المقفلة فعليًا أو الأتمتة التي يتم تنفيذها بشكل نشط عبر البروتوكول. وقد مرّت كلٌّ من GEL وLINK بهذا الفارق أيضًا في وقت مبكر، لكنهما في النهاية أغلقتا الفجوة مع الوقت عندما لحق الاستخدام بالسرد. تبدو فجوة نيوتن الآن أوسع من فجوة أيٍّ منهما في مرحلة مماثلة، على الأقل استنادًا إلى ما استطعتُ مقارنته. لذا فإن "الجيل القادم من التمويل اللامركزي" يدور ويتداول على نطاق واسع قبل أن تختبر رأس المال فعليًا ما إذا كانت هذه الأجيال تعمل على نطاق واسع. ليس ذلك أمرًا غير معتاد في هذه المرحلة؛ فمعظم البنية التحتية يُتحدث عنها قبل استخدامها، لكن حجم الفجوة جعلني أرغب في متابعتها فعليًا بدلًا من افتراض أنها ستغلق بالطريقة نفسها التي حدثت مع فجوة GEL أو LINK. أتساءل: كم من الوقت يستغرق الأمر حتى يلحق الاستخدام فعليًا بالقدر الكبير الذي يتم الحديث عنه بالفعل؟
قارنتُ النسبة الفعلية من إجمالي القيمة المقفلة في بروتوكول نيوتن إلى الاهتمام المحيط به مع زوجٍ من رموز الأتمتة الأخرى التي كانت تحظى بهيب مماثل، وهما GEL وLINK، وذلك في مهمة على CreatorPad بعنوان "لماذا يهم نيوتن للأجيال القادمة من التمويل اللامركزي". كنتُ أتساءل إن كان نصيب الاهتمام (mindshare) ورأس المال الحقيقي الملتزم يتحركان معًا. $NEWT ، #NewtonProtocol، @NewtonProtocol. ما برز لي هو أن الإشارات الاجتماعية والمحتوى على نمط CreatorPad حول نيوتن قد نما بشكل أسرع بكثير من القيمة المقفلة فعليًا أو الأتمتة التي يتم تنفيذها بشكل نشط عبر البروتوكول. وقد مرّت كلٌّ من GEL وLINK بهذا الفارق أيضًا في وقت مبكر، لكنهما في النهاية أغلقتا الفجوة مع الوقت عندما لحق الاستخدام بالسرد. تبدو فجوة نيوتن الآن أوسع من فجوة أيٍّ منهما في مرحلة مماثلة، على الأقل استنادًا إلى ما استطعتُ مقارنته. لذا فإن "الجيل القادم من التمويل اللامركزي" يدور ويتداول على نطاق واسع قبل أن تختبر رأس المال فعليًا ما إذا كانت هذه الأجيال تعمل على نطاق واسع. ليس ذلك أمرًا غير معتاد في هذه المرحلة؛ فمعظم البنية التحتية يُتحدث عنها قبل استخدامها، لكن حجم الفجوة جعلني أرغب في متابعتها فعليًا بدلًا من افتراض أنها ستغلق بالطريقة نفسها التي حدثت مع فجوة GEL أو LINK. أتساءل: كم من الوقت يستغرق الأمر حتى يلحق الاستخدام فعليًا بالقدر الكبير الذي يتم الحديث عنه بالفعل؟
9
3
220
·
--
بروتوكول نيوتن يجلب معيارًا جديدًا إلى أمن onchainبروتوكول نيوتن: معيار يحتاج إلى أكثر من تطبيق واحد
كنت أعيد ضبط مركز المنزل الذكي صباحًا، للأمر المضحك، لأن علامتين مختلفتين من مصابيح الإضاءة التي أملكهما لا تتحدثان معًا بالشكل الصحيح رغم أن كليهما يدّعي أنهما يدعمان "نفس" المعيار اللاسلكي. قضيت عشرين دقيقة مع القهوة فقط لأجعل مصباحًا واحدًا يستجيب. اتضح أن عبارة "المعيار" وعبارة "يعمل بالطريقة نفسها في كل مكان" ليستا دائمًا الادعاء نفسه.
كان ذلك الإزعاج لا يزال حاضرًا عندما عدت لاحقًا إلى مواد بروتوكول نيوتن، هذه المرة حول "جلب معيار جديد إلى أمن onchain". وجعلني مصباح الإضاءة الذكي أتوقف فعلًا عند كلمة "المعيار" بدلًا من تجاوزها كعادتي. المعيار، بحكم التعريف، هو شيء تتبناه وتطبّقه بشكل متوافق أطراف متعددة ومستقلة. لذا بحثت تحديدًا: هل نموذج الأمان الخاص بـ TEE-plus-ZK لدى نيوتن هو شيء تتبنّاه وتبني حوله تطبيقات متوافقة له مشاريع مستقلة أخرى فعليًا؟ أم أنه بنية معمارية خاصة بمشروع واحد، تستخدم فقط لبنات تشفير قياسية يشيع استخدامها؟
بروتوكول نيوتن يجلب معيارًا جديدًا إلى أمن onchain
بروتوكول نيوتن: معيار يحتاج إلى أكثر من تطبيق واحد
كنت أعيد ضبط مركز المنزل الذكي صباحًا، للأمر المضحك، لأن علامتين مختلفتين من مصابيح الإضاءة التي أملكهما لا تتحدثان معًا بالشكل الصحيح رغم أن كليهما يدّعي أنهما يدعمان "نفس" المعيار اللاسلكي. قضيت عشرين دقيقة مع القهوة فقط لأجعل مصباحًا واحدًا يستجيب. اتضح أن عبارة "المعيار" وعبارة "يعمل بالطريقة نفسها في كل مكان" ليستا دائمًا الادعاء نفسه.
كان ذلك الإزعاج لا يزال حاضرًا عندما عدت لاحقًا إلى مواد بروتوكول نيوتن، هذه المرة حول "جلب معيار جديد إلى أمن onchain". وجعلني مصباح الإضاءة الذكي أتوقف فعلًا عند كلمة "المعيار" بدلًا من تجاوزها كعادتي. المعيار، بحكم التعريف، هو شيء تتبناه وتطبّقه بشكل متوافق أطراف متعددة ومستقلة. لذا بحثت تحديدًا: هل نموذج الأمان الخاص بـ TEE-plus-ZK لدى نيوتن هو شيء تتبنّاه وتبني حوله تطبيقات متوافقة له مشاريع مستقلة أخرى فعليًا؟ أم أنه بنية معمارية خاصة بمشروع واحد، تستخدم فقط لبنات تشفير قياسية يشيع استخدامها؟
كنت أعيد ضبط مركز المنزل الذكي صباحًا، للأمر المضحك، لأن علامتين مختلفتين من مصابيح الإضاءة التي أملكهما لا تتحدثان معًا بالشكل الصحيح رغم أن كليهما يدّعي أنهما يدعمان "نفس" المعيار اللاسلكي. قضيت عشرين دقيقة مع القهوة فقط لأجعل مصباحًا واحدًا يستجيب. اتضح أن عبارة "المعيار" وعبارة "يعمل بالطريقة نفسها في كل مكان" ليستا دائمًا الادعاء نفسه.
كان ذلك الإزعاج لا يزال حاضرًا عندما عدت لاحقًا إلى مواد بروتوكول نيوتن، هذه المرة حول "جلب معيار جديد إلى أمن onchain". وجعلني مصباح الإضاءة الذكي أتوقف فعلًا عند كلمة "المعيار" بدلًا من تجاوزها كعادتي. المعيار، بحكم التعريف، هو شيء تتبناه وتطبّقه بشكل متوافق أطراف متعددة ومستقلة. لذا بحثت تحديدًا: هل نموذج الأمان الخاص بـ TEE-plus-ZK لدى نيوتن هو شيء تتبنّاه وتبني حوله تطبيقات متوافقة له مشاريع مستقلة أخرى فعليًا؟ أم أنه بنية معمارية خاصة بمشروع واحد، تستخدم فقط لبنات تشفير قياسية يشيع استخدامها؟
3
1
88
·
--
#newt $NEWT @NewtonProtocol
أثناء إنجاز بعض المهام الروتينية على السلسلة في CreatorPad، توقّفت عند Newton Protocol، إذ لاحظت أن توسيع نطاق الابتكار المستقل ما زال يعتمد كثيرًا على الحدود التي يحددها البشر. عمليًا، مع $NEWT #Newton @newton_xyz، يتيح النظام لوكلاء الذكاء الاصطناعي تولّي العمليات المتكررة مع تنفيذ يمكن التحقق منه، لكن تجاوز الحدود فعليًا لا يحدث إلا بعد أن يستثمر المستخدمون وقتًا في تحديد نطاقات الأذونات الدقيقة وعتبات السمعة—على خلاف ما يوحي به مفهوم الاستقلالية الأوسع. وتُظهر رموز مرتبطة مثل $SAHARA و$FET مسارات موازية يلتقي فيها إمكانات الوكلاء بالقيود العملية.
برزت ملاحظة واحدة: تعمل الأتمتة الافتراضية ذات الإجراء الواحد بموثوقية وبأقل قدر من الإعداد، لكن التوجه نحو الابتكار متعدد الخطوات أو السلوكيات التكيفية يُظهر خيار التصميم المتمثل في فرض ضمانات وسياسات صارمة. وهذا يعزز الأمان، لكنه يحد من الإحساس بـ«الاستقلالية» في المراحل الأولى من الاستخدام. وجعلني ذلك أتأمل بهدوء المفاضلة بين السلامة والتوسع الحقيقي دون تدخل.
ما زلت أتساءل عن مدى سرعة تخفيف هذه الحدود مع ازدياد عدد المشغّلين الذين يبنون سمعتهم، أم أن التحكم القابل للتحقق سيتطلب دائمًا هذا القدر المتعمد من الاحتكاك.
#newt $NEWT @NewtonProtocol
أثناء إنجاز بعض المهام الروتينية على السلسلة في CreatorPad، توقّفت عند Newton Protocol، إذ لاحظت أن توسيع نطاق الابتكار المستقل ما زال يعتمد كثيرًا على الحدود التي يحددها البشر. عمليًا، مع $NEWT #Newton @newton_xyz، يتيح النظام لوكلاء الذكاء الاصطناعي تولّي العمليات المتكررة مع تنفيذ يمكن التحقق منه، لكن تجاوز الحدود فعليًا لا يحدث إلا بعد أن يستثمر المستخدمون وقتًا في تحديد نطاقات الأذونات الدقيقة وعتبات السمعة—على خلاف ما يوحي به مفهوم الاستقلالية الأوسع. وتُظهر رموز مرتبطة مثل $SAHARA و$FET مسارات موازية يلتقي فيها إمكانات الوكلاء بالقيود العملية.
برزت ملاحظة واحدة: تعمل الأتمتة الافتراضية ذات الإجراء الواحد بموثوقية وبأقل قدر من الإعداد، لكن التوجه نحو الابتكار متعدد الخطوات أو السلوكيات التكيفية يُظهر خيار التصميم المتمثل في فرض ضمانات وسياسات صارمة. وهذا يعزز الأمان، لكنه يحد من الإحساس بـ«الاستقلالية» في المراحل الأولى من الاستخدام. وجعلني ذلك أتأمل بهدوء المفاضلة بين السلامة والتوسع الحقيقي دون تدخل.
ما زلت أتساءل عن مدى سرعة تخفيف هذه الحدود مع ازدياد عدد المشغّلين الذين يبنون سمعتهم، أم أن التحكم القابل للتحقق سيتطلب دائمًا هذا القدر المتعمد من الاحتكاك.
أثناء إنجاز بعض المهام الروتينية على السلسلة في CreatorPad، توقّفت عند Newton Protocol، إذ لاحظت أن توسيع نطاق الابتكار المستقل ما زال يعتمد كثيرًا على الحدود التي يحددها البشر. عمليًا، مع $NEWT #Newton @newton_xyz، يتيح النظام لوكلاء الذكاء الاصطناعي تولّي العمليات المتكررة مع تنفيذ يمكن التحقق منه، لكن تجاوز الحدود فعليًا لا يحدث إلا بعد أن يستثمر المستخدمون وقتًا في تحديد نطاقات الأذونات الدقيقة وعتبات السمعة—على خلاف ما يوحي به مفهوم الاستقلالية الأوسع. وتُظهر رموز مرتبطة مثل $SAHARA و$FET مسارات موازية يلتقي فيها إمكانات الوكلاء بالقيود العملية.
برزت ملاحظة واحدة: تعمل الأتمتة الافتراضية ذات الإجراء الواحد بموثوقية وبأقل قدر من الإعداد، لكن التوجه نحو الابتكار متعدد الخطوات أو السلوكيات التكيفية يُظهر خيار التصميم المتمثل في فرض ضمانات وسياسات صارمة. وهذا يعزز الأمان، لكنه يحد من الإحساس بـ«الاستقلالية» في المراحل الأولى من الاستخدام. وجعلني ذلك أتأمل بهدوء المفاضلة بين السلامة والتوسع الحقيقي دون تدخل.
ما زلت أتساءل عن مدى سرعة تخفيف هذه الحدود مع ازدياد عدد المشغّلين الذين يبنون سمعتهم، أم أن التحكم القابل للتحقق سيتطلب دائمًا هذا القدر المتعمد من الاحتكاك.
8
1
262
·
--
عرض الترجمة
Newton Protocol Creating a Smarter Future for On-Chain SystemsMarket felt weirdly quiet today. Charts barely moving, everyone refreshing the same feeds, and I caught myself doom-scrolling through random project threads instead of staring at positions. Out of curiosity, I clicked into something about Newton Protocol because a friend had mentioned it in passing last week.
So I started looking at $NEWT and how it’s trying to handle AI agents on-chain. I thought it would be another one of those “trust the code” stories. But the more I dug into actual usage during the CreatorPad tasks, something clicked that’s been sitting with me since.
People are looking at this whole verifiable automation thing wrong. Everyone talks like the big unlock is finally handing over control to smart AI agents that just work. The narrative is all seamless delegation, set-it-and-forget-it portfolio moves, treasury runs, whatever. What actually happens is more like giving your keys to a very careful but still learning driver who needs you to pre-approve every slightly unusual turn.
What people assume is that you just define loose policies and the system takes care of the rest with zero-knowledge proofs or whatever magic keeps it safe. What actually happens is you end up spending real time tightening those permission slips and session keys, especially once you move past basic single-action stuff. During the task I tried a simple recurring flow and it was smooth. Then I tried layering in a couple conditions across chains and suddenly I was tweaking guardrails more than I expected. The verifiability is there, but it forces you to be more deliberate than the “AI future” hype suggests.
Here’s the part that bothers me though: if the whole point is reducing human error and complexity in on-chain ops, why does getting the advanced cases right still feel like it demands more upfront thinking than just doing it manually sometimes? I’m not fully convinced this holds under real market pressure when volatility spikes and agents need to react fast. What if the reputation systems and collateral requirements make operators too cautious, slowing things down exactly when speed matters?
It matters most for people who already manage more than a few positions or small team treasuries—those who are tired of babysitting every tx but also scared of losing control. For pure degen plays or super simple holders, it might still feel like overkill right now. The quiet realization is that Newton isn’t removing the need for oversight; it’s making the oversight programmable and auditable. That’s smarter in the long run, but it’s not the hands-free revolution some threads are painting.
I thought it would feel more magical. But actually, the value is in how it forces better discipline while still opening the door for agents to handle the boring parts reliably.
Anyway, market still looks shaky and I’ll probably just watch how this plays out over the next few weeks. Might tinker with another small setup tomorrow.
@NewtonProtocol #Newt $NEWT
Newton Protocol Creating a Smarter Future for On-Chain Systems
Market felt weirdly quiet today. Charts barely moving, everyone refreshing the same feeds, and I caught myself doom-scrolling through random project threads instead of staring at positions. Out of curiosity, I clicked into something about Newton Protocol because a friend had mentioned it in passing last week.
So I started looking at $NEWT and how it’s trying to handle AI agents on-chain. I thought it would be another one of those “trust the code” stories. But the more I dug into actual usage during the CreatorPad tasks, something clicked that’s been sitting with me since.
People are looking at this whole verifiable automation thing wrong. Everyone talks like the big unlock is finally handing over control to smart AI agents that just work. The narrative is all seamless delegation, set-it-and-forget-it portfolio moves, treasury runs, whatever. What actually happens is more like giving your keys to a very careful but still learning driver who needs you to pre-approve every slightly unusual turn.
What people assume is that you just define loose policies and the system takes care of the rest with zero-knowledge proofs or whatever magic keeps it safe. What actually happens is you end up spending real time tightening those permission slips and session keys, especially once you move past basic single-action stuff. During the task I tried a simple recurring flow and it was smooth. Then I tried layering in a couple conditions across chains and suddenly I was tweaking guardrails more than I expected. The verifiability is there, but it forces you to be more deliberate than the “AI future” hype suggests.
Here’s the part that bothers me though: if the whole point is reducing human error and complexity in on-chain ops, why does getting the advanced cases right still feel like it demands more upfront thinking than just doing it manually sometimes? I’m not fully convinced this holds under real market pressure when volatility spikes and agents need to react fast. What if the reputation systems and collateral requirements make operators too cautious, slowing things down exactly when speed matters?
It matters most for people who already manage more than a few positions or small team treasuries—those who are tired of babysitting every tx but also scared of losing control. For pure degen plays or super simple holders, it might still feel like overkill right now. The quiet realization is that Newton isn’t removing the need for oversight; it’s making the oversight programmable and auditable. That’s smarter in the long run, but it’s not the hands-free revolution some threads are painting.
I thought it would feel more magical. But actually, the value is in how it forces better discipline while still opening the door for agents to handle the boring parts reliably.
Anyway, market still looks shaky and I’ll probably just watch how this plays out over the next few weeks. Might tinker with another small setup tomorrow.
@NewtonProtocol #Newt $NEWT
So I started looking at $NEWT and how it’s trying to handle AI agents on-chain. I thought it would be another one of those “trust the code” stories. But the more I dug into actual usage during the CreatorPad tasks, something clicked that’s been sitting with me since.
People are looking at this whole verifiable automation thing wrong. Everyone talks like the big unlock is finally handing over control to smart AI agents that just work. The narrative is all seamless delegation, set-it-and-forget-it portfolio moves, treasury runs, whatever. What actually happens is more like giving your keys to a very careful but still learning driver who needs you to pre-approve every slightly unusual turn.
What people assume is that you just define loose policies and the system takes care of the rest with zero-knowledge proofs or whatever magic keeps it safe. What actually happens is you end up spending real time tightening those permission slips and session keys, especially once you move past basic single-action stuff. During the task I tried a simple recurring flow and it was smooth. Then I tried layering in a couple conditions across chains and suddenly I was tweaking guardrails more than I expected. The verifiability is there, but it forces you to be more deliberate than the “AI future” hype suggests.
Here’s the part that bothers me though: if the whole point is reducing human error and complexity in on-chain ops, why does getting the advanced cases right still feel like it demands more upfront thinking than just doing it manually sometimes? I’m not fully convinced this holds under real market pressure when volatility spikes and agents need to react fast. What if the reputation systems and collateral requirements make operators too cautious, slowing things down exactly when speed matters?
It matters most for people who already manage more than a few positions or small team treasuries—those who are tired of babysitting every tx but also scared of losing control. For pure degen plays or super simple holders, it might still feel like overkill right now. The quiet realization is that Newton isn’t removing the need for oversight; it’s making the oversight programmable and auditable. That’s smarter in the long run, but it’s not the hands-free revolution some threads are painting.
I thought it would feel more magical. But actually, the value is in how it forces better discipline while still opening the door for agents to handle the boring parts reliably.
Anyway, market still looks shaky and I’ll probably just watch how this plays out over the next few weeks. Might tinker with another small setup tomorrow.
@NewtonProtocol #Newt $NEWT
74
·
--
@NewtonProtocol #Newt $NEWT
ذهبت أبحث عن تفاعل فعلي بين وكيل وآخر على بروتوكول نيوتن لمهمة في CreatorPad ضمن "تطوير التعاون بين الآلات"، وهذه المرة كنت أتفقد شيئًا أضيق من السابق — ليس ما إذا كانت الوكلاء يشتركون في الوعي، بل ما إذا كان أي وكيلين قد أجريا مباشرةً معاملةً مع بعضهما البعض أو فعّلا بعضهما على الإطلاق. $NEWT, #NewtonProtocol, @NewtonProtocol. اتضح أن الإجابة هي تقريبًا لا، وبحسب التصميم. جميع تفاعلات الوكلاء تمر عبر المسار نفسه — المستخدم يقدّم نية، ينفّذ الوكيل ذلك ضمن نطاق zkPermission الخاص به، تم — دون وجود حالة موثّقة أو نمط مدعوم يجعل ناتج وكيلٍ ما يصبح إدخالًا لوكيلٍ آخر. لذا فإن "التعاون بين الآلات" يصف قدرة مستقبلية قد يدعمها التصميم نظريًا، وليس شيئًا يحدث بين أي وكيلين حيين اليوم. كنت أظن أن التعاون يعني أن شيئًا كان يحدث بين الآلات بالفعل، حتى على نطاق صغير، لكنني وجدت بنية مصممة حاليًا للمهام المعزولة المخصصة لوكيل واحد فقط. ليست هذه انتقادًا، بل مجرد فجوة أكبر بين العبارة والحاضر مما توقعت أثناء دخولي الموضوع. أتساءل كيف يبدو أول تفاعل حقيقي بين وكيلين هنا فعليًا عندما يحدث في النهاية.
@NewtonProtocol #Newt $NEWT
ذهبت أبحث عن تفاعل فعلي بين وكيل وآخر على بروتوكول نيوتن لمهمة في CreatorPad ضمن "تطوير التعاون بين الآلات"، وهذه المرة كنت أتفقد شيئًا أضيق من السابق — ليس ما إذا كانت الوكلاء يشتركون في الوعي، بل ما إذا كان أي وكيلين قد أجريا مباشرةً معاملةً مع بعضهما البعض أو فعّلا بعضهما على الإطلاق. $NEWT , #NewtonProtocol, @NewtonProtocol. اتضح أن الإجابة هي تقريبًا لا، وبحسب التصميم. جميع تفاعلات الوكلاء تمر عبر المسار نفسه — المستخدم يقدّم نية، ينفّذ الوكيل ذلك ضمن نطاق zkPermission الخاص به، تم — دون وجود حالة موثّقة أو نمط مدعوم يجعل ناتج وكيلٍ ما يصبح إدخالًا لوكيلٍ آخر. لذا فإن "التعاون بين الآلات" يصف قدرة مستقبلية قد يدعمها التصميم نظريًا، وليس شيئًا يحدث بين أي وكيلين حيين اليوم. كنت أظن أن التعاون يعني أن شيئًا كان يحدث بين الآلات بالفعل، حتى على نطاق صغير، لكنني وجدت بنية مصممة حاليًا للمهام المعزولة المخصصة لوكيل واحد فقط. ليست هذه انتقادًا، بل مجرد فجوة أكبر بين العبارة والحاضر مما توقعت أثناء دخولي الموضوع. أتساءل كيف يبدو أول تفاعل حقيقي بين وكيلين هنا فعليًا عندما يحدث في النهاية.
ذهبت أبحث عن تفاعل فعلي بين وكيل وآخر على بروتوكول نيوتن لمهمة في CreatorPad ضمن "تطوير التعاون بين الآلات"، وهذه المرة كنت أتفقد شيئًا أضيق من السابق — ليس ما إذا كانت الوكلاء يشتركون في الوعي، بل ما إذا كان أي وكيلين قد أجريا مباشرةً معاملةً مع بعضهما البعض أو فعّلا بعضهما على الإطلاق. $NEWT , #NewtonProtocol, @NewtonProtocol. اتضح أن الإجابة هي تقريبًا لا، وبحسب التصميم. جميع تفاعلات الوكلاء تمر عبر المسار نفسه — المستخدم يقدّم نية، ينفّذ الوكيل ذلك ضمن نطاق zkPermission الخاص به، تم — دون وجود حالة موثّقة أو نمط مدعوم يجعل ناتج وكيلٍ ما يصبح إدخالًا لوكيلٍ آخر. لذا فإن "التعاون بين الآلات" يصف قدرة مستقبلية قد يدعمها التصميم نظريًا، وليس شيئًا يحدث بين أي وكيلين حيين اليوم. كنت أظن أن التعاون يعني أن شيئًا كان يحدث بين الآلات بالفعل، حتى على نطاق صغير، لكنني وجدت بنية مصممة حاليًا للمهام المعزولة المخصصة لوكيل واحد فقط. ليست هذه انتقادًا، بل مجرد فجوة أكبر بين العبارة والحاضر مما توقعت أثناء دخولي الموضوع. أتساءل كيف يبدو أول تفاعل حقيقي بين وكيلين هنا فعليًا عندما يحدث في النهاية.
4
87
·
--
بروتوكول نيوتن: بناء البنية التحتية خلف الأسواق الذاتيةبروتوكول نيوتن: البنية التحتية للأسواق، أو البنية التحتية لصفقة واحدة كبيرة مترابطة
كنت أراقب سربًا من الطيور خارج نافذتي هذا الصباح، طيورًا حقيقية، لا مخططات، أماطل بشدة. انحرف السرب بالكامل إلى اليسار في اللحظة نفسها تمامًا، كأنه كائن واحد بدلًا من مئتي طائر فردي يتخذون مئتي قرار فردي. بصراحة، كان الأمر مقلقًا بعض الشيء عند مشاهدته عن قرب، ومدهشًا كم كان متزامنًا على نحو مثالي.
كانت تلك الصورة ما تزال عالقة في رأسي عندما جلست لاحقًا مع صياغة بروتوكول نيوتن حول «بناء البنية التحتية خلف الأسواق الذاتية». وشيء ما في كلمة «الأسواق» جعلني أتوقف بطريقة مختلفة عن المعتاد. فالسوق، في جوهره، يحتاج إلى اختلاف: مشترون يعتقدون أن شيئًا ما رخيص، وبائعون يعتقدون أنه باهظ، ومعلومات مختلفة، وتفاوتات في تقبل المخاطر، وأوقات مختلفة. إن الاحتكاك بين الآراء المتعارضة هو ما يخلق فعليًا السيولة واكتشاف السعر. لذلك ذهبت وراجعت شيئًا محددًا: هل الوكلاء الذين يعملون على نيوتن يتصرفون بشكل مختلف فعلًا عن بعضهم البعض، أم أنهم أقرب إلى ذلك السرب من الطيور؟
بروتوكول نيوتن: بناء البنية التحتية خلف الأسواق الذاتية
بروتوكول نيوتن: البنية التحتية للأسواق، أو البنية التحتية لصفقة واحدة كبيرة مترابطة
كنت أراقب سربًا من الطيور خارج نافذتي هذا الصباح، طيورًا حقيقية، لا مخططات، أماطل بشدة. انحرف السرب بالكامل إلى اليسار في اللحظة نفسها تمامًا، كأنه كائن واحد بدلًا من مئتي طائر فردي يتخذون مئتي قرار فردي. بصراحة، كان الأمر مقلقًا بعض الشيء عند مشاهدته عن قرب، ومدهشًا كم كان متزامنًا على نحو مثالي.
كانت تلك الصورة ما تزال عالقة في رأسي عندما جلست لاحقًا مع صياغة بروتوكول نيوتن حول «بناء البنية التحتية خلف الأسواق الذاتية». وشيء ما في كلمة «الأسواق» جعلني أتوقف بطريقة مختلفة عن المعتاد. فالسوق، في جوهره، يحتاج إلى اختلاف: مشترون يعتقدون أن شيئًا ما رخيص، وبائعون يعتقدون أنه باهظ، ومعلومات مختلفة، وتفاوتات في تقبل المخاطر، وأوقات مختلفة. إن الاحتكاك بين الآراء المتعارضة هو ما يخلق فعليًا السيولة واكتشاف السعر. لذلك ذهبت وراجعت شيئًا محددًا: هل الوكلاء الذين يعملون على نيوتن يتصرفون بشكل مختلف فعلًا عن بعضهم البعض، أم أنهم أقرب إلى ذلك السرب من الطيور؟
كنت أراقب سربًا من الطيور خارج نافذتي هذا الصباح، طيورًا حقيقية، لا مخططات، أماطل بشدة. انحرف السرب بالكامل إلى اليسار في اللحظة نفسها تمامًا، كأنه كائن واحد بدلًا من مئتي طائر فردي يتخذون مئتي قرار فردي. بصراحة، كان الأمر مقلقًا بعض الشيء عند مشاهدته عن قرب، ومدهشًا كم كان متزامنًا على نحو مثالي.
كانت تلك الصورة ما تزال عالقة في رأسي عندما جلست لاحقًا مع صياغة بروتوكول نيوتن حول «بناء البنية التحتية خلف الأسواق الذاتية». وشيء ما في كلمة «الأسواق» جعلني أتوقف بطريقة مختلفة عن المعتاد. فالسوق، في جوهره، يحتاج إلى اختلاف: مشترون يعتقدون أن شيئًا ما رخيص، وبائعون يعتقدون أنه باهظ، ومعلومات مختلفة، وتفاوتات في تقبل المخاطر، وأوقات مختلفة. إن الاحتكاك بين الآراء المتعارضة هو ما يخلق فعليًا السيولة واكتشاف السعر. لذلك ذهبت وراجعت شيئًا محددًا: هل الوكلاء الذين يعملون على نيوتن يتصرفون بشكل مختلف فعلًا عن بعضهم البعض، أم أنهم أقرب إلى ذلك السرب من الطيور؟
1
79
·
--
عرض الترجمة
Newton Protocol Building a Reliable Framework for AI AgentsNewton Protocol: A "Framework" That Doesn't Actually Transfer
Was reorganizing my toolbox this weekend, one of those rare productive Saturdays. Had this one adjustable wrench I use for basically everything, and I remember thinking, this is the whole point of a good tool, one thing that adapts to a dozen different jobs without me needing a separate wrench for every bolt size.
That thought was still sitting there later when I got back to reading through Newton Protocol material, this time on the "building a reliable framework for AI agents" angle. Framework is a word that implies exactly that adjustable-wrench quality, something reusable, something you build once and apply across different situations with minor tweaks. So I went and actually looked at what happens when you try to stand up a second, structurally different agent after having built a first one.
And here's what caught me off guard. The permission scope, the zkPermission definition itself, isn't really reusable across agent types in any meaningful way. Building a DCA agent's permission boundary and building a rebalancing agent's permission boundary means writing two mostly separate specifications, because the actual risk surface, the specific things that need restricting, is different enough between the two that you can't just swap parameters into a shared template. Each one ends up being built close to from scratch. Which means "framework" is describing the underlying verification machinery, TEEs and proofs and all that, which genuinely is reusable and consistent. It is not describing the part a builder actually spends most of their time on, which is bespoke every single time.
I think I'd been picturing framework the way I picture my wrench, one shape that flexes to fit different jobs with small adjustments. What's actually here is closer to a really well-made workbench, solid, reliable, exactly the same every time you use it, but you still have to build a completely different jig for every different project you put on it. The workbench isn't the hard part. The jig is. And the jig is exactly the part the word "framework" implies has already been solved for you.
Here's what bothers me about that a little. Reliability, in this system, comes specifically from narrowness — the tighter and more specific a permission scope is, the more genuinely trustworthy the resulting automation. But narrowness is basically the opposite of reusability. So the same design choice that makes each individual agent reliable is the design choice that prevents the framework from behaving like an actual reusable framework across agent types. You can't really have both maximized at once, tight bespoke scopes and broad plug-and-play reuse, at least not with how this is currently structured. I don't think that's a flaw exactly, I think it might just be an honest tradeoff nobody's naming clearly. But it does mean the second agent someone builds probably takes almost as long as the first one did, which isn't really what "framework" usually promises.
That matters most, I'd guess, for anyone evaluating this as a way to scale agent development quickly across many use cases versus anyone building one very specific, very high-stakes automation and planning to stop there. For the second group, this is genuinely solid, arguably the whole point. For the first group, expecting the second, tenth, fiftieth agent to get meaningfully faster to build just because the underlying rails are shared, I think that expectation might not hold up the way the word "framework" suggests it should.
I keep going back and forth on whether that's just how security-first systems always work, tight scoping resisting reuse by nature, or whether there's a smarter middle layer that hasn't been built yet that could make permission templates more composable across agent types. Genuinely don't know.
Anyway, wrench went back in the toolbox, workbench is still there for next weekend. I'll probably keep watching whether anyone actually builds that reusable middle layer, or if bespoke stays bespoke here indefinitely.
@NewtonProtocol $NEWT #Newt
Newton Protocol Building a Reliable Framework for AI Agents
Newton Protocol: A "Framework" That Doesn't Actually Transfer
Was reorganizing my toolbox this weekend, one of those rare productive Saturdays. Had this one adjustable wrench I use for basically everything, and I remember thinking, this is the whole point of a good tool, one thing that adapts to a dozen different jobs without me needing a separate wrench for every bolt size.
That thought was still sitting there later when I got back to reading through Newton Protocol material, this time on the "building a reliable framework for AI agents" angle. Framework is a word that implies exactly that adjustable-wrench quality, something reusable, something you build once and apply across different situations with minor tweaks. So I went and actually looked at what happens when you try to stand up a second, structurally different agent after having built a first one.
And here's what caught me off guard. The permission scope, the zkPermission definition itself, isn't really reusable across agent types in any meaningful way. Building a DCA agent's permission boundary and building a rebalancing agent's permission boundary means writing two mostly separate specifications, because the actual risk surface, the specific things that need restricting, is different enough between the two that you can't just swap parameters into a shared template. Each one ends up being built close to from scratch. Which means "framework" is describing the underlying verification machinery, TEEs and proofs and all that, which genuinely is reusable and consistent. It is not describing the part a builder actually spends most of their time on, which is bespoke every single time.
I think I'd been picturing framework the way I picture my wrench, one shape that flexes to fit different jobs with small adjustments. What's actually here is closer to a really well-made workbench, solid, reliable, exactly the same every time you use it, but you still have to build a completely different jig for every different project you put on it. The workbench isn't the hard part. The jig is. And the jig is exactly the part the word "framework" implies has already been solved for you.
Here's what bothers me about that a little. Reliability, in this system, comes specifically from narrowness — the tighter and more specific a permission scope is, the more genuinely trustworthy the resulting automation. But narrowness is basically the opposite of reusability. So the same design choice that makes each individual agent reliable is the design choice that prevents the framework from behaving like an actual reusable framework across agent types. You can't really have both maximized at once, tight bespoke scopes and broad plug-and-play reuse, at least not with how this is currently structured. I don't think that's a flaw exactly, I think it might just be an honest tradeoff nobody's naming clearly. But it does mean the second agent someone builds probably takes almost as long as the first one did, which isn't really what "framework" usually promises.
That matters most, I'd guess, for anyone evaluating this as a way to scale agent development quickly across many use cases versus anyone building one very specific, very high-stakes automation and planning to stop there. For the second group, this is genuinely solid, arguably the whole point. For the first group, expecting the second, tenth, fiftieth agent to get meaningfully faster to build just because the underlying rails are shared, I think that expectation might not hold up the way the word "framework" suggests it should.
I keep going back and forth on whether that's just how security-first systems always work, tight scoping resisting reuse by nature, or whether there's a smarter middle layer that hasn't been built yet that could make permission templates more composable across agent types. Genuinely don't know.
Anyway, wrench went back in the toolbox, workbench is still there for next weekend. I'll probably keep watching whether anyone actually builds that reusable middle layer, or if bespoke stays bespoke here indefinitely.
@NewtonProtocol $NEWT #Newt
Was reorganizing my toolbox this weekend, one of those rare productive Saturdays. Had this one adjustable wrench I use for basically everything, and I remember thinking, this is the whole point of a good tool, one thing that adapts to a dozen different jobs without me needing a separate wrench for every bolt size.
That thought was still sitting there later when I got back to reading through Newton Protocol material, this time on the "building a reliable framework for AI agents" angle. Framework is a word that implies exactly that adjustable-wrench quality, something reusable, something you build once and apply across different situations with minor tweaks. So I went and actually looked at what happens when you try to stand up a second, structurally different agent after having built a first one.
And here's what caught me off guard. The permission scope, the zkPermission definition itself, isn't really reusable across agent types in any meaningful way. Building a DCA agent's permission boundary and building a rebalancing agent's permission boundary means writing two mostly separate specifications, because the actual risk surface, the specific things that need restricting, is different enough between the two that you can't just swap parameters into a shared template. Each one ends up being built close to from scratch. Which means "framework" is describing the underlying verification machinery, TEEs and proofs and all that, which genuinely is reusable and consistent. It is not describing the part a builder actually spends most of their time on, which is bespoke every single time.
I think I'd been picturing framework the way I picture my wrench, one shape that flexes to fit different jobs with small adjustments. What's actually here is closer to a really well-made workbench, solid, reliable, exactly the same every time you use it, but you still have to build a completely different jig for every different project you put on it. The workbench isn't the hard part. The jig is. And the jig is exactly the part the word "framework" implies has already been solved for you.
Here's what bothers me about that a little. Reliability, in this system, comes specifically from narrowness — the tighter and more specific a permission scope is, the more genuinely trustworthy the resulting automation. But narrowness is basically the opposite of reusability. So the same design choice that makes each individual agent reliable is the design choice that prevents the framework from behaving like an actual reusable framework across agent types. You can't really have both maximized at once, tight bespoke scopes and broad plug-and-play reuse, at least not with how this is currently structured. I don't think that's a flaw exactly, I think it might just be an honest tradeoff nobody's naming clearly. But it does mean the second agent someone builds probably takes almost as long as the first one did, which isn't really what "framework" usually promises.
That matters most, I'd guess, for anyone evaluating this as a way to scale agent development quickly across many use cases versus anyone building one very specific, very high-stakes automation and planning to stop there. For the second group, this is genuinely solid, arguably the whole point. For the first group, expecting the second, tenth, fiftieth agent to get meaningfully faster to build just because the underlying rails are shared, I think that expectation might not hold up the way the word "framework" suggests it should.
I keep going back and forth on whether that's just how security-first systems always work, tight scoping resisting reuse by nature, or whether there's a smarter middle layer that hasn't been built yet that could make permission templates more composable across agent types. Genuinely don't know.
Anyway, wrench went back in the toolbox, workbench is still there for next weekend. I'll probably keep watching whether anyone actually builds that reusable middle layer, or if bespoke stays bespoke here indefinitely.
@NewtonProtocol $NEWT #Newt
3
1
55
·
--
@NewtonProtocol #Newt $NEWT
لقد نظرتُ إلى ما يستند إليه فعليًا مفهوم "المبني على الثقة" تحت طبقة التنفيذ الخاصة ببروتوكول Newton، وذلك ضمن مهمة على CreatorPad. كنت أتوقع أن تكون "مركز الثقة" هو التشفير الخاص بالبروتوكول نفسه، لأن هذا هو ما تتم مناقشته بشكل أكبر. $NEWT، #NewtonProtocol، @NewtonProtocol. ما وجدته هو أن عنصر TEE يعتمد على ضمانات الأمان الخاصة بالشركة المصنّعة للأجهزة التي تقوم بتشغيله؛ أي أن جزءًا ذي مغزى من "الثقة" الفعلية هنا يقع على عاتق سلامة التصنيع والبرامج الثابتة الخاصة بالشركة المصنّعة للشرائح، وليس على كود Newton أو حوكمته على الإطلاق. لذلك فإن "بنية ذكاء اصطناعي مبنية على الثقة" تتمحور جزئيًا حول شركة ليست Newton، وليست لامركزية، ولا يتم ذكرها كثيرًا ضمن العرض. وهذا اعتماد شائع إلى حدّ ما بالنسبة للأنظمة المعتمدة على TEE عمومًا، وليس شيئًا فريدًا في هذا المشروع، لكنني فوجئت بمدى خروج هذه القطعة فعليًا عن نطاق تحكم البروتوكول بمجرد أن تتبعتُها. جعلني ذلك أتساءل عن مقدار لغة "المبني على الثقة" المنتشرة عبر هذه الفئة كلها، والتي تستعير الثقة بهدوء من الشركات المصنّعة للأجهزة التي لا أحد يذكرها بصوت عالٍ.
@NewtonProtocol #Newt $NEWT
لقد نظرتُ إلى ما يستند إليه فعليًا مفهوم "المبني على الثقة" تحت طبقة التنفيذ الخاصة ببروتوكول Newton، وذلك ضمن مهمة على CreatorPad. كنت أتوقع أن تكون "مركز الثقة" هو التشفير الخاص بالبروتوكول نفسه، لأن هذا هو ما تتم مناقشته بشكل أكبر. $NEWT ، #NewtonProtocol، @NewtonProtocol. ما وجدته هو أن عنصر TEE يعتمد على ضمانات الأمان الخاصة بالشركة المصنّعة للأجهزة التي تقوم بتشغيله؛ أي أن جزءًا ذي مغزى من "الثقة" الفعلية هنا يقع على عاتق سلامة التصنيع والبرامج الثابتة الخاصة بالشركة المصنّعة للشرائح، وليس على كود Newton أو حوكمته على الإطلاق. لذلك فإن "بنية ذكاء اصطناعي مبنية على الثقة" تتمحور جزئيًا حول شركة ليست Newton، وليست لامركزية، ولا يتم ذكرها كثيرًا ضمن العرض. وهذا اعتماد شائع إلى حدّ ما بالنسبة للأنظمة المعتمدة على TEE عمومًا، وليس شيئًا فريدًا في هذا المشروع، لكنني فوجئت بمدى خروج هذه القطعة فعليًا عن نطاق تحكم البروتوكول بمجرد أن تتبعتُها. جعلني ذلك أتساءل عن مقدار لغة "المبني على الثقة" المنتشرة عبر هذه الفئة كلها، والتي تستعير الثقة بهدوء من الشركات المصنّعة للأجهزة التي لا أحد يذكرها بصوت عالٍ.
لقد نظرتُ إلى ما يستند إليه فعليًا مفهوم "المبني على الثقة" تحت طبقة التنفيذ الخاصة ببروتوكول Newton، وذلك ضمن مهمة على CreatorPad. كنت أتوقع أن تكون "مركز الثقة" هو التشفير الخاص بالبروتوكول نفسه، لأن هذا هو ما تتم مناقشته بشكل أكبر. $NEWT ، #NewtonProtocol، @NewtonProtocol. ما وجدته هو أن عنصر TEE يعتمد على ضمانات الأمان الخاصة بالشركة المصنّعة للأجهزة التي تقوم بتشغيله؛ أي أن جزءًا ذي مغزى من "الثقة" الفعلية هنا يقع على عاتق سلامة التصنيع والبرامج الثابتة الخاصة بالشركة المصنّعة للشرائح، وليس على كود Newton أو حوكمته على الإطلاق. لذلك فإن "بنية ذكاء اصطناعي مبنية على الثقة" تتمحور جزئيًا حول شركة ليست Newton، وليست لامركزية، ولا يتم ذكرها كثيرًا ضمن العرض. وهذا اعتماد شائع إلى حدّ ما بالنسبة للأنظمة المعتمدة على TEE عمومًا، وليس شيئًا فريدًا في هذا المشروع، لكنني فوجئت بمدى خروج هذه القطعة فعليًا عن نطاق تحكم البروتوكول بمجرد أن تتبعتُها. جعلني ذلك أتساءل عن مقدار لغة "المبني على الثقة" المنتشرة عبر هذه الفئة كلها، والتي تستعير الثقة بهدوء من الشركات المصنّعة للأجهزة التي لا أحد يذكرها بصوت عالٍ.
1
120
·
--
عرض الترجمة
Newton Protocol Enhancing Security Through Verifiable AutomationNewton Protocol: Securing the Middle, Not the Edges
Left my phone unlocked on the kitchen counter for like ten minutes this morning while I dealt with something else, and when I came back I had this brief mini panic, not because anything happened, just that reflex of "wait, what if someone had picked that up." Nothing did happen. But it got me thinking about where security actually lives in a system, versus where you assume it lives.
That thought was still rattling around later when I sat down with Newton Protocol's material again, this time on the "enhancing security through verifiable automation" framing. And instead of just nodding at it, I found myself asking a more specific question — security against what, exactly, and security starting from where. So I went digging into the actual boundaries of what the TEE and ZK layer are protecting.
Here's what clicked, and it's a little unsettling once you see it clearly. The verification system secures the middle of the pipeline extremely well — it proves that whatever action got executed matched the rules that were signed off on. That part is airtight, genuinely. What it doesn't touch, at all, is the moment before that — how the permission got authored and signed in the first place, and by what. If the device or key that signed a permission scope gets compromised, or if someone with access just writes a permission that's technically valid but way too broad, the entire downstream system will faithfully, cryptographically prove that the resulting bad action was "correctly executed." Because it was. Correctly executed, according to instructions nobody should have given.
I think I'd been assuming, the same way I assume my phone is basically fine as long as nobody's actively hacking it remotely, that the security story here starts at the beginning and covers the whole chain end to end. It doesn't. It starts once a permission already exists and is treated as legitimate. Everything before that — the human step, the signing step, the device holding the keys — sits completely outside what gets verified. That's not a criticism of the engineering, the engineering inside its boundary is genuinely strong. It's more that the boundary is narrower than "security through verifiable automation" sounds like it's promising.
But here's the part that actually bothers me. Most real-world compromises in crypto historically haven't come from breaking cryptography, they've come from exactly this upstream layer — phished keys, compromised devices, someone approving something they shouldn't have under pressure or confusion. If that's still where the actual risk concentrates, then a system that provably secures everything after the permission exists is solving a problem that isn't usually the one that bites people. It's a bit like installing an extremely good lock on a door, while the actual break-ins mostly happen through an open window nobody's checking. I'm not saying the lock is pointless, I just don't think it changes the odds as much as the framing implies.
There's also the revocation question, which I didn't expect to care about but now can't stop thinking about — once a permission's live and an agent's mid-cycle, how fast can a user actually pull it back if something feels wrong. Haven't fully nailed down the answer there, might just be a gap in what I've read so far rather than a gap in the system itself.
Matters most, I'd guess, for anyone treating this kind of verified automation as a reason to be less careful about the upstream stuff — device hygiene, who has signing access, how permissions get reviewed before they're granted. The math doesn't really change there just because everything downstream is cryptographically airtight.
Anyway, phone's back in my pocket, nothing happened, obviously. Still checking twice before I leave it lying around though. Old habits, I guess, even when the actual risk was probably somewhere else entirely.
@NewtonProtocol #Newt $NEWT
Newton Protocol Enhancing Security Through Verifiable Automation
Newton Protocol: Securing the Middle, Not the Edges
Left my phone unlocked on the kitchen counter for like ten minutes this morning while I dealt with something else, and when I came back I had this brief mini panic, not because anything happened, just that reflex of "wait, what if someone had picked that up." Nothing did happen. But it got me thinking about where security actually lives in a system, versus where you assume it lives.
That thought was still rattling around later when I sat down with Newton Protocol's material again, this time on the "enhancing security through verifiable automation" framing. And instead of just nodding at it, I found myself asking a more specific question — security against what, exactly, and security starting from where. So I went digging into the actual boundaries of what the TEE and ZK layer are protecting.
Here's what clicked, and it's a little unsettling once you see it clearly. The verification system secures the middle of the pipeline extremely well — it proves that whatever action got executed matched the rules that were signed off on. That part is airtight, genuinely. What it doesn't touch, at all, is the moment before that — how the permission got authored and signed in the first place, and by what. If the device or key that signed a permission scope gets compromised, or if someone with access just writes a permission that's technically valid but way too broad, the entire downstream system will faithfully, cryptographically prove that the resulting bad action was "correctly executed." Because it was. Correctly executed, according to instructions nobody should have given.
I think I'd been assuming, the same way I assume my phone is basically fine as long as nobody's actively hacking it remotely, that the security story here starts at the beginning and covers the whole chain end to end. It doesn't. It starts once a permission already exists and is treated as legitimate. Everything before that — the human step, the signing step, the device holding the keys — sits completely outside what gets verified. That's not a criticism of the engineering, the engineering inside its boundary is genuinely strong. It's more that the boundary is narrower than "security through verifiable automation" sounds like it's promising.
But here's the part that actually bothers me. Most real-world compromises in crypto historically haven't come from breaking cryptography, they've come from exactly this upstream layer — phished keys, compromised devices, someone approving something they shouldn't have under pressure or confusion. If that's still where the actual risk concentrates, then a system that provably secures everything after the permission exists is solving a problem that isn't usually the one that bites people. It's a bit like installing an extremely good lock on a door, while the actual break-ins mostly happen through an open window nobody's checking. I'm not saying the lock is pointless, I just don't think it changes the odds as much as the framing implies.
There's also the revocation question, which I didn't expect to care about but now can't stop thinking about — once a permission's live and an agent's mid-cycle, how fast can a user actually pull it back if something feels wrong. Haven't fully nailed down the answer there, might just be a gap in what I've read so far rather than a gap in the system itself.
Matters most, I'd guess, for anyone treating this kind of verified automation as a reason to be less careful about the upstream stuff — device hygiene, who has signing access, how permissions get reviewed before they're granted. The math doesn't really change there just because everything downstream is cryptographically airtight.
Anyway, phone's back in my pocket, nothing happened, obviously. Still checking twice before I leave it lying around though. Old habits, I guess, even when the actual risk was probably somewhere else entirely.
@NewtonProtocol #Newt $NEWT
Left my phone unlocked on the kitchen counter for like ten minutes this morning while I dealt with something else, and when I came back I had this brief mini panic, not because anything happened, just that reflex of "wait, what if someone had picked that up." Nothing did happen. But it got me thinking about where security actually lives in a system, versus where you assume it lives.
That thought was still rattling around later when I sat down with Newton Protocol's material again, this time on the "enhancing security through verifiable automation" framing. And instead of just nodding at it, I found myself asking a more specific question — security against what, exactly, and security starting from where. So I went digging into the actual boundaries of what the TEE and ZK layer are protecting.
Here's what clicked, and it's a little unsettling once you see it clearly. The verification system secures the middle of the pipeline extremely well — it proves that whatever action got executed matched the rules that were signed off on. That part is airtight, genuinely. What it doesn't touch, at all, is the moment before that — how the permission got authored and signed in the first place, and by what. If the device or key that signed a permission scope gets compromised, or if someone with access just writes a permission that's technically valid but way too broad, the entire downstream system will faithfully, cryptographically prove that the resulting bad action was "correctly executed." Because it was. Correctly executed, according to instructions nobody should have given.
I think I'd been assuming, the same way I assume my phone is basically fine as long as nobody's actively hacking it remotely, that the security story here starts at the beginning and covers the whole chain end to end. It doesn't. It starts once a permission already exists and is treated as legitimate. Everything before that — the human step, the signing step, the device holding the keys — sits completely outside what gets verified. That's not a criticism of the engineering, the engineering inside its boundary is genuinely strong. It's more that the boundary is narrower than "security through verifiable automation" sounds like it's promising.
But here's the part that actually bothers me. Most real-world compromises in crypto historically haven't come from breaking cryptography, they've come from exactly this upstream layer — phished keys, compromised devices, someone approving something they shouldn't have under pressure or confusion. If that's still where the actual risk concentrates, then a system that provably secures everything after the permission exists is solving a problem that isn't usually the one that bites people. It's a bit like installing an extremely good lock on a door, while the actual break-ins mostly happen through an open window nobody's checking. I'm not saying the lock is pointless, I just don't think it changes the odds as much as the framing implies.
There's also the revocation question, which I didn't expect to care about but now can't stop thinking about — once a permission's live and an agent's mid-cycle, how fast can a user actually pull it back if something feels wrong. Haven't fully nailed down the answer there, might just be a gap in what I've read so far rather than a gap in the system itself.
Matters most, I'd guess, for anyone treating this kind of verified automation as a reason to be less careful about the upstream stuff — device hygiene, who has signing access, how permissions get reviewed before they're granted. The math doesn't really change there just because everything downstream is cryptographically airtight.
Anyway, phone's back in my pocket, nothing happened, obviously. Still checking twice before I leave it lying around though. Old habits, I guess, even when the actual risk was probably somewhere else entirely.
@NewtonProtocol #Newt $NEWT
7
56
سجّل الدخول لاستكشاف المزيد من المُحتوى
انضم إلى مُستخدمي العملات الرقمية حول العالم على Binance Square
⚡️ احصل على أحدث المعلومات المفيدة عن العملات الرقمية.
💬 موثوقة من قبل أكبر منصّة لتداول العملات الرقمية في العالم.
👍 اكتشف الرؤى الحقيقية من صنّاع المُحتوى الموثوقين.
البريد الإلكتروني / رقم الهاتف
المواضيع الرائجة
EarningsSeason
1.6M مشاهدات
7,542 يقومون بالنقاش
الجلسة 2 من موسم الأرباح: أرباح Tesla وMeta — الأنظار كلها على السبعة الرائعين
Binance Square Official
·651 إعجاب
·1.2M مشاهدات
JapanTransportMinisterToStudyStablecoinTaxRefunds
0 مشاهدات
20 يقومون بالنقاش
NEAROpensVoteToCutAnnualIssuanceTo1.6%
5,332 مشاهدات
201 يقومون بالنقاش