Leia esta página para decidir contra o que construir e por onde começar: o modelo da cadeia em poucos parágrafos, os parâmetros da testnet ativa, como obter RAND de teste e um mapa do restante da documentação.
O que é o Rand Protocol
Rand é uma cadeia blindada pós-quântica. Sua moeda nativa é o RAND, e o RAND vive em um pool totalmente blindado (shielded): não há contas nem saldos on-chain, apenas compromissos de notes e nullifiers, e uma transferência é uma prova de conhecimento zero de que quatro notes se tornaram outros quatro notes (notes fictícios preenchem os slots não usados), sem mostrar qual ativo se moveu. O RAND e todo token do padrão próprio da cadeia, o RPL, compartilham esse único pool. A mesma moeda paga por programas confidenciais: programas RISC-V que são executados off-chain dentro de uma máquina virtual de conhecimento zero e são liquidados on-chain com uma prova, em vez de com as suas entradas.
Cada primitiva é escolhida para resistir a um adversário quântico:
| camada | o que roda |
|---|---|
| Assinaturas | Dilithium2 (baseado em reticulados). Os validadores assinam blocos e votos com ele; o faucet, as ações de staking e os registros da bridge são assinados com ele. Uma carteira nunca assina uma transação: um bundle se autoriza por meio de sua prova. |
| Criptografia de notes | Encapsulamento de chaves ML-KEM-768 mais ChaCha20-Poly1305. Cada note on-chain é acompanhado por um envelope que apenas o seu dono (e o seu remetente) pode abrir. |
| Hashing | BLAKE3 com separação de domínio para endereços, ids de transação, a raiz de estado e todo o resto fora do sistema de provas; Poseidon2 sobre o corpo Goldilocks para notes, nullifiers, a árvore de compromissos e tudo o que está dentro de uma prova. |
| Provas | Um STARK em lote Plonky3 com FRI de ocultação (80 consultas, blowup 8, 20 bits de proof-of-work). Transparente: sem trusted setup, sem curva de emparelhamento, e a hipótese é uma função hash resistente a colisões. |
| Computação confidencial | O zkVM da Rand, uma máquina RV32IM provada sob esse STARK. Um programa é identificado por um digest dentro do circuito, e o verificador nunca vê uma única palavra de instrução. |
| Consenso | HotStuff BFT encadeado: quóruns ponderados por stake de mais de dois terços, líderes em rodízio, uma regra de commit de três views consecutivas. |
| Armazenamento e rede | Um RocksDB por nó, com commits sincronizados em disco (fsync) e verificação de integridade na inicialização; libp2p (TCP, Noise, Yamux, gossipsub, Kademlia, mDNS em LANs). |
A implementação de referência é randprotocol/fullnode, em Rust: o binário rand-node é o nó, o binário rand é a carteira, e os métodos JSON-RPC têm o prefixo rand_. O explorador é randscan.org.
A testnet: chain 20
A frota pública executa a chain 20, ativa desde 2026-10-01 06:17 UTC no fullnode v0.6.8. As chains 15 a 19 foram aposentadas. Quatro chains foram criadas em quatro dias, cada uma por uma mudança que altera todas as provas ou o formato da transação:
- A Chain 16 (2026-09-28, fullnode v0.6.1) moveu o zkVM para o conjunto de restrições 7, que oculta o que uma prova costumava revelar sobre pequenas entradas privadas, e ativou as regras
hardening_v6. - A Chain 17 (2026-09-29, v0.6.3) separou a autorização de uma transferência de sua prova: cada bundle carrega uma segunda prova, pequena, feita com a spend key, de modo que a prova grande possa ser feita por uma máquina que detém apenas uma viewing key.
- A Chain 18 (2026-09-29, v0.6.7) mede as chamadas confidenciais em gas (conjunto de restrições 8) e ativa o memo criptografado em cada envelope de note.
- A Chain 20 (2026-10-01, v0.6.8) vincula cada prova e cada mensagem assinada ao hash de gênese, adiciona estado de programa (RPL-2), cobra uma taxa sobre mints e burns da bridge de zUSD e ativa as regras audit-v6 listadas na tabela abaixo.
A chain 19 (2026-10-01 03:43 UTC, v0.6.7) foi um re-genesis da chain 18 sobre o mesmo build e não mudou nenhuma regra. A chain 18 foi parada na altura 143,776, e a chain 19 foi criada a partir de um snapshot na altura 141,935. Sua gênese diferia da gênese da chain 18 apenas no id da chain, no timestamp, nos notes transferidos e na seção da bridge: novos emissores para os endpoints de Ethereum, Binance Smart Chain e Tron, com os contadores de sequência mantidos.
A chain 20 é um hard fork da chain 19: sua gênese foi criada a partir de um snapshot da chain 19 na altura 7,258, a chain 19 foi parada na altura 7,700, e todos os 26 validadores foram reiniciados juntos na chain 20, com as mesmas chaves, ids de peer e nós de bootstrap. A chain 19 e a chain 18 estão aposentadas. Uma carteira precisa da v0.6.8 para enviar na chain 20: as provas e assinaturas de uma carteira mais antiga não carregam o vínculo com a gênese, e a chain as recusa.
Cada uma é uma chain nova. Os saldos de RAND nas carteiras do operador e o zUSD em circulação foram levados para a gênese seguinte, e nada mais: um programa implantado em uma chain não existe na seguinte. É um software experimental: não auditado, e o RAND nele não tem valor.
Os Programas na chain 20 podem manter estado: as células de programa, os cofres de programa (program vaults) e a ação Invoke do RPL-2 estão ativos.
| chain id | 20 (rand_chainId) |
| genesis hash | 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 |
| arquivo de genesis | deploy/genesis-chain20.json no repositório do fullnode |
| build | fullnode v0.6.8 (tag c9c9bd3c); um nó informa a própria build em rand_getVersion. Esta build recusa as chains 14 a 17, e uma carteira anterior à v0.6.8 não consegue enviar na chain 20 |
| vínculo com o genesis | binding_domain 1: o vínculo de prova de cada bundle e toda mensagem de ação assinada incluem o hash do genesis, de modo que nada provado ou assinado para uma chain é verificado em outra |
| marcador de testnet | testnet true: o genesis se declara uma rede de teste, o que permite que um faucet funcione ao lado da bridge |
| validadores | 26, cada um com stake de 1.000 RAND, o mínimo de staking |
| quórum | 18 de 26: estritamente mais de dois terços do stake |
| intervalo de bloco | o padrão --block-interval-ms 1000; cerca de um bloco por segundo |
| tempo de bloco | um timestamp mais de 60 s além do de seu bloco pai é inválido, e um validador não vota em um bloco mais de 15 s à frente do próprio relógio, por isso os validadores executam NTP |
| janela de prova | proof_window_blocks 1.024: a âncora de um bundle deve ser uma das últimas 1.024 raízes de fim de bloco, e seu time não pode ser mais antigo que isso (256 blocos nas chains 18 e 19) |
| épocas | 1.000 blocos; um novo bond espera duas épocas extras antes de contar (bond_activation_epochs 2, ativando na época e + 3), e o stake desvinculado é liberado duas épocas depois |
| staking | os registros são v2 (rand-node register --v2), e uma nova chave só se registra depois que validadores com mais de dois terços do peso a votam (admission_by_vote); o peso de um validador é limitado a 33,33 %; o novo stake que entra em um limite de época é limitado a 25 % do peso ativo (max_stake_entry_bps_per_epoch 2.500); sem slashing |
| zkVM | conjunto de restrições 8, perfil FRI de produção (80 consultas) |
| guest do bundle | hc_bundle 60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce: o bundle de ativo oculto de 4 entradas e 4 saídas, versão 3, tier 14 |
| guest de autenticação | hc_auth 1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1: a autorização de gasto que todo bundle carrega, tier 10 |
| gas | uma chamada declara um limite de gas que o circuito impõe e paga gas_price por ele: 100 unidades por gas e 800 unidades por KiB no piso, ambos se movendo a cada bloco rumo a uma meta de 262.144 de gas e 10.485.760 bytes, e nunca acima dos tetos de 10.000 por gas e 80.000 por KiB. Apenas os bytes sobre os quais o preço por byte é cobrado (a prova de uma chamada e seu envelope de entrada) contam para a carga de bytes (byte_load: "paying"), de modo que um bloco de transferências não a eleva. Todo bundle declara o limite fixo 20.479 e paga os 0,001 RAND fixos |
| estado de programa | RPL-2 ativado: células de programa, cofres de programa e Invoke (Action 33); uma célula criada custa 0,01 RAND (cell_fee 10.000.000 unidades); uma invocação lê no máximo 8 células, escreve no máximo 8 e faz no máximo 4 pagamentos (rand_getLimits.program_state) |
| envelope de note | envelope_bytes 1860: o envelope de cada note tem 1.860 bytes e carrega um memo criptografado |
| limite de programa | max_program_words 65.535, mas sob hardening_v6 um deploy que nenhuma chamada de tier 14 conseguiria comportar é recusado (ProgramUncallable): 8.180 palavras para um programa sem segmento público |
| limite de prova | max_proof_bytes 4.194.304 (4 MiB); eram 8 MiB nas chains 13 a 16 |
| limite de bloco | max_block_bytes 20.971.520 (20 MiB) |
| limite de envelope de chamada | max_call_envelope_bytes 65.536 |
| entrada pública por programa | max_program_public_words 32.768, fixado no deploy |
| faucet | ativado, mas apenas para as 16 carteiras da allowlist do genesis (staking.faucet_recipients), e apenas a partir dos 18 validadores que o genesis nomeia como minters (staking.faucet_minters): até 100 RAND por chamada, 10.000 RAND por época no total |
| computação confidencial | ativada; a prova de uma chamada é limitada ao tier 14. Os programas não são transferidos por uma troca de chain; os programas de exemplo indicam em qual chain cada um está implantado |
| tokens | o registro RPL está ativado: taxa de registro de 1 RAND, queimada; no máximo 4.096 tokens; todo valor de note abaixo de 2⁶³. O zUSD está listado no genesis no índice 1 |
| bridge | ativada: conjunto de guardiões 1 com oito guardiões, oito guardiões PQ Dilithium2, uma chave de pausa, emissores para quatro chains de origem, um limite diário de mint de 100.000 zUSD por lastro e um limite global de 4.000 zUSD por 24 horas contínuas em todos os lastros. O zUSD tem sete lastros; sua oferta é o que estiver bloqueado, lido ao vivo em rand_getTokenSupply. Desde a chain 20, uma taxa de 10 bps é cobrada em cada mint e em cada burn, em zUSD, como uma note para um endereço de tesouraria (bridge.fees): um depósito credita o valor bruto menos a taxa, e um burn libera amount − fee na chain de origem. Uma rotação dos guardiões PQ ou da chave de pausa carrega a assinatura própria de cada nova chave e entra em vigor 86.400 s depois de aceita (bridge.rotation) |
| histórico | 24 validadores mantêm 24 horas de blocos (--prune-history 24h) e respondem -32010 abaixo disso; dois nós de arquivo mantêm todos os blocos, e o RPC público https://rpc.randprotocol.org encaminha para um nó de arquivo |
| agregação de blocos | desativada (nenhuma seção aggregation no genesis; a build se recusa a iniciar com um genesis que tenha uma) |
| valor do genesis | 26.000 RAND em stake no registro de validadores mais sete notes de depósito totalizando 5.184,243719258 RAND, trazidas das carteiras do operador na chain 19: 31.184,243719258 RAND, antes dos mints do faucet (rand_getSupply informa genesis_staked e genesis_deposited); mais duas notes de genesis totalizando 99 zUSD, correspondendo aos 99 zUSD bloqueados em seus lastros |
Os nós de bootstrap (deploy/nodes.env):
/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQA chain 20 roda com as chaves de validador que as chains 14 a 19 usaram, portanto estes peer ids não mudaram desde a rotação de chaves da chain 14.
O explorador em randscan.org indexa a chain 20 e serve uma API REST em https://randscan.org/api/v1 (API do explorador). O JSON-RPC do nó completo escuta em 127.0.0.1:8545 por padrão; execute um nó (Executando um nó), use um em que você confie, ou use o endpoint público https://rpc.randprotocol.org (rand --rpc https://rpc.randprotocol.org …). O endpoint público serve tudo de que uma carteira precisa, inclusive a primeira sincronização e o envio de transações, sob um limite de 1.200 leituras e 6 envios por minuto por endereço. Ele não serve o faucet.
Obtendo RAND no faucet
O faucet é um tipo de transação: um validador cunha uma note de valor público para um endereço shielded, e a note só pode ser aberta pelo titular do endereço. Na chain 20 ele paga apenas os 16 endereços da allowlist do genesis: um mint para qualquer outro endereço é recusado com the faucet may not mint to this recipient (not in staking.faucet_recipients), de modo que uma carteira que não esteja nela obtém RAND de teste recebendo um envio. Qualquer um dos três caminhos abaixo pede um mint a um nó validador; os observadores respondem faucet mints are signed by validators; ask a validator node, e o endpoint RPC público não encaminha rand_mint de forma alguma.
Com a carteira rand, apontada para o RPC de um validador:
rand keygen # writes wallet.key.json; refuses to overwrite
rand address # the rand1… address on stdout (about 1,665 characters), its fingerprint on stderr
rand faucet # an allowlisted wallet: 100 RAND into a note only it can open
rand balance # scans the tree with this key; prints 100 RANDrand faucet [ADDRESS] --amount <RAND> cunha para outro endereço ou um valor menor; 100 RAND é tanto o padrão quanto o limite por chamada. Via JSON-RPC, a mesma requisição é rand_mint:
curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"rand_mint","params":["rand1…", "100000000000"]}'O resultado é o hash da transação de mint; consulte rand_getTransaction até que ela retorne um bloco. Os valores são strings de unidades, e 1 RAND equivale a 10⁹ unidades. Os aplicativos de carteira têm o mesmo faucet em um toque; envie a partir deles com a Rand Wallet v0.6.8 ou posterior, a primeira versão para a chain 20. A página do faucet deste site recebe pedidos da lista de espera para concessões na devnet.
Um mint tem valor público on-chain: a visibilidade de um salto que qualquer depósito de transparente para shielded tem. O que a note vale, e para quem, depois disso fica oculto como em qualquer outra note.
Para onde ir a seguir
- Contas e endereços: os dois tipos de chaves, o que é um endereço
rand1…e por que o endereço de 54 caracteres da chain 11 foi revertido. - Notes e a árvore de compromissos, Transações e ações, Taxas, Consenso e finalidade, Oferta: o modelo.
- Criptografia e Provas: as primitivas, os parâmetros do STARK, como um bundle é provado e verificado.
- Tokens e Implantar um token RPL: o padrão RPL, um token como entrada de registro com um id
rpl1…, e a criação de um a partir da carteira. - Programas: implantar e chamar um programa confidencial, e o que ainda não é possível.
- Bridge, Mint e burn, Staking, Executar um node.
- Escrever um programa em Rust ou C: o guia completo, do desenho das entradas e saídas de um programa até um leilão de lance selado escrito nas duas linguagens, o orçamento de prova, a implantação e a verificação de uma chamada.
- Quatro programas de exemplo: aplicações completas, cada uma executada na testnet: uma votação anônima sobre uma lista de permissão Keccak, uma prova de passivos sobre uma árvore de somas SHA-256, um ledger fora da cadeia cujo estado é transportado entre chamadas, e uma decisão de crédito privada a partir de um modelo publicado.
- A ISA RISC-V, Implantar um programa Rust, Implantar um programa RISC-V: como compilar e implantar seus próprios programas com a toolchain
rand-guest. - O transpilador Solana e O transpilador Ethereum: SPL Token e um ERC-20, traduzidos para RISC-V e comparados palavra por palavra com os interpretadores.
- Executar um validator e um aggregator: RAM, CPU e disco para cada função, e os limites medidos de memória de prova.
- Desenvolvedores: os repositórios, a stack, os marcos do zkVM, o que está especificado mas não foi entregue, e como compilar, testar e contribuir.
- JSON-RPC, Linha de comando, API do explorer: as referências.
O diretório docs/ do próprio repositório do fullnode é a fonte com a qual estas páginas são conferidas, e os papers trazem o embasamento criptográfico.