المواعيد النهائية للمعاملات في STON.fi V2: توقيع المحفظة ليس انتهاء صلاحية DEX
يمكن أن تنتهي عملية تبديل STON.fi V2 حتى بعد أن تكون المحفظة قد وافقت بالفعل على الرسالة الأولى. تقوم TON بتمرير العملية عبر عقود منفصلة، بينما تخزّن STON.fi tx_deadline داخل حمولة DEX بحيث يمكن رفض التنفيذ المتقاد لاحقًا.
🔥 وقت المحفظة مقابل وقت DEX
- إن validUntil في TonConnect لا يحكم إلا ما إذا كانت المحفظة تقبل الطلب.
- إن valid_until على رسالة المحفظة لا يقيّد إلا قبول الرسالة الموقّعة.
- tx_deadline ينتمي إلى حمولة STON.fi V2 ويحمي عمليات التنفيذ اللاحقة.
🚀 مسار الرسالة الذي يحمل الانتهاء
1. تبدأ محفظة المستخدم عرض تحويل Jetton.
2. ترسل محفظة Router Jetton transfer_notification إلى Router الخاص بـ STON.fi.
3. يستقبل Router بيانات التبديل بما فيها tx_deadline وعنوان الاسترداد min_out.
4. يقوم Router بإرسال رسالة تبديل إلى الـ Pool المطابق.
5. لا يزال لدى الـ Pool tx_deadline عندما يطبّق شروط التبديل.
🧠 لماذا يحدث هذا الانقسام
التوقيع ونقل الرموز ومعالجة Router وتنفيذ Pool ليست حدثًا واحدًا على TON. تحت الحمل، قد يمر وقت بعد وصول أول معاملة بالفعل. أضافت STON.fi حدًا زمنيًا اختياريًا V2 بعد تلك التأخيرات. لا يزال min_out وtx_deadline يحلان مشكلتين مختلفتين.
⚡ ماذا تفحص بعد انتهاء الصلاحية
- قد توجد بالفعل معاملات سابقة للمحفظة ولتحويل الرموز.
- اتبع إشعار Router، ثم توقيت Pool، ثم pay_to أو الاسترداد.
- لا تعتبر تجزئة أول رسالة للمحفظة كإتمام تسوية.
- إذا كان الاقتباس قديمًا، أعد المحاكاة بدل تحديث الحد الزمني فقط.
يتم فرض انتهاء صلاحية STON.fi عند تنفيذ الـ Pool، وليس عند توقيع المحفظة.
هل ستضع حدًا زمنيًا أقصر لـ STON.fi tx_deadline تحت الحمل أم تترك مساحة أكبر لتأخر الرسائل؟ 👇
ألقِ نظرة على خطوة التتبع التي أربكتك أكثر عند ظهور تبديل V2 كأنه منتهي.
ليست نصيحة استثمارية - ابحث بنفسك! 🚀
$GRAM @STONfi DEX
يمكن أن تنتهي عملية تبديل STON.fi V2 حتى بعد أن تكون المحفظة قد وافقت بالفعل على الرسالة الأولى. تقوم TON بتمرير العملية عبر عقود منفصلة، بينما تخزّن STON.fi tx_deadline داخل حمولة DEX بحيث يمكن رفض التنفيذ المتقاد لاحقًا.
🔥 وقت المحفظة مقابل وقت DEX
- إن validUntil في TonConnect لا يحكم إلا ما إذا كانت المحفظة تقبل الطلب.
- إن valid_until على رسالة المحفظة لا يقيّد إلا قبول الرسالة الموقّعة.
- tx_deadline ينتمي إلى حمولة STON.fi V2 ويحمي عمليات التنفيذ اللاحقة.
🚀 مسار الرسالة الذي يحمل الانتهاء
1. تبدأ محفظة المستخدم عرض تحويل Jetton.
2. ترسل محفظة Router Jetton transfer_notification إلى Router الخاص بـ STON.fi.
3. يستقبل Router بيانات التبديل بما فيها tx_deadline وعنوان الاسترداد min_out.
4. يقوم Router بإرسال رسالة تبديل إلى الـ Pool المطابق.
5. لا يزال لدى الـ Pool tx_deadline عندما يطبّق شروط التبديل.
🧠 لماذا يحدث هذا الانقسام
التوقيع ونقل الرموز ومعالجة Router وتنفيذ Pool ليست حدثًا واحدًا على TON. تحت الحمل، قد يمر وقت بعد وصول أول معاملة بالفعل. أضافت STON.fi حدًا زمنيًا اختياريًا V2 بعد تلك التأخيرات. لا يزال min_out وtx_deadline يحلان مشكلتين مختلفتين.
⚡ ماذا تفحص بعد انتهاء الصلاحية
- قد توجد بالفعل معاملات سابقة للمحفظة ولتحويل الرموز.
- اتبع إشعار Router، ثم توقيت Pool، ثم pay_to أو الاسترداد.
- لا تعتبر تجزئة أول رسالة للمحفظة كإتمام تسوية.
- إذا كان الاقتباس قديمًا، أعد المحاكاة بدل تحديث الحد الزمني فقط.
يتم فرض انتهاء صلاحية STON.fi عند تنفيذ الـ Pool، وليس عند توقيع المحفظة.
هل ستضع حدًا زمنيًا أقصر لـ STON.fi tx_deadline تحت الحمل أم تترك مساحة أكبر لتأخر الرسائل؟ 👇
ألقِ نظرة على خطوة التتبع التي أربكتك أكثر عند ظهور تبديل V2 كأنه منتهي.
ليست نصيحة استثمارية - ابحث بنفسك! 🚀
$GRAM @STONfi DEX
