Fees

Use this page to set the fee on a transaction, to estimate what a deploy or a call costs, and to understand what a validator is paid. Fees are floors in RAND. Every action but a call pays a flat one. Since chain 18 a call pays for the gas limit its proof declares and for its bytes, at prices that move with how full blocks are and, since chain 20, stop at a ceiling. On chain 21 (fullnode v0.8.0, live since 2026-10-12) the floor itself is burned and the proposer keeps only the tip (below).

The floors

Fees are in units of 10⁻⁹ RAND. Constants live in randprotocol_core::gas:

The fee is a public word of the bundle and is always RAND. The hidden-asset bundle guest binds it into the RAND group’s balance relation in₂ + in₃ = out₂ + out₃ + fee + burn_r (slots 2–3), so it is paid out of hidden notes without revealing which; a token moves through slots 0–1 of the same bundle under its own relation, in₀ + in₁ = out₀ + out₁ + burn_a. One proof therefore moves a token and pays its RAND fee, and a wallet holding a token but no spendable RAND is refused before proving.

The bridge’s charge falls on the burn because that is the one bridge transaction whose sender is sure to hold RAND; a deposit pays only the base, since the depositor has no RAND yet. The registration fee is a ledger fact rather than part of fee_floor, so it is checked with the action’s own rules (RegistrationFeeTooLow), the way a call’s gas or tier part is charged once its proof is decoded. A call’s floor is checked twice, because what it declares is only trusted once its proof has verified. On a gas-metered chain (chain 21, as chains 18 to 20) the first check, before any verification, prices the call’s bytes and a declared limit of 1 (an Invoke also owes its cell fee there); the second prices the limit the verified proof declares. On a chain without a gas section the two are BUNDLE_BASE + CALL_BASE and the tier-exact floor.

Ask the node rather than guessing:

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 21's starting prices (chain 20's)

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

That answer is 1,000,000 + 100 × 20,479 + 800 × 1,319 at the starting prices; the node prices whatever the tip’s prices are when it is asked. Since chain 20 the call spec’s gas field is required over JSON-RPC (-32602 without it). rand fee call <tier> without --gas sends the tier’s ceiling, and without --bytes prices no bytes. An invoke is priced the same way, with "kind":"invoke" and "created_cells": c adding c cell fees (24103100 for the example above with two cells, asked of chain 20 on 2026-10-01). On chain 15, which had no gas section, rand fee call 14 answered 0.0022 RAND.

The wallet’s defaults are exactly the floors, except for a call on a gas-metered chain (chain 21), whose default adds headroom (below); rand send --fee <RAND> and the --fee flag on bond, call, bridge-mint, bridge-burn (default 0.01) and the token subcommands raise them. Anything above the floor is a tip.

Gas on chain 18

Chain 18, live from 2026-09-29 to 2026-10-01, was the first gas-metered chain, and chain 19, its re-genesis on the same build, carried the same gas section. Chain 20 (v0.6.8) kept every rule of this section and added two price ceilings and a byte load counted only on the bytes that pay (below). Chain 21 (v0.8.0, 2026-10-12) carries chain 20’s gas section unchanged but for the block’s byte target, which follows its smaller block cap. A chain without a gas section keeps the tier schedule in the table above.

What is counted. One gas is one row of the zkVM’s cpu table, so an ordinary instruction costs 1. The syscalls are the only other costs:

The declared limit. A call proof carries one public value more than before, GAS_LIMIT, and the circuit (constraint set 8) proves that the run’s gas is at or under it. The exact gas stays private. A limit above the ceiling of the proof’s own header is refused before any verifier key is built:

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

That is 1,279 at tier 10, 5,119 at tier 12 and 20,479 at tier 14 for a call that uses neither hash table.

The floor. The ledger charges the declared limit and the bytes, at the prices in force when the block starts:

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

bytes is the call proof plus the input envelope. The tier schedule and its free allowance do not apply on such a chain. The pool demands exactly what a block does, and refuses a cheaper call as FeeTooLow.

Bundles and the authorisation proof declare pinned limits. Every bundle proof must declare exactly the genesis bundle_gas_limit, 20,479 (the tier-14 ceiling), or the transaction is refused as BundleGasLimit. Chain 21, like every chain since 17, runs split authorisation, so every bundle carries a tier-10 authorisation proof, which must declare 1,279 (AuthGasLimit); a bundle authorised by a private multisig policy, new on chain 21, carries a tier-18 proof of the second auth guest instead (Transactions). Neither is a charge: a transfer, a bond or a deploy still pays its flat floor from the table above. The wallet declares both values itself.

The prices move. Since chain 18 the gas section has a dynamic controller, so gas_price and byte_price are ledger state, committed in the state root. Once per block, after its transactions, each moves by how full the block was against a target:

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

used is capped at twice the target, so adjust_bps is the largest move one block can make in either direction. max_price is the genesis ceiling; chains 18 and 19 had none. byte_price follows the block’s paying bytes (below); gas_price follows the sum of its calls’ and invokes’ declared limits plus 20,479 for every bundle.

A block under its targets moves the prices down, so on a quiet chain they sit at the floors. rand_getLimits serves the tip’s current gas_price and byte_price with gas_metering: "circuit", bundle_gas_limit, adjust_bps, and since v0.6.8 max_gas_price, max_byte_price and byte_load (null on a chain without them); rand_status reports the same two prices as gas_prices.

Ceilings and the paying byte load

Both are genesis fields of gas.dynamic, new in v0.6.8 (audit v6, POOL-2), and chain 20 is the first chain to set them. They fix a fault chains 18 and 19 had. There, byte_price moved with every transaction’s encoded length, while only a call pays it. Seven transfers (about 2.85 MB each, flat fee) fill a block to about 1.9 times the byte target and lift the price about 11% a block, with no ceiling: about 65 such blocks take it to 1,000 times its start, and a call then costs about 1 RAND instead of about 0.004.

• Ceilings. max_gas_price and max_byte_price are prices the controller never lifts past. The step is the same and then clamped (gas::next_price_capped), so a price at its ceiling stays there through any run of full blocks and falls on the first block under target. A genesis must set each at or above its starting price. At these ceilings (chain 21 keeps chain 20’s) the tier-14 call above, 20,479 gas and 1,319 KiB, has a floor of 0.3113 RAND, the highest its floor can go.
• The paying byte load. Under byte_load: "paying" the block’s bytes_used counts only the bytes the byte price is charged on: each Call’s and Invoke’s proof plus input envelope (gas::call_bytes), nothing of a transfer, a bond or a burn. A block of transfers moves no byte price. Ledger::block_usage computes the figure for both the proposer and the replica, so the two agree.

Under the paying load a block full of transfers gives a call no price signal, so an honest proposer also reserves room for calls. This is node policy, not a validity rule: while a call or an invoke is pooled and pays its current floor, flat-fee transactions take at most three quarters of the block’s bytes in the first pass, and what the calls leave of the last quarter is then filled with the transfers held back (Mempool).

What the wallet pays for a call

rand call runs the program in the emulator first and prints gas: <exact> (declaring <limit>, tier <t>). By default it declares the exact gas rounded up to a multiple of 2^(tier − 2); --gas-limit N declares an exact figure and --gas-limit max the header’s ceiling.

Two things make the default fee higher than the floor:

• The proof is priced at the cap. Since chain 16 (hardening_v6, chain 21 included) a call proof is bound to its own transaction, so the fee is fixed before the proof exists. The wallet prices the chain’s proof cap — 6 MiB on chain 21, 4 MiB on chains 18 to 20 — in place of the real proof size (wallet::hardened_call_quote_bytes). That can only overpay.
• Two price steps of headroom. rand_getLimits serves the committed head’s prices and a call lands two or three blocks later, so the default multiplies the floor by (1 + adjust_bps / 10,000)², which is 1.125² on chain 21, as on chain 20.

Measured on chain 18 on 2026-09-30, four calls cost between 0.0057 and 0.0075 RAND each at these defaults (Example programs). --fee overrides the default; the wallet re-prices the real proof before it submits and refuses a fee under its floor.

Where the fee goes

On chain 21 the floor is burned and the proposer keeps the tip. Chain 21’s genesis carries a fees section with burn_base and burn_floor set (fullnode v0.8.0; rand_getLimits.fee_rules serves it as {"burn_base": true, "burn_floor": true, "subsidy_net_of_fees": false, "proposer_share_bps": null, "prove_base": null, "usd_subsidy": null}). In every bundle’s fee split the ledger’s own floor for that bundle — BUNDLE_BASE for a transfer, a bond, a token action or an attestation; BUNDLE_BASE plus the per-word term for a Deploy; the tier-exact call floor at the block’s prices for a Call, plus the cell fee for an Invoke; BRIDGE_BURN_FEE for a BridgeBurn, so the bridge’s own charge is destroyed with the base — is burned (burned = min(fee, floor)), and the block proposer’s rewards in the validator register, the one place on this chain that stores an amount in the clear, grow by the tip, fee − floor, alone. rand_getSupply counts the burn in base_fees_burned, on the right of the supply identity beside registration_fees_burned (Supply), and fees_paid moves by what the proposer keeps. Nothing a sender pays changes: the floors and the wallet’s defaults are the numbers above, only where the floor goes differs. The faithful EIP-1559 form was chosen over burning the base alone so that a proposer gains nothing from a block that lifts a price. A registration’s registration_fee is not part of the floor; it burns under its own flag, as before.

On chains 15 to 20 all of it — floor and tip — was credited to the proposer, with one exception. On a genesis with tokens.burn_registration_fee (chain 21, as every chain since 15), a RegisterToken’s or RegisterBridgedToken’s registration_fee is burned and the proposer keeps fee − registration_fee; rand_getSupply counts it in registration_fees_burned. On chain 14, which lacked the flag, the proposer kept the whole fee. A validator turns accumulated rewards into a note with rand-node withdraw (Staking). There are no block rewards and no inflation on chain 21: tips are the whole of a validator’s income. A Withdraw’s base is paid register-side, out of the amount withdrawn, and never passes the bundle fee split, so it is not burned.

One fee since chain 20 is not RAND and goes to no validator. Under the genesis bridge.fees (new in v0.6.8, carried into chain 21) the bridge keeps 10 bps of every zUSD deposit and of every zUSD burn, rounded down to a whole release unit of the backing, as a zUSD note to a treasury address the genesis names. A deposit credits the depositor the gross less the fee; a burn releases amount − fee on the source chain. The fee note stays issued and backed. See Bridge and RPL tokens.

The mempool orders candidates by what they pay above their floor per KiB, then by fee (Mempool), so a higher fee only matters under congestion. A transfer is about 2.85 MB (measured on chain 18): a 1.49 MB bundle proof and a 1.36 MB authorisation proof, so about seven fit chain 20’s 20 MiB block and six chain 21’s 19 MiB one at that size (constraint set 9’s proof sizes on chain 21 are not measured here yet). The fullnode’s own note was that a fee market on bytes — not on opcodes — is what the floor should become before mainnet. Since chain 20 the byte price is that market for calls, moved only by the bytes calls pay for; a transfer’s floor is still flat, and since chain 21 it is burned.

Why gas is a price here, not a bound

Ethereum meters every opcode because every node executes every transaction and execution is open-ended. On Rand no node executes anything: the sender runs the program once, off chain, and hands the chain a proof. A node’s work per transaction is a fixed sequence — decode the public fields, run the free checks, verify one STARK — and that verification costs about 16 ms with a warm verifier key whatever the program did. So the three jobs of gas fall apart:

• Termination is enforced by the tier: a run that does not halt within 2ᵗ − 1 cycles cannot be proved at all, and the prover absorbs the failure.
• Pricing the work is what the gas floor does, since chain 18. The network’s cost per instruction is near zero, but the sender’s proving work is real, and a flat floor priced a million-cycle call like a thousand-cycle one. Until chain 18 the floor was flat per tier.
• Block sizing is a byte budget (MAX_BLOCK_BYTES = 4 MiB by default, the genesis max_block_bytes otherwise) and a transaction count (2,000).

Two caveats the fullnode states plainly: bytes do vary (a proof is over a megabyte, so block space, not compute, is the scarce resource), and state growth — the tree, the nullifier set, deployed program bytes — is priced only by the per-word deploy fee and the flat base, which is adequate for a testnet and worth revisiting when state size matters.

What the sender pays instead: proving

The one cost that varies is producing the STARK proof, and only the sender’s machine pays it. In order of effect:

1. The tier t ∈ {10, 12, 14, 16, 18, 20} (a call above 14 is refused on chain since v0.5.6; a bundle is pinned to 14, and since chain 17 carries a tier-10 authorisation proof beside it, about 7 s more): the cpu table is padded to 2ᵗ rows and each step roughly quadruples the padded trace. Measured on the development laptop: private_payment at tier 10 in about 7 s; the hidden-asset bundle guest at tier 14 in about 100 s, whichever asset it moves.
2. Cycles executed, because they decide the tier: instructions run, not instructions written.
3. Program size, weakly: one digest row per four words at the start of the trace.
4. Private-input size, the same way.
5. Which tables are present: a keccak or sha256 table costs its columns’ share only when the guest used it.
6. The FRI profile: 80 queries instead of 27 triples proof size but barely changes proving time.

Proving does not depend on the amounts, on how many notes the sender owns, or on the chain’s size: membership is proved against a fixed-depth tree, so a transfer costs the same at block ten and block ten million.

Reference