आपूर्ति

इस पृष्ठ का उपयोग rand_getSupply को सही ढंग से पढ़ने और निर्गमन (issuance) को समझने के लिए करें: RAND कहाँ से आता है, कहाँ जाता है, और वह सर्वसमिका जो एक परिरक्षित चेन की आपूर्ति को सटीक बनाती है, जबकि कोई भी उसके नोटों का योग नहीं निकाल सकता।

RAND कहाँ से आता है और कहाँ जाता है

एक परिरक्षित चेन अपनी ही राशि का योग नहीं निकाल सकती: किसी नोट का मूल्य उसके कमिटमेंट के भीतर रहता है। सार्वजनिक केवल पूल की सीमा को पार करने वाला हर संक्रमण है। ये पाँच प्रकार के होते हैं, और प्रोग्राम वॉल्ट वाली चेन (RPL-2, चेन 20) पर सात:

जिस चेन का जेनेसिस tokens.burn_registration_fee सेट करता है, जैसा कि चेन 20 का करता है, उस पर टोकन पंजीकरण का 1 RAND registration_fee भी burned के माध्यम से पूल से बाहर जाता है, परंतु किसी रजिस्टर प्रविष्टि में नहीं जाता: वह नष्ट हो जाता है, और प्रस्तावक के पास केवल बंडल का आधार शुल्क रहता है।

पूल के साथ वैलिडेटर रजिस्टर रहता है, जो राशियाँ खुले रूप में रखता है क्योंकि सहमति का भार (consensus weight) सार्वजनिक होना आवश्यक है। रजिस्टर में रखा स्टेक वास्तविक RAND है: उसे अनबॉन्ड करके वापस एक नोट में निकाला जा सकता है। चेन 20 पर प्रोग्राम वॉल्ट उसके साथ दूसरा सार्वजनिक बैलेंस हैं: कोई invoke जो RAND जमा करता है, वह वहाँ तब तक गणनीय रहता है जब तक कोई भुगतान उसे नोट के रूप में पूल में वापस नहीं लौटा देता।

चेन 20 पर न कोई ब्लॉक रिवॉर्ड है और न कोई मुद्रास्फीति। चेन का पहला निर्धारित निर्गमन ब्लॉक-एग्रीगेशन सब्सिडी है — प्रति सील किए गए ब्लॉक नए RAND की एक घटती राशि, जो उस एग्रीगेटर को दी जाती है जिसका प्रूफ़ उस ब्लॉक को कवर करता है — और यह चेन 20 पर सक्रिय नहीं है (प्रूफ़)। चेन 20 एक नई चेन है, 2026-10-01 को 06:17 UTC से लाइव, चेन 19 से काटी गई (fullnode v0.6.8, एक हार्ड फ़ोर्क)। इसके जेनेसिस ने 31,184.243719258 RAND जारी किए: 26 जेनेसिस वैलिडेटरों में 26,000 स्टेक किए गए और 5,184.243719258 सात डिपॉज़िट नोटों में, जो चेन 19 से लाए गए सात ऑपरेटर वॉलेटों के बैलेंस हैं। चेन 19 पर अन्य वॉलेटों के पास जो था, लगभग 519.9 RAND (अनुमत-सूची वाले प्राप्तकर्ताओं को फ़ॉसेट मिंट, उपयोगकर्ताओं को भुगतान), वह नहीं लाया गया, क्योंकि कोई नोट उसके स्वामी के पते के बिना दोबारा नहीं बनाया जा सकता; न ही बिना निकाले गए 0.499 RAND के वैलिडेटर रिवॉर्ड लाए गए। दो और जेनेसिस नोट, कुल नौ, ब्रिज के 99 zUSD (10 और 89) रखते हैं, जो RAND नहीं है और इस ऑडिट के दायरे से बाहर है। चेन 20 पर rand_getSupply genesis_deposited 5,184,243,719,258 इकाइयाँ और invariant_holds: true पढ़ता है (ऊँचाई 3,037, 2026-10-01)। चेन 19, जो उसी दिन चेन 18 के ऊँचाई 141,935 पर लिए गए स्नैपशॉट से काटी गई थी, ने 31,294.644359629 RAND जारी किए: वही 26,000 स्टेक किए गए और 5,294.644359629 सात नोटों में, साथ में एक 10 zUSD का नोट। उसके बाद हर फ़ॉसेट मिंट जारी राशि में जुड़ता है, और हर बर्न किया गया पंजीकरण शुल्क उसमें से घटता है। चेन 15, जो 2026-09-26 को काटी गई थी, ने जेनेसिस पर 23,000 RAND जारी किए, 18 वैलिडेटरों में 18,000 स्टेक किए गए और 5,000 पाँच नोटों में; इसके बाद के आठ वैलिडेटरों ने मौजूदा नोटों से बॉन्ड किया, जिससे कुछ भी जारी नहीं हुआ।

टोकन इस ऑडिट के दायरे से बाहर हैं

ऊपर दिए गए संक्रमण RAND के हैं। कोई RPL टोकन, चाहे ब्रिज किया गया हो या मूल, कभी RAND की सीमा पार नहीं करता: एसेट इंडेक्स 0 RAND के लिए आरक्षित है और टोकन रजिस्ट्री उसे कभी आवंटित नहीं करती, इसलिए एक BridgeAttest, एक TokenMint या किसी पंजीकरण का प्रारंभिक मिंट हमेशा किसी अन्य एसेट का नोट जमा करता है, और किसी BridgeBurn या TokenBurn का burn_a हमेशा ऐसा एक नोट नष्ट करता है (burn_a के माध्यम से RAND बर्न करना अस्वीकार किया जाता है)। fees_paid और burned की गणना केवल बंडल के fee और burn_r से होती है, और पूल के भीतर टोकन का अंतरण कोई भी काउंटर नहीं बदलता, क्योंकि उसका एसेट सार्वजनिक भी नहीं होता। चेन 20 पर कोई Invoke burn_a के माध्यम से टोकन भी ले सकता है: प्रोग्राम के वॉल्ट में (deposit), जिससे उसकी आपूर्ति अपरिवर्तित रहती है, या नष्ट करके (burn), केवल प्रोग्राम के अपने टोकन के लिए। ब्रिज के शुल्क नोट (चेन 20, प्रत्येक zUSD डिपॉज़िट और बर्न का 10 bps, एक ट्रेज़री पते पर) zUSD हैं, कभी RAND नहीं: जारी और समर्थित, इसलिए डिपॉज़िट का बैकिंग और आपूर्ति सकल राशि से बढ़ते हैं और बर्न में ये amount − fee से घटते हैं। किसी टोकन की अपनी आपूर्ति रजिस्ट्री की सार्वजनिक गणना है: rand_getTokenSupply total_supply लौटाता है और, ब्रिज किए गए टोकन के लिए, प्रत्येक बैकिंग की locked राशि, जिनका योग उसके बराबर होता है (RPL टोकन)।

ऑडिट सर्वसमिका

इकाइयों में (1 RAND = 10⁹) छह एकदिश (monotonic) काउंटर, दो जो नष्ट की गई राशि दर्ज करते हैं, और चेन 20 पर दो प्रोग्राम वॉल्ट के लिए:

pool_value     = genesis_deposited + faucet_minted + withdraw_deposited + program_rand_out − fees_paid − burned
register_total = Σ over the register of (stake + pending + rewards)
total_supply   = pool_value + register_total + program_rand_held
issued         = genesis_deposited + genesis_staked + faucet_minted

invariant:       total_supply == issued − slashed − registration_fees_burned

pool_value वह है जो भीतर आया घटा जो बाहर गया — वही संख्या जो नोटों का योग है, जिसकी गणना कोई नहीं कर सकता। किसी withdraw का 0.001 RAND आधार शुल्क संक्रमण नहीं है: वह रजिस्टर की एक पंक्ति से प्रस्तावक की पंक्ति में जाता है, और सीमा केवल नोट ने पार की। invariant_holds का false होना सहमति (consensus) का बग या क्षतिग्रस्त डेटाबेस है, कभी कोई वैध स्थिति नहीं। प्रोग्राम वॉल्ट के बिना वाली चेन पर दोनों प्रोग्राम पद शून्य होते हैं, इसलिए वहाँ सर्वसमिका चेन 19 वाली ही है। जेनेसिस का vesting खंड, जो किसी भी चेन में नहीं रहा है, इसी तरह एक तीसरा सार्वजनिक रजिस्टर जोड़ेगा (JSON-RPC)।

एक ऐसी चेन पर, जिसने 2,000 जमा किए और 4,000 स्टेक किए, 1,000 RAND के एक बॉन्ड और एक withdraw के माध्यम से देखें:

इसे पढ़ना

curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"rand_getSupply","params":[]}'

{ "height": 1998,
  "genesis_deposited": "2000000000000", "genesis_staked": "4000000000000",
  "faucet_minted": "0", "withdraw_deposited": "999999000000",
  "fees_paid": "1000000", "burned": "1000000000000",
  "slashed": "0", "registration_fees_burned": "0",
  "pool_value": "1999998000000", "register_total": "4000002000000",
  "total_supply": "6000000000000", "invariant_holds": true }

हर राशि इकाइयों की एक दशमलव स्ट्रिंग है, क्योंकि JSON संख्या 2⁵³ के बाद सटीक पूर्णांक नहीं रहती। पूरे ऑब्जेक्ट में यहाँ दिखाए गए फ़ील्ड से अधिक फ़ील्ड हैं, जिनमें फ़ॉसेट की प्रति-एपॉक जोड़ी faucet_epoch और faucet_minted_in_epoch शामिल है, जिसे चेन 20 अपने बजट से जाँचती है, program_rand_out और program_rand_held (v0.6.8 से), और चार vesting_* काउंटर जो चेन 20 पर "0" पढ़ते हैं, क्योंकि उसके जेनेसिस में कोई vesting खंड नहीं है (JSON-RPC)। एक्सप्लोरर यही ऑब्जेक्ट GET /supply पर और मुख्य आँकड़े GET /stats में उपलब्ध कराता है।

यह कितना सटीक है

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

दो प्रविष्टियाँ पहले एक दावे पर टिकी थीं, और चेन 14 दोनों को जाँच में बदल देती है (audit v3, POOL-1):

• फ़ॉसेट Mint नोट की ओपनिंग साथ लेकर चलता है। cm और amount के अतिरिक्त यह क्रिया pk, time और r भी प्रकाशित करती है। स्वीकृति के समय (pk, no sender, amount, asset 0, time, r) का कमिटमेंट फिर से परिकलित किया जाता है। मेल न खाने पर क्रिया the mint's commitment does not open to its published note and amount के साथ अस्वीकार की जाती है, और time को बंडल विंडो के भीतर रहना होता है। मिंटर सातों फ़ील्ड पर डोमेन rand-mint-2 के अंतर्गत हस्ताक्षर करता है। इससे पहले कोई वैलिडेटर एक राशि प्रकाशित करके किसी दूसरी राशि का नोट सील कर सकता था। इसकी कीमत यह है कि फ़ॉसेट नोट के स्वामी का pk सार्वजनिक होता है, जैसे निकासी का भुगतान सार्वजनिक होता है; rand_mint के पैरामीटर अपरिवर्तित हैं।
• जेनेसिस alloc नोट भी अपनी ओपनिंग साथ लेकर चलता है। tokens अनुभाग वाली चेन पर हर पंक्ति { cm, envelope, amount, opening: { pk, time, r } } होती है। नोड कमिटमेंट को फिर से परिकलित करता है। यह गणना एसेट 0 पर होती है, जब तक ओपनिंग किसी सूचीबद्ध टोकन का asset न बताए। जिस जेनेसिस फ़ाइल का cm मेल नहीं खाता, नोड उसे अस्वीकार कर देता है। genesis_deposited में केवल एसेट-0 पंक्तियाँ गिनी जाती हैं। अपारदर्शी cm ही वह एकमात्र रास्ता था जिससे कोई जेनेसिस लेखक किसी भी एसेट का बिना समर्थन वाला नोट पूल में डाल सकता था, और कोई उसकी जाँच नहीं कर सकता था। इसलिए फ़ाइल प्रकाशित होते ही जेनेसिस नोट का स्वामी और उसकी राशि डिज़ाइन के अनुसार सार्वजनिक हो जाते हैं। केवल यह निजी रहता है कि नोट बाद में कब और किसमें खर्च हुआ। rand-node genesis हमेशा ओपनिंग लिखता है।

tokens अनुभाग के बिना बनाई गई चेन पर पुराना नियम अब भी लागू है: genesis_deposited घोषित amount फ़ील्डों का योग है, और इस योग को जेनेसिस फ़ाइल के आधार पर विश्वसनीय माना जाता है। दोनों जेनेसिस राशियाँ जेनेसिस हैश में शामिल हैं, इसलिए दोनों ही स्थितियों में सभी नोड उन पर सहमत रहते हैं।

ये काउंटर जान-बूझकर सहमति-स्थिति का हिस्सा नहीं हैं, यानी स्टेट रूट उन्हें हैश नहीं करता। rand-node verify --mode quick चेन को दोबारा चलाकर हर काउंटर को फिर से परिकलित करता है। अगर संग्रहीत स्नैपशॉट से मान मेल नहीं खाता, तो यह कमांड बेमेल की रिपोर्ट करता है।