Rand Protocol
Documentação
Guias

Cunhagem e queima

Como a RAND entra no pool (depósitos de gênese e o faucet da testnet) e como sai dele (taxas e as palavras de queima de um bundle), e o que cada movimento publica.

Use esta página para operar um faucet em uma chain de teste, para entender o que é uma transação Mint na rede e para ver exatamente como um bond ou um burn de ponte retira valor do pool. Toda entrada e toda saída é pública; tudo o que fica entre elas é uma nota.

O mint do faucet

Um Mint é a única forma de criar RAND depois do genesis na chain 20, e só existe em chains cujo genesis diz "faucet": true. É uma transação assinada por um validador e sem pacote:

Action::Mint { cm: Word8, pk: Word8, time: u32, r: Word8, envelope: Envelope, amount: u64,
               minter: PublicKey, signature: Signature }

rand_mint(address[, amount]), em um nó validador, constrói uma nota de amount para o endereço rand1… informado, sela o envelope sob uma chave de remetente descartável, assina o mint com a chave Dilithium2 do próprio nó e o submete pela mempool normal — assim o mint passa pelo consenso e todo nó o aplica. O limite é 100000000000 unidades, 100 RAND, por chamada, e o padrão é o limite. Desde a chain 14 o mint carrega a abertura da nota — pk, time e r — e a assinatura a cobre: a admissão recalcula o compromisso de (pk, no sender, amount, asset 0, time, r) e recusa um cm que não corresponda, com the mint's commitment does not open to its published note and amount, e mantém time dentro da janela do pacote. Os parâmetros de rand_mint não mudaram. A mensagem assinada é blake3("rand-mint-2" ‖ bincode(chain_id, cm, pk, time, r, envelope, amount)) nas chains 14 a 19; na chain 20, cujo genesis define binding_domain: 1, é rand-mint-3 sobre o hash do genesis seguido dos mesmos campos, de modo que um mint assinado para uma chain é recusado em qualquer outra, mesmo que compartilhe o chain id e as chaves dos validadores. Um observador não tem chave de validador e responde faucet mints are signed by validators; ask a validator node; uma chain sem a flag responde faucet is disabled on this chain.

O faucet da chain 20 está ligado, mas limitado pela seção staking do genesis, com os mesmos valores da chain 19:

regrachain 20recusa
destinatáriosuma lista de permissão de 16 carteiras (staking.faucet_recipients); o pk publicado do mint precisa constar nelathe faucet may not mint to this recipient (not in staking.faucet_recipients), permanente
orçamento10.000 RAND por época de 1.000 blocos (staking.faucet_budget_per_epoch), somando todos os validadoresthe faucet budget of … for this epoch is exhausted (… minted); a próxima época o admite
emissores18 dos 26 validadores (staking.faucet_minters, listados desde a chain 16); o mint precisa ser assinado por um delesminter … is not a faucet minter on this chain

Assim, rand faucet funciona na chain 20 apenas para uma carteira da lista, solicitado a um nó validador cuja chave seja um emissor listado; qualquer outro endereço precisa ser pago por quem detém RAND.

rand faucet                          # 100 RAND to this wallet's address, waits for the commit
rand faucet rand1… --amount 25       # to another address, less than the cap
→ {"method":"rand_mint","params":["rand1…", "100000000000"]}
← "9ab1c0…4f"

O que é público: o compromisso da nova nota, seu envelope, o valor em claro, e a chave pública do validador que fez o mint (exibida como endereço) e sua assinatura. A abertura também publica a chave de proprietário pk da nota, de modo que o proprietário de uma nota do faucet é público, como é o pagamento de um withdraw; o que permanece oculto é quando e onde essa nota será gasta depois. O vínculo de um salto entre “100 RAND foram criados” e “existe uma nota de 100 RAND” é a mesma visibilidade que um depósito de transparente para blindado tem em qualquer lugar. A admissão verifica que o faucet está habilitado, que o valor está abaixo do limite, que o orçamento da época comporta o mint, que o destinatário consta na lista de permissão quando o genesis tem uma, que o compromisso abre para a nota publicada, que o emissor é um validador (e consta na lista de emissores quando o genesis tem uma) e que a assinatura é válida; um mint não paga taxa.

rand_getTransaction renderiza um como { "kind": "mint", "cm": "…", "amount": "100000000000", "minter": "<validator base58>" } com "bundle": null — o valor é uma string decimal, como todo valor u64 que o RPC serve desde a chain 14; o explorador os lista em kind=mint, um dos poucos tipos com amount público.

Depósitos de genesis

A outra forma de o valor entrar é o arquivo de genesis: cada --alloc rand1<address>=<RAND> passado a rand-node genesis vira uma nota de depósito { cm, envelope, amount, opening } com aleatoriedade de compromisso nova, as primeiras folhas da árvore. A chain 20 tem nove notas de genesis: sete notas de RAND, 5.184,243719258 RAND no total (genesis_deposited), os saldos dos operadores transportados de um snapshot da chain 19, e duas notas de zUSD de 10 e 89 zUSD, os 99 zUSD de custódia da ponte transportados da chain 19 (Bridge), que não são RAND e não entram em genesis_deposited. O RAND mantido na chain 19 por carteiras que o operador não controla, cerca de 520 RAND, e as taxas de validador não sacadas não foram transportados. Histórico: a chain 19 teve oito, sete notas de RAND de 5.294,644359629 RAND e uma de 10 zUSD; a chain 18 teve seis notas de RAND, cinco de 1.000 RAND e uma de 300 RAND; as chains 14 e 15 tiveram cinco de 1.000 RAND. O valor é público para que todos possam somar a oferta inicial, e desde a chain 14 a nota carrega também sua abertura, de modo que o proprietário de uma nota de genesis é público por desenho. Refazer o corte com as mesmas alocações gera notas diferentes e um hash de genesis diferente, de propósito.

Burns

Toda transação carrega um pacote de ativos ocultos de quatro slots, e ele tem duas palavras de burn: burn_r é RAND saindo do pool para um lugar público, e burn_a é uma quantidade do token indicado por burn_asset. O guest do pacote equilibra os dois grupos em uma única prova, e a admissão exige que os três sejam zero, exceto nestas ações:

burnregrapara onde vai o valor
o pacote de um Bondburn_r == amounto stake público do validador no registro
o pacote de um BridgeBurnburn_asset == asset, burn_a == amount, burn_r == 0, asset != 0destruído na Rand; o contrato da chain de origem libera amount da moeda indicada contra a mensagem de burn assinada pelos guardiões. Na chain 20 a chain retém uma taxa de 10 bps como uma nota de zUSD para o tesouro e a liberação é amount − fee
o pacote de um TokenBurno mesmo formato do de um burn de pontedestruído; o total_supply público do token RPL cai exatamente nesse valor
o pacote de um Invoke (RPL-2, chain 20)burn_r, e burn_a de burn_asset, conforme a transição do programa declaraRAND e tokens depositados no vault público do programa, ou o token do próprio programa destruído; um vault só paga de novo como notas calculadas pela chain (Programs)

(O pacote de um register_aggregator também queima seu bond de genesis por burn_r; a agregação está desligada na chain 20.)

Burns não são taxas. O burn de um bond é RAND movendo-se do pool para o registro e é contado em burned na auditoria de oferta (e reaparece em register_total). Um burn de ponte é um único pacote desde a chain 14 (antes eram dois): os slots 0–1 queimam o ativo em ponte e os slots 2–3 pagam a taxa, de modo que ele toca a oferta de RAND apenas por essa taxa, BRIDGE_BURN_FEE, 0,01 RAND. Ele precisa indicar uma moeda que lastreia o ativo, liberar um número inteiro de unidades dessa moeda e caber no que esse lastro tem bloqueado (Bridge). Na chain 20, o bridge.fees do genesis também cobra 10 bps de todo mint e burn em ponte em zUSD: um depósito credita o valor bruto menos a taxa e um burn libera amount − fee, cada taxa sendo uma nota blindada de zUSD para o tesouro. A nota de taxa continua emitida e lastreada, de modo que total_supply == Σ locked do zUSD continua valendo; não é um movimento de RAND e não entra na auditoria de oferta de RAND. Um TokenBurn paga a base de pacote de 0,001 RAND; um token em ponte é recusado ali e sai por bridge-burn.

Uma taxa também é um burn na chain 20, como em toda chain desde a 15: seu genesis define tokens.burn_registration_fee, de modo que o registration_fee de 1 RAND de um RegisterToken ou RegisterBridgedToken é destruído em vez de pago ao proponente, que fica apenas com a base do pacote. Ele é contado em burned e, separadamente, em registration_fees_burned (RPL tokens).

rand bond <validator> 1000 [--registration <hex>]     # burns 1000 RAND out of this wallet's notes
rand bridge-burn <ASSET> <AMOUNT> <TO_CHAIN> <TOKEN> <TO>   # burns AMOUNT of a bridged asset, released as TOKEN on TO_CHAIN
rand token burn <ASSET> <AMOUNT>                      # destroys AMOUNT of an RPL token this wallet holds

As taxas são a outra saída

A fee de cada pacote sai do pool para os rewards do proponente do bloco, um campo público do registro, e só volta ao pool quando o validador a saca como uma nota (Staking). Um Withdraw paga a base de 0,001 RAND, retirada do valor sacado, ao proponente do bloco que o aplica; essa base nunca deixa o registro, portanto não é uma travessia.

Como a oferta se move

in:   genesis_deposited, faucet_minted, withdraw_deposited, program_rand_out
out:  fees_paid, burned
pool_value     = in − out
total_supply   = pool_value + Σ register (stake + pending + rewards) + program_rand_held
               ==  genesis_deposited + genesis_staked + faucet_minted − slashed − registration_fees_burned

program_rand_held e program_rand_out são novos na chain 20 (RPL-2): o RAND que um Invoke queima para um vault de programa por burn_r é contado em burned do lado do pool e mantido no vault, e o que um vault paga como notas volta ao pool. rand_getSupply serve ambos, com invariant_holds.

Somente uma emissão do faucet (mint) aumenta o que a chain emitiu, e na chain 20 somente uma taxa de registro queimada reduz esse total: slashed contaria um bond de aggregator sofrendo slashing ou, sob uma seção staking.slashing do genesis, o stake de um validator sofrendo slashing, e a chain 20 não tem nenhum dos dois (a agregação está desativada e slashing é null). Um bond, uma taxa, um withdraw e um depósito em vault movem valor entre o pool, o registro e os vaults, e não criam nada. Supply traz os contadores e um exemplo resolvido. O subsídio de agregação de blocos — novos RAND por bloco selado, segundo um cronograma de halving, pagos a um aggregator como uma nota de depósito — seria a primeira emissão programada, e não está ativo na chain 20.

Última verificação em relação ao commit c0878c3f do fullnode (chain 21) em 2026-10-12. Onde o código e esta página divergirem, o código está certo; avise-nos.