Lee esta página para decidir con qué construir y por dónde empezar: el modelo de la cadena en pocos párrafos, los parámetros de la testnet activa, cómo obtener RAND de prueba y un mapa del resto de la documentación.
Qué es Rand Protocol
Rand es una cadena protegida poscuántica. Su moneda nativa es RAND, y RAND vive en un pool totalmente protegido: no hay cuentas ni saldos en la cadena, solo compromisos de notas y anuladores, y una transferencia es una prueba de conocimiento cero de que cuatro notas se convirtieron en otras cuatro (las notas ficticias ocupan las ranuras sin usar), sin mostrar qué activo se movió. RAND y todo token del estándar propio de la cadena, RPL, comparten ese único pool. La misma moneda paga los programas confidenciales: programas RISC-V que se ejecutan fuera de la cadena dentro de una máquina virtual de conocimiento cero y se liquidan en la cadena con una prueba en lugar de sus entradas.
Cada primitiva se elige para resistir a un adversario cuántico:
| capa | qué se ejecuta |
|---|---|
| Firmas | Dilithium2 (basada en retículos). Los validadores firman con ella los bloques y los votos; el faucet, las acciones de staking y los registros del puente también se firman con ella. Una billetera nunca firma una transacción: un paquete se autoriza por sí mismo mediante su prueba. |
| Cifrado de notas | Encapsulación de claves ML-KEM-768 más ChaCha20-Poly1305. Cada nota en la cadena va acompañada de un sobre que solo su propietario (y su remitente) puede abrir. |
| Hash | BLAKE3 con separación de dominios para direcciones, identificadores de transacción, la raíz de estado y todo lo demás que queda fuera del sistema de pruebas; Poseidon2 sobre el cuerpo Goldilocks para notas, anuladores, el árbol de compromisos y todo lo que ocurre dentro de una prueba. |
| Pruebas | Un STARK por lotes de Plonky3 con FRI con ocultamiento (80 consultas, blowup 8, 20 bits de prueba de trabajo). Transparente: sin configuración de confianza, sin curva de emparejamiento, y el supuesto es una función hash resistente a colisiones. |
| Computación confidencial | La zkVM de Rand, una máquina RV32IM demostrada bajo ese STARK. Un programa se identifica por un resumen dentro del circuito, y el verificador nunca ve una sola palabra de instrucción. |
| Consenso | HotStuff BFT encadenado: quórums ponderados por stake de más de dos tercios, líderes rotativos por turnos, una regla de confirmación de tres vistas consecutivas. |
| Almacenamiento y red | Una RocksDB por nodo con confirmaciones sincronizadas con fsync y una comprobación de integridad al arrancar; libp2p (TCP, Noise, Yamux, gossipsub, Kademlia, mDNS en redes locales). |
La implementación de referencia es randprotocol/fullnode, en Rust: el binario rand-node es el nodo, el binario rand es la billetera, y los métodos JSON-RPC llevan el prefijo rand_. El explorador es randscan.org.
La testnet: cadena 20
La flota pública ejecuta la cadena 20, activa desde el 2026-10-01 06:17 UTC con fullnode v0.6.8. Las cadenas 15 a 19 están retiradas. Se cortaron cuatro cadenas en cuatro días, cada una por un cambio que altera todas las pruebas o el formato de las transacciones:
- Cadena 16 (2026-09-28, fullnode v0.6.1) llevó la zkVM al conjunto de restricciones 7, que oculta lo que una prueba antes revelaba sobre las entradas privadas pequeñas, y activó las reglas
hardening_v6. - Cadena 17 (2026-09-29, v0.6.3) separó la autorización de una transferencia de su prueba: cada paquete lleva una segunda prueba, pequeña, hecha con la clave de gasto, de modo que la grande pueda generarla una máquina que solo posea una clave de visualización.
- Cadena 18 (2026-09-29, v0.6.7) mide las llamadas confidenciales en gas (conjunto de restricciones 8) y activa el memo cifrado en cada sobre de nota.
- Cadena 20 (2026-10-01, v0.6.8) vincula cada prueba y cada mensaje firmado al hash del génesis, añade estado de programa (RPL-2), cobra una comisión en las acuñaciones y quemas de zUSD del puente, y activa las reglas audit-v6 enumeradas en la tabla siguiente.
La cadena 19 (2026-10-01 03:43 UTC, v0.6.7) fue un nuevo génesis de la cadena 18 sobre la misma compilación y no cambió ninguna regla. La cadena 18 se detuvo en la altura 143.776, y la cadena 19 se cortó a partir de una instantánea en la altura 141.935. Su génesis difería del de la cadena 18 solo en el identificador de cadena, la marca de tiempo, las notas trasladadas y la sección del puente: nuevos emisores para los endpoints de Ethereum, Binance Smart Chain y Tron, y los contadores de secuencia trasladados.
La cadena 20 es una bifurcación dura de la cadena 19: su génesis se cortó a partir de una instantánea de la cadena 19 en la altura 7.258, la cadena 19 se detuvo en la altura 7.700, y los 26 validadores se reiniciaron juntos en la cadena 20, con las mismas claves, los mismos identificadores de par y los mismos nodos de arranque. La cadena 19 y la cadena 18 están retiradas. Una billetera necesita v0.6.8 para enviar en la cadena 20: las pruebas y las firmas de una billetera más antigua no llevan el vínculo con el génesis, y la cadena las rechaza.
Cada una es una cadena nueva. Los saldos de RAND en las billeteras del operador y el zUSD en circulación se trasladaron al siguiente génesis, y nada más: un programa desplegado en una cadena no existe en la siguiente. Es software experimental: no auditado, y RAND en ella no tiene valor.
Los programas en la cadena 20 pueden mantener estado: las celdas de programa de RPL-2, las bóvedas de programa y la acción Invoke están activas.
| chain id | 20 (rand_chainId) |
| genesis hash | 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 |
| genesis file | deploy/genesis-chain20.json en el repositorio del fullnode |
| build | fullnode v0.6.8 (tag c9c9bd3c); un nodo informa su propio build en rand_getVersion. Este build rechaza las chains 14 a 17, y una wallet anterior a v0.6.8 no puede enviar en la chain 20 |
| genesis binding | binding_domain 1: el vínculo de la prueba de cada bundle y cada mensaje de acción firmado incluyen el genesis hash, de modo que nada probado ni firmado para una chain se verifica en otra |
| testnet marker | testnet true: el genesis se declara a sí mismo una red de prueba, lo que permite que un faucet funcione junto al bridge |
| validadores | 26, cada uno con 1,000 RAND en stake, el mínimo de staking |
| quórum | 18 de 26: estrictamente más de dos tercios del stake |
| intervalo de bloque | el valor por defecto --block-interval-ms 1000; aproximadamente un bloque por segundo |
| tiempo de bloque | un timestamp más de 60 s posterior al de su bloque padre es inválido, y un validador no vota por un bloque con más de 15 s de adelanto respecto de su propio reloj, por lo que los validadores ejecutan NTP |
| ventana de prueba | proof_window_blocks 1,024: el ancla de un bundle debe ser una de las últimas 1,024 raíces de fin de bloque, y su time no puede ser más antiguo que eso (256 bloques en las chains 18 y 19) |
| épocas | 1,000 bloques; un nuevo bond espera dos épocas adicionales antes de contar (bond_activation_epochs 2, que se activa en la época e + 3), y el stake desvinculado se libera dos épocas después |
| staking | los registros son v2 (rand-node register --v2), y una clave nueva se registra solo después de que validadores que posean más de dos tercios del peso la voten a favor (admission_by_vote); el peso de un validador está limitado a 33.33 %; el nuevo stake que entra en un límite de época está limitado a 25 % del peso activo (max_stake_entry_bps_per_epoch 2,500); sin slashing |
| zkVM | conjunto de restricciones 8, perfil FRI de producción (80 consultas) |
| bundle guest | hc_bundle 60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce: el bundle de activos ocultos de 4 entradas y 4 salidas, versión 3, tier 14 |
| auth guest | hc_auth 1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1: la autorización de gasto que lleva cada bundle, tier 10 |
| gas | una llamada declara un límite de gas que el circuito hace cumplir y paga gas_price por él: 100 unidades por gas y 800 unidades por KiB en el piso, ambos moviéndose por bloque hacia un objetivo de 262,144 de gas y 10,485,760 bytes, y nunca por encima de los techos de 10,000 por gas y 80,000 por KiB. Solo los bytes sobre los que se cobra el precio por byte (la prueba y el sobre de entrada de una llamada) cuentan para la carga de bytes (byte_load: "paying"), de modo que un bloque de transferencias no la eleva. Cada bundle declara el límite fijado 20,479 y paga la tarifa fija de 0.001 RAND |
| estado de programa | RPL-2 activado: celdas de programa, bóvedas de programa e Invoke (Action 33); crear una celda cuesta 0.01 RAND (cell_fee 10,000,000 unidades); un invoke lee como máximo 8 celdas, escribe como máximo 8 y realiza como máximo 4 pagos (rand_getLimits.program_state) |
| sobre de nota | envelope_bytes 1860: el sobre de cada nota es de 1,860 bytes y lleva un memo cifrado |
| límite de programa | max_program_words 65,535, pero bajo hardening_v6 se rechaza un deploy que ninguna llamada de tier 14 podría contener (ProgramUncallable): 8,180 palabras para un programa sin segmento público |
| límite de prueba | max_proof_bytes 4,194,304 (4 MiB); era de 8 MiB en las chains 13 a 16 |
| límite de bloque | max_block_bytes 20,971,520 (20 MiB) |
| límite del sobre de llamada | max_call_envelope_bytes 65,536 |
| entrada pública por programa | max_program_public_words 32,768, fijado en el deploy |
| faucet | activado, pero solo para las 16 wallets de la lista de permitidos del genesis (staking.faucet_recipients), y solo desde los 18 validadores que el genesis nombra como minters (staking.faucet_minters): hasta 100 RAND por llamada, 10,000 RAND por época en total |
| cómputo confidencial | activado; la prueba de una llamada está limitada al tier 14. Los programas no se conservan a través de un corte; los programas de ejemplo indican en qué chain está desplegado cada uno |
| tokens | el registro RPL está activado: tarifa de registro de 1 RAND, quemada; como máximo 4,096 tokens; todo valor de nota por debajo de 2⁶³. zUSD figura en el genesis en el índice 1 |
| bridge | activado: conjunto de guardianes 1 con ocho guardianes, ocho guardianes PQ Dilithium2, una clave de pausa, emisores para cuatro chains de origen, un límite diario de mint de 100,000 zUSD por respaldo y un límite global de 4,000 zUSD por 24 horas móviles entre todos los respaldos. zUSD tiene siete respaldos; su suministro es lo que esté bloqueado, leído en vivo de rand_getTokenSupply. Desde la chain 20 se cobra una comisión de 10 bps en cada mint y cada burn, en zUSD, como una nota a una dirección de tesorería (bridge.fees): un depósito acredita el monto bruto menos la comisión, y un burn libera amount − fee en la chain de origen. Una rotación de los guardianes PQ o de la clave de pausa lleva la firma propia de cada nueva clave y entra en vigor 86,400 s después de ser aceptada (bridge.rotation) |
| historial | 24 validadores conservan 24 horas de bloques (--prune-history 24h) y responden -32010 por debajo de ese punto; dos nodos de archivo conservan todos los bloques, y el RPC público https://rpc.randprotocol.org reenvía a un archivo |
| agregación de bloques | desactivada (sin sección aggregation en el genesis; el build se niega a iniciar con un genesis que la tenga) |
| valor del genesis | 26,000 RAND en stake en el registro de validadores más siete notas de depósito que suman 5,184.243719258 RAND, traídas de las wallets del operador en la chain 19: 31,184.243719258 RAND, antes de los mints del faucet (rand_getSupply informa genesis_staked y genesis_deposited); más dos notas del genesis que suman 99 zUSD, equivalentes a los 99 zUSD bloqueados en sus respaldos |
Los nodos de arranque (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/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQLa chain 20 se ejecuta con las claves de validador que usaron las chains 14 a 19, por lo que estos peer ids no han cambiado desde la rotación de claves de la chain 14.
El explorador en randscan.org indexa la chain 20 y ofrece una API REST en https://randscan.org/api/v1 (API del explorador). El JSON-RPC del full node se enlaza por defecto a 127.0.0.1:8545; ejecute un nodo (Ejecutar un nodo), use uno de su confianza, o use el endpoint público https://rpc.randprotocol.org (rand --rpc https://rpc.randprotocol.org …). El endpoint público sirve todo lo que necesita una wallet, incluida su primera sincronización y el envío de transacciones, con un límite de 1,200 lecturas y 6 envíos por minuto por dirección. No sirve el faucet.
Obtener RAND del faucet
El faucet es un tipo de transacción: un validador acuña una nota de un monto público hacia una dirección protegida, y la nota solo puede ser abierta por el titular de la dirección. En la chain 20 solo paga a las 16 direcciones de la lista de permitidos del genesis: un mint a cualquier otra dirección es rechazado con the faucet may not mint to this recipient (not in staking.faucet_recipients), de modo que una wallet que no figure en ella obtiene RAND de prueba cuando se le envía. Cualquiera de las tres vías siguientes solicita un mint a un nodo validador; los observadores responden faucet mints are signed by validators; ask a validator node, y el endpoint RPC público no reenvía rand_mint en absoluto.
Con la wallet rand, apuntando al RPC de un 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> acuña a otra dirección o una cantidad menor; 100 RAND es tanto el valor por defecto como el límite por llamada. Por JSON-RPC la misma solicitud es 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"]}'El resultado es el hash de la transacción de mint; consulte rand_getTransaction hasta que devuelva un bloque. Los montos son cadenas de unidades, y 1 RAND son 10⁹ unidades. Las apps de wallet tienen el mismo faucet en un solo toque; envíe desde ellas con Rand Wallet v0.6.8 o posterior, la primera versión para la chain 20. La página del faucet de este sitio recibe solicitudes de lista de espera para donaciones en devnet.
El monto de un mint es público en la chain: la visibilidad de un salto que tiene todo depósito de transparente a protegido. Cuánto vale la nota y para quién después queda oculto, como cualquier otra nota.
Dónde continuar
- Cuentas y direcciones: los dos tipos de claves, qué es una dirección
rand1…y por qué se revirtió la dirección de 54 caracteres de la chain 11. - Notes y el árbol de compromisos, Transacciones y acciones, Comisiones, Consenso y finalidad, Suministro: el modelo.
- Criptografía y Pruebas: las primitivas, los parámetros de STARK, cómo se prueba y se verifica un paquete.
- Tokens y Desplegar un token RPL: el estándar RPL, un token como entrada de un registro con un id
rpl1…, y cómo crear uno desde la wallet. - Programas: desplegar y llamar a un programa confidencial, y lo que aún no es posible.
- Bridge, Acuñación y quema, Staking, Ejecutar un nodo.
- Escribir un programa en Rust o C: la guía completa, desde el diseño de las entradas y salidas de un programa hasta una subasta de oferta sellada escrita en ambos lenguajes, el presupuesto de prueba, el despliegue y la verificación de una llamada.
- Cuatro programas de ejemplo: aplicaciones completas, cada una ejecutada en la testnet: una votación anónima sobre una lista de permitidos con Keccak, una prueba de pasivos sobre un árbol de sumas SHA-256, un libro mayor fuera de la cadena cuyo estado se transmite entre llamadas, y una decisión de crédito privada a partir de un modelo publicado.
- El ISA RISC-V, Desplegar un programa en Rust, Desplegar un programa RISC-V: cómo compilar y desplegar tus propios programas con la cadena de herramientas
rand-guest. - El transpilador de Solana y El transpilador de Ethereum: SPL Token y un ERC-20, traducidos a RISC-V y contrastados palabra por palabra con los intérpretes.
- Ejecutar un validador y un agregador: RAM, CPU y disco para cada rol, y los límites medidos de memoria de prueba.
- Desarrolladores: los repositorios, el stack, los hitos de la zkVM, lo que está especificado pero no se ha entregado, y cómo compilar, probar y contribuir.
- JSON-RPC, Línea de comandos, API del explorador: las referencias.
El directorio docs/ del propio repositorio del fullnode es la fuente con la que se contrastan estas páginas, y los artículos aportan el contexto criptográfico.