ERC-20 की कुल आपूर्ति और वॉलेट बैलेंस: आपका आंकड़ा कौन सा है?

ERC-20 टोकन में balanceOf(account) एक खाते के लिए दर्ज बैलेंस बताता है। totalSupply() टोकन अनुबंध की कुल आपूर्ति बताता है। टोकन पेज पर बड़ी आपूर्ति दिखने का मतलब आपके खाते में बड़ी होल्डिंग होना नहीं है।

अपनी होल्डिंग जांचने के लिए एक्सप्लोरर खोला है, तो खाते का बैलेंस चुनें। अनुबंध कुल कितनी इकाइयां बताता है, यह जांचने के लिए आपूर्ति चुनें। अकेला कोई भी आंकड़ा डॉलर मूल्य नहीं बताता, पते पर नियंत्रण साबित नहीं करता और टोकन की सुरक्षा स्थापित नहीं करता।

एक अनुबंध, दो अलग सवाल

ERC-20 विनिर्देश इन्हें अलग केवल पढ़ने वाली विधियों के रूप में परिभाषित करता है। totalSupply() में खाते का इनपुट नहीं होता। balanceOf को उस पते की जरूरत होती है जिसका बैलेंस आप जांचना चाहते हैं। जिस टोकन अनुबंध को कॉल करते हैं, वही तय करता है कि आप किस परिसंपत्ति के बारे में पूछ रहे हैं।

पढ़ा जाने वाला मान	टोकन अनुबंध के अलावा इनपुट	किस सवाल का जवाब
totalSupply()	कोई नहीं	यह अनुबंध कितनी आपूर्ति बताता है?
balanceOf(account)	सार्वजनिक खाते का पता	इस खाते के लिए कितना बैलेंस दर्ज है?

मसलन, एक टोकन की आपूर्ति 1,000 इकाइयां है, जिनमें से खाता A के पास 25 हैं। सही परिणाम आपूर्ति के लिए 1,000 और खाता A के लिए 25 होंगे। यह अंतर स्वाभाविक है। वापस पाने के लिए कोई 975 इकाइयों की होल्डिंग गायब नहीं हुई है।

ये समझाने के लिए बनाए गए आंकड़े हैं, किसी सक्रिय टोकन से पढ़े गए मान नहीं। कौन सा पता खाते का है और कौन सा परिसंपत्ति का, इस पर संदेह हो तो कोई भी फ़ील्ड पढ़ने से पहले वॉलेट पते और टोकन अनुबंध की मार्गदर्शिका देखें।

बैलेंस और आपूर्ति किससे बदलते हैं?

एक सरल काल्पनिक टोकन लें, जिसमें बिना शुल्क या विशेष लेखांकन के सामान्य ट्रांसफ़र होते हैं। शुरुआत में खाता A में 25 और खाता B में 975 टोकन हैं:

घटना	खाता A	खाता B	कुल आपूर्ति
शुरुआती स्थिति	25	975	1,000
A ने B को 5 भेजे	20	980	1,000
B के लिए 100 नए टोकन जारी हुए	20	1,080	1,100
B ने बर्न फ़ंक्शन से 10 जलाए	20	1,070	1,090

ट्रांसफ़र बदलता है कि इकाइयां किसके पास हैं। मिंटिंग नई इकाइयां बनाती है और उदाहरण में दिखाए तंत्र से बर्न करने पर इकाइयां हटती हैं। OpenZeppelin का ERC20 संदर्भ मिंट और बर्न के लेखांकन का वर्णन करता है, जिसमें बर्न पर आपूर्ति कम होना भी शामिल है।

यह तालिका उसी सरल मॉडल का वर्णन करती है। टोकन ट्रांसफ़र को अनुकूलित कर सकता है या अन्य लेखांकन नियम अपना सकता है। “dead” कहलाने वाले पते पर टोकन भेजने को totalSupply() घटने का प्रमाण न मानें: जांचें कि अनुबंध वास्तव में आपूर्ति घटाता है या नहीं। पते पर लगा लेबल बर्न फ़ंक्शन नहीं चलाता।

इसी तरह, दूसरी जगह आपूर्ति बदलने पर आपका बैलेंस वही रह सकता है। OpenZeppelin की आपूर्ति मार्गदर्शिका बताती है कि ERC-20 आपूर्ति का तंत्र कार्यान्वयन पर छोड़ता है। वर्तमान आपूर्ति का मान यह साबित नहीं करता कि भविष्य में मिंटिंग असंभव है।

टोकन हिलाए बिना दोनों आंकड़े पढ़ें

दोनों आंकड़े एक ही नेटवर्क के एक ही टोकन अनुबंध से पढ़ें। यह प्रक्रिया एक सुझाई गई जांच है, इस लेख के लिए किए गए वॉलेट परीक्षण की रिपोर्ट नहीं। प्राथमिक दस्तावेज़ 23 अक्टूबर 2026 को जांचे गए।

1. नेटवर्क और टोकन अनुबंध का पूरा पता दर्ज करें। पते को जारीकर्ता की आधिकारिक डिप्लॉयमेंट जानकारी से मिलाएं। अलग नेटवर्क पर एक जैसा प्रतीक समान आधार पर तुलना के लिए पर्याप्त नहीं है।
2. जिस सार्वजनिक खाते को जांचना है उसे दर्ज करें। उसे उस खाते के विवरण से लें। टोकन अनुबंध से अलग रखें। सार्वजनिक ट्रैकिंग उन खातों पर भी काम करती है जिन पर आपका नियंत्रण नहीं है, इसलिए सफल खोज स्वामित्व साबित नहीं करती।
3. उस नेटवर्क का भरोसेमंद एक्सप्लोरर या अनुबंध रीडर खोलें। सत्यापित टोकन अनुबंध के लिए केवल पढ़ने वाला इंटरफ़ेस चुनें। totalSupply() पढ़ें, फिर खाते का पता इनपुट देकर balanceOf पढ़ें। इंटरफ़ेस के लेबल बदलते हैं; सवाल पहचानने के लिए फ़ंक्शन के नाम देखें।
4. परिणाम के साथ उस समय की स्थिति रखें। उपलब्ध हो तो ब्लॉक संख्या दर्ज करें। दोनों कॉल एक ही ब्लॉक पर करना बेहतर है। अलग-अलग “latest” रीडिंग के बीच ट्रांसफ़र, मिंट या बर्न होने पर वे अलग स्थितियां दिखा सकती हैं।
5. तुलना से पहले इकाइयां दर्ज करें। कच्चे उत्तर सुरक्षित रखें और देखें कि इंटरफ़ेस ने उन्हें पहले ही फ़ॉर्मैट किया है या नहीं। कॉल विफल होने का अर्थ डेटा अनुपलब्ध है, शून्य बैलेंस नहीं।

Ethereum के ERC-20 दस्तावेज़ आपूर्ति और खाते के बैलेंस के लिए अलग कॉल दिखाते हैं। कौन सा परिणाम चाहिए, यह समझने के लिए उनकी डेवलपर व्यवस्था दोहराना जरूरी नहीं है। सार्वजनिक रीड विधियों वाला एक्सप्लोरर उसी तरह की जानकारी दे सकता है।

सार्वजनिक स्थिति पढ़ने के लिए ट्रांसफ़र या टोकन अनुमति जरूरी नहीं है। यदि पेज इन मानों को दिखाने के लिए रिकवरी फ़्रेज़ या हस्ताक्षर मांगे, तो वह प्रक्रिया रोक दें। दोनों में से कोई भी इस तुलना का इनपुट नहीं है।

दोनों आंकड़ों के लिए समान इकाइयां रखें

आपूर्ति और खाते के बैलेंस में एक ही टोकन का लेखांकन पैमाना इस्तेमाल होता है। OpenZeppelin की दशमलव संबंधी व्याख्या दोनों को फ़ॉर्मैट करने की बात स्पष्ट करती है। सत्यापित 6 दशमलव स्थान वाले काल्पनिक टोकन में कच्ची आपूर्ति 1000000000 का अर्थ 1,000 टोकन और कच्चे बैलेंस 25000000 का अर्थ 25 टोकन है।

कच्ची आपूर्ति की तुलना फ़ॉर्मैट किए बैलेंस से न करें। इंटरफ़ेस ने आंकड़ा पहले ही बदला हो तो उसे दोबारा भाग न दें। ERC-20 दशमलव मार्गदर्शिका पैमाना तय करने, मेटाडेटा न मिलने और राउंडिंग को समझाती है। यहां पैमाना मिलाना दो अलग मापों की तुलना की पूर्वशर्त भर है; इससे वे बराबर नहीं हो जाते।

आपूर्ति का आंकड़ा क्या तय नहीं कर सकता

ERC-20 का totalSupply() परिसंचारी आपूर्ति की मानकीकृत गणना नहीं है। प्रदाता परिसंचरण का अनुमान लगाते समय कुछ हिस्से हटा सकता है। उसकी पद्धति में उन अपवादों का विवरण होना चाहिए; अनुबंध के उत्तर का नाम बदलकर वे नहीं मिलते। अधिकतम आपूर्ति एक और अलग सवाल है। OpenZeppelin आपूर्ति सीमा का विस्तार दस्तावेज़ करता है, लेकिन ERC-20 खुद हर टोकन में यह सुविधा अनिवार्य नहीं करता।

परिणाम उस खास डिप्लॉयमेंट और उस स्थिति का भी है जिसे आपने पढ़ा। वह अलग चेन, रैप किए टोकन या संबंधित अनुबंधों के टोकन को अपने आप नहीं जोड़ता। समान नाम वाले डिप्लॉयमेंट जोड़ने से अर्थहीन आंकड़ा बन सकता है, जब तक उनके संबंध और लेखांकन को अलग से स्थापित न किया जाए।

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