#shareyourvote
shareyourvote
2,411 مشاهدات
10 يقومون بالنقاش
رائج
جديد
كل خزانة في Trustless Bitcoin Vaults (TBV) تُخصص حوالي 93 دولارًا من البيتكوين كرهن تحدٍّ. معظم الناس لن يروا أبدًا أن هذه الأموال تذهب إلى أي مكان؛ فهي فقط تبقى هناك ثم تعود عندما تُغلق الخزانة.
@BabylonLabs_io $BABY
فما الفائدة من ذلك إذن.
الفكرة هي أن التحدّيات يجب أن تكلف شيئًا فعليًا لكي يعمل النظام. إذا كان الاعتراض على ادعاء مجانيًا، فيمكن للناس إرسال تحدّيات مزيفة طوال اليوم لإزعاج الآخرين. وإذا كان الكذب مجانيًا من الجهة الأخرى أيضًا، فلن يكون لدى أحد سبب للبقاء صادقًا.
الأمر يشبه تقريبًا المنطق نفسه في وديعة قابلة للاسترداد تضعها قبل استئجار معدات. نادرًا ما تخسرها، لكن مجرد حقيقة أنك قد تخسرها هو ما يحافظ على العدالة للجميع ممن لهم علاقة بالأمر.
#ShareYourVote
$KOMA $BANK
#baby
@BabylonLabs_io $BABY
فما الفائدة من ذلك إذن.
الفكرة هي أن التحدّيات يجب أن تكلف شيئًا فعليًا لكي يعمل النظام. إذا كان الاعتراض على ادعاء مجانيًا، فيمكن للناس إرسال تحدّيات مزيفة طوال اليوم لإزعاج الآخرين. وإذا كان الكذب مجانيًا من الجهة الأخرى أيضًا، فلن يكون لدى أحد سبب للبقاء صادقًا.
الأمر يشبه تقريبًا المنطق نفسه في وديعة قابلة للاسترداد تضعها قبل استئجار معدات. نادرًا ما تخسرها، لكن مجرد حقيقة أنك قد تخسرها هو ما يحافظ على العدالة للجميع ممن لهم علاقة بالأمر.
#ShareYourVote
$KOMA $BANK
#baby
Challenge bonds work
0%
Refundable security model
100%
Anti-spam mechanism
0%
Need more incentives
0%
1 الأصوات • تمّ إغلاق التصويت
لست متأكدًا تمامًا مما الذي يجب فهمه بشأن هذه الواحدة: حصلت تضخم BABY السنوي على تخفيض من 8% إلى 5.5% في نوفمبر الماضي. وفي نفس التحديث الذي أدخل نظام إتاحة/حيازة BTC BABY Staking (20,000 BABY لكل 1 BTC مقابل مكافآت إضافية). نفس الترقية شهدت تغييرين.
هل من المفترض أن يكون تخفيض التضخم مُعادلًا للطلب الجديد على BABY الناتج عن CoStaking، أم أن هذه في الحقيقة تغييرات غير مرتبطة ببعضها وقد جاءت للتو معًا؟ وهل يتصل أي من ذلك بالطريقة التي تُوجّه بها رسوم Trustless Bitcoin Vaults (TBV) في النهاية إلى حروق BABY، أم أنها مسار منفصل تمامًا؟
أحاول معرفة ما إذا كانت هناك قصة واحدة منسّقة لآليات/اقتصاديات الرموز (tokenomics) هنا، أم مجرد اقتراحين من الحوكمة حدثا بالصدفة في الوقت نفسه.
$KOMA $BANK
#ShareYourVote
@BabylonLabs_io $BABY #baby
هل من المفترض أن يكون تخفيض التضخم مُعادلًا للطلب الجديد على BABY الناتج عن CoStaking، أم أن هذه في الحقيقة تغييرات غير مرتبطة ببعضها وقد جاءت للتو معًا؟ وهل يتصل أي من ذلك بالطريقة التي تُوجّه بها رسوم Trustless Bitcoin Vaults (TBV) في النهاية إلى حروق BABY، أم أنها مسار منفصل تمامًا؟
أحاول معرفة ما إذا كانت هناك قصة واحدة منسّقة لآليات/اقتصاديات الرموز (tokenomics) هنا، أم مجرد اقتراحين من الحوكمة حدثا بالصدفة في الوقت نفسه.
$KOMA $BANK
#ShareYourVote
@BabylonLabs_io $BABY #baby
Coordinated tokenomics
0%
Two separate changes
100%
Need more context
0%
Burn link matters most
0%
1 الأصوات • تمّ إغلاق التصويت
تمّ التحقق
بحثت في النقاط الرئيسية للحصول على القائمة الكاملة للأشياء التي يُفترض أن تدعمها صناديق البيتكوين الموثوقة (TBV)، وقد توقّفني اثنتان: بطاقات الائتمان والتأمين.
إقراض الستابل كوينز، بيربس — الثلاثة جميعها تحصل على أقسام التصميم الفعلية في الورقة البيضاء. البنية/سير العمل — الفوائد — كلها موضحة بالتفصيل. تظهر بطاقات الائتمان والتأمين في القائمة ضمن التطبيقات، لكن “الضمان BTC المحلي” قد يستطيع تشغيل ذلك، ومع ذلك لا يحصل أيٌّ منهما على أي شيء قريب من ذلك في “المعالجة” في أي مكان داخل المادة التقنية.
وبالمقارنة مع حالات الاستخدام الثلاث المصممة، فهذا ليس مجرد نقص في التفاصيل. منتج بطاقة الائتمان يحتاج إلى أشياء لا تتضمنها الإقراض: الإذن الفوري، توقيت تسوية التاجر، إدارة المنازعات/رد المبالغ (chargebacks)، إلخ. ولا يظهر أي شيء من ذلك في أي قسم قرأته.
لا أقول إن الأمر لا يمكن أن يعمل في النهاية. فبداهة/العنصر الأساسي للصندوق (vault primitive) عام بما يكفي لدرجة أنه ربما يمكنه ذلك بالطريقة نفسها التي يمتد بها عبر الإقراض والستابل كوينز والبيربس بالفعل.
فقط أشير إلى أن عبارة “بطاقات الائتمان والتأمين” في الوقت الحالي تبدو أكثر كفئة تعتقدها المجموعة أنها قابلة للتحقيق، لا كمنتج لديه أي آليات منشورة تدعمه.
$BANK $KOMA
#ShareYourVote
@BabylonLabs_io $BABY #baby
إقراض الستابل كوينز، بيربس — الثلاثة جميعها تحصل على أقسام التصميم الفعلية في الورقة البيضاء. البنية/سير العمل — الفوائد — كلها موضحة بالتفصيل. تظهر بطاقات الائتمان والتأمين في القائمة ضمن التطبيقات، لكن “الضمان BTC المحلي” قد يستطيع تشغيل ذلك، ومع ذلك لا يحصل أيٌّ منهما على أي شيء قريب من ذلك في “المعالجة” في أي مكان داخل المادة التقنية.
وبالمقارنة مع حالات الاستخدام الثلاث المصممة، فهذا ليس مجرد نقص في التفاصيل. منتج بطاقة الائتمان يحتاج إلى أشياء لا تتضمنها الإقراض: الإذن الفوري، توقيت تسوية التاجر، إدارة المنازعات/رد المبالغ (chargebacks)، إلخ. ولا يظهر أي شيء من ذلك في أي قسم قرأته.
لا أقول إن الأمر لا يمكن أن يعمل في النهاية. فبداهة/العنصر الأساسي للصندوق (vault primitive) عام بما يكفي لدرجة أنه ربما يمكنه ذلك بالطريقة نفسها التي يمتد بها عبر الإقراض والستابل كوينز والبيربس بالفعل.
فقط أشير إلى أن عبارة “بطاقات الائتمان والتأمين” في الوقت الحالي تبدو أكثر كفئة تعتقدها المجموعة أنها قابلة للتحقيق، لا كمنتج لديه أي آليات منشورة تدعمه.
$BANK $KOMA
#ShareYourVote
@BabylonLabs_io $BABY #baby
Do You Agree With My Content
50%
You Don't Agree
17%
Already Know
0%
Comparison Gap-analysis
33%
6 الأصوات • تمّ إغلاق التصويت
تمّ التحقق
ورقة عمل صناديق بيتكوين اللامركزية الموثوقة (TBV) تفعل شيئًا يستحق الإشارة إليه: في القسم 5 تُدرج "المشاركة المفتوحة" كميزة معلنة، وتحدد "المصفيين" المدرجين على القائمة البيضاء كآلية فعلية في القسم نفسه.@BabylonLabs_io
الفقرة/نقطة الميزة تكون واضحة بشأن من تغطيه المشاركة المفتوحة: المصفيون والمقترضون والمطورون جميعهم مفترض أن يندمجوا في البروتوكول مع حد أدنى من الإعداد/التسجيل. بينما تدفق التصفية قبل ذلك بعدة فقرات يكون واضحًا بنفس القدر: تُنفَّذ عمليات التصفية بواسطة مصفيين مُدرجين على القائمة البيضاء — وهي مجموعة محددة بإذن مسبق وليست أي شخص يرغب في إغلاق مركزٍ غير مغطى بشكل كافٍ.$BABY
وليس القول إن إدراج المصفيين على القائمة البيضاء أمر غير معقول. فالتصفية تعني الاحتفاظ بالأموال الرأسمالية الحقيقية وتحريكها بسرعة، والتحقق من المشاركين لهذا الدور ممارسة قياسية في بروتوكولات الإقراض سواء كانت على السلسلة (onchain) أم خارجها.
لكن أيضًا ليس القول إن الادعاءين يتوافقان معًا بشكل مريح. فالميزة تذكر المصفيين كمشاركين "مفتوحين". والآلية تحظرهم. لا يمكن أن يكون الاثنان صحيحين بالكامل في الوقت نفسه: "المشاركة المفتوحة" تحمل وزنًا أكبر في تلك النقطة مما تدعمه القائمة البيضاء. #baby
قد توجد طريقة لحل هذا الخلاف إذا كانت القائمة البيضاء نفسها سهلة الانضمام — مثل مجموعات التوقيع المشترك k-of-n حيث يمكن لأي شخص الدخول، عندها يمكن أن تكون "المشاركة المفتوحة" و"المصفيون المدرجون على القائمة البيضاء" شيئًا واحدًا من زاويتين مختلفتين. لكن ورقة العمل لا تقول أبدًا كيف يحصل المصفي على إدراجه على القائمة البيضاء.
فهل يمكن لأي شخص أن يصبح مصفيًا؟ أم أن "المشاركة المفتوحة" تنتهي عند حد القائمة البيضاء؟ القسم 5 يذكر الميزة والبوابة في الصفحة نفسها، ولا يربط بين الأمرين.
$UAI $BANK
#ShareYourOpinion
#ShareYourVote
الفقرة/نقطة الميزة تكون واضحة بشأن من تغطيه المشاركة المفتوحة: المصفيون والمقترضون والمطورون جميعهم مفترض أن يندمجوا في البروتوكول مع حد أدنى من الإعداد/التسجيل. بينما تدفق التصفية قبل ذلك بعدة فقرات يكون واضحًا بنفس القدر: تُنفَّذ عمليات التصفية بواسطة مصفيين مُدرجين على القائمة البيضاء — وهي مجموعة محددة بإذن مسبق وليست أي شخص يرغب في إغلاق مركزٍ غير مغطى بشكل كافٍ.$BABY
وليس القول إن إدراج المصفيين على القائمة البيضاء أمر غير معقول. فالتصفية تعني الاحتفاظ بالأموال الرأسمالية الحقيقية وتحريكها بسرعة، والتحقق من المشاركين لهذا الدور ممارسة قياسية في بروتوكولات الإقراض سواء كانت على السلسلة (onchain) أم خارجها.
لكن أيضًا ليس القول إن الادعاءين يتوافقان معًا بشكل مريح. فالميزة تذكر المصفيين كمشاركين "مفتوحين". والآلية تحظرهم. لا يمكن أن يكون الاثنان صحيحين بالكامل في الوقت نفسه: "المشاركة المفتوحة" تحمل وزنًا أكبر في تلك النقطة مما تدعمه القائمة البيضاء. #baby
قد توجد طريقة لحل هذا الخلاف إذا كانت القائمة البيضاء نفسها سهلة الانضمام — مثل مجموعات التوقيع المشترك k-of-n حيث يمكن لأي شخص الدخول، عندها يمكن أن تكون "المشاركة المفتوحة" و"المصفيون المدرجون على القائمة البيضاء" شيئًا واحدًا من زاويتين مختلفتين. لكن ورقة العمل لا تقول أبدًا كيف يحصل المصفي على إدراجه على القائمة البيضاء.
فهل يمكن لأي شخص أن يصبح مصفيًا؟ أم أن "المشاركة المفتوحة" تنتهي عند حد القائمة البيضاء؟ القسم 5 يذكر الميزة والبوابة في الصفحة نفسها، ولا يربط بين الأمرين.
$UAI $BANK
#ShareYourOpinion
#ShareYourVote
Anyone can liquidate
60%
Whitelist is required
20%
Needs clarification
20%
5 الأصوات • تمّ إغلاق التصويت
قمتُ بتعيين برنامج البيع المُنظَّم استنادًا إلى تقرير يونيو 2025 لأنه يحتوي على مكوّنات أكثر تمييزًا مما يوحي به الحدس بأن المطلعين يبيعون وفق جدول؛ سبعة آليات منفصلة تعمل معًا.
شهادة ما قبل التبني لا يمكن اعتماد الخطة إلا عندما يكون لدى الفرد عدم امتلاك معلومات غير عامة جوهرية في تلك اللحظة.
فترة التهدئة لا يمكن بدء المبيعات فورًا بعد اعتماد الخطة؛ إذ إن التأخير الإلزامي يحد من أي ميزة معلومات متبقية. حدود تكرار البيع: لا تُسمح إلا بمبيعات دورية مُجدولة مسبقًا دون توقيت تقديري. حدود الكمية (Sale Caps): قيود محاذية للحجم على مقدار ما يمكن بيعه في كل عملية بيع مُجدولة.
قيود الأهلية: لا يَجوز إلا للرموز غير المقيّدة بالكامل والمستحقة بالكامل؛ تُستبعد الرموز المقيّدة أو غير المستحقة كليًا. متطلبات التنفيذ: يجب أن تتم المبيعات عبر طرف ثالث مستقل من خلال بورصات معتمدة أو منصات OTC غير مُدارة ذاتيًا. شرط الإيقاف: يمكن لمدير الخطة تعليق الخطط النشطة خلال أحداث بروتوكول كبرى أصوات الحوكمة ترقيات حوادث أمنية لمنع توقيت غير متوافق.
سبع ضوابط متميزة، يَغلق كلٌّ منها فجوة محتملة مختلفة.
شهادة ما قبل التبني وفترة التهدئة تعالجان عدم تماثل المعلومات وقت الالتزام. حدود تكرار البيع وحدود الكمية تعالجان التوقيت التقديري والتلاعب بالحجم.
في الواقع، أعتقد أن هذا البناء شامل فعلًا؛ إذ إنه مُنمذج بشكل صريح على خطط تداول 10b5-1 المستخدمة في امتثال تداول المطلعين في الشركات العامة التقليدية، مع تكييفه لتخصيصات الرموز. تستهدف المكوّنات السبعة طريقة محددة يمكن أن يؤدي فيها بيع المطلعين إلى خلق مزايا معلومات غير عادلة أو التأثير على السوق.
ما لم أُحسن تحليله هو ما إذا كان هذا البرنامج المُنظم قد تم استخدامه بالفعل بعدُ وما إذا كان أي من المساهمين الأساسيين أو الداعمين الأوائل أو قيادة المؤسسة قد نفّذوا مبيعات بموجب هذا البرنامج منذ بدء فترة الـ12 شهرًا؛ أو ما إذا كان البرنامج لا يزال غير مُجرَّب عمليًا، لأن الاستحقاق لم يكن قد بدأ في فكّ رموز الاستحقاق إلا مؤخرًا.
$LAB $EVAA
#ShareYourVote
@NewtonProtocol $NEWT #Newt
شهادة ما قبل التبني لا يمكن اعتماد الخطة إلا عندما يكون لدى الفرد عدم امتلاك معلومات غير عامة جوهرية في تلك اللحظة.
فترة التهدئة لا يمكن بدء المبيعات فورًا بعد اعتماد الخطة؛ إذ إن التأخير الإلزامي يحد من أي ميزة معلومات متبقية. حدود تكرار البيع: لا تُسمح إلا بمبيعات دورية مُجدولة مسبقًا دون توقيت تقديري. حدود الكمية (Sale Caps): قيود محاذية للحجم على مقدار ما يمكن بيعه في كل عملية بيع مُجدولة.
قيود الأهلية: لا يَجوز إلا للرموز غير المقيّدة بالكامل والمستحقة بالكامل؛ تُستبعد الرموز المقيّدة أو غير المستحقة كليًا. متطلبات التنفيذ: يجب أن تتم المبيعات عبر طرف ثالث مستقل من خلال بورصات معتمدة أو منصات OTC غير مُدارة ذاتيًا. شرط الإيقاف: يمكن لمدير الخطة تعليق الخطط النشطة خلال أحداث بروتوكول كبرى أصوات الحوكمة ترقيات حوادث أمنية لمنع توقيت غير متوافق.
سبع ضوابط متميزة، يَغلق كلٌّ منها فجوة محتملة مختلفة.
شهادة ما قبل التبني وفترة التهدئة تعالجان عدم تماثل المعلومات وقت الالتزام. حدود تكرار البيع وحدود الكمية تعالجان التوقيت التقديري والتلاعب بالحجم.
في الواقع، أعتقد أن هذا البناء شامل فعلًا؛ إذ إنه مُنمذج بشكل صريح على خطط تداول 10b5-1 المستخدمة في امتثال تداول المطلعين في الشركات العامة التقليدية، مع تكييفه لتخصيصات الرموز. تستهدف المكوّنات السبعة طريقة محددة يمكن أن يؤدي فيها بيع المطلعين إلى خلق مزايا معلومات غير عادلة أو التأثير على السوق.
ما لم أُحسن تحليله هو ما إذا كان هذا البرنامج المُنظم قد تم استخدامه بالفعل بعدُ وما إذا كان أي من المساهمين الأساسيين أو الداعمين الأوائل أو قيادة المؤسسة قد نفّذوا مبيعات بموجب هذا البرنامج منذ بدء فترة الـ12 شهرًا؛ أو ما إذا كان البرنامج لا يزال غير مُجرَّب عمليًا، لأن الاستحقاق لم يكن قد بدأ في فكّ رموز الاستحقاق إلا مؤخرًا.
$LAB $EVAA
#ShareYourVote
@NewtonProtocol $NEWT #Newt
DO YOU LIKE THIS
50%
I DONT LIKE THIS
50%
OR I CANT UNDERSTAND
0%
2 الأصوات • تمّ إغلاق التصويت
تمّ التحقق
NewtonPermissions هو اسم لم أكن قد رأيته من قبل هذا الأسبوع. إنه ما كان نيوتن يطلقه على السياسات القابلة لإعادة الاستخدام في تقرير الربع الثالث من عام 2025 قبل أن تستقر المصطلحات الحالية.
يتمحور الطرح حول سياسات قابلة لإعادة الاستخدام يحددها مالكو التطبيقات ويطبّقونها ويثبتونها قبل الاستقرار. وهذا هو نفس المبدأ الأساسي الذي تم تناوله بشكل واسع في التحليل السابق تحت اسم policy packs وRego policies. تغيير الاسم مع بقاء المفهوم الأساسي نفسه في مرحلة سابقة من تطور التوثيق.
يجدر التنبيه إلى ما لم يتغير إلى جانب الاسم.
إن الكيانات الثلاث الأساسية Applications وOperators وData Providers هي نفسها الثلاثة الأدوار الموجودة في التوثيق الحالي، فقط تم وصفها باختلاف بسيط. تحدد التطبيقات السياسات وتطلب تقييماتها. يقوم المشغّلون بتقييم ما إذا كانت النوايا تتوافق. ويزوّد مزوّدو البيانات بإدخالات onchain وoffchain. وقد ظل هذا الهيكل ثابتًا عبر التحول في التسمية.
لا أقول إن تغيير التسمية مهم بحد ذاته كثيرًا. تتطور المصطلحات مع تنقيح التوثيق، ومع انتقال المشروع من أسماء العمل الداخلية إلى لغة المنتج الموجّه للجمهور.
ولا أقول أيضًا إنه غير ذي صلة تمامًا. فكل من يقرأ الإفصاحات الأسبق لنيوتن إلى جانب التوثيق الحالي يحتاج إلى معرفة أن NewtonPermissions والسياسات الحالية تشير إلى الآلية نفسها، وإلا ستبدو الوثائق التاريخية كأنها تصف ميزة مختلفة وغير مرتبطة.
ما لم أعمله بعد هو متى بالضبط تحولت التسمية من NewtonPermissions إلى التسمية الحالية، وما إذا كانت هناك أي تغييرات وظيفية ترافق إعادة التسمية إلى جانب الملصق نفسه.
$EVAA $LAB
#ShareYourVote
@NewtonProtocol $NEWT #Newt
يتمحور الطرح حول سياسات قابلة لإعادة الاستخدام يحددها مالكو التطبيقات ويطبّقونها ويثبتونها قبل الاستقرار. وهذا هو نفس المبدأ الأساسي الذي تم تناوله بشكل واسع في التحليل السابق تحت اسم policy packs وRego policies. تغيير الاسم مع بقاء المفهوم الأساسي نفسه في مرحلة سابقة من تطور التوثيق.
يجدر التنبيه إلى ما لم يتغير إلى جانب الاسم.
إن الكيانات الثلاث الأساسية Applications وOperators وData Providers هي نفسها الثلاثة الأدوار الموجودة في التوثيق الحالي، فقط تم وصفها باختلاف بسيط. تحدد التطبيقات السياسات وتطلب تقييماتها. يقوم المشغّلون بتقييم ما إذا كانت النوايا تتوافق. ويزوّد مزوّدو البيانات بإدخالات onchain وoffchain. وقد ظل هذا الهيكل ثابتًا عبر التحول في التسمية.
لا أقول إن تغيير التسمية مهم بحد ذاته كثيرًا. تتطور المصطلحات مع تنقيح التوثيق، ومع انتقال المشروع من أسماء العمل الداخلية إلى لغة المنتج الموجّه للجمهور.
ولا أقول أيضًا إنه غير ذي صلة تمامًا. فكل من يقرأ الإفصاحات الأسبق لنيوتن إلى جانب التوثيق الحالي يحتاج إلى معرفة أن NewtonPermissions والسياسات الحالية تشير إلى الآلية نفسها، وإلا ستبدو الوثائق التاريخية كأنها تصف ميزة مختلفة وغير مرتبطة.
ما لم أعمله بعد هو متى بالضبط تحولت التسمية من NewtonPermissions إلى التسمية الحالية، وما إذا كانت هناك أي تغييرات وظيفية ترافق إعادة التسمية إلى جانب الملصق نفسه.
$EVAA $LAB
#ShareYourVote
@NewtonProtocol $NEWT #Newt
Just a name change
0%
Same tech, new label
100%
Rename + new features
0%
Need more evidence
0%
1 الأصوات • تمّ إغلاق التصويت
اقرأ تقارير الربع الرابع 2025 مرتين قائمة تكامل Oracle الخاصة بالتكامل مع Oracle لأن شيئًا لم يَتّضح لي في المرة الأولى. الآنيوتن لديه جهازي Oracle منفصلين مخصصين للـKYC: Persona وVeriff، وأنا أفترض أن البروتوكول كان سيستقر على واحد.
تم الإعلان عن Persona في الربع الأول 2026. يظهر Veriff في تقرير الربع الرابع 2025، ما يعني أنه يسبق فعليًا Persona بحوالي ربع سنة. هذا الترتيب مهم: Veriff ليس إضافة زائدة/مكررة بعد أن كان Persona موجودًا بالفعل. Persona جاء ثانيًا.
فلماذا الحفاظ على جهازي Oracle للتحقق من الهوية يقومان بعمل متشابه.
تؤطر الورقة نموذج Oracle الخاص بنيوتن كطبقة سياسات محايدة عبر أنظمة غير متجانسة، بدلًا من كونه تأييدًا لأي تطبيق محدد، واللغة التحذيرية نفسها التي غطّت في تحليل سابق للإطار التوضيحي بعدم التأييد.
اقرأ هذا مقابل ذلك الإطار: وجود مزوّدي KYC اثنين ليس تكرارًا؛ بل هو قابلية للاختيار. مؤلف السياسات الذي يبني حزمة امتثال يختار مزود التحقق من الهوية الذي يناسب علاقاته الحالية أو متطلبات تنظيمية لديه: Veriff لمعايير توثيق اختصاص قضائي واحد، وPersona لآخرين، أو أيهما حسب المورّد الذي لدى مؤسسة بعينها عقد معه.
في الواقع، أعتقد أن هذا يعيد صياغة ما يجب قراءة تكامل نيوتن مع إعلانات X على أنه يحدث بشكل جماعي لا بشكل فردي: النمط ليس أن نيوتن اختار أفضل مزود KYC. بل أن نيوتن يبني قائمة، ومؤلفو السياسات يختارون منها بناءً على علاقات الموردين القائمة لديهم واحتياجاتهم من ناحية الاختصاص.
ما لم أعمله بعد هو ما إذا كانت بيانات Persona وVeriff يمكن تركيبها ضمن سياسة واحدة، مع التوصل إلى اتفاق بينهما، أو قبول أيٍّ منهما، أو ما إذا كان مؤلف السياسات يجب أن يختار بالضبط Oracle واحدًا للهوية لكل سياسة ولا يمكنه الإشارة إليهما معًا في الوقت نفسه.
لماذا تعتقد أن نيوتن يدمج كلاً من Persona وVeriff؟
#ShareYourVote #VoteYourOpinion $DODO $XEC
@NewtonProtocol $NEWT #Newt
تم الإعلان عن Persona في الربع الأول 2026. يظهر Veriff في تقرير الربع الرابع 2025، ما يعني أنه يسبق فعليًا Persona بحوالي ربع سنة. هذا الترتيب مهم: Veriff ليس إضافة زائدة/مكررة بعد أن كان Persona موجودًا بالفعل. Persona جاء ثانيًا.
فلماذا الحفاظ على جهازي Oracle للتحقق من الهوية يقومان بعمل متشابه.
تؤطر الورقة نموذج Oracle الخاص بنيوتن كطبقة سياسات محايدة عبر أنظمة غير متجانسة، بدلًا من كونه تأييدًا لأي تطبيق محدد، واللغة التحذيرية نفسها التي غطّت في تحليل سابق للإطار التوضيحي بعدم التأييد.
اقرأ هذا مقابل ذلك الإطار: وجود مزوّدي KYC اثنين ليس تكرارًا؛ بل هو قابلية للاختيار. مؤلف السياسات الذي يبني حزمة امتثال يختار مزود التحقق من الهوية الذي يناسب علاقاته الحالية أو متطلبات تنظيمية لديه: Veriff لمعايير توثيق اختصاص قضائي واحد، وPersona لآخرين، أو أيهما حسب المورّد الذي لدى مؤسسة بعينها عقد معه.
في الواقع، أعتقد أن هذا يعيد صياغة ما يجب قراءة تكامل نيوتن مع إعلانات X على أنه يحدث بشكل جماعي لا بشكل فردي: النمط ليس أن نيوتن اختار أفضل مزود KYC. بل أن نيوتن يبني قائمة، ومؤلفو السياسات يختارون منها بناءً على علاقات الموردين القائمة لديهم واحتياجاتهم من ناحية الاختصاص.
ما لم أعمله بعد هو ما إذا كانت بيانات Persona وVeriff يمكن تركيبها ضمن سياسة واحدة، مع التوصل إلى اتفاق بينهما، أو قبول أيٍّ منهما، أو ما إذا كان مؤلف السياسات يجب أن يختار بالضبط Oracle واحدًا للهوية لكل سياسة ولا يمكنه الإشارة إليهما معًا في الوقت نفسه.
لماذا تعتقد أن نيوتن يدمج كلاً من Persona وVeriff؟
#ShareYourVote #VoteYourOpinion $DODO $XEC
@NewtonProtocol $NEWT #Newt
Vendor optionality
0%
Better security
100%
Regional compliance
0%
1 الأصوات • تمّ إغلاق التصويت
سجّل الدخول لاستكشاف المزيد من المُحتوى