Rand Protocol
Documentação
Tokens

Implantar um token RPL

Passo a passo, de uma carteira a um token ativo na Rand: o que é um token RPL, como criar um token de oferta fixa ou emitível, emitir e transferir a autoridade, enviar e queimar o token de forma shielded, e consultá-lo no explorador com uma chave.

Esta página leva um token do zero a um ativo ativo e transferível na Rand. RPL é o padrão de tokens da Rand, novo na chain 14. Se você já implantou um ERC-20 ou criou um mint SPL, a primeira seção é a que merece leitura atenta, porque um token RPL não é nenhuma das duas coisas. Tokens RPL é a página de conceitos por trás desta.

1. O que é um token RPL

Um token RPL é uma entrada no registro de tokens do ledger, não um smart contract. Não há código para escrever, compilar nem auditar. Criar um token é uma única transação que adiciona uma linha ao registro e, a partir daí, as unidades do token são notes protegidas (shielded) comuns, mantidas no mesmo pool que a RAND e gastas da mesma forma.

camporegra
asset id32 bytes, a identidade do token. Escrito como rpl1…: bech32m, 62 caracteres, com checksum
indexum número pequeno que a chain atribui no registro (1, 2, …; 0 é a RAND). Um atalho para o id nesta chain
name1 a 32 bytes de UTF-8, fixado na criação
symbol1 a 12 caracteres ASCII imprimíveis, fixado na criação
decimals0 a 9, fixado na criação
mint authorityquem pode emitir mais unidades: ninguém (None), uma chave (Key) ou a bridge (Bridge)
total supplypúblico, e alterado apenas por um mint ou um burn

Os símbolos não são únicos. Qualquer pessoa pode criar um token chamado USDC, exatamente como na Ethereum e na Solana. A identidade de um token é o seu asset id; por isso, confira o id rpl1… antes de aceitar ou listar um token, nunca o símbolo. A forma textual tem checksum: um id digitado errado é recusado, e não enviado para outro lugar.

Como difere de ERC-20 e SPL

ERC-20 / SPLRPL
o que é um tokenum contrato, ou uma conta pertencente a um programauma linha do registro; sem código por token, portanto sem taxa sobre transferência, rebase nem hook
saldospúblicos, por endereçonotes protegidas (shielded). Ninguém consegue ler o saldo de um detentor nem listar os detentores de um token
uma transferênciaremetente, destinatário e valor públicosprovada pelo remetente, totalmente protegida (shielded). Um observador não a distingue de um pagamento em RAND
taxaa moeda nativa da chainRAND. Um detentor precisa de um pouco de RAND para movimentar um token, assim como um detentor de ERC-20 precisa de ETH
recebimentoo SPL exige antes uma token accountnada a configurar. Qualquer endereço rand1… pode receber qualquer token
valoresuint256 / u64u64, e no máximo 9 casas decimais
approve / transferFromsimnão na v1
freeze, blacklist, pausefrequentesnenhum
metadadosfora da chain ou mutáveisna chain e imutáveis
mantido por um programasimnão na v1

O que permanece público é a fronteira: o registro de um token, cada mint e cada burn, cada um com o seu valor. É isso que torna o total supply auditável por qualquer pessoa. As transferências entre detentores não revelam nada, nem mesmo qual token foi movimentado.

2. Antes de começar

você precisa decomo
a linha de comando randRunning a node a compila; Command line lista todos os comandos
uma carteirarand keygen grava um arquivo de spend key e rand address imprime o endereço rand1… correspondente (Accounts and addresses)
um nó com o qual se comunicara carteira fala JSON-RPC com um nó, por padrão o seu próprio em http://127.0.0.1:8545. Um nó vincula o seu RPC ao localhost, então a configuração usual é um nó próprio acompanhando a chain 20. Sem um, passe --rpc https://rpc.randprotocol.org: o endpoint público atende tudo nesta página, exceto rand faucet, que ele recusa (JSON-RPC, the public endpoint)
RAND para taxasalguns RAND na carteira. Os 100 RAND de uma chamada ao faucet cobrem tudo nesta página, mas na chain 20 o rand faucet paga apenas as 16 carteiras que o genesis inclui na allowlist (staking.faucet_recipients) e recusa qualquer outro endereço com the faucet may not mint to this recipient; qualquer outra carteira precisa receber RAND de alguém que o possua (Mint and burn)
a taxa de registroum parâmetro de genesis da chain, entre 1 e 10.000 RAND. Na chain 20 ela é de 1 RAND, portanto rand token create custa 1,001 RAND: a base de 0,001 RAND que toda transação paga, mais a taxa de registro, que a chain 20 queima em vez de pagá-la ao proposer do bloco. Todos os outros comandos aqui custam a base de 0,001 RAND
cerca de 6 GB de memória livretoda transação é provada na sua própria máquina. Na chain 20 são duas provas, e a carteira imprime uma linha para cada: proving the spend authorisation on this machine (tier 10; seconds)…, depois proving the bundle (tier 14; about a minute and a half on a laptop)…. A prova do bundle leva cerca de 100 segundos e cerca de 5,7 GB de memória enquanto roda; as duas pesam cerca de 1,37 MB e cerca de 1,5 MB na rede, cerca de 2,85 MB juntas. Isso vale para todas as etapas abaixo que alteram a chain: a criação, cada mint, cada envio e cada burn
rand --key wallet.key.json keygen     # writes the spend key; refuses to overwrite
rand --key wallet.key.json address    # your rand1… address
rand --key wallet.key.json faucet     # testnet only, allowlisted wallets only: asks a validator node to mint 100 RAND to this wallet
rand --key wallet.key.json balance    # scans the tree, prints the spendable value and the unspent note count

--key assume por padrão wallet.key.json e pode ser definido uma vez como RAND_KEY; --rpc (ou RAND_RPC) indica o nó com o qual se comunicar e assume por padrão http://127.0.0.1:8545. Os comandos abaixo escrevem --key explicitamente. Antes de gastar uma prova, confira se o nó está na chain 20: o método JSON-RPC rand_chainId retorna 20 nela. A carteira precisa ser uma build da chain 20, v0.6.8: a chain 20 vincula toda prova e toda mensagem assinada, inclusive a de um mint de token, ao seu genesis hash, de modo que um rand v0.6.7 produz provas e assinaturas que a chain 20 recusa.

3. Criar o token

token create recebe seus valores na menor unidade do token. --fixed-supply e --initial são números inteiros de unidades base: com --decimals 2, um valor de 1000000 equivale a 10.000,00 tokens. Todo comando posterior (rand send --asset, rand token mint, rand token burn) recebe as unidades de exibição do token desde a v0.5.10, assim como os valores em RAND são expressos em RAND (1.5): a carteira lê decimals na linha do registro do token, e mais casas fracionárias do que o token possui são recusadas. Na chain, um valor é sempre o inteiro em unidades base.

Decida primeiro uma coisa: poderão algum dia ser emitidas mais unidades? A resposta é fixada no token na criação e não pode ser ampliada depois.

supply fixomintable
mint authorityNoneKey: uma chave Dilithium2 que você controla
supplytodo o supply é emitido de uma só vez, na transação de criaçãocomeça em zero, ou em --initial; o detentor da chave emite ao longo do tempo
flags--fixed-supply <N> --to <rand1…>--authority-key-out <FILE> e, opcionalmente, --initial <N> --to <rand1…>
serve paraum token com limite, uma unidade de associação ou de votoum emissor que aumenta o supply, como um token de pontos ou de recompensa

Um token de supply fixo

rand --key wallet.key.json token create \
  --name "Example Credits" \
  --symbol EXC \
  --decimals 2 \
  --fixed-supply 1000000 \
  --to rand1…

--to é o endereço rand1… completo que recebe o supply, por exemplo a saída de rand address. --fixed-supply está em unidades base: 1000000 com 2 decimals equivale a 10.000,00 EXC.

O comando lê do nó o próximo index do registro e a taxa de registro, monta o note do mint inicial, prova um bundle de taxa, envia o registro e espera o bloco. Em caso de sucesso, informa o envio, depois imprime uma linha no formato index <N>, id <64 hex> (<rpl1…>) e, por fim, committed at height <H>. Anote o id rpl1…: ele é a identidade do token, e todo comando posterior o recebe.

A taxa padrão é a base mais a taxa de registro da chain, 1,001 RAND na chain 20, portanto não há nada a calcular; --fee (em RAND) a aumenta. --no-wait retorna assim que a transação é enviada e omite a linha committed. --cuda prova em uma GPU NVIDIA conectada, exige uma build com --features cuda e não recorre à CPU.

Se outro token for registrado enquanto o seu está sendo provado, ele ocupa o index para o qual o seu foi selado. O nó recusa o registro e o comando imprime another token took index N first — re-run to register at N+1, com os números reais. Um registro recusado nunca chega a um bloco; o que se perde é a prova, cerca de 100 segundos de trabalho. Execute o comando novamente e ele prova contra o próximo index.

O supply inteiro agora está em um único note protegido (shielded) pertencente ao endereço --to. O registro e o seu valor são públicos; o que o destinatário faz com o note depois não é.

Um token mintable

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json

Isto grava uma nova chave Dilithium2 em exp-authority.key.json (modo 0600, recusando sobrescrever um arquivo existente) e registra o token com essa chave como autoridade de emissão e com oferta zero. A saída é a mesma de duas linhas de um token de oferta fixa. Exatamente uma das opções --fixed-supply e --authority-key-out deve ser informada.

Para emitir um primeiro valor na mesma transação, acrescente --initial e --to, que devem ser informados juntos:

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json \
  --initial 5000 \
  --to rand1…

Enquanto o registro está em andamento, a chave fica em exp-authority.key.json.pending. Ela é promovida a exp-authority.key.json quando a cadeia aceita o registro e é descartada se a cadeia o recusa. Se a conexão falhar sem que o resultado seja conhecido, o arquivo permanece em .pending: verifique rand token list antes de apagá-lo.

O arquivo da chave é o poder de imprimir o token. Mantenha-o offline e com cópia de segurança; ele é distinto da chave de gasto da sua carteira e nunca é necessário para enviar ou receber.

Por que o destinatário da primeira emissão faz parte do id

Um registro não é assinado por quem o cria. Qualquer pessoa que veja o seu aguardando no mempool pode submeter uma cópia dele, paga com o próprio pacote de taxa. Se o id do ativo cobrisse apenas o nome, o símbolo e a quantidade, essa cópia poderia indicar o endereço de quem a copiou como destinatário e chegar primeiro a um bloco: essa pessoa seria dona do id e, num token de oferta fixa, de toda a oferta para sempre.

Por isso o id é um hash de tudo o que há no registro, inclusive a emissão inicial: sua quantidade, seu destinatário, sua aleatoriedade, seu horário e seu envelope cifrado. Uma cópia com outro destinatário gera um id de ativo diferente. É outro token que por acaso compartilha o seu símbolo, o que é tudo o que um símbolo não único jamais prometeu. O seu id só pode ser registrado com o seu destinatário.

--salt <hex32> define o salt de 32 bytes que também entra no id. Se for omitido, a carteira escolhe um ao acaso. Defina-o quando precisar que o id seja reproduzível, por exemplo para publicar o id antes de o token existir.

Confirme

rand token info rpl1…          # by id: rpl1… or 64 hex characters
rand token info 2              # or by the index `token create` printed
rand token list --limit 20     # one page of the registry; --from <index> pages on

token info imprime a linha do token como JSON: index, id, id_text (a forma rpl1…), name, symbol, decimals, authority, mint_nonce, total_supply e registered_at. authority é {"kind":"none"} para um token de oferta fixa e {"kind":"key","key":…,"address":…} para um token emitível. total_supply é uma string decimal em unidades base. token list imprime enabled, registration_fee, next_index e as linhas de tokens. Ambos leem a listagem completa do nó, de modo que o nó não fica sabendo qual token lhe interessava.

Ou por JSON-RPC, onde o parâmetro pode ser o índice, o id hexadecimal de 64 caracteres ou a forma rpl1…:

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

O resultado é a mesma linha que token info imprime, ou null se o token não existir; um id malformado (checksum incorreto, maiúsculas e minúsculas misturadas, comprimento errado) gera o erro -32602. rand_getTokens recebe [from_index, limit] e percorre página por página todos os tokens registrados, e rand_getTokenSupply retorna apenas { total_supply, backings }. Nenhum deles exige chave. Veja JSON-RPC.

Uma linha que existe hoje na cadeia 20 é a do zUSD, o token com ponte no índice 1. O explorador serve o registro do nó sem que você precise de um nó próprio:

curl -s https://randscan.org/api/v1/tokens

Na cadeia 14, em 2026-09-20, isso retornou "registration_fee": 1000000000, "next_index": 2 e um token, aqui abreviado até o seu primeiro lastro:

{
  "index": 1,
  "id": "32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f",
  "id_text": "rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx",
  "name": "Shielded USD",
  "symbol": "zUSD",
  "decimals": 8,
  "authority": {
    "kind": "bridge",
    "backings": [
      { "chain": 2, "token": "000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7",
        "decimals": 6, "locked": "0", "minted_today": "0", "mint_day": 20716,
        "mint_cap_per_day": "10000000000000" }
    ]
  },
  "mint_nonce": 0,
  "total_supply": "0",
  "registered_at": 256
}

Na cadeia 20, a linha tem o mesmo id, id_text, nome, símbolo e lastros, mas o zUSD consta no genesis em vez de ser registrado na altura 256 (registered_at 0), e sua oferta começou em 99 zUSD: 22 bloqueados em USDT na Ethereum, 22 em USDT na BSC, 30 em USDT na Tron e 25 em USDT na Solana, herdados da cadeia 19. (A da cadeia 19 começou com 10 zUSD, todos na Solana; a da cadeia 18, com 9 na Tron e 1 na Solana.) Cada linha de lastro também traz os campos de janela móvel minted_in_window, mint_window_secs e mint_headroom.

A cópia de registration_fee no explorador é um número JSON; o RPC do próprio nó o retorna, como todo valor, em uma string decimal. Na cadeia 20, como em todas desde a 15, o rand_getTokens do nó também traz max_tokens (4096), burn_registration_fee e bound_note_value (ambos true) (tokens RPL).

4. Emitir e transferir a autoridade

Só um token com autoridade Key pode ser emitido, e somente por essa chave.

rand --key wallet.key.json token mint \
  --asset rpl1… \
  --to rand1… \
  --amount 5000 \
  --authority-key exp-authority.key.json

--amount está nas unidades de exibição do token: 5000 deste token de 0 decimais são 5.000 unidades base, e 1.5 de um token de 6 decimais seriam 1.500.000. Antes de construir uma nota ou uma prova, a carteira lê a linha do token e se recusa a prosseguir se o token não tiver autoridade Key ou se --authority-key não for a chave indicada pelo registro. Em caso de sucesso, informa o envio e imprime minted <amount> (<base units> units) of asset <index> to <address>. --fee (padrão 0,001 RAND), --no-wait e --cuda funcionam como em token create.

Uma emissão acrescenta uma nota para o destinatário e eleva a oferta total. A quantidade e a chave pública do destinatário vão em claro na rede: uma emissão é um evento público por desenho, assim como um depósito pela ponte. Quando o destinatário movimenta a nota, ela passa a ser blindada como todo o resto. A carteira que paga a taxa (--key) e a chave que autoriza a emissão (--authority-key) são chaves diferentes e podem estar com pessoas diferentes.

Cada emissão é assinada sobre o id da cadeia, o id do ativo e um contador que o registro mantém e, na cadeia 20, também sobre o hash do genesis (rand-rpl-mint-2), de modo que uma emissão não pode ser reproduzida nesta cadeia nem copiada para outra, mesmo uma que compartilhe o mesmo id de cadeia. set-authority é vinculado da mesma forma.

Para transferir a autoridade a uma nova chave, ou abrir mão dela de vez:

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --new-key next-authority.key.json

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --renounce

--new-key recebe um arquivo de chave e entrega o token à chave pública desse arquivo; exatamente uma das opções --new-key e --renounce deve ser informada. O comando imprime asset <index>'s mint authority is now <public key hex> ou asset <index>'s mint authority is renounced for good. Cada uma custa a base de 0,001 RAND e uma rodada de prova. --renounce transforma o token em um token de oferta fixa na oferta atual. É irreversível: uma autoridade pode passar de chave para chave ou de uma chave para ninguém, e nada além disso. Um token criado com oferta fixa nunca pode se tornar emitível.

5. Use-o

Enviar

rand --key wallet.key.json send rand1… 250 --asset rpl1…

Isto envia 250 do token em unidades de exibição: 250 EXP com 0 decimais, ou 250,00 EXC (25.000 unidades base) com 2. O destinatário e a quantidade são posicionais, como no caso do RAND. Antes de qualquer prova, a carteira imprime uma linha, to fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <symbol> (<base units> units), e pergunta send? [y/N]. Confira a impressão digital com a do destinatário e as unidades base com o que você pretendia. --yes dispensa a pergunta, e um script deve passá-lo: sem ele, um stdin que não seja um terminal é recusado. --asset aceita o índice, o id rpl1… ou o id hexadecimal de 64 caracteres, e omiti-lo envia RAND. --memo <text> sela até 510 bytes de texto para o destinatário dentro do envelope do pagamento, o que a cadeia 18 é a primeira a permitir; nada na cadeia mostra que há um memo. --fee é sempre em RAND e tem padrão 0,001; --no-wait e --cuda se aplicam. Um id é resolvido para o seu índice a partir da listagem completa do registro do nó, e um índice numérico nunca chega ao nó, de modo que o nó não é informado de qual token está prestes a se mover. É o mesmo rand send que movimenta RAND, e a mesma prova. A transação publica quatro nullifiers, quatro compromissos, uma taxa em RAND, um horário, quatro envelopes cifrados, a prova do pacote e, desde a cadeia 17, um compromisso de autorização e a sua prova, qualquer que seja o ativo movimentado. Um observador não distingue uma transferência de token de um pagamento em RAND, não sabe de qual token se tratava e não vê remetente, destinatário nem quantidade.

A taxa é paga em RAND dentro do mesmo pacote, portanto a carteira remetente precisa ter algum RAND. A carteira verifica isso antes de começar a provar.

Consultar um saldo

rand --key wallet.key.json asset-balance 2     # one token, by index
rand --key wallet.key.json asset-balance       # a row for every token this wallet holds

O argumento é um índice do registro. Para um token, a carteira imprime asset <index> balance: <N> units, em unidades base. rand notes lista todas as notas que a carteira abriu, com o respectivo índice asset. A carteira encontra suas notas varrendo a cadeia com a sua chave de visualização. Nada na cadeia guarda um saldo para ela consultar.

Queimar

rand --key wallet.key.json token burn rpl1… 100

O ativo e a quantidade são posicionais: o ativo como índice, rpl1… ou hexadecimal, a quantidade nas unidades de exibição do token, como send --asset as lê. --fee tem padrão 0,001 RAND; --no-wait e --cuda se aplicam.

Uma queima destrói unidades e reduz a oferta total. Como a emissão, é uma fronteira pública: a quantidade e o token são visíveis, o detentor não. Um token com ponte, como o zUSD, não é queimado desta forma: token burn o recusa antes de provar, e ele sai por rand bridge-burn, que libera a moeda que o lastreia.

6. Verifique no explorador

randscan.org mostra o lado público de um token a qualquer pessoa: o seu registro, as suas emissões e queimas, e a sua oferta total. Todos os tokens estão listados em randscan.org/tokens, e a página de um token é /tokens/<rpl1…>, /tokens/<64 hex> ou /tokens/<index>; randscan.org/tokens/1 é o zUSD. Os mesmos dados estão em GET /api/v1/tokens e GET /api/v1/tokens/:id, o segundo com a transação de implantação do token e o seu histórico de oferta, com registro, emissões e queimas (API do Explorer).

A página pública de uma transferência não mostra nenhum ativo, nenhum valor e nenhuma parte, porque a cadeia não os tem. Para provar um pagamento a outra pessoa, como um auditor, uma contraparte ou uma exchange, entregue-lhe uma chave:

chaveo que o seu titular vê
uma chave de transaçãouma saída de uma transação aberta: o token, o valor e as partes
uma chave de visualizaçãotodas as notes que a carteira enviou ou recebeu, com o mesmo detalhe, e se cada uma foi gasta
rand --key wallet.key.json tx-key <TX_HASH>    # the keys for one transaction
rand --key wallet.key.json viewing-key         # the wallet's viewing key, 64 hex characters

tx-key imprime uma linha por saída dessa transação que esta carteira enviou, recebeu ou manteve como troco: a saída (bundle:0 a bundle:3, os quatro slots do bundle), o papel, o valor (em RAND, ou N (asset I) para um token) e a chave por transação sob a qual essa saída foi selada. Entregue a chave da linha sent. Funciona para qualquer transação passada, porque a carteira recupera a chave a partir da cadeia.

Cole uma chave de transação na página da transação no randscan para abrir essa saída; o explorer resolve o índice do ativo no registro e mostra o token pelo nome, com as suas casas decimais aplicadas. Uma chave de visualização vai em randscan.org/viewing. O explorer não guarda nenhuma chave e não decifra nada no seu servidor. Por JSON-RPC, a mesma divulgação é rand_checkTransaction(hash, key). Nenhuma das chaves pode gastar o que quer que seja. Uma chave de visualização não pode ser retomada depois de compartilhada, por isso prefira uma chave de transação quando basta provar um único pagamento.

7. Tokens com ponte

zUSD (“Shielded USD”) também é um token RPL, com uma autoridade Bridge: as suas unidades só são emitidas quando os guardiões atestam um depósito de USDT ou USDC em Ethereum, Binance Smart Chain, Tron ou Solana, e a sua oferta é sempre igual ao que está bloqueado ali. Foi registrado na chain 14 por uma transação na altura 256, no índice 1, com sete lastros, e o genesis de todas as chains desde então, incluindo a chain 20, volta a listá-lo com o mesmo id, rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. A chain 15 herdou os 10 zUSD ainda em circulação quando a chain 14 parou, as chains 16 a 19 começaram com os mesmos 10 zUSD, e a chain 20 começou com os 99 zUSD em circulação na chain 19. Na chain 20, a ponte cobra 10 bps sobre cada depósito e cada resgate, em zUSD, para uma note de tesouraria (Bridge). O zUSD é uma cesta: os seus lastros são agrupados pelo valor de face, de modo que quem o detém assume o risco de todas as moedas listadas, e não apenas da que depositou (Tokens RPL). A sua oferta varia a cada depósito e a cada resgate; rand token info 1 ou /tokens/1 no explorer dão o valor atual.

A sua vida na chain 14, uma testnet anterior (verificado no explorer em 2026-09-20). Esta tabela é o histórico da chain 14: a chain 14 foi desativada, portanto estas transações não estão no explorer da chain 20:

o quêtransação (chain 14)altura
o registro (register_bridged_token)7fa28fe6277a82401dcc440ff32da13c5e5763f79826fb17cc508f4c15abdd13256
uma emissão pela ponte (bridge_attest)f2f24d75bc0e7d84dff1f4e4518a9d4bef115392492a39befca1528a2404851d2,572
uma transferência shielded de zUSDe6ddaca3c852e6c861524a55d00a0fbdcaff6867544b9f19b9bf60ce263c32ed3,259
uma queima pela ponte (bridge_burn)f9f365ca170a5fb51ff9381d7b5cc39538c1a621e5f6e8c1bd74d8751c7bbc493,481

A página da transferência mostrava o que qualquer transferência de token mostra: quatro nullifiers, quatro commitments e uma taxa, e nada que indique que zUSD foi movimentado.

Para mostrar o que uma chave divulga, as notas de versão v0.5 do fullnode publicaram duas para essa transferência da chain 14, a partir de uma carteira de demonstração feita para esse fim, que não guarda mais nada:

chavevaloro que abre
a chave de transação da transferência7f68f57c4f33a3f0fe419f4d1a5df2875461339dbc454af8ced50cbd7f40e4efa saída bundle:0 dessa única transação: valor 100000000 do asset 1, ou seja, 1 zUSD
a chave de visualização da carteira de demonstraçãoa93c673ffeff7204447161347828d8e549b7070460813ae1b7e664694e1dcd5dtodas as notes que essa carteira enviou ou recebeu

Na chain 14, a chave de transação abria essa saída na página da transferência, e por JSON-RPC bastava uma chamada (verificado em 2026-09-20). A chamada tem a mesma forma na chain 20 para uma transação sua; com estes valores da chain 14, um nó da chain 20 responde null (verificado em 2026-10-01), pois nunca teve essa transação:

curl -s https://rpc.randprotocol.org -H 'content-type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1, "method": "rand_checkTransaction",
  "params": ["e6ddaca3c852e6c861524a55d00a0fbdcaff6867544b9f19b9bf60ce263c32ed",
             "7f68f57c4f33a3f0fe419f4d1a5df2875461339dbc454af8ced50cbd7f40e4ef"] }'

Nunca publique uma chave de visualização de uma carteira que você usa: ela mostra todo o histórico dessa carteira, para sempre.

Um endereço comum não pode criar um token com ponte. rand token create recusa uma autoridade Bridge, e registrar um token com ponte, ou acrescentar uma moeda por trás de um já existente, exige um quórum assinado do conjunto de guardiões pós-quânticos da ponte. Um token que se apresenta como zUSD sem isso é apenas mais um token com um símbolo emprestado, o que é mais uma razão para conferir o id rpl1…. Os tokens com ponte têm sempre 8 casas decimais na Rand.

Bridge trata de depósitos, resgates e do conjunto de guardiões.

Última verificação em relação ao commit c0878c3f do fullnode (chain 21) em 2026-10-12, e fullnode `docs/tokens.md`, `docs/cli.md`, `docs/rpc.md` and the wallet's output lines in `crates/randprotocol-client/src/main.rs`; randscan `adfe129` (`docs/api.md`); the live registry at `randscan.org/api/v1/tokens` on 2026-09-20. The commands on this page were checked against those sources, not run by us on chain 14. Updated for chain 15 against fullnode `8abf85e` (v0.5.9) 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, `deploy/genesis-chain18.json` and the wallet's output lines in `crates/randprotocol-client/src/main.rs` and `wallet.rs` at the v0.6.7 tag; randscan `fffa404` (`docs/api.md`). The commands were checked against those sources, not run by us on chain 18; the zUSD transactions in section 7 are chain 14's. Updated for chain 20 on 2026-10-01 against fullnode `c9c9bd3c` (v0.6.8): `deploy/genesis-chain20.json` (`tokens`, `binding_domain`), `crates/randprotocol-core/src/types/binding.rs` (the genesis-bound mint and authority messages), and the live `rand_chainId`, `rand_getTokens` and `rand_checkTransaction` on 2026-10-01 Updated for chain 21 on 2026-10-12 against fullnode `c0878c3f` (v0.8.0): `deploy/genesis-chain21.json` (`tokens`, `fees`), `rand_getTokens` and `rand_getSupply` on chain 21; the commands were not run on chain 21.. Onde o código e esta página divergirem, o código está certo; avise-nos.