टोकन approvals और allowance: ERC-20 अनुमति कैसे जाँचें और रद्द करें

किसी साइट से वॉलेट जोड़ने पर ऐप आम तौर पर सार्वजनिक पता देख सकता है और हस्ताक्षर माँग सकता है। इससे उसे सभी ERC-20 टोकन ले जाने का अधिकार अपने आप नहीं मिलता। allowance टोकन कॉन्ट्रैक्ट में अलग से दर्ज होती है। MetaMask भी dapp डिस्कनेक्ट करने और token approval रद्द करने को अलग बताता है।

ERC-20 allowance टोकन कॉन्ट्रैक्ट, नेटवर्क, मालिक के पते और spender के पते से जुड़ी होती है। Ethereum पर दी गई अनुमति Polygon पर उसी नाम वाले टोकन या किसी दूसरे टोकन की अनुमति नहीं है। केवल “मैंने साइट को मंज़ूरी दी थी” याद रखने से यह छूट सकता है कि किस नेटवर्क पर किस टोकन की अनुमति अभी सक्रिय है।

यह मार्गदर्शिका Ethereum और संगत नेटवर्क पर ERC-20 approve, allowance और transferFrom तक सीमित है। native ETH ट्रांसफर, NFT का setApprovalForAll, अन्य मानक और वॉलेट लॉगिन कनेक्शन अलग नियमों पर चलते हैं। कुंजी के बैकअप और पुनर्प्राप्ति के लिए seed phrase और wallet recovery guide देखें।

मालिक टोकन कॉन्ट्रैक्ट में approve(spender, amount) बुलाकर किसी खास spender को एक सीमा तक टोकन इस्तेमाल करने दे सकता है। transferFrom spender को मालिक की ओर से टोकन स्थानांतरित करने देता है। इसलिए approve आम तौर पर उसी समय बैलेंस नहीं बदलता, लेकिन बाद की कॉन्ट्रैक्ट कॉल allowance खर्च कर सकती है। यही ERC-20 मानक का तरीका है।

उदाहरण के लिए, वॉलेट में 300 टोकन हैं और एक router को 80 की allowance दी जाती है। सामान्य ERC-20 में शेष allowance और बैलेंस में जो कम हो वही सीमा होती है। अनुमति एक ही ट्रेड तक सीमित होना जरूरी नहीं; कॉन्ट्रैक्ट कई बार transferFrom बुला सकता है। स्वीकृत कॉन्ट्रैक्ट या उसके तय रास्ते का दुरुपयोग होने पर टोकन आपकी अपेक्षा से अलग तरीके से जा सकते हैं। टोकन का गैर-मानक व्यवहार भी जाँचें।

Approval आम तौर पर टोकन कॉन्ट्रैक्ट को भेजा गया ऑन-चेन ट्रांज़ैक्शन होता है और नेटवर्क शुल्क लग सकता है। कुछ ऐप approval और swap अलग रखते हैं; कुछ हस्ताक्षरित अनुमति को बाद के ट्रांज़ैक्शन के साथ जोड़ते हैं। “Approve” बटन के नाम से नहीं, वॉलेट की वास्तविक हस्ताक्षर माँग और चुने नेटवर्क से निर्णय लें।

“Unlimited” अक्सर टोकन के अधिकतम पूर्णांक के करीब allowance दिखाता है। इससे असीमित टोकन नहीं बनते और approval के समय बैलेंस ट्रांसफर नहीं होता। लेकिन उसी नेटवर्क पर उसी टोकन के भविष्य में आने वाले बैलेंस पर भी spender बची हुई अनुमति इस्तेमाल कर सकता है। कुछ कॉन्ट्रैक्ट अधिकतम allowance को खर्च के बाद घटाते नहीं; टोकन का व्यवहार जाँचें।

बार-बार approval से बचने के लिए ऐप बड़ी सीमा माँग सकता है, पर सुविधा और जोखिम दोनों देखें। spender कॉन्ट्रैक्ट की कमजोरी या उसके नियंत्रण के दुरुपयोग से पुरानी अनुमति बाद में काम आ सकती है। Ethereum.org की revoke guide बताती है कि टोकन वापस वॉलेट में लाने के बाद भी बड़ी allowance जोखिम बनी रह सकती है।

छोटी सीमा हर जोखिम दूर नहीं करती। नकली टोकन या गलत spender को अनुमति देने से छोटी रकम भी खो सकती है; हर बार दोबारा approval देने से शुल्क और गलती की संभावना बढ़ती है। नियोजित मात्रा, उपयोग की आवृत्ति, कॉन्ट्रैक्ट पर भरोसा और बाद में अनुमति जाँचने की क्षमता पर विचार करें।

हस्ताक्षर से पहले चार बातें मिलाएँ: चुना नेटवर्क ऐप के निर्देश से मेल खाता है या नहीं; टोकन कॉन्ट्रैक्ट का पता सही है या नहीं, केवल ticker नहीं; spender पता परियोजना के आधिकारिक दस्तावेज़ या जाँचे जा सकने वाले कॉन्ट्रैक्ट डेटा से मेल खाता है या नहीं; और सीमा नियोजित काम के अनुपात में है या लंबे समय की बड़ी अनुमति छोड़ती है।

DM, QR कोड, सपोर्ट चैट या अप्रमाणित विज्ञापन के लिंक से वॉलेट न जोड़ें। फ़िशिंग साइट असली ऐप जैसी दिख सकती है। सहेजे गए आधिकारिक पते या परियोजना के दस्तावेज़ से शुरू करें। पहचाना हुआ कॉन्ट्रैक्ट नाम पता सही होने का सबूत नहीं; block explorer का verified चिह्न भी सुरक्षा की गारंटी नहीं है।

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

कुछ ERC-20 ERC-2612 permit का समर्थन करते हैं। सामान्य approve ट्रांज़ैक्शन भेजने के बजाय मालिक typed data पर हस्ताक्षर करता है; कोई दूसरा पक्ष वह हस्ताक्षर जमा करके allowance सेट कर सकता है। मानक संदेश में मालिक, spender, रकम, nonce और deadline होते हैं और domain हस्ताक्षर को नेटवर्क तथा कॉन्ट्रैक्ट से जोड़ता है।

ERC-2612 का deadline हस्ताक्षरित permit जमा करने की अंतिम समय सीमा है। इसका मतलब यह नहीं कि सफलतापूर्वक सेट allowance उसी समय अपने आप समाप्त होगी। वह इस्तेमाल, बदलाव या रद्द होने तक बनी रह सकती है। कुछ टोकन अलग permit तरीके या अतिरिक्त समाप्ति नियम अपनाते हैं; हर “permit” अनुरोध को ERC-2612 न मानें।

हस्ताक्षर किसी दूसरे खाते को शुल्क देने दे सकता है, पर इसलिए वह केवल सुरक्षित login पुष्टि नहीं बन जाता। यदि वॉलेट टोकन, spender, रकम और समय की शर्त साफ़ न दिखाए या ऐप के वर्णन से मेल न खाए, अस्वीकार करें और आधिकारिक दस्तावेज़ देखें। अभी जमा न किया गया हस्ताक्षर भी deadline से पहले कोई और जमा कर सकता है।

लॉगआउट या वॉलेट डिस्कनेक्ट ब्राउज़र सत्र या कनेक्शन की अनुमति बदलता है। टोकन कॉन्ट्रैक्ट में दर्ज ERC-20 allowance बनी रह सकती है। उलट, allowance रद्द करने से साइट को पता चला सार्वजनिक पता या पुराना ऑन-चेन इतिहास नहीं मिटता। MetaMask की disconnect guide यह अंतर बताती है।

रद्द करने के लिए आम तौर पर ऑन-चेन ट्रांज़ैक्शन से उस टोकन और spender की allowance शून्य करनी होती है। नेटवर्क शुल्क लगता है और पुष्टि तक पुरानी अनुमति सक्रिय रह सकती है। फिर approval सूची ताज़ा करें या कॉन्ट्रैक्ट दोबारा पढ़कर उसी वॉलेट, नेटवर्क, टोकन और spender के लिए शून्य की पुष्टि करें। MetaMask और Ethereum.org नेटवर्क-विशिष्ट जाँच बताते हैं; आधिकारिक domain और चुना नेटवर्क जाँचें।

हर नेटवर्क की स्थिति अलग होती है। Ethereum पर शून्य करने से दूसरे नेटवर्क पर उसी टोकन की अनुमति नहीं बदलती। संबंधित हर खाते, टोकन कॉन्ट्रैक्ट, spender और नेटवर्क की जाँच करें और ट्रांज़ैक्शन की पुष्टि के बाद परिणाम दोबारा देखें। Revoke टूल को seed phrase या निजी कुंजी की जरूरत नहीं होनी चाहिए।

शून्य allowance की पुष्टि के बाद वही अधिकार नया transferFrom नहीं करा सकता। लेकिन यह पूरे हो चुके ट्रांसफर वापस नहीं करता, प्राप्तकर्ता से टोकन नहीं लौटाता और दूसरे कॉन्ट्रैक्ट के अधिकार नहीं हटाता। संदिग्ध spender ने टोकन पहले ही हटा दिए हों तो revoke करने से वापसी की गारंटी नहीं मिलती।

यदि वॉलेट की निजी कुंजी उजागर हो, हमलावर दूसरे तरीके से भी ट्रांज़ैक्शन साइन कर सकता है। दूसरे spender या टोकन की मंज़ूरियाँ, NFT operator अधिकार, permit signature और कॉन्ट्रैक्ट-विशिष्ट अनुमति भी बची रह सकती हैं। परिणाम को उसी वॉलेट और नेटवर्क के दायरे में समझें जिसे आपने जाँचा।

रद्द करने के बाद अगली swap, deposit या redemption के लिए नई मंज़ूरी देनी पड़ सकती है। पहले देखें कि pending transaction या active position उस अधिकार पर निर्भर तो नहीं; जरूरत हो तो प्रोटोकॉल की आधिकारिक सहायता देखें। जानें कि अगली कार्रवाई में क्या बदलेगा।

ERC-20 मानक सलाह देता है कि UI मौजूदा nonzero allowance को किसी दूसरे nonzero मान में बदलने से पहले शून्य करे। पुरानी और नई मंज़ूरी के बीच spender का ट्रांज़ैक्शन आ जाए तो वह अपेक्षा से अधिक इस्तेमाल कर सकता है। उदाहरण: 100 से 25 पर बदलते समय spender नया 25 दर्ज होने से पहले पुराना 100 खर्च करे, फिर नया 25 भी इस्तेमाल कर सकता है।

पहले शून्य की पुष्टि करने से पुराने और नए मान के एक साथ उपलब्ध होने की संभावना घटती है, लेकिन शून्य ट्रांज़ैक्शन की पुष्टि से पहले पुरानी allowance के उपयोग को पलटा नहीं जा सकता। दोनों चरणों पर शुल्क लग सकता है और टोकन का व्यवहार अलग हो सकता है। वॉलेट या टोकन की आधिकारिक सुरक्षित प्रक्रिया अपनाएँ और अगला चरण पुष्टि के बाद करें।

मौजूदा allowance पता न हो तो बदलने से पहले चुने नेटवर्क पर टोकन कॉन्ट्रैक्ट देखें। मान खाली या अप्रत्याशित हो तो जाँचें कि कहीं दूसरा नेटवर्क या पता तो नहीं देख रहे। मालिक का पता और टोकन कॉन्ट्रैक्ट दोनों सही होने चाहिए।

1. परियोजना का आधिकारिक domain और चुना नेटवर्क पक्का करें।
2. टोकन कॉन्ट्रैक्ट और spender पते जाँचें; सीमा को नियोजित मात्रा से मिलाएँ।
3. वॉलेट में दिखा वास्तविक ट्रांज़ैक्शन या typed data पढ़ें। न समझ आए तो हस्ताक्षर न करें।
4. सही नेटवर्क पर उन spenders की allowance देखें जिन्हें अब इस्तेमाल या भरोसा नहीं करते; जरूरी हो तो शून्य करें और परिणाम जाँचें।
5. वॉलेट तुलना में नेटवर्क समर्थन के साथ यह भी देखें कि approval कितनी साफ़ दिखती है और अपडेट/रिकवरी निर्देश कितने समझने योग्य हैं।

Hardware wallet कुंजी रखने और हस्ताक्षर जाँचने का एक विकल्प है, कॉन्ट्रैक्ट सुरक्षा की गारंटी या बड़ी सीमा मंज़ूर करने से रोकने वाला साधन नहीं। spender, token, network और रकम स्वयं जाँचें। यह समझना कि allowance साइट कनेक्शन से अलग रह सकती है, वॉलेट सुरक्षा सुविधाओं और उनकी वास्तविक सीमाओं की तुलना में मदद करता है।