Tarifas

Use esta página para fijar la comisión de una transacción, para estimar lo que cuesta un despliegue o una llamada y para entender qué se le paga a un validador. Las comisiones son pisos en RAND. Toda acción salvo una llamada paga una comisión fija. En la chain 20, una llamada paga por el límite de gas que declara su prueba y por sus bytes, a precios que se mueven según lo llenos que estén los bloques y que se detienen en un techo.

Los pisos

Las comisiones se expresan en unidades de 10⁻⁹ RAND. Las constantes están en randprotocol_core::gas:

La comisión es una palabra pública del bundle y siempre es RAND. El guest del bundle de activos ocultos la vincula a la relación de balance del grupo RAND in₂ + in₃ = out₂ + out₃ + fee + burn_r (slots 2–3), de modo que se paga con notes ocultas sin revelar cuáles; un token se mueve por los slots 0–1 del mismo bundle bajo su propia relación, in₀ + in₁ = out₀ + out₁ + burn_a. Por tanto, una sola prueba mueve un token y paga su comisión en RAND, y una wallet que tiene un token pero ningún RAND gastable es rechazada antes de probar.

El cargo del bridge recae sobre el burn porque es la única transacción del bridge cuyo emisor tiene seguro RAND; un depósito paga solo la base, ya que el depositante aún no tiene RAND. La comisión de registro es un hecho del ledger y no parte de fee_floor, por lo que se comprueba con las reglas propias de la acción (RegistrationFeeTooLow), del modo en que se cobra la parte de gas o de tier de una llamada una vez decodificada su prueba. El piso de una llamada se comprueba dos veces, porque lo que declara solo es fiable cuando su prueba ha sido verificada. En la chain 20, la primera comprobación, antes de cualquier verificación, fija el precio de los bytes de la llamada y de un límite declarado de 1 (un Invoke también debe allí su comisión por celda); la segunda fija el precio del límite que declara la prueba verificada. En una chain sin sección gas, ambas son BUNDLE_BASE + CALL_BASE y el piso exacto por tier.

Pregunte al nodo en lugar de adivinar:

rand fee bundle          # 0.001 RAND
rand fee deploy 256      # 0.0266 RAND
rand fee call 14 --gas 20479 --bytes 1350000   # 0.0041 RAND at chain 20's starting prices

→ {"method":"rand_estimateFee","params":[{"kind":"call","tier":14,"gas":20479,"bytes":1350000}]}
← "4103100"

Esa respuesta es 1,000,000 + 100 × 20,479 + 800 × 1,319 a los precios iniciales; el nodo fija el precio con los precios del tip en el momento de la consulta. En la chain 20, el campo gas de la especificación de la llamada es obligatorio por JSON-RPC (-32602 si falta). rand fee call <tier> sin --gas envía el techo del tier, y sin --bytes no cobra ningún byte. Un invoke se cotiza del mismo modo, con "kind":"invoke" y "created_cells": c, que suma c comisiones por celda (24103100 para el ejemplo anterior con dos celdas, consultado a la chain 20 el 2026-10-01). En la chain 15, que no tenía sección gas, rand fee call 14 respondió 0.0022 RAND.

Los valores por defecto de la wallet son exactamente los pisos, salvo en una llamada en la chain 20, cuyo valor por defecto añade margen (abajo); rand send --fee <RAND> y la opción --fee en bond, call, bridge-mint, bridge-burn (por defecto 0.01) y los subcomandos token los elevan. Todo lo que exceda el piso es una propina.

Gas on chain 18

La chain 18, activa del 2026-09-29 al 2026-10-01, fue la primera chain con medición de gas, y la chain 19, su re-génesis con la misma build, llevó la misma sección gas. La chain 20 (v0.6.8) mantiene todas las reglas de esta sección y añade dos techos de precio y una carga de bytes contada solo sobre los bytes que pagan (abajo). Una chain sin sección gas mantiene el calendario por tiers de la tabla anterior.

Qué se cuenta. Un gas es una fila de la tabla cpu de la zkVM, de modo que una instrucción ordinaria cuesta 1. Las syscalls son los únicos otros costos:

El límite declarado. Una prueba de llamada lleva un valor público más que antes, GAS_LIMIT, y el circuito (conjunto de restricciones 8) prueba que el gas de la ejecución es igual o inferior a él. El gas exacto permanece privado. Un límite por encima del techo del propio encabezado de la prueba se rechaza antes de construir cualquier clave del verificador:

gas_max = (2ᵗ − 1) + 2^(t−2) + 191 × (keccak rows / 32) + 63 × (sha256 rows / 64)

Eso es 1,279 en el tier 10, 5,119 en el tier 12 y 20,479 en el tier 14 para una llamada que no usa ninguna de las tablas de hash.

El piso. El ledger cobra el límite declarado y los bytes, a los precios vigentes cuando comienza el bloque:

fee ≥ BUNDLE_BASE + gas_price × gas_limit + byte_price × ⌈bytes / 1024⌉

bytes es la prueba de la llamada más el envoltorio de entrada. El calendario por tiers y su franquicia gratuita no se aplican en una chain así. El pool exige exactamente lo que exige un bloque, y rechaza una llamada más barata como FeeTooLow.

Los bundles y la prueba de autorización declaran límites fijados. Toda prueba de bundle debe declarar exactamente el bundle_gas_limit del génesis, 20,479 (el techo del tier 14), o la transacción se rechaza como BundleGasLimit. La chain 20, como toda chain desde la 17, ejecuta autorización dividida, de modo que cada bundle lleva una prueba de autorización de tier 10, que debe declarar 1,279 (AuthGasLimit). Ninguno es un cargo: una transferencia, un bond o un despliegue sigue pagando su piso fijo de la tabla anterior. La wallet declara ambos valores por sí misma.

Los precios se mueven. La sección gas de la chain 20 tiene un controlador dynamic, de modo que gas_price y byte_price son estado del ledger, comprometido en la raíz de estado. Una vez por bloque, después de sus transacciones, cada uno se mueve según lo lleno que estuvo el bloque respecto de un objetivo:

price' = min(max_price, max(min_price, price + ⌊price × adjust_bps × (used − target) / (10,000 × target)⌋))

used está limitado a dos veces el objetivo, de modo que adjust_bps es el mayor movimiento que un bloque puede hacer en cualquier dirección. max_price es el techo del génesis; las chains 18 y 19 no tenían ninguno. byte_price sigue los bytes que pagan del bloque (abajo); gas_price sigue la suma de los límites declarados de sus llamadas e invokes más 20,479 por cada bundle.

Un bloque por debajo de sus objetivos hace bajar los precios, de modo que en una cadena tranquila se sitúan en los mínimos. rand_getLimits entrega el gas_price y el byte_price vigentes en la punta de la cadena junto con gas_metering: "circuit", bundle_gas_limit, adjust_bps y, desde v0.6.8, max_gas_price, max_byte_price y byte_load (null en una cadena que no los tiene); rand_status informa de los mismos dos precios como gas_prices.

Techos y la carga de bytes pagada

Ambos son campos del génesis de gas.dynamic, nuevos en v0.6.8 (auditoría v6, POOL-2), y la cadena 20 es la primera en fijarlos. Corrigen una falla que tenían las cadenas 18 y 19. En ellas, byte_price se movía con la longitud codificada de cada transacción, aunque solo una llamada lo paga. Siete transferencias (unos 2.85 MB cada una, comisión fija) llenan un bloque hasta aproximadamente 1.9 veces el objetivo de bytes y elevan el precio cerca de 11% por bloque, sin techo: unos 65 bloques así lo llevan a 1,000 veces su valor inicial, y entonces una llamada cuesta cerca de 1 RAND en lugar de unos 0.004.

• Techos. max_gas_price y max_byte_price son precios que el controlador nunca supera. El paso es el mismo y luego se limita (gas::next_price_capped), de modo que un precio en su techo permanece allí durante cualquier racha de bloques llenos y baja en el primer bloque por debajo del objetivo. Un génesis debe fijar cada uno en un valor igual o superior a su precio inicial. Con los techos de la cadena 20, la llamada de tier 14 mencionada arriba, de 20,479 de gas y 1,319 KiB, tiene un mínimo de 0.3113 RAND, el más alto al que puede llegar su mínimo.
• La carga de bytes pagada. Con byte_load: "paying", los bytes_used del bloque cuentan solo los bytes sobre los que se cobra el precio por byte: la prueba más el sobre de entrada de cada Call e Invoke (gas::call_bytes), y nada de una transferencia, un bono o una quema. Un bloque de transferencias no mueve ningún precio por byte. Ledger::block_usage calcula la cifra tanto para el proponente como para la réplica, de modo que ambos coinciden.

Con la carga pagada, un bloque lleno de transferencias no da ninguna señal de precio a una llamada, así que un proponente honesto también reserva espacio para las llamadas. Esto es política del nodo, no una regla de validez: mientras haya una llamada o un invoke en el pool que pague su mínimo vigente, las transacciones de comisión fija ocupan como máximo tres cuartos de los bytes del bloque en la primera pasada, y lo que las llamadas dejen del último cuarto se completa luego con las transferencias retenidas (Mempool).

Lo que paga la billetera por una llamada

rand call ejecuta primero el programa en el emulador e imprime gas: <exact> (declaring <limit>, tier <t>). Por defecto declara el gas exacto redondeado hacia arriba a un múltiplo de 2^(tier − 2); --gas-limit N declara una cifra exacta y --gas-limit max el techo del encabezado.

Dos factores hacen que la comisión por defecto sea mayor que el mínimo:

• La prueba se tarifa al límite. Desde la cadena 16 (hardening_v6, incluida la cadena 20) una prueba de llamada queda ligada a su propia transacción, de modo que la comisión se fija antes de que exista la prueba. La billetera tarifa el límite de prueba de la cadena, 4 MiB, en lugar del tamaño real de la prueba (wallet::hardened_call_quote_bytes). Eso solo puede resultar en un pago de más.
• Dos pasos de precio de margen. rand_getLimits entrega los precios del encabezado confirmado y una llamada se incluye dos o tres bloques después, así que por defecto se multiplica el mínimo por (1 + adjust_bps / 10,000)², que es 1.125² en la cadena 20.

Medido en la cadena 18 el 2026-09-30, cuatro llamadas costaron entre 0.0057 y 0.0075 RAND cada una con estos valores por defecto (Example programs). --fee reemplaza el valor por defecto; la billetera vuelve a tarifar la prueba real antes de enviarla y rechaza una comisión inferior a su mínimo.

Adónde va la comisión

Toda ella, mínimo y propina, se acredita a los rewards del proponente del bloque en el registro de validadores, el único lugar de esta cadena que almacena un monto en claro, con una excepción. En un génesis con tokens.burn_registration_fee (la cadena 20, como toda cadena desde la 15), el registration_fee de un RegisterToken o de un RegisterBridgedToken se quema y el proponente se queda con fee − registration_fee; rand_getSupply lo contabiliza en registration_fees_burned. En la cadena 14, que carecía de la bandera, el proponente se quedaba con la comisión completa. No se quema nada más y no hay reparto. Un validador convierte las recompensas acumuladas en una nota con rand-node withdraw (Staking). La comisión de celda de un invoke forma parte de la comisión de su bundle y va al proponente junto con el resto. En la cadena 20 no hay recompensas por bloque ni inflación: las comisiones son la totalidad del ingreso de un validador.

Una comisión de la cadena 20 no es en RAND y no va a ningún validador. Según el bridge.fees del génesis (nuevo en v0.6.8), el puente retiene 10 bps de cada depósito de zUSD y de cada quema de zUSD, redondeados hacia abajo a una unidad de liberación entera del respaldo, como una nota de zUSD dirigida a una dirección de tesorería que nombra el génesis. Un depósito acredita al depositante el monto bruto menos la comisión; una quema libera amount − fee en la cadena de origen. La nota de la comisión sigue emitida y respaldada. Véanse Bridge y RPL tokens.

El mempool ordena los candidatos por lo que pagan por encima de su mínimo por KiB y luego por comisión (Mempool), de modo que una comisión mayor solo importa bajo congestión. Una transferencia pesa unos 2.85 MB (medido en la cadena 18): una prueba de bundle de 1.49 MB y una prueba de autorización de 1.36 MB, de modo que caben unas siete en el bloque de 20 MiB de la cadena 20. La propia nota del fullnode decía que un mercado de comisiones sobre bytes, y no sobre opcodes, es en lo que debería convertirse el mínimo antes de mainnet-beta. El precio por byte de la cadena 20 es ese mercado para las llamadas, movido solo por los bytes que las llamadas pagan; el mínimo de una transferencia sigue siendo fijo.

Por qué aquí el gas es un precio y no un límite

Ethereum mide cada opcode porque todos los nodos ejecutan todas las transacciones y la ejecución no tiene cota. En Rand ningún nodo ejecuta nada: el remitente ejecuta el programa una vez, fuera de la cadena, y entrega a la cadena una prueba. El trabajo de un nodo por transacción es una secuencia fija —decodificar los campos públicos, ejecutar las comprobaciones gratuitas, verificar una STARK— y esa verificación cuesta unos 16 ms con una clave del verificador en caché, haga lo que haga el programa. Así, las tres funciones del gas se separan:

• La terminación la impone el tier: una ejecución que no se detiene en 2ᵗ − 1 ciclos no puede probarse en absoluto, y el probador absorbe el fallo.
• La tarificación del trabajo es lo que hace el mínimo de gas, desde la cadena 18. El costo de la red por instrucción es casi nulo, pero el trabajo de prueba del remitente es real, y un mínimo fijo tarifaba una llamada de un millón de ciclos igual que una de mil. Hasta la cadena 18 el mínimo era fijo por tier.
• El dimensionamiento de los bloques es un presupuesto de bytes (MAX_BLOCK_BYTES = 4 MiB por defecto, el max_block_bytes del génesis en los demás casos) y un número de transacciones (2,000).

Dos salvedades que el fullnode declara con claridad: los bytes sí varían (una prueba supera el megabyte, de modo que el espacio en bloque, y no el cómputo, es el recurso escaso), y el crecimiento del estado —el árbol, el conjunto de nullifiers, los bytes de los programas desplegados— se tarifa solo mediante la comisión de despliegue por palabra y la base fija, lo cual es adecuado para una testnet y conviene revisar cuando el tamaño del estado importe.

Lo que paga el remitente en cambio: la prueba

El único costo que varía es la producción de la prueba STARK, y solo lo paga la máquina del remitente. En orden de efecto:

1. El tier t ∈ {10, 12, 14, 16, 18, 20} (una llamada por encima de 14 se rechaza en la cadena desde v0.5.6; un bundle está fijado en 14 y, desde la cadena 17, lleva a su lado una prueba de autorización de tier 10, unos 7 s más): la tabla de la cpu se rellena hasta 2ᵗ filas y cada paso multiplica aproximadamente por cuatro la traza rellenada. Medido en el portátil de desarrollo: private_payment en tier 10 en unos 7 s; el guest de bundle de activos ocultos en tier 14 en unos 100 s, sea cual sea el activo que mueva.
2. Los ciclos ejecutados, porque deciden el tier: instrucciones ejecutadas, no instrucciones escritas.
3. El tamaño del programa, de forma débil: una fila de digest por cada cuatro palabras al inicio de la traza.
4. El tamaño de la entrada privada, del mismo modo.
5. Qué tablas están presentes: una tabla keccak o sha256 cuesta la parte de sus columnas solo cuando el guest la usó.
6. El perfil FRI: 80 consultas en lugar de 27 triplican el tamaño de la prueba pero apenas cambian el tiempo de prueba.

La prueba no depende de los montos, de cuántas notas posee el remitente ni del tamaño de la cadena: la pertenencia se prueba contra un árbol de profundidad fija, de modo que una transferencia cuesta lo mismo en el bloque diez que en el bloque diez millones.

Referencia