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

TRON पर जमा पतों से USDT का स्वीप: हर स्वीप के लिए सक्रियण, ऊर्जा और बैंडविड्थ

जो पेमेंट गेटवे या एक्सचेंज हर ग्राहक को उसका अपना जमा पता देता है, उसे उन पतों पर पड़े TRC-20 USDT को एक मुख्य वॉलेट, यानी हॉट वॉलेट, में बटोरना पड़ता है, इससे पहले कि वह उसमें से कुछ भी बाहर चुका सके। TRON पर इनमें से हर स्थानांतरण एक आम USDT ट्रांसफ़र है, जिस पर जमा पता हस्ताक्षर करता है। उसे on-chain खाता चाहिए, अनुबंध कॉल के लिए ऊर्जा चाहिए और बाइटों के लिए बैंडविड्थ, और जिस जमा पते में सिर्फ़ USDT आया है उसके पास इनमें से कुछ नहीं होता।

USDT पाने से खाता नहीं बनता

USDT का बैलेंस टोकन अनुबंध की अपनी स्टोरेज में एक प्रविष्टि है। भीतर आता ट्रांसफ़र वह प्रविष्टि लिखता है और कोई खाता नहीं बनाता, इसलिए कोई पता USDT रख सकता है जबकि नेटवर्क के पास उसका कोई खाता ही न हो। 7 सितंबर 2026 की हमारी माप में मेननेट पर ऐसे दो पते मिले: दोनों के पास USDT था, और जिस नोड से हमने पढ़ा उसने उनके पीछे के खाते के बारे में पूछे जाने पर एक ख़ाली ऑब्जेक्ट लौटाया, हमारे टेस्ट कॉल से पहले भी और बाद में भी। 27 अक्टूबर को दोनों के पास ठीक वही बैलेंस थे जो 7 सितंबर को थे।

ऊर्जा किसी खाते को सौंपी जाती है, और जिस पते का कोई खाता नहीं उसे हम वह पहुँचाते नहीं: जो mode A या mode C का ऑर्डर ऐसे पते को from के रूप में नाम देता है वह 422 invalid_address के साथ लौटता है, और details.reason में inactive_wallet रहता है। चेन ख़ुद ऐसे पते को सौंपना ले लेगी या नहीं, यह हमने परखा नहीं, क्योंकि हमारा इनकार पहले आ जाता है। हमारे संचालन-नोट में उस वॉलेट से भेजने पर नोड का जवाब भी दर्ज है जिसे कभी कुछ मिला ही नहीं, no OwnerAccount। वह नोट हमारे अपने हॉट वॉलेट से भेजे गए TRX के बारे में है; हमने इस अवस्था के किसी पते से USDT ट्रांसफ़र आज़माया नहीं है। इस अवस्था की बड़ी कहानी सक्रिय न किए गए खातों वाली पोस्ट में है।

पते को सक्रिय करने में एक TRX ट्रांसफ़र लगता है, जिसका ख़र्च भेजने वाला उठाता है

भीतर आने वाला कोई भी TRX ट्रांसफ़र, चाहे कितना भी छोटा, खाता बना देता है, और उसके बाद वह पता किसी भी दूसरे खाते जैसा खाता है। उस माप की पहली कोशिश ठीक इसी पर बिगड़ी, और हमने उसे रद्द कर दिया: एक पते के बारे में पढ़ा गया कि उसका कोई खाता नहीं, और 22 सेकंड बाद किसी ने उसे एक अकेला sun भेजा, जिससे खाता बन गया। उसका अपना बनने का समय यही बता रहा था।

उसे बनाने की फ़ीस उस पर पड़ती है जो TRX भेजता है: स्वीप वाले इंतज़ाम में, वह वॉलेट जो सक्रियण का ख़र्च भरता है। इसे दो चेन पैरामीटर तय करते हैं। हमने उन्हें 3 सितंबर 2026 को पढ़ा, और नेटवर्क उन्हें बदल सकता है, इसलिए उनसे बजट बनाने से पहले उन्हें फिर पढ़ लीजिए।

एक सादे TRX ट्रांसफ़र पर दोनों कैसे मिलते हैं, यह हमने अपने किसी भेजने से नहीं नापा: उसके लिए किसी नए पते पर एक असली ट्रांसफ़र चाहिए, और हमने कोई किया नहीं। दोनों सूरतों में फ़ीस हर पते पर एक बार चुकती है। जो डेस्क हर पते को उसके बनते ही सक्रिय करता है, वह उसे उन पतों पर भी चुकाता है जिन पर शायद कभी कोई जमा आए ही नहीं, और जो पहली जमा पर सक्रिय करता है वह उसे सिर्फ़ वहाँ चुकाता है जहाँ स्वीप करने को कुछ है।

हर स्वीप में ऊर्जा का छोटा आँकड़ा लगता है

USDT ट्रांसफ़र कितनी ऊर्जा ख़र्च करता है, यह प्राप्तकर्ता पर निर्भर है। जब प्राप्तकर्ता के पास पहले से USDT है तो ट्रांसफ़र में लगभग 65,000 इकाइयाँ लगती हैं; जब उसका USDT बैलेंस शून्य है तो लगभग 131,000। प्राप्तकर्ता का खाता है या नहीं, इसका इसमें कोई दख़ल नहीं। जिस माप में वे दो पते मिले उसने चारों संयोजन आमने-सामने रखे, और हर बार फ़ैसला बैलेंस ने किया (दो आँकड़े क्यों हैं)।

स्वीप हमेशा एक ही प्राप्तकर्ता को भुगतान करता है, हॉट वॉलेट को, और हॉट वॉलेट के पास USDT है। इसलिए हर स्वीप सस्ती क़िस्म का है, single, चाहे जमा पता किसी भी अवस्था में हो। 7 सितंबर के कॉल एक इकाई ऐसे वॉलेट से बाहर ले गए जिसके पास बाक़ी बचा रहा, जबकि स्वीप सब कुछ ले जाता है और जमा पते को शून्य पर छोड़ता है। 27 अक्टूबर को हमने नोड से उन्हीं दो पतों पर दोनों का सिमुलेशन माँगा, प्राप्तकर्ता के रूप में USDT रखने वाले एक वॉलेट के साथ।

जमा पते को ख़ाली कर देने से कुछ नहीं बदला, और आँकड़ा वही है जो उस माप ने USDT रखने वाले को हर ट्रांसफ़र के लिए दिया था। ये नोड के सिमुलेशन हैं, और इनमें से कोई प्रसारित हुए स्वीप की रसीद नहीं है; 7 सितंबर के आँकड़ों पर भी यही चेतावनी लागू है। दोनों पतों का आज खाता है या नहीं, यह हमने दोबारा नहीं पढ़ा।

सस्ती क़िस्म खोने का एक ही तरीक़ा है, हॉट वॉलेट को ख़ाली कर देना। प्राप्तकर्ता पर USDT की एक अकेली इकाई छोटे आँकड़े के लिए काफ़ी है, पर शून्य पर उसमें अगला स्वीप लगभग 131,000 इकाइयाँ लेता है, जो जलाने पर 13.1 TRX है। जलाने पर एक सामान्य स्वीप प्रोटोकॉल की दर 100 sun प्रति इकाई पर 6.5 TRX का पड़ता है, और वही ऊर्जा किराए पर लेने का दाम बाज़ार के साथ हिलता है।

मुफ़्त बैंडविड्थ हर पते के लिए दिन में लगभग एक स्वीप ढकती है

बैंडविड्थ लेन-देन के बाइट नापती है, जहाँ ऊर्जा उसकी गणना नापती है (दोनों मीटर आमने-सामने)। हर खाते को उसका एक मुफ़्त दैनिक भत्ता मिलता है। 2 सितंबर 2026 को मेननेट पर हमने जो USDT ट्रांसफ़र भेजा और नापा, उसने अपनी बैंडविड्थ का दाम TRX में चुकाया, और उसी से ठीक पता चलता है कि उस पर कितनी बैंडविड्थ का बिल बना।

रोज़ के 600 के सामने, उतने का बिल बनाने वाला एक स्वीप समा जाता है और लगातार दो नहीं समाते। भत्ते के आगे नेटवर्क बाइटों के लिए भेजने वाले का TRX जलाता है। इसलिए दिन में किसी पते का पहला स्वीप बैंडविड्थ में कुछ नहीं लेता, और जो जमा पता अपनी ऊर्जा भी सौंपने से पाता है उसे यह स्वीप भेजने के लिए अपना कोई TRX नहीं चाहिए। पहले के कुछ ही देर बाद का दूसरा स्वीप अपने बाइटों का दाम जमा पते के TRX से चुकाता है। इन दोनों के बीच भत्ता कितनी जल्दी लौटता है, यह हमने नहीं नापा; हमारा अपना स्वीप मुफ़्त भत्ते से हर पते पर दिन में लगभग एक ट्रांसफ़र मानकर चलता है। अगर किसी पते को इससे ज़्यादा बार स्वीप करना होगा, तो सक्रिय करने वाला ट्रांसफ़र उसी समय उन बाइटों का TRX उसके पास छोड़ सकता है।

स्वीप के दौर के लिए ऊर्जा ऑर्डर करना

Mode A हर ट्रांसफ़र के दोनों सिरों के नाम लेता है, जमा पता from के रूप में और हॉट वॉलेट to के रूप में, और क़िस्म हम हॉट वॉलेट से ख़ुद पढ़ लेते हैं। Mode C सिर्फ़ उस वॉलेट का नाम लेता है जिसमें ऊर्जा भरनी है और क़िस्म आपसे लेता है, जो उस कस्टडी सिस्टम को जमता है जो अपने स्वीप अपने शेड्यूल पर हस्ताक्षरित करता है और चाहता है कि ऊर्जा पहले से वहाँ खड़ी हो (mode C विस्तार से)। स्वीप के लिए वह क़िस्म हमेशा single है, जब तक हॉट वॉलेट के पास USDT है। दोनों में से कोई भी mode एक ऑर्डर में 500 ट्रांसफ़र तक लेता है, भुगतान के दौर वाली ही छत। पट्टा पाँच मिनट या एक घंटे का है, और send_before उसके अंत से तीन सेकंड पहले पड़ता है।

खाते के बिना एक भी जमा पता हो तो पूरा ऑर्डर ठुकरा दिया जाता है। 422 उसे details.index और details.address में नाम से बताता है, और कुछ नहीं ख़रीदा जाता। इसलिए दौर को पहले छान लीजिए। POST /v1/estimate वही 500 ट्रांसफ़र लेता है और कुछ नहीं रोकता, और वह चेताता है कि ऑर्डर कहाँ ठुकराया जाएगा: उसे हर आइटम पर from दीजिए, और खाते के बिना हर जमा पता inactive_sender से चिह्नित होकर लौटता है। उन्हें सक्रिय कीजिए, सक्रियण को पक्का होने दीजिए, और ऑर्डर भेजिए। इनकार Idempotency-Key ख़र्च नहीं करता, और किसी ऑर्डर को इसके लिए ठुकराने से पहले हम सक्रियण को कैश छोड़कर सीधे चेन से दोबारा पढ़ते हैं, इसलिए सक्रिय करने वाला ट्रांसफ़र पक्का होते ही वही कुंजी और वही बॉडी चल जाती है।

हमारे अपने स्वीप से लेने लायक़ नियम

हम अपना एक स्वीप चलाते हैं। ग्राहक उन जमा पतों पर भुगतान करते हैं जो हम उनके लिए रखते हैं, और पृष्ठभूमि में चलने वाला एक पास वह रक़म उस एक हॉट वॉलेट में ले जाता है जो ख़रीद चुकाता है। वह TRX ले जाता है, इसलिए बैंडविड्थ ख़र्च करता है और ऊर्जा नहीं, और उसके रिकॉर्ड USDT स्वीप के ऊर्जा वाले पक्ष के बारे में कुछ नहीं कहते।

हमारा स्वीप रक़म उसी पल चेन से पढ़ता है जब वह तय करता है। हमारे अपने रिकॉर्ड को उस फ़ीस का पता नहीं जो जल गई, या उस स्वीप का जिसकी डेटाबेस पंक्ति क्रैश हुई प्रक्रिया के बाद बची नहीं, और चेन को पता है। यही नियम दोबारा कोशिश को सुरक्षित बनाता है: अगर रक़म पहले ही जा चुकी है, तो भेजने को कुछ नहीं बचता।

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

हमारा TRX स्वीप ज़्यादा से ज़्यादा बैलेंस में से फ़ीस का रिज़र्व घटाकर भेजता है, और वह रिज़र्व तभी रखता है जब पते की मुफ़्त बैंडविड्थ पहले ही ख़र्च हो चुकी हो। USDT स्वीप अपनी फ़ीस उससे अलग कॉइन में चुकाता है जिसे वह ले जाता है, इसलिए हर बार पूरा USDT बैलेंस जाता है, और रिज़र्व वह TRX बन जाता है जो किसी जमा पते को दिन में दूसरे स्वीप के बाइटों के लिए चाहिए।

स्वीप का दाम निकलने से पहले हर वह जमा पता खोजिए जिसे अब भी सक्रिय करना है, एक अनुरोध में पाँच सौ तक: हर आइटम पर from के साथ POST /v1/estimate →