Rand Protocol
مستندات
مفاهیم اصلی

توکن‌های RPL

استاندارد توکن RPL - توکن به‌عنوان یک ورودی رجیستری در دفتر کل، شناسه دارایی، اندیس و قالب متنی rpl1 آن، مراجع ضرب (mint)، هزینه ایجاد توکن، دلیل اینکه انتقال توکن دقیقاً شبیه پرداخت RAND به نظر می‌رسد، ضرب و سوزاندن توکن، و تفاوت آن با ERC-20 و SPL.

از این صفحه برای درک اینکه توکن در این زنجیره چیست استفاده کنید، پیش از آنکه توکنی ایجاد، فهرست یا نمایه‌سازی کنید. RPL استاندارد توکن Rand است و از زنجیره 14 اضافه شده است. توکن یک دارایی بومی محافظت‌شده است: یک ورودی در رجیستری دفتر کل که موجودی‌های آن به‌صورت نوت‌های معمولی در همان درخت تعهدی نگهداری می‌شود که RAND استفاده می‌کند. توکن یک قرارداد نیست. برای ایجاد گام‌به‌گام آن، استقرار یک توکن RPL را ببینید.

دلیل این طراحی ساختاری است. یک Call فقط یک رسید می‌نویسد، پس قراردادی به سبک ERC-20 جایی برای نگهداری موجودی نداشت، و یک جدول موجودی عمومی توکن‌ها را به تنها دارایی شفاف در یک زنجیره محافظت‌شده تبدیل می‌کرد. RPL به‌جای آن، توکن را به یک شیء درجه‌یک دفتر کل تبدیل می‌کند. زنجیره 20 نسخه RPL-2 را اضافه می‌کند (v0.6.8): یک برنامه می‌تواند سلول‌های حالت عمومی و یک خزانه عمومی نگه دارد و می‌تواند مرجع مجاز ضرب (mint authority) توکنی از آنِ خودش باشد (در ادامه); موجودی‌هایی که اشخاص نگه می‌دارند همچنان نوت هستند.

توکن یک ورودی رجیستری است

TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) یک جدول واحد است که همه توکن‌ها، چه بومی و چه پلی، در آن مشترک‌اند. همان رجیستری‌ای است که پل شاخص یک دارایی را از طریق آن تعیین می‌کند. هر ورودی:

فیلدقاعده
idشناسه دارایی، ۳۲ بایت، مبتنی بر محتوا
indexu32، مقداری که کلمه asset یک نوت حمل می‌کند؛ فشرده، به ترتیب ثبت از 1 تخصیص می‌یابد. شاخص 0 همان RAND است و هرگز ثبت نمی‌شود
name۱ تا ۳۲ بایت UTF-8، فاصله مجاز است، تغییرناپذیر
symbol۱ تا ۱۲ بایت ASCII گرافیکی (0x21..=0x7e، بدون فاصله)، تغییرناپذیر
decimals۰ تا ۹، تغییرناپذیر
authorityمرجع مجاز ضرب، در ادامه
mint_nonceشمارنده ضدبازپخش یک مرجع از نوع Key
total_supplyu64، با محاسبات بررسی‌شده؛ سرریز، ضرب را رد می‌کند. از زنجیره 15 زیر 2^63 نگه داشته می‌شود (در ادامه)
registered_atارتفاع ثبت

ارقام اعشار در عدد 9 متوقف می‌شوند چون مقادیر u64 هستند: با 18 رقم اعشار، یک u64 فقط 18.4 توکن کامل را در خود جا می‌دهد، و 9 دقت خود RAND است. یک توکن پلی همیشه با 8 رقم اعشار ثبت می‌شود، فارغ از اینکه سکه‌های مبدأ آن چه دقتی دارند.

رجیستری با بخش tokens در فایل genesis روشن می‌شود، همان‌طور که bridge و aggregation با بخش‌های خودشان روشن می‌شوند. بدون آن، هر اقدام توکنی پیش از هر بررسی دیگر رد می‌شود (TokenError::Disabled). genesis زنجیره 20 این بخش را دارد و یک توکن را فهرست می‌کند، یعنی zUSD با هفت پشتوانه‌اش، که از زنجیره 14 در هر برش منتقل شده است؛ هر توکن دیگر روی زنجیره با تراکنش وارد می‌شود. (genesis زنجیره 14 هیچ توکنی فهرست نمی‌کرد.) با روشن بودن این دروازه، یک tokens_root (ریشه merkle برگ‌های blake3("rand-token-leaf-1", bincode(TokenInfo)) به ترتیب شاخص) در ریشه حالت ادغام می‌شود. دامنه این ریشه rand-state-4 است در زنجیره‌ای که چیز دیگری پس از آن روشن نشده باشد؛ ریشه زنجیره 20 حالت faucet و صف bond، قیمت‌های جاری gas و ریشه حالت برنامه را نیز حمل می‌کند، هش‌هایی تحت rand-state-8، و یک بار دیگر با مجموعه validatorهای پذیرفته‌شده پوشانده می‌شود (اجماع).

زنجیره‌ای که بخش tokens دارد همچنین ایجاب می‌کند که هر نوت alloc در genesis بازگشایی خود (pk، time، r) را حمل کند، و گره تعهد را دوباره محاسبه می‌کند و فایلی را که مطابقت نداشته باشد رد می‌کند. تعهد روی دارایی 0 است، مگر آنکه بازگشایی شاخص توکنی را نام ببرد که همان genesis فهرست کرده است — زنجیره 20 دو نوت چنین دارد، 10 و 89 zUSD در شاخص 1 — و به ازای هر توکن فهرست‌شده، نوت‌های genesis باید جمعی برابر با مقداری داشته باشند که پشتوانه‌های آن با locked شروع می‌کنند. وقتی یک نوت کلمه asset ای دارد که می‌تواند یک توکن را نام ببرد، یک تعهد genesis بازنشده تنها راهی می‌بود که نوتی بدون پشتوانه از هر دارایی را بدون بررسی وارد استخر کند.

شناسه دارایی، شاخص و rpl1…

یک توکن دو نام دارد و RPC هر دو را می‌دهد.

  • شناسه دارایی ۳۲ بایت است و مانند شناسه برنامه مبتنی بر محتواست. شناسه یک توکن بومی blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt)) است، که در آن salt ۳۲ بایتی است که سازنده انتخاب می‌کند و initial کل ضرب اولیه است، در صورت وجود. شناسه یک توکن پلی blake3("rand-rpl-asset", bincode(name, symbol, 8, salt)) است. ثبت شناسه‌ای که از قبل وجود دارد رد می‌شود (TokenError::AlreadyRegistered).
  • شاخص چیزی است که یک نوت در واقع حمل می‌کند، چون شناسه ۳۲ بایتی در یک کلمه جا نمی‌شود. این یک میان‌بر است که فقط در همین زنجیره معنا دارد.
  • شکل متنی rpl1… از نوع bech32m (BIP-350) است با بخش خوانا برای انسان rpl روی ۳۲ بایت شناسه: ۵۲ نویسه داده و یک جمع‌کنترل ۶ نویسه‌ای، در مجموع ۶۲ نویسه. این شکل در هر جا که توکنی نام برده شود کنار شناسه ۶۴ رقمی هگزادسیمال نشان داده می‌شود و در هر جا که توکنی جست‌وجو شود پذیرفته می‌شود؛ هگزادسیمال همچنان پذیرفته است. تجزیه سخت‌گیرانه است: جمع‌کنترل نادرست، پیشوند اشتباه، بار داده‌ای که دقیقاً ۳۲ بایت نباشد، یا حروف ترکیبی (بزرگ و کوچک) رد می‌شود، بنابراین یک غلط تایپی نمی‌تواند به توکن دیگری تعیین شود.

نمادها یکتا نیستند. مانند ERC-20 و SPL، هویت یک توکن شناسه دارایی آن است، نه نام یا نماد آن.

مقدار قدیمی به ازای هر (chain, token) که rand_bridgeAssetId محاسبه می‌کند و rand_getAssets برای هر ردیف پشتوانه چاپ می‌کند، شناسه‌ای محدودتر برای قالب سیمی پل است، نه شناسه خود توکن.

مراجع مجاز ضرب

authorityچه کسی می‌تواند واحد صادر کندیادداشت‌ها
Noneهیچ‌کس، پس از ثبتعرضه ثابت: ضرب اولیه الزامی است و تمام آن چیزی است که همیشه وجود خواهد داشت
Key(PublicKey)دارنده یک کلید Dilithium2بعداً با امضا دوباره ضرب می‌کند؛ می‌تواند مرجع را به کلید دیگری واگذار یا از آن صرف‌نظر کند
Bridge { backings }فقط قفل و آزادسازی پلهرگز ضرب مستقیم نیست؛ فقط از طریق اقدامات حاکمیتی پل وجود دارد
Program(ProgramId)فقط Invokeهای آن برنامه (RPL-2)در زنجیره‌ای با بخش program_state (زنجیره 20): بدون ضرب اولیه ثبت می‌شود، پس عرضه آن از صفر شروع می‌شود، و فقط با گذارهایی ضرب یا سوزانده می‌شود که اثبات برنامه تأییدشان کند (rand token create --program <id>). در زنجیره‌ای بدون این بخش، هنگام ثبت رد می‌شود

یک RegisterToken که Bridge را نام ببرد رد می‌شود (TokenError::AuthorityNotAllowed)، همچنین است اگر Program را با ضرب اولیه یا در زنجیره‌ای بدون program_state نام ببرد. یک مرجع Key دقیقاً یک کلید عمومی Dilithium2 است: کلیدی با هر طول بایت دیگر رد می‌شود (TokenError::BadAuthorityKey)، و کلید ML-KEM گیرنده در یک ضرب نیز به همین ترتیب به طول خود مقید است. هر دو یا حالت اجماع‌اند یا فضای بلوکی که با کارمزد ثابت خریداری می‌شود، پس هیچ‌کدام نباید به‌طور دلخواه بزرگ باشند.

ایجاد یک توکن

ایجاد بدون نیاز به مجوز است. Action::RegisterToken { name, symbol, decimals, authority, initial, salt, index } روی یک بسته کارمزد معمولی RAND سوار می‌شود و BUNDLE_BASE به‌علاوه registration_fee رجیستری را می‌پردازد. کارمزد ثبت یک پارامتر genesis است که بین 1 RAND و 10,000 RAND محدود شده است، تا یک توکن هرزنامه همیشه هزینه‌ای داشته باشد. در زنجیره 20 این مقدار 1 RAND است، پس یک ثبت 1.001 RAND هزینه دارد، و زنجیره 20 آن را می‌سوزاند، همان‌طور که هر زنجیره از 15 به بعد چنین کرده است: پیشنهاددهنده فقط پایه بسته را نگه می‌دارد (در ادامه).

index شاخص رجیستری‌ای را نام می‌برد که سازنده نوت اولیه را برای آن مهروموم کرده است. اگر ثبت دیگری ابتدا آن شاخص را بگیرد، تراکنش رد می‌شود (TokenError::IndexMismatch) تا نوت بی‌صاحب نماند؛ سازنده در شاخص بعدی دوباره اثبات می‌کند.

نوت ضرب‌شده را زنجیره محاسبه می‌کند، نه ارسال‌کننده انتخاب: note_commitment(recipient.pk, MINT_FROM, amount, index, time, r). مقدار و pk گیرنده روی سیم عمومی هستند، پس گیرنده می‌تواند نوت را از خود فیلدهای تراکنش بازسازی کند، حتی اگر پاکت مهروموم‌شده بی‌معنا باشد. واریز پل نیز همین دفاع را دارد.

چرا شناسه کل ضرب اولیه را مقید می‌کند

یک RegisterToken امضا نمی‌شود. مقیدسازی تراکنش جلوی تغییر یک نسخه اثبات‌شده را می‌گیرد، اما درباره آنچه یک نسخه تازه می‌تواند نام ببرد چیزی نمی‌گوید. اگر شناسه فقط مقدار اولیه را پوشش می‌داد، ناظری که ثبتی در انتظار را می‌دید می‌توانست نسخه‌ای با گیرنده‌ای دیگر ارسال کند، آن را با همان شناسه ثبت کند، و با تعهد زودتر، کل عرضه یک توکن با عرضه ثابت را بگیرد. از آنجا که شناسه کل ضرب اولیه را پوشش می‌دهد (مقدار، گیرنده، r، time و پاکت)، یک نسخه تغییر مسیر داده‌شده به یک شناسه دارایی متفاوت هش می‌شود: توکنی دیگر با همان نماد، که نمادِ غیریکتا از پیش اجازه‌اش را می‌دهد. نسخه اصلی همچنان با هزینه یک اثبات دوباره در شاخص بعدی می‌نشیند.

انتقال‌ها همان بسته RAND هستند

از زنجیره 14 هر تراکنشی که ارزش جابه‌جا می‌کند دقیقاً یک بسته حمل می‌کند، همان شکل ثابت ۴ ورودی و ۴ خروجی با دارایی پنهان (تراکنش‌ها و اقدامات). اسلات‌های 0–1 یک دارایی خصوصی را حمل می‌کنند، RAND یا هر توکن RPL، و مدار هرگز نمی‌فهمد کدام. اسلات‌های 2–3 همیشه RAND حمل می‌کنند. انتقال هر دارایی Action::None است، همان اقدامی که یک پرداخت ساده RAND استفاده می‌کند. هیچ اقدام انتقال توکن و هیچ فیلد عمومی‌ای که توکن را نام ببرد وجود ندارد.

آنچه ناظر در انتقال یک توکن می‌بیند دقیقاً همان است که یک پرداخت RAND منتشر می‌کند: یک لنگر، چهار نالیفایر، چهار تعهد، کارمزد fee به RAND، burn_a = burn_r = burn_asset = 0، یک time، چهار متن رمزشدهٔ پاکت و اثبات بسته. از زنجیرهٔ ۱۷ به بعد (احراز مجوز تفکیک‌شده)، هر بسته یک auth_commit و یک اثبات احراز مجوز دوم و کوچک‌تر هم دارد که باز برای همهٔ دارایی‌ها یکسان است. در زنجیرهٔ ۲۰ هر پاکت دقیقاً 1,860 بایت است و جا برای یک یادداشت رمزشده (rand send --memo) دارد، چه فرستاده شود و چه نه. ناظر فرستنده، گیرنده، مقدار، دارایی منتقل‌شده، اسلات‌های ساختگی و باقی‌مانده را نمی‌بیند.

کیف پول حداکثر دو نوت از توکن را در اسلات‌های ۰ و ۱ و حداکثر دو نوت RAND را برای کارمزد در اسلات‌های ۲ و ۳ خرج می‌کند. کارمزد همیشه به RAND است، بنابراین دارندهٔ توکنی که RAND ندارد پیش از اثبات‌سازی رد می‌شود. هزینه با هزینهٔ یک پرداخت RAND یکسان است (کارمزدها). در زنجیرهٔ ۲۰ این یعنی دو اثبات STARK که روی دستگاه فرستنده ساخته می‌شوند: احراز مجوز خرج (سطح ۱۰، حدود 7 ثانیه، حدود 1.37 MB) و بسته (سطح ۱۴، حدود 100 ثانیه، حدود 1.5 MB)، که روی هم حدود 2.85 MB روی شبکه می‌شود. هر کدام زیر سقف 4 MiB زنجیره برای یک اثبات است. پیش از زنجیرهٔ ۱۷ یک انتقال فقط اثبات بسته را داشت، حدود 1.42 MB آنگونه که آن زمان اندازه‌گیری شد.

ضرب توکن و مرجع مجاز

TokenMint { asset, amount, recipient, r, time, envelope, nonce, signature } از توکنی که مرجع آن Key است توکن بیشتری ضرب می‌کند. SetAuthority { asset, new, nonce, signature } مرجع را به کلید دیگری می‌سپارد، یا اگر new نباشد آن را رها می‌کند؛ پس از رهاسازی هیچ کلیدی دیگر هرگز نمی‌تواند آن توکن را ضرب کند. هر یک از این دو عمل روی توکنی که مرجع آن Key نیست رد می‌شود (TokenError::NotKeyAuthority).

مرجع مجاز blake3("rand-rpl-mint-1" | "rand-rpl-authority-1", chain_id ‖ asset_id ‖ nonce ‖ body) را امضا می‌کند. nonce باید برابر mint_nonce توکن باشد که پس از آن یک واحد افزایش می‌یابد، پس یک ضرب امضاشده را نمی‌توان روی این زنجیره بازپخش کرد یا به زنجیرهٔ دیگری برد. body در ضرب شامل چکیدهٔ پاکت است: تعهد به‌تنهایی آن را پوشش نمی‌دهد، و بدون چکیده، شخص ثالث می‌توانست یک ضرب منتشرشده را با پاکتی بی‌معنی دوباره بسته‌بندی کند و nonce را مصرف کند.

هر دو عمل سوار بر یک بستهٔ کارمزد RAND می‌شوند که BUNDLE_BASE می‌پردازد. کیف پولی که کارمزد را می‌پردازد و کلیدی که ضرب را مجاز می‌کند جدا هستند و می‌توانند متعلق به افراد مختلف باشند.

سوزاندن

Action::TokenBurn { asset, amount } سوار بر همان بستهٔ واحد می‌شود: burn_asset بسته باید برابر asset باشد، burn_a باید برابر amount باشد و burn_r برابر 0 است. توکن از طریق اسلات‌های دارایی از استخر خارج می‌شود و کارمزد RAND از طریق اسلات‌های ۲ و ۳ همان اثبات. total_supply دقیقاً به اندازهٔ amount کم می‌شود. توکنی با مرجع Bridge اینجا رد می‌شود (TokenError::BridgedToken)؛ چنین توکنی از طریق سوزاندن پل خارج می‌شود.

کارمزدها

هر عمل RPL به RAND پرداخت می‌شود.

عملکف کارمزددر زنجیرهٔ ۲۰
انتقال هر دارایی (Action::None)BUNDLE_BASE0.001 RAND
RegisterTokenBUNDLE_BASE + registration_fee1.001 RAND که 1 RAND آن سوزانده می‌شود
TokenMintBUNDLE_BASE0.001 RAND
SetAuthorityBUNDLE_BASE0.001 RAND
TokenBurnBUNDLE_BASE0.001 RAND

جنسیس زنجیرهٔ ۲۰ بخشی به نام gas دارد و آن فقط قیمت فراخوانی و اجرای برنامه‌ها را تعیین می‌کند. این کف‌ها ثابت‌اند: هیچ عمل RPL بر اساس گس یا بایت پرداخت نمی‌کند.

چه چیزی عمومی است و چه چیزی پنهان

عمومیپنهان
ثبتنام، نماد، تعداد ارقام اعشار، مرجع مجاز، شناسهٔ دارایی، مقدار و گیرندهٔ ضرب اولیههیچ؛ به همین دلیل عرضهٔ توکن از همان بلوک نخست قابل حسابرسی است
ضرب بعدیمقدار، آدرس محافظت‌شدهٔ گیرنده، فیلدهای نوت جدیداینکه چه کسی کارمزد RAND را پرداخته است
انتقالهیچ چیزی که نشان دهد توکنی جابه‌جا شده استفرستنده، گیرنده، مقدار، دارایی
سوزاندندارایی و مقداراینکه چه کسی نوت‌های سوزانده‌شده را در اختیار داشته است
تغییر مرجع مجازکلید جدید، یا اینکه مرجع رها شده است—

بنابراین total_supply همیشه قابل حسابرسی است: آنچه ثبت و هر ضرب افزوده‌اند منهای هر سوزاندن. انتقال میان دارندگان هیچ چیز را فاش نمی‌کند، از جمله اینکه به‌جای RAND یک توکن دست‌به‌دست شده است.

افشا مانند RAND کار می‌کند. متن آشکار نوت دارایی را در خود دارد، پس یک کلید هر تراکنش (rand tx-key <hash>) یا یک کلید مشاهده، نوت توکن را دقیقاً همانطور که نوت RAND را باز می‌کند باز می‌کند، و rand_checkTransaction و rand_getViewingNotes در نوتی که افشا می‌کنند asset را برمی‌گردانند. با داشتن چنین کلیدی، randscan شاخص را در برابر رجیستری حل می‌کند و انتقال را به‌صورت توکن نام‌دار نشان می‌دهد؛ صفحهٔ عمومی همان تراکنش هیچ‌یک از اینها را نشان نمی‌دهد.

توکن‌های پل‌شده

توکنی با مرجع Bridge همچنان یک توکن RPL است: همان ورودی رجیستری، همان انتقال پنهان، همان سازوکار سوزاندن. عرضهٔ آن فقط از طریق قفل روی یک زنجیرهٔ مبدأ (BridgeAttest) یا یک آزادسازی (BridgeBurn) جابه‌جا می‌شود. یک توکن پل‌شده می‌تواند چندین پشتوانه داشته باشد، هر کدام یک جفت (chain, token) با ارقام اعشار مبدأ، مقدار قفل‌شده و سقف ضرب خودش، و total_supply همیشه برابر مجموع آن چیزی است که پشتوانه‌هایش قفل کرده‌اند. ثبت یک توکن پل‌شده و افزودن یک پشتوانه فقط تحت حدنصاب نگهبانان پساکوانتومی پل ممکن است.

در زنجیرهٔ ۲۰ نخستین توکن رجیستری zUSD («Shielded USD») است، با شاخص 1 و 8 رقم اعشار، که در فایل جنسیس با هفت پشتوانه فهرست شده است (USDT و USDC روی Ethereum، Binance Smart Chain و Solana، و USDT روی Tron). این توکن همان شناسهٔ دارایی‌ای را نگه داشته که در زنجیرهٔ ۱۴ داشت، جایی که با تراکنش در ارتفاع 256 ثبت شد: زنجیره‌های ۱۵ تا ۲۰ هر کدام آن را در جنسیس با همان نام، نماد و salt فهرست کرده‌اند. زنجیرهٔ ۲۰ را با 99 zUSD در دو نوت جنسیس (10 و 89) آغاز کرد، با پشتوانهٔ 22 USDT قفل‌شده روی Ethereum، 22 روی Binance Smart Chain، 30 روی Tron و 25 روی Solana، که از وضعیت پل زنجیرهٔ ۱۹ منتقل شده بود. زنجیرهٔ ۱۹ با 10 zUSD آغاز شد که پشتوانهٔ آن 10 USDT روی Solana بود؛ زنجیرهٔ ۱۸ با 9 USDT قفل‌شده روی Tron و 1 روی Solana. عرضهٔ کل آن برابر چیزی است که پشتوانه‌هایش قفل‌شده نگه می‌دارند و با هر واریز و بازخرید جابه‌جا می‌شود. شناسهٔ آن rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx است. پل پشتوانه‌ها، واحدهای آزادسازی، سقف‌های ضرب، توقف و هم‌امضایی را توضیح می‌دهد.

zUSD یک سبد است، نه هفت ادعای جداگانه. پشتوانه‌های آن به ارزش اسمی در هم ادغام شده‌اند، پس دارنده ریسک همهٔ پشتوانه‌های فهرست‌شده را می‌پذیرد، نه فقط ریسک سکه‌ای که واریز کرده است: پشتوانه‌ای که پیوند ارزی خود را از دست داده می‌تواند به ارزش اسمی واریز شود و zUSD به سمت یک پشتوانهٔ سالم سوزانده شود، تا وقتی که پشتوانه‌های سالم تخلیه شوند. آنچه زیان را محدود می‌کند پنجرهٔ ضرب غلتان است (در زنجیرهٔ ۲۰، 4,000 zUSD در مجموع همهٔ پشتوانه‌ها در هر 24 ساعت، در کنار 100,000 برای هر پشتوانه) و نگهداری واقعاً قفل‌شده. پنجره نرخ را محدود می‌کند و زمان توقف ضرب‌ها را فراهم می‌آورد. مجموع را سقف نمی‌گذارد. یک پشتوانه فقط تحت حدنصاب نگهبانان پساکوانتومی فهرست می‌شود، و نه در زمانی که ضرب‌ها متوقف است.

کارمزدهای پل، به zUSD (زنجیرهٔ ۲۰). جنسیس زنجیرهٔ ۲۰ مقدار bridge.fees را تعیین می‌کند: 10 bps برای واریز و 10 bps برای سوزاندن، هر کدام به سمت پایین تا یک واحد آزادسازی کامل پشتوانه گرد می‌شود (100 واحد پایه برای USDT با 6 رقم اعشار)، که به‌صورت یک نوت zUSD به آدرس خزانه‌ای که جنسیس نام می‌برد پرداخت می‌شود (v0.6.8، fullnode docs/bridge.md §25). یک واریز به مقدار g دو نوت اضافه می‌کند: g − fee برای واریزکننده و fee برای خزانه؛ واریز 1 USDT برای واریزکننده 0.999 zUSD می‌شود. یک سوزاندن به مقدار amount، fee را به‌صورت نوت خزانه نگه می‌دارد و amount − fee را روی زنجیرهٔ مبدأ آزاد می‌کند؛ نگهبانان همین مقدار آزادسازی را امضا می‌کنند و rand_getBridgeBurn مقادیر amount، release_amount و fee را ارائه می‌دهد. نوت کارمزد صادر و پشتوانه‌دار است، پس total_supply همچنان برابر مجموع locked پشتوانه‌هاست: یک واریز هر دو را به اندازهٔ g جابه‌جا می‌کند و یک سوزاندن هر دو را به اندازهٔ amount − fee کاهش می‌دهد. نوت کارمزد پاکت ندارد. تک‌تک اجزای آن عمومی‌اند (مقدار از تراکنش و نرخ جنسیس، دارایی و time، یک عامل پوشاننده که از چکیدهٔ گواهی یا شناسهٔ تراکنش سوزاندن مشتق می‌شود، و مالک از جنسیس)، پس کیف پول خزانه آن را از فیلدهای عمومی بازسازی می‌کند (نوت‌ها). BRIDGE_BURN_FEE، یعنی 0.01 RAND که یک سوزاندن به پیشنهاددهنده می‌پردازد، بدون تغییر است. زنجیره‌های ۱۴ تا ۱۹ روی Rand کارمزد پل نداشتند.

رجیستری از زنجیرهٔ ۱۵ به بعد

از زنجیرهٔ ۱۵ جنسیس سه قاعدهٔ رجیستری را روشن می‌کند که زنجیرهٔ ۱۴ نداشت، و جنسیس زنجیرهٔ ۲۰ همان سه مقدار را تعیین می‌کند. هر کدام در هش جنسیس و ریشهٔ توکن ثبت می‌شود.

فیلد genesischain 20اثر
tokens.max_tokens4096رجیستری هرگز بیش از این نگه نمی‌دارد؛ در سقف، RegisterToken و RegisterBridgedToken با RegistryFull رد می‌شوند. ListBacking توکنی اضافه نمی‌کند و تحت تأثیر قرار نمی‌گیرد
tokens.burn_registration_feetrueregistration_fee یک ثبت به‌جای پرداخت به پیشنهاددهنده سوزانده می‌شود؛ پیشنهاددهنده fee − registration_fee را نگه می‌دارد. rand_getSupply آن را در burned و در registration_fees_burned می‌شمارد (Supply)
tokens.bound_note_valuetrueیک TokenMint، یک مینت اولیه یا یک واریز پل به مقدار 2^63 یا بیشتر با AmountTooLarge رد می‌شود، و مقداری که total_supply یک توکن را به 2^63 یا فراتر از آن برساند با SupplyTooLarge رد می‌شود

کران مقدار note وجود دارد چون مدار bundle هر مقدار را تا 63 بیت بررسی بازه می‌کند: یک note با ارزش 2^63 یا بیشتر قابل commit شدن است اما هرگز خرج نمی‌شود، در حالی که همچنان در عرضه‌ی توکن شمرده می‌شود. هر node همچنین چنین مقداری را هنگام پذیرش در هر chain رد می‌کند، فارغ از آنچه genesis آن می‌گوید.

RPC و CLI

متدپارامترهانتیجه
rand_getTokens[from_index, limit]، اختیاری، پیش‌فرض 0 و 1000، محدود به 1000{ enabled, registration_fee, next_index, max_tokens, burn_registration_fee, bound_note_value, tokens }، به ترتیب صعودی اندیس، خوانده‌شده به‌صورت بازه‌ای از from_index
rand_getToken[token]: یک اندیس، یک شناسه‌ی 64 رقمی هگز یا rpl1…ردیف یک توکن، یا null؛ شناسه‌ی بدشکل -32602 است
rand_getTokenSupply[token]، با همان قالب‌ها{ total_supply, backings }؛ backings برای توکن بومی خالی است

هر مقدار در این نتایج (total_supply، registration_fee، locked یک پشتوانه، mint_cap_per_day و minted_today) یک رشته‌ی اعشاری است، زیرا یک عدد JSON بیش از 2⁵³ دقیق نیست. index، next_index، mint_day و max_tokens اعداد صحیح ساده‌اند (max_tokens در chain بدون سقف null است)؛ burn_registration_fee و bound_note_value بولی‌اند. authority یک ردیف به یکی از این شکل‌هاست: {"kind":"none"}، {"kind":"key","key","address"}، {"kind":"bridge","backings":[…]} یا {"kind":"program","program"}. جزئیات کامل در JSON-RPC آمده است.

حریم خصوصی. هزینه‌ی rand_getTokens برای هر توکنی که فراخواننده در نظر دارد یکسان است. rand_getToken و rand_getTokenSupply به node می‌گویند فراخواننده به کدام توکن اهمیت می‌دهد: برای یک explorer مناسب است، اما برای کیف پولی که در آستانه‌ی ارسال است نادرست. بنابراین کیف پول هر --asset را از فهرست کامل resolve می‌کند و یک اندیس عددی هرگز به node نمی‌رسد.

دستورکاری که می‌کند
rand token createثبت یک توکن در اندیس بعدیِ رجیستری، با عرضه‌ی ثابت یا با مجوز Key
rand token mintمینت بیشتر از یک توکن دارای مجوز Key، با امضای کلید اختیار آن
rand token set-authorityواگذاری اختیار به کلید دیگر (--new-key) یا چشم‌پوشی از آن (--renounce)
rand token burn <ASSET> <AMOUNT>سوزاندن واحدهایی که این کیف پول نگه می‌دارد
rand token info <ASSET>ردیف کامل یک توکن
rand token listیک صفحه از رجیستری
rand send <TO> <AMOUNT> --asset <INDEX|rpl1…|hex>ارسال یک توکن در یک bundle؛ بدون --asset، RAND ارسال می‌کند. اثر انگشت گیرنده و مقدار را چاپ می‌کند و پیش از اثبات می‌پرسد send? [y/N] (--yes پرسش را رد می‌کند)
rand asset-balance [INDEX]آنچه این کیف پول از یک دارایی نگه می‌دارد، یا یک ردیف برای هر دارایی
rand token register-bridged, rand token list-backingدو اقدام فهرست‌سازی پل؛ هرکدام به یک فایل حدنصاب نگهبانان PQ نیاز دارد

از v0.5.10، مقدارهای rand send --asset، rand token mint و rand token burn بر حسب واحدهای نمایشی توکن هستند و با decimals خودِ ردیف رجیستری آن خوانده می‌شوند: 1.5 از یک توکن با 6 رقم اعشار برابر 1,500,000 از کوچک‌ترین واحد آن است، و ارقام اعشاری بیشتر از آنچه توکن دارد رد می‌شود. تأییدیه‌ی send هر دو را چاپ می‌کند (1.500000 USDX (1500000 units)). --fixed-supply و --initial در rand token create همچنان کوچک‌ترین واحدهای کامل را می‌گیرند، همان‌طور که rand bridge-burn می‌گیرد، و rand asset-balance کوچک‌ترین واحدها را چاپ می‌کند. روی chain، مقدار همیشه عدد صحیح کوچک‌ترین واحد است. پرچم‌ها و پیش‌فرض‌ها در Command line آمده است.

تفاوت‌ها با ERC-20 و SPL

ERC-20 / SPLRPL
موجودی‌هایک نگاشت یا حساب عمومیnoteهای shielded؛ فقط دارنده‌ی کلید می‌تواند آن‌ها را ببیند
رویدادهای انتقالعمومی، با فرستنده، گیرنده و مقدارندارد؛ یک انتقال هیچ چیز متمایزکننده‌ای منتشر نمی‌کند
کد به‌ازای هر توکنممکن: مالیات، rebase، hook، فریزندارد؛ هر توکن از همان قواعد ثابت پیروی می‌کند
نگهداری توسط یک برنامهبلهروی chain 20 (RPL-2): خزانه‌ی عمومی یک برنامه، که با فیلدهای burn در یک invoke پر می‌شود و به‌صورت noteهای محاسبه‌شده توسط chain پرداخت می‌شود
مقدارهاتا 256 بیت (ERC-20)، 64 بیت (SPL)u64، حداکثر 9 رقم اعشار
دریافتERC-20 به هیچ راه‌اندازی نیاز ندارد؛ SPL به یک associated token account نیاز داردبدون راه‌اندازی؛ یک آدرس shielded هر چیزی را دریافت می‌کند
هزینه‌ی یک انتقالاجرای ساده‌ی EVM یا SVMاثبات توسط فرستنده: bundle مشترک دارایی پنهان، و از chain 17 یک اثبات مجوز کوچک در کنار آن
تأییدیه‌ها (approvals)approve / transferFromهنوز نه
فرادادهدر برخی پیاده‌سازی‌ها قابل تغییرروی chain و تغییرناپذیر
فریز، فهرست سیاهروی برخی توکن‌ها ممکنعمداً خارج از دامنه

محدودیت‌های شناخته‌شده

  • بدون allowance. approve و transferFrom در مشخصات RPL به‌صورت حساب‌های allowance اختصاص‌یافته طراحی شده‌اند و ساخته نشده‌اند.
  • دارایی‌های یک برنامه عمومی است. روی chain 20 یک برنامه می‌تواند توکن‌ها را در خزانه‌ی خود نگه دارد و توکن خودش را مینت کند (RPL-2)، اما موجودی خزانه عمومی است، مانند عرضه‌ی یک توکن؛ فقط noteها خصوصی‌اند. chainهای پیش از 20 هیچ وضعیت برنامه‌ای نداشتند.
  • کارمزدها فقط RAND است. یک توکن نمی‌تواند کارمزد خودش را بپردازد؛ کیف پولی که فقط توکن دارد نمی‌تواند جابه‌جایی کند.
  • مقدارهای u64 و حداکثر 9 رقم اعشار. یک کوین مبدأ با 18 رقم اعشار با دقت پایین‌تر نمایش داده می‌شود؛ پل این را با 8 رقم اعشار و یک واحد آزادسازی به‌ازای هر پشتوانه حل می‌کند.
  • هر انتقال اثبات می‌شود. حدود 100 s و چندین GB حافظه روی دستگاه فرستنده؛ برای یک توکن مسیر ارزان‌تری از RAND وجود ندارد.
  • بدون فریز، فهرست سیاه یا توقف روی یک توکن بومی، به‌موجب تصمیم طراحی. توقف مینت پل فقط برای مینت‌های پل‌شده اعمال می‌شود.
  • جست‌وجوهای مختص هر توکن، علاقه را فاش می‌کنند. rand_getToken، rand_getTokenSupply و /tokens/:id در explorer به سرور می‌گویند درباره‌ی کدام توکن پرسیده شده است.

آخرین بار با کامیت c0878c3f از fullnode (زنجیرهٔ 21) در تاریخ 2026-10-12، و fullnode `docs/tokens.md`, `docs/cli.md`, `docs/rpc.md`, `docs/superpowers/specs/2026-09-19-rpl-token-standard-design.md`, and the live registry at `randscan.org/api/v1/tokens` on 2026-09-20; updated for chain 15 against fullnode `8abf85e` (v0.5.9) `docs/tokens.md` §§14–16 and `deploy/genesis-chain15.json`; updated for chain 18 on 2026-09-30 against fullnode `90e7716` (the fleet runs v0.6.7 `86941a1`) `docs/tokens.md`, `docs/cli.md`, `docs/shielded.md` §2, `docs/bridge.md` §13.1, `crates/randprotocol-core/src/gas.rs` and `deploy/genesis-chain18.json`; updated for chain 20 on 2026-10-01 against fullnode v0.6.8 `c9c9bd3c` `docs/bridge.md` §25, `docs/program-state.md`, `crates/randprotocol-core/src/ledger/tokens.rs`, `crates/randprotocol-client/src/wallet.rs` (`rebuilt_notes_with`), the committed `deploy/genesis-chain20.json` and `rand_getLimits` on chain 20 بررسی شد. هرجا کد و این صفحه با هم اختلاف دارند، حق با کد است؛ به ما اطلاع دهید.