JSON-RPC

नोड HTTP पर --rpc (डिफ़ॉल्ट 127.0.0.1:8545) पर JSON-RPC 2.0 सेवा देता है, और सब्सक्रिप्शन के लिए उसी पोर्ट पर एक WebSocket भी। v0.6.8 से यह एक दूसरा, सार्वजनिक लिसनर (--public-rpc, नीचे) भी खोल सकता है। randprotocol_client::RpcClient (Rust) नीचे दी गई प्रत्येक मेथड को रैप करता है। यह पृष्ठ मेथडों की वह सूची है जो v0.6.8 (c9c9bd3c), यानी वह बिल्ड जिस पर chain 20 चलती है, प्रदान करता है; जहाँ कोई मेथड कोड में मौजूद है परंतु chain 20 पर निष्क्रिय है, वहाँ यह बात स्पष्ट रूप से कही गई है।

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

सार्वजनिक एंडपॉइंट

https://rpc.randprotocol.org (यही प्रॉक्सी https://randprotocol.org/api/rpc पर भी उपलब्ध है) अनुरोधों को chain 20 के एक आर्काइव नोड तक अग्रेषित करता है, जो हर ब्लॉक रखता है। यह उन वॉलेटों और पृष्ठों के लिए है जिनका अपना नोड नहीं है (rand --rpc https://rpc.randprotocol.org …)। यह केवल HTTP POST स्वीकार करता है, इसमें CORS खुला है और WebSocket नहीं है। यह एक नोड की तुलना में सीमित है:

• प्रति कॉल एक अनुरोध। बैच को -32600 के साथ अस्वीकार किया जाता है।
• मेथडों की एक अनुमति-सूची: 2026-10-01 से यह वही समुच्चय है जो नोड के अपने सार्वजनिक लिसनर का है (v0.6.8 में rpc::PUBLIC_METHODS)। अतः rand program invoke को आवश्यक प्रोग्राम-स्टेट रीड, rand_getAdmitted, एग्रीगेशन रीड और वेस्टिंग रीड इसमें शामिल हैं, साथ ही rand_checkTransaction और rand_sendTransaction भी। rand_mint, rand_importViewingKey, rand_getViewingNotes, rand_removeViewingKey और rand_getPeers इसमें शामिल नहीं हैं। ये नोड तक पहुँचे बिना ही -32601 method not allowed here उत्तर देती हैं, क्योंकि सार्वजनिक फ़ॉसेट दुरुपयोग का द्वार है और व्यूइंग की केवल उसी नोड को दी जानी चाहिए जिसे आप स्वयं चलाते हैं।
• अनुरोध का बॉडी अधिकतम 12 MiB। इसमें कोई भी ट्रांसफ़र, टोकन एक्शन या डिप्लॉय, तथा लगभग 3.4 MB तक के प्रूफ़ वाली कॉल समा जाती है (ट्रांज़ैक्शन hex-एन्कोडेड होता है, और कॉल के प्रूफ़ से पहले उसके बंडल और auth प्रूफ़ लगभग 2.85 MB लेते हैं)। इससे बड़ी कॉल अपने नोड पर भेजें। सीमा से अधिक होने पर: HTTP 413 और -32600।
• प्रति पता, प्रति मिनट 1,200 अनुरोध, और rand_sendTransaction के लिए प्रति मिनट 6। सीमा से अधिक होने पर: HTTP 429 और -32005। रीड की सीमा किसी वॉलेट के पहले सिंक के अनुसार तय की गई है, जिसमें एक ही झोंके में कई सौ अनुरोध होते हैं (chain 18 की ऊँचाई 99,000 पर 645)।
• जब पीछे का नोड उत्तर नहीं देता, तो -32000 upstream unavailable।

इस पृष्ठ पर शेष सब कुछ स्वयं नोड का वर्णन करता है।

नोड के दो लिसनर

v0.6.8 (audit v6) से एक नोड के दो JSON-RPC लिसनर होते हैं।

• --rpc <ADDR>, ऑपरेटर का लिसनर। सभी मेथड, बैच और WebSocket। यह कॉलर की पहचान उसके सॉकेट पते से करता है और लूपबैक पर भरोसा करता है: व्यूइंग-की मेथड केवल लूपबैक को उत्तर देती हैं, और लूपबैक की गिनती नहीं की जाती। इसे 127.0.0.1 पर ही रखें। रिवर्स प्रॉक्सी या SSH फ़ॉरवर्ड लूपबैक पर पहुँचता है, इसलिए ऐसी व्यवस्था के पीछे हर आगंतुक ऑपरेटर बन जाता है: किसी सार्वजनिक एंडपॉइंट को कभी इस पोर्ट की ओर इंगित न करें।
• --public-rpc <ADDR>, सार्वजनिक लिसनर, ठीक इसी कड़ी के लिए। यह मेथडों का एक निश्चित समुच्चय प्रदान करता है: वे रीड जिनकी किसी वॉलेट, एक्सप्लोरर या पृष्ठ को आवश्यकता होती है, और rand_sendTransaction (rpc::PUBLIC_METHODS)। rand_importViewingKey, rand_getViewingNotes, rand_removeViewingKey, rand_mint और rand_getPeers वहाँ कभी उपलब्ध नहीं होतीं, और न ही बाद में जोड़ी गई कोई मेथड, जब तक उसे सूची में न जोड़ा जाए; ऐसी कॉल का उत्तर -32000 <method> is not served on this node's public listener होता है। बैच का उत्तर -32600 है, और कोई WebSocket रूट नहीं है। एक ही मीटर सभी कॉलरों को मिलाकर गिनता है: एक झोंके में 600 अनुरोध और प्रति सेकंड 150; इससे आगे, -32000 बॉडी के साथ HTTP 429। प्रति-आगंतुक सीमाएँ प्रॉक्सी का काम हैं, क्योंकि वही आगंतुकों को देख सकता है। इसके कॉलर नोड के ब्लॉकिंग-रीड स्लॉट में से अधिकतम आधे ही रख सकते हैं, ताकि ऑपरेटर का लिसनर कभी संसाधनों से वंचित न हो।

दोनों लिसनर दो रीड सीमाएँ साझा करते हैं। जो ब्लॉकिंग रीड 30 s के भीतर पूरा नहीं होता, उसका उत्तर -32000 this read took longer than 30 s on this node; retry with a smaller range होता है। rand_getBlocks 64 MiB ब्लॉक पढ़ लेने पर अपना पृष्ठ समाप्त कर देता है।

--rpc-viewing-token-file <PATH> --rpc की व्यूइंग-की मेथडों पर एक बेयरर टोकन लगाता है: फ़ाइल की पहली पंक्ति, कम से कम 32 अक्षर, जो Authorization: Bearer <token> के रूप में भेजी जाती है। इसके लागू होने पर केवल लूपबैक पर्याप्त नहीं रहता, और कहीं से भी जो कॉलर इसे प्रस्तुत करे, उसे सेवा दी जाती है।

परिपाटियाँ

• वैलिडेटर पते base58 स्ट्रिंग (32 बाइट) होते हैं। हैश 64 hex अक्षरों के होते हैं, 0x के साथ या उसके बिना। शील्डेड मान, यानी कमिटमेंट, नलिफ़ायर, एंकर, ट्री रूट और विटनेस स्तर, Word8 होते हैं: आठ लिटिल-एंडियन u32 शब्द, 64 लोअरकेस hex अक्षरों के रूप में।
• शील्डेड पते rand1 + base58 होते हैं, 1,667 अक्षरों के। 2,000 अक्षरों से लंबा पैरामीटर पार्स किए जाने से पहले ही अपनी लंबाई के कारण अस्वीकार कर दिया जाता है।
• प्रत्येक u64 राशि एक दशमलव स्ट्रिंग है ("1500000000" = 1.5 RAND; 1 RAND = 10⁹ इकाइयाँ): चाहे RAND इकाइयाँ हों या टोकन इकाइयाँ, चेन स्टेट हो या डिकोड किए गए ट्रांज़ैक्शन का अपना फ़ील्ड। JSON संख्या 2⁵³ के बाद सटीक पूर्णांक नहीं रहती, और 9 दशमलव वाले टोकन की आपूर्ति कुछ करोड़ इकाइयों पर ही यह सीमा पार कर जाती है। इससे क्या बदला, इसके लिए नीचे दिनांकित टिप्पणी देखें।
• सूचकांक, नॉन्स, ऊँचाइयाँ, लीफ़ सूचकांक, व्यू, लंबाइयाँ, दशमलव और दिवस-गणक (mint_day) कभी राशियाँ नहीं होते और हर जगह JSON पूर्णांक होते हैं।
• प्रत्येक अनुरोध में id सदस्य होना अनिवार्य है। जिस ऑब्जेक्ट में यह नहीं है, वह एक नोटिफ़िकेशन है और -32600 के साथ अस्वीकार किया जाता है; स्पष्ट रूप से दिया गया "id": null एक सामान्य अनुरोध है।
• कोई बैलेंस मेथड नहीं है और कोई अकाउंट मेथड नहीं है। वॉलेट अपनी व्यूइंग की से rand_getCommitments और rand_getNullifiers को स्कैन करके अपना बैलेंस निकालता है। rand_getBalance, rand_getAccount और rand_getAssetBalance का उत्तर -32601 है।

असंगत परिवर्तन, 2026-09-20 (chain 14): प्रत्येक राशि एक दशमलव स्ट्रिंग है

chain 14 से पहले, डिकोड किए गए ट्रांज़ैक्शन के भीतर की राशियाँ JSON पूर्णांक होती थीं। वह अपवाद अब समाप्त हो गया है। ये फ़ील्ड JSON संख्याओं से दशमलव स्ट्रिंग में बदल गए हैं, उनके अर्थ या स्थान में कोई अन्य परिवर्तन किए बिना:

• bundle.fee, rand_getTransaction के tx में और rand_getBlockByHeight / rand_getBlockByHash के transactions[] में;
• kind = mint, bond, unbond, withdraw, bridge_attest के लिए action.amount (वही तीन मेथड);
• kind = bridge_burn के लिए action.amount और action.relayer_fee (वही तीन मेथड);
• rand_getAssets की और rand_getBridgeState.assets[] की पंक्तियों में locked।

जो क्लाइंट इनमें से किसी को संख्या के रूप में पढ़ता है, उसे अब स्ट्रिंग पार्स करनी होगी। rand_status का aggregation.subsidy_base (केवल एग्रीगेशन वाली चेनों पर) इसी परिवर्तन में स्ट्रिंग बन गया। बाकी हर राशि पहले से स्ट्रिंग थी: rand_getSupply, rand_getEmission, rand_getValidators, व्यूइंग नोट, और chain 14 के साथ जोड़ा गया हर फ़ील्ड, यानी बंडल के burn_a और burn_r, टोकन आपूर्तियाँ, प्रत्येक बैकिंग के locked, mint_cap_per_day और minted_today, registration_fee, और token_mint, token_burn तथा register_token का amount (initial_amount, initial.amount)।

बैच

किसी POST बॉडी में अधिकतम 20 अनुरोध ऑब्जेक्टों का एक ऐरे हो सकता है। इसका उत्तर उसी लंबाई का एक ऐरे होता है, अनुरोधों के क्रम में, त्रुटियों सहित। अनुरोध एक के बाद एक चलते हैं। खाली ऐरे, 20 से बड़ा ऐरे, या ऐसा बॉडी जो न ऑब्जेक्ट है न ऐरे, null id के साथ एक अकेला -32600 होता है। पूरा बॉडी फिर भी नोड की अनुरोध-बॉडी सीमा से बँधा रहता है, जो प्रूफ़ वाले एक ट्रांज़ैक्शन के अनुसार तय है: प्रूफ़ वाली दो rand_sendTransaction कॉल का बैच 413 के साथ अस्वीकार किया जाता है। रीड को बैच करें, प्रूफ़ वाले सबमिशन को नहीं।

चेन और नोड

rand_chainId

पैरामीटर []। परिणाम: चेन id (पूर्णांक); testnet पर 20।

rand_tokenInfo

पैरामीटर []। परिणाम { "symbol": "RAND", "decimals": 9 }।

rand_getHead

पैरामीटर []। परिणाम { "height": 1998, "hash": "…", "view": 2251 }। view नोड का वर्तमान सहमति व्यू है, जो व्यू के टाइम-आउट होने पर ऊँचाई से आगे निकल जाता है।

rand_status (उपनाम rand_syncStatus)

पैरामीटर []। परिणाम:

{
  "height": 1998, "head_hash": "…", "view": 2251, "high_qc_view": 2250,
  "syncing": false, "sync_target": 1998,
  "sync_inflight_age_ms": null, "sync_failures": 0, "sync_late_batches": 0,
  "peer_count": 26, "connected_peers": 26, "reserved_peers": 25, "ws_clients": 0, "refused_cache": 0,
  "verify_queue": 0, "mempool_size": 0,
  "is_validator": true, "active_validator": true, "faucet": true, "confidential": true,
  "testnet": true, "fri_profile": "production", "programs": 10, "viewing_keys": 0,
  "notes": 197, "nullifiers": 160, "tree_root": "72b9…1197", "hc_bundle": "60af…3fce", "hc_auth": "1e4e…39c1",
  "binding_domain": 1,
  "address": "5TAofR…", "peer_id": "12D3KooW…",
  "gas_prices": { "gas_price": "100", "byte_price": "800" }
}

is_validator: इस नोड के पास एक वैलिडेटर की है; active_validator: वह की वर्तमान एपॉक चलाने वाले समुच्चय में है। reserved_peers (v0.6.8) उन पीयरों की गिनती है जिन्हें इनबाउंड कनेक्शन सीमा के बावजूद प्रवेश दिया गया: बूटस्ट्रैप, कोई भी --reserved-peer, और हस्ताक्षरित पीयर बाइंडिंग से ज्ञात हर वैलिडेटर पहचान, प्रत्येक एक बार; फ़्लीट नोड पर यह शुरू होने के एक मिनट के भीतर वैलिडेटरों की संख्या तक पहुँच जानी चाहिए। viewing_keys बताता है कि नोड-साइड स्कैनिंग के लिए नोड अपनी मेमोरी में कितनी व्यूइंग की रखता है। verify_queue उन ट्रांज़ैक्शनों की संख्या है जो चार प्रूफ़-सत्यापन वर्करों में से किसी एक की प्रतीक्षा कर रहे हैं (अधिकतम 64)। hc_bundle वह बंडल गेस्ट है जिसके विरुद्ध इस चेन के प्रूफ़ बनते हैं, और hc_auth वह auth गेस्ट जिसे इसका जेनेसिस निर्धारित करता है (विभाजित प्राधिकरण, chain 17 से), या जिस चेन पर यह नहीं है वहाँ null; जिस नोड का बिल्ड इनमें से किसी से मेल नहीं खाता, वह शुरू होने से इनकार कर देता है। testnet और binding_domain इन्हीं नामों वाले जेनेसिस फ़ील्ड हैं, जैसे rand_getLimits उन्हें प्रदान करता है। gas_prices टिप लेजर की वर्तमान गैस कीमतें हैं, जो हर कमिट पर ताज़ा होती हैं, दशमलव स्ट्रिंग के रूप में; जिस चेन पर gas खंड नहीं है वहाँ null। chain 20 की कीमतें गतिशील हैं और ब्लॉक के भराव के अनुसार हर ब्लॉक पर बदलती हैं, कभी 100 और 800 के न्यूनतम स्तर से नीचे नहीं और कभी 10,000 और 80,000 की अधिकतम सीमा से ऊपर नहीं; इसलिए इन्हें यहाँ या rand_getLimits में पढ़ें और हार्ड-कोड न करें। ऑब्जेक्ट में एक aggregation ऑब्जेक्ट भी होता है (इसका subsidy_base दशमलव स्ट्रिंग, बाकी पूर्णांक), जो aggregation खंड रहित चेन पर, जैसी chain 20 है, पूरी तरह शून्य दिखाता है।

ऑब्जेक्ट में disk_free_bytes (एक संख्या) और disk_low भी होते हैं, और प्रतिधारण की जोड़ी भी: prune_floor, वह न्यूनतम ऊँचाई जो यह नोड अब भी रखता है (आर्काइव पर 0), और prune_history_secs, वह अवधि जो --prune-history के साथ शुरू किया गया नोड रखता है (जब वह सब कुछ रखता है तो null)। chain 20 पर, chain 19 की तरह, 26 में से 24 वैलिडेटर 24 घंटे के ब्लॉक रखते हैं; दोनों आर्काइव सभी ब्लॉक रखते हैं। देखें प्रून किए गए नोड।

rand_getPeers

पैरामीटर []। परिणाम: { "peer_id": "12D3KooW…", "addrs": ["/ip4/…/tcp/30303"], "connected_secs": 1241 } का एक ऐरे।

rand_getBlockByHeight / rand_getBlockByHash

पैरामीटर [height] या [hash]। अज्ञात होने पर परिणाम null, अन्यथा:

{
  "hash": "647b…", "height": 50, "view": 92, "parent": "2d41…",
  "proposer": "3v3VBJ…", "timestamp_ms": 1788000123456,
  "tx_root": "0000…", "state_root": "a1b2…", "justify_view": 91,
  "tx_count": 0, "transactions": [ ]
}

केवल कमिट हो चुके ब्लॉक ही उपलब्ध कराए जाते हैं। transactions का स्वरूप वही है जो rand_getTransaction के tx का है। ब्लॉक में sealed भी होता है, और उसके प्रत्येक लेनदेन में sealed_by; एग्रीगेशन रहित चेन पर इनका मान false और null होता है।

rand_getBlocks

पैरामीटर [from_height, to_height]। परिणाम: ब्लॉक हेडर, सबसे पुराने पहले, from_height से अधिकतम 1,024 (2026-09-24 से पहले के नोड पर 128): rand_getBlockByHeight के फ़ील्ड, transactions के बिना। सीमा से चौड़ी या हेड से आगे जाने वाली रेंज अस्वीकार नहीं की जाती, बल्कि छोटी कर दी जाती है, और v0.6.8 से कोई पेज 64 MiB ब्लॉक पढ़ लेने पर भी समाप्त हो जाता है; लौटाई गई अंतिम ऊँचाई से आगे बढ़ें। to_height के from_height से कम होने पर -32602।

v0.6.8 से प्रत्येक हेडर में public_notes भी होता है: ब्लॉक के bridge_attest, token_mint और register_token लेनदेन, और ब्रिज शुल्क वाली चेन पर उसके bridge_burn लेनदेन, [{ "hash", "raw" }] के रूप में (वही एन्कोडिंग जो rand_getRawTransaction देता है); अन्य हर ब्लॉक के लिए यह खाली होता है। बर्न लेनदेन उसके प्रूफ़ खाली करके और "proofs_stripped": true के साथ दिया जाता है; उसका hash वास्तविक लेनदेन id है। वॉलेट का पहला सिंक इन्हीं पेजों को पढ़ता है और सार्वजनिक नोट पुनर्निर्मित करने के लिए उसे किसी और चीज़ की आवश्यकता नहीं होती।

rand_getFinality

पैरामीटर [height] या [hash]। परिणाम, इनमें से एक: { "status": "committed", "height", "hash" }, { "status": "certified", "height", "hash", "qc_view" }, { "status": "proposed", "height", "hash" }, { "status": "unknown" }। ऊँचाई की जाँच केवल कमिट हुई चेन के विरुद्ध होती है, इसलिए उसका उत्तर committed या unknown होता है; हैश का उत्तर certified (रेप्लिका के अनकमिटेड ट्री में, कोरम प्रमाणपत्र सहित) या proposed (ट्री में, कोरम प्रमाणपत्र के बिना) भी हो सकता है।

rand_getProposer

पैरामीटर [view] या [from_view, to_view], अधिकतम 64 व्यू। परिणाम { "epoch": 3, "proposers": [ { "view": 2251, "proposer": "2nRdFC…" } ] }: वर्तमान वैलिडेटर सेट के अंतर्गत प्रत्येक व्यू का लीडर, न कि वह सेट जो ऐतिहासिक रूप से उस व्यू पर सक्रिय था। उलटी रेंज या 64 से अधिक व्यू के लिए -32602।

rand_getVersion

पैरामीटर []। परिणाम { "version", "git_sha", "chain_id", "hc_bundle", "hc_auth", "fri_profile" }। version वर्कस्पेस क्रेट का संस्करण है; git_sha बिल्ड के समय दर्ज किया गया कमिट हैश है, ट्रैक की गई फ़ाइलें भिन्न होने पर उसके अंत में -dirty जुड़ा होता है, अन्यथा "unknown"। hc_auth जेनेसिस का ऑथ गेस्ट है, जैसा rand_status में, या null। 2026-10-01 को चेन 20 पर सार्वजनिक एंडपॉइंट:

{ "version": "0.6.8", "git_sha": "c9c9bd3c1903aa4cc5833b7ab8c62fc3e6942017", "chain_id": 20,
  "hc_bundle": "60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce",
  "hc_auth": "1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1",
  "fri_profile": "production" }

rand_getGenesisHash

पैरामीटर []। परिणाम: हेक्स में जेनेसिस हैश; चेन 20 पर "6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135" (चेन 19 का a3defc93…228a था)। केवल चेन id से दो चेन कट में अंतर नहीं किया जा सकता; जेनेसिस हैश से किया जा सकता है। चेन 20 पर यह प्रत्येक लेनदेन बाइंडिंग और प्रत्येक हस्ताक्षरित कार्रवाई संदेश का भी हिस्सा है (binding_domain: 1, देखें rand_getLimits)।

rand_getHealth

पैरामीटर []। परिणाम, इनमें से एक: { "status": "disk_low", "free_bytes": "3221225472" }, { "status": "ok" }, { "status": "syncing", "behind": 412 }, { "status": "behind", "behind": 30 }। disk_low बाकी सबसे पहले आता है, जब डेटा डायरेक्टरी के फ़ाइल सिस्टम पर खाली जगह नोड के --min-free-disk-mb के चार गुना से कम हो (डिफ़ॉल्ट 1024, यानी 4 GB से कम); free_bytes एक दशमलव स्ट्रिंग है। ok तब, जब sync_target - height अधिकतम 2 हो और कोई सिंक बैच अनुरोध लंबित न हो; syncing तब, जब ऐसा अनुरोध लंबित हो; behind तब, जब नोड सिंक नहीं कर रहा हो और अंतर फिर भी 2 से अधिक हो।

rand_getMempoolInfo

पैरामीटर []। परिणाम { "count": 2, "bytes": 2611200, "oldest_ms": 1450, "max_count": 10000 }। bytes पूल में मौजूद हर लेनदेन की एन्कोडेड लंबाई का योग है; पूल खाली होने पर oldest_ms का मान null होता है। v0.6.8 से पूल की बाइट्स में भी सीमा है, जो जेनेसिस max_block_bytes का आठ गुना है (चेन 20 पर 160 MiB): इसके पार, जो लेनदेन अपनी न्यूनतम सीमा से ऊपर प्रति KiB अधिक भुगतान करता है, वह सबसे सस्ते लेनदेन को हटा देता है, और कम या बराबर भुगतान करने वाला लेनदेन mempool full के साथ अस्वीकार होता है। गवर्नेंस कार्रवाइयाँ दोनों सीमाओं से मुक्त रहती हैं।

सबमिट करना

rand_sendTransaction

पैरामीटर [hex], जहाँ hex bincode(Transaction) है। परिणाम: लेनदेन हैश। नोड प्रवेश क्रम में सत्यापन करता है (लेनदेन), लेनदेन को पूल में रखता है और गॉसिप के ज़रिए प्रसारित करता है। त्रुटियाँ कारण सहित -32000 होती हैं: nullifier already spent, anchor is not one of the last 1024 roots, time 12 is outside [1500, 2524] (दोनों विंडो जेनेसिस का proof_window_blocks हैं, चेन 20 पर 1,024; चेन 19 तक की चेनों पर 256), fee 1000000 below minimum 2000000, the bundle's digest is not what its proof published, invalid bundle proof: …, unknown program …, already in mempool, conflicts with a pending transaction over <nullifier>, faucet is disabled on this chain; किसी invoke के लिए cell <key> is no longer what this transition read (एक स्टेट निर्णय: सेल को फिर से पढ़ें और फिर से प्रूफ़ बनाएँ) या the vault holds … of asset … and the transition pays …; वोट द्वारा प्रवेश के अंतर्गत पंजीकरण करने वाले Bond के लिए validator … has not been admitted by the validator set's vote (staking.admission_by_vote); ask the validators for an AdmitValidator first; चेन 20 के जेनेसिस में फ़िट न होने वाले बंडल के लिए envelope is 1348 bytes, this chain requires exactly 1860, this chain requires an auth proof on every bundle (genesis hc_auth), the auth proof publishes a different commitment than the bundle's auth_commit, auth proof: …, bundle proof declares gas limit …, this chain requires exactly 20479, non-canonical proof: … — re-prove with an up-to-date wallet; ब्रिज कार्रवाइयों के लिए bridge: attestation already consumed, the attestation names a different recipient, the attestation deposits under asset 2, and the transaction names 1, the bundle burns 399, not the 400 the action declares; ऐसा बर्न ले जाने वाले बंडल के लिए जिसे उसकी कार्रवाई नहीं ले जा सकती, the bundle burns asset 2 on an action that burns no token, a burn of 5 is not allowed on this action या RAND burned through burn_a (5); a RAND burn goes through burn_r; ब्रिज की स्थिति के लिए bridge minting is paused, mint cap … per backing per day, already paused, not paused, wrong pause nonce, wrong list nonce, chain N has no registered emitter; टोकन रजिस्ट्री के लिए wrong mint nonce और wrong token index। स्वीकार होना कमिट होना नहीं है: rand_getTransaction या rand_getTransactionStatus को पोल करें।

चेन की ब्लॉक सीमा (rand_getLimits से max_block_bytes) से बड़ा लेनदेन मेमपूल तक पहुँचने से पहले ही -32000 के साथ अस्वीकार कर दिया जाता है, और त्रुटि में दोनों आकार बताए जाते हैं। अनुरोध बॉडी की सीमा 2 × (2 × max_proof_bytes + 4 × 2048 + max_call_envelope_bytes + 16,384 + 64 KiB) + 256 KiB है, जिसकी गणना स्टार्टअप पर जेनेसिस से होती है: डिफ़ॉल्ट चेन पर 8,867,840 बाइट्स और चेन 20 की सीमाओं पर 17,350,656, जो चेन 17 से 19 के समान है (चेन 13 से 15 पर 34,127,872, जिनकी प्रूफ़ सीमा 8 MiB थी)। 4 × 2048 बंडल के चार एन्वेलप हैं, प्रत्येक एन्वेलप सीमा पर। इससे बड़ी बॉडी पर -32600 मिलता है, जिसमें सीमा बताई जाती है।

केवल -32000 (प्रवेश ने इसे अस्वीकार किया) और -32602 (इसे डिकोड नहीं किया जा सका) ही लेनदेन पर निर्णय हैं। कोई भी अन्य विफलता, -32603 सहित, लेनदेन का परिणाम अज्ञात छोड़ती है: नोड उत्तर देने से पहले लेनदेन को पूल में रखता और गॉसिप करता है, इसलिए जो नोड उस अंतराल में रुक जाए, उसने वह लेनदेन स्वीकार कर लिया हो सकता है जिसका उसने कभी उत्तर नहीं दिया। randprotocol_client केवल इन्हीं दो कोड पर किसी भेजे गए लेनदेन को अस्वीकृत मानता है।

rand_getTransactionStatus

पैरामीटर [[hash, …]], 1 से 64 हैश। परिणाम: प्रत्येक हैश के लिए एक प्रविष्टि, उसी क्रम में:

[ { "hash": "…", "status": "committed", "height": 1998, "index": 0 },
  { "hash": "…", "status": "pending" },
  { "hash": "…", "status": "rejected", "reason": "bad mint signature" },
  { "hash": "…", "status": "unknown" } ]

प्रति हैश खोज का क्रम: committed (स्टोरेज), pending (मेमपूल), rejected (अस्वीकृत लेनदेन का कैश, जिसकी गिनती rand_status का refused_cache करता है), अन्यथा unknown। rejected में केवल वे अस्वीकृतियाँ आती हैं जो लेनदेन के अपने बाइट्स से संबंधित हैं, जिन्हें कोई बाद का ब्लॉक नहीं बदल सकता: अमान्य प्रूफ़, ऐसा बंडल डाइजेस्ट जो उसके प्रूफ़ द्वारा प्रकाशित डाइजेस्ट से भिन्न है, ग़लत मिंट हस्ताक्षर, ग़लत चेन id, सीमा से बड़ा कोई भाग, लेनदेन के भीतर दोहराया गया नलिफ़ायर या कमिटमेंट, ग़लत आकार का एन्वेलप, अनुपस्थित या बेमेल ऑथ प्रूफ़, ग़लत गैस सीमा घोषित करने वाला बंडल या ऑथ प्रूफ़। जो अस्वीकृति उस क्षण नोड की स्थिति पर निर्भर करती है — खर्च हो चुका नलिफ़ायर, विंडो से बाहर का एंकर या time, न्यूनतम सीमा से कम शुल्क (जो चेन 20 पर गैस कीमतों के साथ बदलती है), अज्ञात प्रोग्राम, रजिस्टर नॉन्स, पुराना पड़ चुका invoke रीड — वह याद नहीं रखी जाती और unknown दिखाती है। खाली सूची या 64 से अधिक हैश के लिए -32602।

rand_mint (testnet फ़ॉसेट)

पैरामीटर [address] या [address, amount]; address एक rand1… पता है, amount इकाइयों की एक स्ट्रिंग जो अधिकतम 100000000000 (100 RAND, डिफ़ॉल्ट) हो सकती है। परिणाम: मिंट लेनदेन हैश। केवल उस चेन पर उपलब्ध जिसके जेनेसिस में "faucet": true हो; अन्यथा -32000 faucet is disabled on this chain। ऑब्ज़र्वर नोड उत्तर देता है faucet mints are signed by validators; ask a validator node।

जिस चेन का जेनेसिस staking.faucet_recipients निर्धारित करता है, जैसा चेन 20 का करता है (16 वॉलेट), वहाँ केवल सूचीबद्ध वॉलेट को ही भुगतान किया जा सकता है: किसी अन्य पते पर मिंट the faucet may not mint to this recipient (not in staking.faucet_recipients) के साथ अस्वीकार होता है। चेन 20 का जेनेसिस staking.faucet_minters (18 वैलिडेटर कुंजियाँ) भी निर्धारित करता है: केवल सूचीबद्ध कुंजी ही मिंट पर हस्ताक्षर कर सकती है। फ़ॉसेट का प्रति-एपॉक बजट भी है, staking.faucet_budget_per_epoch (चेन 20 पर प्रति 1,000-ब्लॉक एपॉक 10,000 RAND); इससे अधिक का मिंट FaucetBudgetExhausted के साथ अस्वीकार होता है, जो एक स्टेट निर्णय है और पूल से निकलने के बाद unknown दिखाता है।

फ़ॉसेट की दर-सीमा प्रत्येक नोड प्रोसेस पर लागू होती है: लगातार आठ मिंट, जिसके बाद क्षमता प्रति सेकंड एक की दर से फिर भरती है। इससे आगे कॉल का उत्तर होता है faucet is rate limited on this node (8 mints back to back, refilling at 1/s); try again shortly। इसलिए फ़ॉसेट की बाढ़ ब्रिज के PauseMints से पहले पूल को नहीं भर सकती। अन्य तीन ब्रिज-गवर्नेंस कार्रवाइयों की तरह PauseMints पर भी पूल का mempool full इनकार लागू नहीं होता और ब्लॉक में उसे सबसे पहले रखा जाता है।

चेन 14 से मिंट खुला (opened) होता है: Mint कार्रवाई cm और amount के साथ नोट के pk, time और r भी लेकर चलती है। प्रवेश के समय कमिटमेंट फिर से गणना किया जाता है, और जो cm इन मानों पर नहीं खुलता उसे अस्वीकार कर दिया जाता है (the mint's commitment does not open to its published note and amount)। मिंटर सातों फ़ील्ड पर डोमेन rand-mint-2 के अंतर्गत हस्ताक्षर करता है; चेन 20 (binding_domain: 1) पर rand-mint-3 के अंतर्गत, जिसमें जेनेसिस हैश सबसे पहले आता है। इसलिए फ़ॉसेट नोट का स्वामी और राशि सार्वजनिक होते हैं, जैसे किसी withdraw का भुगतान सार्वजनिक होता है। rand_mint के पैरामीटर नहीं बदले हैं।

rand_estimateFee

पैरामीटर [spec], जो इनमें से एक है: {"kind":"bundle"}, {"kind":"deploy","words":n,"public_words":m}, {"kind":"call","tier":t,"bytes":b,"gas":g}, जहाँ t का मान 10, 12, 14, 16, 18 या 20 है। परिणाम: इकाइयों में न्यूनतम शुल्क, स्ट्रिंग के रूप में। {"kind":"bundle"} का मान "1000000" है। public_words (वैकल्पिक, डिफ़ॉल्ट 0) का भुगतान कोड की तरह प्रति वर्ड होता है, इसलिए शुल्क n + m वर्ड के डिप्लॉय शुल्क के बराबर होता है। bytes (वैकल्पिक, डिफ़ॉल्ट 0) कॉल के प्रूफ़ की लंबाई और उसके इनपुट एनवेलप की लंबाई का योग है।

कॉल का मूल्य कैसे तय होता है, यह rand_getLimits के gas_metering पर निर्भर करता है:

• "circuit", ऐसी चेन जिसका अपना gas सेक्शन है, जैसे चेन 20। gas वह गैस सीमा है जो कॉल का प्रूफ़ घोषित करता है, और यह अनिवार्य है: इसके बिना कॉल का उत्तर होता है -32602 under the gas section a call estimate needs its gas। उत्तर है 1,000,000 + gas_price × gas + byte_price × ⌈bytes / 1024⌉, जो टिप की वर्तमान कीमतों पर निकाला जाता है, यानी उन कीमतों पर जो rand_getLimits देता है। चेन 20 की न्यूनतम कीमतों 100 और 800 पर, 20,479 गैस घोषित करने वाली और 1,300,000 बाइट प्रूफ़ व एनवेलप वाली कॉल का शुल्क "4063900" है। कीमतें हर ब्लॉक के साथ बदलती हैं, इसलिए अनुमान भेजने से ठीक पहले लगाएँ।
• "header", सेक्शन-रहित चेन पर नोड-स्तरीय गैस नीति। कॉल spec keccak_log_height और sha256_log_height लेता है (वैकल्पिक, डिफ़ॉल्ट 0, प्रत्येक 0 से 40 के बीच, अन्यथा -32602)। ये वे हैश-तालिका ऊँचाइयाँ हैं जो प्रूफ़ हेडर घोषित करता है। उत्तर लेजर के टियर न्यूनतम और उस हेडर के गैस न्यूनतम में से बड़ा मान होता है। gas सेक्शन के अंतर्गत ये दोनों ऊँचाइयाँ स्वीकार की जाती हैं, पर उपयोग नहीं होतीं।
• null, दोनों में से कोई नहीं। केवल लेजर की टियर अनुसूची लागू होती है: निःशुल्क सीमा (2,097,152 + 18,432 बाइट) तक कॉल का शुल्क उसके टियर का शुल्क है। उससे ऊपर प्रत्येक KiB पर 1,000 इकाइयाँ जुड़ती हैं, और अधूरा KiB पूरा गिना जाता है।

v0.6.8 से {"kind":"invoke", …, "created_cells": c} किसी RPL-2 invoke का मूल्य निकालता है। इसमें कॉल spec के सभी फ़ील्ड होते हैं, और साथ में created_cells (वैकल्पिक, डिफ़ॉल्ट 0, अधिकतम max_writes, अन्यथा -32602), यानी वे सेल जो ट्रांज़िशन बनाएगा। प्रत्येक सेल पर चेन का cell_fee (rand_getLimits.program_state) जुड़ता है। इनकी गिनती कॉलर करता है: ऐसे सेल में शून्येतर मान लिखना, जिसे rand_getProgramCell शून्य के रूप में पढ़ता है। चेन 20 पर, ऊपर वाली कॉल दो नए सेल के साथ "24063900" होती है। जिस चेन पर program_state सेक्शन नहीं है, वहाँ यह kind -32602 देता है।

अनुसूची शुल्क में दी गई है।

पूल

rand_getTreeInfo

पैरामीटर []। परिणाम { "next_index": 41, "root": "6b1d…c4", "nullifiers": 12 }: लीफ़ की संख्या, वर्तमान रूट, और कितने नोट खर्च हो चुके हैं।

rand_getCommitments

पैरामीटर [from_index] या [from_index, limit]। परिणाम: from_index से शुरू होने वाले लीफ़ का एक पृष्ठ, सबसे पुराने पहले। limit कितना भी बड़ा हो, अधिकतम 1,000 पंक्तियाँ लौटती हैं।

[ { "index": 40, "cm": "2a9f…07", "height": 37,
    "envelope": { "kem_ct": "b41c…", "to_receiver": "77e0…", "to_sender": "0c31…", "body": "9dd2…" } } ]

rand_getNullifiers

पैरामीटर [from_height] या [from_height, limit]। परिणाम: उस ऊँचाई से आगे प्रकाशित हर नलीफ़ायर, उसी 1,000-पंक्ति सीमा के साथ। कोई पृष्ठ किसी ऊँचाई के बीच में रुक सकता है; अगला पृष्ठ अब तक देखी गई सबसे ऊँची ऊँचाई से माँगें।

[ { "height": 37, "nullifier": "8c04…d1" }, { "height": 41, "nullifier": "12be…9a" } ]

rand_getCompactBlocks

पैरामीटर [from_height, to_height], दोनों अनिवार्य। परिणाम: प्रति ब्लॉक एक पंक्ति, सबसे पुराने पहले, जिसमें वही होता है जिसकी लाइट वॉलेट को आवश्यकता है, और कुछ नहीं:

[ { "height": 192, "hash": "63f6…08", "timestamp_ms": 1788000123456,
    "commitments": [],
    "transactions": [
      { "hash": "4f2c…e7",
        "commitments": [ { "index": 40, "cm": "2a9f…07", "envelope": { "kem_ct": "…", "to_receiver": "…", "to_sender": "…", "body": "…" } } ],
        "nullifiers": ["8c04…d1", "5e77…20", "03aa…6f", "e19b…42"] } ] } ]

यहाँ बंडल वाले हर ट्रांज़ैक्शन के चार नोट और चार नलीफ़ायर होते हैं। ये उसके चार स्लॉट हैं, जिनमें डमी स्लॉट भी शामिल हैं, और कोई भी पाठक उन्हें असली स्लॉट से अलग नहीं पहचान सकता (उदाहरण में केवल पहली कमिटमेंट पंक्ति दिखाई गई है)। v0.6.8 से कुछ ट्रांज़ैक्शन के पास इन चार के बाद और नोट भी होते हैं। invoke के पास प्रति भुगतान एक नोट होता है, पहले pays फिर mints, और हर नोट के साथ उस भुगतान का अपना एनवेलप होता है, ताकि प्राप्तकर्ता ट्रायल डिक्रिप्शन से उसे ढूँढ सके। ब्रिज शुल्क वाली चेन पर, जैसे चेन 20, bridge_burn के पास उसका ट्रेज़री शुल्क नोट होता है, और bridge_attest के पास उसके डिपॉज़िट के बाद उसका शुल्क नोट होता है। शुल्क नोट का एनवेलप खाली होता है और किसी के लिए सील नहीं किया जाता: ट्रेज़री वॉलेट ट्रांज़ैक्शन के सार्वजनिक फ़ील्ड से नोट फिर से बना लेता है।

प्रति कॉल अधिकतम 128 ब्लॉक (बड़ी रेंज इस सीमा तक घटा दी जाती है)। पहले ब्लॉक के बाद अधिकतम 1,000 नोट लौटते हैं; पहला ब्लॉक हमेशा पूरा दिया जाता है। अंतिम लौटाई गई height में एक जोड़कर आगे बढ़ें। ब्लॉक-स्तरीय commitments ऐरे में ऊँचाई 0 पर जेनेसिस डिपॉज़िट होते हैं और अन्य सभी ब्लॉक में यह खाली रहता है। Withdraw और BridgeAttest से बने नोट उनके ट्रांज़ैक्शन के अंतर्गत दिखते हैं। उलटी रेंज या कोई सीमा न होने पर -32602 लौटता है।

rand_getAnchor

हेड के लिए पैरामीटर [], या [height]। परिणाम { "height": 192, "root": "6b1d…c4" }, या ऐसी ऊँचाई के लिए -32001 जिसका कोई एंकर दर्ज नहीं है। केवल ब्लॉक के अंत के रूट ही एंकर होते हैं। नोड किसी पुरानी ऊँचाई का उत्तर दे सकता है, पर किसी बंडल का एंकर तभी स्वीकार्य है जब वह अंतिम proof_window_blocks रूट में से एक हो: चेन 20 पर 1,024, और चेन 19 तक 256। हेड के आधार पर बनाएँ।

rand_getWitness

पैरामीटर [index]। ट्री के अंत से आगे परिणाम null होता है, अन्यथा उस लीफ़ का Merkle पथ, लीफ़ से शुरू होकर, ठीक 32 स्तर, और साथ में ट्री का वर्तमान रूट:

{ "index": 40, "root": "6b1d…c4", "path": ["0000…00", "f2a1…3b", "…"] }

यह नोड द्वारा दिया जाने वाला सबसे महँगा रीड है (यह पूरे depth-32 ट्री को फिर से बनाता है), और यही एकमात्र अनुरोध है जो कॉलर के बारे में कुछ उजागर करता है। एक नोड एक समय में अधिकतम दो ट्री पुनर्निर्माण चलाता है, rand_getWitness और rand_getWitnesses मिलाकर। जो अनुरोध स्लॉट के लिए 10 s से अधिक प्रतीक्षा करता है, उसे -32000 witness builds are busy on this node; retry shortly के साथ अस्वीकार कर दिया जाता है।

rand_getWitnesses

पैरामीटर [[index, …]], 1 से 32 लीफ़ इंडेक्स। परिणाम { "root": "…", "witnesses": [ { "index": 7, "path": ["…"] }, { "index": 9, "path": null } ] }: यह एक ही ट्री निर्माण में कई लीफ़ पर rand_getWitness चलाता है, ताकि कई नोट का प्रूफ़ बनाने वाला वॉलेट पुनर्निर्माण का भुगतान केवल एक बार करे। ट्री के अंत से आगे का इंडेक्स अपनी प्रविष्टि में path: null देता है। खाली सूची या 32 से अधिक इंडेक्स पर -32602 लौटता है।

व्यूइंग की और प्रकटीकरण

rand_importViewingKey

पैरामीटर [viewing_key] या [viewing_key, rescan_from_height], जिसमें की 64 हेक्स वर्णों के रूप में होती है। परिणाम { "imported": true, "rescan_from_height": 0, "viewing_keys": 3 }। नोड की को केवल मेमोरी में रखता है: प्रति नोड अधिकतम 64, और रीस्टार्ट पर मिट जाती हैं। जो की पहले से रखी है, उसे फिर इम्पोर्ट करने का कोई प्रभाव नहीं होता ("imported": false)। इम्पोर्ट कभी स्कैन नहीं करता; स्कैन अगली मेथड चलाती है। विकृत की पर -32602; 65वीं की पर -32000।

तीनों व्यूइंग-की मेथड केवल लूपबैक कॉलर को उत्तर देती हैं और बाकी सभी को -32000 के साथ अस्वीकार करती हैं, जब तक नोड --rpc-viewing-open के साथ किसी प्रमाणीकरण करने वाली व्यवस्था के पीछे न चल रहा हो। rand_removeViewingKey ([viewing_key] → { "removed": bool, "viewing_keys": n }) एक स्लॉट खाली करती है और की को शून्य से अधिलेखित कर देती है। रजिस्ट्री में प्रविष्टियाँ की की एकतरफ़ा id, blake3("rand-viewing-registry-id-1" ‖ nk), से पहचानी जाती हैं, स्वयं की से कभी नहीं। इसलिए इम्पोर्ट ही की की एकमात्र दीर्घकालिक प्रति है, और हटाने पर वह मिट जाती है। अनुरोध का अपना JSON टेक्स्ट और ट्रायल डिक्रिप्शन के दौरान बनी अस्थायी प्रतियाँ नहीं मिटाई जातीं।

rand_getViewingNotes

पैरामीटर [viewing_key] या [viewing_key, from_index, limit] (limit का डिफ़ॉल्ट और अधिकतम 1,000)। हर कॉल की के स्कैन को अधिकतम 10,000 लीफ़ आगे बढ़ाती है, फिर पृष्ठ देती है:

{ "scanned_index": 10041, "next_index": 10041, "complete": true,
  "notes": [
    { "index": 40, "cm": "2a9f…07", "height": 37, "role": "received",
      "note": { "pk": "…", "from": "…", "amount": "1500000000", "asset": 0, "time": 5, "memo": "coffee" },
      "nullifier": "8c04…d1", "spent": false },
    { "index": 43, "cm": "b310…88", "height": 39, "role": "sent",
      "note": { "pk": "…", "from": "…", "amount": "25000000", "asset": 0, "time": 9, "memo": null },
      "nullifier": null, "spent": null } ] }

role या तो received होता है (एनवेलप प्राप्तकर्ता के रूप में खुला और नोट में की का pk दर्ज है) या sent (आउटगोइंग व्यूइंग की से खुला)। नोट का memo प्रेषक का एन्क्रिप्टेड मेमो है, अधिकतम 510 बाइट का UTF-8 टेक्स्ट। कोई मेमो न होने पर, या उसका फ़ील्ड विकृत रूप में खुलने पर, यह null होता है; विकृत मेमो के कारण प्राप्तकर्ता नोट कभी नहीं खोता। मेमो में कोई भी कुछ भी लिख सकता है, इसलिए उसे अविश्वसनीय मानकर दिखाएँ। जो की इस नोड ने इम्पोर्ट नहीं की है, उसके लिए -32001 लौटता है।

rand_checkTransaction

पैरामीटर [hash, key], जिसमें key प्रति-ट्रांज़ैक्शन TxKey है, 64 हेक्स वर्णों के रूप में। अज्ञात हैश के लिए परिणाम null होता है, अन्यथा वह जानकारी जो की प्रकट करती है:

{ "tx": "4f2c…e7", "height": 192,
  "disclosed": [ { "output": "bundle:0", "cm": "2a9f…07", "index": 40,
                   "note": { "pk": "…", "from": "…", "amount": "1500000000", "asset": 0, "time": 5, "memo": "invoice 7" } } ] }

Stateless: कुंजी कॉल के साथ ही हटा दी जाती है। output बंडल के चार आउटपुट स्लॉट के लिए bundle:0 … bundle:3 है (स्लॉट 0–1 निजी एसेट के आउटपुट, स्लॉट 2–3 RAND के आउटपुट, डमी सहित)। ब्रिज सत्यापन के डिपॉज़िट एनवेलप के लिए यह deposit है। किसी TokenMint के नोट के लिए token_mint है और किसी RegisterToken के प्रारंभिक मिंट के लिए initial_mint। फ़ॉसेट मिंट के एकमात्र एनवेलप के लिए यह mint:0 है। (v0.6.8) किसी invoke द्वारा भुगतान किए गए नोटों के लिए यह payout:0 … payout:3 है, जिनकी संख्या ट्रांज़िशन में उनके स्थान के अनुसार है: पहले pays, फिर mints। दूसरे बंडल के साथ asset_bundle:* भी हटा दिया गया है। ब्रिज शुल्क वाली चेन पर deposit शुद्ध डिपॉज़िट खोलता है, यानी सकल राशि में से शुल्क घटाकर। प्रकट किया गया note अपना asset साथ रखता है। यह कॉल, उस कुंजी के साथ जिसके अंतर्गत प्रेषक ने सील किया था, वह एकमात्र स्थान है जहाँ RPC बताता है कि किसी ट्रांसफ़र ने कौन-सा एसेट स्थानांतरित किया। इसमें memo भी रहता है, जैसा rand_getViewingNotes में होता है: जो कुंजी नोट खोलती है, वही उसी सील किए गए मुख्य भाग से memo भी खोलती है। गलत कुंजी { "disclosed": [] } लौटाती है। इसे उस ट्रांज़ैक्शन से अलग नहीं पहचाना जा सकता जो कुछ भी प्रकट नहीं करता। withdraw और genesis alloc के एनवेलप आज़माए नहीं जाते। वे नोड के भीतर ऐसी कुंजियों से सील किए जाते हैं जो तुरंत हटा दी जाती हैं, इसलिए उनके लिए कोई TxKey मौजूद नहीं होती। फ़ॉसेट मिंट का एनवेलप आज़माया जाता है: उसका प्राप्तकर्ता एनवेलप के KEM भाग से कुंजी पुनः प्राप्त करता है (rand tx-key)।

ट्रांज़ैक्शन

rand_getTransaction

पैरामीटर [hash]। परिणाम कमिट होने तक null रहता है, उसके बाद:

{
  "height": 192, "index": 0, "block_hash": "63f6…08",
  "tx": {
    "hash": "4f2c…e7", "chain_id": 20,
    "bundle": { "anchor": "6b1d…c4",
                "nullifiers": ["8c04…d1", "5e77…20", "03aa…6f", "e19b…42"],
                "commitments": ["2a9f…07", "b310…88", "77c1…0e", "5d20…b3"],
                "fee": "1000000", "burn_a": "0", "burn_r": "0", "burn_asset": 0, "time": 5,
                "proof_len": 1490435, "envelope_len": [1860, 1860, 1860, 1860],
                "auth_commit": "9217…ee9e", "auth_proof_bytes": 1361161 },
    "action": { "kind": "none" }
  }
}

बंडल-रहित कार्रवाइयों पर bundle null होता है। प्रूफ़ और एनवेलप की केवल लंबाई बताई जाती है। chain 20 पर हर स्लॉट के लिए envelope_len 1,860 है, क्योंकि उसका genesis नोट एनवेलप को इसी आकार पर निर्धारित करता है (rand_getLimits में envelope_bytes)। chain 14 से 17 तक यह 1,348 था। auth_commit और auth_proof_bytes विभाजित प्राधिकरण के फ़ील्ड हैं (chain 17 से)। पहला सार्वजनिक प्रतिबद्धता c = H(AUTH, nk, salt) है, जिसे बंडल प्रूफ़ और auth प्रूफ़ दोनों प्रकाशित करते हैं। दूसरा auth प्रूफ़ की लंबाई है। hc_auth रहित चेन पर ये शून्य और 0 होते हैं।

bundle छिपे-एसेट वाला बंडल है (chain 14 से)। इसमें चार इनपुट स्लॉट और चार आउटपुट स्लॉट होते हैं, इसलिए डमी सहित हमेशा चार nullifiers, चार commitments और चार envelope_len होते हैं। हर ट्रांज़ैक्शन में अधिकतम एक बंडल होता है, दूसरा बंडल नहीं होता। इसमें कोई asset फ़ील्ड नहीं है: स्लॉट 0–1 एक निजी एसेट रखते हैं और स्लॉट 2–3 RAND। कोई भी सार्वजनिक जानकारी यह नहीं बताती कि स्लॉट 0–1 ने कौन-सा एसेट स्थानांतरित किया। RAND का ट्रांसफ़र और किसी भी RPL टोकन का ट्रांसफ़र, दोनों "kind": "none" होते हैं, जिनमें burn_a, burn_r और burn_asset तीनों 0 होते हैं। दोनों का स्वरूप फ़ील्ड-दर-फ़ील्ड एक जैसा है। कोई token_transfer kind नहीं है। पूल से बाहर जाने वाले मूल्य के बारे में बंडल का एकमात्र सार्वजनिक कथन ये तीन burn फ़ील्ड हैं:

• burn_a / burn_asset — बर्न की गई निजी एसेट की राशि, और कौन-सा एसेट। ये token_burn या bridge_burn पर शून्येतर होते हैं, जहाँ ये कार्रवाई के amount और asset के बराबर होते हैं। ये उस invoke पर भी शून्येतर होते हैं जिसका inflow deposit या burn है।
• burn_r — बर्न किया गया RAND। यह bond पर (उसके amount के बराबर), register_aggregator पर, और उस invoke पर शून्येतर होता है जो प्रोग्राम के वॉल्ट में RAND जमा करता है।
• fee — RAND शुल्क, जो हमेशा स्लॉट 2–3 से आता है।

कार्रवाइयों का प्रस्तुतीकरण (हर amount, relayer_fee और initial_amount दशमलव स्ट्रिंग है। किसी टोकन की राशियाँ उसकी अपनी इकाइयों में होती हैं, RAND की इकाइयों में नहीं):

किसी टोकन का पंजीकरण और उसके मिंट सार्वजनिक होते हैं, जैसे ब्रिज डिपॉज़िट होता है। मिंट किए गए नोट का हर word कार्रवाई में मौजूद होता है (उसका from चेन का निश्चित MINT_FROM है)। इसलिए प्राप्तकर्ता बिना कुछ डिक्रिप्ट किए इन्हीं फ़ील्ड से नोट फिर से बना लेता है। kind स्ट्रिंग bridge_attest, token_mint, register_token और invoke पर वॉलेट का स्कैन आधारित है, और ये एक टेस्ट द्वारा स्थिर रखी गई हैं।

chain 20 की ऊँचाई 3,079 पर एक invoke, जिसने एक सेल पढ़ा, उसे हटाया, और वॉल्ट से दो नोटों का भुगतान किया:

{ "kind": "invoke", "program": "aaaf…4b21", "proof_len": 1433874, "input_envelope_len": null,
  "transition": {
    "reads":  [{ "key": "0100…fa98", "value": "0000000004000000…00000000" }],
    "writes": [{ "key": "0100…fa98", "value": "0000000000000000000000000000000000000000000000000000000000000000" }],
    "inflow": "none",
    "pays":  [{ "asset": 0, "amount": "1000000000", "recipient": "rand1…", "time": 3027, "r": "87e6…9a67", "cm": "2555…6487" },
              { "asset": 4, "amount": "2000000000", "recipient": "rand1…", "time": 3027, "r": "b833…f390", "cm": "2b70…f204" }],
    "mints": [] } }

यह सब डिज़ाइन के अनुसार सार्वजनिक है। reads वे सेल हैं जिन्हें प्रोग्राम ने पढ़ा, उन मानों के साथ जो उसने पढ़े। प्रूफ़ इन्हीं के आधार पर बनाया गया था, और जब तक ये मान बने न रहें, लेजर ट्रांज़ैक्शन को अस्वीकार करता है। writes वे सेल हैं जिनमें उसने लिखा। 64 शून्यों का लिखित मान सेल को हटा देता है। सेल की कुंजी या मान एक Word8 होता है। जो अंदर आया, वह बंडल का है। burn_r प्रोग्राम के वॉल्ट में जमा किया गया RAND है। burn_asset का burn_a वह टोकन है जिसे inflow नामित करता है: वॉल्ट में जाने पर deposit, प्रोग्राम का अपना टोकन होने पर burn, और burn_a 0 होने पर none। जो बाहर गया, वह हर भुगतान के लिए चेन द्वारा गणना किया गया एक नोट है: पहले वॉल्ट से pays, फिर ऐसे टोकन के mints जिसका मिंट प्राधिकार यही प्रोग्राम है। हर नोट का हर word यहाँ token_mint के फ़ील्ड नामों के अंतर्गत मौजूद है। time बंडल का है, cm वह लीफ़ है जिसे चेन ने जोड़ा, और नोट का from चेन का निश्चित PROGRAM_FROM है। प्रोग्राम के आठ आउटपुट words रसीद पर होते हैं, जैसे किसी कॉल के होते हैं।

किसी भी ट्रांसफ़र के उत्तर में प्रेषक, प्राप्तकर्ता, nonce, राशि या एसेट नहीं होता, क्योंकि संग्रहीत ट्रांसफ़र में ऐसा कोई फ़ील्ड मौजूद ही नहीं है।

rand_getRawTransaction

पैरामीटर [hash]। परिणाम: bincode hex के रूप में पूरा कमिट किया गया ट्रांज़ैक्शन, प्रूफ़ बाइट्स सहित। एग्रीगेटर को इसी की आवश्यकता होती है, और rand_getTransaction इसे कभी प्रस्तुत नहीं करता।

प्रोग्राम और रसीदें

rand_getProgram

पैरामीटर [program_id]। परिणाम null या { "id", "base_pc", "words_len", "code_hash", "deployed_at", "public_words_len", "public_digest" }। इसमें कोई deployer फ़ील्ड नहीं है, क्योंकि deploy का भुगतान एक बंडल करता है। public_words_len प्रोग्राम के deploy-समय के सार्वजनिक इनपुट की लंबाई है (न होने पर 0)। public_digest उसका डाइजेस्ट है, यानी वह मान जिसके विरुद्ध हर कॉल के प्रूफ़ की जाँच होती है, या न होने पर null।

rand_getProgramCode

पैरामीटर [program_id]। परिणाम null या { "base_pc": 0, "words": [ … ] }।

rand_getProgramPublic

पैरामीटर [program_id]। परिणाम: प्रोग्राम के डिप्लॉय-समय के सार्वजनिक वर्ड, एक हेक्स स्ट्रिंग के रूप में, जिसमें हर वर्ड अपने 4 लिटिल-एंडियन बाइट के रूप में होता है (प्रति वर्ड 8 हेक्स अंक): [1, 2, 0xdeadbeef] का रूप "0100000002000000efbeadde" है। सार्वजनिक इनपुट के बिना डिप्लॉय हुए प्रोग्राम के लिए "" लौटता है। जिस id का कोई प्रोग्राम नहीं है, उसके लिए null लौटता है। किसी कॉल का प्रूफ़ बनाने वाला वॉलेट ये वर्ड प्रूवर को देता है। लेजर प्रूफ़ के कमिटमेंट को प्रोग्राम के public_digest से जाँचता है।

rand_getProgramCell

v0.6.8, RPL-2। पैरामीटर [program_id, key] हैं। कुंजी एक Word8 होती है, जो 64 हेक्स अंकों में दी जाती है (0x के साथ या उसके बिना)। परिणाम { "key": "<64 hex>", "value": "<64 hex>" } है। जिस सेल में प्रोग्राम ने कभी कुछ नहीं लिखा, या शून्य लिखे (जिससे वह हट जाती है), वह 64 शून्यों के रूप में पढ़ी जाती है। “अनुपस्थित” का यही एकमात्र निरूपण है। जिस प्रोग्राम को किसी ने डिप्लॉय नहीं किया, उसकी हर कुंजी भी ऐसे ही पढ़ी जाती है, क्योंकि प्रोग्राम के अस्तित्व की जाँच नहीं होती। जिस चेन में program_state अनुभाग नहीं है, उस पर { "enabled": false } लौटता है। सेल अपनी संरचना से ही सार्वजनिक होती है: किसी invoke के reads बनाने के लिए वॉलेट यही पढ़ता है।

rand_getProgramCells

v0.6.8। पैरामीटर [program_id, { "after": "<64 hex>" | null, "limit": n }] हैं। ऑब्जेक्ट वैकल्पिक है। परिणाम { "cells": [{ "key", "value" }, …], "next": "<64 hex>" | null } है: प्रोग्राम की सेलें कुंजी के क्रम में (आठ वर्डों की अचिह्नित तुलना से), after के बाद से शुरू होकर, अधिकतम limit तक (जो 1 से 1,000 के बीच सीमित रहता है)। जब और सेलें बाकी हों, तो next परोसी गई अंतिम कुंजी होती है। उसे after के रूप में वापस भेजें। अंतिम पृष्ठ पर यह null होता है। जिस प्रोग्राम में कोई सेल नहीं है, उसका उत्तर { "cells": [], "next": null } होता है। अनुभाग न होने पर { "enabled": false } लौटता है।

rand_getProgramVault

v0.6.8। पैरामीटर [program_id]। परिणाम [{ "asset": 0, "amount": "123" }, …] है, जो एसेट इंडेक्स के आरोही क्रम में होता है। 0 RAND है, और हर दूसरा इंडेक्स टोकन रजिस्ट्री का है। राशियाँ एसेट की अपनी इकाइयों में दशमलव स्ट्रिंग के रूप में होती हैं। शून्य वाली पंक्ति मौजूद ही नहीं होती, इसलिए खाली वॉल्ट [] होता है। जिस प्रोग्राम को किसी ने डिप्लॉय नहीं किया, उसका उत्तर भी [] होता है। अनुभाग न होने पर { "enabled": false } लौटता है। मूल्य वॉल्ट में किसी invoke के बंडल से आता है (burn_r से, और जब inflow का मान deposit हो तो burn_asset के burn_a से भी)। वह उन नोटों के रूप में बाहर जाता है जिनके नाम ट्रांज़िशन के pays में होते हैं।

rand_getLimits

पैरामीटर []। परिणाम: ट्रांज़ैक्शन बनाने के लिए वॉलेट को चेन के जेनेसिस से जो चाहिए, वह सब। इसमें पाँच कॉल सीमाएँ, नोट-एनवेलप का आकार, v0.6 स्विच, auth गेस्ट और गैस की शर्तें आती हैं। v0.6.8 से इसमें audit-v6 जेनेसिस फ़ील्ड और प्रोग्राम-स्टेट सीमाएँ भी आती हैं। चेन 20 पर:

{ "max_program_words": 65535, "max_proof_bytes": 4194304, "max_block_bytes": 20971520,
  "max_call_envelope_bytes": 65536, "max_program_public_words": 32768,
  "envelope_bytes": 1860, "hardening_v6": true,
  "hc_auth": "1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1",
  "gas_metering": "circuit", "gas_price": "100", "byte_price": "800",
  "bundle_gas_limit": 20479, "adjust_bps": 1250,
  "max_gas_price": "10000", "max_byte_price": "80000", "byte_load": "paying",
  "admission_by_vote": true, "testnet": true, "slashing": null, "binding_domain": 1,
  "proof_window_blocks": 1024,
  "program_state": { "cell_fee": "10000000", "max_reads": 8, "max_writes": 8, "max_payouts": 4 } }

जिस जेनेसिस में पाँच सीमा फ़ील्ड नहीं हैं (चेन 12), उसे 4096, 2097152, 4194304, 18432 और 0 मिलते हैं। चेन 13 से 15 पर max_proof_bytes का मान 8,388,608 था।

जो नोड किसी फ़ील्ड से पहले का है, वह उस फ़ील्ड के बिना उत्तर देता है। इस उत्तर में कुछ भी प्रमाणीकृत नहीं है, इसलिए वॉलेट envelope_bytes को केवल नोड के कहने पर स्वीकार नहीं करता। नोड कुछ भी उत्तर दे, rand वॉलेट चेन id 14 से 17 पर पुराना एनवेलप ही सील करता है। अन्य क्लाइंट को भी ऐसा ही करना चाहिए।

rand_getReceipt

पैरामीटर [tx_hash]। कॉल कमिट होने तक परिणाम null होता है। उसके बाद परिणाम { "tx", "program", "tier": 14, "outputs": [1, 0, 25, 0, 0, 0, 0, 0], "height": 17, "index": 0, "h_in": "9c0e…7f", "h_pub": null } होता है। इसमें effect फ़ील्ड नहीं होता। h_pub प्रोग्राम के डिप्लॉय-समय के उस सार्वजनिक इनपुट का डाइजेस्ट है जिसके विरुद्ध कॉल का प्रूफ़ जाँचा गया। जिस प्रोग्राम में सार्वजनिक इनपुट नहीं है, उसके लिए यह null होता है। invoke (v0.6.8) की रसीद कॉल जैसी ही होती है, और rand_getReceipts तथा receipts टॉपिक उसे बिना बदले देते हैं।

rand_getReceipts

पैरामीटर [program_id, from_height, to_height, limit?]। परिणाम { "receipts": [ … ], "next_height": 2051 } है: program_id की वे रसीदें जिनके लिए from_height <= height <= to_height है। ये ऊँचाई और फिर इंडेक्स के क्रम में होती हैं, और हर एक ठीक rand_getReceipt जैसा ऑब्जेक्ट होती है। limit का डिफ़ॉल्ट और अधिकतम मान 256 है, और यह किसी ऊँचाई को कभी नहीं बाँटता। जब किसी पृष्ठ में limit रसीदें आ जाएँ, तब भी वह उस ऊँचाई की बाकी रसीदें परोसता है। next_height वह पहली ऊँचाई है जो परोसी नहीं गई। जब पृष्ठ to_height पर समाप्त हुआ हो, तो यह null होता है। to_height के from_height से कम होने पर -32602 लौटता है।

rand_getCallEnvelope

पैरामीटर [tx_hash]। परिणाम null होता है, या हेक्स में { "tx", "h_in", "kem_ct", "to_sender", "to_auditor", "body" }। यह कॉल का सील किया हुआ इनपुट ट्रांसक्रिप्ट है, जो ज्यों-का-त्यों परोसा जाता है। नोड के पास इसे खोलने वाली कोई कुंजी नहीं होती। तीन स्थितियों में null लौटता है: कॉल ने कोई एनवेलप प्रकाशित नहीं किया (--no-envelope), ट्रांज़ैक्शन कॉल नहीं है, या कोई रसीद नहीं है।

स्टेकिंग और आपूर्ति

rand_getValidators

पैरामीटर []। परिणाम: रजिस्टर की हर प्रविष्टि के लिए एक पंक्ति, पते के क्रम में, और राशियाँ दशमलव स्ट्रिंग के रूप में:

[{ "address": "…", "stake": "1000000000000",
   "pending": [{ "release_epoch": 41, "amount": "5000000000" }],
   "rewards": "4000000", "payout": "rand1…", "nonce": 3, "active": true, "jailed_until": null }]

jailed_until (v0.6.8) वह पहला एपॉक है जिसमें स्लैश की गई कुंजी फिर से सेट में आ सकती है (स्थायी रूप से बाहर होने पर 18446744073709551615)। कुंजी जेल में न हो तो यह null होता है। चेन 20 में staking.slashing नहीं है, इसलिए वहाँ यह हमेशा null होता है।

rand_getAdmitted

v0.6.8। Params []। परिणाम { "admission_by_vote": true, "max": 256, "admitted": ["<address>", …] }: वे कुंजियाँ जिन्हें वैलिडेटर सेट ने AdmitValidator के माध्यम से मत देकर प्रवेश दिया है और जिनका पंजीकरण अभी नहीं हुआ है, एड्रेस क्रम में। जिस चेन का जेनेसिस staking.admission_by_vote सेट करता है, जैसा कि चेन 20 का करता है, उस पर किसी नई कुंजी का पंजीकरण करने वाला Bond इन्हीं में से होना चाहिए। max बताता है कि लेजर एक समय में अधिकतम कितनी कुंजियाँ रखता है। इस फ़्लैग के बिना वाली चेन पर admission_by_vote false होता है, सूची सदैव खाली रहती है और पंजीकरण के लिए किसी मत की आवश्यकता नहीं होती। 2026-10-01 को चेन 20 ने "admitted": [] उत्तर दिया।

rand_getEpoch

Params []। परिणाम { "epoch": 41, "epoch_blocks": 1000, "next_set": ["…", "…"] }; next_set एक अनुमान है।

rand_getSupply

Params []। परिणाम:

{ "height": 1998,
  "genesis_deposited": "…", "genesis_staked": "…", "faucet_minted": "…",
  "faucet_epoch": "…", "faucet_minted_in_epoch": "…",
  "withdraw_deposited": "…", "fees_paid": "…", "burned": "…",
  "subsidised": "…", "sealed_blocks": "…", "aggregator_bonds": "…", "slashed": "…",
  "registration_fees_burned": "…",
  "vesting_issued": "…", "vesting_released": "…", "vesting_in_register": "…", "vesting_locked": "…",
  "program_rand_out": "…", "program_rand_held": "…",
  "pool_value": "…", "register_total": "…", "total_supply": "…", "invariant_holds": true }

subsidised, sealed_blocks, aggregator_bonds और slashed केवल एग्रीगेशन चेन पर बदलते हैं। faucet_epoch और faucet_minted_in_epoch फ़ॉसेट का प्रति-एपॉक काउंटर हैं, जिसकी तुलना staking.faucet_budget_per_epoch से होती है (चेन 20 पर सर्वसम्मति स्थिति)। चार vesting_* फ़ील्ड जेनेसिस वेस्टिंग के काउंटर हैं; vesting खंड के बिना वाली चेन पर, जैसी चेन 20 है, ये सभी "0" होते हैं। program_rand_out और program_rand_held (v0.6.8, RPL-2; program_state खंड के बिना "0") में पहला वह RAND है जो invoke ने प्रोग्राम वॉल्ट से नोट के रूप में चुकाया है (पूल पक्ष, pool_value के भीतर), और दूसरा वह जो वॉल्ट में अब भी है (रजिस्टर पक्ष, total_supply के भीतर)। यह RAND किसी invoke के burn_r से प्रवेश करता है, इसलिए पूल पक्ष पर यह burned के भीतर गिना जाता है। registration_fees_burned जेनेसिस tokens.burn_registration_fee के अंतर्गत बर्न किए गए टोकन पंजीकरण शुल्कों का Σ है, जिसे चेन 20 सेट करती है; invariant_holds चेन द्वारा जारी राशि में से इसे और slashed को घटाता है। आपूर्ति इस सर्वसमिका की व्याख्या करता है।

rand_getEmission

Params []। परिणाम { "inflation": "0", "subsidy": null, "faucet": true }। inflation स्थिर रूप से "0" है। subsidy ब्लॉक-एग्रीगेशन अनुसूची है (current, base, halving_blocks, sealed_blocks, next_halving_at), और aggregation खंड के बिना वाली चेन पर, जैसी चेन 20 है, null होती है। faucet वही दर्शाता है जो rand_status दर्शाता है।

ब्रिज

चारों विधियाँ किसी भी चेन पर उत्तर देती हैं; bridge खंड के बिना वाली चेन पर स्थिति { "enabled": false } और रजिस्ट्री [] होती है। चेन 20 के जेनेसिस में यह खंड है, जिसमें ये शामिल हैं: आठ गार्जियन वाला गार्जियन सेट 1 (guardian_set_index 1), आठ PQ गार्जियन, एक पॉज़ कुंजी, जेनेसिस पर burn_sequence 13, एक रीप्ले न्यूनतम सीमा (स्रोत चेन 2, 3 और 4 के लिए min_inbound_sequence 3, और स्रोत चेन 5 के लिए 7), और ब्रिज rules_v2, जिसमें सभी बैकिंग पर मिलाकर प्रति 24-घंटे की विंडो में 4,000 zUSD की वैश्विक मिंट सीमा है। इनके अलावा v0.6.8 में आए दो नए समूह हैं: rotation (PQ-गार्जियन या पॉज़-कुंजी के रोटेशन के लिए नई कुंजियों का स्वामित्व-प्रमाण आवश्यक है, और रोटेशन कमिट होने के 86,400 s बाद प्रभावी होता है) और fees (हर जमा और हर बर्न का 10 bps, जिसे Rand पर ट्रेज़री एड्रेस के लिए zUSD नोट के रूप में रखा जाता है)। चेन 19 पर burn_sequence 8 और न्यूनतम सीमाएँ 1 और 4 थीं, और ये दोनों समूह नहीं थे। चेन 20 के tokens खंड में 1 RAND का registration_fee (बर्न किया जाता है) और प्रति-बैकिंग mint_cap_per_day 10000000000000 (आठ दशमलव पर 100,000 zUSD) है, और यह खंड स्वयं zUSD को सूचीबद्ध करता है: जेनेसिस पर चेन 14 से आगे लाया गया, वही asset id, index 1, सात बैकिंग।

rand_getBridgeState

Params []। परिणाम { "enabled": false }, या:

{
  "enabled": true,
  "emitter": "01…",
  "emitters": { "2": "02…" },
  "guardian_set_index": 0,
  "guardians": ["aabb…"],
  "pq_guardians": ["…"],
  "mint_paused": false,
  "pause_nonce": 0,
  "list_nonce": 0,
  "pause_key": "…",
  "registration_fee": "1000000000",
  "burn_sequence": 1,
  "rotation_nonce": 0,
  "rules_v2": { "global_mint_cap_per_window": "…", "cap_window_secs": 86400,
                "global_minted_in_window": "…", "global_mint_headroom": "…" },
  "min_inbound_sequence": { "2": 2, "3": 2, "4": 2, "5": 2 },
  "rotation_rules": { "delay_secs": 86400, "needs_possession": true },
  "pending_rotations": [],
  "fees": { "mint_bps": 10, "burn_bps": 10, "recipient": "rand1…" },
  "assets": [ … ]
}

कोई बैलेंस नहीं: ब्रिज किया गया मूल्य नोट के रूप में होता है। अब कोई next_index नहीं है: ब्रिज किया गया टोकन जमा किए जाने से पहले उस index के अंतर्गत सूचीबद्ध होता है जो उसके पंजीकरण ने पहले ही तय कर दिया था, इसलिए अनुमान लगाने के लिए कोई index शेष नहीं रहता। सूचीबद्ध टोकन का index assets या rand_getTokens से पढ़ें।

rand_getAssets

Params []। परिणाम: ब्रिज की एसेट रजिस्ट्री, index के आरोही क्रम में, या []:

[{ "index": 1, "chain": 2, "token": "aaaa…", "asset_id": "…", "decimals": 6, "locked": "600",
   "mint_cap_per_day": "10000000000000", "minted_today": "1000", "mint_day": 20350,
   "minted_in_window": "1000", "mint_window_secs": 86400, "mint_headroom": "390000000000" }]

v0.6.8 से हर बैकिंग पंक्ति में, यहाँ और जहाँ भी बैकिंग दी जाती हैं (rand_getBridgeState.assets, तथा rand_getToken, rand_getTokens और rand_getTokenSupply के backings), minted_in_window (दशमलव स्ट्रिंग) और mint_window_secs होते हैं, जो डे-काउंटर चेन पर दोनों null होते हैं, और mint_headroom होता है: हेड के ब्लॉक समय पर सीमाएँ उस बैकिंग में जितनी बड़ी से बड़ी जमा स्वीकार करती हैं, यानी प्रति-बैकिंग सीमा में से उसके द्वारा मिंट की गई राशि घटाकर, और rules v2 के अंतर्गत, रजिस्ट्री-व्यापी विंडो में शेष राशि से अधिक नहीं। mint_headroom पढ़ें, mint_cap_per_day − minted_today नहीं, क्योंकि वह वैश्विक सीमा को अनदेखा करता है। rules v2 के अंतर्गत, जैसा चेन 20 पर है, minted_today रोलिंग-विंडो की गणना है, वही आँकड़ा जिससे प्रति-बैकिंग सीमा की जाँच होती है; नीचे दिया गया डे-काउंटर विवरण चेन 14 का है।

प्रति बैकिंग (स्रोत कॉइन) एक पंक्ति, इसलिए सात बैकिंग वाला टोकन एक ही index के अंतर्गत सात पंक्तियाँ होता है। index वह asset शब्द है जो उस एसेट का नोट धारण करता है; index 0 RAND है और यह कभी रजिस्ट्री में नहीं होता। decimals बैकिंग के स्रोत दशमलव हैं। locked, mint_cap_per_day और minted_today टोकन की अपनी आठ-दशमलव इकाइयों में दशमलव स्ट्रिंग हैं, RAND की इकाइयों में कभी नहीं; mint_day एक सामान्य पूर्णांक है, एक UTC दिन संख्या। mint_cap_per_day जेनेसिस tokens.mint_cap_per_day है, यानी ब्लॉक समय के प्रति UTC दिन में एक बैकिंग अधिकतम जितना मिंट कर सकती है। minted_today वह राशि है जो बैकिंग ने mint_day पर मिंट की है, जो हेड ब्लॉक का UTC दिन (timestamp_ms / 86,400,000) है, इसलिए पिछले दिन से बचा काउंटर हेड के आधी रात पार करते ही "0" पढ़ा जाता है। सीमा से अधिक जमा MintCapExceeded के साथ अस्वीकार होती है और अगले दिन स्वीकार्य हो जाती है। chain और token वह वायर पहचान हैं जिस पर गार्जियन हस्ताक्षर करते हैं; asset_id इन दोनों का blake3 है, जिसकी गणना rand_bridgeAssetId करता है।

rand_bridgeAssetId

Params [token_chain, token_address] (पूर्णांक, 32 बाइट hex)। परिणाम: asset id, 64 hex वर्ण। शुद्ध अंकगणित।

rand_getBridgeBurn

Params [sequence]। परिणाम null या { "sequence": 0, "body_hex": "…", "digest": "…", "tx": "…", "height": 2, "amount": "…", "release_amount": "…", "fee": "…" }।

अंतिम तीन फ़ील्ड v0.6.8 के हैं और हर चेन पर, टोकन की आठ-दशमलव इकाइयों में दशमलव स्ट्रिंग के रूप में आते हैं। release_amount हस्ताक्षरित body में दर्ज राशि है, जो स्वयं body_hex से पढ़ी जाती है: वह राशि जो स्रोत कॉन्ट्रैक्ट रिलीज़ करता है और जिसमें से वह body का रिलेयर शुल्क चुकाता है। fee वह ब्रिज शुल्क है जिसे चेन ने ट्रेज़री नोट के रूप में रखा, और amount वह राशि है जो बंडल ने बर्न की, release_amount + fee। bridge.fees के बिना (चेन 14 से 19) fee "0" होता है। चेन 20 पर sequence 13, 0.999 zUSD का एक बर्न: "amount": "99900000", "fee": "99900", "release_amount": "99800100"।

टोकन (RPL)

RPL टोकन रजिस्ट्री: हर टोकन, ब्रिज किया गया और नेटिव दोनों। टोकन इस मानक की व्याख्या करता है।

rand_getTokens

Params [from_index, limit], दोनों वैकल्पिक (0 और 1000; limit को 1,000 पर सीमित किया जाता है)। परिणाम: from_index से आरंभ करके index के आरोही क्रम में रजिस्ट्री, उस index से रेंज के अनुसार पढ़ी गई:

{ "enabled": true, "registration_fee": "1000000000", "next_index": 3, "max_tokens": 4096,
  "burn_registration_fee": true, "bound_note_value": true,
  "tokens": [
    { "index": 2, "id": "<64 hex>", "id_text": "rpl1…", "name": "Test Coin", "symbol": "TST",
      "decimals": 6,
      "authority": { "kind": "key", "key": "<Dilithium2 key, hex>", "address": "<base58>" },
      "mint_nonce": 1, "total_supply": "5700", "registered_at": 3 }
  ] }

जिस chain पर tokens खंड नहीं है, वहाँ परिणाम { "enabled": false, "tokens": [] } है। index वह asset शब्द है जो उस टोकन का नोट वहन करता है (0 RAND है और कभी सूचीबद्ध नहीं होता)। id टोकन का asset id है और id_text उसका चेकसम-युक्त पाठ रूप: bech32m, HRP rpl, 32 id बाइट्स पर, 62 अक्षर। authority इनमें से एक है:

आपूर्तियाँ, locked, mint_cap_per_day, minted_today और registration_fee दशमलव स्ट्रिंग हैं (registration_fee के लिए RAND इकाइयाँ, शेष के लिए टोकन इकाइयाँ); next_index, mint_day और max_tokens संख्याएँ हैं। max_tokens रजिस्ट्री पर genesis की सीमा है (chain 20 पर 4,096; सीमा न होने पर null), जिसके पार किसी पंजीकरण को RegistryFull के साथ अस्वीकार कर दिया जाता है। burn_registration_fee बताता है कि पंजीकरण का शुल्क प्रस्तावक को दिए जाने के बजाय burn किया जाता है या नहीं; bound_note_value बताता है कि 2⁶³ या उससे अधिक का mint या deposit वैधता नियम के अंतर्गत आता है या नहीं (admission हर chain पर इसे वैसे भी अस्वीकार करता है)। chain 20 पर तीनों सेट हैं। limit से छोटा पृष्ठ अंतिम पृष्ठ होता है।

program authority ({ "kind": "program", "program": "<id>" }) केवल उसी chain पर पंजीकृत की जा सकती है जिसमें program_state खंड हो, जैसा chain 20 (v0.6.8) में है: टोकन शून्य आपूर्ति से आरंभ होता है, और केवल उस program के invoke ही उसे mint या burn करते हैं।

वॉलेट टोकन id को इसी सूची के माध्यम से हल करता है, कभी rand_getToken के माध्यम से नहीं: किसी हस्तांतरण का asset chain पर निजी रहता है, और पूरी रजिस्ट्री पढ़ने की लागत एक समान है, चाहे अभिप्रेत टोकन कोई भी हो।

rand_getToken

Params [token]: एक रजिस्ट्री index (संख्या या दशमलव स्ट्रिंग), 64-hex id (0x के साथ या बिना, किसी भी case में) या rpl1… पाठ रूप (पूरा lower या पूरा upper case)। परिणाम: उस टोकन की rand_getTokens पंक्ति, या null। विकृत id — गलत चेकसम, अन्य HRP, गलत लंबाई, मिश्रित case, hex न होना — -32602 है, ताकि कोई टाइपो कभी किसी अन्य टोकन की ओर न ले जाए। प्रति-टोकन लुकअप node को बता देता है कि कॉलर किस टोकन में रुचि रखता है; यह explorers और एकबारगी पठन के लिए है।

rand_getTokenSupply

Params [token], वही रूप। परिणाम null, या:

{ "total_supply": "600",
  "backings": [{ "chain": 2, "token": "<32 bytes hex>", "decimals": 6, "locked": "600",
                 "mint_cap_per_day": "10000000000000", "minted_today": "1000", "mint_day": 20350 }] }

नेटिव टोकन के लिए backings रिक्त होता है; ब्रिज किए गए टोकन के लिए locked राशियों का योग total_supply के बराबर होता है। गोपनीयता संबंधी वही टिप्पणी लागू है जो rand_getToken पर है।

ब्लॉक एग्रीगेशन (chain 20 पर सक्रिय नहीं)

ये node में उन chains के लिए मौजूद हैं जिनके genesis में aggregation खंड है। chain 20 पर रजिस्टर रिक्त है और कुछ भी कभी unsealed नहीं होता।

Aggregate बाकी सब की तरह rand_sendTransaction के माध्यम से प्रस्तुत किया जाता है।

Genesis vesting (chain 20 पर सक्रिय नहीं)

ये node में उन chains के लिए मौजूद हैं जिनके genesis में vesting खंड है। अभी किसी chain में यह नहीं है: chain 20 पर प्रत्येक { "enabled": false } उत्तर देता है। सार्वजनिक endpoint 2026-10-01 से इन्हें अग्रेषित करता है।

राशियाँ दशमलव स्ट्रिंग हैं। चारों vesting क्रियाएँ rand_sendTransaction के माध्यम से प्रस्तुत की जाती हैं।

सब्सक्रिप्शन (WebSocket)

ws://127.0.0.1:8545/ या /ws। यह socket केवल rand_subscribe और rand_unsubscribe परोसता है और अन्य किसी भी चीज़ का उत्तर -32601 देता है। तीन topics, स्वतंत्र स्ट्रीम जिनके बीच क्रम की कोई गारंटी नहीं:

• newHeads — rand_getHead का आकार, प्रत्येक committed ब्लॉक पर एक बार, क्रम में, sync के दौरान भी भेजा जाता है। यहाँ view ब्लॉक का अपना view है।
• receipts या receipts <program_id> — प्रत्येक उस committed ब्लॉक पर एक सूचना जिसमें कम से कम एक मेल खाती call receipt हो: { "height", "hash", "receipts": [ … ] }, प्रत्येक receipt rand_getReceipt के आकार में।
• transaction <hash> — एक सूचना, जिसके बाद node सब्सक्रिप्शन हटा देता है: { "status": "committed", "height", "index" }, या लेनदेन के अपने बाइट्स से संबंधित अस्वीकृति के लिए { "status": "rejected", "reason" } (वही सीमा जो rand_getTransactionStatus की है)। स्टेट-आश्रित अस्वीकृति कभी घोषित नहीं की जाती, इसलिए इसके साथ timeout जोड़ें।

{ "jsonrpc": "2.0", "id": 1, "method": "rand_subscribe",   "params": ["newHeads"] }
{ "jsonrpc": "2.0", "id": 2, "method": "rand_unsubscribe", "params": ["1"] }
{ "jsonrpc": "2.0", "id": 3, "method": "rand_subscribe",   "params": ["receipts", "<program_id>"] }
{ "jsonrpc": "2.0", "id": 4, "method": "rand_subscribe",   "params": ["transaction", "<hash>"] }

{ "jsonrpc": "2.0", "id": 1, "result": "1" }
{ "jsonrpc": "2.0", "id": 2, "result": true }
{ "jsonrpc": "2.0", "method": "rand_subscription",
  "params": { "subscription": "1", "result": { "height": 1998, "hash": "…", "view": 2251 } } }

सीमाएँ: प्रति node 64 कनेक्शन (65वाँ upgrade पर 503 के साथ अस्वीकार), प्रति कनेक्शन 8 सब्सक्रिप्शन, प्रति client frame 64 KiB, हर 30 s पर एक ping जिसका उत्तर 5 s के भीतर देना होता है, और प्रति स्ट्रीम 256 प्रविष्टियों का backlog — जो सब्सक्राइबर अपनी सुनी जा रही स्ट्रीम पर इससे अधिक पीछे हो, उसे buffer करने के बजाय कोड 1008 के साथ बंद कर दिया जाता है; पुनः कनेक्ट करें और अंतराल को rand_getCompactBlocks (heads), rand_getReceipts (receipts) या rand_getTransactionStatus (लेनदेन) से भरें। upgrade headers के बिना सादा GET / का उत्तर 400 होता है।

त्रुटियाँ

{ "jsonrpc": "2.0", "id": 1, "error": { "code": -32000, "message": "…" } }

rand_sendTransaction के लिए केवल -32000 और -32602 ही लेनदेन पर निर्णय हैं; किसी अन्य कोड के बाद उसकी स्थिति अज्ञात रहती है (देखें rand_sendTransaction)।

Pruned nodes: त्रुटि -32010

--prune-history <window> के साथ आरंभ किया गया node पूरा लेजर (नोट, nullifiers, anchors, रजिस्टर) रखता है, किंतु ब्लॉक, लेनदेन और receipts केवल अंतिम <window> के ही रखता है; rand_status.prune_floor वह न्यूनतम height है जो उसके पास अभी भी है। chain 20 पर 26 में से 24 वैलिडेटर --prune-history 24h चलाते हैं; दो archives इस flag के बिना चलते हैं और हर ब्लॉक रखते हैं, और सार्वजनिक endpoint इनमें से एक को अग्रेषित करता है।

• Height द्वारा, floor से नीचे (genesis को छोड़कर): rand_getBlockByHeight, height द्वारा rand_getFinality, और floor से नीचे तक पहुँचने वाली rand_getBlocks, rand_getCompactBlocks या rand_getReceipts range का उत्तर data: { "floor": f } के साथ -32010 pruned: height h is below this node's retention floor f होता है। किसी archive से पूछें। [0, 0] अब भी genesis परोसता है।
• Hash द्वारा: rand_getBlockByHash, rand_getReceipt, rand_getRawTransaction, rand_getCallEnvelope और rand_getAggregate pruned hash के लिए null उत्तर देते हैं, ठीक वैसे ही जैसे कभी अस्तित्व में न रहे hash के लिए; केवल archive ही दोनों में भेद कर सकता है। rand_getTransaction और rand_checkTransaction भी null उत्तर देते हैं, और -32010 केवल तब जब floor से नीचे की height बताने वाली कोई location पंक्ति बची रह गई हो। pruned node पर rand_getTransactionStatus प्रत्येक unknown प्रविष्टि में floor जोड़ता है।
• वॉलेट स्कैनिंग अप्रभावित रहती है: rand_getCommitments, rand_getNullifiers, rand_getAnchor और witness methods उन families को पढ़ते हैं जो कभी prune नहीं होतीं।

वायर पर लेनदेन

Transaction { chain_id: u64, bundle: Option<Bundle>, action: Action }

Bundle {                                        // the hidden-asset bundle (since chain 14)
  anchor: Word8, nullifiers: [Word8; 4], commitments: [Word8; 4],
  fee: u64, burn_a: u64, burn_r: u64, burn_asset: u32, time: u32,
  envelopes: [Envelope; 4], proof: Vec<u8>,
  auth_commit: Word8, auth_proof: Vec<u8>,      // since chain 17 (v0.6.3): split authorisation's c and
}                                               //   its proof; zeros and empty without hc_auth
Envelope { kem_ct: Vec<u8>, to_receiver: Vec<u8>, to_sender: Vec<u8>, body: Vec<u8> }

Action::None
Action::Mint { cm: Word8, pk: Word8, time: u32, r: Word8, envelope: Envelope, amount: u64,
               minter: PublicKey, signature: Signature }
Action::Deploy { base_pc: u32, words: Vec<u32>, public: Vec<u32> }
Action::Call { program: Hash, proof: Vec<u8>, input_envelope: Option<CallEnvelope> }
Action::Bond { validator: Address, amount: u64, registration: Option<Registration> }
Action::Unbond { validator: Address, amount: u64, nonce: u64, signature: Signature }
Action::Withdraw { validator: Address, amount: u64, nonce: u64, time: u32, r: Word8,
                   envelope: Envelope, signature: Signature }
Action::BridgeAttest { attestation: Vec<u8>, recipient: ShieldedAddress, r: Word8, time: u32,
                       asset: u32, envelope: Envelope, pq_signatures: Vec<PqSignature> }
Action::BridgeBurn { asset: u32, amount: u64, relayer_fee: u64, to_chain: u16,
                     token: [u8; 32], to: [u8; 32] }
// the five aggregation variants sit here in the enum's declared order
Action::RegisterToken { name: String, symbol: String, decimals: u8, authority: MintAuthority,
                        initial: Option<InitialMint>, salt: [u8; 32], index: u32 }
Action::TokenMint { asset: u32, amount: u64, recipient: ShieldedAddress, r: Word8, time: u32,
                    envelope: Envelope, nonce: u64, signature: Signature }
Action::SetAuthority { asset: u32, new: Option<PublicKey>, nonce: u64, signature: Signature }
Action::TokenBurn { asset: u32, amount: u64 }
Action::PauseMints { nonce: u64, signature: Signature }               // bundle-less, fee-less
Action::UnpauseMints { nonce: u64, pq_signatures: Vec<PqSignature> }  // bundle-less
Action::RegisterBridgedToken { name: String, symbol: String, salt: [u8; 32], chain: u16,
                               token: [u8; 32], decimals: u8, nonce: u64,
                               pq_signatures: Vec<PqSignature> }
Action::ListBacking { token_index: u32, chain: u16, token: [u8; 32], decimals: u8, nonce: u64,
                      pq_signatures: Vec<PqSignature> }
Action::RotatePqGuardians { new_pq_guardians: Vec<PublicKey>, nonce: u64,
                            pq_signatures: Vec<PqSignature> }         // bundle-less, fee-less
Action::RotatePauseKey { new_pause_key: PublicKey, nonce: u64,
                         pq_signatures: Vec<PqSignature> }            // bundle-less, fee-less
// the four vesting variants (ClaimVested, RevokeVesting, BondVested, UnbondVested) follow, tags 24 to 27;
// since v0.6.8 RevokeVesting carries `signatures: Vec<RevokerSignature>` in place of one `signature`
Action::AdmitValidator { candidate: PublicKey, signatures: Vec<(PublicKey, Signature)> }   // tag 28, v0.6.8
Action::SlashEquivocation { first: Box<SignedHeader>, second: Box<SignedHeader> }         // tag 29
Action::RotatePqGuardiansV2 { new_pq_guardians: Vec<PublicKey>, possession: Vec<Vec<u8>>,
                              nonce: u64, pq_signatures: Vec<PqSignature> }                // tag 30
Action::RotatePauseKeyV2 { new_pause_key: PublicKey, possession: Vec<u8>, nonce: u64,
                           pq_signatures: Vec<PqSignature> }                               // tag 31
Action::CancelRotation { kind: u8, nonce: u64, signature: Signature }                      // tag 32
Action::Invoke { program: Hash, proof: Vec<u8>, input_envelope: Option<CallEnvelope>,
                 transition: Transition }                                                  // tag 33, RPL-2

MintAuthority = None | Key(PublicKey) | Bridge { backings: Vec<Backing> } | Program(Hash)
InitialMint { amount: u64, recipient: ShieldedAddress, r: Word8, time: u32, envelope: Envelope }
Transition { reads: Vec<Cell>, writes: Vec<Cell>, inflow: Inflow, pays: Vec<Payout>, mints: Vec<Payout> }
Cell { key: Word8, value: Word8 }               // keys strictly ascending in each list
Inflow = None | Deposit | Burn                  // what the bundle's burn_a of burn_asset is to the program
Payout { asset: u32, amount: u64, recipient: ShieldedAddress, r: Word8, envelope: Envelope }
Registration { public_key: PublicKey, payout: ShieldedAddress, signature: Signature }
CallEnvelope { kem_ct: Vec<u8>, to_sender: Vec<u8>, to_auditor: Vec<u8>, body: Vec<u8> }
PqSignature { index: u8, signature: Vec<u8> }   // one guardian's Dilithium2 co-signature, by set index

bincode का डिफ़ॉल्ट कॉन्फ़िगरेशन: निश्चित-चौड़ाई वाले पूर्णांक, 8-बाइट लंबाई prefix, घोषणा-क्रम में u32 enum tags। पाँच aggregation variants enum में BridgeBurn के बाद और RegisterToken से पहले आते हैं (लेनदेन); chain 20 इन्हें कभी स्वीकार नहीं करता, न ही चार vesting variants को और न SlashEquivocation को, किंतु tag संख्याओं को hard-code करने वाले encoder को फिर भी इनकी गणना करनी होगी।

bundle के अंतिम दो फ़ील्ड v0.6.3 और chain 17 के साथ आए। bincode स्थितिगत है, इसलिए chain 16 या उससे पहले के लिए लिखा गया encoder ऐसा लेनदेन नहीं बनाता जिसे यह chain डिकोड कर सके, और इनके साथ हर लेनदेन id बदल गया: id का domain अब rand-txid-3 है, जो auth_commit और auth proof के digest को बाँधता है। जो client ids को स्थानीय रूप से पुनर्गणना करता है, उसे भी इसके साथ बदलना होगा। chain 20 पर हर bundle एक auth proof वहन करता है, चाहे वह स्वयं-प्रमाणित हो या प्रत्यायोजित। v0.6.8 Transaction या Bundle के लेआउट में कुछ नहीं बदलता; यह actions 28 से 33 जोड़ता है।

हर लेन-देन में अधिकतम एक बंडल होता है। Bond ऐसा बंडल ले जाता है जिसका burn_r उसके amount के बराबर होता है, और burn_a तथा burn_asset 0 होते हैं। BridgeBurn या TokenBurn बंडल के माध्यम से बर्न करता है: burn_asset को उस action का asset (कभी 0 नहीं) होना चाहिए, burn_a को action का amount, और burn_r को 0, जबकि fee का भुगतान स्लॉट 2–3 से RAND में होता है। अन्य कोई भी action कोई टोकन बर्न नहीं करता, और RAND केवल burn_r के माध्यम से ही बर्न होता है: जिस बंडल में burn_asset 0 हो और burn_a शून्येतर हो, उसे हर जगह अस्वीकार किया जाता है। BridgeAttest का r व्युत्पन्न होता है, चुना नहीं जाता: स्वीकृति के लिए संरक्षकों द्वारा हस्ताक्षरित डाइजेस्ट पर blake3("rand-deposit-r-1" ‖ mu) आवश्यक है, और कोई भी अन्य मान अस्वीकार किया जाता है (WrongDepositBlinding, एक स्थायी अस्वीकृति)। किसी ब्रिज किए गए टोकन का कोई भी सत्यापन स्वीकार्य होने से पहले उस टोकन का सूचीबद्ध होना आवश्यक है, चाहे genesis पर या RegisterBridgedToken / ListBacking के द्वारा; किसी असूचीबद्ध कॉइन का सत्यापन UnlistedToken के साथ अस्वीकार किया जाता है।

हर बंडल प्रमाण उसी लेन-देन पर बनाया जाता है, और उसी के विरुद्ध सत्यापित किया जाता है, जिसमें वह शामिल होता है: पूरा लेन-देन, जिसके प्रमाण रिक्त कर दिए गए हों, नए टैग के अंतर्गत chain id से बँधा होता है, और chain 20 (binding_domain: 1) पर genesis hash से भी। chain 14 से 19 तक बंधन केवल chain id से था, इसलिए chain 19 के लिए बनाया गया प्रमाण chain 20 पर सत्यापित नहीं होता, और v0.6.8 से पुराना wallet वहाँ भेज नहीं सकता। chain 18 से 20 तक, अपने दोनों प्रमाणों के बिना एक बंडल 7,936 बाइट में एन्कोड होता है और उनके बिना एक ट्रांसफ़र लेन-देन 7,949 बाइट में (chain 14 से 16 पर 5,848 और 5,861, 1,348-बाइट एनवेलप के साथ और बिना किसी प्राधिकरण फ़ील्ड के)। नेटवर्क पर प्रेषित एक ट्रांसफ़र प्रोडक्शन प्रोफ़ाइल पर लगभग 2.85 MB का होता है, जिसका लगभग पूरा भाग प्रमाण है: लगभग 1.49 MB का बंडल प्रमाण और लगभग 1.36 MB का प्राधिकरण प्रमाण। विभाजित प्राधिकरण से पहले यह लगभग 1.43 MB था।