لا ← لم يخرج إلى السلسلة، والتوقف عند طرف الإرسال.
نعم، والتأكيدات ناقصة ← خرج فعلاً وينتظر تأكيد الشبكة.
نعم، والتأكيدات مكتملة دون قيد ← المشكلة عند المستلم.
لكل قسم معالجة مختلفة، وسؤال الطرف الخطأ يضيّع دورة كاملة. وطريقة القراءة في كيف تقرأ تحويلاً.
الأول: لم يخرج بعد
الأصل ما يزال عند طرف الإرسال. والأسباب المعتادة: طابور معالجة، أو مراجعة داخلية استدعتها هذه العملية، أو صيانة تُوقف السحب على تلك الشبكة.
والفارق الحاسم: هل لم يُرسل أصلاً، أم أُرسل ببطء؟ فإن كانت الواجهة تقول «قيد المعالجة» فلم يُرسل، وإعادة الإرسال تنتج سجلاً معلّقاً ثانياً.
وإن كان السبب مراجعة الحساب فراجع توقف السحب والمراجعة.
الثاني: خرج وينتظر التأكيدات
وجود المعرّف يعني أن الشبكة استلمته. ومدة الانتظار تتبع سرعة السلسلة وقيمة الرسم الذي دفعته. وعند الازدحام تتأخر المعاملات ذات الرسم المنخفض — تأخيراً لا رفضاً.
والتصرف الصحيح هنا هو الانتظار. وعادتنا أن ننظر أولاً إلى ازدحام السلسلة ككل: فإن كانت مزدحمة عموماً عرفنا أن الأمر ليس خاصاً بنا، فيهدأ البال ولا تمتد اليد إلى تصرف آخر.
الثالث: اكتملت التأكيدات ولم يُقيَّد
السلسلة تقول اكتمل، والتأكيدات فوق المطلوب، والحساب خالٍ — إذن المشكلة في إجراءات القيد لدى المستلم، ولا جواب إضافي على السلسلة.
وأشهر الأسباب وسم مفقود، ثم مبلغ دون الحد الأدنى، ثم صيانة عند المستلم. وعند مراسلته أرفق أربعة: المعرّف ووقت الإرسال والمبلغ والأصل والعنوان والوسم كما أدخلتهما.
هل يمكن الإسراع
تدعم بعض السلاسل استبدال معاملة معلّقة برسم أعلى لتتقدم في الطابور.
وهذه الخاصية متاحة عادةً في المحافظ التي تحفظها بنفسك، ولا تصلح لسحب صادر من منصة — لأن المنصة هي من وقّع تلك المعاملة، ولا صلاحية لك باستبدالها.
وحتى مع توفرها يلزم فهم آليتها: هي إعادة إرسال بالمعطيات نفسها تُلغي الأولى، لا «تذكير» بها. وخطأ في المعطيات يحوّلها إلى تحويلين مستقلين. ولغير المتمرس، الانتظار أسلم من التصرف.
ما لا يُفعل
- لا تُرسل تحويلاً «تجريبياً» ثانياً — الأول سيكتمل غالباً فتصير مرتين.
- لا تبدّل الشبكة وتعيد المحاولة — التبديل يستلزم عنواناً آخر وتأكيداً جديداً.
- لا تنشر لقطة كاملة في مجموعة عامة — ستصلك رسائل خاصة تعرض «التسريع».
- لا تدفع لمن يزعم الاستعجال — ترتيب الطابور يحدده رسم الشبكة، ولا أحد يتخطاه.
إن كانت USDT عالقة، فانظر أولاً على أي سلسلة أُرسلت
أكثر حالات «العملة عالقة» شيوعاً تخصّ USDT تحديداً، والسبب أنها موجودة على سلاسل عدة تحت الاسم نفسه. فحين تقول «حوّلت USDT ولم تصل» تكون قد أغفلت أهم معلومة: على أي سلسلة أُرسلت؟
لماذا يقع الالتباس هنا بالذات
واجهة الإرسال تعرض «USDT» فقط، بينما تحتها قائمة الشبكة هي التي تحدد الطريق فعلاً. ومن يترك القائمة على خيارها الافتراضي دون قراءة، يرسل على شبكة قد لا يستقبلها الطرف الآخر أصلاً.
وعندها لا تكون العملة «عالقة» بالمعنى الدقيق: هي وصلت إلى العنوان، لكن على شبكة لا يراقبها المستلم، أو إلى عنوان لا يملك المستلم مفتاحه على تلك الشبكة تحديداً.
كيف تعرف على أيّها ذهبت
افتح سجل السحب في الجهة المرسلة وانظر حقل الشبكة المسجّل مع العملية — لا تعتمد على ذاكرتك. ثم افتح مستكشف تلك السلسلة بالذات وابحث عن معرّف المعاملة. فإن لم تجدها هناك فأنت على الأرجح تفتش في السلسلة الخطأ، وطريقة القراءة في كيف تقرأ تحويلاً على مستكشف الكتل.
وقارن بعد ذلك بما تقبله الجهة المستلمة: افتح صفحة الإيداع لديها وانظر هل الشبكة التي أرسلت عليها مدرجة أصلاً. إن لم تكن مدرجة فهذه ليست حالة انتظار بل حالة شبكة خاطئة، ومعالجتها مختلفة تماماً — التفصيل في ماذا بعد اختيار الشبكة الخطأ.
وسبب وجود العملة الواحدة على سلاسل متعددة مشروح في لماذا للعملة الواحدة عدة شبكات، وهو يستحق القراءة مرة واحدة لأنه يمنع تكرار هذا الموقف كله.
ما يُدوَّن في أثناء الانتظار
العمل الوحيد المفيد وقتها هو تدوين الوقائع، لأن الحالات تتغير والإشعارات تُستبدل:
- معرّف المعاملة، وعلى أي سلسلة بحثت.
- عنوانا المرسل والمستلم كاملين.
- الأصل والكمية والمبلغ الواصل المعروض.
- وقت الإرسال ووقت ملاحظتك الخلل.
- نص الحالة في واجهة الإرسال منقولاً كما هو.
وأخفِ ما لا صلة له من بياناتك عند المشاركة.