क्रिप्टोकरेंसी उपयोगकर्ताओं के बीच एक व्यापक धारणा है: अगर आप सही पता डालते हैं, सही नेटवर्क चुनते हैं, और फीस कवर करने के लिए पर्याप्त नेटिव टोकन होता है, तो लेनदेन हो जाएगा। अधिकांश मामलों में यह धारणा सही भी रहती है।
लेकिन हर ब्लॉकचैन के अपने छिपे नियम होते हैं — ऐसे नियम जो केवल बहुत विशिष्ट परिस्थितियों में ही सतह पर आते हैं। और जब वे आते हैं, तो एक लेनदेन असफल हो सकता है भले ही आपकी दृष्टि से सब कुछ सही किया गया हो।
यही हमारे साथ हुआ जब हमारे स्वैपिंग सर्विस के एक ग्राहक ने Rabbit.io के माध्यम से LTC को SOL में स्वैप किया। राशि बहुत छोटी थी — 0.0003 SOL से भी कम, जो वर्तमान कीमतों पर तीन सेंट से कम है। मैंने अपनी कई पिछली सामग्री में बताया है कि हम स्वैप पर ऊपरी सीमा नहीं लगाते। हाँ, हम अक्सर बेहद छोटी राशियाँ भी प्रोसेस करते हैं।
जब हमने अनुरोधित SOL भेजने की कोशिश की, तो हमें समस्या का सामना करना पड़ा। पता सही था। नेटवर्क Solana Mainnet था। हमारा बैलेंस पर्याप्त था। फीस भी ध्यान में रखी गई थी। फिर भी लेनदेन बार-बार फेल हो रहा था।
विवरण हमारे लिए भी अप्रत्याशित निकला। और जब हमने इसे क्लाइंट के साथ साझा किया, तो उसने शुरू में विश्वास नहीं किया। इस घटना ने मुझे सोचने पर मजबूर किया: कितने ऐसे छिपे पिटफॉल विभिन्न ब्लॉकचेन पर मौजूद हैं?
मैंने जांच करने और सबसे रोचक उदाहरणों को संकलित करने का निर्णय लिया — वे मामले जो मुझे भी हैरान कर सकते हैं, भले ही मैं रोज़ाना कई प्रकार के क्रिप्टो एक्सचेंज प्रोसेस करता हूँ।
1. Solana. "रेंट" देना — यहाँ तक कि नेटिव SOL के लिए भी
यह आश्चर्यजनक क्यों है
बहुत से लोगों ने सुना होगा कि Solana पर, ऐसे पते जो पहले कभी किसी SPL टोकन (जैसे USDT, USDC आदि) को होल्ड नहीं करते, उन्हें उन टोकन प्राप्त करने के लिए थोड़े से SOL की आवश्यकता होती है। सख्ती से कहें तो यह पूरी तरह सटीक नहीं है, पर इसमें कुछ सच्चाई है।
प्रत्येक टोकन एक अलग Associated Token Account (ATA) में स्टोर होता है, और वह अकाउंट बनवाने का लागत लगभग 0.002 SOL होती है। हालाँकि, यदि रिसीवर का बैलेंस शून्य भी हो, तो टोकन प्राप्त किए जा सकते हैं — क्योंकि ATA बनाने की लागत भेजने वाले द्वारा चुकाई जाती है, रिसीवर द्वारा नहीं।
कम ही लोग जानते हैं कि कभी-कभी इसी तरह की शर्त नेटिव SOL के ट्रांसफर पर भी लागू हो सकती है। यही हमारे साथ हुआ जब हमने क्लाइंट द्वारा अनुरोधित बहुत छोटी राशि भेजने की कोशिश की।
यह मैकेनिज़्म कैसे काम करता है
Solana पर, एक अकाउंट सिर्फ एक स्ट्रिंग नहीं है जो एड्रेस दर्शाती हो। यह ब्लॉकचेन की वर्तमान स्टेट में एक वास्तविक रिकॉर्ड है। वह रिकॉर्ड वेलीडेटर्स के नोड्स पर डिस्क स्पेस घेरता है — और स्टोरेज मुफ्त नहीं है।
यह मैकेनिज्म रेंट-एक्सेम्प्शन (rent exemption) के नाम से जाना जाता है। किसी अकाउंट के अस्तित्व के लिए उसका बैलेंस एक निश्चित न्यूनतम से अधिक होना चाहिए — व्यवहार में यह दो साल के स्टोरेज रेंट की लागत के बराबर होता है।
यह मान हमेशा के लिए तय नहीं रहता, लेकिन इस समय, एक बेसिक सिस्टम अकाउंट (साधारण वॉलेट) के लिए न्यूनतम 890,880 lamports है, या 0.00089088 SOL।
अगर किसी पते का ऑन-चेन अस्तित्व अभी तक नहीं है (यानी उसका बैलेंस शून्य है), तो पहली ट्रांज़ैक्शन जो उस अकाउंट को इस थ्रेशहोल्ड से कम राशि के साथ बनाने का प्रयास करेगी, उसे रिजेक्ट कर दिया जाएगा।
यही हमारे केस में हो रहा था। हम ब्रांड-न्यू पते पर लगभग 0.0003 SOL भेज रहे थे — जो आवश्यक थ्रेशहोल्ड से लगभग तीन गुना कम था। हमारे क्लाइंट को शुरू में इस नियम के अस्तित्व पर विश्वास नहीं हुआ। और ईमानदारी से कहूँ तो हमें Solana की आधिकारिक डॉ큐मेंटेशन में इसका कोई स्पष्ट बयान खोजना भी कठिन लगा। जो एक अप्रत्यक्ष पुष्टि मिली वह RPC मेथड getMinimumBalanceForRentExemption के विवरण में थी, जो इस नियम का संकेत देती है — हालांकि वह इसे स्पष्ट रूप से नहीं गढ़ती।
यहाँ एक महत्वपूर्ण सूक्ष्मता है। हमने पहले भी कई बार ग्राहकों को इतनी छोटी राशियाँ भेजी हैं बिना किसी परेशानी के। प्रैक्टिकल अनुभव से हमें पता था कि Solana अनिवार्य रूप से किसी भी छोटी राशि के ट्रांसफर की अनुमति देता है।
और यह सत्य है — लेकिन केवल तब जब रिसीवर अकाउंट पहले से मौजूद हो। अगर यह दूसरा, तीसरा या सौवा इनकमिंग ट्रांज़ैक्शन है, तो पता 1 lamport भी प्राप्त कर सकता है। लेकिन जब अकाउंट पहली बार बनाया जा रहा हो, तो रेंट-एक्सेम्प्शन की जांच लागू होती है।
2. XRP Ledger और Stellar. पता मौजूद है — पर अकाउंट नहीं
Solana पर जो समस्या हमने देखी वह वास्तव में एक व्यापक पैटर्न का विशिष्ट मामला है। कई नेटवर्क में, एक एड्रेस क्रिप्टोग्राफिक ऑब्जेक्ट है और एक अकाउंट डिस्ट्रिब्यूटेड लेज़र में एक एंट्री है — ये दोनों अलग चीजें हैं। बिना किसी न्यूनतम प्रारंभिक बैलेंस के, अकाउंट बस मौजूद नहीं होता।
XRP Ledger पर, हर नए अकाउंट को कम से कम 1 XRP का रिज़र्व प्राप्त करना आवश्यक है। नेटवर्क के शुरुआती दिनों में यह आवश्यकता बहुत अधिक थी — लॉन्च पर 200 XRP, बाद में घटाकर 50 XRP, फिर 20, फिर 10 किया गया। जैसे-जैसे XRP की कीमत बढ़ी, यह रिज़र्व धीरे-धीरे घटाकर वर्तमान 1 XRP कर दिया गया।
यह रिज़र्व अकाउंट में स्थायी रूप से लॉक रहता है। इसे खर्च नहीं किया जा सकता। इसे ट्रांज़ैक्शन फीस भुगतान के लिए उपयोग नहीं किया जा सकता। कुछ XRP Ledger एक्सप्लोरर कुल बैलेंस और लॉक्ड रिज़र्व को अलग-अलग दिखाते भी हैं, ताकि वॉलेट मालिक स्पष्ट रूप से देख सकें कि वास्तव में खर्च के लिए कितना XRP उपलब्ध है।
Stellar नेटवर्क भी इसी लॉजिक का पालन करता है। जब तक एक पता न्यूनतम बैलेंस प्राप्त नहीं करता, वह लेज़र में मौजूद नहीं होता। एक Stellar अकाउंट को सक्रिय और ऑपरेशनल रहने के लिए कम-से-कम 1 XLM की आवश्यकता होती है।
आपको याद होगा कि मैंने एक बार एक त्रुटि के बारे में लिखा था जिसने 1,000 USDC को 1 XLM में बदल दिया। उस आलेख में वर्णित स्थिति ठीक इसी मैकेनिज़्म का उदाहरण थी: एक टोकन ट्रांज़ैक्शन, भले ही भेजने वाले द्वारा सही ढंग से साइन किया गया हो, रिसीवर के खाते में तभी क्रेडिट हो सकता है जब कुछ पूर्व-शर्तें पूरी हों।
XRP Ledger और Stellar दोनों की एक विशेषता यह है कि कोई अकाउंट तब तक किसी टोकन को प्राप्त नहीं कर सकता जब तक उसने स्पष्ट रूप से उस विशिष्ट एसेट के साथ इंटरैक्ट करने के लिए "ऑप्ट-इन" नहीं किया हो। यह डेवलपर्स द्वारा लिया गया जानबूझकर डिज़ाइन निर्णय है, और इसके फायदे भी हैं।
अन्य नेटवर्कों पर, व्हेल और सेलिब्रिटी पते अक्सर नए बनाए गए स्पैम टोकंस से भर जाते हैं, जिससे ऐसा भ्रम होता है कि पता मालिक ने उन्हें खरीदा है। XRP Ledger और Stellar पर ऐसा स्पैम असंभव है — क्योंकि किसी एसेट को प्राप्त करने के लिए पूर्व अनुमति आवश्यक है।
3. Lightning Network. लिक्विडिटी मौजूद है — पर रूट नहीं
Lightning Network पेमेंट चैनलों का एक नेटवर्क है जो बिटकॉइन भेजने के लिए डिज़ाइन किया गया है बिना हर ट्रांसफर को ब्लॉकचेन पर रिकॉर्ड किए। सामान्य ऑन-चेन ट्रांज़ैक्शनों के विपरीत, एक Lightning पेमेंट को पूरे नेटवर्क के नोड्स द्वारा वैलिडेट नहीं किया जाता और न ही खनिकों द्वारा ब्लॉक में कन्फर्म किया जाता है। इसके बजाय, यह मध्यवर्ती नोड्स की एक चेन के माध्यम से यात्रा करता है।
और यहीं एक पूरी श्रेणी के गैर-स्वाभाविक त्रुटियाँ सामने आती हैं।
रूटिंग कैसे काम करती है
एक पेमेंट को Alice से David तक Bob और Carol जैसे मध्यवर्ती नोड्स के माध्यम से जाने के लिए, रूट के हर सेगमेंट में आवश्यक दिशा में पर्याप्त लिक्विडिटी होनी चाहिए।
नेटवर्क हर चैनल की कुल क्षमता जानता है, पर यह नहीं जानता कि बैलेंस दोनों पक्षों में कैसे विभाजित है। इससे ऐसी परिस्थितियाँ बन सकती हैं:
- David के पास Carol के साथ उसके चैनल में पर्याप्त इनबाउंड लिक्विडिटी है।
- पर Bob और Carol के चैनल में लगभग पूरा बैलेंस किस्मत से Carol की तरफ बैठा हुआ है। Bob उस दिशा में पेमेंट फार्वर्ड नहीं कर सकता।
परिणामस्वरूप, Alice से David का पेमेंट "route not found" त्रुटि के साथ फेल हो जाता है — भले ही Alice के पास पर्याप्त फंड हों, David के पास रिसीव करने में सक्षम एक सक्रिय चैनल हो, और नेटवर्क ग्राफ़ पर औपचारिक रूप से एक रूट मौजूद हो।
छिपा हुआ फीस लिमिट जाल
एक और विशेष रूप से चतुर nuance है। LND में, जो कि व्यापक रूप से उपयोग किए जाने वाले Lightning नोड इम्प्लिमेंटेशन्स में से एक है, डिफ़ॉल्ट रूटिंग फीस लिमिट 0 satoshis पर सेट की गई है।
इसका मतलब है कि नोड केवल पूरी तरह मुफ्त रूट्स ही खोजने की कोशिश करेगा — जो एक वास्तविक नेटवर्क में व्यावहारिक रूप से मौजूद नहीं होते। उपयोगकर्ता जिन्होंने कभी यह डिफ़ॉल्ट सेटिंग बदली नहीं, वे बार-बार "route not found" त्रुटि देख सकते हैं, भले ही पेमेंट तब सफल हो जाये अगर उन्होंने थोड़ी सी रूटिंग फीस की अनुमति दी होती।
यह कोई दोष नहीं है। इसके विपरीत, LND डेवलपर्स ने जानबूझकर यह तय न करने का विकल्प चुना कि उपयोगकर्ता अधिकतम कितनी फीस देने के लिए तैयार हैं। अगर डिफ़ॉल्ट रूप से कोई सकारात्मक लिमिट सेट की गई होती, तो बाद में उपयोगकर्ता यह पाते कि रूटिंग फीस बिना उनके ज्ञान के काट ली गई हैं।
"route not found" त्रुटि के अन्य कारण:
- रिसीवर का नोड ऑफ़लाइन है, और उसके चैनल निष्क्रिय हैं।
- इनवॉइस की वैधता समाप्त हो गई है। Lightning इनवॉइसेस की सीमित वैधता अवधि होती है, अक्सर लगभग एक घंटे।
- राशि बहुत बड़ी है। बड़े पेमेंट्स को रूट करना छोटे पेमेंट्स की तुलना में कठिन होता है।
- पहले का एक प्रयास लिक्विडिटी को "स्टिक" कर चुका है। HTLC कॉन्ट्रैक्ट्स टाइम-लॉक्स के साथ टेम्पररी रूप से चैनल क्षमता को लॉक कर सकते हैं जब तक वे एक्सपायर न हो जाएँ।
हम बिटकॉइन का Lightning Network के माध्यम से एक्सचेंज करते समय इन सभी समस्याओं का सामना करते हैं। ये समस्या पारंपरिक ब्लॉकचेन ट्रांज़ैक्शनों की तुलना में असामान्य लग सकती हैं, पर इनमें से हर समस्या का समाधान है। इसलिए, Rabbit.io पर आप बिना इन पिटफॉल्स की चिंता किए बिटकॉइन Lightning Network के जरिए भेज और प्राप्त कर सकते हैं।
4. USDT और USDC. अलग आर्किटेक्चर वाली ब्लैकलिस्ट्स
USDT और USDC केंद्रीकृत रूप से प्रबंधित स्टेबलकॉइन्स हैं। उनके स्मार्ट कॉन्ट्रैक्ट्स में ब्लैकलिस्ट फ़ंक्शन्स शामिल हैं: इश्यूअर्स — Tether और Circle — किसी भी समय किसी पते को ब्लैकलिस्ट में जोड़ सकते हैं, जिसके बाद उस पते पर टोकन्स से संबंधित ऑपरेशंस असंभव हो जाते हैं।
यह एक अच्छी तरह जाना हुआ तथ्य है। जो कम समझा जाता है वह यह है कि USDT और USDC में प्रतिबंध मैकेनिज्म मूल रूप से भिन्न हैं — और यह अंतर महत्वपूर्ण व्यावहारिक परिणाम लाता है।
USDC (Circle): दोनों दिशाएँ ब्लॉक
USDC कॉन्ट्रैक्ट में, ब्लैकलिस्ट जांच दोनों — भेजने वाले और प्राप्तकर्ता — पर लागू होती है। अगर रिसीवर पता ब्लैकलिस्टेड है, तो स्मार्ट कॉन्ट्रैक्ट ट्रांज़ैक्शन को रिजेक्ट कर देगा। भेजने वाले को बस थोड़ी गैस खर्च हो जाएगी, जबकि USDC उसके वॉलेट में बने रहेंगे।
भेजने वाले के परिप्रेक्ष्य से यह एक सुरक्षित मॉडल है: फंड गायब किसी फ्रीज़ किए हुए पते में नहीं चले जाते।
USDT (Tether): केवल भेजने वाला ब्लॉक होता है
USDT कॉन्ट्रैक्ट (TetherToken) में, transfer फ़ंक्शन में निम्नलिखित चेक है: require(!isBlackListed[msg.sender]). इसका मतलब है कि केवल भेजने वाले की ब्लैकलिस्ट पर जाँच की जाती है। प्राप्तकर्ता पते की वैलिडेशन ट्रांसफर के दौरान नहीं की जाती।
व्यवहार में, इसके निम्नलिखित परिणाम होते हैं:
- आप ब्लैकलिस्टेड पते पर सफलतापूर्वक USDT भेज सकते हैं।
- ट्रांज़ैक्शन बिना त्रुटियों के गुजर जाएगा।
- ब्लॉकचेन ट्रांसफर को रिकॉर्ड कर लेगा।
- पर फंड बाद में फ्रीज़ हो जाएंगे।
न तो रिसीवर और न ही कोई और उन टोकन्स को बाद में मूव कर पाएगा — किसी ब्लैकलिस्टेड पते से आउटगोइंग ट्रांज़ैक्शन्स पर प्रतिबंध है। केवल इश्यूअर, Tether, destroyBlackFunds फ़ंक्शन का उपयोग करके ब्लैकलिस्टेड पते से टोकन्स को प्रभावी रूप से मिटा सकता है।
इस विशेष मामले में कोई तर्क कर सकता है कि सही तरीके से बनायी गयी ट्रांज़ैक्शन का सीधे फेल होना बेहतर है। USDC कॉन्ट्रैक्ट में लागू किया गया दृष्टिकोण USDT मॉडल की तुलना में अधिक पारदर्शी और निष्पक्ष प्रतीत होता है, जहाँ ट्रांज़ैक्शन सफल तो हो जाती है — पर बाद में यह स्पष्ट हो जाता है कि ट्रांसफर वास्तव में बेकार था।
मेरी सिफारिशें:
- USDT के साथ काम करते समय, भेजने से पहले काउंटरपार्टी पते को प्रतिबंध या ब्लैकलिस्ट डेटा के खिलाफ जांचें। जो पता कल "साफ" था वह आज साफ नहीं हो सकता — इसका स्टेटस सबसे खराब समय पर बदल सकता है।
- यदि संभव हो, तो Liquid ब्लॉकचेन पर USDT उपयोग करने पर विचार करें, जहाँ Tether के पास व्यक्तिगत पतों को फ्रीज़ करने की क्षमता नहीं है।
फिर भी, कभी-कभी USDT ट्रांसफर सीधे तौर पर फेल भी हो सकते हैं — भले ही सभी ट्रांज़ैक्शन डेटा सही दिखाई दे। इस लेख के भाग II में, मैं ऐसे मामलों को कवर करूँगा, साथ ही Bitcoin, Ethereum, और Tron नेटवर्क पर कम-ज्ञात ट्रांज़ैक्शन सीमाओं को भी उजागर करूँगा।
यह ठीक एक हफ़्ते में यहीं प्रकाशित होगा।
