عرضه

په دې پاڼه کې ښودل شوي چې rand_getSupply څنګه سم ولولئ او د صادرولو په اړه څنګه استدلال وکړئ: RAND له کومه راځي، چېرته ځي، او هغه برابري چې د یوه پټ زنځیر عرضه دقیقه کوي، که څه هم هېڅوک یې نوټونه نشي جمع کولی.

RAND له کومه راځي او چېرته ځي

پټ زنځیر خپلې پیسې نشي جمع کولی، ځکه د نوټ ارزښت د هغه په ژمنه کې پټ وي. عامه برخه یوازې د حوض له پولې هر تېرېدل دي. دا پنځه ډوله دي، او په هغه زنځیر کې چې د پروګرام خزانې لري (RPL-2، chain 20) اووه ډوله:

په هغه زنځیر کې چې پیدایښت یې tokens.burn_registration_fee ټاکي، لکه د chain 20 پیدایښت، د ټوکن د ثبت 1 RAND registration_fee هم د burned له لارې له حوض وځي، خو هېڅ راجستر ثبت ته نه ننوځي: له منځه وړل کېږي، او وړاندیز کوونکی یوازې د بنډل اساسي فیس ساتي.

د حوض ترڅنګ د تاییدوونکو راجستر دی، چې اندازې په ښکاره ساتي، ځکه د اجماع وزن باید عامه وي. په راجستر کې ګرو ریښتینی RAND دی: له ګرو ایستل کېدای شي او بېرته په یوه نوټ کې ایستل کېدای شي. په chain 20 کې د پروګرام خزانې د هغه ترڅنګ دویم عامه بیلانس دی: هغه RAND چې یو invoke یې زېرمه کوي هلته د شمېرلو وړ پاتې کېږي تر هغو چې یوه ورکړه یې د نوټ په توګه حوض ته بېرته راولي.

په chain 20 کې نه د بلاک انعامونه شته او نه انفلاسیون. د زنځیر لومړی مهالوېشل شوی صادرول د بلاک راټولولو سبسایډي ده — په هر مهر شوي بلاک د نوي RAND یوه کمېدونکې اندازه، هغه راټولوونکي ته ورکول کېږي چې ثبوت یې هغه بلاک پوښي — او په chain 20 کې فعاله نه ده (ثبوتونه). chain 20 یو نوی زنځیر دی، د 2026-10-01 په 06:17 UTC ژوندی شو، له chain 19 څخه جلا شوی (fullnode v0.6.8، یو hard fork). د هغه پیدایښت 31,184.243719258 RAND صادر کړل: 26,000 د پیدایښت په 26 تاییدوونکو کې په ګرو، او 5,184.243719258 په اوو زېرمه نوټونو کې، چې د اوو عملیاتي بټوو بیلانسونه دي له chain 19 څخه راوړل شوي. هغه څه چې نورو بټوو په chain 19 کې درلودل، شاوخوا 519.9 RAND (اجازه لرونکو ترلاسه کوونکو ته د فاسیټ ضربونه، کاروونکو ته ورکړې)، نه دي راوړل شوي، ځکه یو نوټ د خپل مالک له پتې پرته بیا نشي جوړېدای؛ او نه د تاییدوونکو نه ایستل شوي 0.499 RAND انعامونه. دوه نور پیدایښت نوټونه، ټول نهه، د bridge 99 zUSD (10 او 89) لري، چې RAND نه دي او له دې پلټنې بهر دي. په chain 20 کې rand_getSupply د genesis_deposited لپاره 5,184,243,719,258 واحدونه او invariant_holds: true لولي (height 3,037، 2026-10-01). chain 19، چې هماغه ورځ د chain 18 له یوه انځور څخه په height 141,935 کې جلا شو، 31,294.644359629 RAND صادر کړل: هماغه 26,000 په ګرو او 5,294.644359629 په اوو نوټونو کې، د یوه 10 zUSD نوټ ترڅنګ. له هغه وروسته هر د فاسیټ ضرب صادر شوې شمېرې ته زیاتوي، او هر سوځول شوی د ثبت فیس ترې کموي. chain 15، چې 2026-09-26 جلا شو، په پیدایښت کې 23,000 RAND صادر کړل، 18,000 په 18 تاییدوونکو کې په ګرو او 5,000 په پنځو نوټونو کې؛ د هغه اتو وروستیو تاییدوونکو له موجودو نوټونو ګرو کړه، چې هېڅ یې صادر نه کړل.

ټوکنونه له دې پلټنې بهر دي

پورته تېرېدل د RAND دي. یو RPL ټوکن، که bridge شوی وي که اصلي، هېڅکله د RAND له پولې نه تېرېږي: د asset index 0 د RAND لپاره ساتل شوی او د ټوکن راجستر یې هېڅکله نه ورکوي، نو یو BridgeAttest، یو TokenMint یا د ثبت لومړنی ضرب تل د کومې بلې شتمنۍ نوټ زېرمه کوي، او د BridgeBurn یا TokenBurn burn_a تل یو له منځه وړي (هغه RAND چې د burn_a له لارې وسوځول شي رد کېږي). fees_paid او burned یوازې د بنډل له fee او burn_r څخه شمېرل کېږي، او د حوض دننه د ټوکن لېږد هېڅ شمېرونکی نه خوځوي، ځکه د هغه شتمني حتی عامه نه ده. په chain 20 کې یو Invoke کولی شي د burn_a له لارې ټوکن هم واخلي: د پروګرام خزانې ته (deposit)، چې عرضه یې نه بدلوي، یا له منځه وړل (burn)، یوازې د پروګرام د خپل ټوکن لپاره. د bridge د فیس نوټونه (chain 20، د هر zUSD زېرمې او سوځولو 10 bps، د خزانې یوې پتې ته) zUSD دي، هېڅکله RAND نه دي: صادر شوي او ملاتړ شوي، نو د زېرمې ملاتړ او عرضه په ناخالصه اندازه خوځېږي او د سوځولو په amount − fee کمېږي. د ټوکن خپله عرضه د راجستر عامه شمېر دی: rand_getTokenSupply total_supply بېرته ورکوي او، د bridge شوي ټوکن لپاره، د هر ملاتړ locked اندازه، چې مجموعه یې ورسره برابره ده (RPL ټوکنونه).

د پلټنې برابري

شپږ یو اړخیز شمېرونکي په واحدونو کې (1 RAND = 10⁹)، دوه چې هغه څه ثبتوي چې له منځه وړل شوي، او په chain 20 کې دوه د پروګرام خزانو لپاره:

pool_value     = genesis_deposited + faucet_minted + withdraw_deposited + program_rand_out − fees_paid − burned
register_total = Σ over the register of (stake + pending + rewards)
total_supply   = pool_value + register_total + program_rand_held
issued         = genesis_deposited + genesis_staked + faucet_minted

invariant:       total_supply == issued − slashed − registration_fees_burned

pool_value هغه څه دي چې ننوتي منفي هغه څه چې وتلي — هماغه شمېره چې د نوټونو مجموعه ده، چې هېڅوک یې نشي محاسبه کولی. د ایستلو 0.001 RAND اساسي فیس تېرېدل نه دي: له یوه راجستر کرښې د وړاندیز کوونکي کرښې ته ځي، او یوازې نوټ تېر شو. د invariant_holds غلط کېدل د اجماع تېروتنه یا زیانمن ډیټابیس دی، هېڅکله مشروع حالت نه دی. د پروګرام دوه ټرمونه په هغه زنځیر کې صفر دي چې د پروګرام خزانې نه لري، نو هلته برابري د chain 19 ده. د پیدایښت vesting برخه، چې هېڅ زنځیر نه ده لرلې، به په همدې ډول دریم عامه راجستر زیات کړي (JSON-RPC).

د 1,000 RAND د یوې ګرو کولو او یوې ایستلو له لارې تعقیب، په هغه زنځیر کې چې 2,000 یې زېرمه او 4,000 یې په ګرو کړي:

لوستل یې

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

{ "height": 1998,
  "genesis_deposited": "2000000000000", "genesis_staked": "4000000000000",
  "faucet_minted": "0", "withdraw_deposited": "999999000000",
  "fees_paid": "1000000", "burned": "1000000000000",
  "slashed": "0", "registration_fees_burned": "0",
  "pool_value": "1999998000000", "register_total": "4000002000000",
  "total_supply": "6000000000000", "invariant_holds": true }

هره اندازه د واحدونو لسیزه رشته ده، ځکه د JSON شمېره له 2⁵³ وروسته دقیق بشپړ عدد نه وي. بشپړ څیز له دې ځای څخه ډېر ساحې لري، په دوی کې د فاسیټ د هرې دورې جوړه faucet_epoch او faucet_minted_in_epoch، چې chain 20 یې د خپلې بودیجې پر وړاندې ګوري، program_rand_out او program_rand_held (له v0.6.8 راهیسې)، او څلور vesting_* شمېرونکي چې په chain 20 کې "0" لولي، ځکه د هغه پیدایښت vesting برخه نه لري (JSON-RPC). سپړونکی هماغه څیز په GET /supply کې او سرلیکي شمېرې په GET /stats کې وړاندې کوي.

څومره دقیق دی

د هر هغه څه لپاره چې زنځیر پخپله کړي، شمېرونکي دقیق دي: هر یو په هغه کوډ لاره کې زیاتېږي چې عمل پلي کوي، د عمل له خپلو عامه ساحو څخه.

دوه ثبتونه پخوا پر یوې ادعا ولاړ وو، او chain 14 دواړه په ازموینو بدلوي (audit v3، POOL-1):

• د فاسیټ Mint د نوټ پرانیستنه له ځانه سره لري. دا عمل د cm او amount تر څنګ pk، time او r هم خپروي. د منلو پړاو د (pk, no sender, amount, asset 0, time, r) ژمنه بیا محاسبه کوي، د نه سمون په صورت کې یې د the mint's commitment does not open to its published note and amount په پیغام ردوي، او time د بنډل په کړکۍ پورې محدودوي. مینټ کوونکی ټولې اوه برخې د rand-mint-2 ډومېن لاندې لاسلیکوي. له دې مخکې یو تاییدوونکي کولای شول یو مقدار خپور کړي او داسې نوټ مهر کړي چې ارزښت یې بل وي. بیه یې دا ده چې د فاسیټ د نوټ د خاوند pk عامه کېږي، لکه څنګه چې د ایستلو تادیه عامه ده؛ د rand_mint پاراميټرونه بدل شوي نه دي.
• د جینیسس alloc نوټ هم خپله پرانیستنه له ځانه سره لري. په هغه زنځیر کې چې tokens برخه لري، هر قطار { cm, envelope, amount, opening: { pk, time, r } } دی، او نوډ ژمنه بیا محاسبه کوي، په asset 0 کې، مګر دا چې پرانیستنه د یوې لېست شوې ټوکن asset په ګوته کړي، او هغه جینیسس فایل ردوي چې cm یې سمون ونه لري. یوازې د asset-0 قطارونه د genesis_deposited په حساب کې شمېرل کېږي. ناڅرګند cm یوازینۍ لار وه چې د جینیسس لیکوال پرې کولای شول د هرې شتمنۍ یو بې‌پوښښه نوټ حوض ته داخل کړي، پرته له دې چې څوک یې وڅېړلای شي. نو د جینیسس د نوټ خاوند او مقدار د فایل له خپرېدو وروسته په قصدي ډول عامه دي؛ یوازې دا چې وروسته کله او په څه کې لګول کېږي، پټ پاتې کېږي. rand-node genesis تل پرانیستنه لیکي.

په هغه زنځیر کې چې پرته له tokens برخې جوړ شوی وي، پخوانی قاعده لا هم نافذه ده: genesis_deposited د اعلان شویو amount برخو مجموعه ده چې د جینیسس فایل له مخې پرې باور کېږي. د جینیسس دواړه مقدارونه د جینیسس په هش کې شامل دي، نو هر نوډ په هره حالت کې پرې یوه خوله وي.

دا شمېرونکي په قصدي ډول د اجماع حالت نه دي، د حالت ریښه یې هش نه کوي، او rand-node verify --mode quick یې هر یو د زنځیر د بیا چلولو له لارې بیا محاسبه کوي او که زېرمه شوې انځور ورسره سمون ونه لري، نه سمون راپور کوي.