Токены RPL

Эта страница поможет понять, что такое токен в этой цепочке, прежде чем вы создадите, опубликуете или проиндексируете его. RPL — стандарт токенов Rand, появившийся в цепочке 14. Токен — это экранированный нативный актив: одна запись в реестре леджера, а балансы хранятся как обычные ноты в том же дереве обязательств, которое использует RAND. Контрактом он не является. Пошаговое создание токена описано в разделе Deploy an RPL token.

Причина структурная. Call записывает только квитанцию, поэтому контракту в стиле ERC-20 негде было хранить баланс, а публичная таблица балансов сделала бы токены единственным прозрачным активом в экранированной цепочке. RPL вместо этого делает токен полноправным объектом леджера. Цепочка 20 добавила RPL-2 (v0.6.8): программа может вести публичные ячейки состояния и публичное хранилище и может быть эмиссионным органом собственного токена (ниже); балансы, которыми владеют люди, по-прежнему являются нотами. Цепочка 21 (fullnode v0.8.0, работает с 2026-10-12) добавляет ещё два публичных держателя токенов помимо хранилищ: RPL-3 perps — движок бессрочных фьючерсов, единственный рынок которого, BTC-PERP, обеспечен в zUSD, и мультиподписные аккаунты — аккаунты M-of-N Dilithium2 с публичными балансами по каждому активу (Transactions).

Токен — это запись в реестре

TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) — единая таблица для всех токенов, нативных и мостовых. Это тот же реестр, через который мост определяет индекс актива. Каждая запись:

Десятичные знаки ограничены 9, потому что суммы имеют тип u64: при 18 десятичных знаках u64 вмещает лишь 18,4 целых токена, а 9 — собственная точность RAND. Мостовой токен всегда регистрируется с 8 десятичными знаками, какими бы ни были десятичные знаки его исходных монет.

Реестр включается секцией tokens в файле генезиса, как bridge и aggregation — своими секциями. Без неё любое действие с токеном отклоняется до всех остальных проверок (TokenError::Disabled). В генезисе цепочки 21 эта секция есть, и в ней указан один токен, zUSD, с его семью обеспечениями; он переносится из цепочки 14 через каждый переход. Любой другой токен в цепочке появляется транзакцией и ни один не переносится через переход: одиннадцать токенов, зарегистрированных в цепочке 20 после её генезиса (DUR от durian.market и его доли пула ликвидности, токены примеров программ, RUSD), были отброшены при переходе на цепочку 21 вместе со своими нотами, поскольку ни один не был обеспечен мостом. (В генезисе цепочки 14 токенов не было.) При включённом шлюзе tokens_root (корень Меркла листьев blake3("rand-token-leaf-1", bincode(TokenInfo)) в порядке индексов) входит в корень состояния. Домен этого корня — rand-state-4 в цепочке, где ничего более позднего не включено; корень цепочки 20 включал также состояние крана и очереди бондов, действующие цены газа и корень состояния программ, хешируемые в домене rand-state-8, и был ещё раз обёрнут множеством допущенных валидаторов; в корень цепочки 21 добавлены состояние perps (rand-state-9) и реестр мультиподписей (rand-state-multisig-1) (Consensus).

Цепочка с секцией tokens также требует, чтобы каждая нота alloc в генезисе несла своё раскрытие (pk, time, r); узел пересчитывает обязательство и отклоняет файл, в котором оно не совпадает. Обязательство относится к активу 0, если только раскрытие не указывает индекс токена, перечисленного в том же генезисе — в цепочке 21 таких нот три: 10, 89.002999 и 0.999 zUSD с индексом 1 (в цепочке 20 их было две: 10 и 89) — а для каждого перечисленного токена сумма генезисных нот должна равняться тому, с чем стартуют его обеспечения в locked. Раз у ноты есть слово asset, способное указывать на токен, нераскрытое генезисное обязательство было бы единственным способом без проверки внести в пул необеспеченную ноту любого актива.

Идентификатор актива, индекс и rpl1…

У токена два имени, и RPC выдаёт оба.

• Идентификатор актива — 32 байта, адресуется по содержимому, как идентификатор программы. Идентификатор нативного токена — blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt)), где salt — 32 байта, выбираемые создателем, а initial — весь начальный выпуск, если он есть. Идентификатор мостового токена — blake3("rand-rpl-asset", bincode(name, symbol, 8, salt)). Регистрация уже существующего идентификатора отклоняется (TokenError::AlreadyRegistered).
• Индекс — то, что нота в действительности несёт, потому что 32-байтный идентификатор не помещается в одно слово. Это сокращение, имеющее смысл только в этой цепочке.
• Текстовая форма rpl1… — это bech32m (BIP-350) с человекочитаемой частью rpl поверх 32 байт идентификатора: 52 символа данных и 6 символов контрольной суммы, всего 62 символа. Она показывается рядом с 64-символьным hex-идентификатором везде, где назван токен, и принимается везде, где токен ищут; hex по-прежнему принимается. Разбор строгий: неверная контрольная сумма, неверный префикс, полезная нагрузка не ровно в 32 байта или смешанный регистр отклоняются, так что опечатка не может привести к другому токену.

Символы не уникальны. Как и в ERC-20 и SPL, идентичность токена — его идентификатор актива, а не название и не тикер.

Прежнее значение для пары (chain, token), которое вычисляет rand_bridgeAssetId и выводит rand_getAssets в каждой строке обеспечения, — это более узкий идентификатор для формата передачи данных моста, а не собственный идентификатор токена.

Эмиссионные органы

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 реестра. Комиссия регистрации — параметр генезиса, ограниченный диапазоном от 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 каждая транзакция, переносящая стоимость, содержит ровно один пакет фиксированной формы 4-в-4 со скрытым активом (Транзакции и действия). Слоты 0–1 несут приватный актив, RAND или любой токен RPL, и схема никогда не узнаёт, какой именно. Слоты 2–3 всегда несут RAND. Перевод любого актива — это Action::None, то же действие, которое использует обычный платёж в RAND. Отдельного действия для перевода токена нет, как нет и публичного поля с названием токена.

Наблюдатель перевода токена видит ровно то же, что публикует платёж в RAND: якорь, четыре нуллификатора, четыре обязательства, комиссию fee в RAND, burn_a = burn_r = burn_asset = 0, time, четыре шифртекста конвертов и доказательство пакета. Начиная с цепочки 17 (раздельная авторизация) каждый пакет также содержит auth_commit и второе, меньшее доказательство авторизации, снова одинаковое для любого актива. В цепочке 20 каждый конверт занимает ровно 1 860 байт и содержит место для зашифрованного мемо (rand send --memo), отправлено оно или нет. Наблюдатель не видит отправителя, получателя, сумму, какой актив перемещался, какие слоты были фиктивными и какова сдача.

Кошелёк тратит до двух нот токена в слотах 0–1 и до двух нот RAND в слотах 2–3 на комиссию. Комиссия всегда в RAND, поэтому держателю токена без RAND будет отказано ещё до построения доказательства. Стоимость та же, что и у платежа в RAND (Комиссии). Начиная с цепочки 17 это два доказательства STARK, строящихся на машине отправителя; по измерениям в цепочке 20 это авторизация траты (уровень 10, около 7 с, около 1,37 МБ) и пакет (уровень 14, около 100 с, около 1,5 МБ), вместе около 2,85 МБ в передаче, каждое в пределах лимита этой цепочки в 4 МиБ на одно доказательство. Доказательства цепочки 21 относятся к набору ограничений 9, лимит 6 МиБ, и здесь пока не измерены. До цепочки 17 перевод содержал только доказательство пакета, около 1,42 МБ по тогдашним измерениям.

Выпуск и полномочие

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 выпуска включает дайджест конверта: одно лишь обязательство его не покрывает, и без дайджеста третья сторона могла бы переупаковать распространяемый по gossip выпуск с мусорным конвертом и израсходовать nonce.

Оба действия передаются в пакете с комиссией в RAND, оплачивающем BUNDLE_BASE. Кошелёк, платящий комиссию, и ключ, авторизующий выпуск, независимы и могут принадлежать разным людям.

Сжигание

Action::TokenBurn { asset, amount } передаётся в том же единственном пакете: burn_asset пакета должен совпадать с asset, burn_a — с amount, а burn_r равен 0. Токен покидает пул через слоты актива, а комиссия в RAND — через слоты 2–3 того же доказательства. total_supply уменьшается ровно на amount. Токен с полномочием Bridge здесь отклоняется (TokenError::BridgedToken); он выводится через сжигание в мосте.

Комиссии

Каждое действие RPL оплачивается в RAND.

В genesis цепочки 21, как и цепочки 20, есть раздел gas, и он определяет цену только для вызовов программ и invoke. Эти минимумы фиксированы: ни одно действие RPL не оплачивается по газу или по байтам. В цепочке 21 каждый минимум сжигается, а чаевые достаются предлагающему блок (Комиссии); 1 RAND регистрации был сожжён ещё раньше.

Что публично, а что скрыто

Поэтому total_supply всегда поддаётся аудиту: это то, что добавили регистрация и каждый выпуск, за вычетом каждого сжигания. Перевод между держателями ничего не раскрывает, в том числе того, что сменил владельца токен, а не RAND.

Раскрытие работает так же, как для RAND. Открытый текст ноты содержит актив, поэтому ключ отдельной транзакции (rand tx-key <hash>) или ключ просмотра открывает ноту токена так же, как ноту RAND, а rand_checkTransaction и rand_getViewingNotes возвращают asset в раскрываемой ноте. Получив такой ключ, randscan сопоставляет индекс с реестром и показывает перевод как перевод названного токена; публичная страница той же транзакции не показывает ничего из этого.

Токены с мостом

Токен с полномочием Bridge по-прежнему токен RPL: та же запись в реестре, тот же скрытый перевод, та же механика сжигания. Его предложение изменяется только через блокировку в исходной цепочке (BridgeAttest) или через выпуск обратно (BridgeBurn). У одного токена с мостом может быть много обеспечений, каждое — пара (chain, token) со своими decimals источника, заблокированной суммой и лимитом выпуска, и total_supply всегда равно сумме того, что заблокировано в его обеспечениях. Токен с мостом регистрируется, а обеспечение добавляется только по кворуму постквантовых хранителей моста.

В цепочке 21 первый токен реестра — zUSD («Shielded USD»), индекс 1, 8 decimals, указанный в файле genesis с семью обеспечениями (USDT и USDC в Ethereum, Binance Smart Chain и Solana и USDT в Tron). Он сохраняет идентификатор актива, который имел в цепочке 14, где был зарегистрирован транзакцией на высоте 256: цепочки с 15 по 21 каждая перечисляют его в genesis под тем же названием, символом и salt. Цепочка 21 началась со 100,001999 zUSD в трёх нотах genesis (10, 89,002999 и 0,999), обеспеченных 22 USDT, заблокированными в Ethereum, 23,001999 в Binance Smart Chain, 30 в Tron и 25 в Solana, перенесёнными из состояния моста цепочки 20 на высоте 814 702. Цепочка 20 началась с 99 zUSD в двух нотах (10 и 89), перенесённых из цепочки 19. Цепочка 19 началась с 10 zUSD, обеспеченных 10 USDT в Solana; цепочка 18 — с 9 USDT, заблокированных в Tron, и 1 в Solana. Его общее предложение равно тому, что заблокировано в его обеспечениях, и меняется с каждым депозитом и погашением. Его идентификатор — rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. Мост описывает обеспечения, единицы выпуска, лимиты выпуска, паузу и соподпись.

zUSD — это корзина, а не семь отдельных требований. Его обеспечения объединены по номиналу, поэтому держатель несёт риск каждого перечисленного обеспечения, а не той монеты, которую внёс: обеспечение, потерявшее привязку, можно внести по номиналу и сжечь zUSD в пользу надёжного обеспечения, пока надёжные не будут исчерпаны. Потери ограничивают скользящее окно выпуска (в цепочке 21, как и в цепочке 20, 4 000 zUSD по всем обеспечениям за 24 часа, помимо 100 000 на каждое обеспечение) и фактически заблокированное хранение. Окно ограничивает скорость и даёт время приостановить выпуск. Общую сумму оно не ограничивает. Обеспечение включается в список только по кворуму постквантовых хранителей и не тогда, когда выпуск приостановлен.

Комиссии моста в zUSD (начиная с chain 20). Генезис chain 20 задал bridge.fees, а генезис chain 21 переносит это без изменений: 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, которые сжигание платит пропозеру, не изменилась. В chains 14–19 на Rand не было комиссии моста.

Реестр начиная с chain 15

Начиная с chain 15 генезис включает три правила реестра, которых не было в chain 14, а генезис chain 21, как и chain 20, задаёт те же три значения. Каждое из них входит в хеш генезиса и корень токенов.

Граница значения ноты существует потому, что схема пакета проверяет диапазон каждой суммы в 63 бита: ноту стоимостью 2^63 или больше можно было бы зафиксировать, но нельзя потратить, хотя она учитывалась бы в предложении токена. Каждый узел также отклоняет такую сумму при приёме на любой цепочке, что бы ни говорил её генезис.

RPC и CLI

Каждая сумма в этих результатах (total_supply, registration_fee, locked обеспечения, mint_cap_per_day и minted_today) — десятичная строка, потому что число JSON не точно за пределами 2⁵³. index, next_index, mint_day и max_tokens — обычные целые числа (max_tokens равно 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 сообщают узлу, какой токен интересует вызывающего: для обозревателя это допустимо, для кошелька, который собирается отправлять, — нет. Поэтому кошелёк разрешает каждый --asset по полному списку, и числовой индекс вообще не доходит до узла.

Начиная с 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 выводит наименьшие единицы. В цепочке сумма всегда является целым числом наименьших единиц. Флаги и значения по умолчанию — в Командной строке.

Отличия от ERC-20 и SPL

Известные ограничения

• Нет разрешений на списание. approve и transferFrom спроектированы в спецификации RPL как целевые аккаунты разрешений и не реализованы.
• Активы программы публичны. С chain 20 программа может держать токены в своём хранилище и выпускать собственный токен (RPL-2), но баланс хранилища публичен, как и предложение токена; приватны только ноты. В цепочках до 20 состояния программ не было вовсе, а мультиподписные аккаунты и движок бессрочных контрактов chain 21 держат токены так же публично.
• Комиссии только в RAND. Токен не может оплатить собственную комиссию; кошелёк, в котором есть только токены, не может совершать переводы.
• Суммы u64 и не более 9 десятичных знаков. Исходная монета с 18 знаками представляется с меньшей точностью; мост рассчитывается с 8 знаками и единицей высвобождения на каждое обеспечение.
• Каждый перевод доказывается. Около 100 с и несколько ГБ памяти на машине отправителя; для токена нет более дешёвого пути, чем для RAND.
• Нет заморозки, чёрного списка и паузы для нативного токена, по решению. Пауза выпуска моста относится только к выпускам через мост.
• Поиск по отдельному токену раскрывает интерес. rand_getToken, rand_getTokenSupply и /tokens/:id обозревателя сообщают серверу, о каком токене спросили.