Taxas

Use esta página para definir a taxa de uma transação, estimar quanto custa um deploy ou uma chamada e entender quanto um validador recebe. As taxas são pisos, em RAND. Toda ação, exceto a chamada, paga um piso fixo. Na chain 20, uma chamada paga pelo limite de gas que sua prova declara e pelos seus bytes, a preços que se movem conforme o enchimento dos blocos e que páram em um teto.

Os pisos

As taxas são expressas em unidades de 10⁻⁹ RAND. As constantes estão em randprotocol_core::gas:

A taxa é uma palavra pública do bundle e é sempre em RAND. O guest do bundle de ativos ocultos a vincula à relação de saldo do grupo RAND, in₂ + in₃ = out₂ + out₃ + fee + burn_r (slots 2–3), de modo que é paga a partir de notas ocultas sem revelar quais; um token circula pelos slots 0–1 do mesmo bundle, sob sua própria relação, in₀ + in₁ = out₀ + out₁ + burn_a. Uma única prova, portanto, move um token e paga sua taxa em RAND, e uma carteira que tem um token mas nenhum RAND gastável é recusada antes de provar.

A cobrança da bridge recai sobre o burn porque essa é a única transação da bridge cujo remetente certamente possui RAND; um depósito paga apenas a base, já que o depositante ainda não tem RAND. A taxa de registro é um fato do ledger, e não parte de fee_floor, por isso é verificada com as regras da própria ação (RegistrationFeeTooLow), do mesmo modo que a parte de gas ou de tier de uma chamada é cobrada depois que sua prova é decodificada. O piso de uma chamada é verificado duas vezes, porque o que ela declara só é considerado confiável depois que sua prova é verificada. Na chain 20, a primeira verificação, antes de qualquer validação, precifica os bytes da chamada e um limite declarado de 1 (um Invoke também deve ali sua taxa de célula); a segunda precifica o limite que a prova verificada declara. Em uma chain sem a seção gas, os dois pisos são BUNDLE_BASE + CALL_BASE e o piso exato do tier.

Pergunte ao nó em vez de adivinhar:

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"

Essa resposta é 1,000,000 + 100 × 20,479 + 800 × 1,319 aos preços iniciais; o nó aplica os preços vigentes no tip quando é consultado. Na chain 20, o campo gas da especificação da chamada é obrigatório via JSON-RPC (-32602 sem ele). rand fee call <tier> sem --gas envia o teto do tier e, sem --bytes, não precifica nenhum byte. Um invoke é precificado do mesmo modo, com "kind":"invoke" e "created_cells": c acrescentando c taxas de célula (24103100 para o exemplo acima com duas células, consultado na chain 20 em 2026-10-01). Na chain 15, que não tinha seção gas, rand fee call 14 respondeu 0,0022 RAND.

Os padrões da carteira são exatamente os pisos, exceto para uma chamada na chain 20, cujo padrão acrescenta folga (abaixo); rand send --fee <RAND> e a flag --fee em bond, call, bridge-mint, bridge-burn (padrão 0,01) e nos subcomandos token os elevam. Tudo o que excede o piso é gorjeta.

Gas na chain 18

A chain 18, ativa de 2026-09-29 a 2026-10-01, foi a primeira chain com medição de gas, e a chain 19, seu re-genesis sobre o mesmo build, trouxe a mesma seção gas. A chain 20 (v0.6.8) mantém todas as regras desta seção e acrescenta dois tetos de preço e uma carga de bytes contada apenas sobre os bytes que pagam (abaixo). Uma chain sem a seção gas mantém a tabela de tiers da tabela acima.

O que é contado. Um gas é uma linha da tabela cpu da zkVM, de modo que uma instrução comum custa 1. Os syscalls são os únicos outros custos:

O limite declarado. Uma prova de chamada carrega um valor público a mais do que antes, GAS_LIMIT, e o circuito (conjunto de restrições 8) prova que o gas da execução é igual ou inferior a ele. O gas exato permanece privado. Um limite acima do teto do próprio cabeçalho da prova é recusado antes que qualquer chave de verificação seja construída:

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

Isso dá 1.279 no tier 10, 5.119 no tier 12 e 20.479 no tier 14 para uma chamada que não usa nenhuma das tabelas de hash.

O piso. O ledger cobra o limite declarado e os bytes, aos preços vigentes quando o bloco começa:

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

bytes é a prova da chamada mais o envelope de entrada. A tabela de tiers e sua franquia gratuita não se aplicam a uma chain assim. O pool exige exatamente o que um bloco exige e recusa uma chamada mais barata como FeeTooLow.

Bundles e a prova de autorização declaram limites fixos. Toda prova de bundle deve declarar exatamente o bundle_gas_limit do genesis, 20.479 (o teto do tier 14), ou a transação é recusada como BundleGasLimit. A chain 20, como toda chain desde a 17, executa a autorização dividida, de modo que cada bundle carrega uma prova de autorização de tier 10, que deve declarar 1.279 (AuthGasLimit). Nenhum dos dois é uma cobrança: uma transferência, um bond ou um deploy ainda paga seu piso fixo da tabela acima. A carteira declara ambos os valores por conta própria.

Os preços se movem. A seção gas da chain 20 tem um controlador dynamic, de modo que gas_price e byte_price são estado do ledger, comprometidos na raiz de estado. Uma vez por bloco, depois de suas transações, cada um se move conforme o quão cheio o bloco estava em relação a uma meta:

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

used é limitado a duas vezes a meta, de modo que adjust_bps é o maior movimento que um bloco pode fazer em qualquer direção. max_price é o teto do genesis; as chains 18 e 19 não tinham nenhum. byte_price acompanha os bytes pagantes do bloco (abaixo); gas_price acompanha a soma dos limites declarados de suas chamadas e invokes mais 20.479 por cada bundle.

Um bloco abaixo de suas metas move os preços para baixo; por isso, numa cadeia ociosa eles ficam nos pisos. rand_getLimits informa os gas_price e byte_price atuais da ponta, com gas_metering: "circuit", bundle_gas_limit, adjust_bps e, desde a v0.6.8, max_gas_price, max_byte_price e byte_load (null numa cadeia que não os tenha); rand_status informa os mesmos dois preços como gas_prices.

Tetos e a carga de bytes pagantes

Ambos são campos de genesis de gas.dynamic, novos na v0.6.8 (auditoria v6, POOL-2), e a chain 20 é a primeira cadeia a defini-los. Eles corrigem uma falha das chains 18 e 19. Nelas, o byte_price se movia com o tamanho codificado de cada transação, embora só uma chamada o pague. Sete transferências (cerca de 2,85 MB cada, com taxa fixa) enchem um bloco até cerca de 1,9 vez a meta de bytes e elevam o preço em cerca de 11% por bloco, sem teto: cerca de 65 blocos assim o levam a 1.000 vezes o valor inicial, e uma chamada passa então a custar cerca de 1 RAND em vez de cerca de 0,004.

• Tetos. max_gas_price e max_byte_price são preços que o controlador nunca ultrapassa. O passo é o mesmo e depois é limitado (gas::next_price_capped); assim, um preço no teto permanece ali durante qualquer sequência de blocos cheios e cai no primeiro bloco abaixo da meta. Um genesis deve definir cada um em valor igual ou superior ao preço inicial. Nos tetos da chain 20, a chamada de tier 14 acima, com 20.479 de gas e 1.319 KiB, tem um piso de 0,3113 RAND, o mais alto que seu piso pode atingir.
• A carga de bytes pagantes. Com byte_load: "paying", o bytes_used do bloco conta apenas os bytes sobre os quais o preço por byte é cobrado: a prova mais o envelope de entrada de cada Call e Invoke (gas::call_bytes), nada de uma transferência, de um bond ou de um burn. Um bloco de transferências não move o preço por byte. Ledger::block_usage calcula o valor tanto para o proponente quanto para a réplica, de modo que os dois concordam.

Sob a carga pagante, um bloco cheio de transferências não dá sinal de preço a uma chamada; por isso, um proponente honesto também reserva espaço para chamadas. Isso é política do nó, não regra de validade: enquanto uma chamada ou um invoke está no pool e paga o piso atual, as transações de taxa fixa ocupam no máximo três quartos dos bytes do bloco na primeira passagem, e o que as chamadas deixam do último quarto é então preenchido com as transferências retidas (Mempool).

O que a carteira paga por uma chamada

rand call executa primeiro o programa no emulador e imprime gas: <exact> (declaring <limit>, tier <t>). Por padrão, declara o gas exato arredondado para cima até um múltiplo de 2^(tier − 2); --gas-limit N declara um valor exato e --gas-limit max o teto do cabeçalho.

Duas coisas tornam a taxa padrão mais alta que o piso:

• A prova é precificada no limite máximo. Desde a chain 16 (hardening_v6, chain 20 incluída), a prova de uma chamada é vinculada à sua própria transação, de modo que a taxa é fixada antes de a prova existir. A carteira precifica o limite máximo de prova da cadeia, 4 MiB, no lugar do tamanho real da prova (wallet::hardened_call_quote_bytes). Isso só pode resultar em pagamento a maior.
• Dois passos de preço de margem. rand_getLimits informa os preços do head confirmado e uma chamada é incluída dois ou três blocos depois; por isso o padrão multiplica o piso por (1 + adjust_bps / 10.000)², que é 1,125² na chain 20.

Medidas na chain 18 em 2026-09-30, quatro chamadas custaram entre 0,0057 e 0,0075 RAND cada com esses padrões (Example programs). --fee substitui o padrão; a carteira reprecifica a prova real antes de enviar e recusa uma taxa abaixo do piso.

Para onde vai a taxa

Toda ela, piso e gorjeta, é creditada às rewards do proponente do bloco no registro de validadores, o único lugar desta cadeia que armazena um valor em claro, com uma exceção. Num genesis com tokens.burn_registration_fee (chain 20, como toda cadeia desde a 15), a registration_fee de um RegisterToken ou RegisterBridgedToken é queimada e o proponente fica com fee − registration_fee; rand_getSupply a contabiliza em registration_fees_burned. Na chain 14, que não tinha o flag, o proponente ficava com a taxa inteira. Nada mais é queimado e não há divisão. Um validador converte as recompensas acumuladas em uma nota com rand-node withdraw (Staking). A taxa de célula de um invoke faz parte da taxa de seu bundle e vai ao proponente com o resto. Não há recompensas de bloco nem inflação na chain 20: as taxas são toda a receita de um validador.

Uma taxa na chain 20 não é em RAND e não vai a nenhum validador. Sob o bridge.fees do genesis (novo na v0.6.8), a bridge retém 10 bps de cada depósito de zUSD e de cada burn de zUSD, arredondados para baixo até uma unidade inteira de liberação do lastro, como uma nota de zUSD para um endereço de tesouraria que o genesis nomeia. Um depósito credita ao depositante o valor bruto menos a taxa; um burn libera amount − fee na cadeia de origem. A nota da taxa permanece emitida e lastreada. Veja Bridge e RPL tokens.

O mempool ordena os candidatos pelo que pagam acima de seu piso por KiB e depois pela taxa (Mempool); assim, uma taxa maior só importa sob congestionamento. Uma transferência tem cerca de 2,85 MB (medido na chain 18): uma prova de bundle de 1,49 MB e uma prova de autorização de 1,36 MB, de modo que cabem cerca de sete no bloco de 20 MiB da chain 20. A própria observação do fullnode era que um mercado de taxas sobre bytes, e não sobre opcodes, é no que o piso deveria se converter antes da mainnet-beta. O preço por byte da chain 20 é esse mercado para chamadas, movido apenas pelos bytes que as chamadas pagam; o piso de uma transferência continua fixo.

Por que o gas aqui é um preço, não um limite

A Ethereum mede cada opcode porque todo nó executa toda transação e a execução é aberta. Na Rand nenhum nó executa nada: o remetente executa o programa uma vez, fora da cadeia, e entrega à cadeia uma prova. O trabalho de um nó por transação é uma sequência fixa — decodificar os campos públicos, executar as verificações gratuitas, verificar um STARK — e essa verificação custa cerca de 16 ms com uma chave de verificação aquecida, seja o que for que o programa tenha feito. Assim, as três funções do gas se separam:

• A terminação é imposta pelo tier: uma execução que não termina em 2ᵗ − 1 ciclos não pode ser provada de forma alguma, e o provador absorve a falha.
• A precificação do trabalho é o que o piso de gas faz, desde a chain 18. O custo da rede por instrução é próximo de zero, mas o trabalho de prova do remetente é real, e um piso fixo precificava uma chamada de um milhão de ciclos como uma de mil ciclos. Até a chain 18, o piso era fixo por tier.
• O dimensionamento do bloco é um orçamento de bytes (MAX_BLOCK_BYTES = 4 MiB por padrão, o max_block_bytes do genesis caso contrário) e uma contagem de transações (2.000).

Duas ressalvas que o fullnode declara com clareza: os bytes de fato variam (uma prova tem mais de um megabyte, de modo que o espaço em bloco, e não a computação, é o recurso escasso), e o crescimento do estado — a árvore, o conjunto de nullifiers, os bytes dos programas implantados — é precificado apenas pela taxa de deploy por palavra e pela base fixa, o que é adequado para uma testnet e merece revisão quando o tamanho do estado importar.

O que o remetente paga em troca: a prova

O único custo que varia é produzir a prova STARK, e só a máquina do remetente o paga. Em ordem de efeito:

1. O tier t ∈ {10, 12, 14, 16, 18, 20} (uma chamada acima de 14 é recusada na cadeia desde a v0.5.6; um bundle é fixado em 14 e, desde a chain 17, leva ao lado uma prova de autorização de tier 10, cerca de 7 s a mais): a tabela da cpu é preenchida até 2ᵗ linhas e cada passo quadruplica aproximadamente o trace preenchido. Medido no laptop de desenvolvimento: private_payment no tier 10 em cerca de 7 s; o guest de bundle de ativo oculto no tier 14 em cerca de 100 s, qualquer que seja o ativo que ele movimente.
2. Ciclos executados, porque decidem o tier: instruções executadas, não instruções escritas.
3. Tamanho do programa, de forma fraca: uma linha de digest a cada quatro palavras no início do trace.
4. Tamanho da entrada privada, da mesma forma.
5. Quais tabelas estão presentes: uma tabela de keccak ou sha256 custa a parcela de suas colunas apenas quando o guest a usou.
6. O perfil de FRI: 80 consultas em vez de 27 triplicam o tamanho da prova, mas mal alteram o tempo de prova.

A prova não depende dos valores, de quantas notas o remetente possui nem do tamanho da cadeia: a pertinência é provada contra uma árvore de profundidade fixa, de modo que uma transferência custa o mesmo no bloco dez e no bloco dez milhões.

Reference