web3空投姐

لحظة، تم توصيل Core بنجاح، فلماذا علينا الانتظار قبل مطابقة المهام العامة؟

ظننت أنني سأتمكن من انتظار المهام فور انتهاء عملية onboarding.

لكن بعد الاطلاع على Cargo الرسمي، اكتشفت أن هناك فترة warmup أيضًا.

تذكر الوثائق الرسمية حاليًا أن Core الجديد يمر بفترة warmup تصل إلى 3 epochs، أي نحو 4.5 ساعات.

ولا يصبح مؤهلًا لمطابقة المهام العامة إلا بعد اجتياز هذه المرحلة.

انتبهوا، المقصود أنه يصبح مؤهلًا للمشاركة في المطابقة، وليس أن المهام ستتوفر له حتمًا فور انتهاء المدة.

لكن، من ناحية أخرى، ليس صحيحًا أنه لا يمكن تنفيذ أي مهام خلال فترة الانتظار.

إذ تتيح Acurast أيضًا ميزة Instant Deploy ‏(instantMatch)، التي تسمح للمطورين بتحديد Processor بعينه لنشر المهام عليه، متجاوزين انتظار المطابقة العامة.

ينبغي النظر إلى هذين المسارين كلٌّ على حدة.

وبالمناسبة، يمكن للهاتف أن يوفّر قدرة حوسبة لشبكة Acurast، وأن يشارك في حوافز $ACU وفقًا لقواعد البروتوكول.

لكن، بحسب ما يبدو حتى الآن، لا ينبغي الخلط بين نجاح الاتصال، واكتساب أهلية المطابقة، واستلام مهمة فعليًا، واستيفاء شروط المكافآت.

لذلك، إذا كنت تخطط للمشاركة بهاتف غير مستخدم، فتحقق أولًا من وقت الاتصال وقواعد warmup الرسمية.

لا تفترض أنك ستحصل على مهمة عامة فور إتمام الاتصال!

@Acurast

الوثائق الرسمية: https://docs.acurast.com/developers/getting-started/quickstart-cargo/

بوابة المشاركة للأفراد: https://hub.acurast.com/rebellion?ref=ikgnqo

#Acurast #ACU #DePIN #手机算力

مساء الخير يا أخوات!\n\nهل أصبحت الهواتف قوية إلى هذا الحد؟ حتى إنها تشغّل وكلاء الذكاء الاصطناعي! فهل يعني ذلك أن النماذج اللغوية الكبيرة أصبحت تُثبّت على الهواتف أيضًا؟ 😂\n\nعندما رأيت مثال Hermes من @Acurast، أردت فعلًا أن أفهم المسألة. وبعد الاطلاع على الوثائق الرسمية، عرفت أنهما يعملان بشكل منفصل.\n\nيوفّر معالج الهاتف في Acurast بيئة التشغيل عبر Cargo، بينما يتولى Hermes تنفيذ مهام الوكيل وسير العمل. وعند الحاجة إلى استدعاء نموذج لغوي كبير، يتم ذلك عبر OpenRouter للاستعانة بخدمات نماذج خارجية. بل إن الوثائق الرسمية تشترط إعداد OPENROUTER_API_KEY.\n\nآه، الآن اتضحت الصورة.\n\nصحيح أن الهاتف يتولى تشغيل وكيل الذكاء الاصطناعي فعليًا، لكن في مثال Hermes الرسمي هذا على الأقل، يجري استدعاء النموذج عبر OpenRouter. لذا لا ينبغي فهم الأمر على أن أوزان النموذج اللغوي الكبير مثبّتة على هذا الهاتف أيضًا. في المرة القادمة التي ترون فيها هاتفًا يشغّل الذكاء الاصطناعي، فكروا: هل الذي يعمل هو الوكيل، أم أن النموذج نفسه يعمل محليًا؟\n\n#Acurast hub.acurast.com/rebellion?ref=ikgnqo

مساء الخير يا أخوات!

هل يمكنني توصيل هاتف غير مستخدم بشبكة @Acurast، ثم قفله ووضعه جانبًا ليواصل توفير القدرة الحاسوبية؟ لحظة، لا يمكننا افتراض ذلك ببساطة.

اطلعتُ بعناية على ملاحظات الإصدار الرسمي Processor 1.26.0، واكتشفت أن نسختَي Lite وCore على Android كانتا تعملان وفق قواعد التشغيل في الواجهة الأمامية. فلا يستطيع التطبيق توفير القدرة الحاسوبية باستمرار إلا وهو في الواجهة الأمامية؛ وبمجرد الانتقال إلى الخلفية أو إطفاء الشاشة، يتوقف عن إرسال نبضات الحياة وعن معالجة توزيع المهام. اتضح أن خطوة بسيطة مثل قفل الشاشة قد تؤثر في عمل الهاتف.

صحيح أن Acurast تتيح للهاتف المشاركة في شبكة الحوسبة والحصول على مكافآت $ACU وفقًا لقواعد البروتوكول، بما فيها مكافآت Benchmark الأساسية، ومكافآت Staked Compute المحتملة عند المشاركة في تخزين القدرة الحاسوبية. لكن نجاح تسجيل الهاتف لا يعني استيفاءه شروط التشغيل طوال الوقت، ولا يصح افتراض أن تركه مقفلًا سيحقق عائدًا.

مع ذلك، هذه هي القواعد الموضحة في إصدار Android Processor 1.26.0. وقد عالج الإصدار 1.27.2 بعض مشكلات نبضات الحياة أثناء تنفيذ المهام. ووفقًا للتحقق من أحدث إصدار، وصل الإصدار الرسمي إلى 1.28.0، لكن ملاحظات التحديث لم توضح صراحةً إلغاء شرط التشغيل في الواجهة الأمامية. كما أنني لم أختبر قفل الشاشة على الإصدار الحالي، لذلك لا أستطيع الجزم بأن الأمر ينطبق على جميع الهواتف.

إذا كنتم تنوون استخدام هاتف غير مستعمل للمشاركة، فمن الأفضل التحقق أولًا من الإصدار المثبّت لديكم ومن أحدث متطلبات التشغيل، ثم تقرير كيفية وضع الهاتف. احسبوا المكافآت، لكن احسبوا أيضًا استهلاك الهاتف، فلا ينتهي الأمر بإتلاف البطارية.

#Acurast ملاحظات الإصدار الرسمي:

https://github.com/Acurast/acurast-processor-update/releases/tag/processor-1.26.0

https://github.com/Acurast/acurast-processor-update/releases/tag/processor-1.28.0

https://hub.acurast.com/rebellion?ref=ikgnqo

مساء الخير يا أخواتي!

كنت أظن أن محفظة Canary واحدة تتحكم في 5 أجهزة Processor، وأنني إذا أردت نقل جهازين إلى محفظة أخرى فسيكون الأمر شبيهًا بتحويل الرموز: أختار الجهازين وأنقلهما. لكن بعد أن دققت في @Acurast، اكتشفت أن الأمر لا يسير هكذا إطلاقًا 😅

نقل ملكية أجهزة Processor في Canary يتم على مستوى الحساب بأكمله.

عند النقل، تنتقل جميع أجهزة Processor المسجلة باسم الحساب معًا، ولا يمكن اختيار جهاز أو جهازين لنقلهما بشكل منفصل. كما لا يمكن للمستلم استخدام محفظة موجودة مسبقًا؛ إذ تشترط المنصة الرسمية أن يكون حساب Canary جديدًا تمامًا — لم يُستخدم من قبل، ورصيده صفر، ولا يملك أي أجهزة Processor أو رموزًا.

والأمر الأكثر تعقيدًا أن أجهزة Processor وcACU لا تُنقل بالطريقة نفسها إطلاقًا. يمكن تحويل cACU داخل سلسلة Canary بحسب الكمية، لكن لا يمكن تقسيم صلاحية إدارة أجهزة Processor كيفما نشاء، مثل تقسيم 5 أجهزة إلى 2 و3. فالأجهزة منفردة، لكن وفق هذه القواعد، يجب أن تنتقل مع الحساب بأكمله.

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

إذا احتجتم مستقبلًا إلى نقل أجهزة متعددة إلى محفظة إدارية أخرى، فلا تتسرعوا في الضغط على زر النقل. على الأقل وفق قواعد Canary، تحقّقوا أولًا مما إذا كان النقل سيشمل الدفعة كاملة، وما إذا كان الحساب المستلم يستوفي الشروط، وما إذا كان هناك رهن لا يزال ساريًا. فهم هذه الأمور مسبقًا يوفّر عليكم الكثير من العناء.

@Acurast #Acurast #Canary提交莱特币ETF申请

https://hub.acurast.com/rebellion?ref=ikgnqo

مساء الخير يا أخوات!

إذا اكتشفتِ يومًا في الـHub أن حالة جهازك الحقيقي تحولت فجأة إلى Revoked، فغالبًا ستكون أول ردة فعل لديكِ نوعًا من الارتباك😂

مع أنك لم تعبثي بأي شيء، لماذا تم سحب اعتماد الجهاز أصلًا؟

بعد الاطلاع على أحدث توضيحات @Acurast الرسمية، اتضح أن كثيرين فهموا هذه النقطة بشكل خاطئ. Revoked لا يعني أن الجهاز مزيف، ولا يمكن الحكم مباشرة بأن المستخدم قام بالغش.

وقد أوضحت الجهة الرسمية تحديدًا السبب الجوهري الذي يجعل بعض المستخدمين النظيفين يتضررون دون ذنب: بعض الأجهزة القديمة تشترك مع نفس الدفعة ونفس الطراز في مفتاح factory attestation. وإذا تسرّب المفتاح، أو ظهرت ثغرة أمنية في ذلك الطراز، فقد تقوم Google بسحب هذا المفتاح، وعندها تتأثر جميع الأجهزة الحقيقية السليمة التي تستخدمه بشكل غير مباشر.

عند مواجهة هذا الوضع، يمكنكِ تجربة الحل القياسي الذي أوصت به الجهة الرسمية: مسح بيانات الجهاز، التحديث إلى أحدث نظام رسمي من الشركة المصنعة، التأكد من أن الجهاز غير مروّت وأن محمّل الإقلاع bootloader ما يزال مقفولًا، ثم إعادة onboard والمحاولة من جديد.

لكن هناك نقطة مهمة جدًا: هذه العملية ليست حلًا سحريًا، ولا تضمن الإصلاح بنسبة 100%.

كما ذكرت الجهة الرسمية أن نتيجة الإصلاح غير مؤكدة؛ فقد تنجح، وقد يكون جهازكِ ضمن دفعة المفاتيح التي تم سحبها بالفعل. وفي هذه الحالة، حتى #Acurast لا يمكنها تجاوز هذا القيد المفروض بسبب السحب.

لذلك، عندما ترين Revoked لا داعي للقلق، ولا تتسرعي في وصف نفسكِ بالجهاز المزيف أو بالغش. ابدئي أولًا بالفحص الذاتي وفق خطوات الجهة الرسمية، وإذا كان مفتاح الجهاز نفسه قد تم سحبه بالفعل، فالتكرار لن يحل المشكلة.

https://hub.acurast.com/rebellion?ref=ikgnqo

يا بنات، بصراحة ما أصدق قد إيش كنت غبية 🥲

كنت أستخدم @Acurast Processor، وكل ما يظهر على هاتفي أن الاتصال ناجح، أظن أنه سيظل متصلاً ويعمل على تنفيذ المهام باستقرار.

لكن بعد قراءة الموقع الرسمي، فهمت أخيراً أن نجاح الاتصال يعني فقط أن الجهاز اتصل بالخدمة. يرسل الجهاز نبضة اتصال تقريباً كل 30 دقيقة، ويشترط الموقع الرسمي بوضوح إبقاء الاتصال بالإنترنت مستقراً، وتشغيل تطبيق Processor باستمرار، حتى يتمكن من استقبال عمليات Deployment وتنفيذها بشكل طبيعي.

يقع كثير من المبتدئين في هذا الالتباس، وتحديداً عند النظر إلى الحقلين الموجودين في Hub → Phones. يشير Last seen إلى وقت رصد آخر نبضة اتصال، بينما يشير Status إلى عدد عمليات Deployment الجاري تشغيلها حالياً.

الأول يوضح ما إذا كان الجهاز قد أرسل إشارة خلال الفترة الأخيرة، والثاني يوضح ما إذا كانت هناك مهام قيد التشغيل الآن؛ وهذان أمران مختلفان تماماً.

#Acurast، يبدو أنني تعلمت درساً عملياً هذه المرة بعد الوقوع في هذا الخطأ. نجاح الاتصال، ووجود نبضة اتصال حديثة، وتشغيل Deployment هي ثلاث حالات مستقلة تماماً، فلا تخلطوا بينها أبداً.

https://hub.acurast.com/rebellion?ref=ikgnqo

يا أخواتي، مساء الخير!

رأيت دعم #Acurast Deploy Agent لـ Base USDC، ومذكور أنه "لا يلزم حساب ACU". صدمت لحظيًا… لحظة، هل يمكن نشره مباشرةً باستخدام USDC؟ وهل لا نحتاج ACU؟

بعد قراءة المستندات فهمت الأمر.

@Acurast أصلًا لدى Acurast طرق نشر متعددة: ما زالت CLI وSDK تمر عبر ACU، بينما Deploy Agent فتح مسارًا مستقلًا خاصًا برقم x402 / USDC، وهو عبارة عن بوابة دخول مستقلة بالكامل.

في السابق كنت أخلط بين شيئين معًا. دفع رسوم النشر وما وظيفة ACU داخل الشبكة ليسا الشيء نفسه إطلاقًا. جميع سيناريوهات ACU الحالية محفوظة بالكامل: لا تزال رسوم النشر، ورسوم المعاملات الشبكية، ومختلف المكافآت، ومكافآت الـ collator موجودة. لذلك هذا المدخل لا يتطلب حساب ACU، لكنه لا يعني أن ACU قد انتهت.

أما بخصوص التسوية على المستوى الأساسي بعد الدفع بـ USDC، وهل سيتم التحويل تلقائيًا أم لا، وكيفية احتساب تكاليف القدرة الحاسوبية… حتى الآن لم تُقدِّم الجهة الرسمية شرحًا كاملًا.

لن نخمن عشوائيًا؛ منطق الطبقة الأساسية سيظل ينتظر إفصاحات الجهة الرسمية اللاحقة.

https://hub.acurast.com/rebellion?ref=ikgnqo

刚看到Acurast 10亿+链上交易数据时，我去，这么牛哇，已经跑了十亿次任务了？

但仔细看了官网和文档才发现，我理解错咯。官网把 Compute Deployments和On-chain Transactions分开列出来，这两个数字本来就不是一回事。

这些链上交易里，也会包含Processor心跳、部署确认、执行上报这些常规操作。目前公开资料里，我也没看到这10亿+交易的具体构成，心跳占多少、付费部署相关交易占多少都不清楚，所以确实不能直接画等号。

也算踩了个小坑长记性了，以后再看到Web3这种特别大的数字，我应该都会先多问问它到底统计的是啥子？不然数字没看错，意思先看错了。

今天也是我第一次参与，就拿手里的闲置手机接进去试试，先边跑边看。

https://hub.acurast.com/rebellion?ref=ikgnqo

@Acurast

مرحبًا مساءً يا أخواتي!

للتو شاهدتُ القواعد الكاملة لفعالية Aster USD1 RWA، وبصراحة لا تكتفين بالنظر فقط إلى أرقام حجم الجائزة.

في المرحلة الأولى يتم احتساب مجموعتين من البرك (المسابح) بشكل منفصل: 125M $WLFI تُحسب بناءً على OI المؤهَّل، و6.25M $USD1 تُحسب بناءً على حجم التداول المؤهَّل؛ وبالنسبة للصفقات التي تحقق الشروط، ستكون هناك استفادة مزدوجة.

الفارق الحقيقي في سحب/توزيع المكافآت يعتمد على طريقة الرهن (الضمان). في عقود RWA الدائمة مثل SPCXUSD1 وCLUSD1 وXAUUSD1، إذا تم استخدام USD1 كرهن، فإن وزن مكافآت OI يتضاعف مباشرةً بمقدار 2.

أما وضع تعدد الأصول، فانتبهن إلى اللقطات (الـ snapshots): يتم النظر إلى متوسط حصة USD1 من الأصول المرهونة خلال فترة زمنية، فإذا تجاوز 50% فلا بأس. لا تظنين أن الأمور “مضمونة” لمجرد فتح صفقات لتجميع العدد المطلوب.

في الواقع، منطق هذه القواعد ممتاز: حوض USD1 يجذب حجم التداول، وحوض WLFI يحافظ على المراكز (open positions)، ووزن 2× هو ما يوجّه الجميع إلى تحويل الهامش إلى USD1.

باختصار، الهدف أن يبقى USD1 داخل حسابات العقود الدائمة ليتم تدويره واستخدامه بشكل مستمر، وليس مجرد إجراء شكلي لسحب الأموال عند اكتمال التداول.

وبالمناسبة، لا تتعجلن فتح صفقات بعد—فالفعالية مستمرة حتى 31 ديسمبر، لكن وقت احتساب الجوائز الرسمي لم يُعلن بعد. وتفاصيل مثل وتيرة اللقطات، وطريقة احتساب الحصص، وموعد توزيع المكافآت، لم تُكشف بالكامل بعد.

الآن أهم شيء هو تثبيت السوق والخيار الخاص بطريقة الرهن التي تنوين تنفيذها. انتظرن حتى تصبح القواعد واضحة تمامًا ثم ادخلن، فلن تهرب المكافآت—لكن لا تدفعن مراكزكن إلى الأمام دون حساب، ولا تسابقن الحظ.

بناتِي، عيد الحب السابع سعيد 🌹

اليوم شفت برنامج دعم/تعويض رسوم التمويل الخاص بـ M، في الدورة رقم #USD1 —بحد أقصى 1000 دولار أمريكي يوميًا. يوجد أيضًا نشاطات كثيرة ضمن منظومة البورصة/المنصة، وبالتوازي بنانس (Binance) يشارك أيضًا.

من 15 أغسطس إلى 13 سبتمبر، إجمالي جائزة قدره 100,000 دولار أمريكي 1. قواعد النشاط: سيتم رد 50% من رسوم التمويل التي تدفعينها فعليًا. كل شخص يمكنه الحصول على حد أقصى 1000 دولار أمريكي يوميًا. يتم التسوية مرة واحدة أسبوعيًا. و1000 هو السقف (حد أقصى) وليس ضمانًا.

يُحسب فقط USD1-M Futures. تذكري استخدام USD1 كـ هامش/ضمان. الرسوم التمويلية التي تحصلين عليها لا تُحسب، وعمليات التحوط للمراكز أيضًا لا تُحسب. كما أن عدة UID سيتم تجميعها للحساب.

وهناك كذلك قاعدة: أول من يشارك هو الأحق. يتوقف النشاط عند نفاد الجائزة أو عند انتهاء مدة النشاط—أيّهما يحدث أولًا. والآن لم يتم نشر رصيد/مقدار المتبقي لحظيًا. إذا كنتِ مهتمة، يمكنك المشاركة.

إذا كنتِ أصلًا تقومين بتشغيل عقد USD1-M، فهذه الفعالية “مجدية” جدًا: كأن المنصة تساعدك في تحمل نصف تكلفة رسوم التمويل التي كنتِ ستدفعينها أصلًا. لكن إذا كنتِ عادةً لا تقومين بعقود إطلاقًا، فلا تفتحي مركزًا مؤقتًا فقط كي ترجعي 50%. الدعم هدفه خفض تكلفتك الحالية، وليس إعطاؤك سببًا لصناعة تداول. لا تُضيّعي الفرصة لتوفير النصف ثم تُنشئي لنفسك تكلفة كاملة من البداية.

مرحبًا يا بنات!

لما رأيت كلمات "مصرف التناوب الوطني"، كدت أظن أيضًا أن USD1 ربما سيُحوَّل إلى ودائع بنكية.

ثم راجعت ملف OCC بعناية، واتضح لي أن أكثر شيء يمكن أن يُساء تفسيره في هذه المرة هو تحديدًا كلمتا "بنك".

في 14 أغسطس، منحت OCC الموافقة المبدئية المشروطة لـ World Liberty Trust Company, N.A.. هذا التطور مهم طبعًا، لكنه لا يزال بعيدًا عن موعد الافتتاح الرسمي؛ فهناك شروط قبل التشغيل مثل الحد الأدنى لرأس مال من الفئة الأولى بقيمة 20 مليون دولار، وإدراج التدقيق الداخلي ضمن المتطلبات قبل الافتتاح، وأخيرًا يتعين انتظار موافقة OCC النهائية.

أما بالنسبة لحاملي USD1 العاديين، فالأمر الأكثر واقعية الآن هو أن شيئًا لم يتغير.

ما زال USD1 يصدر ويُحفظ حاليًا بواسطة BitGo. أما World Liberty Trust Company فستنتظر حتى الافتتاح الرسمي، ثم تخطط لتولي إصدار USD1 والاسترداد وإدارة الاحتياطيات.

يمكنكم الاحتفال بهذه الخطوة، لكن الموافقة المبدئية لا تعني أن الافتتاح تم فعلًا، وUSD1 أيضًا ليس وديعة محمية من FDIC. ما حصلت عليه هذه المرة هو مسار رقابي اتحادي أكثر وضوحًا، وليس تأمينًا يغطي مشكلة في وديعة بنكية مع وجود من يتكفّل.

بالعكس، أرى أن هذا هو بالضبط الجزء الذي تستحق الرسالة الانتباه إليه.

ما تقوم به WLFI الآن ليس مجرد تغيير مفاجئ لهوية USD1 لتصبح أكثر بريقًا، بل نقل جوانب مثل الإصدار والحفظ والاسترداد—وهي أساس هذه المنظومة—خطوة بخطوة إلى إطار رقابي أوضح.

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

الخطوة التالية: انتظروا متى ستمنح OCC الموافقة النهائية، ووقت بدء التسليم الرسمي من BitGo إلى World Liberty Trust Company. وعندما يتحقق هذان الأمران فعليًا، سيمكن عندها معرفة أي "باب" قطعه USD1 بالفعل.

@worldlibertyfi #USDT #WLFI

مرحبًا مساءً يا أخواتي!

كنت للتو قد رأيت أن هيئة الرقابة OCC منحت بالأمس شركة World Liberty Trust Company موافقة مبدئية مشروطة، وبعدها مباشرة ذهبت لقراءة تفاصيل المستند.

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

وبالنسبة لنا كمُلاك عاديين بقيمة USD1، الأكثر واقعية الآن هو: من سيُشرف على الإصدار والحفظ. في مستندات OCC مكتوب بوضوح أن BitGo Bank & Trust لا يزال هو الجهة الوحيدة المصدِرة والجهة المكلفة بالحفظ. أما World Liberty فيجب عليها الانتظار حتى بعد بدء التشغيل الفعلي لتتولى الإصدار والاسترداد وإدارة الاحتياطيات.

لذلك فإن مسار استرداد المدفوعات الذي يسلكه المستخدمون حاليًا لن يتغير فورًا بسبب هذه الموافقة المبدئية وحدها. كذلك قال Zach Witkoff بنفسه إن هذا مجرد معلم في عملية متعددة الخطوات، كما طلبت OCC توفر رأسمال من المستوى الأول لا يقل عن 20 مليون دولار. العتبة موجودة هناك.

الاتجاه صحيح: نمرّ من كل بوابة رقابية خطوة بخطوة، لكن ما زال ليس وقت الاحتفال المسبق. القادم هو انتظار موعد صدور الموافقة النهائية، ومتى سيتم الإعلان رسميًا عن ترتيبات الانتقال بين BitGo وWorld Liberty. عند تحقق هاتين النقطتين فعليًا، عندها فقط يمكن الحديث عن معنى ذلك بالنسبة للحاملين، وسيكون الأمر أكثر اطمئنانًا.

@worldlibertyfi #USD1 #WLFI

1.7 مليار قطعة $WLFI ، لا يعني ذلك أن ما في حسابك من $USD1 سيمكنك من الحصول على مكافآت بقدر ما لديك من رصيد.

وفقًا لإعلان بينانس بتاريخ 7 أغسطس، تستمر هذه الدورة حتى 4 سبتمبر الساعة 00:00 (UTC). والأشياء الثلاثة التي من السهل على الجميع حسابها بشكل خاطئ هي:

1、يتم أخذ الحد الأدنى من رصيد USD1 المؤهل يوميًا من لقطة الساعات لتلك اليوم، وليس من الذروة؛

2、ليس صحيحًا أن مضاعف 1.2 يعني امتلاك 300 USD1 فقط، بل المقصود هو أن يكون الحد الأدنى للـ OI اليومي في زوج تداول عقود USD1 هو ≥ 300 USD1، وإذا لم يتحقق ذلك في ذلك اليوم يتم احتساب القيمة على أساس 1x؛

3、لا تُحسب التزامات USD1 التي تم اقتراضها مباشرة، بينما يُطبق على الجزء الرافعي الذي يتم الحصول عليه عبر اقتراض عملات مستقرة أخرى ثم تحويلها إلى USD1 خصم haircut بنسبة 70%.

أما بالنسبة لـ APR، فلا تعتمد على بيانات الفترة السابقة لحساب طريقة اللعب في هذه الدورة. حتى الآن، ما زالت الجهة الرسمية تعرض أن Base APR و1.2x Boosted APR وقيمة WLFI Token الخاصة بالفترة الأولى من 7 إلى 14 أغسطس سيتم تحديثها في 14 أغسطس. يكفي قبل المشاركة التأكد من نوع حسابك والحد الأدنى اليومي للرصد والحد الأدنى للـ OI ومصدر التمويل.

هذا مجرد جزء من قواعد التوزيع المرحلي لمرحلة USD1 الخاصة بهذه الدورة من بينانس، وليس عائدًا أصليًا ثابتًا لـ USD1. ويُعتمد في النهاية على توفر الأهلية حسب المنطقة وفقًا لسجلات المنصة والإعلان الأحدث.

. @flagshiptcg لن تفتح الفعالية أبوابها رسميًا إلا في 5 سبتمبر، بينما قامت @renaissxyz مسبقًا بشيءٍ ممتع للغاية. فـ Early Supporter لا يهتم بالحساب فقط، بل يجب أيضًا مطابقة حساب X نفسه مع محفظة Renaiss.

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

ثم يأتي بعد ذلك لقطة الثامن من أغسطس في تمام 22:30 (UTC+8). بهذا الشكل يصبح كل شيء منطقيًا: ما الذي فعلته في X تُسجّله السجلات، بينما تقوم المحفظة بتثبيت هذه الواقعة على عنوان محدّد بعينه، واللقطة تجعل الحالة في ذلك الوقت ثابتة. عندما نضع الخطوات الثلاث معًا، صراحةً أشعر أن الأمر أكثر جدارة بالانتباه من الـ SBT نفسها.

كانت Renaiss تستخدم دائمًا X Linker، وهذه المرة تواصل FLAGSHIP اعتماد منطق مماثل، ما يعني أن الأمر ليس مجرد إضافة عتبة بشكل مؤقت. يبدو الأمر أقرب إلى ربط هوية الأشخاص داخل المجتمع—ومستقبلًا هوية المحفظة التي تمتلك الأصول فعليًا—بنفس الإحداثية تدريجيًا. كما أن الهوية على السلسلة لا يلزم بالضرورة أن تبدأ منذ أول مرة شراء بطاقة أو شحن أو إجراء معاملة؛ فمجرد سلوك مجتمعي حقيقي يمكن ربطه بشكل واضح بمحفظة معيّنة يمكن أن يصبح جزءًا من السجل لهذا العنوان.

وبالطبع، ما زال هناك بعض التفاصيل التي لم يذكرها الفريق رسميًا بعد، مثل كيفية تأكيد حالة الربط تحديدًا، ومتى يتم إصدار الـ SBT، وما إذا كان إلغاء المتابعة أو تغيير المحفظة بعد اللقطة سيؤثر على الأهلية؛ لذا لن أستبق النتائج الآن ولا أستنتج قبل الأوان. قبل اللقطة، سأكتفي بالتأكد أولًا مما إذا كان حساب X الذي يَتصل حاليًا بمحفظة Renaiss هو نفسه الحساب الذي أتابعه، وهو @flagshiptcg.

في هذه الجولة، ما جعلني أتعرف على Early Supporter عبر SBT حقًا، ليس ما الذي يمكن الحصول عليه عبر المتابعة المبكرة، بل حقيقة أن Renaiss تحاول تحويل سلوك اجتماعي خفيف—إلى سجل له انتماء إلى محفظة وزاوية زمنية واضحة. التأكد أولًا من أنه يخص من، ثم تركه هناك—هذا الأسلوب أعجبني كثيرًا.

Vault明明有Earnings，为什么我去HertzFlow @Hertzflow_xyz 的Trade页看Claim，却找不到同一笔钱？

我对着Beginner’s Guide #2 看了一遍，才发现这里不是收益没到账，却是我们很容易一开始就看错地方。官方甚至专门把Confusing yield with Claim列成了新手常见误区。

存进Pool，拿到的是HzLP；存进Vault，拿到的是HzV。LP 这边的价值变化，通常会直接反映在share value里。费用和净交易者PnL会影响AUM，所以哪怕你手里的份额数量没变，对应价值也会跟着动，当然也可能往下走。

Trade页的Claim则是另一套逻辑。它对应的是可以直接进入余额、等待领取的项目，具体来源还是要看当前页面Earnings和Claim看起来都像收益，其实记在两本不同的账里。

有些价值，已经写进你手里的份额。
有些余额，才需要你去Claim。

我盯着Claim这个词看了几秒，反而觉得这里最容易让普通用户误会。真希望HertzFlow以后能把Share Value和 Claimable Balance分开摆，再各补一句这笔价值从哪里来。这样不用翻文档，也不会因为Claim里没数字，就误以为LP没有变化。

所以以后看Pool或Vault，我会先看share value；看到 Claim，再确认它到底对应哪类余额，当前仍是测试网机制，主网上线后，以正式页面和官方规则为准。

لقد لاحظت مؤخرًا أن الجميع يتابع منافسة <at>velvet_capital</at> للـ Perps، 75 مليون Gems، وتنتهي في 9 أغسطس.

ما إن ترتفع الحِدّة والضجة، اعتاد الناس أن يبحثوا أولًا عن الـ Token، ثم يفكرون في كيفية تنفيذ ذلك بأنفسهم.

لكن بعد أن درست هيكل منتجات Velvet عدة مرات، تبيّن لي أن السؤال الأول لا ينبغي أن يكون «أيّ Token يجب شراؤه»، بل «ما الذي تنوي فعلَـه بهذا المبلغ الآن».

إن كنت تريد امتلاك أصلٍ ما مباشرةً، فهذا يقابل Spot. وإن كنت تريد التعبير عن اتجاهٍ لفترة زمنية، فهذا يقابل Perps؛ ستحصل على تعرّض (exposure) وليس على أصلٍ فوري. وإن كنت تريد وضع الأصل ضمن استراتيجية عائد، فهنا يأتي دور Yield، كما يجب أن نعرف من أين يأتي العائد، ومتى يمكن الخروج، وما المخاطر التي يتحملها الأساس.

عندما رأيت أن My Positions يعرض في الوقت نفسه tokens وperpetual positions وDeFi positions، فكّرت في الأمر. لقد لم تعد Velvet مجرد تجميع لكومة من الـ Token؛ فهي تُجمّع حالات مختلفة محتملة لنفس قطعة رأس المال داخل منتج واحد ليطلع عليها المستخدم.

هذه الفكرة أهم بكثير من كثرة الوظائف. فالمجمّعات العادية تحل مشكلة «إلى أين تذهب للشراء»، بينما تتقدم Velvet خطوة إلى الأمام: تجعل المستخدم يبدأ بالتفكير أولًا في ماهية دور هذا المبلغ—هل سيحتفظ به، أم سيُستخدم للتعبير عن الاتجاه، أم سيُدخل في استراتيجية.

وبالطبع، فإن توحيد Portfolio لا يعني أن الأموال تُستخدم بشكل مشترك بالكامل. ما يزال لـ Perps «مدخراته» ومسار التنفيذ الخاص به، كما أن العوائد اللحظية لـ Yield والرسوم وشروط الخروج يجب أن تُعاد مواءمتها وتأكيدها ضمن المنتج.

في كثير من الأحيان، الخطأ الأكثر شيوعًا الذي يُمكن أن يقع فيه شخصٌ ما ليس أنه لم يَلْحَق بالـ Token الرائج، بل أنه لم يُفكر أصلًا في ماذا يريد أن يفعل به. لذلك، في المرة القادمة عندما أفتح هذا النوع من «محطة طرفية كاملة» (full-stack terminal)، سأبدأ بسؤال: ما الدور الذي يجب أن تؤديه هذه الأموال اليوم؟ إذا لم تكن الإجابة محددة بعد، فلا تتعجل في البحث عن Token.

ريـنايس @renaissxyz 刚预告第三轮社区大使选举、中国、台湾、越南都会参与，而且每两个月轮换一次。

عندما رأيت هذه الرسالة، لم يخطر في بالي أولاً من سيفوز، بل المشكلة التي لم تُحسم بعد من الدورة السابقة: هل ستتغيّر معها أيضاً؟

بالنسبة للمستخدمين العاديين، فإن ما يسبب المتاعب غالباً ليس الأمور الكبيرة، بل قد يكون مجرد أن الشرح باللغة الصينية غير مفهوم، أو أن مواعيد الفعالية لا تنطبق، أو أن مسألة الحفظ/السحب لا يعرف المرء من يجب أن يسأل عنها.

كون أحد السفراء ردّ مرة واحدة داخل المجموعة لا يعني بالضرورة أن المشكلة تم حلها فعلاً. إذا لم تكن هناك سجلات، ولا حالة واضحة، ولا تسليم رسمي، فقد يضطر المستخدمون عند تبدّل الشخص إلى شرح الأمر من جديد.

التعريف الرسمي المبكر لـ Community Supporter كان أصلاً يشمل الإجابة عن أسئلة الأعضاء ومساعدة الوافدين الجدد على الاندماج، ولهذا السبب أرى أن هذه الآلية هي أكثر شيء مفيد.

أنا أميل إلى فهم «السفير المجتمعي» كأنه لوحة وصل (سنترال) لمشكلات منطقة معيّنة. تجمع صياغات اللغة والسيناريوهات والاحتكاكات الواقعية لدى المستخدمين المحليين للبرنامج، ثم تنقل ردّ المشروع إلى المجتمع. يمكن للناس أن يتناوبوا، لكن لا ينبغي للمشكلات أن تُمحى أو «تعود للصفر» مع كل دورة.

حالياً، لم تكشف الجهة الرسمية بعد عن مدخلات ثابتة للتغذية الراجعة، أو عن طريقة لمعرفة التقدم في المعالجة، أو عن آلية تسليم رسمية. لذا لا يمكن اعتبار هذه الأمور كآليات قائمة بعد. بعد صدور قواعد الترشيح، سأراجع أولاً: من أين تُقدَّم المشكلة؟ وهل يمكن تتبّع التقدم؟ وهل توجد قائمة بالمهام غير المنتهية عند تبدّل الدورة.

إن آلية سفراء جيدة، في النهاية، لا ينبغي ألا تترك وراءها سوى اسم جديد. يجب أيضاً أن تبقى تلك المشكلات التي تم سماعها بالفعل، والتي ما تزال قيد المعالجة، أو التي يوجد من يتابعها لاحقاً.

كنت قد قمتُ سابقًا بربط Referral Code بشكل عابر، فهل ما زال بإمكاني تغييره؟

يقول HertzFlow @Hertzflow_xyz بشكل مباشر في دليل المبتدئين #3 الأحدث: نعم يمكنك. وفقًا لقواعد شبكة الاختبار الحالية، حتى الأكواد التي تم ربطها بالفعل يمكن تغييرها لاحقًا، ولا توجد قيود على عدد المرات.

عند الاتصال الأول تخطي نافذة منبثقة لا يعني أن الفرصة لن تكون متاحة لاحقًا. بعد ذلك، ما زلت تستطيع الذهاب إلى صفحة الـReferral وربط كود يدويًا؛ وحتى الأكواد التي تم ربطها مسبقًا يمكن استبدالها بكود جديد.

الأهم فعلًا هو: كيف يتم احتساب الأمور بعد التغيير. الكود الجديد يؤثر فقط على المعاملات المؤهلة التي تحدث لاحقًا؛ الخصومات والعمولات المرتجعة والإحصاءات التي تم توليدها مسبقًا لن تتم إعادة حسابها، ولن يتم إعادة توزيعها ضمن علاقات إحالة أخرى.

عندما قرأت هذه القاعدة، ما كنت أتهّم به لم يكن فقط هل يمكن التغيير أم لا، بل ماذا سيتغير وماذا لن يتغير بعد التغيير. الدعوة (邀请码) أشبه بلوحة إرشادية سارية المفعول من الآن فصاعدًا، وليست ممحاة لمسح سجلات سابقة.

عند إعادة ضبط شبكة الاختبار في 29 يوليو، قامت الجهة الرسمية أيضًا بالاحتفاظ بجميع سجلات الـreferral. وبالنظر إلى ذلك معًا، منطق HertzFlow واضح جدًا: يمكن للمستخدم تعديل اختياراته المستقبلية، لكن السجلات التاريخية التي تشكّلت بالفعل لا تتحرك معها.

أتمنى أن تعرض الصفحة لاحقًا كل شيء في بطاقة تأكيد واحدة: الـCode الحالي، وقت التغيير، بدء المفعول في المستقبل، وأن التاريخ لا يتغير. قبل أن يوقّع المستخدم، يلقي نظرة واحدة ويفهم ماذا تم تغييره بهذه المرة، ويعرف أيضًا أي المحتويات لم تتغير.

قبل الإجراء، لا بد من مراجعة ما سيتم فعله على hertzflow.xyz، الشبكة الحالية، وما يتم في المحفظة. ما ورد أعلاه هو قواعد شبكة الاختبار الحالية؛ أما ما إذا كانت الشبكة الرئيسية ستستمر بنفس التطبيق، فيعتمد على الصفحة الرسمية الوثائقية والمستندات الرسمية.

الفرصة في صالح السوق، لكن المحفظة فيها BNB Meme واضحة… ومع ذلك لا يوجد BNB. عندما تريد البيع، لا يمكنك حتى إتمام عملية الإرسال—وهذا التأخير المحبط، الذي يكون أسوأ من دفع Gas باهظ التكلفة، يثير القلق فعلًا.

في 29 يوليو، أطلقت <velvet_capital> ميزة Gasless Trading. في اليوم التالي، تم فتح سيناريوهات BNB Chain. عند تسجيل الدخول عبر Email أو X مع المحفظة المدمجة، إذا لم يكن لديك Gas كافٍ بشكل أصلي، ستتولى VelvetX معالجة Gas لهذه الصفقة.

وإذا اشترى المستخدم عبر سلسلة/شبكة (cross-chain) ثم كان يخطط للبيع، فلن تحتاج أولًا إلى الخروج من التطبيق، أو إيجاد جسر (bridge)، أو تعويض Gas، ثم العودة لملاحقة السعر. بالنسبة لهذا السيناريو، شعرت فعلًا بالارتياح—فوقت الشراء إن كان هناك تعليق يمكنك الانتظار، لكن في وقت وجود حركة بالسوق، لن ينتظر السعر أحدًا.

لكن ما يلتقطه Gasless هو فقط خطوة واحدة: هل يمكن إرسال الصفقة أم لا. أما هل يمكن للراوتر أن يمر، وهل السيولة كافية، وهل يمكن قبول الانزلاق السعري (slippage)، وهل تغيّر السعر—فكل ذلك ما زال يؤثر على نتيجة الطلب النهائية.

لذلك فهو لا يضمن التنفيذ، ولا يعني أن التداول مجاني.

ما يزيله فعلًا هو نقطة توقف “ساذجة” لكنها قاتلة: لديك الأصول بالفعل بين يديك، لكن زر البيع يفشل لأنه ينقصه عملة أصلية واحدة. وبالنسبة لمنتجات التداول، من المهم جدًا أن يتمكن المستخدم من الدخول بسلاسة، وعندما تتغير ظروف السوق أن تبقى إجراءات الخروج قادرة على الإرسال بشكل صحيح؛ وهذا وحده يوضح مدى تفكير المنتج في سيناريوهات الاستخدام الواقعية.

حاليًا، يتوفر Gasless للمحفظة المدمجة عند تسجيل الدخول عبر Email أو X، بينما تظل المحافظ الخارجية بحاجة إلى توفير Gas من طرف المستخدم. وحدود الدعم، وحالة الصفحة بعد فشل الصفقة ومسارات إعادة المحاولة، لم تُشرح بعد بشكل واضح في المواد المنشورة.

عند مواجهة حركة سعرية سريعة، يمكنك أولًا التأكد من نوع المحفظة التي تستخدمها، وما إذا كان سعر العرض الحالي والانزلاق السعري ما زالا ضمن ما تقبله، وهل توجد ملاحظات/تغذية راجعة واضحة حول حالة الطلب