ब्लॉग · 4 नवंबर 2026

TRON लेन-देन pending, expired या not found: USDT ट्रांसफ़र के लिए हर एक का मतलब

TRON हर तीन सेकंड में एक ब्लॉक बनाता है, इसलिए चेन पर पाँच मिनट सौ ब्लॉक होते हैं। उसके बाद भी pending दिख रहा USDT ट्रांसफ़र चार जगहों में से किसी एक पर होता है: हस्ताक्षर हुआ पर कभी प्रसारित नहीं हुआ, किसी नोड ने स्वीकार किया पर अभी किसी ब्लॉक में नहीं, ऐसे ब्लॉक में जो अभी अपरिवर्तनीय नहीं, या on-chain अंतिम और प्राप्त करने वाले प्लेटफ़ॉर्म के उसे क्रेडिट करने की राह देखता। रास्ते में दो और शब्द अक्सर सामने आते हैं: एक एक्सप्लोरर जो हैश नहीं ढूँढ पाता, और एक नोड जो लेन-देन को expired कहता है। हर एक का अपना इलाज है, और इनमें से एक इलाज, बहुत जल्दी आज़माया जाए तो, उसी ट्रांसफ़र की क़ीमत दो बार चुकवा देता है।

हर लेन-देन अपनी समय-सीमा साथ लेकर चलता है

ब्लॉक का अंतराल प्रोटोकॉल का एक स्थिरांक है, 3,000 मिलीसेकंड। दूसरी संख्या लेन-देन के भीतर है। जब कोई वॉलेट ट्रांसफ़र बनाता है, वह एक expiration समय लिखता है raw_data में, यानी उस हिस्से में जिस पर हस्ताक्षर होते हैं, और हर नोड उसे जाँचता है। जिस लेन-देन का समाप्ति-समय बीत चुका है उसे ठुकरा दिया जाता है, और उसे भी जिसका समाप्ति-समय नोड के हेड ब्लॉक से एक दिन से ज़्यादा आगे पड़ता है। दोनों के लिए नोड का शब्द TRANSACTION_EXPIRATION_ERROR है।

फ़ील्डों की एक दूसरी जोड़ी लेन-देन को किसी हाल के ब्लॉक से बाँधती है। ref_block_bytes और ref_block_hash एक ऐसे ब्लॉक का नाम लेते हैं जिसे नेटवर्क अब भी रखता है, और एक नोड पिछले 65,536 ब्लॉक याद रखता है, यानी चेन के लगभग 54 घंटे। उससे पुराना संदर्भ, या टेस्ट नेटवर्क से लिया गया संदर्भ, इसके बजाय TAPOS_ERROR कमाता है। दोनों की घड़ी तब शुरू होती है जब लेन-देन बनाया जाता है।

“pending” के चार मतलब

हस्ताक्षर हुआ, कभी प्रसारित नहीं हुआ

कोई वॉलेट या भुगतान स्क्रिप्ट ट्रांसफ़र पर हस्ताक्षर करके उसे किसी नोड को कभी सौंप ही न पाए — टाइमआउट के बाद, या हस्ताक्षर और भेजने के बीच किसी क्रैश के बाद। ट्रांसफ़र का हैश फिर भी होता है, क्योंकि हैश लेन-देन के अपने बाइटों से निकाला जाता है। वह raw_data का SHA-256 है, और वह तब भी मौजूद है जब किसी नोड ने कुछ देखा तक नहीं। आपके लॉग में एक हैश बस यह साबित करता है कि ट्रांसफ़र बनाया गया था। जो एक्सप्लोरर उसके लिए “not found” कहता है वह सही है: जिन नोडों से वह पढ़ता है उनमें से किसी के पास वे बाइट नहीं हैं।

नोड ने स्वीकार किया, अभी किसी ब्लॉक में नहीं

जो नोड कोई लेन-देन लेता है वह तुरंत जवाब देता है और उसे लंबित लेन-देनों के अपने पूल में तब तक रखता है जब तक कोई ब्लॉक उसे न ले ले। स्वीकार होना और शामिल होना अलग घटनाएँ हैं, और हमारे अपने ऑर्डर की स्थितियाँ उन्हें अलग रखती हैं: mode B में, जहाँ हम क्लाइंट का हस्ताक्षर किया हुआ ट्रांसफ़र प्रसारित करते हैं, broadcasted का मतलब है कि किसी नोड ने लेन-देन स्वीकार किया, और ब्लॉक के बारे में अभी कुछ नहीं कहता। तीन-सेकंड वाली चेन पर यह अवस्था छोटी होती है। नोड ऐसा लेन-देन भी स्वीकार कर सकता है जिसे कोई ब्लॉक कभी नहीं लेता, आम तौर पर इसलिए कि उसे उस पूल से गिरा दिया गया। ऐसा ट्रांसफ़र समाप्ति-समय बीतते ही हमेशा के लिए चला जाता है।

ब्लॉक में, अभी अपरिवर्तनीय नहीं

चेन के हेड पर सबसे नए ब्लॉक अब भी बदले जा सकते हैं। TRON हेड के पीछे एक दूसरा पॉइंटर रखता है, नवीनतम सॉलिडिफ़ाइड ब्लॉक, जो वह सबसे नया ब्लॉक है जिसे नेटवर्क अपरिवर्तनीय मानता है, और नोड दोनों देता है। दोनों के बीच की दूरी इतनी है जितनी देर कोई ट्रांसफ़र किसी ब्लॉक में बिना अंतिम हुए पड़ा रहता है। हमने दोनों पॉइंटर एक बार एक सार्वजनिक फ़ुल नोड से पढ़े, एक ही पल में किए दो कॉल से।

ब्लॉक संख्याओं का अंतर और टाइमस्टैंपों का अंतर तीन सेकंड प्रति ब्लॉक पर एक-दूसरे से मेल खाते हैं। हमारे mode B के आइटम confirmed तक सॉलिडिफ़िकेशन के बाद ही पहुँचते हैं, जिसे हमारा API रेफ़रेंस लगभग एक मिनट बताता है, और यह पाठ उससे मेल खाता है। इससे इस आम सवाल का जवाब बनता है कि TRON पर USDT ट्रांसफ़र में कितना समय लगता है: हर तीन सेकंड में एक ब्लॉक, और उसके लगभग एक मिनट बाद अंतिमता। यह एक नोड से एक अकेला पाठ है। हमने यह नहीं नापा कि यह अंतर दिन भर में कैसे हिलता है, या हमारे अपने ऑर्डरों का डिलीवरी से प्रसारण और फिर ब्लॉक तक का समय।

चेन पर अंतिम, अभी क्रेडिट नहीं हुआ

एक्सचेंज या पेमेंट प्रोसेसर जमा राशि को ब्लॉकों की उस गिनती के बाद क्रेडिट करता है जो वह अपने लिए तय करता है। हम किसी प्लेटफ़ॉर्म की गिनती नहीं जानते और कोई गिनती उद्धृत नहीं करते। प्लेटफ़ॉर्म से पूछने से पहले, ट्रांसफ़र के बगल में लिखा नतीजा पढ़िए। ट्रांसफ़र ब्लॉक में होकर भी नाकाम हो सकता है, फ़ीस ख़र्च हो गई और कोई टोकन नहीं हिला, और उस जगह SUCCESS के सिवा कुछ भी नाकामी है (OUT_OF_ENERGY का मतलब, और USDT ट्रांसफ़र के नाकाम होने के बाक़ी तरीक़े)। सॉलिडिफ़ाइड ब्लॉक में सफल ट्रांसफ़र प्राप्तकर्ता के पते तक पहुँच चुका है। जो बचता है वह प्लेटफ़ॉर्म का हिसाब-किताब है, और उसका सपोर्ट उसे हैश से ढूँढ सकता है।

expired का मतलब, और दोबारा कैसे भेजें

समाप्ति-समय के बाद कोई लेन-देन किसी ब्लॉक में नहीं जा सकता। हर नोड उसे ठुकराता है, इसलिए वही हस्ताक्षरित बाइट दोबारा प्रसारित करने से बस एक और इनकार मिलता है। इलाज एक नया लेन-देन है: ट्रांसफ़र को फिर बनाइए, नए समाप्ति-समय और किसी हाल के ब्लॉक के संदर्भ के साथ, और उस पर हस्ताक्षर कीजिए।

दोबारा बनाने से एक ही रक़म दो बार नहीं चुकती। जिस लेन-देन को किसी ब्लॉक ने लिया ही नहीं, वह कभी चला ही नहीं: उसने कोई टोकन नहीं हिलाया और कुछ नहीं जलाया, क्योंकि ट्रांसफ़र अपनी ऊर्जा और अपना TRX तब ख़र्च करता है जब वह किसी ब्लॉक में चलता है। एक बार लेन-देन किसी ब्लॉक में आ जाए, तो कोई नोड उसे दूसरी बार नहीं चलाएगा। पैसे को दो बार भेजने का इकलौता तरीक़ा यह है कि आप तब बदली का लेन-देन हस्ताक्षरित कर दें जब मूल अब भी पहुँच सकता हो। नोड समाप्ति-समय को अपने हेड ब्लॉक के समय के सामने परखता है, जो आपकी घड़ी से पीछे हो सकता है, इसलिए समय-सीमा से ठीक पहले के सेकंडों में बना कोई ब्लॉक अब भी मूल को ले सकता है, और पिछड़ा हुआ नोड या एक्सप्लोरर उसे अभी न दिखा रहा हो। जिस सॉफ़्टवेयर ने मूल बनाया उसके पास वह मौजूद है और वह raw_data.expiration पढ़ सकता है, एपॉक से मिलीसेकंड में। तब तक रुकिए जब तक नवीनतम सॉलिडिफ़ाइड ब्लॉक उस पल से आगे न निकल जाए, जिसमें हमारे पाठ में लगभग एक मिनट और लगता है, और फिर किसी नोड से हैश के सहारे पूछिए। अगर नोड फिर भी लेन-देन को नहीं जानता, तो मूल अब कभी नहीं पहुँच सकता, और नया ट्रांसफ़र ही अकेला है।

ऊर्जा ऑर्डर पर pending और expired

किराए की ऊर्जा एक दूसरी घड़ी जोड़ देती है। जब किसी ऑर्डर की ऊर्जा पहुँच जाती है, तो ऑर्डर में send_before होता है, यानी पट्टे में से तीन सेकंड घटाकर: पाँच मिनट के पट्टे पर 297 सेकंड और घंटे पर 3,597। खिड़की उस सौंपने से गिनी जाती है जिसे हमने पक्का होते देखा, और चेन पर पट्टा उससे एक ब्लॉक और एक पूछताछ-चक्र पहले शुरू हो चुका था, इसलिए खिड़की के आख़िरी सेकंडों को पहले ही जा चुका मानिए (किराए की ऊर्जा कितनी देर चलती है)। जो ट्रांसफ़र तब किसी ब्लॉक में पहुँचता है जब ऊर्जा वॉलेट से जा चुकी हो, वह भेजने वाले का TRX प्रोटोकॉल की दर 100 sun प्रति इकाई पर जलाता है, USDT रखने वाले पते को ट्रांसफ़र के लिए लगभग 6.5 TRX।

खिड़की बंद होने पर क्या होता है, यह इस पर निर्भर है कि भेजता कौन है। mode A में आप ट्रांसफ़र ख़ुद प्रसारित करते हैं। हम नेटवर्क देखते हैं, आपका ट्रांसफ़र दिखते ही आइटम को sent चिह्नित करते हैं, और उसके हैश के साथ order.item.sent webhook भेजते हैं, हैश data.txid में होता है। अगर send_before तक कोई ट्रांसफ़र नहीं दिखा, तो आइटम expired हो जाता है और उसका शुल्क लगता है, क्योंकि ऊर्जा पहुँचाई गई थी।

mode B में आप हमें हस्ताक्षरित लेन-देन सौंपते हैं और ऊर्जा पहुँचते ही हम उसे प्रसारित कर देते हैं (mode B कैसे काम करता है)। आइटम broadcasting और broadcasted से होता हुआ confirmed तक जाता है, आख़िरी सिर्फ़ सॉलिडिफ़िकेशन के बाद। हम send_before के बाद कभी प्रसारित नहीं करते: जो आइटम हम समय पर नहीं भेज सके वह failed पर बंद होता है, error: broadcast_window_missed के साथ, और रोकी गई राशि पूरी लौट आती है। वहाँ खिड़की पर लेन-देन के अपने समाप्ति-समय की भी सीमा लगती है, प्रसारण के लिए एक हाशिया घटाकर, इसलिए जो लेन-देन हम तक बहुत कम उम्र बचे हुए पहुँचता है उसे छोटी खिड़की मिलती है।

Mode B आते समय भी समाप्ति-समय जाँचता है। जब हमें लेन-देन मिलता है तो उसमें कम से कम 180 सेकंड की उम्र बची होनी चाहिए और 23 घंटे 59 मिनट से ज़्यादा नहीं। बहुत आगे की समय-सीमा 400 invalid_request के रूप में लौटती है, जिसमें details.reason में expiration_too_far रहता है, और बहुत कम उम्र उसी 400 के रूप में, सिर्फ़ details.index के साथ। दोनों जवाब किसी भी ऊर्जा के ख़रीदे जाने से पहले आते हैं।

क्रम से क्या जाँचें

1. क्या किसी नोड ने कभी लेन-देन स्वीकार किया। जिस सॉफ़्टवेयर ने उसे भेजा उसके पास नोड का जवाब होता है, या कुछ नहीं होता क्योंकि प्रसारण कभी हुआ ही नहीं। हैश अकेला कुछ तय नहीं करता, क्योंकि वह किसी भी प्रसारण से पहले मौजूद होता है।
2. क्या हैश मिलता है, किसी एक्सप्लोरर पर या हैश के सहारे पूछे गए नोड से। अगर वह नहीं मिलता और समाप्ति-समय अभी आगे है, तो वही हस्ताक्षरित बाइट दोबारा प्रसारित कीजिए। अगर नवीनतम सॉलिडिफ़ाइड ब्लॉक समाप्ति-समय से आगे निकल गया और हैश अब भी नहीं मिलता, तो नया लेन-देन बनाइए और उस पर हस्ताक्षर कीजिए।
3. जो हैश मिल जाए उसके बगल का नतीजा। SUCCESS का मतलब है ट्रांसफ़र पूरा हुआ। इसके सिवा कुछ भी हो तो उसका मतलब है कि वह चला और नाकाम हुआ, और फ़ीस पहले ही ख़र्च हो चुकी है।
4. क्या उसका ब्लॉक सॉलिडिफ़ाइड है। हमारे पाठ में सबसे नया अपरिवर्तनीय ब्लॉक हेड से लगभग एक मिनट पीछे था, इसलिए उससे कम उम्र का सफल ट्रांसफ़र अभी निपट रहा है।
5. प्राप्त करने वाले प्लेटफ़ॉर्म की ब्लॉकों की अपनी गिनती, और उसके बाद उसका सपोर्ट, हैश के साथ।
6. हमारे किसी ऑर्डर पर, आइटम: sent, अपने txid के साथ, mode A में; confirmed mode B में। जब खिड़की पहले बंद हो गई, तो mode A expired दिखाता है और mode B failed दिखाता है, error: broadcast_window_missed के साथ। mode B में expired का मतलब है कि किसी नोड ने लेन-देन में ही किसी खोट की वजह से उसे ठुकरा दिया, या लेन-देन किसी ब्लॉक में रिवर्ट हो गया, और उसका शुल्क लगता है।

देखिए कि कोई आइटम ready पर बैठा रहे और फिर expired हो जाए, जबकि असल में कुछ दाँव पर नहीं: सैंडबॉक्स में एक ऐसा प्राप्तकर्ता है जिसका ट्रांसफ़र कभी आता ही नहीं →