Acuñación y quema

Use esta página para ejecutar un faucet contra una cadena de prueba, para entender qué es una transacción Mint en la red y para ver con exactitud cómo un bono o una quema de puente saca valor del pool. Toda entrada y toda salida es pública; todo lo que hay entre ambas es una nota.

El mint del faucet

Un Mint es la única forma de crear RAND después del génesis en la chain 20, y existe solo en las cadenas cuyo génesis dice "faucet": true. Es una transacción firmada por un validador y sin bundle:

Action::Mint { cm: Word8, pk: Word8, time: u32, r: Word8, envelope: Envelope, amount: u64,
               minter: PublicKey, signature: Signature }

rand_mint(address[, amount]) en un nodo validador construye una nota de amount para la dirección rand1… indicada, sella su sobre con una clave de remitente desechable, firma el mint con la propia clave Dilithium2 del nodo y lo envía por el mempool normal, de modo que el mint pasa por el consenso y todos los nodos lo aplican. El límite es 100000000000 unidades, 100 RAND, por llamada, y el valor por defecto es el límite. Desde la chain 14 el mint lleva la apertura de la nota (pk, time y r) y la firma la cubre: la admisión recalcula el compromiso de (pk, no sender, amount, asset 0, time, r) y rechaza un cm que no coincida con the mint's commitment does not open to its published note and amount, y exige que time esté dentro de la ventana del bundle. Los parámetros de rand_mint no cambian. El mensaje firmado es blake3("rand-mint-2" ‖ bincode(chain_id, cm, pk, time, r, envelope, amount)) en las cadenas 14 a 19; en la chain 20, cuyo génesis establece binding_domain: 1, es rand-mint-3 sobre el hash del génesis seguido de los mismos campos, de modo que un mint firmado para una cadena es rechazado en cualquier otra, incluso una que comparta el id de cadena y las claves de los validadores. Un observador no tiene clave de validador y recibe faucet mints are signed by validators; ask a validator node; una cadena sin la bandera responde faucet is disabled on this chain.

El faucet de la chain 20 está activo pero acotado por la sección staking de su génesis, con los mismos valores que los de la chain 19:

Así, rand faucet funciona en la chain 20 solo para una wallet de la lista, solicitado a un nodo validador cuya clave sea un emisor listado; cualquier otra dirección tiene que recibir el pago de alguien que tenga RAND.

rand faucet                          # 100 RAND to this wallet's address, waits for the commit
rand faucet rand1… --amount 25       # to another address, less than the cap

→ {"method":"rand_mint","params":["rand1…", "100000000000"]}
← "9ab1c0…4f"

Lo que es público: el compromiso de la nueva nota, su sobre, el monto en claro, y la clave pública del validador que emite el mint (mostrada como su dirección) y su firma. La apertura también publica la clave propietaria de la nota pk, de modo que el propietario de una nota del faucet es público, igual que el pago de un retiro; lo que permanece oculto es cuándo y dónde se gasta esa nota después. El vínculo de un solo salto entre «se emitieron 100 RAND» y «existe una nota por 100 RAND» es la misma visibilidad que tiene en cualquier parte un depósito de transparente a blindado. La admisión comprueba que el faucet esté habilitado, que el monto esté por debajo del límite, que el presupuesto de la época tenga margen, que el destinatario esté en la lista de permitidos cuando el génesis tiene una, que el compromiso se abra a la nota publicada, que el emisor sea un validador, y esté en la lista de emisores cuando el génesis tiene una, y que la firma verifique; un mint no paga comisión.

rand_getTransaction muestra uno como { "kind": "mint", "cm": "…", "amount": "100000000000", "minter": "<validator base58>" } con "bundle": null: el monto es una cadena decimal, como todo monto u64 que el RPC sirve desde la chain 14; el explorador los lista bajo kind=mint, uno de los pocos tipos con un amount público.

Depósitos de génesis

La otra forma en que entra valor es el archivo de génesis: cada --alloc rand1<address>=<RAND> pasado a rand-node genesis se convierte en una nota de depósito { cm, envelope, amount, opening } con aleatoriedad de compromiso nueva, las primeras hojas del árbol. La chain 20 tiene nueve notas de génesis: siete notas de RAND, 5,184.243719258 RAND en total (genesis_deposited), los saldos de los operadores trasladados desde una instantánea de la chain 19, y dos notas de zUSD de 10 y 89 zUSD, los 99 zUSD de custodia del puente trasladados desde la chain 19 (Puente), que no son RAND y no se cuentan en genesis_deposited. El RAND que tenían en la chain 19 wallets que el operador no controla, unos 520 RAND, y las comisiones de validador no retiradas no se trasladaron. Historial: la chain 19 tenía ocho, siete notas de RAND por 5,294.644359629 RAND y una de 10 zUSD; la chain 18 tenía seis notas de RAND, cinco de 1,000 RAND y una de 300 RAND; las chains 14 y 15 tenían cinco de 1,000 RAND. El monto es público para que cualquiera pueda sumar el suministro inicial, y desde la chain 14 la nota lleva también su apertura, de modo que el propietario de una nota de génesis es público por diseño. Volver a generar las mismas asignaciones produce notas distintas y un hash de génesis distinto, a propósito.

Quemas

Toda transacción lleva un bundle de activos ocultos de cuatro ranuras, y este tiene dos palabras de quema: burn_r es RAND que sale del pool hacia un lugar público, y burn_a es una cantidad del token nombrado por burn_asset. La guest del bundle equilibra ambos grupos en una sola prueba, y la admisión exige que los tres sean cero salvo en estas acciones:

(El bundle de un register_aggregator también quema su bono de génesis mediante burn_r; la agregación está desactivada en la chain 20.)

Las quemas no son comisiones. La quema de un bono es RAND que pasa del pool al registro y se cuenta en burned de la auditoría de suministro (y reaparece en register_total). Una quema de puente es un solo bundle desde la chain 14 (antes eran dos): las ranuras 0–1 queman el activo puenteado y las ranuras 2–3 pagan la comisión, de modo que afecta al suministro de RAND solo a través de esa comisión, BRIDGE_BURN_FEE, 0.01 RAND. Debe nombrar una moneda que respalde el activo, liberar un número entero de unidades de esa moneda y caber en lo que ese respaldo tiene bloqueado (Puente). En la chain 20 su bridge.fees de génesis también toma 10 bps de cada mint y quema puenteados en zUSD: un depósito acredita el bruto menos la comisión y una quema libera amount − fee, cada comisión una nota blindada de zUSD para la tesorería. La nota de comisión sigue emitida y respaldada, así que total_supply == Σ locked de zUSD se sigue cumpliendo; no es un movimiento de RAND y no entra en la auditoría de suministro de RAND. Un TokenBurn paga la base de bundle de 0.001 RAND; un token puenteado se rechaza ahí y sale mediante bridge-burn.

Una comisión también es una quema en la chain 20, como en todas las cadenas desde la 15: su génesis establece tokens.burn_registration_fee, de modo que el registration_fee de 1 RAND de un RegisterToken o RegisterBridgedToken se destruye en lugar de pagarse al proponente, que solo conserva la base del bundle. Se cuenta en burned y, por separado, en registration_fees_burned (Tokens RPL).

rand bond <validator> 1000 [--registration <hex>]     # burns 1000 RAND out of this wallet's notes
rand bridge-burn <ASSET> <AMOUNT> <TO_CHAIN> <TOKEN> <TO>   # burns AMOUNT of a bridged asset, released as TOKEN on TO_CHAIN
rand token burn <ASSET> <AMOUNT>                      # destroys AMOUNT of an RPL token this wallet holds

Las comisiones son la otra salida

La fee de cada bundle sale del pool hacia los rewards del proponente del bloque, un campo público del registro, y vuelve al pool solo cuando el validador la retira como una nota (Staking). Un Withdraw paga la base de 0.001 RAND, tomada del monto retirado, al proponente del bloque que lo aplica; esa base nunca sale del registro, así que no es un cruce.

Cómo se mueve el suministro

in:   genesis_deposited, faucet_minted, withdraw_deposited, program_rand_out
out:  fees_paid, burned
pool_value     = in − out
total_supply   = pool_value + Σ register (stake + pending + rewards) + program_rand_held
               ==  genesis_deposited + genesis_staked + faucet_minted − slashed − registration_fees_burned

program_rand_held y program_rand_out son nuevos en la chain 20 (RPL-2): el RAND que un Invoke quema hacia una bóveda de programa mediante burn_r se cuenta en burned del lado del pool y se mantiene en la bóveda, y lo que una bóveda paga como notas vuelve al pool. rand_getSupply sirve ambos, con invariant_holds.

Solo una emisión del faucet aumenta lo que la cadena ha emitido, y en la chain 20 solo una comisión de registro quemada lo reduce: slashed contabilizaría un bono de aggregator penalizado (slashed) o, con una sección staking.slashing en el génesis, un stake de validator penalizado, y la chain 20 no tiene ninguno de los dos (la agregación está desactivada y slashing es null). Un bono, una comisión, un retiro y un depósito en una bóveda mueven valor entre el pool, el registro y las bóvedas, y no crean nada. Supply recoge los contadores y un ejemplo resuelto. El subsidio de agregación de bloques —RAND nuevos por cada bloque sellado según un calendario de reducción a la mitad, pagados a un aggregator como una note de depósito— sería la primera emisión programada, y no está activa en la chain 20.