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

भुगतान वॉलेट को ऊर्जा में रखना: स्टेक, हर ट्रांसफ़र पर किराया, या हर एक के बाद भराई

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

स्टेक सबसे व्यस्त दिन के हिसाब से बनता है और हर दिन उसकी क़ीमत चुकाई जाती है

ऊर्जा के लिए TRX स्टेक करना एक तय दैनिक पूल का हिस्सा ख़रीदना है। वॉलेट का दैनिक भत्ता उसका स्टेक गुणा नेटवर्क के TotalEnergyLimit भाग TotalEnergyWeight है, और 3 सितंबर 2026 को वह अनुपात 180,000,000,000 बटा 18,770,236,993 था: हर स्टेक किए TRX पर रोज़ दस इकाई ऊर्जा से ज़रा कम। भाजक ऊर्जा के लिए नेटवर्क का पूरा स्टेक है, आपका भी, इसलिए यह आँकड़ा ब्लॉक-दर-ब्लॉक खिसकता रहता है (सूत्र हल करके)।

ख़र्च हुई ऊर्जा अगले 24 घंटों में धीरे-धीरे लौटती है। जो वॉलेट अपने दिन का ज़्यादातर भुगतान दोपहर के एक ही दौर में करता है, उसे ऐसा स्टेक चाहिए जो उस दौर को ढके, और वह स्टेक शांत घंटों और शांत दिनों में भी बँधा रहता है। बाहर निकलना भी धीमा है। मेननेट पर, आज अनस्टेक किया TRX चौदह दिन बाद निकाला जा सकता है।

जब भुगतान स्टेक से बड़े हो जाते हैं, तो जिन ट्रांसफ़रों को भत्ता ख़र्च हुआ मिलता है वे कमी के लिए TRX जलाते हैं और, वॉलेट पर TRX और fee_limit में गुंजाइश हो तो, फिर भी पक्के हो जाते हैं। कोई त्रुटि नहीं लौटती, और पहला संकेत वॉलेट के इतिहास में जलने की एक पंक्ति है (सीमा कम होने पर क्या होता है)।

हर ट्रांसफ़र पर किराए पर लेना हर भेजने के आगे एक इंतज़ार रख देता है

दूसरा तरीक़ा हर ट्रांसफ़र के लिए, जैसे-जैसे वह आता है, ऊर्जा ख़रीदता है। ऑर्डर भेजने वाले वॉलेट और प्राप्तकर्ता का नाम लेता है। API 202 से जवाब देता है, ऑर्डर का अपना पता Location में और पूछताछ का अंतराल Retry-After में, और हम ऊर्जा ख़रीदते हैं और उसे वॉलेट पर आते देखते हैं। सौंपना पक्का होते ही ऑर्डर में send_before आता है, और वही आपके कोड के लिए भेजने का संकेत है। खिड़की पट्टे में से तीन सेकंड घटाकर है: पाँच मिनट के पट्टे पर 297 सेकंड और एक घंटे के पट्टे पर 3,597।

इसलिए हर भुगतान एक ख़रीद और एक ब्लॉक का इंतज़ार करता है। यह इंतज़ार हमने अपने उन ऑर्डरों पर नापा जिनमें भेजना क्लाइंट का कोड करता है, ऑर्डर बनने के पल से लेकर on-chain पक्के हुए आख़िरी सौंपने तक, 8 सितंबर 2026 तक के साठ दिनों में।

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

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

वह नियम जो हर ट्रांसफ़र के बाद वॉलेट को फिर भरता है

तीसरा तरीक़ा वॉलेट पर एक नियम है, जिसे हम Auto-refill के रूप में बेचते हैं, यानी TRX रखे बिना USDT भेजने का हॉट-वॉलेट वाला मामला। वह दो फ़ील्ड लेता है, address और daily_budget_trx, POST /v1/auto-refill-rules को एक कॉल में। तब से वॉलेट अपने हर ट्रांसफ़र के बाद फिर लगभग 131,000 इकाई ऊर्जा तक लाया जाता है। वह अगले किसी भी एक ट्रांसफ़र को ढकता है, उसे भी जो ऐसे पते को हो जिसके पास USDT नहीं। नियम कोई ऑर्डर नहीं बनाता: GET /v1/orders सिर्फ़ वही गिनाता है जो आपने दिए।

भराई की क़ीमत इससे तय होती है कि उससे पहले के ट्रांसफ़र ने क्या ख़र्च किया। अगर उस ट्रांसफ़र ने लगभग 65,000 इकाइयाँ ख़र्च कीं, तो भराई single दर पर लगती है; अगर लगभग 131,000, तो double पर। दोनों दरें GET /v1/tariff में maintenance_price_trx के नीचे हैं। वे अपनी अलग क़ीमत हैं और पट्टों की क़ीमतों से अलग हिलती हैं, और जो दर लगती है वह वही है जो भराई के पक्का होने के समय चल रही हो। नए नियम की पहली भराई हमेशा double होती है: उसकी क़ीमत तय करने के लिए कोई पिछला ट्रांसफ़र नहीं, और वॉलेट को पूरे 131,000 एक साथ मिलते हैं।

बिलिंग तब तक रुकती है जब तक ऊर्जा वॉलेट पर on-chain दिख न जाए; किसी आपूर्तिकर्ता का यह कहना कि उसने पहुँचा दी, काफ़ी नहीं। हर शुल्क एक maintenance.topup घटना के रूप में आता है, जिसमें rule_id, address, units और charged_trx होते हैं, और एक charge पंक्ति के रूप में, GET /v1/ledger में। जो वॉलेट कुछ नहीं भेजता उसे कोई भराई नहीं मिलती और वह किसी का भुगतान नहीं करता।

भराई कैसे रुकती है, और तब वॉलेट क्या करता है

दैनिक बजट, daily_budget_trx, नियम शुरू होने पर आपके उपलब्ध बैलेंस में से रोक लिया जाता है और हर UTC दिन की शुरुआत पर फिर, और नियम उस दिन इससे ज़्यादा ख़र्च नहीं कर सकता। भराइयाँ उसी रोकी गई राशि से कटती हैं, और जो बचता है वह आधी रात UTC पर बैलेंस में लौट जाता है। नियम का spent_today_trx दिखाता है कि दिन का कितना जा चुका। दोपहर में बजट बढ़ाने से अंतर रोकी गई राशि में जुड़ता है, और कोई दूसरा दिन नहीं खुलता।

जब बजट ख़र्च हो जाता है, तो भराइयाँ अगले UTC दिन तक रुक जाती हैं। आपको एक maintenance.budget_exhausted घटना मिलती है, जिसमें spent_today_trx और daily_budget_trx होते हैं, और नियम active रहता है। उस पल से आधी रात तक, वॉलेट जो हर ट्रांसफ़र ऊर्जा में नहीं चुका सकता वह कमी के लिए TRX जलाता है, 100 sun प्रति इकाई पर। औसत दिन के हिसाब से बना बजट व्यस्त दिन पर ख़त्म हो जाता है।

जब आपका बैलेंस अगले दिन की रोकी जाने वाली राशि को नहीं ढक पाता, तो नियम रुक जाता है। उसका status paused हो जाता है, paused_reason में insufficient_balance के साथ, और एक maintenance.paused घटना निकलती है। रुका हुआ नियम अपने आप कभी दोबारा शुरू नहीं होता, और जमा उसे दोबारा शुरू नहीं करती: वह PATCH /v1/auto-refill-rules/{rule_id} का इंतज़ार करता है, {"status": "active"} के साथ, और जिस दोबारा शुरू करने को बैलेंस अब भी नहीं ढक पाता उसका जवाब 402 है। जो विराम आप ख़ुद लगाएँ उसमें कोई कारण नहीं होता, इसलिए paused_reason पैसे का इंतज़ार करते नियम को आपके फ़ैसले का इंतज़ार करते नियम से अलग बताता है।

double दर से कम बजट को 422 के साथ ठुकरा दिया जाता है, details.reason में budget_below_topup_price और न्यूनतम details.min_daily_budget_trx में: पहली भराई double है, और छोटे बजट वाला नियम चालू हो जाता और उसका दाम कभी न चुका पाता।

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

एक उदाहरण-दिन, तीन तरीक़ों से

तीनों को आमने-सामने रखने के लिए एक वॉलेट और एक दिन लीजिए: ऐसे पतों को तीस भुगतान जिनके पास पहले से USDT है और ऐसे पतों को दस जिनके पास कुछ नहीं। जलना और स्टेक नेटवर्क का गणित हैं। ऑर्डर की क़ीमत और भराई की दरें हमारी हैं, जो GET /v1/tariff से 27 अक्टूबर 2026 को 21:46 UTC पर पढ़ी गईं; आज की क़ीमतों वाले पन्ने पर हैं।

उस घंटे ऑर्डर भराइयों से कम निकले, और आम तौर पर यही होता था। उसी शाम तक के तीस दिन के घंटेवार इतिहास में भराई की दरें एक बार भी नहीं बदलीं, और उसी ट्रांसफ़र के लिए पाँच मिनट का ऑर्डर ज़्यादातर घंटों में उसकी भराई से कम पड़ा।

भराई ऑर्डर से जितनी ऊपर पड़ती है, उससे ऐसा वॉलेट मिलता है जिसके पास हर ट्रांसफ़र के निकलते समय पहले से अपनी ऊर्जा होती है, और दिन में वह कितना ख़र्च कर सकता है उस पर एक सख़्त छत। बजट को, स्टेक की तरह, व्यस्त दिन ढकना होता है, पर शांत दिन उसका जो छोड़ता है वह आधी रात UTC पर बैलेंस में लौट जाता है। हमारे पास प्रोडक्शन का कोई आँकड़ा नहीं कि एक नियम दिन में कितनी भराइयाँ करता है।

एक अनुरोध और अपने चुने दैनिक बजट से भुगतान वॉलेट को ख़ुद भरने वाला बनाइए: API रेफ़रेंस में POST /v1/auto-refill-rules →