برج

استعمال کا مقصد: اس صفحے کو برج کے ساتھ انضمام کے لیے استعمال کریں: کسی ماخذ چین پر ڈپازٹ تیار کرنے، Rand پر تصدیق نامہ جمع کرانے، برج شدہ اثاثے کو جلا کر واپس باہر بھیجنے، اور برج کی عوامی حالت پڑھنے کے لیے۔ Chain 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 میں وصول کی جاتی ہے، اور گردش کے قواعد جو پوسٹ کوانٹم سیٹ یا توقف کلید کی گردش کو نئی کلیدوں کی ملکیت ثابت کرنے اور ایک دن انتظار کرنے کا پابند بناتے ہیں۔ chain 14 کے برعکس، اس کی genesis میں zUSD اپنی ساتوں پشت پناہیوں کے ساتھ درج ہے اور اس میں وہ تحویل منتقل ہوئی ہے جو chain 14 سے ہر اجرا کے ساتھ آگے آتی رہی ہے (chain 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):

نگہبان 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 سیٹ ہے۔ پوسٹ کوانٹم سیٹ اور توقف کلید اپنے الگ اقدامات کے ذریعے گردش کرتے ہیں، جو chain 20 پر ایک دن کی تاخیر پوری کرتے ہیں: نیچے۔) اگر n·2/3 + 1 نگہبان ملی بھگت کر لیں تو وہ من مانی قدر منٹ کر سکتے ہیں؛ برج کی مضبوطی یہ حد مقرر کرتی ہے کہ کتنی اور کتنی تیزی سے، مگر اس خطرے کو ختم نہیں کرتی۔

ٹرانزیکشن کی پابندی۔ Rand کی ٹرانزیکشن میں کوئی دستخط نہیں ہوتا: برن کی اجازت اس کے بنڈل کے STARK ثبوت سے ملتی ہے۔ chain 14 سے ہر بنڈل ثبوت Transaction::binding پر بنایا جاتا ہے اور اسی کے مقابل اس کی تصدیق ہوتی ہے — یہ پوری ٹرانزیکشن کا ہیش ہے (چین شناخت، اپنے چار لفافوں سمیت واحد بنڈل، اور عمل) جس میں صرف ثبوت کے بائٹس خالی کیے جاتے ہیں۔ chain 17 سے ایک بنڈل میں دو ثبوت ہوتے ہیں، بنڈل ثبوت اور خرچ کی اجازت کا ثبوت: binding دونوں کو خالی کرتی ہے، بنڈل کا auth_commit برقرار رکھتی ہے، اور دونوں کی تصدیق اسی کے مقابل ہوتی ہے۔ کسی زیرِ التوا برن کی ایسی نقل جس میں to، relayer_fee یا (to_chain, token) بدلا گیا ہو، یا کسی attest کی ایسی نقل جس کا time یا لفافہ بدلا گیا ہو، ثبوت میں ناکام ہو جاتی ہے (TxError::InvalidBundleProof)۔ chain 20 پر binding میں genesis ہیش بھی شامل ہے (genesis binding_domain: 1: genesis ہیش، چین شناخت، بنڈل اور عمل پر rand-tx-bind-2)، لہٰذا کسی ایسی دوسری چین کے لیے بنایا گیا ثبوت بھی تصدیق نہیں پاتا جس کی چین شناخت یکساں ہو۔ والیٹس اور ریلیئرز کو اسی چین کے لیے تیار کردہ بائنری چلانی چاہیے جس پر وہ جمع کراتے ہیں: chain 20 پر v0.6.8 (chains 18 اور 19 پر v0.6.7)؛ پرانا rand ایسے ثبوت اور دستخط بناتا ہے جنہیں chain 20 مسترد کر دیتی ہے۔

نگہبان اور ریلیئر ڈیمن فل نوڈ کا حصہ نہیں ہیں؛ فل نوڈ میں مشترکہ کوڈیک اور وصولی والا نصف حصہ شامل ہے۔

وائر فارمیٹ

ہر عدد صحیح big-endian ہے؛ وائر ورژن 1 ہے۔

تصدیق نامے کا لفافہ

باڈی ہیڈر — 51 بائٹس، پھر پے لوڈ

Transfer پے لوڈ — id 1، 133 بائٹس

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 عمل میں رکھتا ہے، اور لیجر ہیش دوبارہ شمار کر کے عدم مطابقت کو مسترد کر دیتا ہے — ورنہ جمع کنندہ یہ طے کر سکتا تھا کہ کسی اور کا ڈپازٹ کون وصول کرے۔ ماخذ چین کے فرنٹ اینڈز کے لیے یہ صورت قبول کرنا لازم ہے؛ والیٹ اسے پرنٹ کرتا ہے۔ chain 11 نے مختصر عرصے کے لیے اس خانے کو براہِ راست وصول کنندہ کی شناخت بنا دیا تھا؛ ایڈریس کی وہ صورت chain 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

chain 20 پر zUSD کا اشاریہ 1 ہے، rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx، نام “Shielded USD”، 8 اعشاریے، genesis فائل میں درج، جیسا کہ chains 15 تا 19 پر تھا، اسی نام، علامت اور salt کے ساتھ جو chain 14 پر تھے، لہٰذا اس کی اثاثہ شناخت (32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f) اور rpl1… شناخت بغیر کسی تبدیلی کے منتقل ہوئیں (ایکسپلورر: GET /tokens/1)۔ chain 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 حامل کی قدر کم کرتا ہے، اور Rand کی جانب کسی ایک پشت پناہی کے حصے پر کوئی حد نہیں ہے۔

zUSD ایک باسکٹ ہے۔ حامل ہر درج پشت پناہی کا خطرہ اٹھاتا ہے، نہ کہ صرف اُس سکے کا جو اس نے جمع کرایا تھا: ایک zUSD پول پر ایک دعویٰ ہے، جو کسی بھی ایسی پشت پناہی پر قابلِ وصول ہے جس کا locked کافی ہو۔ کوئی چیز کسی پشت پناہی کی قیمت متعین نہیں کرتی۔ کسی بھی درج سکے کی 1 اکائی لاک کرنے سے 1 zUSD منٹ ہوتا ہے، اور برن کسی بھی ایسی پشت پناہی کا نام لے سکتا ہے جس کا locked اسے پورا کرے۔ چنانچہ جو سکہ اپنا پیگ کھو چکا ہو اسے مساوی قدر پر جمع کرایا جا سکتا ہے اور zUSD کو کسی ایسے سکے کی طرف برن کیا جا سکتا ہے جس نے اپنا پیگ برقرار رکھا ہو، یہاں تک کہ مستحکم پشت پناہیاں خالی ہو جائیں۔ نقصان کی حد منٹ کی متحرک مدتیں اور حقیقتاً لاک شدہ تحویل مقرر کرتی ہیں: chain 20 پر کسی بھی 24 گھنٹوں میں تمام پشت پناہیوں میں مجموعی طور پر زیادہ سے زیادہ 4,000 zUSD، اور فی پشت پناہی 100,000، منٹ کیے جا سکتے ہیں (rules v2)، اور کسی مستحکم پشت پناہی سے اس سے زیادہ نہیں نکل سکتا جتنا وہ پشت پناہی رکھتی ہے۔ یہ مدت شرح کو محدود کرتی ہے، مجموعے کو نہیں: یہ منٹ روکنے کا وقت فراہم کرتی ہے، جس سے کمزور سکے کی نئی جمع آوری رک جاتی ہے جبکہ برن کھلے رہتے ہیں۔ فی پشت پناہی نہ کوئی واپسی کی حد ہے اور نہ کوئی توقف۔ chain 14 پر، rules v2 سے پہلے، ماخذ اینڈ پوائنٹس کا اپنا pauser اور فی ٹوکن شرح کی حدیں ہی واحد حد تھیں۔

لازمی مساوات: total_supply == Σ backings.locked۔ TokenRegistry::lock (ایک BridgeAttest) تصدیق شدہ رقم کو ایک ہی کال میں پشت پناہی کے locked اور ٹوکن کے total_supply دونوں میں جمع کرتا ہے؛ TokenRegistry::release (ایک BridgeBurn) جاری شدہ رقم دونوں سے منہا کرتا ہے۔ ان میں سے کسی فیلڈ میں کوئی اور چیز نہیں لکھتی، اور ٹوکن لیف ہر پشت پناہی کے locked کو tokens_root میں کمٹ کرتا ہے، اس لیے جو دو نوڈ کسی ایک پر اختلاف کریں ان کا اسٹیٹ روٹ الگ ہو جاتا ہے۔ ماخذ اینڈ پوائنٹس لاک پر کوئی فیس نہیں لیتے اور ریلیز پر پوری تصدیق شدہ رقم منہا کرتے ہیں، اس لیے ہر پشت پناہی کا locked اُس اینڈ پوائنٹ کی تحویل کے برابر ہوتا ہے، راستے میں موجود پیغامات کے سوا۔ chain 20 پر فیسیں اس مساوات کو نہیں توڑتیں: فیس ایک zUSD نوٹ ہے جو جاری شدہ اور پشت پناہی یافتہ رہتا ہے، اس لیے جمع آوری اب بھی مجموعی رقم لاک کرتی ہے اور برن صرف amount − fee ریلیز کرتا ہے۔ chain 20 پر اینڈ پوائنٹس کی اپنی ریلیز پر 10 bps کی USDT کٹوتی کٹ کے وقت 0 کر دی گئی؛ فیس اب Rand پر لی جاتی ہے۔

وائر پر رقوم 8 اعشاری اکائیوں میں ہوتی ہیں، ماخذ سکے کے اپنے اعشاری مقامات خواہ کچھ بھی ہوں: Ethereum سے 1 USDT (6 اعشاری مقامات) کی جمع آوری 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 اعشاری اکائیوں میں اعشاری اسٹرنگز ہیں، بالکل اسی طرح جیسے chain 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 } جمع کرانے والا نہیں بلکہ چین خود اُس رقم سے حساب کرتا ہے جس پر نگہبانوں نے دستخط کیے، اس لیے ریلیئر منٹ کو نہ بڑھا سکتا ہے نہ اس کا رخ موڑ سکتا ہے؛ اس کا کمٹمنٹ وہ واحد لیف ہے جو ٹرانزیکشن وائر پر ساتھ نہیں لاتی۔ chain 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 اسی مدت کا پابند ہے جس کا بنڈل کا time ہوتا ہے (chain 20 پر 1,024 بلاک، جینیسس کے proof_window_blocks سے؛ پہلے 256)، اور جان بوجھ کر اخذ نہیں کیا جاتا: کوئی ایسا اصول نہیں جو ایسا time دے جس پر ہر جمع کنندہ متفق ہو، اس لیے فرنٹ رنر اب بھی مدت کے اندر کوئی اور time چن سکتا ہے — یعنی اسی وصول کنندہ، رقم اور اثاثے کا ایک مختلف نوٹ، جسے وصول کنندہ کا والیٹ اسی طریقے سے ڈھونڈ لیتا ہے — اور اس صورت میں دونوں جمع آوریاں تصدیق نامے کے ڈائجسٹ پر ٹکراتی ہیں۔ asset کا اُس انڈیکس کے برابر ہونا لازم ہے جو رجسٹری پہلے ہی (chain, token) کو دے چکی ہے، ورنہ TxError::AttestAssetMismatch۔

Transfer پے لوڈ کی fee ساتھ آتی ہے مگر کسی کو ادا نہیں کی جاتی: ادائیگی کے لیے جمع کنندہ کی کوئی شناخت موجود نہیں، اس لیے جمع آوری مجموعی رقم ہوتی ہے، جس میں سے صرف چین کی اپنی منٹ فیس منہا ہوتی ہے جہاں جینیسس اسے مقرر کرے (chain 20)۔ دوبارہ استعمال سے تحفظ ڈائجسٹ کے ذریعے ہے: ہر صرف شدہ mu برج کے spent سیٹ میں چلا جاتا ہے، اور میم پول اسی تصدیق نامے کی دوڑ میں شریک دوسرے ریلیئر کو رد کر دیتا ہے۔ جمع آوری پشت پناہی کی منٹ حد کی بھی پابند ہے، chain 20 پر عالمی حد کی بھی، اور منٹ روکے جانے کے دوران رد کر دی جاتی ہے (B1، rules v2)۔ دونوں حدیں مجموعی رقم شمار کرتی ہیں۔ جس چین کا جینیسس replay floor مقرر کرے، بشمول chain 20، اس پر جس منتقلی کا sequence اس کے ماخذ چین کے floor سے کم ہو اسے کسی بھی دستخط کی جانچ سے پہلے BelowReplayFloor کے ساتھ رد کر دیا جاتا ہے (chain 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 اور chain id کے مقابل جانچتا ہے، جانچتا ہے کہ وصول کنندہ کا ہیش تصدیق شدہ وصول کنندہ سے مطابقت رکھتا ہے، اور درج انڈیکس پڑھتا ہے؛ پھر وہ r اخذ کرتا ہے، وصول کنندہ کا لفافہ سیل کرتا ہے (فیس والے چین پر خالص رقم کے لیے) اور اپنے RAND کے ایک بنڈل سے ادائیگی کرتا ہے۔ bridge-rotate نگہبانوں کے سیٹ کی روٹیشن (payload 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 }
}

chain 14 کے پوشیدہ اثاثہ بنڈل کے بعد سے برن ایک بنڈل ہے (پہلے دو تھے): سلاٹ 0–1 ثابت کرتے ہیں کہ برن کرنے والا اُس اثاثے کے ایسے نوٹوں کا مالک تھا جن کا مجموعہ کم از کم amount ہے، جہاں burn_a پول سے نکلنے والی قدر ہے، اور سلاٹ 2–3 فیس RAND میں ادا کرتے ہیں۔ فیس BRIDGE_BURN_FEE ہے، 0.01 RAND، جو بنڈل کی بنیادی فیس پوری کرتی ہے۔ relayer_fee، amount کا ایک حصہ ہے (fee ≤ amount) جسے منزل کے چین پر ریلیز کنٹریکٹ الگ کرتا ہے، کوئی اضافی چارج نہیں، اس لیے burn_a ٹھیک amount ہے۔ chain 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 اور chain 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 کا ثبوت۔ چین 17 کے بعد سے ہر بنڈل کی طرح چین 20 پر بھی اس کے ساتھ خرچ کی اجازت کا ایک ثبوت بنتا ہے (چند سیکنڈ، تقریباً 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)۔

دونوں نوٹ جاری شدہ بھی ہیں اور پشت پناہی یافتہ بھی، اس لیے 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) BSC USDT کی جانب 0.999 zUSD کے برن میں سے 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 سے پہلے برج کی واحد فیس ماخذ اینڈپوائنٹس کی اپنی 10 bps کٹوتی تھی، جو اجرا کے وقت میزبان چین پر USDT سے لی جاتی تھی؛ چین 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 کے بعد سے ہر چین نے رکھا ہے۔ rules v2 کے بغیر (چین 14) ایک دن بلاک ٹائم اسٹیمپ کا timestamp_ms / 86_400_000 ہے؛ rules v2 کے تحت (چین 15 تا 20) یہی حد بلاک ٹائم کی cap_window_secs کی متحرک کھڑکی پر ناپی جاتی ہے، اور رجسٹری کی سطح پر عالمی حد، جو چین 20 پر فی 86,400 s میں 4,000 zUSD ہے، زیادہ سخت پابندی ہے (rules v2)۔ حد سے تجاوز کرنے والا ڈپازٹ نگہبانوں کے دستخطوں کی جانچ سے پہلے ہی TokenError::MintCapExceeded کے ساتھ مسترد ہو جاتا ہے، اور جب کھڑکی میں دوبارہ گنجائش ہو تو قابلِ قبول ہو جاتا ہے۔

جینیسس bridge.pause_key ایک Dilithium2 کلید ہے جو ہر پوسٹ کوانٹم نگہبان سے مختلف ہے۔ بنڈل اور فیس کے بغیر دو کارروائیاں:

• PauseMints { nonce, signature }: صرف معطلی کی کلید سے دستخط شدہ۔ یہ صرف معطل کر سکتی ہے۔
• UnpauseMints { nonce, pq_signatures }: اس کے لیے پوسٹ کوانٹم نگہبانوں کا کورم درکار ہے، معطلی کی کلید کبھی کافی نہیں۔

دونوں pause_nonce ساتھ رکھتی اور اسے بڑھاتی ہیں، اس لیے کسی کو دہرایا نہیں جا سکتا۔ معطلی کے دوران ہر منتقلی والا BridgeAttest BridgeError::MintsPaused کے ساتھ مسترد ہوتا ہے؛ برن اور نگہبان سیٹ کی تبدیلیاں کھلی رہتی ہیں، اس لیے معطلی کبھی واپسی کو نہیں روکتی۔ rules 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 تک پشت پناہیاں شامل کر سکتا ہے جن میں سے ہر ایک کی اپنی روزانہ حد ہو، اور rules 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) کے ہم آہنگ ہے۔ payload-2 تبدیلی صرف ECDSA سیٹ کو بدلتی ہے؛ rules v2 کے بغیر پوسٹ کوانٹم سیٹ چین کی پوری عمر کے لیے مقرر رہتا ہے، اور rules v2 کے تحت اسے صرف RotatePqGuardians بدلتا ہے (چین 20 پر اس کی V2 صورت، ملکیت کے ثبوت اور ایک دن کی تاخیر کے ساتھ)۔ چین 20 پر آٹھ نگہبان ہیں، وہی آٹھ کلیدیں جو چین 15 تا 19 پر تھیں؛ منٹ کے لیے ان میں سے چھ درکار ہیں (چین 14 پر چھ تھے اور پانچ درکار تھے)۔

یہ مشترکہ دستخط چین 20 پر بھی صرف چین آئی ڈی سے بندھا ہے۔ نیچے دیے گئے گورننس پیغامات کے برعکس اسے جینیسس ہیش کے پیچھے منتقل نہیں کیا گیا، کیونکہ اسے بنانے والے نگہبان ڈیمن ایک دوسری ریپوزٹری میں ہیں اور ان میں کوئی تبدیلی نہیں ہوئی۔ اگر کسی چین کی ایسی نقل بنائی جائے جس کی آئی ڈی وہی ہو اور جس نے نگہبانوں کا مجموعہ بھی نقل کر لیا ہو، تو وہ کسی ڈپازٹ کے اصل چین کے لیے بنائے گئے مشترکہ دستخط قبول کر لے گی۔ چین 20 پر ڈپازٹ ٹرانزیکشن کا اپنا فیس بنڈل جینیسس سے بندھا ہے، مگر اس کے اندر موجود تصدیق نامہ نہیں۔

B4: جینیسس کے بعد برجڈ ٹوکن کی فہرست سازی

کوئی عام ایڈریس کبھی Bridge-اختیار والا ٹوکن نہیں بنا سکتا۔ اس کے لیے دو عمل ہیں۔ دونوں ایک عام RAND فیس بنڈل پر چلتے ہیں اور دونوں پوسٹ کوانٹم کورم کے تحت ہوتے ہیں:

• RegisterBridgedToken { name, symbol, salt, chain, token, decimals, nonce, pq_signatures }: اگلے انڈیکس پر ایک نیا برجڈ ٹوکن، Rand پر 8 اعشاریوں کے ساتھ، جینیسس منٹ حد کے تحت، اپنی پہلی پشت پناہی سمیت۔ فیس: بنڈل کی بنیادی فیس اور رجسٹری کی registration_fee (چین 20 پر 1 RAND، یعنی کل 1.001 RAND)۔ چین 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>

ترتیب کے دو قواعد ہیں۔ پہلا: نگہبان پہلے رجسٹریشن پر دستخط کرتے ہیں، اس کے کمٹ ہونے کا انتظار کرتے ہیں، تفویض شدہ انڈیکس واپس پڑھتے ہیں، اور صرف اس کے بعد ان فہرست سازیوں پر دستخط کرتے ہیں جن میں وہ انڈیکس درج ہو۔ وجہ یہ ہے کہ مقامی ٹوکن کی رجسٹریشن کے لیے کسی اجازت کی ضرورت نہیں، اس لیے پیشگی دستخط شدہ فہرست سازی کو اپنا انڈیکس پہلے سے لیا ہوا مل سکتا ہے۔ دوسرا: کوئی سکہ ماخذ اینڈپوائنٹ پر setToken کے ذریعے فعال ہونے سے پہلے Rand پر فہرست میں شامل کیا جاتا ہے۔ اگر ترتیب الٹی ہو تو ممکن ہے کوئی ڈپازٹ اس وقت لاک ہو جائے جب Rand کے پاس کریڈٹ کرنے کے لیے کوئی پشت پناہی موجود نہ ہو۔ ایسی صورت میں اس کا تصدیق نامہ UnlistedToken کے ساتھ اس وقت تک مسترد ہوتا رہے گا جب تک Rand پیچھے سے آ نہ ملے۔

گورننس پیغامات

یہ مقررہ بائٹس ہیں، کبھی 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 بائٹس پر مشتمل ہے، اور کلیدیں اسی ترتیب میں ہوتی ہیں جو نئے مجموعے میں ہوگی۔

چین 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 شکل میں دستخط شدہ فائل چین 20 پر مسترد کر دی جاتی ہے (BadPauseSignature، PqBadSignature)۔ چین 14 سے 19 تک اوپر دی گئی …-1 ترتیبیں بائٹ بہ بائٹ استعمال کرتی ہیں۔

قواعد v2: تبدیلیاں، متحرک دورانیے کی حدیں، توقف کے دوران فہرست سازی ممنوع

یہ جینیسس کے bridge حصے کے اندر ایک اختیاری گروپ ہے۔ چین 14 میں یہ موجود نہیں تھا۔ چین 15 کے بعد سے ہر چین میں ہے، اور چین 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 بائٹ کی ہوں، کوئی کلید دہرائی نہ گئی ہو، اور توقف کلید ان میں شامل نہ ہو۔ کوئی رعایتی مدت نہیں ہے: تبدیل شدہ مجموعہ یا کلید اس کے بعد کسی چیز پر دستخط نہیں کرتی۔ چین 20 پر یہ v1 عمل مسترد کر دیے جاتے ہیں، اور ہر تبدیلی کو نئی کلیدوں کی ملکیت ثابت کرنی ہوتی ہے اور ایک دن انتظار کرنا ہوتا ہے (نیچے)۔
• متحرک دورانیے کی حدیں۔ ہر پشت پناہی کی mint_cap_per_day اب کیلنڈر کے دن کے بجائے cap_window_secs کے متحرک دورانیے پر ناپی جاتی ہے۔ ایک دوسری، پوری رجسٹری پر لاگو حد global_mint_cap_per_window ہر ٹوکن کی ہر پشت پناہی کو مجموعی طور پر محیط کرتی ہے (TokenError::GlobalMintCapExceeded)۔ چین 20 پر یہ 400,000,000,000 اکائیاں ہیں، یعنی ہر 86,400 s میں 4,000 zUSD۔ دن والے قاعدے میں 23:59:59 پر پوری حد اور پھر 00:00:01 پر دوبارہ پوری حد استعمال کی جا سکتی تھی، یعنی دو سیکنڈ میں دگنی حد۔ دورانیے والے قاعدے میں دوسری بار مسترد ہو جاتی ہے۔
• توقف کے دوران فہرست سازی ممنوع۔ جب mint_paused ہو تو RegisterBridgedToken اور ListBacking کو MintsPaused کے ساتھ مسترد کر دیا جاتا ہے۔ برن اور دونوں تبدیلیاں کھلی رہتی ہیں۔

تبدیلی: ملکیت اور ایک دن کی تاخیر

قواعد v2 میں تین مسائل حل طلب رہ گئے تھے۔ پہلا: کوئی چیز یہ ثابت نہیں کرتی تھی کہ نئی کلیدیں واقعی کسی کے پاس ہیں۔ ایک ٹائپنگ کی غلطی، یا ایسی کلید جو کسی کے پاس نہ ہو، پوسٹ کوانٹم کورم کو ہمیشہ کے لیے ناکارہ کر سکتی تھی۔ دوسرا: تبدیلی اسی بلاک میں نافذ ہو جاتی تھی جس میں وہ شامل ہوئی۔ تیسرا: کسی معاندانہ تبدیلی کو روکنے کا کوئی طریقہ نہیں تھا۔ rules_v2 کے ساتھ ایک دوسرا اختیاری گروپ یہ تینوں مسائل حل کرتا ہے۔ یہ گروپ rules_v2 پر منحصر ہے اور v0.6.8 میں نیا ہے (audit v6، BRG-14)۔ چین 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، چین 20 پر ان کی …-2 شکل میں)۔ ہر کلید کا ایک دستخط ہوتا ہے، کلیدوں کی ترتیب میں، اور ہر دستخط 2,420 بائٹ کا ہوتا ہے۔ v1 عمل PossessionRequired کے ساتھ مسترد کر دیے جاتے ہیں۔ غلط تعداد یا لمبائی کورم کی تصدیق سے پہلے ہی مسترد ہو جاتی ہے، جبکہ غلط ملکیتی دستخط (BadPossession { index }) کورم کی تصدیق کے بعد۔
• تاخیر۔ قبول شدہ تبدیلی زیرِ التوا کے طور پر درج ہوتی ہے، effective_at_secs = block time + delay_secs کے ساتھ۔ یہ اس پہلے بلاک کے اختتام پر نافذ ہوتی ہے جس کا ٹائم اسٹیمپ اس وقت تک پہنچ جائے۔ چین 20 پر یہ 86,400 s، یعنی ایک دن ہے۔ اس وقت تک ہر منٹ پر پرانا مجموعہ ہی مشترکہ دستخط کرتا ہے اور پرانی توقف کلید ہی توقف کرتی ہے۔ تبدیلی کو قبول کرنے پر ایک rotation_nonce خرچ ہوتا ہے اور اسے فعال کرنے پر دوسرا، اس لیے پرانے مجموعے کے تحت پول میں جمع منٹ تصدیق نامہ مجموعہ بدلتے ہی پول سے نکل جاتا ہے۔ ہر قسم کی ایک وقت میں صرف ایک تبدیلی زیرِ التوا رہ سکتی ہے (RotationPending { effective_at_secs })۔
• منسوخی۔ CancelRotation { kind, nonce, signature } (بنڈل اور فیس کے بغیر) kind قسم کی زیرِ التوا تبدیلی کو ختم کر دیتا ہے (0 = پوسٹ کوانٹم مجموعہ، 1 = توقف کلید)۔ اس پر موجودہ توقف کلید دستخط کرتی ہے، جو کورم سے الگ رکھی گئی واحد کلید ہے۔ چین 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 فراہم کرتا ہے۔ جس چین میں یہ گروپ نہ ہو (چین 14 سے 19) اس پر دونوں null ہوتے ہیں۔ ECDSA نگہبان مجموعے کی تبدیلی (payload 2) اس سے متاثر نہیں ہوتی: اس کے اپنے قواعد اور اپنی رعایتی مدت برقرار ہیں۔ چین 20 پر اب تک کوئی تبدیلی نہیں کی گئی۔

چین 14 سے منتقل شدہ

چین 15 کو چین 14 کی برج پوزیشن سے کاٹا گیا (وہی ایمیٹر اور وہی ماخذ اینڈپوائنٹس)، اور چین 16، 17 اور 18 میں سے ہر ایک کو اسی طرح اپنی پیشرو چین کی پوزیشن سے کاٹا گیا۔ چین 19 کو چین 18 کی پوزیشن سے ایک تبدیلی کے ساتھ کاٹا گیا: اس کے Ethereum، BSC اور Tron ایمیٹر وہ اینڈپوائنٹس ہیں جو 2026-09-30 کو دوبارہ ڈیپلائے کیے گئے (چین 2 اور 3 کے لیے 0x7af6b17047c1db6cb54347fdea45cf9179075bfa، چین 4 کے لیے 0x6410797df959987a5baf65b5fab97edeb34d5163)۔ چین 18 نے ان پر کبھی اعتماد نہیں کیا، اس لیے وہاں ان سے کچھ منٹ نہیں ہوا۔ چین 20 کو چین 19 کے بلندی 7,258 والے اسنیپ شاٹ سے کاٹا گیا، برج کو پہلے روک کر۔ اس میں چین 19 کے ایمیٹر، نگہبان، پوسٹ کوانٹم کلیدیں اور توقف کلید بغیر تبدیلی کے برقرار ہیں۔ اس میں صرف فیس اور تبدیلی کے گروپ نئے شامل ہیں۔ Solana کا ایمیٹر اور Rand کی جانب کا ایمیٹر چین 14 کے بعد سے نہیں بدلے۔ چین 20 کے جینیسس میں یہ شامل ہے:

• تحویل۔ 99 zUSD، دو جینیسس zUSD نوٹس (10 اور 89 zUSD) کی صورت میں۔ ان کے مقابل Ethereum پر 22 USDT، BSC پر 22 USDT، Tron پر 30 USDT اور Solana پر 25 USDT مقفل ہیں، اور ہر USDC پشت پناہی پر 0 ہے۔ یہ اسنیپ شاٹ کے وقت چین 19 کا locked ہے، جو اینڈ پوائنٹس کی تحویل سے مطابقت رکھتا تھا۔ total_supply == Σ locked بلاک 0 پر اینڈ پوائنٹس کی تحویل کے برابر ہے۔ تاریخ: چین 14 پر باقی رہ جانے والے 10 zUSD چین 15 سے 19 تک ایک جینیسس نوٹ تھے۔ چین 18 کے جینیسس میں یہ Tron پر 9 USDT مقفل اور Solana پر 1 کے طور پر رکھے گئے تھے، اور چین 19 کے جینیسس میں Solana پر 10 کے طور پر، جو چین 18 پر توازنِ نو کا نتیجہ تھا۔ باقی 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 میں ایک سابقہ testnet، یعنی چین 14، پر برج اس طرح فعال ہوا:

1. چین کو bridge سیکشن (بشمول pq_guardians اور pause_key) اور ایک tokens سیکشن کے ساتھ جاری کریں۔ tokens سیکشن registration_fee اور mint_cap_per_day مقرر کرتا ہے اور اس میں کوئی ٹوکن درج نہیں ہوتا۔ 2026-09-20 کو مکمل ہوا۔
2. فاسیٹ فعال کریں تاکہ تعینات کنندہ کا والیٹ RAND حاصل کر سکے۔ مکمل ہوا۔
3. تعینات کنندہ zUSD کو اس کی پہلی پشت پناہی کے ساتھ رجسٹر کرتا ہے، اس کے لیے list_nonce = 0 پر M_register پر کورم کا دستخط درکار ہے۔ بلندی 256 پر مکمل ہوا۔
4. نگہبان انڈیکس واپس پڑھتے ہیں اور باقی چھ ListBacking پیغامات پر دستخط کرتے ہیں، جو ایک ایک کر کے جمع کرائے جاتے ہیں۔ مکمل: list_nonce کی قدر 7 ہے۔
5. ہر پشت پناہی کے لیے: ماخذ اینڈ پوائنٹ پر setToken سے پہلے Rand پر اندراج کریں۔
6. چاروں ماخذ اینڈ پوائنٹس پر نگہبان سیٹ کی گردش (سیٹ 0 → سیٹ 1، موجودہ سیٹ کے 6 میں سے 5 دستخطوں کے ساتھ)، پھر Rand پر وہی تصدیق۔ چین 14 کی پوری مدت میں Rand پر سیٹ 0 ہی رہا؛ چین 15 کا آغاز سیٹ 1 سے ہوتا ہے۔
7. ہر ماخذ چین کے لیے کم رقوم کے ساتھ ایک براہِ راست مکمل چکر: برج میں داخلہ، 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 عوامی کلیدیں ہیں، ہر ایک ہیکس میں 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 رجسٹری فراہم کرتے ہیں۔

کیا عوامی ہے اور کیا پوشیدہ

معلوم خامیاں

فل نوڈ کی اپنی فہرست کے مطابق:

• Rand پر کسی ریلیئر کو ادائیگی نہیں ہوتی۔
• ڈپازٹ کا لفافہ کسی چیز سے بندھا نہیں، اس لیے کوئی مخاصم ریلیئر بے معنی ڈیٹا سیل کر سکتا ہے۔ اسی وجہ سے والیٹ ڈپازٹ نوٹس عوامی فیلڈز سے دوبارہ بناتا ہے۔
• لیجر کی سطح کے مشترکہ ٹیسٹ ویکٹرز نوٹ پول پر دوبارہ نہیں بنائے گئے۔
• bridge-burn کو منزل اینڈ پوائنٹ کی اپنی پالیسی کا علم اب بھی ثبوت کی ادائیگی کے بعد ہی ہوتا ہے۔
• برج شدہ چین پر پیرنٹ بلاک کے برابر ٹائم اسٹیمپس کی اجازت ہے، اس لیے ملی بھگت کرنے والے لیڈرز کسی منسوخ شدہ نگہبان سیٹ کو اس کی رعایتی مدت کے اندر برقرار رکھ سکتے ہیں۔
• میموری میں رکھے گئے برن لاگ کی کوئی حد نہیں۔
• ماخذ چین کی حالت کی کوئی لائٹ کلائنٹ یا آن چین تصدیق موجود نہیں، اور نہ ہی اس کا کوئی منصوبہ ہے۔