Rand Protocol
दस्तावेज़ीकरण
टोकन

RPL टोकन डिप्लॉय करें

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

यह पृष्ठ एक टोकन को शून्य से Rand पर एक सक्रिय, हस्तांतरणीय परिसंपत्ति तक ले जाता है। RPL, Rand का टोकन मानक है, जो chain 14 पर नया है। यदि आपने कोई ERC-20 डिप्लॉय किया है या कोई SPL mint बनाया है, तो पहला खंड ध्यान से पढ़ें, क्योंकि RPL टोकन इन दोनों में से कोई नहीं है। इस पृष्ठ के पीछे की अवधारणा RPL टोकन पृष्ठ पर है।

1. RPL टोकन क्या है

RPL टोकन लेजर की टोकन रजिस्ट्री में एक प्रविष्टि है, कोई स्मार्ट कॉन्ट्रैक्ट नहीं। इसमें न कोई कोड लिखना है, न कंपाइल करना है, न ऑडिट करना है। टोकन बनाना एक ही ट्रांज़ैक्शन है जो रजिस्ट्री में एक पंक्ति जोड़ता है। उसके बाद टोकन की इकाइयाँ सामान्य शील्डेड नोट होती हैं, जो RAND वाले उसी पूल में रहती हैं और उसी तरह खर्च होती हैं।

फ़ील्डनियम
asset id32 बाइट, टोकन की पहचान। rpl1… के रूप में लिखा जाता है: bech32m, 62 वर्ण, चेकसम सहित
indexपंजीकरण के समय chain द्वारा दी गई एक छोटी संख्या (1, 2, …; 0 RAND है)। इस chain पर id का संक्षिप्त रूप
nameUTF-8 के 1 से 32 बाइट, निर्माण के समय निश्चित
symbol1 से 12 मुद्रण-योग्य ASCII वर्ण, निर्माण के समय निश्चित
decimals0 से 9, निर्माण के समय निश्चित
mint authorityकौन और इकाइयाँ जारी कर सकता है: कोई नहीं (None), एक कुंजी (Key), या ब्रिज (Bridge)
total supplyसार्वजनिक, और केवल मिंट या बर्न से बदलती है

सिंबल अद्वितीय नहीं होते। कोई भी USDC नाम का टोकन बना सकता है, ठीक वैसे ही जैसे Ethereum और Solana पर। टोकन की पहचान उसकी asset id है, इसलिए किसी टोकन को स्वीकार या सूचीबद्ध करने से पहले rpl1… id जाँचें, सिंबल कभी नहीं। पाठ रूप में चेकसम होता है: गलत टाइप की गई id अस्वीकार कर दी जाती है, कहीं और नहीं भेजी जाती।

यह ERC-20 और SPL से कैसे भिन्न है

ERC-20 / SPLRPL
टोकन क्या हैएक कॉन्ट्रैक्ट, या किसी प्रोग्राम के स्वामित्व वाला खाताएक रजिस्ट्री पंक्ति; प्रति-टोकन कोई कोड नहीं, इसलिए कोई ट्रांसफ़र टैक्स, रीबेस या हुक नहीं
बैलेंससार्वजनिक, प्रति पताशील्डेड नोट। कोई भी किसी धारक का बैलेंस नहीं पढ़ सकता और न किसी टोकन के धारकों की सूची बना सकता है
ट्रांसफ़रप्रेषक, प्राप्तकर्ता और राशि सार्वजनिकप्रेषक द्वारा प्रमाणित, पूरी तरह शील्डेड। पर्यवेक्षक इसे RAND भुगतान से अलग नहीं पहचान सकता
शुल्कchain का मूल सिक्काRAND। टोकन भेजने के लिए धारक को थोड़े RAND चाहिए, जैसे ERC-20 धारक को ETH चाहिए
प्राप्त करनाSPL में पहले टोकन खाता चाहिएकुछ भी सेट अप नहीं करना। कोई भी rand1… पता कोई भी टोकन प्राप्त कर सकता है
राशियाँuint256 / u64u64, और अधिकतम 9 दशमलव
approve / transferFromहाँv1 में नहीं
फ़्रीज़, ब्लैकलिस्ट, पॉज़अक्सरकोई नहीं
मेटाडेटाऑफ़-चेन या परिवर्तनीयऑन-चेन और अपरिवर्तनीय
किसी प्रोग्राम के पास होनाहाँv1 में नहीं

जो सार्वजनिक रहता है वह सीमा है: टोकन का पंजीकरण, हर मिंट और हर बर्न, प्रत्येक अपनी राशि सहित। इसी से total supply कोई भी ऑडिट कर सकता है। धारकों के बीच ट्रांसफ़र कुछ भी प्रकट नहीं करते, यह भी नहीं कि कौन-सा टोकन भेजा गया।

2. शुरू करने से पहले

आपको चाहिएकैसे
rand कमांड लाइननोड चलाना इसे बिल्ड करता है; कमांड लाइन हर कमांड सूचीबद्ध करता है
एक वॉलेटrand keygen एक spend-key फ़ाइल लिखता है और rand address उसका rand1… पता प्रिंट करता है (खाते और पते)
बात करने के लिए एक नोडवॉलेट किसी नोड से JSON-RPC में बात करता है, डिफ़ॉल्ट रूप से http://127.0.0.1:8545 पर आपके अपने नोड से। नोड अपना RPC localhost से बाँधता है, इसलिए सामान्य व्यवस्था chain 20 का अनुसरण करने वाला आपका अपना नोड है। अपना नोड न हो तो --rpc https://rpc.randprotocol.org दें: सार्वजनिक endpoint इस पृष्ठ की हर चीज़ संभालता है, सिवाय rand faucet के, जिसे वह अस्वीकार करता है (JSON-RPC, सार्वजनिक endpoint)
शुल्क के लिए RANDवॉलेट में कुछ RAND। एक faucet कॉल के 100 RAND इस पृष्ठ की हर चीज़ के लिए पर्याप्त हैं, लेकिन chain 20 पर rand faucet केवल उन 16 वॉलेट को भुगतान करता है जिन्हें genesis अनुमति-सूची में रखता है (staking.faucet_recipients), और किसी अन्य पते को the faucet may not mint to this recipient के साथ अस्वीकार करता है; किसी अन्य वॉलेट को RAND ऐसे व्यक्ति से भेजवाने होंगे जिसके पास कुछ RAND हों (मिंट और बर्न)
पंजीकरण शुल्कchain का एक genesis पैरामीटर, 1 से 10,000 RAND के बीच। chain 20 पर यह 1 RAND है, इसलिए rand token create की लागत 1.001 RAND है: हर ट्रांज़ैक्शन द्वारा चुकाया जाने वाला 0.001 RAND आधार शुल्क, और पंजीकरण शुल्क, जिसे chain 20 ब्लॉक के प्रस्तावक को देने के बजाय बर्न कर देता है। यहाँ की हर अन्य कमांड की लागत 0.001 RAND आधार शुल्क है
लगभग 6 GB खाली मेमोरीहर ट्रांज़ैक्शन आपकी अपनी मशीन पर प्रमाणित होता है। chain 20 पर यह दो प्रूफ़ हैं, और वॉलेट प्रत्येक के लिए एक पंक्ति प्रिंट करता है: proving the spend authorisation on this machine (tier 10; seconds)…, फिर proving the bundle (tier 14; about a minute and a half on a laptop)…। बंडल प्रूफ़ में लगभग 100 सेकंड और चलते समय लगभग 5.7 GB मेमोरी लगती है; दोनों प्रूफ़ नेटवर्क पर लगभग 1.37 MB और लगभग 1.5 MB के हैं, कुल मिलाकर लगभग 2.85 MB। यह नीचे के हर उस चरण पर लागू होता है जो chain को बदलता है: create, हर मिंट, हर send और हर बर्न
rand --key wallet.key.json keygen     # writes the spend key; refuses to overwrite
rand --key wallet.key.json address    # your rand1… address
rand --key wallet.key.json faucet     # testnet only, allowlisted wallets only: asks a validator node to mint 100 RAND to this wallet
rand --key wallet.key.json balance    # scans the tree, prints the spendable value and the unspent note count

--key का डिफ़ॉल्ट wallet.key.json है और इसे एक बार RAND_KEY के रूप में सेट किया जा सकता है; --rpc (या RAND_RPC) उस नोड को बताता है जिससे बात करनी है और इसका डिफ़ॉल्ट http://127.0.0.1:8545 है। नीचे की कमांड --key को स्पष्ट रूप से लिखती हैं। प्रूफ़ पर समय खर्च करने से पहले जाँच लें कि नोड chain 20 पर है: वहाँ JSON-RPC मेथड rand_chainId 20 लौटाता है। वॉलेट chain 20 का बिल्ड, v0.6.8, होना चाहिए: chain 20 हर प्रूफ़ और हर हस्ताक्षरित संदेश को, टोकन मिंट सहित, अपने genesis हैश से बाँधता है, इसलिए v0.6.7 का rand ऐसे प्रूफ़ और हस्ताक्षर बनाता है जिन्हें chain 20 अस्वीकार कर देता है।

3. टोकन बनाएँ

token create अपनी राशियाँ टोकन की सबसे छोटी इकाई में लेता है। --fixed-supply और --initial आधार इकाइयों की पूर्ण संख्याएँ हैं: --decimals 2 के साथ, 1000000 की राशि 10,000.00 टोकन है। बाद की हर कमांड (rand send --asset, rand token mint, rand token burn) v0.5.10 से टोकन की प्रदर्शन इकाइयाँ लेती है, जैसे RAND की राशियाँ RAND में होती हैं (1.5): वॉलेट टोकन की रजिस्ट्री पंक्ति से decimals पढ़ता है, और टोकन से अधिक दशमलव अंक अस्वीकार कर दिए जाते हैं। ऑन-चेन राशि हमेशा आधार-इकाई का पूर्णांक होती है।

पहले एक बात तय करें: क्या कभी और इकाइयाँ जारी की जा सकेंगी? उत्तर निर्माण के समय टोकन में निश्चित हो जाता है और बाद में विस्तारित नहीं किया जा सकता।

स्थिर आपूर्तिमिंट-योग्य
mint authorityNoneKey: आपके पास रखी एक Dilithium2 कुंजी
आपूर्तिपूरी आपूर्ति एक बार, निर्माण वाले ट्रांज़ैक्शन में मिंट होती हैशून्य से, या --initial से शुरू होती है; कुंजी-धारक समय के साथ मिंट करता है
फ़्लैग--fixed-supply <N> --to <rand1…>--authority-key-out <FILE>, और वैकल्पिक रूप से --initial <N> --to <rand1…>
उपयुक्तसीमित टोकन, सदस्यता या मतदान इकाईऐसा जारीकर्ता जो आपूर्ति बढ़ाता है, जैसे पॉइंट या रिवॉर्ड टोकन

स्थिर आपूर्ति वाला टोकन

rand --key wallet.key.json token create \
  --name "Example Credits" \
  --symbol EXC \
  --decimals 2 \
  --fixed-supply 1000000 \
  --to rand1…

--to वह पूरा rand1… पता है जो आपूर्ति प्राप्त करता है, उदाहरण के लिए rand address का आउटपुट। --fixed-supply आधार इकाइयों में है: 2 दशमलव पर 1000000 का अर्थ 10,000.00 EXC है।

कमांड नोड से रजिस्ट्री का अगला index और पंजीकरण शुल्क पढ़ती है, प्रारंभिक मिंट का नोट बनाती है, एक शुल्क बंडल प्रमाणित करती है, पंजीकरण सबमिट करती है और ब्लॉक की प्रतीक्षा करती है। सफल होने पर यह सबमिशन की सूचना देती है, फिर index <N>, id <64 hex> (<rpl1…>) के रूप की एक पंक्ति प्रिंट करती है, फिर committed at height <H>। rpl1… id लिख लें: यह टोकन की पहचान है, और बाद की हर कमांड इसे लेती है।

डिफ़ॉल्ट शुल्क आधार शुल्क और chain का पंजीकरण शुल्क है, chain 20 पर 1.001 RAND, इसलिए कुछ गणना नहीं करनी; --fee (RAND में) इसे बढ़ाता है। --no-wait ट्रांज़ैक्शन सबमिट होते ही लौट आता है और committed पंक्ति छोड़ देता है। --cuda संलग्न NVIDIA GPU पर प्रमाणित करता है, इसके लिए --features cuda वाला बिल्ड चाहिए, और यह CPU पर वापस नहीं जाता।

यदि आपका टोकन प्रमाणित होते समय कोई दूसरा टोकन पंजीकृत हो जाए, तो वह उस index को ले लेता है जिसके लिए आपका टोकन सील किया गया था। नोड पंजीकरण अस्वीकार करता है और कमांड वास्तविक संख्याओं के साथ another token took index N first — re-run to register at N+1 प्रिंट करती है। अस्वीकृत पंजीकरण कभी किसी ब्लॉक तक नहीं पहुँचता; जो खोता है वह प्रूफ़िंग है, लगभग 100 सेकंड का काम। कमांड दोबारा चलाएँ और वह अगले index के लिए प्रमाणित करेगी।

पूरी आपूर्ति अब --to पते के स्वामित्व वाले एक शील्डेड नोट में है। पंजीकरण और उसकी राशि सार्वजनिक हैं; प्राप्तकर्ता बाद में उस नोट के साथ क्या करता है, वह सार्वजनिक नहीं है।

मिंट-योग्य टोकन

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json

यह एक नई Dilithium2 कुंजी exp-authority.key.json में लिखता है (mode 0600, किसी मौजूदा फ़ाइल को अधिलेखित करने से इनकार करते हुए) और टोकन को पंजीकृत करता है, जिसमें यही कुंजी उसकी मिंट अथॉरिटी होती है और आपूर्ति शून्य होती है। आउटपुट वही दो पंक्तियाँ हैं जो स्थिर-आपूर्ति वाले टोकन के लिए आती हैं। --fixed-supply और --authority-key-out में से ठीक एक देना अनिवार्य है।

उसी ट्रांज़ैक्शन में पहली राशि मिंट करने के लिए --initial और --to जोड़ें, जिन्हें साथ-साथ ही देना होता है:

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json \
  --initial 5000 \
  --to rand1…

जब तक पंजीकरण प्रक्रिया में रहता है, कुंजी exp-authority.key.json.pending पर रहती है। चेन द्वारा पंजीकरण स्वीकार किए जाने पर इसे exp-authority.key.json में बदल दिया जाता है, और चेन द्वारा अस्वीकार किए जाने पर इसे हटा दिया जाता है। यदि कनेक्शन विफल हो जाए और परिणाम अज्ञात रहे, तो फ़ाइल .pending पर ही रहती है: उसे हटाने से पहले rand token list जाँच लें।

कुंजी फ़ाइल ही टोकन छापने की शक्ति है। इसे ऑफ़लाइन रखें और इसका बैकअप रखें; यह आपके वॉलेट की स्पेंड कुंजी से अलग है और भेजने या प्राप्त करने के लिए कभी आवश्यक नहीं होती।

पहले मिंट का प्राप्तकर्ता id का हिस्सा क्यों है

पंजीकरण पर उसके निर्माता के हस्ताक्षर नहीं होते। जो कोई भी आपके पंजीकरण को mempool में प्रतीक्षा करते देखे, वह अपने स्वयं के शुल्क बंडल से भुगतान करके उसकी प्रति जमा कर सकता है। यदि asset id केवल नाम, प्रतीक और राशि को समाहित करता, तो वह प्रति प्राप्तकर्ता के रूप में प्रतिलिपिकर्ता का पता दर्ज कर सकती थी और पहले किसी ब्लॉक में पहुँच सकती थी: तब id उसका हो जाता और, स्थिर-आपूर्ति वाले टोकन के मामले में, पूरी आपूर्ति सदा के लिए उसकी हो जाती।

इसलिए id पंजीकरण की हर चीज़ पर बना हैश है, प्रारंभिक मिंट सहित: उसकी राशि, उसका प्राप्तकर्ता, उसकी यादृच्छिकता, उसका समय और उसका एन्क्रिप्टेड लिफ़ाफ़ा। भिन्न प्राप्तकर्ता वाली प्रति का हैश एक भिन्न asset id बनता है। वह एक भिन्न टोकन है जिसका प्रतीक संयोगवश आपके प्रतीक जैसा है, और किसी गैर-अद्वितीय प्रतीक ने इससे अधिक का वादा कभी किया ही नहीं था। आपका id केवल आपके प्राप्तकर्ता के साथ ही पंजीकृत हो सकता है।

--salt <hex32> 32-बाइट का वह salt निर्धारित करता है जो id में भी जाता है। इसे छोड़ देने पर वॉलेट यादृच्छिक रूप से एक चुन लेता है। इसे तब निर्धारित करें जब आपको id पुनरुत्पादनीय चाहिए, उदाहरण के लिए टोकन के अस्तित्व में आने से पहले id प्रकाशित करने के लिए।

इसकी पुष्टि करें

rand token info rpl1…          # by id: rpl1… or 64 hex characters
rand token info 2              # or by the index `token create` printed
rand token list --limit 20     # one page of the registry; --from <index> pages on

token info टोकन की पंक्ति को JSON के रूप में प्रिंट करता है: index, id, id_text (rpl1… रूप), name, symbol, decimals, authority, mint_nonce, total_supply और registered_at। स्थिर-आपूर्ति वाले टोकन के लिए authority का मान {"kind":"none"} होता है और मिंट-योग्य टोकन के लिए {"kind":"key","key":…,"address":…}। total_supply आधार इकाइयों में एक दशमलव स्ट्रिंग है। token list enabled, registration_fee, next_index और tokens पंक्तियाँ प्रिंट करता है। दोनों नोड की पूरी सूची पढ़ते हैं, इसलिए नोड को यह पता नहीं चलता कि आपकी रुचि किस टोकन में थी।

या JSON-RPC के माध्यम से, जहाँ पैरामीटर index, 64-अक्षरों का hex id या rpl1… रूप हो सकता है:

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

परिणाम वही पंक्ति है जो token info प्रिंट करता है, या यदि ऐसा कोई टोकन मौजूद नहीं है तो null; त्रुटिपूर्ण id (गलत checksum, मिश्रित केस, गलत लंबाई) पर त्रुटि -32602 आती है। rand_getTokens [from_index, limit] लेता है और हर पंजीकृत टोकन को पृष्ठवार दिखाता है, और rand_getTokenSupply केवल { total_supply, backings } लौटाता है। इनमें से किसी को भी कुंजी की आवश्यकता नहीं होती। देखें JSON-RPC।

आज chain 20 पर मौजूद एक पंक्ति zUSD की है, जो index 1 पर स्थित ब्रिज किया गया टोकन है। एक्सप्लोरर आपके अपने नोड के बिना ही नोड की रजिस्ट्री उपलब्ध कराता है:

curl -s https://randscan.org/api/v1/tokens

chain 14 पर, 2026-09-20 को, इसने "registration_fee": 1000000000, "next_index": 2 और एक टोकन लौटाया, जिसे यहाँ उसकी पहली backing तक संक्षिप्त किया गया है:

{
  "index": 1,
  "id": "32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f",
  "id_text": "rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx",
  "name": "Shielded USD",
  "symbol": "zUSD",
  "decimals": 8,
  "authority": {
    "kind": "bridge",
    "backings": [
      { "chain": 2, "token": "000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7",
        "decimals": 6, "locked": "0", "minted_today": "0", "mint_day": 20716,
        "mint_cap_per_day": "10000000000000" }
    ]
  },
  "mint_nonce": 0,
  "total_supply": "0",
  "registered_at": 256
}

chain 20 पर पंक्ति में वही id, id_text, नाम, प्रतीक और backings हैं, किंतु zUSD को height 256 पर पंजीकृत करने के बजाय genesis में सूचीबद्ध किया गया है (registered_at 0), और इसकी आपूर्ति 99 zUSD से शुरू हुई: 22 Ethereum USDT पर लॉक, 22 BSC USDT पर, 30 Tron USDT पर और 25 Solana USDT पर, जो chain 19 से आगे लाए गए। (chain 19 की आपूर्ति 10 zUSD से शुरू हुई थी, सभी Solana पर; chain 18 की 9 Tron पर और 1 Solana पर।) प्रत्येक backing पंक्ति में रोलिंग-विंडो फ़ील्ड minted_in_window, mint_window_secs और mint_headroom भी होते हैं।

एक्सप्लोरर की प्रति में registration_fee एक JSON संख्या है; नोड का अपना RPC इसे, हर राशि की तरह, दशमलव स्ट्रिंग के रूप में लौटाता है। chain 20 पर, जैसे chain 15 के बाद से हर चेन पर, नोड के rand_getTokens में max_tokens (4096), burn_registration_fee और bound_note_value (दोनों true) भी होते हैं (RPL टोकन)।

4. मिंट करें, और अथॉरिटी सौंपें

केवल Key अथॉरिटी वाले टोकन को ही मिंट किया जा सकता है, और केवल उसी कुंजी द्वारा।

rand --key wallet.key.json token mint \
  --asset rpl1… \
  --to rand1… \
  --amount 5000 \
  --authority-key exp-authority.key.json

--amount टोकन की प्रदर्शन इकाइयों में होता है: इस 0-दशमलव टोकन का 5000 5,000 आधार इकाइयाँ है, और 6-दशमलव टोकन का 1.5 1,500,000 होगा। कोई नोट या प्रमाण बनाने से पहले वॉलेट टोकन की पंक्ति पढ़ता है और इनकार कर देता है यदि टोकन Key-अधिकृत नहीं है या यदि --authority-key वह कुंजी नहीं है जिसका नाम रजिस्ट्री में है। सफल होने पर यह सबमिशन की सूचना देता है और minted <amount> (<base units> units) of asset <index> to <address> प्रिंट करता है। --fee (डिफ़ॉल्ट 0.001 RAND), --no-wait और --cuda वैसे ही काम करते हैं जैसे token create के लिए।

एक मिंट प्राप्तकर्ता के लिए एक नोट जोड़ता है और कुल आपूर्ति बढ़ाता है। राशि और प्राप्तकर्ता की सार्वजनिक कुंजी नेटवर्क पर दिखाई देती हैं: मिंट डिज़ाइन के अनुसार एक सार्वजनिक घटना है, ठीक ब्रिज के माध्यम से जमा की तरह। जैसे ही प्राप्तकर्ता नोट को आगे बढ़ाता है, वह बाकी सब की तरह शील्डेड हो जाता है। शुल्क चुकाने वाला वॉलेट (--key) और मिंट को अधिकृत करने वाली कुंजी (--authority-key) अलग-अलग कुंजियाँ हैं और अलग-अलग लोगों के पास रह सकती हैं।

प्रत्येक मिंट पर chain id, asset id और रजिस्ट्री द्वारा रखे गए एक काउंटर पर हस्ताक्षर होते हैं, और chain 20 पर genesis hash पर भी (rand-rpl-mint-2), ताकि किसी मिंट को इस चेन पर दोहराया न जा सके या किसी दूसरी चेन पर कॉपी न किया जा सके, भले ही वह समान chain id साझा करती हो। set-authority भी इसी प्रकार बँधा है।

अथॉरिटी को किसी नई कुंजी पर ले जाने, या उसे सदा के लिए त्यागने के लिए:

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --new-key next-authority.key.json

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --renounce

--new-key एक कुंजी फ़ाइल लेता है और टोकन को उस फ़ाइल की सार्वजनिक कुंजी को सौंप देता है; --new-key और --renounce में से ठीक एक देना अनिवार्य है। कमांड asset <index>'s mint authority is now <public key hex> या asset <index>'s mint authority is renounced for good प्रिंट करता है। प्रत्येक पर 0.001 RAND का आधार शुल्क और प्रूविंग का एक दौर लगता है। --renounce टोकन को उसकी वर्तमान आपूर्ति पर एक स्थिर-आपूर्ति वाले टोकन में बदल देता है। यह एकतरफ़ा है: अथॉरिटी एक कुंजी से दूसरी कुंजी पर, या किसी कुंजी से किसी के भी पास नहीं, जा सकती है, और इसके अतिरिक्त कुछ नहीं। स्थिर आपूर्ति के साथ बनाया गया टोकन कभी मिंट-योग्य नहीं बन सकता।

5. इसका उपयोग करें

भेजें

rand --key wallet.key.json send rand1… 250 --asset rpl1…

यह टोकन की 250 प्रदर्शन इकाइयाँ भेजता है: 0 दशमलव पर 250 EXP, या 2 पर 250.00 EXC (25,000 आधार इकाइयाँ)। प्राप्तकर्ता और राशि स्थितीय (positional) हैं, जैसे RAND के लिए। कोई भी प्रूविंग शुरू होने से पहले वॉलेट एक पंक्ति प्रिंट करता है, to fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <symbol> (<base units> units), और पूछता है send? [y/N]। फ़िंगरप्रिंट का प्राप्तकर्ता के फ़िंगरप्रिंट से, और आधार इकाइयों का आपके अभिप्रेत मान से मिलान करें। --yes प्रश्न को छोड़ देता है, और किसी स्क्रिप्ट को इसे देना ही होगा: इसके बिना, टर्मिनल न होने वाला stdin अस्वीकार कर दिया जाता है। --asset index, rpl1… id या 64-अक्षरों का hex id लेता है, और इसे छोड़ देने पर RAND भेजा जाता है। --memo <text> भुगतान के लिफ़ाफ़े के भीतर प्राप्तकर्ता के लिए अधिकतम 510 बाइट का पाठ सील करता है, जिसकी अनुमति देने वाली पहली चेन chain 18 है; चेन पर कुछ भी यह नहीं दर्शाता कि कोई मेमो मौजूद है। --fee सदैव RAND में होता है और उसका डिफ़ॉल्ट 0.001 है; --no-wait और --cuda लागू होते हैं। किसी id को नोड की पूरी रजिस्ट्री सूची से उसके index में बदला जाता है, और संख्यात्मक index नोड तक पहुँचता ही नहीं, इसलिए नोड को यह नहीं बताया जाता कि कौन-सा टोकन स्थानांतरित होने वाला है। यह वही rand send है जो RAND को स्थानांतरित करता है, और प्रूविंग भी वही है। ट्रांज़ैक्शन चार nullifier, चार commitment, एक RAND शुल्क, एक समय, चार एन्क्रिप्टेड लिफ़ाफ़े, बंडल प्रमाण और, chain 17 से, एक प्राधिकरण commitment और उसका प्रमाण प्रकाशित करता है, चाहे कोई भी एसेट स्थानांतरित हुआ हो। पर्यवेक्षक टोकन ट्रांसफ़र को RAND भुगतान से अलग नहीं पहचान सकता, यह नहीं जान सकता कि वह कौन-सा टोकन था, और उसे कोई प्रेषक, प्राप्तकर्ता या राशि दिखाई नहीं देती।

शुल्क उसी बंडल से RAND में चुकाया जाता है, इसलिए भेजने वाले वॉलेट में कुछ RAND होना आवश्यक है। प्रूविंग शुरू करने से पहले वॉलेट इसकी जाँच करता है।

बैलेंस जाँचें

rand --key wallet.key.json asset-balance 2     # one token, by index
rand --key wallet.key.json asset-balance       # a row for every token this wallet holds

तर्क एक रजिस्ट्री index है। एक टोकन के लिए वॉलेट asset <index> balance: <N> units प्रिंट करता है, आधार इकाइयों में। rand notes वॉलेट द्वारा खोले गए हर नोट को उसके asset index के साथ सूचीबद्ध करता है। वॉलेट अपनी viewing कुंजी से चेन को स्कैन करके अपने नोट ढूँढता है। चेन पर ऐसा कोई बैलेंस दर्ज नहीं है जिसे वह देख सके।

बर्न करें

rand --key wallet.key.json token burn rpl1… 100

एसेट और राशि स्थितीय हैं: एसेट index, rpl1… या hex के रूप में, और राशि टोकन की प्रदर्शन इकाइयों में, जैसे send --asset उसे पढ़ता है। --fee का डिफ़ॉल्ट 0.001 RAND है; --no-wait और --cuda लागू होते हैं।

बर्न इकाइयों को नष्ट करता है और कुल आपूर्ति घटाता है। मिंट की तरह, यह एक सार्वजनिक सीमा है: राशि और टोकन दिखाई देते हैं, धारक नहीं। zUSD जैसे ब्रिज किए गए टोकन को इस तरह बर्न नहीं किया जाता: token burn प्रूविंग से पहले ही उसे अस्वीकार कर देता है, और वह rand bridge-burn के माध्यम से बाहर निकलता है, जो उसके पीछे के कॉइन को मुक्त करता है।

6. एक्सप्लोरर पर इसका सत्यापन करें

randscan.org किसी टोकन का सार्वजनिक पक्ष सभी को दिखाता है: उसका पंजीकरण, उसके मिंट और बर्न, और उसकी कुल आपूर्ति। हर टोकन randscan.org/tokens पर सूचीबद्ध है, और किसी एक टोकन का पृष्ठ /tokens/<rpl1…>, /tokens/<64 hex> या /tokens/<index> है; randscan.org/tokens/1 zUSD है। यही डेटा GET /api/v1/tokens और GET /api/v1/tokens/:id पर भी उपलब्ध है; दूसरे में टोकन का डिप्लॉय ट्रांज़ैक्शन और पंजीकरण, मिंट तथा बर्न का उसका आपूर्ति-इतिहास भी शामिल है (Explorer API)।

किसी ट्रांसफ़र के सार्वजनिक पृष्ठ पर न कोई एसेट, न कोई राशि और न कोई पक्ष दिखता है, क्योंकि चेन के पास ये जानकारियाँ होती ही नहीं। किसी और को, जैसे किसी ऑडिटर, प्रतिपक्ष या एक्सचेंज को, किसी भुगतान का प्रमाण देने के लिए उन्हें एक कुंजी दें:

कुंजीउसका धारक क्या देखता है
ट्रांज़ैक्शन कुंजीएक ट्रांज़ैक्शन का एक आउटपुट खुला हुआ: टोकन, राशि और पक्ष
व्यूइंग कुंजीवॉलेट द्वारा भेजा या प्राप्त किया गया हर नोट, इसी विवरण के साथ, और यह भी कि प्रत्येक खर्च हो चुका है या नहीं
rand --key wallet.key.json tx-key <TX_HASH>    # the keys for one transaction
rand --key wallet.key.json viewing-key         # the wallet's viewing key, 64 hex characters

tx-key उस ट्रांज़ैक्शन के हर उस आउटपुट के लिए एक पंक्ति प्रिंट करता है जिसे इस वॉलेट ने भेजा, प्राप्त किया या चेंज के रूप में रखा: आउटपुट (bundle:0 से bundle:3, यानी बंडल के चार स्लॉट), भूमिका, राशि (RAND में, या टोकन के लिए N (asset I)) और वह प्रति-ट्रांज़ैक्शन कुंजी जिसके अंतर्गत वह आउटपुट सील किया गया था। sent पंक्ति की कुंजी सौंपें। यह किसी भी पिछले ट्रांज़ैक्शन के लिए काम करता है, क्योंकि वॉलेट कुंजी को चेन से पुनः प्राप्त कर लेता है।

उस आउटपुट को खोलने के लिए ट्रांज़ैक्शन कुंजी को randscan पर उस ट्रांज़ैक्शन के पृष्ठ में पेस्ट करें; एक्सप्लोरर एसेट इंडेक्स को रजिस्ट्री से मिलाकर टोकन को उसके नाम से और उसके दशमलव लागू करके दिखाता है। व्यूइंग कुंजी randscan.org/viewing में डाली जाती है। एक्सप्लोरर कोई कुंजी नहीं रखता और अपने सर्वर पर कुछ भी डिक्रिप्ट नहीं करता। JSON-RPC पर यही प्रकटीकरण rand_checkTransaction(hash, key) है। दोनों में से कोई भी कुंजी कुछ भी खर्च नहीं कर सकती। व्यूइंग कुंजी एक बार साझा करने के बाद वापस नहीं ली जा सकती, इसलिए जब केवल एक भुगतान सिद्ध करना हो, तो ट्रांज़ैक्शन कुंजी को प्राथमिकता दें।

7. ब्रिज किए गए टोकन

zUSD (“Shielded USD”) भी एक RPL टोकन है, जिसकी अथॉरिटी Bridge है: इसकी इकाइयाँ केवल तभी मिंट होती हैं जब गार्डियन Ethereum, Binance Smart Chain, Tron या Solana पर USDT या USDC की जमा राशि को सत्यापित करते हैं, और इसकी आपूर्ति हमेशा वहाँ लॉक की गई राशि के बराबर रहती है। इसे chain 14 पर ऊँचाई 256 के ट्रांज़ैक्शन द्वारा, इंडेक्स 1 पर, सात बैकिंग के साथ पंजीकृत किया गया था, और तब से हर चेन का जेनेसिस, chain 20 सहित, इसे उसी id, rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx, के अंतर्गत फिर से सूचीबद्ध करता है। chain 14 के रुकने के समय बकाया 10 zUSD को chain 15 आगे ले गई, chains 16 से 19 इन्हीं 10 zUSD के साथ शुरू हुईं, और chain 20 chain 19 पर बकाया 99 zUSD के साथ शुरू हुई। chain 20 पर ब्रिज प्रत्येक जमा और प्रत्येक रिडेम्पशन का 10 bps, zUSD में, एक ट्रेज़री नोट में ले लेता है (Bridge)। zUSD एक बास्केट है: इसकी बैकिंग अंकित मूल्य पर पूल की जाती हैं, इसलिए धारक हर सूचीबद्ध कॉइन का जोखिम वहन करता है, न कि केवल उस कॉइन का जिसे उसने जमा किया था (RPL tokens)। इसकी आपूर्ति हर जमा और रिडेम्पशन के साथ बदलती है; rand token info 1 या एक्सप्लोरर का /tokens/1 वर्तमान आँकड़ा देता है।

chain 14, एक पूर्ववर्ती testnet, पर इसका जीवनक्रम (एक्सप्लोरर पर 2026-09-20 को जाँचा गया)। यह तालिका chain 14 का इतिहास है: chain 14 सेवानिवृत्त हो चुकी है, इसलिए ये ट्रांज़ैक्शन chain-20 एक्सप्लोरर पर नहीं हैं:

क्याट्रांज़ैक्शन (chain 14)ऊँचाई
पंजीकरण (register_bridged_token)7fa28fe6277a82401dcc440ff32da13c5e5763f79826fb17cc508f4c15abdd13256
एक ब्रिज मिंट (bridge_attest)f2f24d75bc0e7d84dff1f4e4518a9d4bef115392492a39befca1528a2404851d2,572
एक शील्डेड zUSD ट्रांसफ़रe6ddaca3c852e6c861524a55d00a0fbdcaff6867544b9f19b9bf60ce263c32ed3,259
एक ब्रिज बर्न (bridge_burn)f9f365ca170a5fb51ff9381d7b5cc39538c1a621e5f6e8c1bd74d8751c7bbc493,481

ट्रांसफ़र के पृष्ठ पर वही दिखा जो कोई भी टोकन ट्रांसफ़र दिखाता है: चार नलीफ़ायर, चार कमिटमेंट और एक शुल्क, और ऐसा कुछ भी नहीं जिससे पता चले कि zUSD स्थानांतरित हुआ।

कोई कुंजी क्या प्रकट करती है, यह दिखाने के लिए fullnode के v0.5 रिलीज़ नोट्स ने उस chain-14 ट्रांसफ़र के लिए दो कुंजियाँ प्रकाशित कीं, जो इसी उद्देश्य से बनाए गए एक डेमो वॉलेट से थीं जिसमें और कुछ नहीं है:

कुंजीमानयह क्या खोलती है
ट्रांसफ़र की ट्रांज़ैक्शन कुंजी7f68f57c4f33a3f0fe419f4d1a5df2875461339dbc454af8ced50cbd7f40e4efउसी एक ट्रांज़ैक्शन का आउटपुट bundle:0: एसेट 1 की राशि 100000000, जो 1 zUSD है
डेमो वॉलेट की व्यूइंग कुंजीa93c673ffeff7204447161347828d8e549b7070460813ae1b7e664694e1dcd5dउस वॉलेट द्वारा भेजा या प्राप्त किया गया हर नोट

chain 14 पर ट्रांज़ैक्शन कुंजी ने ट्रांसफ़र के पृष्ठ पर उस आउटपुट को खोला, और JSON-RPC पर यह एक ही कॉल थी (2026-09-20 को जाँचा गया)। chain 20 पर आपके अपने किसी ट्रांज़ैक्शन के लिए कॉल का स्वरूप यही है; इन chain-14 मानों के साथ chain-20 नोड null उत्तर देता है (2026-10-01 को जाँचा गया), क्योंकि उसके पास वह ट्रांज़ैक्शन कभी था ही नहीं:

curl -s https://rpc.randprotocol.org -H 'content-type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1, "method": "rand_checkTransaction",
  "params": ["e6ddaca3c852e6c861524a55d00a0fbdcaff6867544b9f19b9bf60ce263c32ed",
             "7f68f57c4f33a3f0fe419f4d1a5df2875461339dbc454af8ced50cbd7f40e4ef"] }'

जिस वॉलेट का आप उपयोग करते हैं, उसकी व्यूइंग कुंजी कभी प्रकाशित न करें: यह उस वॉलेट का पूरा इतिहास हमेशा के लिए दिखा देती है।

कोई साधारण पता ब्रिज किया गया टोकन नहीं बना सकता। rand token create Bridge अथॉरिटी को अस्वीकार कर देता है, और ब्रिज किए गए टोकन को पंजीकृत करने, या किसी मौजूदा टोकन के पीछे कोई कॉइन जोड़ने के लिए ब्रिज के पोस्ट-क्वांटम गार्डियन सेट के हस्ताक्षरित कोरम की आवश्यकता होती है। जो टोकन इसके बिना स्वयं को zUSD कहता है, वह उधार लिए गए प्रतीक वाला बस एक और टोकन है, और rpl1… id की जाँच करने का यह एक और कारण है। Rand पर ब्रिज किए गए टोकन के हमेशा 8 दशमलव होते हैं।

Bridge जमा, रिडेम्पशन और गार्डियन सेट का विवरण देता है।

2026-10-12 को fullnode कमिट c0878c3f (चेन 21) के विरुद्ध अंतिम बार सत्यापित, और fullnode `docs/tokens.md`, `docs/cli.md`, `docs/rpc.md` and the wallet's output lines in `crates/randprotocol-client/src/main.rs`; randscan `adfe129` (`docs/api.md`); the live registry at `randscan.org/api/v1/tokens` on 2026-09-20. The commands on this page were checked against those sources, not run by us on chain 14. Updated for chain 15 against fullnode `8abf85e` (v0.5.9) and `deploy/genesis-chain15.json`. Updated for chain 18 on 2026-09-30 against fullnode `90e7716` (the fleet runs v0.6.7 `86941a1`): `docs/tokens.md`, `docs/cli.md`, `docs/shielded.md` §2, `deploy/genesis-chain18.json` and the wallet's output lines in `crates/randprotocol-client/src/main.rs` and `wallet.rs` at the v0.6.7 tag; randscan `fffa404` (`docs/api.md`). The commands were checked against those sources, not run by us on chain 18; the zUSD transactions in section 7 are chain 14's. Updated for chain 20 on 2026-10-01 against fullnode `c9c9bd3c` (v0.6.8): `deploy/genesis-chain20.json` (`tokens`, `binding_domain`), `crates/randprotocol-core/src/types/binding.rs` (the genesis-bound mint and authority messages), and the live `rand_chainId`, `rand_getTokens` and `rand_checkTransaction` on 2026-10-01 Updated for chain 21 on 2026-10-12 against fullnode `c0878c3f` (v0.8.0): `deploy/genesis-chain21.json` (`tokens`, `fees`), `rand_getTokens` and `rand_getSupply` on chain 21; the commands were not run on chain 21.। जहाँ कोड और यह पृष्ठ असहमत हों, वहाँ कोड सही है; हमें बताएँ।