Tokens RPL

Use esta página para entender qué es un token en esta cadena antes de crear uno, listar uno o indexar uno. RPL es el estándar de tokens de Rand, nuevo en la chain 14. Un token es un activo nativo blindado: una entrada en un registro del ledger, con saldos mantenidos como notas ordinarias en el mismo árbol de compromisos que usa RAND. No es un contrato. Para crear uno paso a paso, consulte Deploy an RPL token.

El motivo es estructural. Un Call escribe solo un recibo, de modo que un contrato al estilo ERC-20 no tenía dónde guardar un saldo, y una tabla pública de saldos convertiría a los tokens en el único activo transparente de una cadena blindada. RPL hace en cambio del token un objeto de primera clase del ledger. La chain 20 añade RPL-2 (v0.6.8): un programa puede mantener celdas de estado públicas y una bóveda pública, y puede ser la autoridad de acuñación de un token propio (más abajo); los saldos en manos de personas siguen siendo notas.

Un token es una entrada de registro

TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) es una tabla compartida por todos los tokens, nativos o puenteados. Es el mismo registro a través del cual el puente resuelve el índice de un activo. Cada entrada:

Los decimales se detienen en 9 porque las cantidades son u64: con 18 decimales un u64 solo admite 18,4 tokens enteros, y 9 es la precisión propia de RAND. Un token puenteado siempre se registra con 8 decimales, sea cual sea la precisión de las monedas de origen.

El registro se activa mediante una sección tokens en el archivo de génesis, igual que bridge y aggregation se activan con las suyas. Sin ella, toda acción sobre tokens se rechaza antes de cualquier otra comprobación (TokenError::Disabled). El génesis de la chain 20 tiene la sección y lista un token, zUSD, con sus siete respaldos, arrastrado desde la chain 14 a través de cada corte desde entonces; todos los demás tokens de la cadena llegan por transacción. (El génesis de la chain 14 no listaba ninguno.) Con la compuerta activada, un tokens_root (la raíz de Merkle de las hojas blake3("rand-token-leaf-1", bincode(TokenInfo)) en orden de índice) se incorpora a la raíz de estado. El dominio de esa raíz es rand-state-4 en una cadena sin nada posterior activado; la raíz de la chain 20 incluye además el estado del faucet y de la cola de bonos, los precios de gas vigentes y la raíz del estado de los programas, hashes bajo rand-state-8, y se envuelve una vez más con el conjunto de validadores admitidos (Consenso).

Una cadena con una sección tokens exige además que toda nota alloc del génesis lleve su apertura (pk, time, r), y el nodo recalcula el compromiso y rechaza un archivo que no coincida. El compromiso es del activo 0, salvo que la apertura nombre el índice de un token que el mismo génesis lista —la chain 20 tiene dos notas así, de 10 y 89 zUSD en el índice 1—, y por cada token listado las notas del génesis deben sumar lo que sus respaldos tienen inicialmente en locked. Desde que una nota tiene una palabra asset que puede nombrar un token, un compromiso de génesis sin abrir sería la única forma de introducir sin verificación en el pool una nota sin respaldo de cualquier activo.

Identificador de activo, índice y rpl1…

Un token tiene dos nombres, y el RPC proporciona ambos.

• El identificador del activo son 32 bytes, direccionados por contenido como el id de un programa. El id de un token nativo es blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt)), donde salt son 32 bytes que elige el creador e initial es la acuñación inicial completa, si la hay. El id de un token puenteado es blake3("rand-rpl-asset", bincode(name, symbol, 8, salt)). Registrar un id que ya existe se rechaza (TokenError::AlreadyRegistered).
• El índice es lo que una nota porta realmente, porque un id de 32 bytes no cabe en una palabra. Es una abreviatura que solo tiene significado en esta cadena.
• La forma textual rpl1… es bech32m (BIP-350) con parte legible por humanos rpl sobre los 32 bytes del id: 52 caracteres de datos y una suma de verificación de 6 caracteres, 62 caracteres en total. Se muestra junto al id de 64 caracteres hexadecimales dondequiera que se nombra un token y se acepta dondequiera que se busca uno; el hexadecimal sigue aceptándose. El análisis es estricto: una suma de verificación errónea, un prefijo equivocado, una carga que no sea exactamente de 32 bytes o el uso mixto de mayúsculas y minúsculas se rechazan, de modo que un error tipográfico no pueda resolverse a un token distinto.

Los símbolos no son únicos. Como con ERC-20 y SPL, la identidad de un token es su identificador de activo, nunca su nombre ni su ticker.

El antiguo valor por (chain, token) que calcula rand_bridgeAssetId y que rand_getAssets imprime por cada fila de respaldo es un identificador más acotado, propio del formato de transmisión del puente, no el id del token en sí.

Autoridades de acuñación

Un RegisterToken que nombre Bridge se rechaza (TokenError::AuthorityNotAllowed), como también uno que nombre Program con una acuñación inicial o en una cadena sin program_state. Una autoridad Key es exactamente una clave pública Dilithium2: una clave de cualquier otra longitud en bytes se rechaza (TokenError::BadAuthorityKey), y la clave ML-KEM del destinatario en una acuñación se somete a su longitud de la misma manera. Ambas son estado de consenso o espacio de bloque comprado a una comisión fija, de modo que ninguna puede ser arbitrariamente grande.

Crear un token

La creación no requiere permisos. Action::RegisterToken { name, symbol, decimals, authority, initial, salt, index } viaja en un bundle de comisión ordinario en RAND y paga BUNDLE_BASE más la registration_fee del registro. La comisión de registro es un parámetro de génesis acotado entre 1 RAND y 10.000 RAND, de modo que un token de spam siempre cuesta algo. En la chain 20 es de 1 RAND, así que un registro cuesta 1,001 RAND, y la chain 20 la quema, como toda cadena desde la 15: el proponente conserva solo la base del bundle (más abajo).

index nombra el índice del registro para el que el creador selló la nota inicial. Si otro registro tomó antes ese índice, la transacción se rechaza (TokenError::IndexMismatch) en lugar de dejar la nota varada; el creador vuelve a generar la prueba para el siguiente índice.

La nota acuñada la calcula la cadena, no la elige quien envía: note_commitment(recipient.pk, MINT_FROM, amount, index, time, r). La cantidad y la pk del destinatario son públicas en la transmisión, de modo que el destinatario puede reconstruir la nota a partir de los propios campos de la transacción aunque el sobre sellado sea basura. Un depósito por el puente tiene la misma defensa.

Por qué el id enlaza toda la acuñación inicial

Un RegisterToken no está firmado. El enlace de la transacción impide que una copia con prueba sea alterada, pero no dice nada sobre lo que puede nombrar una copia nueva. Si el id cubriera solo la cantidad inicial, un observador de un registro pendiente podría enviar una copia con otro destinatario, registrarla bajo el mismo id y quedarse con todo el suministro de un token de suministro fijo al confirmarla primero. Como el id cubre toda la acuñación inicial (cantidad, destinatario, r, time y sobre), una copia redirigida produce un hash que corresponde a un identificador de activo distinto: un token diferente con el mismo símbolo, algo que un símbolo no único ya permite. El original aún se confirma en el siguiente índice al costo de una nueva prueba.

Las transferencias son el mismo bundle que RAND

Desde la chain 14 toda transacción que mueve valor lleva exactamente un bundle, la forma fija de 4 entradas y 4 salidas con activo oculto (Transacciones y acciones). Las ranuras 0–1 llevan un activo privado, RAND o cualquier token RPL, y el circuito nunca sabe cuál. Las ranuras 2–3 llevan siempre RAND. Una transferencia de cualquier activo es Action::None, la acción que usa un pago ordinario en RAND. No existe una acción de transferencia de tokens ni un campo público que nombre el token.

Lo que ve un observador de una transferencia de token es exactamente lo que publica un pago en RAND: un ancla, cuatro nullifiers, cuatro compromisos, la comisión fee en RAND, burn_a = burn_r = burn_asset = 0, un time, cuatro cifrados de sobre y la prueba del paquete. Desde la cadena 17 (autorización dividida), cada paquete lleva además un auth_commit y una segunda prueba de autorización, más pequeña, igualmente idéntica para todos los activos. En la cadena 20 cada sobre ocupa exactamente 1860 bytes y tiene espacio para un memo cifrado (rand send --memo), se envíe o no. No ve el remitente, el destinatario, el monto, qué activo se movió, qué ranuras eran señuelos ni el cambio.

La wallet gasta hasta dos notas del token en las ranuras 0–1 y hasta dos notas de RAND en las ranuras 2–3 para la comisión. La comisión siempre es en RAND, de modo que un titular con un token y sin RAND es rechazado antes de generar la prueba. El costo es el mismo que el de un pago en RAND (Comisiones). En la cadena 20 son dos pruebas STARK generadas en la máquina del remitente: la autorización de gasto (nivel 10, unos 7 s, unos 1,37 MB) y el paquete (nivel 14, unos 100 s, unos 1,5 MB), unos 2,85 MB en total por la red. Cada una queda por debajo del límite de 4 MiB por prueba de la cadena. Antes de la cadena 17, una transferencia llevaba solo la prueba del paquete, de unos 1,42 MB según la medición de entonces.

Acuñación y la autoridad

TokenMint { asset, amount, recipient, r, time, envelope, nonce, signature } acuña más unidades de un token autorizado por Key. SetAuthority { asset, new, nonce, signature } entrega la autoridad a otra clave, o la renuncia cuando new está ausente; tras una renuncia ninguna clave podrá volver a acuñar el token. Cualquiera de las dos acciones sobre un token cuya autoridad no sea Key es rechazada (TokenError::NotKeyAuthority).

La autoridad firma blake3("rand-rpl-mint-1" | "rand-rpl-authority-1", chain_id ‖ asset_id ‖ nonce ‖ body). nonce debe ser igual al mint_nonce del token, que a continuación se incrementa, de modo que una acuñación firmada no puede reproducirse en esta cadena ni trasladarse a otra. El body de una acuñación incluye el digest del sobre: el compromiso por sí solo no lo cubre, y sin el digest un tercero podría reenvolver una acuñación difundida con un sobre basura y consumir el nonce.

Ambas acciones viajan en un paquete de comisión en RAND que paga BUNDLE_BASE. La wallet que paga la comisión y la clave que autoriza la acuñación son independientes y pueden pertenecer a personas distintas.

Quema

Action::TokenBurn { asset, amount } viaja en el mismo paquete único: el burn_asset del paquete debe ser igual a asset, burn_a debe ser igual a amount y burn_r es 0. El token sale del pool por las ranuras de activo y la comisión en RAND por las ranuras 2–3 de la misma prueba. total_supply disminuye exactamente en amount. Un token con autoridad Bridge es rechazado aquí (TokenError::BridgedToken); sale mediante una quema de bridge.

Comisiones

Toda acción RPL se paga en RAND.

El génesis de la cadena 20 tiene una sección gas, y fija precios solo para las llamadas e invocaciones de programas. Estos mínimos son fijos: ninguna acción RPL paga por gas ni por byte.

Qué es público y qué permanece oculto

Por tanto, total_supply siempre es auditable: es lo que sumaron el registro y cada acuñación, menos cada quema. Una transferencia entre titulares no revela nada, ni siquiera que cambió de manos un token y no RAND.

La divulgación funciona como en RAND. El texto plano de la nota incluye el activo, de modo que una clave por transacción (rand tx-key <hash>) o una clave de visualización abre una nota de token exactamente como abre una de RAND, y rand_checkTransaction y rand_getViewingNotes devuelven asset en la nota que divulgan. Dada una de esas claves, randscan resuelve el índice contra el registro y muestra la transferencia como el token con su nombre; la página pública de la misma transacción no muestra nada de eso.

Tokens con puente

Un token de autoridad Bridge sigue siendo un token RPL: la misma entrada del registro, la misma transferencia oculta, la misma mecánica de quema. Su suministro solo se mueve mediante un bloqueo en una cadena de origen (BridgeAttest) o una liberación (BridgeBurn). Un mismo token con puente puede tener muchos respaldos, cada uno un par (chain, token) con sus propios decimales de origen, monto bloqueado y tope de acuñación, y total_supply siempre es igual a la suma de lo que sus respaldos tienen bloqueado. Un token con puente se registra, y se añade un respaldo, solo con el quórum de los guardianes poscuánticos del bridge.

En la cadena 20, el primer token del registro es zUSD (“Shielded USD”), índice 1, 8 decimales, listado en el archivo de génesis con siete respaldos (USDT y USDC en Ethereum, Binance Smart Chain y Solana, y USDT en Tron). Conserva el id de activo que tenía en la cadena 14, donde se registró por transacción en la altura 256: las cadenas 15 a 20 lo listan cada una en el génesis con el mismo nombre, símbolo y sal. Comenzó la cadena 20 con 99 zUSD en dos notas de génesis (10 y 89), respaldados por 22 USDT bloqueados en Ethereum, 22 en Binance Smart Chain, 30 en Tron y 25 en Solana, trasladados desde el estado del bridge de la cadena 19. La cadena 19 comenzó con 10 zUSD, respaldados por 10 USDT en Solana; la cadena 18, con 9 USDT bloqueados en Tron y 1 en Solana. Su suministro total es igual a lo que sus respaldos tienen bloqueado y se mueve con cada depósito y cada reembolso. Su id es rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. Bridge trata los respaldos, las unidades de liberación, los topes de acuñación, la pausa y la cofirma.

zUSD es una cesta, no siete reclamaciones separadas. Sus respaldos se agrupan a valor nominal, de modo que un titular asume el riesgo de todos los respaldos listados, no el de la moneda que depositó: un respaldo que ha perdido su paridad puede depositarse a la par y quemarse el zUSD hacia un respaldo sólido, hasta agotar los sólidos. Lo que acota la pérdida es la ventana de acuñación móvil (en la cadena 20, 4000 zUSD entre todos los respaldos por cada 24 horas, junto a 100 000 por respaldo) y la custodia realmente bloqueada. La ventana limita el ritmo y da tiempo para pausar las acuñaciones. No limita el total. Un respaldo se lista solo con el quórum de guardianes poscuánticos, y no mientras las acuñaciones estén en pausa.

Las comisiones del bridge, en zUSD (cadena 20). El génesis de la cadena 20 fija bridge.fees: 10 bps por un depósito y 10 bps por una quema, cada una redondeada hacia abajo a una unidad de liberación entera del respaldo (100 unidades base para un USDT de 6 decimales), pagada como una nota de zUSD a una dirección de tesorería que nombra el génesis (v0.6.8, fullnode docs/bridge.md §25). Un depósito de g añade dos notas: la g − fee del depositante y la fee de la tesorería; 1 USDT de entrada son 0,999 zUSD para el depositante. Una quema de amount retiene fee como nota de la tesorería y libera amount − fee en la cadena de origen; los guardianes firman ese monto de liberación, y rand_getBridgeBurn sirve amount, release_amount y fee. Una nota de comisión se emite y está respaldada, de modo que total_supply sigue siendo igual a la suma de los locked de los respaldos: un depósito mueve ambos en g, una quema reduce ambos en amount − fee. Una nota de comisión no lleva sobre. Cada una de sus palabras es pública (el monto, por la transacción y la tasa del génesis; el activo y time; un cegado derivado del digest de la atestación o del id de transacción de la quema; el propietario, por el génesis), por lo que la wallet de la tesorería la reconstruye a partir de campos públicos (Notas). BRIDGE_BURN_FEE, los 0,01 RAND que una quema paga al proponente, no cambia. Las cadenas 14 a 19 no tenían comisión de bridge en Rand.

El registro desde la cadena 15

Desde la cadena 15, el génesis activa tres reglas de registro que la cadena 14 no tenía, y el génesis de la cadena 20 fija los mismos tres valores. Cada una está comprometida en el hash del génesis y en la raíz de tokens.

El límite de valor de las notas existe porque el circuito del bundle verifica por rango cada importe a 63 bits: una nota de 2^63 o más podría comprometerse, pero nunca gastarse, y aun así contaría en el suministro del token. Además, todo nodo rechaza ese importe en la admisión en cualquier chain, sea cual sea su génesis.

RPC y CLI

Cada importe de estos resultados (total_supply, registration_fee, el locked, mint_cap_per_day y minted_today de un respaldo) es una cadena decimal, porque un número JSON no es exacto más allá de 2⁵³. index, next_index, mint_day y max_tokens son enteros simples (max_tokens es null en una chain sin límite); burn_registration_fee y bound_note_value son booleanos. La authority de una fila es {"kind":"none"}, {"kind":"key","key","address"}, {"kind":"bridge","backings":[…]} o {"kind":"program","program"}. El detalle completo está en JSON-RPC.

Privacidad. rand_getTokens cuesta lo mismo sea cual sea el token que el llamante tenga en mente. rand_getToken y rand_getTokenSupply le indican al nodo qué token le interesa al llamante: aceptable para un explorador, inadecuado para una wallet a punto de enviar. Por eso la wallet resuelve cada --asset a partir del listado completo, y un índice numérico nunca llega al nodo.

Desde la v0.5.10, los importes de rand send --asset, rand token mint y rand token burn se expresan en las unidades de visualización del token, leídas con los decimals de su propia fila del registro: 1.5 de un token de 6 decimales son 1,500,000 de su unidad más pequeña, y se rechazan más dígitos fraccionarios de los que tiene el token. La confirmación de send imprime ambos (1.500000 USDX (1500000 units)). Los --fixed-supply y --initial de rand token create siguen aceptando unidades enteras más pequeñas, igual que rand bridge-burn, y rand asset-balance imprime en la unidad más pequeña. En la chain el importe es siempre el entero en la unidad más pequeña. Los flags y valores por defecto están en Command line.

Diferencias con ERC-20 y SPL

Límites conocidos

• Sin allowances. approve y transferFrom están diseñados en la especificación de RPL como cuentas de allowance reservadas y no están implementados.
• Las tenencias de un programa son públicas. En la chain 20 un programa puede conservar tokens en su bóveda y emitir su propio token (RPL-2), pero el saldo de una bóveda es público, como el suministro de un token; solo las notas son privadas. Las chains anteriores a la 20 no tenían ningún estado de programa.
• Las comisiones son solo en RAND. Un token no puede pagar su propia comisión; una wallet que solo tenga tokens no puede moverse.
• Importes u64 y un máximo de 9 decimales. Una moneda de origen de 18 decimales se representa con menor precisión; el puente lo resuelve con 8 decimales y una unidad de liberación por respaldo.
• Cada transferencia se prueba. Unos 100 s y varios GB de memoria en la máquina del remitente; no existe un camino más barato para un token que para RAND.
• Sin congelación, lista negra ni pausa en un token nativo, por decisión de diseño. La pausa de emisión del puente se aplica solo a las emisiones puenteadas.
• Las consultas por token filtran interés. rand_getToken, rand_getTokenSupply y el /tokens/:id del explorador le indican al servidor sobre qué token se preguntó.