Desplegar un token RPL

Esta página lleva un token desde cero hasta un activo vivo y transferible en Rand. RPL es el estándar de tokens de Rand, nuevo en la cadena 14. Si ha desplegado un ERC-20 o creado un mint de SPL, la primera sección es la que conviene leer despacio, porque un token RPL no es ninguna de esas dos cosas. Tokens RPL es la página conceptual que respalda a esta.

1. Qué es un token RPL

Un token RPL es una entrada en el registro de tokens del libro mayor, no un contrato inteligente. No hay código que escribir, compilar ni auditar. Crear un token es una sola transacción que añade una fila al registro y, a partir de ahí, las unidades del token son notas blindadas ordinarias, mantenidas en el mismo pool que RAND y gastadas de la misma forma.

Los símbolos no son únicos. Cualquiera puede crear un token llamado USDC, igual que en Ethereum y Solana. La identidad de un token es su asset id, así que compruebe el id rpl1… antes de aceptar o listar un token, nunca el símbolo. La forma textual lleva suma de verificación: un id mal escrito se rechaza, no se envía a otro destino.

En qué se diferencia de ERC-20 y SPL

Lo que permanece público es el límite: el registro de un token, cada emisión y cada quema, cada una con su importe. Eso es lo que hace que el suministro total sea auditable por cualquiera. Las transferencias entre titulares no revelan nada, ni siquiera qué token se movió.

2. Antes de empezar

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 toma por defecto wallet.key.json y puede fijarse una vez como RAND_KEY; --rpc (o RAND_RPC) indica el nodo con el que comunicarse y toma por defecto http://127.0.0.1:8545. Los comandos que siguen escriben --key de forma explícita. Antes de gastar una prueba, compruebe que el nodo está en la cadena 20: el método JSON-RPC rand_chainId devuelve 20 en ella. La wallet debe ser una compilación de la cadena 20, v0.6.8: la cadena 20 vincula cada prueba y cada mensaje firmado, incluido el de una emisión de token, a su hash de génesis, por lo que un rand v0.6.7 genera pruebas y firmas que la cadena 20 rechaza.

3. Crear el token

token create toma sus importes en la unidad más pequeña del token. --fixed-supply y --initial son números enteros de unidades base: con --decimals 2, un importe de 1000000 equivale a 10,000.00 tokens. Todos los comandos posteriores (rand send --asset, rand token mint, rand token burn) toman las unidades de visualización del token desde v0.5.10, igual que los importes de RAND se expresan en RAND (1.5): la wallet lee decimals de la fila del registro del token, y se rechaza todo importe con más dígitos fraccionarios de los que tiene el token. En la cadena, un importe es siempre el entero en unidades base.

Decida primero una cosa: ¿podrán emitirse alguna vez más unidades? La respuesta queda fijada en el token al crearlo y no puede ampliarse después.

Un token de suministro fijo

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

--to es la dirección rand1… completa que recibe el suministro, por ejemplo la salida de rand address. --fixed-supply está en unidades base: 1000000 con 2 decimales son 10,000.00 EXC.

El comando lee del nodo el siguiente índice del registro y la comisión de registro, construye la nota de la emisión inicial, demuestra un bundle de comisión, envía el registro y espera al bloque. Si tiene éxito, informa del envío, luego imprime una línea con la forma index <N>, id <64 hex> (<rpl1…>), y después committed at height <H>. Anote el id rpl1…: es la identidad del token, y todos los comandos posteriores lo toman.

La comisión por defecto es la base más la comisión de registro de la cadena, 1.001 RAND en la cadena 20, de modo que no hay nada que calcular; --fee (en RAND) la aumenta. --no-wait regresa en cuanto la transacción se envía y omite la línea committed. --cuda demuestra en una GPU NVIDIA conectada, requiere una compilación con --features cuda y no recurre a la CPU.

Si se registra otro token mientras el suyo se está demostrando, ese toma el índice para el que se selló el suyo. El nodo rechaza el registro y el comando imprime another token took index N first — re-run to register at N+1, con los números reales. Un registro rechazado nunca llega a un bloque; lo que se pierde es la demostración, unos 100 segundos de trabajo. Ejecute el comando de nuevo y demostrará contra el siguiente índice.

Todo el suministro está ahora en una sola nota blindada propiedad de la dirección --to. El registro y su importe son públicos; lo que el destinatario haga después con la nota no lo es.

Un token emitible

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

Esto escribe una nueva clave Dilithium2 en exp-authority.key.json (modo 0600, se niega a sobrescribir un archivo existente) y registra el token con esa clave como su autoridad de acuñación y un suministro de cero. La salida son las mismas dos líneas que para un token de suministro fijo. Debe indicarse exactamente una de las opciones --fixed-supply y --authority-key-out.

Para acuñar una primera cantidad en la misma transacción, añada --initial y --to, que deben indicarse juntas:

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…

Mientras el registro está en curso, la clave permanece en exp-authority.key.json.pending. Se promueve a exp-authority.key.json una vez que la cadena acepta el registro, y se descarta si la cadena lo rechaza. Si la conexión falla sin que se conozca el resultado, el archivo permanece en .pending: compruebe rand token list antes de eliminarlo.

El archivo de clave es el poder de emitir el token. Manténgalo fuera de línea y con copia de seguridad; es independiente de la clave de gasto de su wallet y nunca es necesario para enviar ni recibir.

Por qué el destinatario de la primera acuñación forma parte del id

Un registro no está firmado por su creador. Cualquiera que vea el suyo esperando en la mempool puede enviar una copia, pagada con su propio paquete de comisión. Si el id del activo cubriera solo el nombre, el símbolo y la cantidad, esa copia podría indicar la dirección del copista como destinatario y llegar a un bloque primero: sería dueño del id y, en un token de suministro fijo, de todo el suministro para siempre.

Por eso el id es un hash de todo lo que contiene el registro, incluida la acuñación inicial: su cantidad, su destinatario, su aleatoriedad, su tiempo y su sobre cifrado. Una copia con un destinatario distinto produce un hash con un id de activo distinto. Es un token diferente que casualmente comparte su símbolo, que es lo único que prometió jamás un símbolo no único. Su id solo puede registrarse con su destinatario.

--salt <hex32> fija la sal de 32 bytes que también alimenta el id. Si la omite, la wallet elige una al azar. Indíquela cuando necesite que el id sea reproducible, por ejemplo para publicar el id antes de que exista el token.

Compruébelo

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 la fila del token como JSON: index, id, id_text (la forma rpl1…), name, symbol, decimals, authority, mint_nonce, total_supply y registered_at. authority es {"kind":"none"} para un token de suministro fijo y {"kind":"key","key":…,"address":…} para uno acuñable. total_supply es una cadena decimal en unidades base. token list imprime enabled, registration_fee, next_index y las filas de tokens. Ambos leen el listado completo del nodo, de modo que el nodo no sabe qué token le interesaba.

O por JSON-RPC, donde el parámetro puede ser el índice, el id hexadecimal de 64 caracteres o la 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…"]
}'

El resultado es la misma fila que imprime token info, o null si no existe tal token; un id mal formado (suma de verificación incorrecta, mayúsculas y minúsculas mezcladas, longitud errónea) produce el error -32602. rand_getTokens recibe [from_index, limit] y recorre por páginas todos los tokens registrados, y rand_getTokenSupply devuelve únicamente { total_supply, backings }. Ninguno necesita una clave. Véase JSON-RPC.

Una fila que existe hoy en la chain 20 es zUSD, el token puenteado en el índice 1. El explorador sirve el registro del nodo sin que usted necesite un nodo propio:

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

En la chain 14, el 2026-09-20, eso devolvió "registration_fee": 1000000000, "next_index": 2 y un token, abreviado aquí a su primer respaldo:

{
  "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
}

En la chain 20 la fila tiene el mismo id, id_text, nombre, símbolo y respaldos, pero zUSD figura en el génesis en lugar de registrarse en la altura 256 (registered_at 0), y su suministro comenzó en 99 zUSD: 22 bloqueados en Ethereum USDT, 22 en BSC USDT, 30 en Tron USDT y 25 en Solana USDT, heredados de la chain 19. (El de la chain 19 comenzó en 10 zUSD, todos en Solana; el de la chain 18, con 9 en Tron y 1 en Solana.) Cada fila de respaldo incluye además los campos de ventana móvil minted_in_window, mint_window_secs y mint_headroom.

La copia de registration_fee del explorador es un número JSON; el RPC propio del nodo la devuelve, como todas las cantidades, como una cadena decimal. En la chain 20, como en todas las cadenas desde la 15, el rand_getTokens del nodo incluye además max_tokens (4096), burn_registration_fee y bound_note_value (ambos true) (RPL tokens).

4. Acuñar y transferir la autoridad

Solo se puede acuñar un token con autoridad Key, y solo con esa clave.

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

--amount está en las unidades de visualización del token: 5000 de este token de 0 decimales son 5.000 unidades base, y 1.5 de un token de 6 decimales serían 1.500.000. Antes de construir una nota o una prueba, la wallet lee la fila del token y se niega si el token no está autorizado por Key o si --authority-key no es la clave que nombra el registro. Si tiene éxito, informa del envío e imprime minted <amount> (<base units> units) of asset <index> to <address>. --fee (por defecto 0,001 RAND), --no-wait y --cuda funcionan igual que en token create.

Una acuñación añade una nota para el destinatario y eleva el suministro total. La cantidad y la clave pública del destinatario viajan en claro: una acuñación es un evento público por diseño, igual que un depósito a través del puente. Cuando el destinatario mueve la nota, queda protegida (shielded) como todo lo demás. La wallet que paga la comisión (--key) y la clave que autoriza la acuñación (--authority-key) son claves distintas y pueden estar en manos de personas diferentes.

Cada acuñación se firma sobre el id de la cadena, el id del activo y un contador que mantiene el registro, y en la chain 20 también sobre el hash del génesis (rand-rpl-mint-2), de modo que una acuñación no puede reproducirse en esta cadena ni copiarse a otra, ni siquiera a una que comparta el id de cadena. set-authority está vinculado de la misma manera.

Para trasladar la autoridad a una nueva clave, o para renunciar a ella definitivamente:

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 toma un archivo de clave y entrega el token a la clave pública de ese archivo; debe indicarse exactamente una de las opciones --new-key y --renounce. El comando imprime asset <index>'s mint authority is now <public key hex>, o asset <index>'s mint authority is renounced for good. Cada una cuesta la base de 0,001 RAND y una ronda de prueba. --renounce convierte el token en un token de suministro fijo con su suministro actual. Es irreversible: una autoridad puede pasar de clave a clave o de una clave a nadie, y nada más. Un token creado con suministro fijo nunca puede pasar a ser acuñable.

5. Úselo

Enviar

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

Esto envía 250 del token en unidades de visualización: 250 EXP con 0 decimales, o 250,00 EXC (25.000 unidades base) con 2. El destinatario y la cantidad son posicionales, igual que para RAND. Antes de generar ninguna prueba, la wallet imprime una línea, to fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <symbol> (<base units> units), y pregunta send? [y/N]. Compare la huella con la del destinatario y las unidades base con lo que pretendía enviar. --yes omite la pregunta, y un script debe pasarla: sin ella, se rechaza una entrada estándar que no sea un terminal. --asset acepta el índice, el id rpl1… o el id hexadecimal de 64 caracteres, y si se omite se envía RAND. --memo <text> sella hasta 510 bytes de texto para el destinatario dentro del sobre del pago, algo que la chain 18 es la primera en permitir; nada en la cadena revela que hay un memo. --fee siempre está en RAND y por defecto es 0,001; se aplican --no-wait y --cuda. Un id se resuelve a su índice a partir del listado completo del registro del nodo, y un índice numérico nunca llega al nodo, de modo que al nodo no se le dice qué token está a punto de moverse. Es el mismo rand send que mueve RAND, y la misma generación de pruebas. La transacción publica cuatro nullifiers, cuatro compromisos, una comisión en RAND, un tiempo, cuatro sobres cifrados, la prueba del paquete y, desde la chain 17, un compromiso de autorización y su prueba, sea cual sea el activo que se movió. Un observador no puede distinguir una transferencia de token de un pago en RAND, no puede saber de qué token se trataba y no ve remitente, destinatario ni cantidad.

La comisión se paga en RAND dentro del mismo paquete, de modo que la wallet que envía debe tener algo de RAND. La wallet lo comprueba antes de empezar a generar la prueba.

Consultar un 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

El argumento es un índice del registro. Para un token, la wallet imprime asset <index> balance: <N> units, en unidades base. rand notes enumera todas las notas que la wallet ha abierto, con su índice asset. La wallet encuentra sus notas escaneando la cadena con su clave de visualización. Nada en la cadena guarda un saldo que ella pueda consultar.

Quemar

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

El activo y la cantidad son posicionales: el activo como índice, rpl1… o hexadecimal, y la cantidad en las unidades de visualización del token, tal como las lee send --asset. --fee es por defecto 0,001 RAND; se aplican --no-wait y --cuda.

Una quema destruye unidades y reduce el suministro total. Como una acuñación, es una frontera pública: la cantidad y el token son visibles, el titular no. Un token puenteado como zUSD no se quema de esta manera: token burn lo rechaza antes de generar la prueba, y sale a través de rand bridge-burn, que libera la moneda que lo respalda.

6. Verifíquelo en el explorador

randscan.org muestra a todos la parte pública de un token: su registro, sus emisiones y quemas, y su suministro total. Todos los tokens figuran en randscan.org/tokens, y la página de un token es /tokens/<rpl1…>, /tokens/<64 hex> o /tokens/<index>; randscan.org/tokens/1 es zUSD. Los mismos datos están en GET /api/v1/tokens y GET /api/v1/tokens/:id; el segundo incluye la transacción de despliegue del token y su historial de suministro, con el registro, las emisiones y las quemas (API del explorador).

La página pública de una transferencia muestra ningún activo, ningún importe y ninguna parte, porque la cadena no los tiene. Para demostrar un pago a un tercero, como un auditor, una contraparte o una casa de cambio, se le entrega una clave:

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 una fila por cada salida de esa transacción que esta billetera envió, recibió o conservó como cambio: la salida (bundle:0 a bundle:3, las cuatro ranuras del bundle), el rol, el importe (en RAND, o N (asset I) para un token) y la clave por transacción con la que se selló esa salida. Entregue la clave de la fila sent. Funciona con cualquier transacción pasada, porque la billetera recupera la clave a partir de la cadena.

Pegue una clave de transacción en la página de la transacción en randscan para abrir esa salida; el explorador resuelve el índice del activo contra el registro y muestra el token por su nombre, con sus decimales aplicados. Una clave de visualización se introduce en randscan.org/viewing. El explorador no guarda ninguna clave y no descifra nada en su servidor. Por JSON-RPC, la misma divulgación es rand_checkTransaction(hash, key). Ninguna de las dos claves puede gastar nada. Una clave de visualización no se puede retirar una vez compartida, así que conviene preferir una clave de transacción cuando solo hace falta demostrar un pago.

7. Tokens puenteados

zUSD («USD protegido») es también un token RPL, con una autoridad Bridge: sus unidades solo se emiten cuando los guardianes atestiguan un depósito de USDT o USDC en Ethereum, Binance Smart Chain, Tron o Solana, y su suministro es siempre igual a lo que está bloqueado allí. Se registró en la cadena 14 mediante una transacción en la altura 256, con el índice 1 y siete respaldos, y el génesis de cada cadena posterior, incluida la cadena 20, lo lista de nuevo con el mismo id, rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. La cadena 15 heredó los 10 zUSD que seguían en circulación cuando la cadena 14 se detuvo, las cadenas 16 a 19 comenzaron con esos mismos 10 zUSD, y la cadena 20 comenzó con los 99 zUSD en circulación en la cadena 19. En la cadena 20, el puente cobra 10 bps de cada depósito y de cada reembolso, en zUSD, a una nota de tesorería (Puente). zUSD es una cesta: sus respaldos se agrupan a valor nominal, de modo que quien lo posee asume el riesgo de todas las monedas listadas, no solo de la que depositó (Tokens RPL). Su suministro varía con cada depósito y cada reembolso; rand token info 1 o la página /tokens/1 del explorador dan la cifra actual.

Su historia en la cadena 14, una testnet anterior (comprobada en el explorador el 2026-09-20). Esta tabla es historia de la cadena 14: la cadena 14 está retirada, por lo que estas transacciones no están en el explorador de la cadena 20:

La página de la transferencia mostraba lo que muestra cualquier transferencia de token: cuatro anuladores, cuatro compromisos y una comisión, y nada que indique que se movió zUSD.

Para mostrar lo que revela una clave, las notas de la versión v0.5 del fullnode publicaron dos para esa transferencia de la cadena 14, procedentes de una billetera de demostración creada para ese fin y que no contiene nada más:

En la cadena 14, la clave de transacción abría esa salida en la página de la transferencia, y por JSON-RPC bastaba una sola llamada (comprobado el 2026-09-20). La llamada tiene la misma forma en la cadena 20 para una transacción propia; con estos valores de la cadena 14, un nodo de la cadena 20 responde null (comprobado el 2026-10-01), porque nunca tuvo esa transacción:

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

No publique nunca la clave de visualización de una billetera que utilice: muestra todo el historial de esa billetera, para siempre.

Una dirección ordinaria no puede crear un token puenteado. rand token create rechaza una autoridad Bridge, y registrar un token puenteado, o añadir una moneda detrás de uno existente, requiere un quórum firmado del conjunto de guardianes poscuánticos del puente. Un token que se llama zUSD sin eso es solo otro token con un símbolo prestado, una razón más para comprobar el id rpl1…. Los tokens puenteados siempre tienen 8 decimales en Rand.

Puente trata los depósitos, los reembolsos y el conjunto de guardianes.