Usa esta página para generar la clave adecuada para cada tarea, para analizar o validar una dirección y para saber qué revela entregar una clave a otra persona. En esta cadena no hay cuentas: un saldo es un hecho sobre un archivo de claves, nunca sobre la cadena.
Dos claves, dos tipos de dirección
| clave de nodo | clave de wallet | |
|---|---|---|
| escrita por | rand-node keygen | rand keygen |
| secreto | una semilla de 32 bytes | una clave de gasto de 256 bits |
| identidad pública | una dirección de 32 bytes, en base58, de 32 a 44 caracteres | una dirección blindada, rand1…, de 1665 o 1666 caracteres |
| firma | bloques, votos, acuñaciones del faucet, Unbond, Withdraw, un Registration y, en la cadena 20, un voto AdmitValidator; como autoridad de acuñación Key de un token, TokenMint y SetAuthority. En la cadena 20 cada uno de estos mensajes cubre además el hash de génesis (Transacciones) | nada: una transferencia se autoriza mediante sus pruebas |
| aparece en la cadena como | un proponente de bloques, una fila del registro de validadores, el acuñador de una acuñación del faucet, la autoridad key de un token | nunca en una transferencia, donde queda sellada dentro de los sobres. Se publica donde entra valor al pool con un monto público: un depósito del puente, una acuñación de token y, en la cadena 20, el pago de una invocación nombran la dirección del destinatario; la dirección de pago de un validador figura en el registro, el génesis de la cadena 20 nombra la tesorería de comisiones del puente, y desde la cadena 14 una acuñación del faucet y una nota alloc del génesis publican el pk del propietario, los primeros 32 bytes de la dirección |
| archivo | { "seed", "address", "public_key" }, modo 0600 | { "version": 2, "spend_key": "<64 hex>" }, modo 0600 |
Las dos nunca se mezclan. Los validadores se identifican con el primer tipo, y la misma forma de clave Dilithium2 sirve a la autoridad de acuñación Key de un token (rand token create --authority-key-out escribe un archivo con la forma del de rand-node keygen), a la clave de pausa del puente y a sus seis claves de guardianes poscuánticas. Las claves de atestación de los guardianes son secp256k1, con direcciones de 20 bytes al estilo de Ethereum (Puente). El valor se mantiene bajo el segundo tipo.
La dirección transparente
Una clave de nodo es una semilla de 32 bytes de la que se deriva de forma determinista un par de claves Dilithium2: una clave pública de 1312 bytes y firmas de 2420 bytes. La dirección es un hash BLAKE3 con separación de dominio de la clave pública, representado en base58:
address = blake3("rand-address" || public_key) // 32 bytes, shown as base58Los objetos firmados (votos, bloques, acuñaciones, acciones de staking) llevan la clave pública completa, de modo que un verificador comprueba blake3("rand-address" || public_key) == address en lugar de confiar en una dirección desnuda. La misma semilla produce además la identidad libp2p del nodo, una clave ed25519 obtenida de blake3("rand-p2p-identity" || seed), que es el id de par que aparece tras /p2p/ en una multiaddr de arranque.
rand-node keygen --out node.key.json # prints the address
rand-node address --key node.key.json # address, public key (hex), libp2p peer idEjemplo: EdrEC2QRQrQF64iRXxF9927jNj6RidiHHByzx5xD6F1e es uno de los validadores de la cadena 20. Las cadenas 15 a 20 reutilizan las dieciocho claves rotadas para la cadena 14, por lo que sus direcciones e ids de par no cambian y ninguna dirección ni id de par de validador de la cadena 13 sigue en uso; ocho validadores más se vincularon en la cadena 15, y los 26 figuran en el archivo de génesis desde la cadena 16 en adelante.
La dirección blindada
Una wallet es un único secreto, la clave de gasto de 256 bits sk, y todo lo demás es una derivación de ella. La derivación es Poseidon2 con una etiqueta de dominio como primera palabra absorbida (H(domain, msg)), la misma función que la zkVM calcula en el circuito:
spend key sk 256 bits, in wallet.key.json
│
├─ viewing key nk = H(NK, sk) sees the whole history; cannot spend
│ ├─ pk = H(PK, nk) the field a note names its owner by
│ ├─ nullifier(cm) = H(NF, nk, cm) what a spend publishes
│ ├─ ovk opens envelopes this wallet sent
│ └─ ML-KEM-768 decapsulation key opens envelopes sent to this wallet
└─ address rand1 + base58(pk || kem_ek)La dirección son los 32 bytes de pk seguidos de la clave de encapsulación ML-KEM-768 de 1184 bytes, en base58 tras el prefijo rand1: 1665 o 1666 caracteres (la longitud en base58 depende de los primeros bytes; aproximadamente una dirección de cada catorce es la más corta), unos 1,6 KB, y sin suma de verificación. Quien envía necesita la clave de encapsulación para sellar el sobre de la nota, y por eso está en la dirección. Es pública por diseño: cualquiera puede pagarle, y tenerla no dice nada sobre lo que contiene.
rand keygen # wallet.key.json; refuses to overwrite an existing file
rand address # rand1… on stdout, its fingerprint XXXX-XXXX-XXXX-XXXX on stderrDesde v0.5.10, rand address imprime exactamente la dirección y un salto de línea en la salida estándar, de modo que $(rand address) funciona en un script. La huella va a stderr.
El análisis, tal como lo hace ShieldedAddress::parse: se quita rand1, se decodifica en base58 y se exigen exactamente 32 + 1184 = 1216 bytes; los primeros 32 son pk como ocho palabras u32 en little-endian, y el resto es la clave de encapsulación. El RPC rechaza cualquier parámetro de más de 2000 caracteres antes de analizarlo.
Junto al archivo de claves, la wallet conserva <key>.key.json.notes.json, una caché de las notas que esta clave ha abierto. Contiene los textos planos de las notas, por lo que se escribe en modo 0600 como la clave; cada fila se puede recuperar volviendo a escanear desde la hoja 0.
Compartir una dirección: la huella y los enlaces randpay:
Una dirección es demasiado larga para leerla en voz alta o compararla a simple vista y no lleva suma de verificación, así que desde v0.5.10 toda wallet muestra una huella junto a ella. La huella es solo para mostrar: nada en la cadena ni en la red lleva una.
fingerprint = first 80 bits of blake3("rand-address-fingerprint-1" || pk_bytes || kem_ek)
= 16 Crockford base32 characters, shown as XXXX-XXXX-XXXX-XXXXEl hash se calcula sobre los 1216 bytes en bruto que codifica la dirección. El alfabeto es 0123456789ABCDEFGHJKMNPQRSTVWXYZ; el análisis ignora mayúsculas y guiones, y lee O como 0 e I o L como 1.
Un enlace randpay: lleva una dirección y, opcionalmente, qué pagarle:
randpay:<rand1…>[?amount=<decimal>][&asset=<index | 64 hex | rpl1…>][&memo=<percent-encoded UTF-8>]amount está en las unidades de visualización del activo (RAND decimal con nueve decimales, un token con los decimals propios de su fila del registro) y no puede ser cero. memo tiene como máximo 510 bytes de UTF-8. El esquema se reconoce sin distinguir mayúsculas; un parámetro desconocido, uno repetido o una codificación porcentual incorrecta se rechazan.
rand address --uri --amount 1.5 --memo "invoice #42" --qr # a randpay: link, as a terminal QR
rand contacts add alice rand1q9f… # shows the fingerprint, asks add? [y/N]
rand send alice 1.5 --memo "coffee" # to a contact, with a memorand send <TO> acepta una dirección rand1…, un enlace randpay: o el nombre de un contacto guardado, probados en ese orden. El amount, el asset y el memo de un enlace completan lo que la línea de comandos deja sin indicar, y un valor dado de ambas formas que no coincida se rechaza. Antes de generar la prueba, send imprime to <contact, if any> · fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <asset> y pide confirmación; un script pasa --yes. Los contactos se guardan junto a la clave en <key>.contacts.json, modo 0600. El memo viaja dentro del sobre de la nota (Notas).
No existe rand balance <address> ni un RPC de saldo: la cadena no puede responderlo para nadie. Una wallet calcula su saldo escaneando todos los sobres de la cadena con su clave de visualización (Notas).
Claves que puedes entregar a otra persona
La divulgación es una propiedad de las claves, y la cadena no puede forzar nada de ella.
| clave | abre | granularidad |
|---|---|---|
la clave de visualización nk (64 hex) | todas las notas que la wallet haya recibido y, mediante ovk, todas las que haya enviado, con el nullifier de cada gasto | todo o nada, retroactiva y prospectiva |
una clave de transacción TxKey (32 bytes) | exactamente el sobre que selló: la nota y, desde la cadena 18, su memo | un pago |
una clave de llamada K_call | la transcripción de entradas privadas de una llamada confidencial | una llamada |
Una clave de visualización no puede gastar. Desde la cadena 17 (autorización dividida) la prueba del paquete se genera a partir de nk, y cada paquete lleva además una segunda prueba de autorización, pequeña, que solo la clave de gasto puede producir y que queda ligada a la transacción concreta (Notas). Eso permite entregar nk a un probador delegado, y con ello todo el historial de la wallet, sin que pueda gastar; la wallet siempre genera la prueba de autorización en su propia máquina. Las direcciones, las claves y las notas existentes no cambian con la división. La wallet deriva nk en cada ejecución y nunca la almacena; cada TxKey se genera nueva para cada sobre y se descarta tras sellarlo. A un nodo se le puede entregar una clave de visualización con rand_importViewingKey (en memoria, como máximo 64 por nodo, se pierde al reiniciar) para que escanee en nombre del titular —el camino del explorador—, y rand_checkTransaction(hash, key) comprueba un pago contra una TxKey en una sola llamada sin estado. rand viewing-key imprime nk, y rand tx-key <hash> imprime la clave de cada salida de una transacción que esta wallet puede abrir.
Los ids de token no son direcciones
Un token RPL tiene un tercer tipo de identificador de texto, y nombra un token, nunca a un titular. El id de activo de 32 bytes del token se muestra como 64 caracteres hexadecimales y como rpl1…: bech32m (BIP-350) con la parte legible rpl sobre los 32 bytes del id, 52 caracteres de datos más una suma de verificación de 6 caracteres, 62 caracteres. El análisis es estricto: una suma de verificación incorrecta, otra parte legible, una carga que no sea exactamente de 32 bytes o el uso mezclado de mayúsculas y minúsculas se rechazan, de modo que un error tipográfico nunca resuelve a un token distinto. Una nota no lleva el id; su palabra asset es el índice denso del token en el registro (Tokens RPL).
El destinatario del puente
El formato de red del puente tiene una ranura de destinatario de 32 bytes, y una dirección blindada no cabe en ella. Hoy la ranura lleva un hash de la dirección:
recipient_hash = blake3("rand-shielded-recipient" || pk_bytes || kem_ek)El depositante en la cadena de origen nombra el hash, los guardianes lo firman, y la transacción BridgeAttest lleva la dirección completa para que el libro mayor la compruebe contra él (Puente).
La dirección blindada corta: probada en la cadena 11, revertida
La cadena 11 (etiqueta de fullnode v0.2, 2026-09-17) sustituyó la dirección larga por un receiver id de 53 a 55 caracteres, rand1 + base58(blake3(receiver signing key) ‖ checksum), y trasladó la clave de encapsulación ML-KEM a un receiver record firmado, que el remitente obtenía del registro del explorador o recibía en línea dentro de una solicitud de pago. Estuvo en funcionamiento un día y se revirtió el mismo día (fullnode 17db41d); la cadena 12 volvió a la dirección larga, exactamente como se describió más arriba, y todas las cadenas posteriores, incluida la cadena 20, la conservan.
Por qué se retiró. Un receiver id es un hash, y un remitente no puede sellar una note para un hash. El primer pago a una wallet que nunca se había registrado exigía que el receptor entregara una solicitud de pago o un archivo de record, y el propio registro se pagaba con una autotransferencia, que una wallet nueva y vacía no puede realizar. Además, ambas vías de entrega revelaban al registro quién estaba a punto de recibir un pago. El diseño que conserva una dirección corta, la capacidad de envío incondicional y la privacidad criptográfica es una dirección híbrida: una clave X25519 de 32 bytes en línea (unos 93 caracteres) y la clave poscuántica por consulta, de modo que el primer pago a una wallet no registrada sea confidencial frente a adversarios clásicos y todos los posteriores sean totalmente poscuánticos. Eso se especifica a continuación; hasta que se publique, la dirección larga es la dirección.
La especificación de la cadena 11 y su implementación permanecen en el historial del fullnode (docs/superpowers/specs/2026-09-17-short-shielded-address.md, etiqueta v0.2) por las partes que reutiliza el diseño híbrido: la clave de firma del receptor derivada, el record firmado y su verificador, y el registro como estado de la cadena.