شرح STON.fi V2 Cross-Swap: حمولة متداخلة لمسارات نفس الراوتر
تحوّل حمولة cross-swap في STON.fi V2 عملية swap موقّعة واحدة إلى مسار متعدد القفزات على نفس الراوتر. الإخراج الوسيط لا يحتاج أبدًا إلى الوصول إلى محفظتك قبل بدء الحوض التالي.
🔥 ما الذي يتغير مع Cross-Swap
- يمكن لحقل custom_payload أن يحمل عملية DEX أخرى مُهيكلة.
- الرمز المخصص هو cross_swap: 0x69cf1a5b.
- يمكن للقفزة التالية نفسها أن تتضمن حمولة custom اختيارية أخرى.
🚀 كيف يعمل مسار A إلى B إلى C
1. يتم نقل الرمز A إلى محفظة Token A الخاصة بالراوتر.
2. يقوم حوض A/B بتنفيذ العملية وإرسال Token B مرة أخرى عبر الراوتر.
3. بدلًا من تسليم B، يقوم الراوتر بإطلاق swap المُشفّر الخاص بـ B/C.
4. يتم إرسال الرمز C إلى المستقبِل بعد انتهاء الحوض الثاني.
🧠 لماذا يجب أن يهتم المستخدمون والبناؤون
يمكن لـ STON.fi وصف B إلى C قبل أن تبدأ A إلى B حتى. هذا مفيد عندما لا يوجد حوض مباشر A/C، لكن يوجد A/B و B/C. تقوم المحفظة بالتوقيع مرة واحدة، بينما تقوم محافظ jetton والراوتر وعدة أحواض بإبقاء المسار مستمرًا عبر رسائل TON.
⚡ ما الذي ما زال يحتاج إلى حذر
- يتم التحقق من الحد الأدنى للإخراج خطوة بخطوة، وليس فقط على الرمز النهائي.
- إذا فشل B إلى C بعد نجاح A إلى B، فقد تكون عملية الاسترداد هي B.
- تجاهل ربط نفس الراوتر (Same-Router chaining) للـ fwd_gas داخل cross_swap؛ يحتاج الراوتر الآخر إلى حمولة swap عادية، والراوتر الآخر كـ receiver، وكفاية forward gas.
💬 رأيي
الجزء الذكي في توجيه STON.fi V2 هو ترميز العملية التالية داخل العملية الحالية. ابدأ من محاكاة API، ومرّر بيانات الراوتر الوصفية إلى dexFactory()، واستخدم createCrossSwapBody فقط مع عنوان الحوض الحالي وعناوين المحفظة.
هل تفضل ربط الأحواض على راوتر STON.fi واحد أم التوجيه إلى راوتر آخر؟ 👇
شارك عدد القفزات الذي ستقوم فعلًا بترميزه في مسار مباشر.
ليست نصيحة استثمارية - قم بالبحث بنفسك! 🚀
$GRAM @STONfi DEX
تحوّل حمولة cross-swap في STON.fi V2 عملية swap موقّعة واحدة إلى مسار متعدد القفزات على نفس الراوتر. الإخراج الوسيط لا يحتاج أبدًا إلى الوصول إلى محفظتك قبل بدء الحوض التالي.
🔥 ما الذي يتغير مع Cross-Swap
- يمكن لحقل custom_payload أن يحمل عملية DEX أخرى مُهيكلة.
- الرمز المخصص هو cross_swap: 0x69cf1a5b.
- يمكن للقفزة التالية نفسها أن تتضمن حمولة custom اختيارية أخرى.
🚀 كيف يعمل مسار A إلى B إلى C
1. يتم نقل الرمز A إلى محفظة Token A الخاصة بالراوتر.
2. يقوم حوض A/B بتنفيذ العملية وإرسال Token B مرة أخرى عبر الراوتر.
3. بدلًا من تسليم B، يقوم الراوتر بإطلاق swap المُشفّر الخاص بـ B/C.
4. يتم إرسال الرمز C إلى المستقبِل بعد انتهاء الحوض الثاني.
🧠 لماذا يجب أن يهتم المستخدمون والبناؤون
يمكن لـ STON.fi وصف B إلى C قبل أن تبدأ A إلى B حتى. هذا مفيد عندما لا يوجد حوض مباشر A/C، لكن يوجد A/B و B/C. تقوم المحفظة بالتوقيع مرة واحدة، بينما تقوم محافظ jetton والراوتر وعدة أحواض بإبقاء المسار مستمرًا عبر رسائل TON.
⚡ ما الذي ما زال يحتاج إلى حذر
- يتم التحقق من الحد الأدنى للإخراج خطوة بخطوة، وليس فقط على الرمز النهائي.
- إذا فشل B إلى C بعد نجاح A إلى B، فقد تكون عملية الاسترداد هي B.
- تجاهل ربط نفس الراوتر (Same-Router chaining) للـ fwd_gas داخل cross_swap؛ يحتاج الراوتر الآخر إلى حمولة swap عادية، والراوتر الآخر كـ receiver، وكفاية forward gas.
💬 رأيي
الجزء الذكي في توجيه STON.fi V2 هو ترميز العملية التالية داخل العملية الحالية. ابدأ من محاكاة API، ومرّر بيانات الراوتر الوصفية إلى dexFactory()، واستخدم createCrossSwapBody فقط مع عنوان الحوض الحالي وعناوين المحفظة.
هل تفضل ربط الأحواض على راوتر STON.fi واحد أم التوجيه إلى راوتر آخر؟ 👇
شارك عدد القفزات الذي ستقوم فعلًا بترميزه في مسار مباشر.
ليست نصيحة استثمارية - قم بالبحث بنفسك! 🚀
$GRAM @STONfi DEX
