ब्रिज

गार्जियन ब्रिज जिस रूप में बना है: स्रोत-चेन पर लॉक, Dilithium2 सह-हस्ताक्षर के साथ गार्जियन सत्यापन, एक BridgeAttest जो नोट जमा करता है, और एक-बंडल BridgeBurn जो निकासी करता है। साथ में वायर फ़ॉर्मेट, zUSD के सात बैकिंग, मिंट और बर्न पर zUSD शुल्क, मिंट सीमाएँ और विराम, स्वामित्व प्रमाण और विलंब सहित rules-v2 रोटेशन, और chain 20 पर क्या लाइव है।

इस पेज की मदद से ब्रिज के साथ इंटीग्रेशन करें: किसी स्रोत चेन पर डिपॉज़िट बनाने, Rand पर अभिप्रमाणन जमा करने, ब्रिज की गई एसेट को बर्न करके वापस बाहर भेजने और ब्रिज की सार्वजनिक स्थिति पढ़ने के लिए। चेन 20, यानी मौजूदा testnet (2026-10-01 06:17 UTC से लाइव, fullnode v0.6.8), एक bridge सेक्शन के साथ जारी की गई है: इसमें गार्डियन सेट इंडेक्स 1 से शुरू होने वाले आठ गार्डियन, आठ पोस्ट-क्वांटम गार्डियन, एक पॉज़ कुंजी, और Ethereum, BSC, Tron तथा Solana के एमिटर हैं (इनमें पहले तीन वे एंडपॉइंट हैं जिन्हें 2026-09-30 को दोबारा डिप्लॉय किया गया)। इसमें rules-v2 समूह भी है, जिसकी वैश्विक मिंट सीमा हर रोलिंग 24 घंटों में 4,000 zUSD है। साथ में एक इनबाउंड रीप्ले फ़्लोर है, और v0.6.8 में नए दो समूह हैं: हर मिंट और हर बर्न पर 10 bps का शुल्क, जो zUSD में लिया जाता है, और रोटेशन नियम, जिनके तहत पोस्ट-क्वांटम सेट या पॉज़ कुंजी के रोटेशन में नई कुंजियों का स्वामित्व सिद्ध करना और एक दिन प्रतीक्षा करना ज़रूरी है। चेन 14 से अलग, इसकी जेनेसिस फ़ाइल zUSD को उसकी सभी सात बैकिंग के साथ सूचीबद्ध करती है। चेन 14 से हर नई चेन में आगे बढ़ती आई कस्टडी भी इसमें बनी रहती है (चेन 14 से आगे लाया गया)। rand_getAssets और एक्सप्लोरर का /bridge/assets हर बैकिंग का मौजूदा locked बताते हैं।

प्रवाह

source chain (Ethereum / BSC / Tron / Solana)                 Rand
┌────────────────────────────────┐                           ┌────────────────────────────────┐
│ lock tokens, emit              │  guardians observe,       │ BridgeAttest transaction        │
│ (amount, token, to, fee)       │  sign mu = keccak²(body)  │   admission → one deposit note  │
└────────────────────────────────┘  threshold n·2/3 + 1      │   computed by the chain          │
              ▲                     + Dilithium2 co-signers  │                                  │
   release after guardian         guardian committee         │ BridgeBurn transaction           │
   signatures on the burn  ◄───── secp256k1 keys ◄─────────  │   one bundle: slots 0–1 burn the │
   message                        read the burn log          │   asset, 2–3 pay the RAND fee;   │
                                                             │   emits a sequenced burn message │
                                                             └────────────────────────────────┘

इनबाउंड: स्रोत चेन पर मूल्य लॉक किया जाता है, गार्डियन अभिप्रमाणित करते हैं, और कोई भी उस अभिप्रमाणन को Rand पर जमा कर सकता है। फिर लेजर प्राप्तकर्ता के लिए एक डिपॉज़िट नोट जोड़ता है। इस नोट का asset शब्द ब्रिज किए गए टोकन का रजिस्ट्री इंडेक्स होता है। आउटबाउंड: एक Rand ट्रांज़ैक्शन उस एसेट के नोट बर्न करता है और एक संदेश जारी करता है। गार्डियन उस संदेश को अभिप्रमाणित करते हैं, और स्रोत चेन का कॉन्ट्रैक्ट राशि रिलीज़ कर देता है। Rand कभी भी स्रोत चेन का हेडर या स्टेट प्रूफ़ सत्यापित नहीं करता: पूरा ट्रस्ट मॉडल गार्डियन समिति के हस्ताक्षरों पर टिका है।

ट्रस्ट मॉडल और चेन आईडी

ब्रिज की अपनी चेन आईडी, जो कॉन्ट्रैक्ट्स के साथ साझा हैं (bridge-codec):

चेन	आईडी
Rand	1
Ethereum	2
BSC	3
Tron	4
Solana	5

गार्डियन secp256k1 कुंजियों की एक समिति हैं। किसी गार्डियन की पहचान keccak256(uncompressed_pubkey[1..]) के अंतिम 20 बाइट हैं, जो Ethereum की एड्रेस व्युत्पत्ति है। इसलिए एक ही कुंजी EVM कॉन्ट्रैक्ट्स, Solana प्रोग्राम और Rand तीनों पर काम करती है। n आकार के सेट के लिए कोरम n·2/3 + 1 है। मैलिएबिलिटी रोकने के लिए हर हस्ताक्षर low-s (s ≤ n/2) होना चाहिए। गार्डियन जिस डाइजेस्ट पर हस्ताक्षर करते हैं, वह mu = keccak256(keccak256(body_bytes)) है। गार्डियन सेट का रोटेशन गवर्नेंस एमिटर (chain 1, keccak256("rand-bridge-governance")) से आया एक अभिप्रमाणन होता है। इसमें new_index == current + 1 होना चाहिए, और इस पर मौजूदा सेट के हस्ताक्षर होने चाहिए, किसी पुराने सेट के नहीं। जाते हुए सेट को प्रक्रियाधीन ट्रांसफ़र के लिए 86,400 सेकंड की छूट अवधि मिलती है। (यह ECDSA सेट की बात है। पोस्ट-क्वांटम सेट और पॉज़ कुंजी अपने अलग एक्शन से रोटेट होते हैं, और चेन 20 पर इनके लिए एक दिन की देरी पूरी करनी होती है: नीचे देखें।) अगर n·2/3 + 1 गार्डियन मिलीभगत करें, तो वे मनचाहा मूल्य मिंट कर सकते हैं। ब्रिज हार्डनिंग यह सीमित करती है कि कितना और कितनी तेज़ी से, पर इस जोखिम को ख़त्म नहीं करती।

ट्रांज़ैक्शन बाइंडिंग। Rand ट्रांज़ैक्शन में कोई हस्ताक्षर नहीं होता: बर्न को उसके बंडल का STARK प्रूफ़ अधिकृत करता है। चेन 14 से हर बंडल प्रूफ़ Transaction::binding पर बनाया और उसी के विरुद्ध सत्यापित किया जाता है। यह पूरे ट्रांज़ैक्शन का हैश है (चेन आईडी, अपने चार एनवेलप वाला एकमात्र बंडल, और एक्शन), जिसमें सिर्फ़ प्रूफ़ के बाइट खाली रखे जाते हैं। चेन 17 से हर बंडल में दो प्रूफ़ होते हैं: बंडल प्रूफ़ और स्पेंड-ऑथराइज़ेशन प्रूफ़। बाइंडिंग इन दोनों को खाली रखती है, बंडल का auth_commit बनाए रखती है, और दोनों प्रूफ़ उसी के विरुद्ध सत्यापित होते हैं। अगर किसी लंबित बर्न की कॉपी में to, relayer_fee या (to_chain, token) बदला गया हो, या किसी अभिप्रमाणन की कॉपी में उसका time या एनवेलप बदला गया हो, तो प्रूफ़ विफल हो जाता है (TxError::InvalidBundleProof)। चेन 20 पर बाइंडिंग में जेनेसिस हैश भी शामिल है (जेनेसिस binding_domain: 1: जेनेसिस हैश, चेन आईडी, बंडल और एक्शन पर rand-tx-bind-2)। इसलिए समान चेन आईडी वाली किसी दूसरी चेन के लिए बना प्रूफ़ भी यहाँ सत्यापित नहीं होता। वॉलेट और रिलेयर को वही बाइनरी चलानी चाहिए जो उस चेन के लिए बनी हो जिस पर वे जमा करते हैं: चेन 20 के लिए v0.6.8 (चेन 18 और 19 के लिए v0.6.7)। पुराना rand ऐसे प्रूफ़ और हस्ताक्षर बनाता है जिन्हें चेन 20 अस्वीकार कर देती है।

गार्डियन और रिलेयर डेमन फ़ुल नोड का हिस्सा नहीं हैं। फ़ुल नोड में साझा कोडेक और प्राप्त करने वाला हिस्सा होता है।

वायर फ़ॉर्मेट

हर पूर्णांक big-endian है। वायर संस्करण 1 है।

अभिप्रमाणन एनवेलप

ऑफ़सेट	लंबाई	फ़ील्ड
0	1	`version` = 1
1	4	`guardian_set_index`
5	1	`n_sigs`
6	66·`n_sigs`	हस्ताक्षर: `index` (1), `r` (32), `s` (32), `v` (1)
6 + 66·`n_sigs`	…	`body`

बॉडी हेडर — 51 बाइट, फिर पेलोड

ऑफ़सेट	लंबाई	फ़ील्ड
0	4	`timestamp`
4	4	`nonce`
8	2	`emitter_chain`
10	32	`emitter_address`
42	8	`sequence`
50	1	`consistency_level`
51	…	`payload`

Transfer पेलोड — id 1, 133 बाइट

ऑफ़सेट	लंबाई	फ़ील्ड
0	1	`id` = 1
1	32	`amount` (u256; Rand निचले 128 बिट उपयोग करता है, और डिपॉज़िट को नोट के `u64` में भी समाना चाहिए)
33	32	`token_address`
65	2	`token_chain`
67	32	`to` — प्राप्तकर्ता हैश, नीचे देखें
99	2	`to_chain`
101	32	`fee` (u256): `amount` में से रिलेयर का हिस्सा

GuardianSetUpgrade पेलोड — id 2: id (1), new_index (4), n (1), फिर n कुंजियाँ, हर एक 20 बाइट की।

Ethereum, BSC और Tron के एड्रेस 20 बाइट के होते हैं और 32-बाइट स्लॉट में बाईं ओर 12 शून्य बाइट से भरे जाते हैं। Solana एड्रेस पूरा स्लॉट भरता है। Transfer को emitter_chain के लिए उस चेन के पंजीकृत एमिटर से ही आना चाहिए, और token_chain उत्सर्जित करने वाली चेन के बराबर होना चाहिए। एक अभिप्रमाणन अधिकतम 16 KiB का होता है। ब्रिज हार्डनिंग ने वायर फ़ॉर्मेट, कोडेक या डिप्लॉय किए गए स्रोत-चेन एंडपॉइंट में कोई बदलाव नहीं किया। पोस्ट-क्वांटम सह-हस्ताक्षर और गवर्नेंस संदेश Rand ट्रांज़ैक्शन में जाते हैं, अभिप्रमाणन में नहीं।

32-बाइट प्राप्तकर्ता

शील्डेड एड्रेस 1,216 बाइट का होता है, जबकि वायर में सिर्फ़ 32 बाइट की जगह है। इसलिए to फ़ील्ड में उसका हैश रखा जाता है:

to = blake3("rand-shielded-recipient" || pk_bytes || kem_ek)     // ShieldedAddress::recipient_hash

डिपॉज़िटर स्रोत चेन पर हैश बताता है और गार्डियन उस पर हस्ताक्षर करते हैं। जमा करने वाला BridgeAttest एक्शन में पूरा एड्रेस डालता है, और लेजर हैश दोबारा गणना करके मेल न खाने पर उसे अस्वीकार कर देता है। अन्यथा जमा करने वाला यह तय कर सकता था कि किसी और का डिपॉज़िट किसे मिले। स्रोत चेन के फ़्रंट एंड को यह रूप स्वीकार करना होगा, और वॉलेट इसे प्रिंट करता है। चेन 11 में कुछ समय के लिए यह स्लॉट सीधे receiver id रखता था। एड्रेस का वह रूप चेन 12 में वापस ले लिया गया (खाते और एड्रेस)।

एक टोकन, कई बैकिंग: zUSD

एसेट रजिस्ट्री अब ब्रिज के पास नहीं है। यह लेजर-स्तर की RPL टोकन रजिस्ट्री में चली गई है, जिसे नेटिव और ब्रिज किए गए दोनों तरह के टोकन साझा करते हैं। चेन का स्टेट रूट इसके प्रति tokens_root के रूप में प्रतिबद्ध होता है। ब्रिज किया गया टोकन एक रजिस्ट्री प्रविष्टि है जिसकी मिंट अथॉरिटी Bridge { backings } है, और वह अब किसी एक (chain, token) जोड़ी से नहीं जुड़ा होता। इनमें पहला, zUSD, चार चेन पर लॉक किए गए USDT और USDC से समर्थित है: Ethereum, Binance Smart Chain और Solana पर दोनों कॉइन हैं, जबकि Tron पर केवल USDT है (Circle ने Tron पर USDC बंद कर दिया):

chain  token (32-byte wire form)                                                  coin  decimals
2      000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7           USDT  6
2      000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48           USDC  6
3      00000000000000000000000055d398326f99059ff775485246999027b3197955           USDT  18
3      0000000000000000000000008ac76a51cc950d9822d68b83fe1ad97b32cd580d           USDC  18
4      000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c           USDT  6
5      ce010e60afedb22717bd63192f54145a3f965a33bb82d2c7029eb2ce1e208264           USDT  6
5      c6fa7af3bedbad3a3d65f36aabc97431b1bbe4c2d2f6e0e47ca60203452f5d61           USDC  6

चेन 20 पर zUSD का इंडेक्स 1 है: rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx, नाम “Shielded USD”, 8 दशमलव। चेन 15 से 19 की तरह यह जेनेसिस फ़ाइल में सूचीबद्ध है, और इसका नाम, सिंबल और salt वही हैं जो चेन 14 पर थे। इसलिए इसकी एसेट आईडी (32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f) और rpl1… आईडी बिना बदले आगे आई हैं (एक्सप्लोरर: GET /tokens/1)। चेन 14 पर इसे ऊँचाई 256 पर एक register_bridged_token ट्रांज़ैक्शन से पंजीकृत किया गया था।

Backing { chain: u16, token: [u8; 32], decimals: u8, locked: u64, minted_today: u64, mint_day: u32 }

पूरी रजिस्ट्री में एक (chain, token) जोड़ी अधिकतम एक टोकन को बैक कर सकती है (TokenError::BackingTaken)। एक टोकन की 1 से 32 बैकिंग हो सकती हैं। decimals स्रोत कॉइन की अपनी संख्या है, 0 से 18, ब्रिज किए गए टोकन के 8 कभी नहीं। साझा बैकिंग एक घोषित जोखिम है: सातों कॉइन zUSD में और zUSD से बराबर मूल्य पर बदले जा सकते हैं। इसलिए इनमें से किसी एक का भी डीपेग हर zUSD धारक का हिस्सा घटा देता है, और Rand की ओर से किसी एक बैकिंग के हिस्से पर कोई सीमा नहीं है।

zUSD एक बास्केट है। धारक हर सूचीबद्ध बैकिंग का जोखिम वहन करता है, न कि केवल जमा किए गए कॉइन का: एक zUSD पूल पर एक दावा है, किसी भी ऐसी बैकिंग पर जिसमें पर्याप्त locked हो। कोई भी व्यवस्था किसी बैकिंग का मूल्य निर्धारित नहीं करती। किसी भी सूचीबद्ध कॉइन की 1 इकाई का लॉक 1 zUSD मिंट करता है, और बर्न किसी भी ऐसी बैकिंग को नामित कर सकता है जिसका locked उसे कवर करता हो, इसलिए जिस कॉइन का पेग टूट चुका है उसे सममूल्य पर जमा किया जा सकता है और zUSD को ऐसे कॉइन की ओर बर्न किया जा सकता है जिसने अपना पेग बनाए रखा है, जब तक कि सुदृढ़ बैकिंग खाली न हो जाएँ। हानि रोलिंग मिंट विंडो और वास्तव में लॉक की गई कस्टडी से सीमित है: चेन 20 पर किसी भी 24 घंटों में सभी बैकिंग में कुल मिलाकर अधिकतम 4,000 zUSD, और प्रति बैकिंग 100,000, मिंट किए जा सकते हैं (नियम v2), और किसी सुदृढ़ बैकिंग से उससे अधिक नहीं निकल सकता जितना वह बैकिंग रखती है। विंडो दर को सीमित करती है, कुल राशि को नहीं: वह मिंट रोकने का समय देती है, जिससे कमज़ोर कॉइन के नए जमा रुक जाते हैं जबकि बर्न खुले रहते हैं। कोई प्रति-बैकिंग रिडेम्पशन सीमा नहीं है और कोई प्रति-बैकिंग विराम नहीं है। चेन 14 पर, नियम v2 से पहले, स्रोत एंडपॉइंट्स का अपना पॉज़र और प्रति-टोकन दर सीमाएँ ही एकमात्र सीमा थीं।

अपरिवर्ती: total_supply == Σ backings.locked। TokenRegistry::lock (एक BridgeAttest) एक ही कॉल में अभिप्रमाणित राशि को बैकिंग के locked और टोकन की total_supply में जोड़ता है; TokenRegistry::release (एक BridgeBurn) रिलीज़ की गई राशि को दोनों से घटाता है। इन दोनों फ़ील्ड में और कुछ नहीं लिखता, और टोकन लीफ हर बैकिंग के locked को tokens_root में कमिट करता है, इसलिए किसी एक पर असहमत दो नोड स्टेट रूट पर अलग हो जाते हैं। स्रोत एंडपॉइंट लॉक पर कोई शुल्क नहीं लेते और रिलीज़ पर पूरी अभिप्रमाणित राशि घटाते हैं, इसलिए हर बैकिंग का locked उस एंडपॉइंट की कस्टडी के बराबर होता है, ट्रांज़िट में चल रहे संदेशों को छोड़कर। चेन 20 पर शुल्क इसे नहीं तोड़ते: शुल्क एक zUSD नोट है जो जारी और समर्थित बना रहता है, इसलिए जमा अब भी सकल राशि लॉक करता है और बर्न केवल amount − fee रिलीज़ करता है। चेन 20 पर रिलीज़ के समय एंडपॉइंट्स की अपनी 10 bps USDT कटौती को कट पर 0 कर दिया गया था; शुल्क अब Rand पर लिया जाता है।

वायर पर राशियाँ 8-दशमलव इकाइयों में होती हैं, स्रोत कॉइन के अपने दशमलव चाहे जितने हों: Ethereum (6 दशमलव) से 1 USDT का जमा 100_000_000 इकाइयों के रूप में लॉक होता है। केवल इंडेक्स 0, RAND, में इस चेन के नौ दशमलव हैं।

किसी टोकन का उसके पहले जमा से पहले सूचीबद्ध होना आवश्यक है। पहली बार दिखने पर होने वाला पंजीकरण अब नहीं होता: ऐसा अभिप्रमाणन जो किसी ऐसे (chain, token) को नामित करता है जिसे किसी ने सूचीबद्ध नहीं किया है, BridgeError::UnlistedToken (token … of chain … is not listed on this chain) के साथ अस्वीकार कर दिया जाता है। धनराशि स्रोत एंडपॉइंट की कस्टडी में तब तक रहती है जब तक कोई पोस्ट-क्वांटम गार्डियन कोरम उस कॉइन को सूचीबद्ध नहीं करता (जेनेसिस के बाद सूचीबद्धता)।

asset_id = blake3("rand-bridge-asset" || token_chain (2 bytes BE) || token_address (32 bytes))

rand_bridgeAssetId(token_chain, token_address) अब भी किसी भी चेन पर इसकी गणना करता है, और किसी Transfer पेलोड का (token_chain, token_address) इसी पर रिज़ॉल्व होता है, पर यह अब रजिस्ट्री कुंजी नहीं है। नोट और वॉलेट टोकन का इंडेक्स वहन करते हैं, जो एक सघन u32 है: इंडेक्स 0 RAND है और कभी रजिस्ट्री में नहीं होता। rand_getAssets में प्रति बैकिंग एक पंक्ति होती है, और एक टोकन की हर पंक्ति एक ही इंडेक्स के अंतर्गत होती है:

[{ "index": 1, "chain": 2, "token": "000000000000000000000000dac17f…", "asset_id": "…", "decimals": 6,
   "locked": "0", "mint_cap_per_day": "10000000000000", "minted_today": "0", "mint_day": 20716 }]

locked, mint_cap_per_day और minted_today 8-दशमलव इकाइयों में दशमलव स्ट्रिंग हैं, ठीक वैसे ही जैसे चेन 14 से RPC द्वारा दी जाने वाली हर u64 राशि; index, chain, decimals और mint_day संख्याएँ ही रहते हैं। टोकन-स्तरीय मेथड — rand_getTokens, rand_getToken, rand_getTokenSupply — किसी ब्रिज्ड टोकन को उसकी सभी बैकिंग वाली एक पंक्ति के रूप में लौटाते हैं (RPL टोकन)। एक्सप्लोरर का GET /bridge/tokens उन कॉइनों की स्थिर अनुमति-सूची है जिन्हें ब्रिज स्वीकार करता है।

इनबाउंड: `BridgeAttest`

Action::BridgeAttest { attestation: Vec<u8>, recipient: ShieldedAddress, r: Word8, time: u32,
                       asset: u32, envelope: Envelope, pq_signatures: Vec<PqSignature> }

PqSignature { index: u8, signature: Vec<u8> }        // Dilithium2, 2,420 bytes

इसे एक सामान्य शील्डेड ट्रांज़ैक्शन वहन करता है, जिसका एकमात्र हिडन-एसेट बंडल 0.001 RAND का आधार शुल्क चुकाता है और उससे अधिक कुछ नहीं: इसका रिलेयर ऐसे जमाकर्ता के लिए भुगतान कर रहा है जिसके पास अभी कोई RAND नहीं है। जमा नोट { pk: recipient.pk, from: 0, amount, asset: <index>, time, r } की गणना सबमिटकर्ता नहीं, बल्कि चेन उस राशि से करती है जिस पर गार्डियनों ने हस्ताक्षर किए, इसलिए रिलेयर किसी मिंट को न बढ़ा सकता है, न पुनर्निर्देशित कर सकता है; इसका कमिटमेंट वह एकमात्र लीफ है जिसे ट्रांज़ैक्शन वायर पर नहीं ले जाता। चेन 20 पर नोट की amount सकल राशि में से मिंट शुल्क घटाकर होती है, और चेन ट्रेज़री के लिए एक दूसरा नोट, यानी शुल्क, जोड़ती है (मिंट और बर्न पर शुल्क)।

ब्लाइंडिंग व्युत्पन्न होती है, चुनी नहीं जाती। r का मान यह होना चाहिए

r = blake3("rand-deposit-r-1" || mu)        // read as eight little-endian words; mu = keccak256(keccak256(body))

यानी वह डाइजेस्ट जिस पर गार्डियन कोरम ने हस्ताक्षर किए; इसके अलावा कुछ भी हो तो BridgeError::WrongDepositBlinding होता है, और इसे किसी भी हस्ताक्षर-जाँच से पहले अस्वीकार कर दिया जाता है। फ़ील्ड वायर पर बनी रहती है — वॉलेट पब्लिक फ़ील्ड से पुनर्निर्माण करते समय उसे वहीं से पढ़ता है — उस पर केवल प्रतिबंध लगाया गया है, और यह नियम रोटेशन के अटेस्ट पर भी लागू होता है। इससे पहले, किसी रिलेयर का लंबित ट्रांज़ैक्शन देखने वाला कोई भी व्यक्ति वही अभिप्रमाणन अपनी चुनी हुई ब्लाइंडिंग के साथ सबमिट कर सकता था: प्राप्तकर्ता को तब भी नोट मिलता, पर रिलेयर का ट्रांज़ैक्शन प्रूफ़ का भुगतान करने के बाद विफल हो जाता। r नियत होने पर, एक ही time पर एक ही अभिप्रमाणन के दो सबमिटकर्ता एक ही नोट नामित करते हैं और पूल कमिटमेंट के आधार पर उन्हें परस्पर-विरोधी मानता है।

time और asset जमाकर्ता के दो पूर्वानुमान हैं, जो इसलिए किए जाते हैं कि ट्रांज़ैक्शन के बनने से पहले ही एनवेलप सील किया जा सके। time उसी विंडो के भीतर होना चाहिए जो किसी बंडल पर लागू होती है (चेन 20 पर 1,024 ब्लॉक, जेनेसिस proof_window_blocks से; पहले 256), और इसे जानबूझकर व्युत्पन्न नहीं किया जाता: कोई नियम ऐसा time तय नहीं करता जिस पर हर सबमिटकर्ता सहमत हो, इसलिए फ्रंट-रनर अब भी विंडो में कोई दूसरा time चुन सकता है — इससे उसी प्राप्तकर्ता, राशि और एसेट का एक भिन्न नोट बनता है, जिसे प्राप्तकर्ता का वॉलेट उसी तरह ढूँढ लेता है — और तब दोनों सबमिशन अभिप्रमाणन डाइजेस्ट पर टकराते हैं। asset का मान उस इंडेक्स के बराबर होना चाहिए जो रजिस्ट्री पहले ही (chain, token) को दे चुकी है, अन्यथा TxError::AttestAssetMismatch।

Transfer पेलोड का fee ट्रांज़ैक्शन में रहता है पर किसी को चुकाया नहीं जाता: भुगतान पाने वाले किसी सबमिटकर्ता की पहचान नहीं होती, इसलिए जमा सकल राशि का होता है, जिसमें से केवल चेन का अपना मिंट शुल्क घटता है जहाँ जेनेसिस उसे निर्धारित करता है (चेन 20)। रीप्ले सुरक्षा डाइजेस्ट के आधार पर है: हर उपभुक्त mu ब्रिज के spent सेट में जाता है, और मेमपूल उसी अभिप्रमाणन के लिए होड़ कर रहे दूसरे रिलेयर को अस्वीकार करता है। जमा पर बैकिंग की मिंट सीमा भी लागू होती है, चेन 20 पर वैश्विक सीमा भी, और मिंट रुके होने पर जमा अस्वीकार किया जाता है (B1, नियम v2)। दोनों सीमाएँ सकल राशि गिनती हैं। जिस चेन का जेनेसिस रीप्ले फ़्लोर निर्धारित करता है, चेन 20 सहित, उस पर ऐसा ट्रांसफ़र जिसका sequence उसकी स्रोत चेन के फ़्लोर से नीचे है, किसी भी हस्ताक्षर की जाँच से पहले BelowReplayFloor के साथ अस्वीकार किया जाता है (चेन 14 से आगे लाया गया)।

rand bridge-mint <attestation hex or @file> --pq <JSON or @file> [--to rand1…] [--fee <RAND>] [--no-wait]
rand bridge-rotate <rotation hex or @file> --pq <JSON or @file> [--fee <RAND>] [--no-wait]

--pq आवश्यक है: गार्डियनों का Dilithium2 सह-हस्ताक्षर कोरम, [{"index":0,"signature":"<4840 hex>"},…] के रूप में। प्रूफ़ बनाने से पहले वॉलेट अभिप्रमाणन को डिकोड करता है, कोरम को नोड के pq_guardians और चेन id के विरुद्ध जाँचता है, जाँचता है कि प्राप्तकर्ता का हैश अभिप्रमाणित प्राप्तकर्ता से मेल खाता है, और सूचीबद्ध इंडेक्स पढ़ता है; फिर वह r व्युत्पन्न करता है, प्राप्तकर्ता का एनवेलप सील करता है (शुल्क वाली चेन पर शुद्ध राशि के लिए) और अपने स्वयं के RAND के एक बंडल से भुगतान करता है। bridge-rotate एक गार्डियन-सेट रोटेशन (पेलोड 2) सबमिट करता है, जो कुछ भी जमा नहीं करता, और ऐसा कोई भी रोटेशन अस्वीकार करता है जो Rand के सेट को ठीक एक कदम आगे न बढ़ाए। चूँकि जमा नोट का हर फ़ील्ड उस एक ट्रांज़ैक्शन में सार्वजनिक होता है, प्राप्तकर्ता का वॉलेट कमिट किए गए bridge_attest ट्रांज़ैक्शनों को क्रम से पढ़कर, कोई एनवेलप खोले बिना, अपने पते पर भेजे गए जमा नोटों का पुनर्निर्माण कर लेता है — एक शत्रुतापूर्ण रिलेयर एनवेलप में निरर्थक डेटा सील कर सकता है पर नोट को छिपा नहीं सकता।

आउटबाउंड: `BridgeBurn`

Transaction {
  chain_id,
  bundle: <hidden-asset bundle: slots 0–1 spend the token, slots 2–3 pay the RAND fee;
           burn_asset = asset, burn_a = amount, burn_r = 0, fee >= BRIDGE_BURN_FEE>,
  action: BridgeBurn { asset, amount, relayer_fee, to_chain, token, to }
}

चेन 14 के हिडन-एसेट बंडल के बाद से बर्न एक बंडल है (पहले दो थे): स्लॉट 0–1 सिद्ध करते हैं कि बर्न करने वाले के पास उस एसेट के ऐसे नोट थे जिनका योग कम से कम amount है, जिसमें burn_a पूल से निकलने वाला मूल्य है, और स्लॉट 2–3 RAND में शुल्क चुकाते हैं। शुल्क BRIDGE_BURN_FEE, यानी 0.01 RAND है, जो बंडल के आधार शुल्क को कवर करता है। relayer_fee, amount का एक अंश है (fee ≤ amount) जिसे गंतव्य चेन पर रिलीज़ कॉन्ट्रैक्ट अलग करता है; यह कोई अतिरिक्त शुल्क नहीं है, इसलिए burn_a ठीक amount के बराबर है। चेन 20 पर चेन amount के 10 bps का बर्न शुल्क भी ट्रेज़री के लिए एक zUSD नोट के रूप में रखती है, और रिलीज़ amount − fee की होती है; रिलेयर का अंश उस रिलीज़ के भीतर समाना चाहिए (मिंट और बर्न पर शुल्क)।

बर्न अपने कॉइन को नामित करता है। (to_chain, token) बर्न किए गए एसेट की एक बैकिंग होनी चाहिए (अन्यथा TokenError::NotABacking), और दो नियम एक्शन चरण पर, बंडल के प्रूफ़ से पहले, जाँचे जाते हैं:

रिलीज़ इकाई। d < 8 स्रोत दशमलव वाली बैकिंग 10^(8−d) की इकाइयों में रिलीज़ करती है (6-दशमलव कॉइन के लिए 100; 18-दशमलव कॉइन के लिए 1)। रिलीज़ की गई राशि और relayer_fee, दोनों का इस इकाई का पूर्ण गुणज होना आवश्यक है, अन्यथा TokenError::NotReleasable (… is not a multiple of the release unit …): स्रोत कॉइन की सबसे छोटी इकाई से कम का अंश कस्टडी में फँसा रह जाता।
बैकिंग की अपनी कस्टडी। उस बैकिंग के लिए रिलीज़ की गई राशि ≤ locked होनी चाहिए, अन्यथा TokenError::InsufficientBacking (only … is locked in that backing, not the … asked for)। टोकन की कुल आपूर्ति रिलीज़ को कवर कर सकती है, पर कवर इसी एक बैकिंग की कस्टडी को करना होता है।

रिलीज़ की गई राशि शुल्क-रहित चेन पर amount और चेन 20 पर amount − fee होती है।

to का आकार सही होना चाहिए (चेन 2, 3 और 4 पर शून्य-पैडेड 20 बाइट; कभी भी पूरी तरह शून्य नहीं)। लेजर एक BridgeBurnRecord को कड़ाई से बढ़ते burn_sequence के अंतर्गत दर्ज करता है, जिसमें प्रेषक स्लॉट में ट्रांज़ैक्शन हैश होता है, और गार्डियन बर्न लॉग पढ़ते हैं:

→ {"method":"rand_getBridgeBurn","params":[13]}
← { "sequence": 13, "amount": "99900000", "fee": "99900", "release_amount": "99800100",
    "body_hex": "…", "digest": "a4bc1c7d…63f4", "tx": "ceb9e3c2…0be7", "height": 2899 }

body_hex वह आउटबाउंड संदेश है, ठीक उसी रूप में जिसमें गार्डियनों को उसे हैश और हस्ताक्षरित करना होता है; इसके Transfer की राशि release_amount है। ऊपर का रिकॉर्ड चेन 20 का पहला बर्न है: ऊँचाई 2,899 पर BSC USDT की ओर 0.999 zUSD बर्न किए गए, जिनमें से 0.000999 ट्रेज़री को गए और 0.998001 रिलीज़ किए गए।

rand bridge-burn <ASSET> <AMOUNT> <TO_CHAIN> <TOKEN> <TO> [--relayer-fee N] [--fee <RAND>] [--no-wait] [--yes]
rand bridge-message <SEQUENCE>       # one outbound message, verbatim, for a guardian to sign

वॉलेट पहले जाँच करता है। यह जाँच किसी भी प्रूविंग से पहले होती है और ब्रिज स्टेट तथा टोकन रजिस्ट्री को एक बार पढ़कर की जाती है। वॉलेट देखता है कि चेन पर ब्रिज है, ASSET रजिस्ट्री में है, TO_CHAIN पर TOKEN उसे बैक करता है और उसमें कम से कम AMOUNT लॉक है, और AMOUNT तथा रिलेयर शुल्क पूर्ण रिलीज़ इकाइयाँ हैं। शुल्क वाली चेन पर वह इसके बाद ब्रिज शुल्क और रिलीज़ होने वाली राशि दिखाता है, और प्रूविंग से पहले पुष्टि माँगता है (--yes देने पर यह प्रश्न नहीं पूछा जाता)। इसके बाद बर्न एक बंडल को प्रूव करता है। इसमें लैपटॉप पर लगभग 100 s लगते हैं और लगभग 1.5 MB का प्रूफ़ बनता है। चेन 20 पर, चेन 17 के बाद के हर बंडल की तरह, इसके साथ एक व्यय-प्राधिकरण प्रूफ़ भी बनता है (कुछ सेकंड, लगभग 1.37 MB)।

मिंट और बर्न पर शुल्क

fullnode v0.6.8 में नया, और चेन 20 पर जेनेसिस समूह द्वारा निर्धारित

"bridge": { …, "fees": { "mint_bps": 10, "burn_bps": 10, "recipient": "rand1…" } }

चेन हर ब्रिज्ड मिंट और हर ब्रिज्ड बर्न पर शुल्क लेती है। यह शुल्क ब्रिज किए गए टोकन में, Rand पर, एक शील्डेड नोट के रूप में ट्रेज़री पते recipient को जाता है। प्रत्येक दर अधिकतम 100 bps (1 %) है; चेन 20 पर दोनों दरें 10 bps, यानी 0.1 %, हैं। शुल्क ⌊amount · bps / 10⁴⌋ है, जिसे बैकिंग की पूर्ण रिलीज़ इकाई तक नीचे की ओर पूर्णांकित किया जाता है। यह इकाई 10^(8 − source decimals) है: 6-दशमलव USDT के लिए 100 इकाइयाँ, 18-दशमलव कॉइन के लिए 1। इससे शुल्क और शेष राशि दोनों पूर्ण इकाइयाँ रहती हैं। जो शुल्क शून्य तक पूर्णांकित हो जाए, उससे कोई नोट नहीं बनता (ledger/bridge_notes.rs, bridge_fee)।

	सकल `g` का जमा (`BridgeAttest`)	`amount` का बर्न (`BridgeBurn`)
शुल्क	`⌊g · mint_bps / 10⁴⌋`, रिलीज़ इकाई तक नीचे	`⌊amount · burn_bps / 10⁴⌋`, रिलीज़ इकाई तक नीचे
उपयोगकर्ता का पक्ष	`g − fee` का एक जमा नोट	`amount` बर्न होता है (`burn_a == amount`, गेस्ट की ओर से कोई चेंज नहीं); आउटबाउंड बॉडी `release_amount = amount − fee` प्रमाणित करती है, और एंडपॉइंट ठीक उतना ही रिलीज़ करता है
ट्रेज़री का नोट	`fee`, ब्लाइंडिंग `blake3("rand-bridge-fee-r-1" ‖ mu)`, जमा के `time` और एसेट पर	`fee`, ब्लाइंडिंग `blake3("rand-bridge-burn-fee-r-1" ‖ txid)`, बंडल के `time` पर
`locked` और `total_supply`	`g` से बढ़ते हैं	`release_amount` से घटते हैं
किसके विरुद्ध जाँचा जाता है	`g` पर, प्रति-बैकिंग और वैश्विक मिंट सीमाएँ	`release_amount` पर `InsufficientBacking` और `NotReleasable`; रिलेयर का हिस्सा उसी के भीतर समाना चाहिए (`FeeExceedsAmount`)

दोनों नोट जारी किए गए और बैक्ड हैं, इसलिए total_supply == Σ locked == custody अब भी लागू रहता है। शुल्क नोट भी किसी अन्य नोट की तरह zUSD है, और उसका मूल्य स्रोत चेन पर तब तक लॉक रहता है जब तक कोई उसे बर्न न करे। BRIDGE_BURN_FEE अपरिवर्तित है और इस शुल्क से अलग है; यह वह 0.01 RAND है जो एक बर्न अपने RAND स्लॉट में चुकाता है।

नोड से पढ़ा गया चेन 20 का पहला राउंड ट्रिप इस प्रकार है। ऊँचाई 1,664 पर BSC से 1 zUSD का जमा हुआ (4f6e6c54…1a64)। इससे जमाकर्ता को 0.999 zUSD और ट्रेज़री को 0.001 मिले। फिर ऊँचाई 2,899 पर (सीक्वेंस 13) 0.999 zUSD वापस BSC USDT की ओर बर्न किए गए। इस बर्न में 0.000999 zUSD शुल्क के रूप में रखे गए और 0.998001 रिलीज़ किए गए। इसके बाद (2026-10-01 को पढ़ने पर) BSC USDT बैकिंग में 22.001999 zUSD थे। टोकन की कुल आपूर्ति 99.001999 zUSD थी, जो उसकी सभी बैकिंगों के योग के बराबर थी।

ट्रेज़री अपने नोट कैसे खोजती है। शुल्क नोट का कोई एनवेलप नहीं होता, क्योंकि उसका हर अंश सार्वजनिक है। राशि ट्रांज़ैक्शन और जेनेसिस दर से मिलती है, एसेट और time ट्रांज़ैक्शन से, ब्लाइंडिंग व्युत्पन्न की जाती है, और स्वामी जेनेसिस का recipient है। जिस वॉलेट का पता recipient है, वह शुल्क नोटों को उसी सार्वजनिक पास में फिर से बनाता है जिसमें जमा नोट फिर से बनाए जाते हैं। इसके लिए वह प्रति सिंक एक बार rand_getBridgeState.fees और बैकिंगों के दशमलव पढ़ता है। शुल्क के बारे में झूठ बोलने वाला नोड केवल किसी नोट को अनखोजा रख सकता है; वह किसी नोट को कभी क्रेडिट नहीं करा सकता। जमाकर्ता का वॉलेट भी अपने जमा का मूल्य इसी तरह आँकता है: सकल राशि में से शुल्क घटाकर। केवल v0.6.8 वॉलेट ऐसा करता है; पुराना वॉलेट वैसे भी चेन 20 पर कुछ भेज नहीं सकता।

चेन 14 से 19 तक यह समूह नहीं है, इसलिए वहाँ कोई शुल्क नहीं लगता: जमा सकल राशि क्रेडिट करता है और बर्न amount रिलीज़ करता है। चेन 20 तक एकमात्र ब्रिज शुल्क स्रोत एंडपॉइंट्स की अपनी कटौती थी: रिलीज़ के समय होस्ट चेन पर USDT का 10 bps। चेन 20 के कट पर इसे 0 कर दिया गया। समूह जेनेसिस हैश में प्रतिबद्ध है और rand-bridge-fees-1 के अंतर्गत ब्रिज रूट में शामिल है। इसकी एन्कोडिंग fullnode docs/bridge.md §25 में दी गई है।

ब्रिज सुदृढ़ीकरण

प्रति-बैकिंग locked और InsufficientBacking रिडेम्प्शन की रक्षा करते हैं। ये मिंटिंग को सीमित नहीं करते: वैध गार्डियन कोरम वाला अटेस्टेशन उतना ही मिंट करता है जितना उसमें लिखा है। तीन परतें यह कमी दूर करती हैं, और चौथी परत किसी टोकन को चेन कट के बिना सूचीबद्ध करने देती है। इनमें से कोई भी परत स्रोत-चेन एंडपॉइंट्स, अटेस्टेशन वायर फ़ॉर्मेट या bridge-codec को नहीं बदलती।

B1: प्रति बैकिंग मिंट सीमा, और मिंट पॉज़

जेनेसिस tokens.mint_cap_per_day प्रति बैकिंग लागू होता है। चेन 20 इसे 10000000000000 पर सेट करती है, यानी प्रति बैकिंग प्रति दिन 100,000 zUSD; चेन 14 के बाद की हर चेन पर यही मान रहा है। नियम v2 के बिना (चेन 14) एक दिन का अर्थ ब्लॉक टाइमस्टैम्प का timestamp_ms / 86_400_000 है। नियम v2 के अंतर्गत (चेन 15 से 20) यही सीमा ब्लॉक समय की cap_window_secs लंबी रोलिंग विंडो पर मापी जाती है। वहाँ रजिस्ट्री-व्यापी वैश्विक सीमा अधिक कड़ी है: चेन 20 पर प्रति 86,400 s 4,000 zUSD (नियम v2)। सीमा से अधिक का जमा गार्डियन हस्ताक्षर-जाँच से पहले ही TokenError::MintCapExceeded के साथ अस्वीकार हो जाता है। विंडो में फिर से जगह होने पर वह स्वीकार्य हो जाता है।

जेनेसिस bridge.pause_key एक Dilithium2 कुंजी है, जो हर पोस्ट-क्वांटम गार्डियन की कुंजी से भिन्न है। इससे जुड़ी दो क्रियाएँ हैं, जिनमें न बंडल लगता है न शुल्क:

PauseMints { nonce, signature } — केवल पॉज़ कुंजी द्वारा हस्ताक्षरित। यह केवल पॉज़ कर सकती है।
UnpauseMints { nonce, pq_signatures } — इसके लिए पोस्ट-क्वांटम गार्डियन कोरम चाहिए; पॉज़ कुंजी इसे कभी नहीं कर सकती।

दोनों क्रियाएँ pause_nonce साथ रखती हैं और उसे बढ़ाती हैं, इसलिए किसी को भी रीप्ले नहीं किया जा सकता। पॉज़ के दौरान हर ट्रांसफ़र BridgeAttest BridgeError::MintsPaused के साथ अस्वीकार होता है। बर्न और गार्डियन-सेट रोटेशन खुले रहते हैं, इसलिए पॉज़ कभी रिडेम्प्शन को नहीं रोकता। नियम v2 के अंतर्गत (चेन 15 से 20) पॉज़ के दौरान लिस्टिंग भी अस्वीकार होती है। पॉज़ कुंजी को गार्डियन कुंजियों से अलग मशीन पर रखने का प्रावधान है।

rand bridge-pause --sig <HEX or @file> [--no-wait]        # no key file and no RAND needed
rand bridge-unpause --pq <JSON or @file> [--no-wait]

पॉज़ इस स्थिति से बचाता है: गार्डियन डेमॉन को धोखा देकर या उनसे समझौता करके किसी जाली मिंट पर सह-हस्ताक्षर करवाए जाएँ, जबकि पोस्ट-क्वांटम कोरम के धारक सुरक्षित हों। यह उस कोरम की चोरी के विरुद्ध बचाव नहीं है। चुराया गया कोरम अनपॉज़ कर सकता है और एक टोकन पर 32 तक बैकिंग सूचीबद्ध कर सकता है, जिनमें से प्रत्येक की अपनी दैनिक सीमा होती है। नियम v2 के अंतर्गत वह पोस्ट-क्वांटम सेट और पॉज़ कुंजी भी बदल सकता है।

B2: सीमित ब्लॉक टाइमस्टैम्प

ब्रिज वाली चेन का ब्लॉक टाइमस्टैम्प गार्डियन सेट की समाप्ति और मिंट-सीमा का दिन तय करता है। इसलिए लीडर को इसे मनमाने ढंग से आगे बढ़ाने की क्षमता नहीं होनी चाहिए। ब्रिज वाली चेन पर दो नियम लागू होते हैं:

एक वैधता नियम, जो रीप्ले पर भी जाँचा जाता है: timestamp_ms ≤ parent.timestamp_ms + 60_000, अन्यथा BlockError::TimestampLeap। मौजूदा रिवाइंड नियम (BlockError::TimestampRewind) के साथ, ब्लॉक समय केवल आगे बढ़ता है, और प्रति ब्लॉक अधिकतम एक मिनट।
एक वोट नियम, जो कभी रीप्ले नियम नहीं होता: वैलिडेटर ऐसे ब्लॉक को अपना वोट नहीं देता जो उसकी अपनी घड़ी से 15,000 ms से अधिक आगे हो।

इसलिए ब्रिज वाली चेन के हर वैलिडेटर को NTP चाहिए। जिसकी घड़ी 15 सेकंड से अधिक विचलित हो, वह दोषपूर्ण लीडर भी है और दोषपूर्ण वोटर भी। हॉल्ट के बाद जब चेन पिछड़ापन पूरा कर रही होती है, ब्लॉक समय प्रति ब्लॉक 60 s तक बढ़ सकता है। तब मिंट-सीमा का दिन वास्तविक दिन से जल्दी बदल सकता है। इसका असर सीमित है: संचित विलंब के हर पूरे दिन पर अधिकतम एक अतिरिक्त दिन की सीमा।

B3: हर मिंट पर एक Dilithium2 सह-हस्ताक्षर

हर BridgeAttest को, चाहे वह जमा हो या रोटेशन, अपने ECDSA कोरम के साथ Dilithium2 हस्ताक्षरों का एक कोरम भी रखना होगा। ये हस्ताक्षर निम्नलिखित पर होते हैं:

M = "rand-bridge-pq-cosign-1" || rand_chain_id (u64 BE) || mu        // 63 bytes

mu वह डाइजेस्ट है जिस पर ECDSA कोरम हस्ताक्षर करता है। चेन id के कारण testnet का सह-हस्ताक्षर किसी अन्य Rand चेन पर सत्यापित नहीं हो सकता। हस्ताक्षर क्रिया के pq_signatures में, ट्रांज़ैक्शन बाइंडिंग के भीतर रहते हैं, इसलिए किसी प्रति पर उन्हें हटाया या बदला नहीं जा सकता। जाँचें सस्ती से महँगी के क्रम में होती हैं:

quorum(n) ≤ len ≤ n (PqNoQuorum)
सूचकांक कड़ाई से बढ़ते क्रम में हों (PqIndexOrder)
हर सूचकांक < n हो (PqIndexOutOfRange)
हर हस्ताक्षर ठीक 2,420 बाइट का हो (PqBadSignatureLength)
अंत में, हर हस्ताक्षर pq_guardians[index] के अंतर्गत सत्यापित हो (PqBadSignature)

दोनों कोरम स्वतंत्र रूप से गिने जाते हैं। जेनेसिस bridge.pq_guardians के सूचकांक जेनेसिस ECDSA सेट (चेन 20 पर सेट 1) के सूचकांकों से मेल खाते हैं। पेलोड-2 रोटेशन केवल ECDSA सेट को बदलता है। नियम v2 के बिना पोस्ट-क्वांटम सेट चेन के पूरे जीवनकाल के लिए स्थिर रहता है। नियम v2 के अंतर्गत केवल RotatePqGuardians उसे बदल सकता है; चेन 20 पर इसका V2 रूप लागू है, जिसमें कुंजी-धारण प्रमाण और एक दिन की देरी होती है। चेन 20 पर आठ पोस्ट-क्वांटम गार्डियन हैं, वही आठ कुंजियाँ जो चेन 15 से 19 पर थीं, और एक मिंट के लिए उनमें से छह के हस्ताक्षर चाहिए। चेन 14 पर छह गार्डियन थे और पाँच के हस्ताक्षर चाहिए थे।

यह सह-हस्ताक्षर chain 20 पर भी केवल चेन आईडी से ही बँधा है: नीचे दिए गए गवर्नेंस संदेशों के विपरीत, इसे जेनेसिस हैश के पीछे नहीं ले जाया गया, क्योंकि इसे बनाने वाले गार्जियन डेमन किसी अन्य रिपॉज़िटरी में हैं और उनमें कोई परिवर्तन नहीं हुआ है। किसी चेन की समान आईडी वाली ऐसी प्रति, जिसने गार्जियन समूह की भी प्रतिलिपि बना ली हो, मूल चेन के लिए बनाए गए किसी जमा के सह-हस्ताक्षर स्वीकार कर लेगी; chain 20 पर जमा लेनदेन का अपना शुल्क बंडल जेनेसिस से बँधा है, किंतु उसके भीतर का अटेस्टेशन नहीं।

B4: जेनेसिस के बाद किसी ब्रिज्ड टोकन को सूचीबद्ध करना

कोई सामान्य पता कभी भी Bridge-प्राधिकार वाला टोकन नहीं बना सकता। इसके लिए दो क्रियाएँ हैं, प्रत्येक एक सामान्य RAND शुल्क बंडल पर और प्रत्येक पोस्ट-क्वांटम कोरम के अधीन:

RegisterBridgedToken { name, symbol, salt, chain, token, decimals, nonce, pq_signatures } — अगले इंडेक्स पर एक नया ब्रिज्ड टोकन, Rand पर 8 दशमलव, जेनेसिस मिंट सीमा के अधीन, अपनी पहली बैकिंग के साथ। शुल्क: बंडल का आधार शुल्क और रजिस्ट्री का registration_fee (chain 20 पर 1 RAND, अतः कुल 1.001 RAND; chain 20 पंजीकरण शुल्क को प्रस्तावक को देने के बजाय बर्न कर देती है)।
ListBacking { token_index, chain, token, decimals, nonce, pq_signatures } — किसी पंजीकृत ब्रिज्ड टोकन पर एक अतिरिक्त बैकिंग, जो locked = 0 से आरंभ होती है। शुल्क: बंडल का आधार शुल्क।

दोनों list_nonce को साथ ले जाती हैं और उसे बढ़ाती हैं (अन्यथा BadListNonce { expected, got }), और दोनों एक ही जाँचें चलाती हैं: चेन का एक पंजीकृत एमिटर हो (BridgeError::NoEmitter), (chain, token) अभी किसी की बैकिंग न हो, बैकिंग 32 से कम हों, और decimals ≤ 18 हो।

rand token register-bridged --name … --symbol … --salt <hex32> --chain N --token <hex32> --decimals N --pq <JSON or @file>
rand token list-backing --asset <index> --chain N --token <hex32> --decimals N --pq <JSON or @file>

क्रम के दो नियम हैं। गार्जियन पहले पंजीकरण पर हस्ताक्षर करते हैं, उसके कमिट होने की प्रतीक्षा करते हैं, आवंटित इंडेक्स पढ़ते हैं, और उसके बाद ही उन लिस्टिंग पर हस्ताक्षर करते हैं जिनमें उस इंडेक्स का उल्लेख है — नेटिव टोकन का पंजीकरण बिना अनुमति के कोई भी कर सकता है, इसलिए पहले से हस्ताक्षरित लिस्टिंग अपना इंडेक्स पहले ही लिया हुआ पा सकती है। और कोई कॉइन Rand पर पहले सूचीबद्ध होता है, उसके बाद setToken उसे स्रोत एंडपॉइंट पर सक्षम करता है: उलटे क्रम में, कोई जमा उस समय लॉक हो सकता है जब Rand के पास क्रेडिट करने के लिए कोई बैकिंग न हो, और जब तक Rand बराबरी पर न आ जाए, उसका अटेस्टेशन UnlistedToken के साथ अस्वीकृत होता रहेगा।

गवर्नेंस संदेश

निश्चित बाइट, bincode कभी नहीं; सभी पूर्णांक big-endian:

M_pause    = "rand-bridge-pause-1"        || chain_id u64 || nonce u64
M_unpause  = "rand-bridge-pq-unpause-1"   || chain_id u64 || nonce u64
M_list     = "rand-bridge-pq-list-1"      || chain_id u64 || nonce u64 || token_index u32 || chain u16 || token [32] || decimals u8
M_register = "rand-bridge-pq-register-1"  || chain_id u64 || nonce u64 || u8 len || name || u8 len || symbol || salt [32] || chain u16 || token [32] || decimals u8
M_rotate_pq    = "rand-bridge-pq-rotate-pq-1"    || chain_id u64 || rotation_nonce u64 || count u32 || key [1312] …   // rules v2
M_rotate_pause = "rand-bridge-pq-rotate-pause-1" || chain_id u64 || rotation_nonce u64 || key [1312]            // rules v2

M_pause/M_unpause में pause_nonce, M_list/M_register में list_nonce, और M_rotate_pq/M_rotate_pause में rotation_nonce होता है। count कुंजियों की संख्या है, बाइट लंबाई नहीं; प्रत्येक कुंजी किसी Dilithium2 सार्वजनिक कुंजी के कच्चे 1,312 बाइट है, उसी क्रम में जो नए समूह में होगा।

chain 20 पर प्रत्येक संदेश जेनेसिस हैश से बँधा है (जेनेसिस binding_domain: 1): टैग का संस्करण अंक 2 हो जाता है और 32-बाइट जेनेसिस हैश टैग और चेन आईडी के बीच आता है, शेष भाग अपरिवर्तित रहता है — M'_pause = "rand-bridge-pause-2" || genesis [32] || chain_id u64 || nonce u64, और इसी प्रकार rand-bridge-pq-unpause-2, rand-bridge-pq-list-2, rand-bridge-pq-register-2, rand-bridge-pq-rotate-pq-2 और rand-bridge-pq-rotate-pause-2 (bridge/gov.rs)। इस प्रकार एक चेन के लिए हस्ताक्षर करने वाली पॉज़ कुंजी या कोरम ऐसी किसी अन्य चेन के लिए हस्ताक्षर नहीं करता जिसकी चेन आईडी और कुंजियाँ समान हों। …-1 रूप में हस्ताक्षरित फ़ाइल chain 20 पर अस्वीकृत होती है (BadPauseSignature, PqBadSignature)। chains 14 से 19 ऊपर दिए गए …-1 लेआउट का बाइट-दर-बाइट उपयोग करती हैं।

Rules v2: रोटेशन, रोलिंग सीमाएँ, पॉज़ के दौरान लिस्टिंग नहीं

जेनेसिस के bridge खंड के भीतर एक वैकल्पिक समूह। chain 14 में यह नहीं था; 15 से आगे की हर चेन में है, chain 20 में समान मानों के साथ:

"bridge": { …, "rules_v2": { "global_mint_cap_per_window": 400000000000, "cap_window_secs": 86400 } }

पोस्ट-क्वांटम कोरम के अधीन दो रोटेशन। RotatePqGuardians { new_pq_guardians, nonce, pq_signatures } पूरे पोस्ट-क्वांटम समूह को बदल देता है; RotatePauseKey { new_pause_key, nonce, pq_signatures } पॉज़ कुंजी को बदल देता है। PauseMints की तरह दोनों बिना बंडल और बिना शुल्क के हैं, दोनों पर वर्तमान पोस्ट-क्वांटम समूह हस्ताक्षर करता है, और दोनों rotation_nonce को साथ ले जाते हैं और बढ़ाते हैं, इसलिए एक हस्ताक्षरित कोरम ठीक एक रोटेशन को अधिकृत करता है। नए समूह की लंबाई वर्तमान ECDSA समूह के बराबर होनी चाहिए, कुंजियाँ 1,312 बाइट की हों, कोई दोहराव न हो और पॉज़ कुंजी शामिल न हो। कोई रियायती अवधि नहीं है: प्रतिस्थापित समूह या कुंजी इसके बाद किसी पर हस्ताक्षर नहीं करती। chain 20 पर ये v1 क्रियाएँ अस्वीकृत हैं, और किसी रोटेशन को नई कुंजियों का स्वामित्व सिद्ध करना होता है और एक दिन प्रतीक्षा करनी होती है (नीचे)।
रोलिंग-विंडो सीमाएँ। प्रति-बैकिंग mint_cap_per_day को कैलेंडर दिन के बजाय cap_window_secs की रोलिंग विंडो पर मापा जाता है, और एक दूसरी, रजिस्ट्री-व्यापी सीमा, global_mint_cap_per_window, सभी टोकनों की सभी बैकिंग को एक साथ कवर करती है (TokenError::GlobalMintCapExceeded)। chain 20 पर यह 400,000,000,000 इकाइयाँ है, प्रति 86,400 s 4,000 zUSD। दैनिक नियम के अंतर्गत, 23:59:59 पर पूरी सीमा और फिर 00:00:01 पर पूरी सीमा, यानी दो सेकंड में दोगुनी सीमा संभव थी; विंडो के अंतर्गत दूसरी अस्वीकृत हो जाती है।
पॉज़ के दौरान लिस्टिंग नहीं। mint_paused के रहते RegisterBridgedToken और ListBacking MintsPaused के साथ अस्वीकृत होते हैं। बर्न और दोनों रोटेशन खुले रहते हैं।

रोटेशन: स्वामित्व और एक दिन की देरी

Rules v2 ने तीन बातें खुली छोड़ दी थीं: कुछ भी यह सिद्ध नहीं करता था कि नई कुंजियाँ किसी के पास हैं (कोई टंकण त्रुटि, या ऐसी कुंजी जो किसी के पास नहीं है, पोस्ट-क्वांटम कोरम को स्थायी रूप से निष्क्रिय कर देती), रोटेशन उसी ब्लॉक में प्रभावी हो जाता था जिसमें वह शामिल होता था, और किसी शत्रुतापूर्ण रोटेशन को कोई रोक नहीं सकता था। rules_v2 के साथ एक दूसरा वैकल्पिक समूह (जिसके लिए rules_v2 आवश्यक है), जो v0.6.8 में नया है (audit v6, BRG-14), इन्हें बंद करता है। chain 20 इसे सेट करती है:

"bridge": { …, "rotation": { "delay_secs": 86400, "needs_possession": true } }

स्वामित्व। रोटेशन RotatePqGuardiansV2 { new_pq_guardians, possession, nonce, pq_signatures } या RotatePauseKeyV2 { new_pause_key, possession, nonce, pq_signatures } होना चाहिए: possession[i] नई कुंजी i का अपना Dilithium2 हस्ताक्षर है, ठीक उसी संदेश पर जिस पर कोरम हस्ताक्षर करता है (M_rotate_pq या M_rotate_pause, chain 20 पर उनके …-2 रूप में), कुंजी क्रम में प्रति कुंजी एक, प्रत्येक 2,420 बाइट का। v1 क्रियाएँ PossessionRequired के साथ अस्वीकृत होती हैं। गलत संख्या या लंबाई कोरम के सत्यापन से पहले अस्वीकृत होती है; खराब स्वामित्व हस्ताक्षर (BadPossession { index }) उसके बाद।
देरी। स्वीकृत रोटेशन लंबित के रूप में दर्ज होता है, effective_at_secs = block time + delay_secs के साथ, और उस पहले ब्लॉक के अंत में प्रभावी होता है जिसका टाइमस्टैम्प उस समय तक पहुँचता है। chain 20 पर यह 86,400 s, यानी एक दिन है। तब तक पुराना समूह हर मिंट पर सह-हस्ताक्षर करता है और पुरानी पॉज़ कुंजी पॉज़ करती है। रोटेशन स्वीकार करने में एक rotation_nonce खर्च होता है और उसे सक्रिय करने में दूसरा, इसलिए पुराने समूह के अधीन पूल में रखा गया मिंट अटेस्टेशन समूह बदलने पर पूल से निकल जाता है। प्रत्येक प्रकार का एक समय में एक ही रोटेशन लंबित रह सकता है (RotationPending { effective_at_secs })।
रद्दीकरण। CancelRotation { kind, nonce, signature } (बिना बंडल, बिना शुल्क) kind प्रकार के लंबित रोटेशन को हटा देता है (0 = पोस्ट-क्वांटम समूह, 1 = पॉज़ कुंजी)। इस पर वर्तमान पॉज़ कुंजी हस्ताक्षर करती है, यानी कोरम से अलग रखी गई एकमात्र कुंजी, chain 20 पर "rand-bridge-cancel-rotation-2" || genesis [32] || chain_id u64 || rotation_nonce u64 || kind u8 पर, और यह nonce खर्च करता है। अतः कब्ज़े में लिया गया कोरम एक दिन से कम समय में समूह को रोटेट नहीं कर सकता, और पॉज़ कुंजी का धारक उस दिन के भीतर उसे रोक सकता है; आने वाली पॉज़ कुंजी अपने ही आगमन को रद्द नहीं कर सकती।

हस्ताक्षरकर्ता rand-node bridge-gov है (rotate-pq, rotate-pause, cancel-rotation, प्रत्येक में message, sign और submit चरण; submit भेजने से पहले स्वामित्व की हर पंक्ति को फिर से सत्यापित करता है)। rand_getBridgeState rotation_rules और pending_rotations प्रदान करता है; जिस चेन पर यह समूह नहीं है (chains 14 से 19), वहाँ दोनों null होते हैं। ECDSA गार्जियन-समूह रोटेशन (payload 2) इससे प्रभावित नहीं होता: उसके अपने नियम और अपनी रियायती अवधि बनी रहती है। chain 20 पर अभी तक कोई रोटेशन नहीं चलाया गया है।

chain 14 से आगे लाया गया

chain 15 को chain 14 की ब्रिज स्थिति (वही एमिटर और स्रोत एंडपॉइंट) से काटा गया था, और chains 16, 17 और 18 में से प्रत्येक को इसी प्रकार अपनी पूर्ववर्ती चेन की स्थिति से काटा गया। chain 19 को chain 18 की स्थिति से एक परिवर्तन के साथ काटा गया: उसके Ethereum, BSC और Tron एमिटर 2026-09-30 को पुनः डिप्लॉय किए गए एंडपॉइंट हैं (chains 2 और 3 के लिए 0x7af6b17047c1db6cb54347fdea45cf9179075bfa, chain 4 के लिए 0x6410797df959987a5baf65b5fab97edeb34d5163)। chain 18 ने उन पर कभी भरोसा नहीं किया, इसलिए वहाँ उनसे कुछ भी मिंट नहीं हुआ। chain 20 को ब्रिज पहले रोककर, ऊँचाई 7,258 पर chain 19 के एक स्नैपशॉट से काटा गया, और यह chain 19 के एमिटर, गार्जियन, पोस्ट-क्वांटम कुंजियाँ और पॉज़ कुंजी अपरिवर्तित रखती है; यह शुल्क और रोटेशन समूह जोड़ती है। Solana का एमिटर और Rand-पक्ष का एमिटर chain 14 के बाद से नहीं बदले हैं। chain 20 का जेनेसिस जो रखता है:

कस्टडी। 99 zUSD, दो जेनेसिस zUSD नोटों (10 और 89 zUSD) के रूप में हैं। इनके सामने Ethereum पर 22 USDT, BSC पर 22 USDT, Tron पर 30 USDT और Solana पर 25 USDT लॉक हैं, और हर USDC बैकिंग पर 0 है। ये आँकड़े स्नैपशॉट के समय चेन 19 के locked से लिए गए हैं, और ये एंडपॉइंटों की कस्टडी से मेल खाते थे। ब्लॉक 0 पर total_supply == Σ locked एंडपॉइंटों की कस्टडी के बराबर है। इतिहास: चेन 14 पर बचे 10 zUSD, चेन 15 से 19 तक एक जेनेसिस नोट के रूप में रहे। चेन 18 के जेनेसिस में वे Tron पर लॉक 9 USDT और Solana पर 1 के सामने थे। चेन 18 पर एक पुनर्संतुलन के बाद, चेन 19 के जेनेसिस में वे Solana पर 10 के सामने थे। शेष 89 चेन 19 की शुद्ध जमाएँ हैं, जिनमें से उसके बर्न घटा दिए गए हैं।
गार्डियन सेट इंडेक्स 1, जिस पर स्रोत एंडपॉइंट पहले से हैं; अगले ECDSA रोटेशन में इंडेक्स 2 होना चाहिए। आठ पोस्ट-क्वांटम कुंजियाँ और पॉज़ कुंजी चेन 15 वाली ही हैं, अपरिवर्तित।
burn_sequence 13: चेन 14 के बर्न 6 पर समाप्त हुए, चेन 15 से 18 का जेनेसिस 7 से शुरू हुआ, चेन 18 ने एक बर्न (7) किया और चेन 19 8 से शुरू हुई। चेन 19 ने पाँच बर्न किए, सीक्वेंस 8 से 12, इसलिए चेन 20 13 से शुरू होती है। इससे सीक्वेंस पर आधारित कोई भी एंडपॉइंट या डेमन एक ही सीक्वेंस दो बार नहीं देखता। चेन 20 के पहले बर्न को सीक्वेंस 13 मिला।
रीप्ले। किसी पिछली चेन का मिंट अब भी ECDSA कोरम पार कर लेगा। लेकिन उसका पोस्ट-क्वांटम सह-हस्ताक्षर उस चेन की id से बँधा होता है, इसलिए चेन 20 पर वह अस्वीकार हो जाता है। चेन 15 के जेनेसिस में कोई इनबाउंड रीप्ले सीमा नहीं थी (min_inbound_sequence null था)। वहाँ यह सुरक्षा सह-हस्ताक्षर पर और इस बात पर टिकी थी कि गार्डियन नई चेन id के लिए किसी पुराने लॉक पर कभी सह-हस्ताक्षर न करें। चेन 16 से जेनेसिस यह सीमा तय करता है। हर स्रोत चेन के लिए यह वह न्यूनतम sequence है जो उस चेन के एमिटर से आए किसी ट्रांसफ़र अटेस्टेशन में हो सकता है। चेन 20 की सीमा { "2": 3, "3": 3, "4": 3, "5": 7 } है। यह चेन 19 के स्नैपशॉट के समय हर एंडपॉइंट का अगला आउटबाउंड सीक्वेंस है, क्योंकि उससे पहले का हर लॉक चेन 19 पर मिंट हो चुका था। (चेन 18 की सीमा { "2": 2, "3": 2, "4": 2, "5": 2 } थी। चेन 19 की सीमा { "2": 1, "3": 1, "4": 1, "5": 4 } थी, जहाँ हर पुनः डिप्लॉय किए गए एंडपॉइंट पर सीक्वेंस 0 ऑपरेटर का अपना लॉक था, जिसे कभी मिंट नहीं होना चाहिए।) सीमा से नीचे का ट्रांसफ़र BelowReplayFloor के साथ अस्वीकार होता है, चाहे उसके साथ कोई भी कोरम और सह-हस्ताक्षर हो। गार्डियन-सेट रोटेशन इस सीमा से नहीं परखे जाते। सीमा जेनेसिस पर तय होती है, जेनेसिस हैश में प्रतिबद्ध होती है और ब्रिज रूट में शामिल होती है।

चेन 14 पर लॉन्च का क्रम (इतिहास)

सितंबर 2026 में चेन 14 पर, जो एक पुराना testnet था, ब्रिज इस क्रम में शुरू हुआ:

चेन bridge सेक्शन (pq_guardians और pause_key सहित) और एक tokens सेक्शन के साथ बनाई गई। tokens सेक्शन registration_fee और mint_cap_per_day तय करता था और उसमें कोई टोकन सूचीबद्ध नहीं था। 2026-09-20 को पूरा।
फ़ॉसेट चालू किया गया, ताकि डिप्लॉयर वॉलेट RAND प्राप्त कर सके। पूरा।
डिप्लॉयर ने list_nonce = 0 पर M_register पर कोरम के हस्ताक्षर के अंतर्गत zUSD को उसकी पहली बैकिंग के साथ पंजीकृत किया। ऊँचाई 256 पर पूरा।
गार्डियनों ने इंडेक्स वापस पढ़ा और शेष छह ListBacking संदेशों पर हस्ताक्षर किए, जो एक-एक करके जमा किए गए। पूरा: list_nonce का मान 7 है।
हर बैकिंग के लिए: स्रोत एंडपॉइंट पर setToken से पहले Rand पर सूचीबद्ध करना।
चारों स्रोत एंडपॉइंटों पर गार्डियन-सेट रोटेशन (सेट 0 → सेट 1, वर्तमान सेट द्वारा 6 में से 5 हस्ताक्षरों से), फिर Rand पर वही अटेस्टेशन। चेन 14 के पूरे जीवनकाल में Rand ने सेट 0 पढ़ा; चेन 15 सेट 1 से शुरू होती है।
हर स्रोत चेन के लिए छोटी राशियों के साथ एक लाइव राउंड ट्रिप चलाई गई: ब्रिज इन, zUSD मिंट, ट्रांसफ़र, वापस बर्न। फिर हर बैकिंग के locked (rand_getTokenSupply) का एंडपॉइंट की कस्टडी से मिलान किया गया।

सार्वजनिक स्थिति

rand_getBridgeState:

{
  "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": "400000000000", "cap_window_secs": 86400,
                "global_minted_in_window": "…", "global_mint_headroom": "…" },
  "min_inbound_sequence": null,
  "rotation_rules": null, "pending_rotations": null,
  "fees": null,
  "assets": [ … ]
}

pq_guardians Dilithium2 सार्वजनिक कुंजियाँ हैं, हर एक hex में 1,312 बाइट की। अब कोई next_index नहीं है। ब्रिज किया गया टोकन जमा किए जाने से पहले सूचीबद्ध होता है, उस इंडेक्स के अंतर्गत जो उसके पंजीकरण ने तय किया था, इसलिए पूर्वानुमान के लिए कोई इंडेक्स नहीं बचता। rotation_nonce वह मान है जो अगले M_rotate_pq/M_rotate_pause/M_cancel में होना चाहिए। जिस चेन पर यह समूह नहीं है (चेन 14), उस पर rules_v2 null होता है। जिस चेन पर रीप्ले सीमा नहीं है (चेन 15 और उससे पहले), उस पर min_inbound_sequence null होता है; चेन 20 पर यह { "2": 3, "3": 3, "4": 3, "5": 7 } है। जिस चेन पर ये समूह नहीं हैं (चेन 14 से 19), उस पर rotation_rules, pending_rotations और fees null होते हैं। ऊपर का नमूना केवल संरचना दिखाता है, चेन 20 के मान नहीं। चेन 20 guardian_set_index 1 और burn_sequence 13 पर शुरू हुई। वह "rotation_rules": { "delay_secs": 86400, "needs_possession": true }, "pending_rotations": [] और "fees": { "mint_bps": 10, "burn_bps": 10, "recipient": "rand1…" } लौटाती है। जिस चेन में bridge सेक्शन नहीं है, वह {"enabled": false} उत्तर देती है।

कोई बैलेंस नहीं: ब्रिज किया गया मूल्य नोटों के रूप में होता है, और वॉलेट अपने ही नोटों से rand asset-balance [INDEX] द्वारा पढ़ता है कि उसके पास क्या है। ब्रिज रूट इन सबके प्रति प्रतिबद्ध होता है:

एमिटर, गार्डियन सेट, ख़र्च हो चुके डाइजेस्ट और बर्न सीक्वेंस
पोस्ट-क्वांटम गार्डियन सेट
पॉज़ कुंजी, पॉज़ फ़्लैग और गवर्नेंस नॉन्स (दो, और rules v2 के अंतर्गत rotation_nonce)
रीप्ले सीमा, जहाँ जेनेसिस उसे तय करता है
चेन 20 पर रोटेशन नियम, लंबित रोटेशन के साथ, और शुल्क समूह

ब्रिज रूट स्टेट रूट में केवल उसी चेन पर शामिल होता है जिस पर ब्रिज है। टोकन रजिस्ट्री, हर बैकिंग के locked सहित, अलग से tokens_root के रूप में प्रतिबद्ध होती है। एक्सप्लोरर के GET /bridge और GET /bridge/assets यही स्थिति लौटाते हैं; दूसरा हर बैकिंग के जमा और बर्न के कुल योग 8-दशमलव स्ट्रिंग के रूप में भी देता है। GET /tokens और GET /tokens/:id रजिस्ट्री लौटाते हैं।

क्या सार्वजनिक है और क्या छिपा है

क्या	इसे कौन देखता है
किसी जमा की राशि, एसेट इंडेक्स और प्राप्तकर्ता का पता	सभी, उसी एक ट्रांज़ैक्शन में
प्राप्तकर्ता बाद में कौन-सा नोट ख़र्च करता है	कोई नहीं
किसी बर्न की राशि, एसेट, कॉइन, गंतव्य और रिलेयर शुल्क	सभी — गार्डियनों को इसकी आवश्यकता होती है
ब्रिज शुल्क नोट की राशि, एसेट और स्वामी, यानी ट्रेज़री (चेन 20)	सभी: यह सार्वजनिक फ़ील्डों से दोबारा बनाया जाता है
किन नोटों से किसी बर्न का भुगतान हुआ	कोई नहीं
ब्रिज किए गए बैलेंस	केवल धारक, या व्यूइंग-की धारक
गार्डियन सेट, एमिटर, हर बैकिंग के `locked` सहित रजिस्ट्री, बर्न लॉग	सभी

ज्ञात कमियाँ

फ़ुलनोड की अपनी सूची से:

Rand पर किसी रिलेयर को भुगतान नहीं होता।
किसी जमा का एनवेलप किसी चीज़ से बँधा नहीं होता, इसलिए कोई शत्रुतापूर्ण रिलेयर उसमें कचरा सील कर सकता है। इसी कारण वॉलेट जमा नोटों को सार्वजनिक फ़ील्डों से दोबारा बनाता है।
लेजर-स्तर के साझा परीक्षण वेक्टर नोट पूल पर दोबारा नहीं बनाए गए हैं।
bridge-burn को गंतव्य एंडपॉइंट की अपनी नीति का पता अब भी प्रूफ़ का भुगतान करने के बाद ही चलता है।
ब्रिज वाली चेन पर पैरेंट के बराबर ब्लॉक टाइमस्टैम्प की अनुमति है, इसलिए मिलीभगत करने वाले लीडर किसी हटाए जा चुके गार्डियन सेट को उसकी ग्रेस विंडो के भीतर बनाए रख सकते हैं।
मेमोरी में रखा बर्न लॉग असीमित है।
स्रोत-चेन की स्थिति के लिए न कोई लाइट क्लाइंट है, न ऑन-चेन सत्यापन, और न ही इनकी कोई योजना है।

2026-10-12 को fullnode कमिट c0878c3f (चेन 21) के विरुद्ध अंतिम बार सत्यापित। जहाँ कोड और यह पृष्ठ असहमत हों, वहाँ कोड सही है; हमें बताएँ।