JSON-RPC

یہ نوڈ --rpc پر HTTP کے ذریعے JSON-RPC 2.0 فراہم کرتا ہے (پہلے سے طے شدہ 127.0.0.1:8545)، اور سبسکرپشنز کے لیے اسی پورٹ پر ایک WebSocket بھی۔ v0.6.8 سے یہ ایک دوسرا، عوامی لسنر بھی کھول سکتا ہے (--public-rpc، نیچے)۔ randprotocol_client::RpcClient (Rust) نیچے دیے گئے ہر میتھڈ کو سمیٹتا ہے۔ یہ صفحہ میتھڈز کی وہ فہرست ہے جو v0.6.8 (c9c9bd3c)، یعنی وہ بلڈ جس پر چین 20 چلتی ہے، فراہم کرتا ہے؛ جہاں کوئی میتھڈ کوڈ میں موجود ہے مگر چین 20 پر غیر فعال ہے، وہاں اس کی صراحت کر دی گئی ہے۔

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

عوامی اینڈپوائنٹ

https://rpc.randprotocol.org (یہی پراکسی https://randprotocol.org/api/rpc پر بھی دستیاب ہے) درخواستیں چین 20 کے ایک آرکائیو نوڈ کو آگے بھیجتا ہے جو ہر بلاک محفوظ رکھتا ہے، ان والیٹس اور صفحات کے لیے جن کا اپنا نوڈ نہیں (rand --rpc https://rpc.randprotocol.org …)۔ یہ صرف HTTP POST قبول کرتا ہے، اس کا CORS کھلا ہے اور WebSocket نہیں ہے، اور یہ ایک نوڈ کی نسبت محدود تر ہے:

• ہر کال میں ایک درخواست۔ بیچ -32600 کے ساتھ مسترد کر دیا جاتا ہے۔
• میتھڈز کی ایک اجازت فہرست: 2026-10-01 سے یہ وہی مجموعہ ہے جو نوڈ کے اپنے عوامی لسنر کا ہے (v0.6.8 میں rpc::PUBLIC_METHODS)، چنانچہ پروگرام اسٹیٹ کی وہ ریڈز جن کی rand program invoke کو ضرورت ہوتی ہے، rand_getAdmitted، تجمیع کی ریڈز اور ویسٹنگ کی ریڈز اس میں شامل ہیں، نیز rand_checkTransaction اور rand_sendTransaction۔ rand_mint، rand_importViewingKey، rand_getViewingNotes، rand_removeViewingKey اور rand_getPeers شامل نہیں، اور نوڈ تک پہنچے بغیر -32601 method not allowed here لوٹاتے ہیں: عوامی فاؤسٹ غلط استعمال کا دروازہ کھولتا ہے، اور مشاہداتی کلید صرف اسی نوڈ کو دی جانی چاہیے جو آپ خود چلاتے ہوں۔
• درخواست کا متن زیادہ سے زیادہ 12 MiB، جس میں کوئی بھی منتقلی، ٹوکن کارروائی یا ڈپلائے سما جاتا ہے، اور ایسی کال بھی جس کا ثبوت تقریباً 3.4 MB تک ہو (ٹرانزیکشن hex میں انکوڈ ہوتی ہے، اور کال کے ثبوت سے پہلے ہی اس کے بنڈل اور تصدیقِ اختیار کے ثبوت تقریباً 2.85 MB لے لیتے ہیں)۔ اس سے بڑی کال آپ کے اپنے نوڈ پر جاتی ہے۔ حد سے تجاوز پر: HTTP 413 اور -32600۔
• فی ایڈریس، فی منٹ 1,200 درخواستیں، اور rand_sendTransaction کے لیے فی منٹ 6۔ تجاوز پر: HTTP 429 اور -32005۔ ریڈ کی حد ایک والیٹ کی پہلی ہم آہنگی کے حساب سے رکھی گئی ہے، جو ایک ہی جھٹکے میں کئی سو درخواستوں پر مشتمل ہوتی ہے (چین 18 کی بلندی 99,000 پر 645)۔
• جب اس کے پیچھے موجود نوڈ جواب نہ دے تو -32000 upstream unavailable۔

اس صفحے پر باقی سب کچھ خود نوڈ کی وضاحت ہے۔

نوڈ کے دو لسنر

v0.6.8 (آڈٹ v6) سے ایک نوڈ کے دو JSON-RPC لسنر ہیں۔

• --rpc <ADDR>، آپریٹر کا لسنر۔ ہر میتھڈ، بیچ اور WebSocket۔ یہ کال کرنے والے کو اس کے ساکٹ ایڈریس سے پہچانتا ہے اور لوپ بیک پر بھروسا کرتا ہے: مشاہداتی کلید کے میتھڈز صرف لوپ بیک کو جواب دیتے ہیں، اور لوپ بیک پر کوئی حد شماری نہیں ہوتی۔ اسے 127.0.0.1 پر رکھیں۔ ریورس پراکسی یا SSH فارورڈ لوپ بیک پر ہی پہنچتا ہے، لہٰذا ان کے پیچھے ہر آنے والا آپریٹر شمار ہوتا ہے: کسی عوامی اینڈپوائنٹ کو کبھی اس پورٹ کی طرف نہ موڑیں۔
• --public-rpc <ADDR>، عوامی لسنر، بالکل اسی مرحلے کے لیے۔ یہ میتھڈز کا ایک مقررہ مجموعہ فراہم کرتا ہے، یعنی وہ ریڈز جن کی ایک والیٹ، ایکسپلورر یا صفحے کو ضرورت ہوتی ہے، اور rand_sendTransaction (rpc::PUBLIC_METHODS)۔ rand_importViewingKey، rand_getViewingNotes، rand_removeViewingKey، rand_mint اور rand_getPeers وہاں کبھی فراہم نہیں کیے جاتے، اور نہ ہی بعد میں شامل ہونے والا کوئی میتھڈ جب تک اسے فہرست میں درج نہ کیا جائے؛ ایسی کال کا جواب -32000 <method> is not served on this node's public listener ہوتا ہے۔ بیچ کا جواب -32600 ہے، اور WebSocket کا کوئی راستہ نہیں۔ ایک ہی پیمانہ تمام کال کرنے والوں کا مجموعی احاطہ کرتا ہے، ایک جھٹکے میں 600 درخواستیں اور فی سیکنڈ 150؛ اس سے آگے، HTTP 429 اور جواب کے متن میں -32000۔ فی صارف حدیں پراکسی کی ذمہ داری ہیں، جو صارفین کو دیکھ سکتا ہے۔ اس کے کال کرنے والے نوڈ کی بلاکنگ ریڈ کی گنجائش کا زیادہ سے زیادہ نصف استعمال کرتے ہیں، تاکہ آپریٹر کا لسنر کبھی محروم نہ رہے۔

دونوں لسنر ریڈ کی دو حدیں مشترک رکھتے ہیں۔ جو بلاکنگ ریڈ 30 s میں مکمل نہ ہو اس کا جواب -32000 this read took longer than 30 s on this node; retry with a smaller range ہوتا ہے۔ rand_getBlocks اپنا صفحہ 64 MiB بلاک پڑھ لینے پر ختم کر دیتا ہے۔

--rpc-viewing-token-file <PATH> --rpc کے مشاہداتی کلید والے میتھڈز پر ایک bearer ٹوکن لگاتا ہے: فائل کی پہلی سطر، کم از کم 32 حروف، جو Authorization: Bearer <token> کی صورت میں بھیجی جاتی ہے۔ اس کے ہوتے ہوئے صرف لوپ بیک کافی نہیں، اور کہیں بھی موجود کال کرنے والا جو اسے پیش کرے، اسے جواب دیا جاتا ہے۔

روایات

• تصدیق کنندہ کے ایڈریس base58 اسٹرنگز ہیں (32 بائٹس)۔ ہیشز 64 hex حروف ہیں، 0x کے ساتھ یا اس کے بغیر۔ پوشیدہ قدریں — کمٹمنٹس، نلیفائرز، اینکرز، ٹری روٹس، وٹنس لیولز — Word8 ہیں: آٹھ little-endian u32 الفاظ، 64 چھوٹے hex حروف کی صورت میں۔
• پوشیدہ ایڈریس rand1 + base58 ہیں، 1,667 حروف۔ 2,000 حروف سے لمبا پیرامیٹر پارس ہونے سے پہلے ہی اپنی لمبائی کی بنا پر مسترد کر دیا جاتا ہے۔
• ہر u64 رقم ایک اعشاری اسٹرنگ ہے ("1500000000" = 1.5 RAND؛ 1 RAND = 10⁹ اکائیاں): RAND کی اکائیاں ہوں یا ٹوکن کی اکائیاں، چین کی اسٹیٹ ہو یا ڈی کوڈ شدہ ٹرانزیکشن کا اپنا فیلڈ۔ JSON عدد 2⁵³ سے آگے درست صحیح عدد نہیں رہتا، اور 9 اعشاریہ والے ٹوکن کی رسد چند کروڑ اکائیوں پر ہی اس حد سے گزر جاتی ہے۔ اس سے کیا بدلا، اس کے لیے نیچے دیا گیا تاریخ وار نوٹ دیکھیں۔
• اشاریے، نانس، بلندیاں، لیف اشاریے، ویوز، لمبائیاں، اعشاریے اور دن کے شمار کنندے (mint_day) کبھی رقمیں نہیں ہوتے اور ہر جگہ JSON صحیح اعداد ہیں۔
• ہر درخواست میں id رکن ہونا لازم ہے۔ جس آبجیکٹ میں یہ نہ ہو وہ نوٹیفکیشن ہے اور -32600 کے ساتھ مسترد کیا جاتا ہے؛ صریح "id": null ایک عام درخواست ہے۔
• بیلنس کا کوئی میتھڈ نہیں اور اکاؤنٹ کا کوئی میتھڈ نہیں۔ والیٹ اپنی مشاہداتی کلید کے ذریعے rand_getCommitments اور rand_getNullifiers کو اسکین کر کے اپنا بیلنس نکالتا ہے۔ rand_getBalance، rand_getAccount اور rand_getAssetBalance کا جواب -32601 ہے۔

بنیادی تبدیلی، 2026-09-20 (چین 14): ہر رقم ایک اعشاری اسٹرنگ ہے

چین 14 سے پہلے، ڈی کوڈ شدہ ٹرانزیکشن کے اندر رقمیں JSON صحیح اعداد تھیں۔ وہ استثنا اب ختم ہو چکا ہے۔ یہ فیلڈز JSON اعداد سے اعشاری اسٹرنگز میں بدل گئے، اور ان کے مفہوم یا مقام میں کوئی اور تبدیلی نہیں ہوئی:

• bundle.fee، rand_getTransaction کے tx میں اور rand_getBlockByHeight / rand_getBlockByHash کے transactions[] میں؛
• action.amount، جب kind = mint، bond، unbond، withdraw، bridge_attest ہو (وہی تین میتھڈز)؛
• action.amount اور action.relayer_fee، جب kind = bridge_burn ہو (وہی تین میتھڈز)؛
• locked، rand_getAssets اور rand_getBridgeState.assets[] کی قطاروں میں۔

جو کلائنٹ ان میں سے کسی کو عدد کے طور پر پڑھتا ہے، اسے اب اسٹرنگ پارس کرنی ہوگی۔ rand_status کا aggregation.subsidy_base (صرف تجمیع والی چینز پر) اسی تبدیلی میں اسٹرنگ بنا۔ باقی ہر رقم پہلے ہی اسٹرنگ تھی: rand_getSupply، rand_getEmission، rand_getValidators، مشاہداتی نوٹس، اور چین 14 کے ساتھ متعارف ہونے والا ہر فیلڈ — بنڈل کے burn_a اور burn_r، ٹوکن کی رسدیں، ہر پشت پناہی کے locked، mint_cap_per_day اور minted_today، registration_fee، اور token_mint، token_burn اور register_token کا amount (initial_amount، initial.amount)۔

بیچ

POST کا متن زیادہ سے زیادہ 20 درخواستی آبجیکٹس کی ایک array ہو سکتا ہے، جس کا جواب اسی لمبائی کی array میں درخواستوں کی ترتیب سے دیا جاتا ہے، غلطیوں سمیت۔ درخواستیں یکے بعد دیگرے چلتی ہیں۔ خالی array، 20 سے زائد کی array، یا ایسا متن جو نہ آبجیکٹ ہو نہ array، null id کے ساتھ ایک واحد -32600 ہے۔ پورا متن پھر بھی نوڈ کی درخواستی متن کی حد کا پابند ہے، جو ایک ثبوت بردار ٹرانزیکشن کے حساب سے رکھی گئی ہے: دو ثبوت بردار rand_sendTransaction کالز کا بیچ 413 کے ساتھ مسترد کر دیا جاتا ہے۔ بیچ ریڈز کے لیے ہیں، ثابت شدہ ترسیلات کے لیے نہیں۔

چین اور نوڈ

rand_chainId

پیرامیٹرز []۔ نتیجہ: چین id (صحیح عدد)؛ testnet پر 20۔

rand_tokenInfo

پیرامیٹرز []۔ نتیجہ { "symbol": "RAND", "decimals": 9 }۔

rand_getHead

پیرامیٹرز []۔ نتیجہ { "height": 1998, "hash": "…", "view": 2251 }۔ view نوڈ کا موجودہ اتفاقِ رائے کا ویو ہے، جو ویوز کا وقت ختم ہونے پر بلندی سے آگے نکل جاتا ہے۔

rand_status (متبادل نام rand_syncStatus)

پیرامیٹرز []۔ نتیجہ:

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

is_validator: یہ نوڈ ایک تصدیق کنندہ کلید رکھتا ہے؛ active_validator: وہ کلید اس مجموعے میں شامل ہے جو موجودہ ایپوک چلا رہا ہے۔ reserved_peers (v0.6.8) ان پیئرز کو شمار کرتا ہے جنہیں آنے والے کنکشنز کی حد سے بالاتر داخلہ ملا: بوٹ اسٹریپس، کوئی بھی --reserved-peer، اور دستخط شدہ پیئر بائنڈنگ سے معلوم ہونے والی ہر تصدیق کنندہ شناخت، ہر ایک ایک بار؛ فلیٹ کے نوڈ پر آغاز کے ایک منٹ کے اندر اسے تصدیق کنندگان کی تعداد تک پہنچ جانا چاہیے۔ viewing_keys بتاتا ہے کہ نوڈ کی جانب سے اسکیننگ کے لیے نوڈ اپنی میموری میں کتنی مشاہداتی کلیدیں رکھتا ہے۔ verify_queue ان ٹرانزیکشنز کی تعداد ہے جو ثبوت کی جانچ کرنے والے چار ورکرز میں سے کسی ایک کی منتظر ہیں (زیادہ سے زیادہ 64)۔ hc_bundle وہ بنڈل گیسٹ ہے جس کے مقابل اس چین کے ثبوت بنتے ہیں اور hc_auth وہ تصدیقِ اختیار گیسٹ جسے اس کا جینیسس طے کرتا ہے (منقسم تصدیقِ اختیار، چین 17 سے)، یا جس چین پر یہ نہ ہو وہاں null؛ جس نوڈ کا بلڈ ان میں سے کسی سے مختلف ہو وہ شروع ہونے سے انکار کر دیتا ہے۔ testnet اور binding_domain جینیسس کے انہی ناموں والے فیلڈز ہیں، جیسا کہ rand_getLimits انہیں فراہم کرتا ہے۔ gas_prices ٹِپ لیجر کی موجودہ گیس قیمتیں ہیں، جو ہر کمٹ پر تازہ ہوتی ہیں، اعشاری اسٹرنگز کی صورت میں؛ جس چین میں gas سیکشن نہ ہو وہاں null۔ چین 20 کی قیمتیں متحرک ہیں اور ہر بلاک پر اس کے بھراؤ کے مطابق بدلتی ہیں، کبھی 100 اور 800 کی کم ترین حدوں سے نیچے نہیں اور کبھی 10,000 اور 80,000 کی بالائی حدوں سے اوپر نہیں، لہٰذا انہیں یہاں یا rand_getLimits میں پڑھیں اور کوڈ میں مستقل نہ لکھیں۔ اس آبجیکٹ میں ایک aggregation آبجیکٹ بھی ہوتا ہے (اس کا subsidy_base اعشاری اسٹرنگ، باقی صحیح اعداد)، جو اس چین پر تمام صفر دکھاتا ہے جس میں aggregation سیکشن نہ ہو، جیسا کہ چین 20 ہے۔

اس آبجیکٹ میں disk_free_bytes (ایک عدد) اور disk_low بھی ہوتے ہیں، اور برقراری کا جوڑا: prune_floor، وہ کم ترین بلندی جو یہ نوڈ اب بھی رکھتا ہے (آرکائیو پر 0)، اور prune_history_secs، وہ دورانیہ جو --prune-history کے ساتھ شروع کیا گیا نوڈ محفوظ رکھتا ہے (جب سب کچھ رکھے تو null)۔ چین 20 پر، چین 19 کی طرح، 26 میں سے 24 تصدیق کنندگان 24 گھنٹے کے بلاک رکھتے ہیں؛ دونوں آرکائیو سب رکھتے ہیں۔ دیکھیں تراشے ہوئے نوڈز۔

rand_getPeers

پیرامیٹرز []۔ نتیجہ: { "peer_id": "12D3KooW…", "addrs": ["/ip4/…/tcp/30303"], "connected_secs": 1241 } کی ایک array۔

rand_getBlockByHeight / rand_getBlockByHash

پیرامیٹرز [height] یا [hash]۔ نامعلوم ہو تو نتیجہ null، ورنہ:

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

صرف کمٹ شدہ بلاک فراہم کیے جاتے ہیں۔ transactions کی ساخت وہی ہے جو rand_getTransaction کے tx کی ہے۔ بلاک میں sealed بھی ہوتا ہے اور اس کی ہر ٹرانزیکشن میں sealed_by؛ جس چین پر ایگریگیشن نہ ہو وہاں ان کی قدریں false اور null ہوتی ہیں۔

rand_getBlocks

پیرامیٹرز [from_height, to_height]۔ نتیجہ: بلاک ہیڈرز، پرانے پہلے، from_height سے زیادہ سے زیادہ 1,024 (2026-09-24 سے پہلے کے نوڈ پر 128): rand_getBlockByHeight کے فیلڈز، transactions کے بغیر۔ حد سے وسیع رینج، یا ہیڈ سے آگے کی رینج، رد نہیں کی جاتی بلکہ کاٹ دی جاتی ہے، اور v0.6.8 سے کوئی صفحہ 64 MiB بلاک پڑھ لینے پر بھی ختم ہو جاتا ہے؛ آخری لوٹائی گئی بلندی سے آگے بڑھیں۔ اگر to_height، from_height سے کم ہو تو -32602۔

v0.6.8 سے ہر ہیڈر میں public_notes بھی ہوتا ہے: بلاک کی bridge_attest، token_mint اور register_token ٹرانزیکشنز، اور برج فیس والی چین پر اس کی bridge_burn ٹرانزیکشنز، بشکل [{ "hash", "raw" }] (وہی انکوڈنگ جو rand_getRawTransaction فراہم کرتا ہے)؛ باقی ہر بلاک کے لیے خالی۔ برن اپنے پروفس خالی کر کے اور "proofs_stripped": true کے ساتھ فراہم کیا جاتا ہے؛ اس کا hash اصل ٹرانزیکشن شناخت ہے۔ والیٹ کی پہلی سنک یہی صفحات پڑھتی ہے اور عوامی نوٹس کی ازسرِنو تشکیل کے لیے اسے کسی اور چیز کی ضرورت نہیں ہوتی۔

rand_getFinality

پیرامیٹرز [height] یا [hash]۔ نتیجہ، ان میں سے ایک: { "status": "committed", "height", "hash" }، { "status": "certified", "height", "hash", "qc_view" }، { "status": "proposed", "height", "hash" }، { "status": "unknown" }۔ بلندی کو ہمیشہ صرف کمٹ شدہ چین کے مقابل جانچا جاتا ہے، اس لیے اس کا جواب committed یا unknown ہوتا ہے؛ ہیش certified (ریپلیکا کے غیر کمٹ شدہ درخت میں، کورم سرٹیفکیٹ کے ساتھ) یا proposed (درخت میں، سرٹیفکیٹ کے بغیر) بھی ہو سکتا ہے۔

rand_getProposer

پیرامیٹرز [view] یا [from_view, to_view]، زیادہ سے زیادہ 64 ویوز۔ نتیجہ { "epoch": 3, "proposers": [ { "view": 2251, "proposer": "2nRdFC…" } ] }: ہر ویو کا لیڈر موجودہ ویلیڈیٹر سیٹ کے تحت، نہ کہ وہ سیٹ جو تاریخی طور پر اس ویو پر چل رہا تھا۔ الٹی رینج یا 64 سے زیادہ ویوز کے لیے -32602۔

rand_getVersion

پیرامیٹرز []۔ نتیجہ { "version", "git_sha", "chain_id", "hc_bundle", "hc_auth", "fri_profile" }۔ version ورک اسپیس کریٹ کا ورژن ہے؛ git_sha بلڈ کے وقت محفوظ کیا گیا کمٹ ہیش، جس کے آخر میں -dirty لگا دیا جاتا ہے اگر ٹریک شدہ فائلیں مختلف تھیں، ورنہ "unknown"۔ hc_auth جینیسس کا auth گیسٹ ہے، جیسا کہ rand_status میں، یا null۔ 2026-10-01 کو chain 20 پر عوامی اینڈپوائنٹ:

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

rand_getGenesisHash

پیرامیٹرز []۔ نتیجہ: جینیسس ہیش بصورت hex؛ chain 20 پر "6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135" (chain 19 کا a3defc93…228a تھا)۔ صرف chain id سے دو چین کٹس میں فرق نہیں کیا جا سکتا؛ اس سے کیا جا سکتا ہے۔ chain 20 پر یہ ہر ٹرانزیکشن بائنڈنگ اور ہر دستخط شدہ ایکشن پیغام کا حصہ بھی ہے (binding_domain: 1، دیکھیے rand_getLimits)۔

rand_getHealth

پیرامیٹرز []۔ نتیجہ، ان میں سے ایک: { "status": "disk_low", "free_bytes": "3221225472" }، { "status": "ok" }، { "status": "syncing", "behind": 412 }، { "status": "behind", "behind": 30 }۔ disk_low باقی سب پر مقدم ہے، جب ڈیٹا ڈائریکٹری کے فائل سسٹم پر خالی جگہ نوڈ کے --min-free-disk-mb (ڈیفالٹ 1024، یعنی 4 GB سے کم) کے چار گنا سے کم ہو؛ free_bytes ایک اعشاری سٹرنگ ہے۔ ok جب sync_target - height زیادہ سے زیادہ 2 ہو اور کوئی سنک بیچ درخواست زیرِ التوا نہ ہو؛ syncing جب تک ایسی درخواست زیرِ التوا ہو؛ behind جب نوڈ سنک نہ کر رہا ہو اور تاخیر پھر بھی 2 سے زیادہ ہو۔

rand_getMempoolInfo

پیرامیٹرز []۔ نتیجہ { "count": 2, "bytes": 2611200, "oldest_ms": 1450, "max_count": 10000 }۔ bytes پول میں موجود ہر ٹرانزیکشن کی انکوڈ شدہ لمبائی کا مجموعہ ہے؛ پول خالی ہو تو oldest_ms کی قدر null ہوتی ہے۔ v0.6.8 سے پول پر بائٹس کی حد بھی ہے، جینیسس کے max_block_bytes کا آٹھ گنا (chain 20 پر 160 MiB): اس سے آگے، جو ٹرانزیکشن اپنی کم از کم حد سے اوپر فی KiB زیادہ ادا کرے وہ سب سے سستی کو ہٹا دیتی ہے، اور جو کم یا برابر ادا کرے وہ mempool full کے ساتھ رد کر دی جاتی ہے۔ گورننس ایکشنز دونوں حدوں سے مستثنیٰ ہیں۔

جمع کرانا

rand_sendTransaction

پیرامیٹرز [hex]، جہاں hex سے مراد bincode(Transaction) ہے۔ نتیجہ: ٹرانزیکشن ہیش۔ نوڈ داخلے کی ترتیب (ٹرانزیکشنز) کے مطابق توثیق کرتا ہے، اسے پول میں رکھتا ہے اور گوسپ کرتا ہے۔ غلطیاں -32000 ہیں، وجہ کے ساتھ: nullifier already spent، anchor is not one of the last 1024 roots، time 12 is outside [1500, 2524] (دونوں ونڈوز جینیسس کا proof_window_blocks ہیں، chain 20 پر 1,024؛ chain 19 تک کی چینز پر 256)، fee 1000000 below minimum 2000000، the bundle's digest is not what its proof published، invalid bundle proof: …، unknown program …، already in mempool، conflicts with a pending transaction over <nullifier>، faucet is disabled on this chain؛ invoke کے لیے cell <key> is no longer what this transition read (ایک اسٹیٹ فیصلہ: سیل دوبارہ پڑھیں اور دوبارہ پروف بنائیں) یا the vault holds … of asset … and the transition pays …؛ ووٹ کے ذریعے داخلے کے تحت رجسٹر کرنے والے Bond کے لیے validator … has not been admitted by the validator set's vote (staking.admission_by_vote); ask the validators for an AdmitValidator first؛ اس بنڈل کے لیے جو chain 20 کے جینیسس سے مطابقت نہ رکھے، envelope is 1348 bytes, this chain requires exactly 1860، this chain requires an auth proof on every bundle (genesis hc_auth)، the auth proof publishes a different commitment than the bundle's auth_commit، auth proof: …، bundle proof declares gas limit …, this chain requires exactly 20479، non-canonical proof: … — re-prove with an up-to-date wallet؛ برج ایکشنز کے لیے bridge: attestation already consumed، the attestation names a different recipient، the attestation deposits under asset 2, and the transaction names 1، the bundle burns 399, not the 400 the action declares؛ ایسے بنڈل کے لیے جس میں ایسا برن ہو جو اس کا ایکشن نہیں رکھ سکتا، the bundle burns asset 2 on an action that burns no token، a burn of 5 is not allowed on this action یا RAND burned through burn_a (5); a RAND burn goes through burn_r؛ برج کی اسٹیٹ کے لیے bridge minting is paused، mint cap … per backing per day، already paused، not paused، wrong pause nonce، wrong list nonce، chain N has no registered emitter؛ ٹوکن رجسٹری کے لیے wrong mint nonce اور wrong token index۔ قبولیت کمٹمنٹ نہیں ہے: rand_getTransaction یا rand_getTransactionStatus کو بار بار جانچیں۔

جو ٹرانزیکشن چین کی بلاک حد (rand_getLimits سے max_block_bytes) سے بڑی ہو، وہ مےمپول تک پہنچنے سے پہلے ہی -32000 کے ساتھ، دونوں سائز بتا کر، رد کر دی جاتی ہے۔ درخواست کی باڈی کی حد 2 × (2 × max_proof_bytes + 4 × 2048 + max_call_envelope_bytes + 16,384 + 64 KiB) + 256 KiB ہے، جو آغاز پر جینیسس سے حساب کی جاتی ہے: ڈیفالٹ چین پر 8,867,840 بائٹس اور chain 20 کی حدود پر 17,350,656، جو chain 17 تا 19 کے برابر ہے (chain 13 تا 15 پر 34,127,872، جن کی پروف حد 8 MiB تھی)۔ 4 × 2048 بنڈل کے چار انویلپس ہیں، انویلپ کی حد پر۔ اس سے بڑی باڈی -32600 ہے، حد کا ذکر کرتے ہوئے۔

صرف -32000 (داخلے نے اسے رد کیا) اور -32602 (اسے ڈی کوڈ نہیں کیا جا سکا) ٹرانزیکشن پر فیصلہ ہیں۔ کوئی بھی دوسری ناکامی، بشمول -32603، اس کا انجام نامعلوم چھوڑتی ہے: نوڈ جواب دینے سے پہلے ٹرانزیکشن کو پول میں رکھ کر گوسپ کر دیتا ہے، اس لیے جو نوڈ اس وقفے میں رک جائے وہ ایسی چیز داخل کر چکا ہو سکتا ہے جس کا اس نے کبھی جواب نہیں دیا۔ randprotocol_client بھیجی گئی ٹرانزیکشن کو صرف انہی دو کوڈز پر رد شدہ مانتا ہے۔

rand_getTransactionStatus

پیرامیٹرز [[hash, …]]، 1 سے 64 ہیش۔ نتیجہ: ہر ہیش کے لیے ایک اندراج، اسی ترتیب سے:

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

ہر ہیش کے لیے تلاش کی ترتیب: کمٹ شدہ (اسٹوریج)، زیرِ التوا (مےمپول)، رد شدہ (رد شدگان کا کیش جسے rand_status کا refused_cache شمار کرتا ہے)، ورنہ unknown۔ rejected صرف ان استردادات کا احاطہ کرتا ہے جو ٹرانزیکشن کے اپنے بائٹس سے متعلق ہوں، جنہیں کوئی بعد کا بلاک نہیں بدل سکتا: غلط پروف، ایسا بنڈل ڈائجسٹ جو وہ نہیں جو اس کے پروف نے شائع کیا، غلط منٹ دستخط، غلط chain id، حد سے بڑا حصہ، ٹرانزیکشن کے اندر دہرایا گیا نلیفائر یا کمٹمنٹ، غلط سائز کا انویلپ، غائب یا غیر مطابق auth پروف، ایسا بنڈل یا auth پروف جو غلط گیس حد ظاہر کرے۔ جو استرداد اس لمحے نوڈ کی اسٹیٹ پر منحصر ہو — خرچ شدہ نلیفائر، ونڈو سے باہر اینکر یا time، کم از کم حد سے کم فیس (جو chain 20 پر گیس کی قیمتوں کے ساتھ بدلتی ہے)، نامعلوم پروگرام، رجسٹر نانس، پرانا invoke ریڈ — وہ یاد نہیں رکھا جاتا اور unknown دکھاتا ہے۔ خالی فہرست یا 64 سے زیادہ ہیش کے لیے -32602۔

rand_mint (testnet فاسٹ)

پیرامیٹرز [address] یا [address, amount]؛ address ایک rand1… ایڈریس، amount اکائیوں کی ایک سٹرنگ جو زیادہ سے زیادہ 100000000000 ہو (100 RAND، ڈیفالٹ)۔ نتیجہ: منٹ ٹرانزیکشن ہیش۔ صرف اس چین پر جس کے جینیسس میں "faucet": true ہو؛ بصورتِ دیگر -32000 faucet is disabled on this chain۔ آبزرور کا جواب ہوتا ہے faucet mints are signed by validators; ask a validator node۔

جس چین کا جینیسس staking.faucet_recipients مقرر کرتا ہے، جیسا کہ chain 20 کا کرتا ہے (16 والیٹس)، وہاں صرف فہرست میں شامل والیٹس کو ادائیگی ہو سکتی ہے: کسی اور ایڈریس پر منٹ the faucet may not mint to this recipient (not in staking.faucet_recipients) کے ساتھ رد کر دیا جاتا ہے۔ chain 20 کا جینیسس staking.faucet_minters (18 ویلیڈیٹر کلیدیں) بھی مقرر کرتا ہے: صرف فہرست میں شامل کلید ہی منٹ پر دستخط کر سکتی ہے۔ فاسٹ کا فی ایپوک بجٹ بھی ہے، staking.faucet_budget_per_epoch (chain 20 پر ہر 1,000 بلاک کے ایپوک میں 10,000 RAND)؛ اس سے آگے کا منٹ FaucetBudgetExhausted کے ساتھ رد کر دیا جاتا ہے، جو ایک اسٹیٹ فیصلہ ہے اور پول سے نکلنے کے بعد unknown دکھاتا ہے۔

فاسیٹ کی شرح ہر نوڈ پراسیس پر محدود ہے: لگاتار آٹھ اجرا، جن کی گنجائش ایک فی سیکنڈ کے حساب سے دوبارہ بھرتی ہے۔ اس حد سے آگے کال یہ جواب دیتی ہے: faucet is rate limited on this node (8 mints back to back, refilling at 1/s); try again shortly۔ اس لیے فاسیٹ کی بھرمار برج کے PauseMints سے پہلے پول کو نہیں بھر سکتی۔ PauseMints برج گورننس کے دیگر تین اقدامات کی طرح پول کے mempool full انکار سے بھی مستثنیٰ ہے اور بلاک میں سب سے پہلے رکھا جاتا ہے۔

چین 14 سے اجرا کھلا ہوتا ہے: Mint اقدام cm اور amount کے ساتھ نوٹ کا pk، time اور r بھی رکھتا ہے۔ داخلے کے وقت کمٹمنٹ دوبارہ شمار کی جاتی ہے اور جو cm ان پر نہ کھلے اسے مسترد کر دیا جاتا ہے (the mint's commitment does not open to its published note and amount)۔ اجرا کنندہ ساتوں فیلڈز پر ڈومین rand-mint-2 کے تحت دستخط کرتا ہے، اور چین 20 (binding_domain: 1) پر rand-mint-3 کے تحت، جس میں جینیسس ہیش سب سے پہلے آتا ہے۔ لہٰذا فاسیٹ نوٹ کا مالک اور رقم عوامی ہوتے ہیں، جیسے انخلا کی ادائیگی عوامی ہوتی ہے۔ rand_mint کے پیرامیٹرز تبدیل نہیں ہوئے۔

rand_estimateFee

پیرامیٹرز [spec]، جو ان میں سے ایک ہو: {"kind":"bundle"}، {"kind":"deploy","words":n,"public_words":m}، {"kind":"call","tier":t,"bytes":b,"gas":g}، جہاں t کی قدر 10، 12، 14، 16، 18 یا 20 ہو۔ نتیجہ: اکائیوں میں کم از کم فیس، بطور string۔ {"kind":"bundle"} کا نتیجہ "1000000" ہے۔ public_words (اختیاری، طے شدہ قدر 0) کی ادائیگی کوڈ کی طرح فی لفظ ہوتی ہے، اس لیے فیس n + m الفاظ کی ڈیپلائے فیس کے برابر ہوتی ہے۔ bytes (اختیاری، طے شدہ قدر 0) کال کے ثبوت کی لمبائی اور اس کے ان پٹ لفافے کی لمبائی کا مجموعہ ہے۔

کال کی قیمت کا تعین rand_getLimits کے gas_metering پر منحصر ہے:

• "circuit"، ایسی چین جس کا اپنا gas سیکشن ہو، جیسا کہ چین 20 کا ہے۔ gas وہ گیس حد ہے جس کا اعلان کال کا ثبوت کرتا ہے، اور یہ لازمی ہے: اس کے بغیر کال یہ جواب دیتی ہے: -32602 under the gas section a call estimate needs its gas۔ جواب ٹِپ کی موجودہ قیمتوں پر، یعنی انہی قیمتوں پر جو rand_getLimits فراہم کرتا ہے، 1,000,000 + gas_price × gas + byte_price × ⌈bytes / 1024⌉ ہوتا ہے۔ چین 20 کی کم از کم قیمتوں 100 اور 800 پر، 20,479 گیس کا اعلان کرنے والی اور ثبوت و لفافے کے 1,300,000 بائٹس والی کال کا جواب "4063900" ہے۔ قیمتیں ہر بلاک کے ساتھ بدلتی ہیں، اس لیے تخمینہ بھیجنے کے قریب لگائیں۔
• "header"، اس سیکشن کے بغیر چین پر نوڈ کی سطح کی گیس پالیسی۔ کال اسپیک keccak_log_height اور sha256_log_height لیتا ہے (اختیاری، طے شدہ قدر 0، ہر ایک 0 سے 40 کے درمیان، ورنہ -32602)۔ یہ ہیش ٹیبل کی وہ بلندیاں ہیں جن کا اعلان ثبوت کا ہیڈر کرتا ہے۔ جواب لیجر کی درجہ وار کم از کم فیس اور اس ہیڈر کی کم از کم گیس فیس میں سے بڑی قدر ہوتا ہے۔ gas سیکشن کے تحت دونوں بلندیاں قبول تو کی جاتی ہیں مگر استعمال نہیں ہوتیں۔
• null، دونوں میں سے کوئی نہیں۔ صرف لیجر کا درجہ وار جدول لاگو ہوتا ہے: مفت حد (2,097,152 + 18,432 بائٹس) کے اندر کال کی قیمت اس کے درجے کی فیس ہے؛ اس سے اوپر ہر KiB پر 1,000 اکائیاں بڑھتی ہیں، اور ادھورا KiB پورا شمار ہوتا ہے۔

v0.6.8 سے {"kind":"invoke", …, "created_cells": c} ایک RPL-2 invoke کی قیمت لگاتا ہے: اس میں کال اسپیک کی ہر فیلڈ ہوتی ہے، اور ساتھ created_cells (اختیاری، طے شدہ قدر 0، زیادہ سے زیادہ max_writes، ورنہ -32602)، یعنی وہ سیل جو یہ ٹرانزیشن بنائے گی۔ ہر سیل پر چین کی cell_fee (rand_getLimits.program_state) کا اضافہ ہوتا ہے۔ انہیں کال کنندہ خود گنتا ہے: کسی ایسے سیل میں غیر صفر قدر لکھنا جسے rand_getProgramCell صفر پڑھتا ہو۔ چین 20 پر، اوپر والی کال دو نئے سیلوں کے ساتھ "24063900" ہے۔ جس چین پر program_state سیکشن نہ ہو وہاں یہ قسم -32602 لوٹاتی ہے۔

جدول فیس میں ہے۔

پول

rand_getTreeInfo

پیرامیٹرز []۔ نتیجہ { "next_index": 41, "root": "6b1d…c4", "nullifiers": 12 }: لیفوں کی تعداد، موجودہ روٹ، اور کتنے نوٹ خرچ ہو چکے ہیں۔

rand_getCommitments

پیرامیٹرز [from_index] یا [from_index, limit]۔ نتیجہ: from_index سے لیفوں کا ایک صفحہ، پرانے پہلے۔ limit جتنی بھی بڑی ہو، زیادہ سے زیادہ 1,000 قطاریں ملتی ہیں۔

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

rand_getNullifiers

پیرامیٹرز [from_height] یا [from_height, limit]۔ نتیجہ: اس بلندی سے آگے شائع ہونے والا ہر نلیفائر، اسی 1,000 قطاروں کی حد کے ساتھ۔ کوئی صفحہ کسی بلندی کے بیچ میں رک سکتا ہے؛ اگلا صفحہ دیکھی گئی سب سے بڑی بلندی سے دوبارہ شروع کریں۔

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

rand_getCompactBlocks

پیرامیٹرز [from_height, to_height]، دونوں لازمی۔ نتیجہ: ہر بلاک کی ایک قطار، پرانے پہلے، جس میں صرف وہی ہوتا ہے جس کی ہلکے والٹ کو ضرورت ہے:

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

یہاں بنڈل رکھنے والی ہر ٹرانزیکشن کے چار نوٹ اور چار نلیفائر ہوتے ہیں، یعنی اس کے چار سلاٹ۔ ان میں فرضی سلاٹ بھی شامل ہیں، جنہیں کوئی پڑھنے والا اصلی سلاٹوں سے الگ نہیں کر سکتا (مثال میں صرف پہلی کمٹمنٹ قطار دکھائی گئی ہے)۔ v0.6.8 سے کچھ ٹرانزیکشنز ان چار کے بعد مزید نوٹوں کی بھی مالک ہوتی ہیں: ایک invoke ہر ادائیگی کا ایک نوٹ رکھتا ہے، پہلے pays پھر mints، ہر ایک ادائیگی کے اپنے لفافے کے ساتھ، تاکہ وصول کنندہ اسے آزمائشی ڈکرپشن سے ڈھونڈ لے۔ برج فیس والی چین پر، جیسی چین 20 ہے، ایک bridge_burn اپنا خزانہ فیس نوٹ رکھتا ہے، اور ایک bridge_attest اپنے ڈپازٹ کے بعد اپنا فیس نوٹ رکھتا ہے۔ فیس نوٹ کا لفافہ خالی ہوتا ہے اور کسی کے لیے سیل نہیں ہوتا: خزانے کا والٹ یہ نوٹ ٹرانزیکشن کی عوامی فیلڈز سے دوبارہ بنا لیتا ہے۔

ہر کال میں زیادہ سے زیادہ 128 بلاک ملتے ہیں (زیادہ وسیع حد کو محدود کر دیا جاتا ہے)، اور پہلے بلاک کے بعد زیادہ سے زیادہ 1,000 نوٹ۔ پہلا بلاک ہمیشہ مکمل فراہم کیا جاتا ہے۔ آخری لوٹائی گئی height میں ایک جمع کر کے وہیں سے دوبارہ شروع کریں۔ بلاک کی سطح کی commitments array میں بلندی 0 پر جینیسس ڈپازٹ ہوتے ہیں اور باقی جگہ یہ خالی ہوتی ہے؛ کسی Withdraw اور BridgeAttest کے ماخوذ نوٹ ان کی ٹرانزیکشن کے تحت ظاہر ہوتے ہیں۔ الٹی حد یا غائب حد پر -32602 ملتا ہے۔

rand_getAnchor

ہیڈ کے لیے پیرامیٹرز []، یا [height]۔ نتیجہ { "height": 192, "root": "6b1d…c4" }، یا ایسی بلندی کے لیے -32001 جس کا کوئی اینکر درج نہ ہو۔ صرف بلاک کے اختتام کے روٹ اینکر ہوتے ہیں۔ نوڈ پرانی بلندی کا جواب بھی دے سکتا ہے، مگر کسی بنڈل کا اینکر صرف اسی صورت قابلِ قبول ہے جب وہ آخری proof_window_blocks روٹس میں سے ہو: چین 20 پر 1,024، اور چین 19 تک کی چینز پر 256۔ ہیڈ کے مطابق تعمیر کریں۔

rand_getWitness

پیرامیٹرز [index]۔ درخت کے اختتام سے آگے نتیجہ null ہوتا ہے، ورنہ اس لیف کا Merkle راستہ، لیف سے شروع ہو کر، ٹھیک 32 سطحیں، درخت کے موجودہ روٹ کے ساتھ:

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

یہ نوڈ کی سب سے مہنگی ریڈ ہے (یہ گہرائی 32 کا پورا درخت دوبارہ بناتی ہے)، اور یہی واحد درخواست ہے جو کال کنندہ کے بارے میں کچھ ظاہر کرتی ہے۔ کوئی نوڈ ایک وقت میں زیادہ سے زیادہ دو درختوں کی دوبارہ تعمیر چلاتا ہے، اس گنتی میں rand_getWitness اور rand_getWitnesses دونوں شامل ہیں۔ جو درخواست سلاٹ کے لیے 10 s سے زیادہ انتظار کرے وہ -32000 witness builds are busy on this node; retry shortly کے ساتھ مسترد کر دی جاتی ہے۔

rand_getWitnesses

پیرامیٹرز [[index, …]]، 1 سے 32 لیف اشاریے۔ نتیجہ { "root": "…", "witnesses": [ { "index": 7, "path": ["…"] }, { "index": 9, "path": null } ] }: یہ rand_getWitness ہی ہے جو ایک ہی درخت کی تعمیر میں کئی لیفوں پر چلتا ہے، تاکہ کئی نوٹوں کا ثبوت دینے والا والٹ دوبارہ تعمیر کی قیمت ایک بار ادا کرے۔ درخت کے اختتام سے آگے کے اشاریے کے اندراج میں path: null آتا ہے۔ خالی فہرست یا 32 سے زیادہ اشاریوں پر -32602 ملتا ہے۔

ویونگ کلیدیں اور افشا

rand_importViewingKey

پیرامیٹرز [viewing_key] یا [viewing_key, rescan_from_height]، کلید 64 ہیکس حروف کی صورت میں۔ نتیجہ { "imported": true, "rescan_from_height": 0, "viewing_keys": 3 }۔ نوڈ کلید کو صرف میموری میں رکھتا ہے: ہر نوڈ پر زیادہ سے زیادہ 64، جو ری اسٹارٹ پر مٹ جاتی ہیں۔ پہلے سے موجود کلید پر کچھ نہیں ہوتا ("imported": false)۔ امپورٹ کبھی اسکین نہیں کرتا؛ اسکین اگلا میتھڈ چلاتا ہے۔ غلط ساخت کی کلید پر -32602، اور 65ویں کلید پر -32000 ملتا ہے۔

ویونگ کلید کے تینوں میتھڈ صرف لوپ بیک کال کنندہ کو جواب دیتے ہیں اور باقی سب کو -32000 کے ساتھ مسترد کرتے ہیں، الا یہ کہ نوڈ --rpc-viewing-open کے ساتھ کسی تصدیق کرنے والی تہہ کے پیچھے چل رہا ہو۔ rand_removeViewingKey ([viewing_key] → { "removed": bool, "viewing_keys": n }) ایک سلاٹ خالی کرتا ہے اور کلید کو صفر سے مٹا دیتا ہے۔ رجسٹری کی کلید خود ویونگ کلید نہیں بلکہ اس کی یک طرفہ شناخت blake3("rand-viewing-registry-id-1" ‖ nk) ہوتی ہے، اس لیے امپورٹ ہی واحد دیرپا نقل ہے اور ہٹانے سے وہ مٹ جاتی ہے۔ درخواست کا اپنا JSON متن اور آزمائشی ڈکرپشن کے دوران بننے والی عارضی نقلیں نہیں مٹائی جاتیں۔

rand_getViewingNotes

پیرامیٹرز [viewing_key] یا [viewing_key, from_index, limit] (limit کی طے شدہ اور زیادہ سے زیادہ قدر 1,000)۔ ہر کال کلید کا اسکین زیادہ سے زیادہ 10,000 لیف آگے بڑھاتی ہے، پھر صفحہ فراہم کرتی ہے:

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

role یا تو received ہوتا ہے (لفافہ وصول کنندہ کے طور پر کھلا اور نوٹ میں کلید کا pk درج ہے) یا sent (لفافہ بیرونی ویونگ کلید کے ذریعے کھلا)۔ نوٹ کا memo بھیجنے والے کا خفیہ کردہ میمو ہے، زیادہ سے زیادہ 510 بائٹس کا UTF-8 متن۔ اگر میمو موجود نہ ہو یا اس کی فیلڈ غلط ساخت میں کھلے تو یہ null ہوتا ہے؛ غلط ساخت کے میمو کی وجہ سے وصول کنندہ نوٹ سے کبھی محروم نہیں ہوتا۔ میمو میں کوئی بھی متن لکھ سکتا ہے، لہٰذا اسے غیر معتبر سمجھ کر دکھائیں۔ جو کلید اس نوڈ نے امپورٹ نہیں کی اس پر -32001 ملتا ہے۔

rand_checkTransaction

پیرامیٹرز [hash, key]، جہاں key فی ٹرانزیکشن TxKey ہے، 64 ہیکس حروف کی صورت میں۔ نامعلوم ہیش پر نتیجہ null ہوتا ہے، ورنہ وہ جو یہ کلید ظاہر کرتی ہے:

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

بے حالت (stateless): کلید کال کے ساتھ ہی ضائع کر دی جاتی ہے۔ output بنڈل کے چار آؤٹ پٹ سلاٹس کے لیے bundle:0 … bundle:3 ہے (سلاٹ 0–1 نجی اثاثے کے آؤٹ پٹ، سلاٹ 2–3 RAND کے آؤٹ پٹ، فرضی آؤٹ پٹ سمیت)، برج تصدیق نامے کے ڈپازٹ لفافے کے لیے deposit، کسی TokenMint کے نوٹ کے لیے token_mint، کسی RegisterToken کے ابتدائی اجرا کے لیے initial_mint، فاسیٹ اجرا کے واحد لفافے کے لیے mint:0، یا (v0.6.8) ان نوٹس کے لیے payout:0 … payout:3 جو کسی invoke نے ادا کیے، ٹرانزیشن میں ان کے مقام کے لحاظ سے نمبر وار، پہلے pays پھر mints؛ asset_bundle:* دوسرے بنڈل کے ساتھ ختم ہو چکا ہے۔ جس چین پر برج فیس ہو، وہاں deposit خالص ڈپازٹ کھولتا ہے، یعنی مجموعی رقم منہا فیس۔ افشا شدہ note اپنا asset ساتھ رکھتا ہے: یہ کال، اس کلید کے ساتھ جس کے تحت بھیجنے والے نے مہر بند کیا، وہ واحد جگہ ہے جہاں RPC ظاہر کرتا ہے کہ کسی منتقلی نے کون سا اثاثہ منتقل کیا۔ یہ memo بھی ساتھ رکھتا ہے، جیسا کہ rand_getViewingNotes کرتا ہے: جو کلید نوٹ کھولتی ہے وہی میمو بھی کھولتی ہے، اسی مہر بند متن سے۔ غلط کلید { "disclosed": [] } لوٹاتی ہے، جو ایسی ٹرانزیکشن سے ناقابلِ امتیاز ہے جو کچھ بھی افشا نہیں کرتی۔ کسی withdraw اور کسی genesis alloc کے لفافے آزمائے نہیں جاتے: وہ نوڈ کے اندر ایسی کلیدوں کے تحت مہر بند ہوتے ہیں جو فوراً ضائع کر دی جاتی ہیں، اس لیے ان کے لیے کوئی TxKey موجود نہیں۔ فاسیٹ اجرا کا لفافہ آزمایا جاتا ہے: اس کا وصول کنندہ لفافے کے KEM حصے کے ذریعے کلید بازیافت کرتا ہے (rand tx-key)۔

ٹرانزیکشنز

rand_getTransaction

پیرامیٹرز [hash]۔ نتیجہ کمٹ ہونے تک null، پھر:

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

بنڈل کے بغیر کارروائیوں پر bundle کی قدر null ہوتی ہے۔ ثبوت اور لفافے صرف لمبائی کے ذریعے رپورٹ کیے جاتے ہیں۔ چین 20 پر ہر سلاٹ کے لیے envelope_len کی قدر 1,860 ہے، جس کا genesis نوٹ لفافے کو اسی سائز پر مقرر کرتا ہے (rand_getLimits میں envelope_bytes)؛ چین 14 تا 17 پر یہ 1,348 تھی۔ auth_commit اور auth_proof_bytes منقسم اجازت کے حصے ہیں (چین 17 سے): عوامی کمٹمنٹ c = H(AUTH, nk, salt) جسے بنڈل ثبوت اور اجازت ثبوت دونوں شائع کرتے ہیں، اور اجازت ثبوت کی لمبائی۔ جس چین پر hc_auth نہ ہو وہاں یہ صفر اور 0 ہوتے ہیں۔

bundle پوشیدہ اثاثے والا بنڈل ہے (چین 14 سے): چار ان پٹ سلاٹس اور چار آؤٹ پٹ سلاٹس، اس لیے ہمیشہ چار nullifiers، چار commitments اور چار envelope_len، فرضی سلاٹس سمیت۔ ہر ٹرانزیکشن زیادہ سے زیادہ ایک بنڈل رکھتی ہے؛ کوئی دوسرا بنڈل نہیں۔ اس میں کوئی asset فیلڈ نہیں: سلاٹ 0–1 ایک نجی اثاثہ رکھتے ہیں اور سلاٹ 2–3 RAND، اور کوئی عوامی چیز یہ نہیں بتاتی کہ سلاٹ 0–1 نے کون سا اثاثہ منتقل کیا۔ RAND کی منتقلی اور کسی بھی RPL ٹوکن کی منتقلی دونوں "kind": "none" ہیں جن میں burn_a، burn_r اور burn_asset سب 0 ہیں — ایک ہی ساخت، فیلڈ بہ فیلڈ۔ کوئی token_transfer قسم موجود نہیں۔ تینوں burn فیلڈز پول سے نکلنے والی قدر کے بارے میں بنڈل کا واحد عوامی بیان ہیں:

• burn_a / burn_asset — نجی اثاثے کی جلائی گئی مقدار، اور کون سا اثاثہ۔ token_burn یا bridge_burn پر غیر صفر، جہاں یہ کارروائی کے amount اور asset کے برابر ہوتے ہیں، اور ایسے invoke پر جس کا inflow deposit یا burn ہو۔
• burn_r — جلایا گیا RAND۔ bond پر غیر صفر (اس کے amount کے برابر)، register_aggregator پر، اور ایسے invoke پر جو پروگرام کے والٹ میں RAND جمع کرے۔
• fee — RAND فیس، ہمیشہ سلاٹ 2–3 سے۔

کارروائیوں کی پیشکش (ہر amount، relayer_fee اور initial_amount ایک اعشاری سٹرنگ؛ کسی ٹوکن کی مقداریں اس کی اپنی اکائیوں میں ہیں، RAND کی اکائیوں میں نہیں):

کسی ٹوکن کی رجسٹریشن اور اجرا عوامی ہیں، جیسا کہ برج ڈپازٹ ہے: اجرا شدہ نوٹ کا ہر لفظ کارروائی میں موجود ہے (اس کا from چین کا مقررہ MINT_FROM ہے)، اس لیے وصول کنندہ کچھ بھی ڈکرپٹ کیے بغیر انہی فیلڈز سے نوٹ دوبارہ بنا لیتا ہے۔ قسم کی سٹرنگز bridge_attest، token_mint، register_token اور invoke وہ ہیں جن پر والٹ کا اسکین انحصار کرتا ہے، اور ایک ٹیسٹ کے ذریعے مقرر ہیں۔

چین 20 کی بلندی 3,079 پر ایک invoke، جس نے ایک سیل پڑھا، اسے حذف کیا، اور والٹ سے دو نوٹ ادا کیے:

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

یہ سب ڈیزائن کے تحت عوامی ہے۔ reads وہ سیلز ہیں جو پروگرام نے پڑھے، ان قدروں کے ساتھ جو اس نے پڑھیں: ثبوت انہی کے مقابل بنایا گیا، اور لیجر ٹرانزیکشن مسترد کر دیتا ہے جب تک وہ قدریں برقرار نہ ہوں۔ writes وہ سیلز ہیں جو اس نے لکھے؛ 64 صفروں کی لکھی گئی قدر سیل کو حذف کر دیتی ہے۔ سیل کی کلید یا قدر ایک Word8 ہے۔ جو اندر آیا وہ بنڈل کا ہے: burn_r پروگرام کے والٹ میں جمع کیا گیا RAND ہے، اور burn_asset کا burn_a وہ ٹوکن ہے جس کا نام inflow لیتا ہے، والٹ میں deposit یا burn (پروگرام کا اپنا ٹوکن)، اور none جب burn_a کی قدر 0 ہو۔ جو باہر گیا وہ ہر ادائیگی کے لیے چین کا شمار کردہ ایک نوٹ ہے، پہلے والٹ سے pays، پھر ایسے ٹوکن کے mints جس کی اجرا اتھارٹی یہی پروگرام ہو۔ ہر نوٹ کا ہر لفظ یہاں token_mint کے فیلڈ ناموں کے تحت موجود ہے؛ time بنڈل کا ہے، cm وہ لیف ہے جو چین نے شامل کیا، اور نوٹ کا from چین کا مقررہ PROGRAM_FROM ہے۔ پروگرام کے آٹھ آؤٹ پٹ الفاظ رسید پر ہیں، جیسا کہ کال کے ہوتے ہیں۔

منتقلی کا کوئی جواب بھیجنے والا، وصول کنندہ، nonce، مقدار یا اثاثہ نہیں رکھتا: محفوظ شدہ منتقلی میں ایسا کوئی فیلڈ موجود ہی نہیں۔

rand_getRawTransaction

پیرامیٹرز [hash]۔ نتیجہ: مکمل کمٹ شدہ ٹرانزیکشن bincode hex کی صورت میں، ثبوت کے بائٹس سمیت — وہ جس کی مجمّع کو ضرورت ہوتی ہے اور جسے rand_getTransaction کبھی پیش نہیں کرتا۔

پروگرامز اور رسیدیں

rand_getProgram

پیرامیٹرز [program_id]۔ نتیجہ null یا { "id", "base_pc", "words_len", "code_hash", "deployed_at", "public_words_len", "public_digest" }۔ کوئی deployer فیلڈ نہیں: ڈیپلائے کی ادائیگی ایک بنڈل کرتا ہے۔ public_words_len پروگرام کے ڈیپلائے کے وقت کے عوامی ان پٹ کی لمبائی ہے (اس کے بغیر 0)؛ public_digest اس کا ڈائجسٹ ہے، وہ قدر جس کے مقابل ہر کال کا ثبوت جانچا جاتا ہے، یا اس کے بغیر null۔

rand_getProgramCode

پیرامیٹرز [program_id]۔ نتیجہ null یا { "base_pc": 0, "words": [ … ] }۔

rand_getProgramPublic

پیرامیٹرز [program_id]۔ نتیجہ: پروگرام کے ڈیپلائے کے وقت کے عوامی الفاظ ایک hex اسٹرنگ کی صورت میں، ہر لفظ اپنے 4 little-endian بائٹس کے طور پر (فی لفظ 8 hex ہندسے): [1, 2, 0xdeadbeef] کا مطلب "0100000002000000efbeadde" ہے۔ عوامی ان پٹ کے بغیر ڈیپلائے کیے گئے پروگرام کے لیے ""، اور ایسی id کے لیے جس کا کوئی پروگرام نہ ہو null۔ کسی کال کا ثبوت بنانے والا والیٹ یہ الفاظ پروور کو دیتا ہے؛ لیجر ثبوت کے commitment کو پروگرام کے public_digest سے جانچتا ہے۔

rand_getProgramCell

v0.6.8، RPL-2۔ پیرامیٹرز [program_id, key]، جہاں key ایک Word8 ہے جو 64 hex میں لکھی جاتی ہے (0x کے ساتھ یا اس کے بغیر)۔ نتیجہ { "key": "<64 hex>", "value": "<64 hex>" }۔ جس سیل میں پروگرام نے کبھی کچھ نہیں لکھا، یا صفر لکھے (جس سے وہ حذف ہو جاتا ہے)، وہ 64 صفر پڑھا جاتا ہے، جو “غیر موجود” کی واحد صورت ہے؛ ایسے پروگرام کی ہر key کا بھی یہی حال ہے جسے کسی نے ڈیپلائے نہیں کیا، کیونکہ پروگرام کے وجود کی جانچ نہیں کی جاتی۔ جس چین پر program_state سیکشن نہ ہو وہاں { "enabled": false }۔ سیل اپنی ساخت ہی سے عوامی ہوتا ہے: والیٹ کسی invoke کے reads بنانے کے لیے یہی پڑھتا ہے۔

rand_getProgramCells

v0.6.8۔ پیرامیٹرز [program_id, { "after": "<64 hex>" | null, "limit": n }]، آبجیکٹ اختیاری ہے۔ نتیجہ { "cells": [{ "key", "value" }, …], "next": "<64 hex>" | null }: پروگرام کے سیل key کی ترتیب میں (آٹھ الفاظ کا unsigned موازنہ)، after کے بعد سے شروع ہو کر، زیادہ سے زیادہ limit تعداد میں (جو 1 سے 1,000 کی حد میں رکھی جاتی ہے)۔ جب مزید سیل باقی ہوں تو next آخری فراہم کردہ key ہوتی ہے؛ اسے after کے طور پر واپس بھیجیں۔ آخری صفحے پر یہ null ہوتا ہے۔ جس پروگرام کا کوئی سیل نہ ہو وہ { "cells": [], "next": null } جواب دیتا ہے؛ سیکشن نہ ہونے پر { "enabled": false }۔

rand_getProgramVault

v0.6.8۔ پیرامیٹرز [program_id]۔ نتیجہ [{ "asset": 0, "amount": "123" }, …]، اثاثے کے اشاریے کی صعودی ترتیب میں (0 سے مراد RAND ہے، باقی ہر اشاریہ ٹوکن رجسٹری کا ہے)، رقوم اعشاری اسٹرنگز کی صورت میں اثاثے کی اپنی اکائیوں میں۔ صفر والی قطار موجود ہی نہیں ہوتی، اس لیے خالی تجوری، اور ایسا پروگرام جسے کسی نے ڈیپلائے نہیں کیا، دونوں [] ہیں۔ سیکشن نہ ہونے پر { "enabled": false }۔ قدر کسی invoke کے بنڈل کے ذریعے تجوری میں داخل ہوتی ہے (burn_r، اور جب inflow کی قدر deposit ہو تو burn_asset کا burn_a) اور ان نوٹس کی صورت میں نکلتی ہے جن کا نام transition کے pays میں ہو۔

rand_getLimits

پیرامیٹرز []۔ نتیجہ: ٹرانزیکشن بنانے کے لیے والیٹ کو چین کے جینیسس سے جو کچھ درکار ہے: کال کی پانچ حدود، نوٹ لفافے کا سائز، v0.6 سوئچ، auth guest، گیس کی شرائط اور، v0.6.8 سے، audit-v6 جینیسس فیلڈز اور پروگرام اسٹیٹ کی حدود۔ چین 20 پر:

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

جس جینیسس میں حدود کے یہ پانچ فیلڈز نہ ہوں (چین 12) اسے 4096، 2097152، 4194304، 18432 اور 0 ملتے ہیں۔ چین 13 سے 15 پر max_proof_bytes کی قدر 8,388,608 تھی۔

جو نوڈ کسی فیلڈ سے پہلے کا ہو وہ اس کے بغیر جواب دیتا ہے۔ اس جواب میں کچھ بھی تصدیق شدہ نہیں، اس لیے والیٹ envelope_bytes کو محض نوڈ کے کہنے پر قبول نہیں کرتا: rand والیٹ چین id 14 سے 17 پر پرانا لفافہ ہی سیل کرتا ہے خواہ نوڈ کچھ بھی جواب دے، اور دوسرے کلائنٹس کو بھی یہی کرنا چاہیے۔

rand_getReceipt

پیرامیٹرز [tx_hash]۔ کال commit ہونے تک نتیجہ null، پھر { "tx", "program", "tier": 14, "outputs": [1, 0, 25, 0, 0, 0, 0, 0], "height": 17, "index": 0, "h_in": "9c0e…7f", "h_pub": null }۔ کوئی effect فیلڈ نہیں۔ h_pub پروگرام کے ڈیپلائے کے وقت کے عوامی ان پٹ کا digest ہے جس کے مقابل کال کا ثبوت جانچا گیا، اور عوامی ان پٹ کے بغیر پروگرام کے لیے null۔ کسی invoke (v0.6.8) کی رسید کال کی رسید ہی ہوتی ہے، اور rand_getReceipts اور receipts ٹاپک اسے بغیر تبدیلی کے پہنچاتے ہیں۔

rand_getReceipts

پیرامیٹرز [program_id, from_height, to_height, limit?]۔ نتیجہ { "receipts": [ … ], "next_height": 2051 }: program_id کی وہ رسیدیں جن کے لیے from_height <= height <= to_height ہو، پہلے اونچائی اور پھر اشاریے کی ترتیب میں، ہر ایک بالکل rand_getReceipt والا آبجیکٹ۔ limit کی طے شدہ قدر اور زیادہ سے زیادہ حد دونوں 256 ہیں اور یہ کبھی کسی اونچائی کو تقسیم نہیں کرتا: جب کسی صفحے میں limit رسیدیں ہو جائیں تب بھی وہ اس اونچائی کی باقی رسیدیں فراہم کرتا ہے۔ next_height پہلی وہ اونچائی ہے جو فراہم نہیں ہوئی، یا null جب صفحہ to_height پر ختم ہوا ہو۔ اگر to_height کی قدر from_height سے کم ہو تو -32602۔

rand_getCallEnvelope

پیرامیٹرز [tx_hash]۔ نتیجہ null، یا hex میں { "tx", "h_in", "kem_ct", "to_sender", "to_auditor", "body" } — کال کا سیل شدہ ان پٹ ٹرانسکرپٹ، جوں کا توں فراہم کیا جاتا ہے؛ نوڈ کے پاس اسے کھولنے والی کوئی key نہیں۔ null جب کال نے کچھ شائع نہ کیا ہو (--no-envelope)، ٹرانزیکشن کال نہ ہو، یا کوئی رسید نہ ہو۔

اسٹیکنگ اور رسد

rand_getValidators

پیرامیٹرز []۔ نتیجہ: رجسٹر کے ہر اندراج کے لیے ایک قطار، ایڈریس کی ترتیب میں، رقوم اعشاری اسٹرنگز کی صورت میں:

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

jailed_until (v0.6.8) وہ پہلا ایپوک ہے جس میں slash شدہ key دوبارہ کسی سیٹ میں شامل ہو سکتی ہے (مستقل طور پر خارج ہونے کی صورت میں 18446744073709551615)، اور جب key قید میں نہ ہو تو null۔ چین 20 پر staking.slashing نہیں ہے، اس لیے وہاں یہ ہمیشہ null ہوتا ہے۔

rand_getAdmitted

v0.6.8۔ پیرامیٹرز []۔ نتیجہ { "admission_by_vote": true, "max": 256, "admitted": ["<address>", …] }: وہ کلیدیں جنہیں ویلیڈیٹر سیٹ نے AdmitValidator کے ذریعے ووٹ دے کر داخل کیا ہے اور جو ابھی رجسٹر نہیں ہوئیں، ایڈریس کی ترتیب میں۔ جس چین کا جینیسس staking.admission_by_vote مقرر کرتا ہے، جیسا کہ چین 20 کا کرتا ہے، اس پر نئی کلید رجسٹر کرنے والا Bond انہی میں سے ہونا چاہیے۔ max بتاتا ہے کہ لیجر بیک وقت کتنی کلیدیں رکھتا ہے۔ جس چین پر یہ فلیگ نہ ہو وہاں admission_by_vote کی قدر false ہوتی ہے، فہرست ہمیشہ خالی رہتی ہے اور رجسٹریشن کے لیے کسی ووٹ کی ضرورت نہیں ہوتی۔ چین 20 نے 2026-10-01 کو "admitted": [] جواب دیا۔

rand_getEpoch

پیرامیٹرز []۔ نتیجہ { "epoch": 41, "epoch_blocks": 1000, "next_set": ["…", "…"] }؛ next_set ایک تخمینہ ہے۔

rand_getSupply

پیرامیٹرز []۔ نتیجہ:

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

subsidised، sealed_blocks، aggregator_bonds اور slashed صرف ایگریگیشن چین پر بدلتے ہیں۔ faucet_epoch اور faucet_minted_in_epoch فاسیٹ کا فی ایپاک کاؤنٹر ہیں جو staking.faucet_budget_per_epoch کے مقابلے میں گنا جاتا ہے (چین 20 پر یہ کنسینسس اسٹیٹ ہے)۔ چاروں vesting_* فیلڈز جینیسس ویسٹنگ کے کاؤنٹر ہیں، اور جس چین میں vesting سیکشن نہ ہو وہاں سب "0" ہوتے ہیں، اور چین 20 ایسی ہی چین ہے۔ program_rand_out اور program_rand_held (v0.6.8، RPL-2؛ program_state سیکشن کے بغیر "0") وہ RAND ہیں جو invokes نے پروگرام والٹس سے نوٹس کی صورت میں ادا کیے (پول کی جانب، pool_value کے اندر) اور جو والٹس میں اب بھی موجود ہیں (رجسٹر کی جانب، total_supply کے اندر)؛ یہ کسی invoke کے burn_r کے ذریعے داخل ہوئے، اس لیے پول کی جانب یہ burned میں شامل ہیں۔ registration_fees_burned اُن ٹوکن رجسٹریشن فیسوں کا Σ ہے جو جینیسس کے tokens.burn_registration_fee کے تحت جلائی گئیں، جسے چین 20 مقرر کرتا ہے؛ invariant_holds اسے slashed کے ساتھ چین کے جاری کردہ کل سے منہا کرتا ہے۔ سپلائی اس مساوات کی وضاحت کرتا ہے۔

rand_getEmission

پیرامیٹرز []۔ نتیجہ { "inflation": "0", "subsidy": null, "faucet": true }۔ inflation مستقل طور پر "0" ہے۔ subsidy بلاک ایگریگیشن کا شیڈول ہے (current، base، halving_blocks، sealed_blocks، next_halving_at)، اور جس چین میں aggregation سیکشن نہ ہو وہاں null ہوتا ہے، اور چین 20 ایسی ہی چین ہے۔ faucet وہی قدر دکھاتا ہے جو rand_status میں ہے۔

برج

چاروں میتھڈز ہر چین پر جواب دیتے ہیں؛ جس چین میں bridge سیکشن نہ ہو وہاں اسٹیٹ { "enabled": false } اور رجسٹری [] ہوتی ہے۔ چین 20 کے جینیسس میں یہ سیکشن موجود ہے: نگہبان سیٹ 1 (guardian_set_index 1) جس میں آٹھ نگہبان ہیں، آٹھ PQ نگہبان، ایک توقف کلید، جینیسس پر burn_sequence 13، ایک ری پلے حد (سورس چینز 2، 3 اور 4 کے لیے min_inbound_sequence 3، اور سورس چین 5 کے لیے 7)، برج rules_v2 جس میں تمام بیکنگز پر مجموعی طور پر ہر 24 گھنٹے کی ونڈو میں 4,000 zUSD کی عالمی منٹ حد ہے، اور v0.6.8 میں شامل دو نئے گروپ: rotation (کسی PQ نگہبان یا توقف کلید کی تبدیلی کے لیے نئی کلیدوں کی ملکیت کا ثبوت درکار ہے اور یہ کمٹ ہونے کے 86,400 s بعد نافذ ہوتی ہے) اور fees (ہر ڈپازٹ کا 10 bps اور ہر برن کا 10 bps، جو Rand پر ایک zUSD نوٹ کی صورت میں ایک ٹریژری ایڈریس کے نام رکھا جاتا ہے)۔ چین 19 میں burn_sequence 8 تھا، حدیں 1 اور 4 تھیں، اور ان دونوں میں سے کوئی گروپ نہیں تھا۔ اس کے tokens سیکشن میں 1 RAND کی registration_fee (جو جلا دی جاتی ہے)، فی بیکنگ mint_cap_per_day کی قدر 10000000000000 (آٹھ اعشاریوں پر 100,000 zUSD) ہے، اور یہ خود zUSD کو درج کرتا ہے: جینیسس پر چین 14 سے منتقل شدہ، وہی ایسٹ آئی ڈی، انڈیکس 1، سات بیکنگز۔

rand_getBridgeState

پیرامیٹرز []۔ نتیجہ { "enabled": false }، یا:

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

کوئی بیلنس نہیں: برج شدہ قدر نوٹس کی صورت میں ہوتی ہے۔ اب کوئی next_index نہیں ہے: برج شدہ ٹوکن ڈپازٹ ہونے سے پہلے اُس انڈیکس کے تحت لسٹ ہوتا ہے جو اس کی رجسٹریشن پہلے ہی طے کر چکی ہوتی ہے، اس لیے پیش گوئی کے لیے کوئی انڈیکس باقی نہیں رہتا۔ لسٹ شدہ ٹوکن کا انڈیکس assets یا rand_getTokens سے پڑھیں۔

rand_getAssets

پیرامیٹرز []۔ نتیجہ: برج کی ایسٹ رجسٹری، انڈیکس کے لحاظ سے صعودی ترتیب میں، یا []:

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

v0.6.8 سے ہر بیکنگ قطار، یہاں بھی اور جہاں کہیں بیکنگز فراہم کی جاتی ہیں (rand_getBridgeState.assets، اور rand_getToken، rand_getTokens اور rand_getTokenSupply کی backings)، minted_in_window (اعشاری اسٹرنگ) اور mint_window_secs رکھتی ہے، جو دونوں روزانہ کاؤنٹر والی چین پر null ہوتے ہیں، اور mint_headroom بھی: اُس بیکنگ میں وہ سب سے بڑا ڈپازٹ جو ہیڈ کے بلاک ٹائم پر حدیں قبول کرتی ہیں، یعنی فی بیکنگ حد میں سے اس کی منٹ شدہ رقم منہا کر کے، اور rules v2 کے تحت اس سے زیادہ نہیں جتنا رجسٹری بھر کی ونڈو میں باقی ہے۔ mint_headroom پڑھیں، نہ کہ mint_cap_per_day − minted_today، جو عالمی حد کو نظرانداز کرتا ہے۔ rules v2 کے تحت، جیسا کہ چین 20 پر ہے، minted_today رولنگ ونڈو کی گنتی ہے، یعنی وہ عدد جس کے مقابلے میں فی بیکنگ حد جانچی جاتی ہے؛ نیچے دی گئی روزانہ کاؤنٹر کی وضاحت چین 14 کی ہے۔

ہر بیکنگ (سورس کوائن) کی ایک قطار، اس لیے سات بیکنگز والا ٹوکن ایک ہی index کے تحت سات قطاریں ہے۔ index وہ asset لفظ ہے جو اس ایسٹ کا نوٹ رکھتا ہے؛ انڈیکس 0 RAND ہے اور کبھی رجسٹری میں نہیں ہوتا۔ decimals بیکنگ کے سورس اعشاریے ہیں۔ locked، mint_cap_per_day اور minted_today ٹوکن کی اپنی آٹھ اعشاری اکائیوں میں اعشاری اسٹرنگز ہیں، کبھی RAND کی اکائیوں میں نہیں؛ mint_day ایک سادہ عدد صحیح ہے، UTC دن کا نمبر۔ mint_cap_per_day جینیسس کا tokens.mint_cap_per_day ہے، یعنی وہ زیادہ سے زیادہ رقم جو ایک بیکنگ بلاک ٹائم کے ہر UTC دن میں منٹ کر سکتی ہے۔ minted_today وہ رقم ہے جو بیکنگ نے mint_day پر منٹ کی، یعنی ہیڈ بلاک کے UTC دن (timestamp_ms / 86,400,000) پر، اس لیے کسی پچھلے دن کا بچا ہوا کاؤنٹر ہیڈ کے آدھی رات عبور کرتے ہی "0" پڑھتا ہے۔ حد سے زائد ڈپازٹ MintCapExceeded کے ساتھ مسترد ہوتا ہے اور اگلے دن قابلِ قبول ہو جاتا ہے۔ chain اور token وہ وائر شناخت ہیں جس کے بارے میں نگہبان دستخط کرتے ہیں؛ asset_id ان دونوں کا blake3 ہے، جو rand_bridgeAssetId شمار کرتا ہے۔

rand_bridgeAssetId

پیرامیٹرز [token_chain, token_address] (عدد صحیح، 32 بائٹس hex)۔ نتیجہ: ایسٹ آئی ڈی، 64 hex حروف۔ خالص حساب۔

rand_getBridgeBurn

پیرامیٹرز [sequence]۔ نتیجہ null یا { "sequence": 0, "body_hex": "…", "digest": "…", "tx": "…", "height": 2, "amount": "…", "release_amount": "…", "fee": "…" }۔

آخری تین فیلڈز v0.6.8 کی ہیں، ہر چین پر، ٹوکن کی آٹھ اعشاری اکائیوں میں اعشاری اسٹرنگز کے طور پر۔ release_amount وہ رقم ہے جو دستخط شدہ متن میں درج ہے، اور خود body_hex سے پڑھی جاتی ہے: یعنی جو رقم سورس کنٹریکٹ ریلیز کرتا ہے، اور اسی میں سے وہ متن میں درج ریلیئر فیس ادا کرتا ہے۔ fee وہ برج فیس ہے جو چین نے ٹریژری نوٹ کی صورت میں رکھی، اور amount وہ رقم ہے جو بنڈل نے جلائی، یعنی release_amount + fee۔ bridge.fees کے بغیر (چین 14 تا 19) fee کی قدر "0" ہوتی ہے۔ چین 20 پر سیکوئنس 13، یعنی 0.999 zUSD کا برن: "amount": "99900000"، "fee": "99900"، "release_amount": "99800100"۔

ٹوکنز (RPL)

RPL ٹوکن رجسٹری: ہر ٹوکن، برج شدہ بھی اور مقامی بھی۔ ٹوکنز اس معیار کی وضاحت کرتا ہے۔

rand_getTokens

پیرامیٹرز [from_index, limit]، دونوں اختیاری (0 اور 1000؛ limit کو 1,000 تک محدود کیا جاتا ہے)۔ نتیجہ: from_index سے شروع ہو کر انڈیکس کے لحاظ سے صعودی ترتیب میں رجسٹری، جو اسی انڈیکس سے رینج کے ذریعے پڑھی جاتی ہے:

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

جس چین پر tokens سیکشن نہ ہو، وہاں: { "enabled": false, "tokens": [] }۔ index وہ asset لفظ ہے جو ٹوکن کا نوٹ اپنے ساتھ رکھتا ہے (0، RAND ہے اور کبھی فہرست میں شامل نہیں ہوتا)۔ id ٹوکن کی اثاثہ شناخت ہے اور id_text اس کی چیک سم شدہ متنی صورت: bech32m، HRP rpl، 32 شناختی بائٹس پر، 62 حروف۔ authority ان میں سے ایک ہے:

رسد، locked، mint_cap_per_day، minted_today اور registration_fee اعشاری سٹرنگز ہیں (registration_fee کے لیے RAND اکائیوں میں، باقی کے لیے ٹوکن اکائیوں میں)؛ next_index، mint_day اور max_tokens اعداد ہیں۔ max_tokens رجسٹری پر جینیسس کی مقرر کردہ حد ہے (چین 20 پر 4,096؛ حد نہ ہو تو null)، جس سے آگے رجسٹریشن RegistryFull کے ساتھ مسترد ہو جاتی ہے۔ burn_registration_fee بتاتا ہے کہ آیا رجسٹریشن کی فیس تجویز کنندہ کو ادا کرنے کے بجائے جلا دی جاتی ہے؛ bound_note_value یہ کہ آیا 2⁶³ یا اس سے زائد کا اجرا یا ڈپازٹ ایک توثیقی قاعدہ ہے (داخلہ ہر چین پر بہرحال اسے رد کرتا ہے)۔ چین 20 پر تینوں مقرر ہیں۔ limit سے چھوٹا صفحہ آخری ہوتا ہے۔

program اختیار ({ "kind": "program", "program": "<id>" }) صرف اسی چین پر رجسٹر کیا جا سکتا ہے جس میں program_state سیکشن ہو، جیسا کہ چین 20 (v0.6.8) میں ہے: ٹوکن صفر رسد سے شروع ہوتا ہے، اور صرف اسی پروگرام کی طلبیاں اسے جاری یا تلف کرتی ہیں۔

والیٹ کسی ٹوکن شناخت کو اسی فہرست کے ذریعے حل کرتا ہے، کبھی rand_getToken کے ذریعے نہیں: منتقلی کا اثاثہ چین پر نجی ہوتا ہے، اور پوری رجسٹری پڑھنے کی لاگت یکساں رہتی ہے خواہ کوئی بھی ٹوکن مراد ہو۔

rand_getToken

پیرامیٹرز [token]: رجسٹری انڈیکس (عدد یا اعشاری سٹرنگ)، 64-ہیکس شناخت (0x کے ساتھ یا اس کے بغیر، کسی بھی کیس میں) یا rpl1… متنی صورت (تمام چھوٹے یا تمام بڑے حروف میں)۔ نتیجہ: اس ٹوکن کی rand_getTokens قطار، یا null۔ ناقص شناخت — غلط چیک سم، کوئی اور HRP، غلط لمبائی، ملے جلے کیس کے حروف، غیر ہیکس — -32602 ہے، تاکہ ٹائپنگ کی کوئی غلطی کبھی کسی اور ٹوکن کی طرف نہ لے جائے۔ فی ٹوکن تلاش نوڈ کو بتا دیتی ہے کہ کال کنندہ کو کس ٹوکن سے غرض ہے؛ یہ ایکسپلوررز اور یک بارگی پڑھائی کے لیے ہے۔

rand_getTokenSupply

پیرامیٹرز [token]، وہی صورتیں۔ نتیجہ null، یا:

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

مقامی ٹوکن کے لیے backings خالی ہوتا ہے؛ برج شدہ ٹوکن کے لیے locked رقوم کا مجموعہ total_supply کے برابر ہوتا ہے۔ رازداری سے متعلق وہی نکتہ جو rand_getToken کے لیے ہے۔

بلاک ایگریگیشن (چین 20 پر فعال نہیں)

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

Aggregate باقی ہر چیز کی طرح rand_sendTransaction کے ذریعے جمع کرایا جاتا ہے۔

جینیسس ویسٹنگ (چین 20 پر فعال نہیں)

یہ طریقے نوڈ میں ان چینز کے لیے موجود ہیں جن کے جینیسس میں vesting سیکشن ہو۔ ابھی تک کسی چین میں یہ سیکشن نہیں ہے: چین 20 پر ہر طریقہ { "enabled": false } جواب دیتا ہے۔ عوامی اینڈپوائنٹ 2026-10-01 سے انہیں آگے بھیجتا ہے۔

رقوم اعشاری سٹرنگز ہیں۔ ویسٹنگ کے چاروں اعمال rand_sendTransaction کے ذریعے جمع کرائے جاتے ہیں۔

سبسکرپشنز (WebSocket)

ws://127.0.0.1:8545/ یا /ws۔ ساکٹ صرف rand_subscribe اور rand_unsubscribe فراہم کرتا ہے اور کسی بھی اور طریقے کو -32601 جواب دیتا ہے۔ تین موضوعات ہیں، آزاد سلسلے جن کے درمیان ترتیب کی کوئی ضمانت نہیں:

• newHeads — rand_getHead کی ساخت، ہر کمٹ شدہ بلاک پر ایک بار، ترتیب سے، ہم آہنگی کے دوران بھی بھیجی جاتی ہے۔ یہاں view بلاک کا اپنا ویو ہے۔
• receipts یا receipts <program_id> — ہر اس کمٹ شدہ بلاک کے لیے ایک اطلاع جس میں کم از کم ایک مطابقت رکھنے والی کال رسید ہو: { "height", "hash", "receipts": [ … ] }، ہر رسید rand_getReceipt کی ساخت میں۔
• transaction <hash> — ایک اطلاع، پھر نوڈ سبسکرپشن ہٹا دیتا ہے: { "status": "committed", "height", "index" }، یا ٹرانزیکشن کے اپنے بائٹس سے متعلق انکار پر { "status": "rejected", "reason" } (وہی حد جو rand_getTransactionStatus کی ہے)۔ حالت پر منحصر انکار کا کبھی اعلان نہیں ہوتا، اس لیے اس کے ساتھ ٹائم آؤٹ رکھیں۔

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

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

حدود: فی نوڈ 64 کنکشن (65واں اپ گریڈ پر 503 کے ساتھ رد ہو جاتا ہے)، فی کنکشن 8 سبسکرپشنز، فی کلائنٹ فریم 64 KiB، ہر 30 s پر ایک پنگ جس کا جواب 5 s کے اندر آئے، اور فی سلسلہ 256 اندراجات کا بیک لاگ — جو سبسکرائبر اپنے سنے جانے والے سلسلے پر اس سے زیادہ پیچھے ہو، اسے بفر کرنے کے بجائے کوڈ 1008 کے ساتھ بند کر دیا جاتا ہے؛ دوبارہ جڑیں اور خلا کو rand_getCompactBlocks (ہیڈز)، rand_getReceipts (رسیدیں) یا rand_getTransactionStatus (ایک ٹرانزیکشن) سے پُر کریں۔ اپ گریڈ ہیڈرز کے بغیر سادہ GET / کا جواب 400 ہوتا ہے۔

خرابیاں

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

rand_sendTransaction کے لیے صرف -32000 اور -32602 ٹرانزیکشن پر حتمی فیصلہ ہیں؛ کسی بھی اور کوڈ کے بعد اس کا انجام نامعلوم ہے (دیکھیں rand_sendTransaction)۔

تراشے ہوئے نوڈ: خرابی -32010

--prune-history <window> کے ساتھ شروع کیا گیا نوڈ پورا لیجر (نوٹس، نلیفائرز، اینکرز، رجسٹر) رکھتا ہے لیکن بلاکس، ٹرانزیکشنز اور رسیدوں میں سے صرف آخری <window>؛ rand_status.prune_floor وہ کم ترین بلندی ہے جو اب بھی اس کے پاس موجود ہے۔ چین 20 پر 26 میں سے 24 ویلیڈیٹرز --prune-history 24h چلاتے ہیں؛ دونوں آرکائیو نوڈ اس فلیگ کے بغیر چلتے ہیں اور ہر بلاک محفوظ رکھتے ہیں، اور عوامی اینڈپوائنٹ انہی میں سے ایک کو آگے بھیجتا ہے۔

• بلندی کے لحاظ سے، نچلی حد سے نیچے (جینیسس کے سوا): rand_getBlockByHeight، بلندی کے لحاظ سے rand_getFinality، اور ایسی rand_getBlocks، rand_getCompactBlocks یا rand_getReceipts رینج جو اس حد سے نیچے پہنچے، -32010 pruned: height h is below this node's retention floor f کے ساتھ data: { "floor": f } جواب دیتے ہیں۔ کسی آرکائیو سے پوچھیں۔ [0, 0] اب بھی جینیسس فراہم کرتا ہے۔
• ہیش کے لحاظ سے: rand_getBlockByHash، rand_getReceipt، rand_getRawTransaction، rand_getCallEnvelope اور rand_getAggregate تراشے گئے ہیش کے لیے null جواب دیتے ہیں، بالکل اس ہیش کی طرح جو کبھی موجود ہی نہ تھا؛ صرف آرکائیو ہی دونوں میں فرق کر سکتا ہے۔ rand_getTransaction اور rand_checkTransaction بھی null جواب دیتے ہیں، اور -32010 صرف تب جب کوئی مقام کی قطار باقی رہ گئی ہو جو نچلی حد سے کم بلندی بتاتی ہو۔ rand_getTransactionStatus تراشے ہوئے نوڈ پر ہر unknown اندراج میں floor شامل کرتا ہے۔
• والیٹ اسکیننگ متاثر نہیں ہوتی: rand_getCommitments، rand_getNullifiers، rand_getAnchor اور وٹنس طریقے ایسے خاندانوں کو پڑھتے ہیں جو کبھی تراشے نہیں جاتے۔

نیٹ ورک پر ٹرانزیکشن

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

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

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

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

bincode کی طے شدہ ترتیب: مقررہ چوڑائی کے صحیح اعداد، 8 بائٹ کے لمبائی سابقے، اعلان کی ترتیب میں u32 اینم ٹیگز۔ ایگریگیشن کے پانچ ویریئنٹس اینم میں BridgeBurn کے بعد اور RegisterToken سے پہلے آتے ہیں (ٹرانزیکشنز)؛ چین 20 انہیں کبھی قبول نہیں کرتا، نہ ویسٹنگ کے چار ویریئنٹس کو اور نہ SlashEquivocation کو، لیکن جو انکوڈر ٹیگ نمبر ہارڈ کوڈ کرتا ہے اسے پھر بھی انہیں شمار کرنا ہوگا۔

بنڈل کی آخری دو فیلڈز v0.6.3 اور چین 17 کے ساتھ آئیں۔ bincode مقام پر مبنی ہے، اس لیے چین 16 یا اس سے پہلے کے لیے لکھا گیا انکوڈر ایسی ٹرانزیکشن نہیں بناتا جسے یہ چین ڈی کوڈ کر سکے، اور ان کے ساتھ ہر ٹرانزیکشن شناخت بدل گئی: شناخت کا ڈومین اب rand-txid-3 ہے، جو auth_commit اور توثیقی ثبوت کے ڈائجسٹ کو پابند کرتا ہے۔ جو کلائنٹ شناختیں مقامی طور پر دوبارہ شمار کرتا ہے اسے بھی اس کے ساتھ تبدیل ہونا ہوگا۔ چین 20 پر ہر بنڈل ایک توثیقی ثبوت رکھتا ہے، خواہ خود ثابت کردہ ہو یا تفویض کردہ۔ v0.6.8 Transaction یا Bundle کی ساخت میں کچھ نہیں بدلتا؛ یہ اعمال 28 تا 33 کا اضافہ کرتا ہے۔

ہر ٹرانزیکشن میں زیادہ سے زیادہ ایک بنڈل ہوتا ہے۔ Bond ایسا بنڈل رکھتا ہے جس کا burn_r اس کے amount کے برابر ہو، اور burn_a اور burn_asset 0 ہوں۔ BridgeBurn یا TokenBurn بنڈل کے ذریعے تلف کرتا ہے: burn_asset لازماً عمل کا asset ہو (کبھی 0 نہیں)، burn_a عمل کا amount، اور burn_r 0، جبکہ fee سلاٹ 2–3 سے RAND میں ادا ہوتی ہے۔ باقی کوئی عمل کوئی ٹوکن تلف نہیں کرتا، اور RAND صرف burn_r کے ذریعے ہی تلف ہوتا ہے: جس بنڈل میں burn_asset 0 اور burn_a غیر صفر ہو، وہ ہر جگہ مسترد کیا جاتا ہے۔ BridgeAttest کا r اخذ کیا جاتا ہے، منتخب نہیں کیا جاتا: داخلے کے لیے اس ڈائجسٹ پر، جس پر نگہبانوں نے دستخط کیے، blake3("rand-deposit-r-1" ‖ mu) لازم ہے اور کوئی بھی دوسری قدر مسترد کر دی جاتی ہے (WrongDepositBlinding، ایک مستقل استرداد)۔ کسی برج شدہ ٹوکن کا کوئی تصدیق نامہ قابلِ قبول ہونے سے پہلے اس ٹوکن کا اندراج ہوتا ہے، جینیسس پر یا RegisterBridgedToken / ListBacking کے ذریعے؛ غیر مندرج سکے کا تصدیق نامہ UnlistedToken کے ساتھ مسترد کیا جاتا ہے۔

ہر بنڈل ثبوت اسی ٹرانزیکشن پر بنایا جاتا ہے اور اسی کے مقابل اس کی توثیق کی جاتی ہے جس میں وہ شامل ہو: پوری ٹرانزیکشن، جس کے ثبوت خالی کر دیے گئے ہوں، چین آئی ڈی سے اور، چین 20 پر (binding_domain: 1)، جینیسس ہیش سے بھی، نئے ٹیگز کے تحت منسلک ہوتی ہے۔ چین 14 سے 19 تک یہ ربط صرف چین آئی ڈی سے تھا، اس لیے چین 19 کے لیے بنائے گئے ثبوت کی چین 20 پر توثیق نہیں ہوتی، اور v0.6.8 سے پرانا والیٹ وہاں کچھ نہیں بھیج سکتا۔ چین 18 سے 20 پر اپنے دونوں ثبوتوں کے بغیر ایک بنڈل 7,936 بائٹس میں انکوڈ ہوتا ہے اور ان کے بغیر ایک ٹرانسفر ٹرانزیکشن 7,949 میں (چین 14 سے 16 پر 5,848 اور 5,861، 1,348 بائٹ کے لفافوں کے ساتھ اور اجازت کے فیلڈز کے بغیر)۔ پروڈکشن پروفائل پر نیٹ ورک میں ایک ٹرانسفر تقریباً 2.85 MB کا ہوتا ہے، جو تقریباً سارا ثبوت ہے: تقریباً 1.49 MB کا بنڈل ثبوت اور تقریباً 1.36 MB کا اجازت کا ثبوت۔ منقسم اجازت دہی سے پہلے یہ تقریباً 1.43 MB تھا۔