सवाल और जवाब
पहले ऑर्डर से पहले इंटीग्रेटर जो पूछते हैं — समूहों में और संक्षेप में। जहाँ जवाब हमारी आदत का नहीं बल्कि अनुबंध का है, वही बात API दस्तावेज़ में विस्तार से लिखी है।
ऊर्जा और क़ीमत
TRON ऊर्जा क्या है?
एक नेटवर्क संसाधन, जो स्मार्ट-कॉन्ट्रैक्ट चलाने का ख़र्च उठाता है। भेजने वाले वॉलेट पर पूरी ऊर्जा हो, तो USDT ट्रांसफ़र में TRX लगभग नहीं जलता।
यह जलाने से सस्ता क्यों है?
जलाने में ऊर्जा प्रोटोकॉल की दर पर पड़ती है, ~100 sun प्रति इकाई — यह चेन का पैरामीटर है, जिसे नेटवर्क ख़ुद समय-समय पर बदलता रहता है; इस साल इसे घटाया गया। हम सौंपी जाने वाली ऊर्जा थोक में लेते हैं और उसी दर के एक अंश पर बेचते हैं; इस समय लागू क़ीमत क़ीमतों वाले पन्ने पर है।
सारी क़ीमतें देखें →
भेजने की अवधि चूक गए तो?
mode A में कटौती बनी रहती है: ऊर्जा पहुँचा दी गई थी, और पैसा उसी पहुँचाने का है। mode B में अवधि बंद होने के बाद हम कुछ भी नहीं भेजते, इसलिए वह हिस्सा नाकाम होकर बंद होता है और रोकी गई पूरी राशि लौट आती है। अवधि हर ऑर्डर के साथ आती है — अपना फ़्लो उसी के हिसाब से बनाएँ।
क्या मैं एक वॉलेट के लिए थोक में ऊर्जा ख़रीद सकता हूँ?
एक ऑर्डर में एक वॉलेट के लिए 65,000 से 50,000,000 तक ऊर्जा इकाइयाँ, ऑर्डर बनते समय लागू क़ीमत पर प्रति इकाई हिसाब से। हर वॉलेट के लिए एक ही स्थिति, और बाज़ार अभी इसी वक़्त इस मात्रा का कितना हिस्सा भर सकता है, यह कुछ भी रोके बिना POST /v1/estimate से मुफ़्त में पूछा जा सकता है।
131,000 इकाइयों से ऊपर किराया अवधि 1 घंटा या उससे लंबी होनी चाहिए। ऑर्डर ऑल-या-नथिंग होगा या नहीं, यह पहली ख़रीद से पहले ही तय हो जाता है (allow_partial); पहली ख़रीद के बाद की कमी भी पहुँचाई जाती है, और जितना पहुँचाया गया उतने का ही बिल बनता है।
क़ीमतों वाले पन्ने पर थोक ऊर्जा →
भेजने की अवधि चूकने की क़ीमत दोनों मोड में एक जैसी है?
नहीं। mode A में ऊर्जा पहुँचा दी गई थी, इसलिए कटौती बनी रहती है — और mode C में भी, जहाँ किसी ट्रांसफ़र का इंतज़ार ही नहीं है और अवधि बंद होते ही वह हिस्सा बस ख़त्म हो जाता है। mode B में अवधि बंद होने के बाद हम भेजते ही नहीं: देर से गया ट्रांसफ़र उस वॉलेट से टकराता जिससे सौंपी हुई ऊर्जा हट चुकी है, और आपका TRX जला देता। वह हिस्सा failed होकर broadcast_window_missed के साथ बंद होता है, रोकी गई पूरी राशि लौट आती है, और उसके लिए ख़रीदी गई ऊर्जा हमारा नुक़सान है।
पैसा और वापसी
भुगतान कैसे करें?
पहले से चुकाए हुए सेवा क्रेडिट, TRX में गिने जाते हैं: अपने निजी पते पर TRX भेजें, सेवाओं पर ख़र्च करें। क़ीमत ऑर्डर बनते ही तय हो जाती है।
जमा पते पर कौन सा टोकन भेज सकते हैं?
TRX, और सिर्फ़ TRX। जमा पते पर आया USDT अपने आप खाते में नहीं चढ़ता: हम विनिमय दर का जोखिम नहीं लेते और बदलने की सेवा नहीं चलाते, इसलिए ऐसा ट्रांसफ़र आदमी के देखने के लिए अलग रख दिया जाता है, और उसे जमा करना या न करना हर मामले में हमारा फ़ैसला है। ग़लत टोकन भेज दिया? हमें लिखिए, और आगे मत भेजिए।
जमा राशि कितनी जल्दी ख़र्च की जा सकती है?
3 पुष्टियों के बाद — लगभग दस सेकंड। उसके बाद बैलेंस तीन हिस्सों में दिखता है: कुल, चालू ऑर्डरों के लिए रोका हुआ, और उपलब्ध। ऑर्डर उपलब्ध हिस्से से बनता है, कुल से नहीं।
क्या ऑर्डर रद्द किया जा सकता है?
सिर्फ़ ख़रीद शुरू होने से पहले; उसके बाद जवाब order_not_cancelable होता है, क्योंकि ऊर्जा ख़रीदी जा चुकी है। रद्द हुआ ऑर्डर अपनी पूरी रोकी गई राशि छोड़ देता है और कुछ भी नहीं काटता।
पैसे वापसी का क्या?
वापसी अपने आप होती है और उसके लिए कभी कोई टिकट नहीं लगता। नियम एक ही है: जो ऊर्जा हमने नहीं पहुँचाई, उसका पैसा नहीं लेते, और रोकी गई राशि आपके बैलेंस में लौट आती है — नाकाम डिलीवरी, ख़रीद शुरू होने से पहले रद्द किया गया ऑर्डर, Auto-refill के दिन का बिना ख़र्च हुआ हिस्सा। पहुँचाई गई ऊर्जा का शुल्क लगता है, आपने उसे इस्तेमाल किया हो या नहीं। एक अपवाद: किसी Auto-refill नियम को, उसकी भराई द्वारा वॉलेट के लिए सप्लायर को पहले से चुकाई गई रकम पूरी करने से पहले, हटाने पर जो हिस्सा पूरा नहीं हुआ उसका शुल्क लगता है।
सुरक्षा और कुंजियाँ
आपको कौन सी कुंजियाँ चाहिए?
कोई नहीं। mode A आपका लेन-देन कभी देखता ही नहीं। mode B वही लेता है जिस पर आप पहले हस्ताक्षर कर चुके हैं, और उसका एक बाइट भी हम बदल नहीं सकते।
क्या आप मल्टीसिग भेजने वाला स्वीकार करते हैं?
mode B में नहीं: लेन-देन पर ठीक एक मालिक का हस्ताक्षर होना चाहिए, Permission_id 0 के साथ। मल्टीसिग खाते की कुंजियाँ नेटवर्क पर रहती हैं और हमें बताए बिना बदलती हैं, इसलिए हम यह वादा नहीं कर सकते कि प्रसारण स्वीकार होगा। mode A में आप कैसे हस्ताक्षर करते हैं, यह हम तक पहुँचता ही नहीं — ट्रांसफ़र आप खुद भेजते हैं।
आप क्या रखते हैं, और कितने समय तक?
mode B में आपका हस्ताक्षरित लेन-देन एन्क्रिप्टेड रहता है और ऑर्डर के अंतिम स्थिति तक पहुँचने के 7 दिन बाद मिटा दिया जाता है। ऑर्डर, खाता-बही की प्रविष्टियाँ और जमा रह जाते हैं: यह हिसाब-किताब है, और इसे रखना हमारी बाध्यता है। आपका और कुछ यहाँ नहीं है — न निजी कुंजियाँ, न सीड वाक्यांश, न आपके पैसे की हिफ़ाज़त।
इंटीग्रेशन
क्या कोई सीमाएँ हैं?
हर कुंजी पर एक मिनट में 120 ऑर्डर, और एक बैच ऑर्डर में 500 ट्रांसफ़र तक। सीमा पार होने पर आपको Retry-After मिलता है, चुपचाप गिरा दिया जाना नहीं।
completed का असल मतलब क्या है?
यह कि ऊर्जा पहुँचा दी गई — यह नहीं कि आपका ट्रांसफ़र चला गया। वादा डिलीवरी का है, ऑर्डर उसी पर बंद होता है, इसलिए mode A में completed तब भी आ सकता है जब आपने कुछ भेजा ही न हो। ऑर्डर में send_before के आने पर नज़र रखिए, ready शब्द पर नहीं: हर दो सेकंड पर पूछते हुए ready शायद एक बार भी न दिखे।
idempotency कैसे काम करती है?
Idempotency-Key उस बॉडी के कच्चे बाइट से बँधी होती है जिसके साथ वह आई थी। वही कुंजी और बाइट-दर-बाइट वही बॉडी — वही ऑर्डर वापस मिलता है; वही कुंजी और दूसरी बॉडी — टकराव; जाँच में लौटाया गया अनुरोध कुंजी ख़र्च नहीं करता, इसलिए बॉडी ठीक करके उसी कुंजी से दोबारा भेजा जा सकता है। बॉडी एक ही बार सीरियलाइज़ कीजिए और वही बाइट दोबारा भेजिए — कुंजियों का दूसरा क्रम या एक अतिरिक्त स्पेस पहले ही से दूसरी बॉडी है।
क्या बिना कुछ चुकाए पता जाँचा जा सकता है?
हाँ, और मुफ़्त। GET /v1/address-check बताता है कि किसी वॉलेट के बारे में हम क्या जानते हैं, और POST /v1/estimate उन्हीं नियमों से 500 तक प्राप्तकर्ताओं की क़ीमत लगाता है जिनसे ऑर्डर लगाता — इसमें यह भी कि उनमें से किन्हें टोकन अनुबंध ने काली सूची में डाला है। दोनों में से कोई न कुछ रोकता है, न कुछ काटता है।
आपका खाता
क्या वॉलेट खुद ही भरा रह सकता है?
हाँ — एक Auto-refill नियम: एक पता और एक दैनिक बजट। हर ट्रांसफ़र के बाद ऊर्जा फिर भर जाती है; बजट रोज़ की सख़्त छत है।
balance.low किस पर सेट करें?
यह संख्या आपकी अपनी सेटिंग है — PATCH /v1/settings में balance_low_threshold_trx; balance.low वह घटना है जो उसी पर आती है। काम की माप लगभग आपके एक दिन के कारोबार जितनी है: तब चेतावनी ऑर्डरों को insufficient_balance मिलने से एक दिन पहले आएगी, पहली अस्वीकृति की जगह नहीं। ख़ासा कम रखा तो घटना बाद की सूचना बन जाती है, ख़ासा ज़्यादा रखा तो शोर। शून्य उसे बंद कर देता है।
क्या मेरी ऑप्स टीम को सिर्फ़ पढ़ने की पहुँच मिल सकती है?
हाँ। एक अकाउंट में आप जितने लोगों को बुलाएँ उतने समा सकते हैं, हर एक चार भूमिकाओं में से एक के साथ — viewer, member, admin, owner — और हर भूमिका वह सब करती है जो पिछली करती थी। viewer बैलेंस, लेजर, ऑर्डर और क़ीमत पढ़ सकता है और कुछ भी ख़र्च नहीं कर सकता; member ऑर्डर और अनुमान बनाता है; admin API कुंजियाँ, webhooks, सेटिंग्स और टीम संभालता है; owner ख़ुद अकाउंट है। एक न्योता viewer, member या admin बनाता है; owner ख़ुद अकाउंट है और उसे न्योता नहीं दिया जाता। न्योते और भूमिकाएँ डैशबोर्ड में रहती हैं, और सिर्फ़ डैशबोर्ड पर ही चलती हैं: एक API कुंजी अकाउंट की होती है, किसी व्यक्ति की नहीं, और उसे किसी ने भी बनाया हो, उसके पास पूरी पहुँच होती है।
कोई सैंडबॉक्स है, या न्यूनतम वॉल्यूम?
न न्यूनतम वॉल्यूम, न सब्सक्रिप्शन, न ख़ाली बैठने का शुल्क। सैंडबॉक्स है: https://sandbox.nrg.market/v1 वही API है, टेस्ट पैसे और सिम्युलेटेड नेटवर्क पर, और उसकी nrg_test_… कुंजियाँ sandbox-app.nrg.market जारी करता है। यह आपकी तरफ़ का इंटीग्रेशन साबित करता है — रिक्वेस्ट का ढाँचा, स्टेटस, webhooks, समय — पर यह नहीं कि ऊर्जा on-chain पहुँचती है; वह प्रोडक्शन में ही पता चलता है। चालू होस्ट पर संदर्भ एंडपॉइंट, अनुमान और webhook की जाँच अब भी कुछ नहीं लेते।
https://sandbox.nrg.market/v1
sandbox-app.nrg.market