هايبريد [المعنى راجع الملف الشخصي] " @SuiNetwork @SuiNetworkKR قمت بتجربة مباشرة لخدمات مثل @CetusProtocol داخل النظام البيئي، وقمت بتنفيذ سلسلة من المهام مثل التبادل، والتحويل، والإيداع." رغم أن كل خدمة كانت تقدم واجهة وأداء مختلفين، إلا أن العملية التي كررتها كانت متشابهة إلى حد كبير: أقارن الشروط لأقرر أين أضع أصولي، ثم أحوّلها إلى التوكنات المطلوبة، وأتحقق من تفاصيل المعاملة في المحفظة وأوافق عليها. وبمجرد اكتمال مهمة، أنتقل إلى الخدمة التالية لأتخذ قرارًا آخر. من خلال تكرار هذه العملية، تمكنّت من فهم أفضل للاقتصاد الوكيلي (Agentic Economy) الذي ركّز عليه Sui بشكل كبير في Basecamp 2026. لأنه إذا كلفت وكيلًا ذكيًا بإدارة الأصول، فالمشكلة الأصعب ليست فقط تنفيذ الصفقات بسرعة، بل كيفية تحويل الأحكام التي يتخذها الإنسان حاليًا إلى قواعد منظمة يمكن للوكيل اتباعها. على سبيل المثال، لنفترض أنك طلبت من الوكيل نقل الأموال المتبقية إلى مصدر ربح مستقر جيد. سيقرأ الوكيل أسعار الفائدة والشروط الحالية، وربما يحول إلى توكن مستقر آخر، ثم يودعه في بروتوكول إقراض. وإذا كانت هناك تكلفة للوصول إلى خدمة جمع البيانات، فسيتم تضمين الدفع في نفس العملية. عندما أقوم بذلك يدويًا، أفتح كل تطبيق على حدة وأتولى المهام بالترتيب. لكن عند تشغيلها تلقائيًا، تصبح الأمور مختلفة. إذا نجح التبديل لكن الإيداع فشل، فستمتلك أصولًا مختلفة عن الطلب الأصلي، ويجب تحديد مسبقًا ما هي الحدود التي يمكن للوكيل إنفاقها أثناء عبوره لعدة خدمات. وهنا تظهر مشكلة Payment Intents في Sui. إنها طريقة لربط مهام متعددة من تطبيقات مختلفة ضمن طلب واحد، ومعالجة النتائج كمعاملة ذرية واحدة. يمكن لـ Sui Programmable Transaction Block تضمين ما يصل إلى 1,024 مهمة في معاملة واحدة، ويمكن تكوينها بحيث تنجح جميع المهام معًا أو تُرفض جميعها معًا. رغم أن الرقم 1,024 كبير، إلا أنني شعرت بقوة أكبر بفكرة أنه لا يمكن ترك بعض المهام معلقة فحسب عند الفشل — فبما أن التبديل والدفع والإيداع هي مهام متسلسلة لتحقيق هدف واحد، فمن الأفضل للمستخدم أن يتم إلغاء العملية بالكامل بدلاً من تنفيذ جزء منها فقط. نفس الشيء ينطبق على نطاق الأموال التي تُمنح. إذا أعطيت محفظتك لوكيل ذكي واستخدمها بحرية، فسيكون من الصعب الثقة بتسليم أصولك الحقيقية. ما يصفه Sui كـ "scoped authority" هو وضع قيود على الوكيل — مثل المبلغ المسموح به، والوقت، والجهة المستفيدة — ثم فرض هذه القيود عبر البروتوكول. يمكن للمستخدم تحديد المهام التي يجب تنفيذها دون الحاجة إلى منح الوكيل صلاحيات كاملة على جميع أصوله. من خلال استخدام هذه الميزات واحدة تلو الأخرى، أدركت أن هناك الكثير مما يفصل بين وصف "الوكيل الذكي الذي يقوم بالتداول تلقائيًا" وبين البنية التحتية المالية الحقيقية اللازمة لـ Agentic Finance. خاصةً في البرامج التي تتعامل مع الأموال، فإن القدرة على العثور على صفقات جيدة وحدها غير كافية. يجب أن تكون قادرًا على إكمال مهام متعددة دفعة واحدة، وعدم تجاوز الصلاحيات الممنوحة، وتجنب ترك الأصول في حالة غير محددة عند الفشل. وحتى تكرار عمليات دفع صغيرة يمكن أن يصبح عبئًا بسبب الحاجة المستمرة لإعداد رصيد Gwei لكل معاملة. ويمكن ربط هذا الجزء الأخير مباشرةً بميزات متاحة بالفعل على شبكة Sui الرئيسية. حاليًا، في Sui، لا تحتاج إلى إعداد رصيد SUI منفصل كرسوم غاز عند إرسال توكنات مستقرة مدعومة مثل USDC بين المحافظ. قد يبدو هذا كميزة راحة بسيطة لشخص يرسل أموالًا نادرًا، لكنه يزيل الحاجة تمامًا لإدارة رصيد Gwei في كل محفظة عندما يقوم برنامج بتشغيل حسابات متعددة ومعالجة دفعات صغيرة باستمرار. كما تم إنشاء سيولة على السلسلة بالفعل للاستخدام عند الحاجة للتداول. يُستخدم DeepBook كطبقة سيولة على السلسلة في Sui، ويقوم Spot بمحاذاة الطلبات على السلسلة باستخدام نموذج سوق أسعار ثابت مركزي. وتقع Margin التي تدعم رافعة مالية تصل إلى 5x وPredict التي تعتمد على هيكل الخيارات فوق نفس البنية التحتية المالية. وكان هذا الجانب أكثر إثارة للاهتمام بالنسبة لي من مجرد اعتبار DeepBook كواجهة تداول عادية. فالأمر ليس عن أي مستخدم يفتح واجهة DEX معينة، بل عن قدرة التطبيقات أو البرامج على الاستفادة من سيولة مشتركة على السلسلة عند الحاجة — وهذا سيصبح أكثر فائدة كلما اتسعت مسؤولية العمليات المالية من الإنسان إلى البرمجيات. وأرى Hashi أيضًا في نفس السياق. Hashi حاليًا متوفر على شبكة Sui Testnet وليس بعد على Mainnet. عندما يودع المستخدم BTC في عنوان Hashi على شبكة Bitcoin، فإن عقدات التحقق في Sui تقوم بالتحقق من ذلك وتربطه بعقد ذكي على Sui لاستخدام BTC كضمان.الهدف هو الاحتفاظ ببيتكوين الحقيقي على شبكة بيتكوين، مع تمكين استخدامه كضمان للقروض أو خدمات مالية أخرى على Sui. عندما ننظر إلى تحويلات العملات المستقرة، السيولة على السلسلة، نوايا الدفع التي تجمع بين عدة عمليات مالية، إدارة الصلاحيات التي تحدّد نطاق إنفاق الوكلاء، وحتى الضمانات المدعومة ببيتكوين، نرى أن سبب قول Sui عن "التمويل الوكيلي" في Basecamp لا يقتصر فقط على كلمة "الذكاء الاصطناعي". لا يمكن حلّ مهمة نقل العمليات المالية التي يديرها البشر حاليًا إلى البرامج فقط بزيادة سرعة المعاملات. يجب أن يكون من الممكن تحديد نطاق الأموال التي يمكن للبرنامج استخدامها، وإنهاء العمليات الآمنة بين عدة خدمات، ثم التحقق من النتائج مرة أخرى على السلسلة قبل أن نتمكن من الثقة بوضع أصولنا الحقيقية تحت تصرفها. مع استخدامي المباشر لـ Sui، انتقل اهتمامي تلقائيًا في هذا الاتجاه. أنا أكثر فضولًا لمعرفة مدى أتمتة المنتجات الفعلية في العمليات التي وافقت عليها يدويًا في محفظتي، أكثر من معرفة كم تطبيقًا جديدًا سيتم الإعلان عنه. في Sui Basecamp في أكتوبر، أرغب في معرفة كيف يتم دمج نوايا الدفع في الخدمات الفعلية، وكيف تتغير تجربة المستخدم عندما يستخدم الوكلاء ذوو الصلاحيات المحدودة تطبيقات مالية متعددة، وما الذي يجهزه Hashi للانتقال من Testnet إلى Mainnet. #Sui #SUINGAPORE