ब्लॉग · 10 सितंबर 2026

TRON खाता सक्रिय नहीं: यह क्या रोकता है और इसे कैसे हटाएँ

जब तक नेटवर्क के पास किसी पते के लिए कोई खाता न हो, वह पता एक कुंजी-जोड़ी भर है। “TRON खाता सक्रिय नहीं” बस इतना ही है, और यही वह जवाब है जो लोगों को चौंका देता है: पता ठीक बना हुआ है, वॉलेट उसे दिखा रहा है, QR कोड स्कैन हो जाता है, और चेन ने उसका नाम तक नहीं सुना। भुगतान करने वाली टीम के सामने यह हालत दो अलग जगहों पर आती है — भेजने वाले वॉलेट पर और जिस पते को पैसा जा रहा है उस पर — और इनमें से अस्वीकृति सिर्फ़ एक है।

सक्रिय होना असल में है क्या

TRON का पता किसी कुंजी-जोड़ी से ऑफ़लाइन निकाला जाता है। बनते समय वह कहीं दर्ज नहीं होता, और नेटवर्क को उसका पता तभी चलता है जब कोई लेन-देन उसके लिए खाते का रिकॉर्ड बना देता है। हमारी अपनी जाँच इस बारे में शब्दशः है: हम किसी नोड से उस पते के पीछे का खाता माँगते हैं, और ख़ाली जवाब का ही मतलब activated: false है। “हमें मिला नहीं” नहीं, “नया लग रहा है” नहीं — वहाँ कोई खाता है ही नहीं।

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

यह क्या रोकता है: वह वॉलेट जो भेजेगा

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

हैंडलर लिखने से पहले उस अस्वीकृति के तीन गुण जान लेने चाहिए।

वह Idempotency-Key ख़र्च नहीं करती। इस परिवार की कोई भी अस्वीकृति नहीं करती: अनुरोध ठीक बना है, बस उन पतों पर हम उसे ले नहीं सकते। वॉलेट बन जाने के बाद वही कुंजी और बाइट-दर-बाइट वही बॉडी टकराव नहीं, जायज़ दोहराव है — इसलिए आपकी तरफ़ कुछ भी दोबारा निकालना नहीं पड़ता।

उसका जवाब कैश से नहीं आता। पते की हालत यहाँ कैश की जाती है, पर किसी ऑर्डर को इस वजह से मना करने से पहले सक्रिय होने की बात कैश के मुँह के आगे से दोबारा पढ़ी जाती है — कुछ सेकंड पहले सक्रिय हुआ वॉलेट तुरंत मान लिया जाता है, किसी प्रविष्टि के बूढ़े होने का इंतज़ार नहीं होता। फ़ौरन दोबारा भेजिए; इंतज़ार करने को कुछ है ही नहीं।

mode B में उसका वजूद ही नहीं है। वहाँ लेन-देन पहले ही भेजने वाले पते के मालिक के हस्ताक्षर के साथ आता है, इसलिए खाता होने का सवाल ही नहीं उठता, और जाँच ऐसा सवाल पूछ रही होती जिसका जवाब ख़ुद उसी में पड़ा है।

सक्रिय न होना और बिगड़ा हुआ होना एक बात नहीं

दो जवाब एक ही ग़लती-कोड लेकर आते हैं और उलटी बातें कहते हैं। 400 invalid_address, जिसमें details.reason होता ही नहीं, उस स्ट्रिंग के आकार के बारे में है: वह TRON का पता है ही नहीं, और चेन पर कुछ भी हो जाए वह पता बनेगा नहीं। 422 invalid_address, जिसमें details.reason होता है, एक बिलकुल ठीक पते की हालत के बारे में है, और एक ही लेन-देन उसे सुधार देता है। जो पाइपलाइन दोनों को एक जैसा मानती है वह पहले पर हमेशा दोबारा कोशिश करती रहती है और दूसरे को छोड़ देती है — इसलिए शाखा उस ग़लती-कोड पर नहीं, जो दोनों में एक है, बल्कि details.reason के होने या न होने पर बनानी चाहिए।

इसका दाम क्या है: वह पता जिसे पैसा जा रहा है

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

यहीं दोनों सवाल अलग हो जाते हैं, और नाम उन्हें गड्डमड्ड करने का न्योता देते हैं, इसलिए सटीक रहिए। activated पूछता है कि नेटवर्क के पास उस पते के लिए खाता है या नहीं। holds_usdt पूछता है कि उसका USDT बैलेंस शून्य से ऊपर है या नहीं। क़ीमत दूसरे के पीछे चलती है: पते पर USDT न हो तो kind double होता है, चाहे वह सक्रिय हो या न हो। inactive_recipient चेतावनी पहले के पीछे चलती है। इसलिए बरसों पहले सक्रिय हुआ ऐसा पता, जिसे कभी USDT में पैसा मिला ही न हो, कोई चेतावनी नहीं लाता और फिर भी double पर लगता है; और जो पता कभी सक्रिय ही न हुआ हो वह भी USDT रख सकता है — TRC-20 बैलेंस टोकन अनुबंध के अपने भंडार में रहता है, इसलिए आता हुआ ट्रांसफ़र बैलेंस बनाता है, खाता नहीं — जिससे वह single पर लगता है और साथ-साथ inactive_recipient की चेतावनी भी लाता है। दोनों तब तक एक ही सवाल लगते हैं, जब तक कोई पता उनके अलग-अलग जवाब न दे दे।

एक पता जाँचना, और पाँच सौ जाँचना

अकेले पते के लिए GET /v1/address-check एक ही कॉल में दोनों सवालों और दो और के जवाब देता है: activated, holds_usdt, blacklisted, is_contract, और इन्हीं से निकलता expected_kind।

बैच के लिए POST /v1/estimate 500 तक ट्रांसफ़र लेता है और मना कुछ भी नहीं करता — उसे जो कुछ दिखता है वह सब उस आइटम पर warnings बनकर लौटता है, वे बातें भी जो किसी ऑर्डर को रोक देतीं। प्राप्तकर्ता हमेशा जाँचे जाते हैं। भेजने वाला तभी जाँचा जाता है जब आप उसका नाम लें: अनुमान के आइटम पर from वैकल्पिक है और किसी क़ीमत को नहीं बदलता, और उसे देने से सिर्फ़ जवाब मिलता है। वहाँ inactive_sender वही बात है जिसे ऑर्डर 422 बनाकर बताता है, बस यह तब आती है जब दाँव पर कुछ नहीं होता।

POST /v1/estimate
{"transfers":[{"from":"TN3W…","to":"TMu1…"}]}
# आइटम पर आ सकने वाली चेतावनियाँ: blacklisted, inactive_recipient,
# contract_recipient, inactive_sender, blacklisted_sender

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

उपाय

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

यही शर्त उस वॉलेट पर भी लागू है जिसे आप भरा हुआ रखना चाहते हैं। Auto-refill का नियम सक्रिय न हुए पते पर उसी वजह-शब्द के साथ मना होता है, और अनुबंध वाले पते पर contract_wallet के साथ — अनुबंध की ऊर्जा-खपत अलग तरह से चलती है और नियम के पास नापने को कुछ नहीं होता। पहले सक्रिय कीजिए, फिर नियम लगाइए।