Gas, Fixed Fees, and the 70/20/10 Split

What the word actually means

Gas is a meter. A program runs, each step costs a defined amount, you set a limit and a price per unit, and you pay for what was consumed rather than for what you asked for.

It exists to price arbitrary computation. It is the answer to "how do we charge for a program whose cost nobody can know in advance".

And this chain has none of it

The word does not appear once in the base-layer crates: not in the transaction types, not in the executor, not in consensus, not in the interface layer.

CONTROL: the same search finds gas limits, gas prices and gas usage repeatedly in the subnet crate, where Ethereum-shaped transactions are decoded. So the searcher finds the vocabulary where it exists, and its absence from the base layer is a reading rather than a failed query.

A block here carries no gas field either. Measured directly against the live endpoint: a block has a height, a round, hashes, a timestamp, a proposer, a transaction count and its transactions. Nothing about consumption.

What it has instead, and why that is defensible

A flat price per operation type. A named constant for each, at two tiers: most operations at one figure, and creating an identifier or performing a guardian recovery at ten times it. Eight operation types are exempt entirely.

This is a reasonable design for what this chain does. Metering prices unpredictable computation, and the base layer here has none: every payload is a fixed-shape identity or value operation whose cost genuinely does not vary with its contents.

The honest way to say it is that the pricing matches the workload, not that gas was unnecessary in general. The moment arbitrary programs run on the base layer, a price list stops working.

So "does Solidus have gas" has two answers

At the base layer, no, and nothing in the code pretends otherwise.

Inside the subnet that executes Ethereum-shaped transactions, yes, because that is what those transactions carry.

Nothing in the vocabulary distinguishes the two layers, so a reader asking the question of the project as a whole can be told either answer truthfully. That is a documentation problem rather than a design one, and this page is part of it.

And here is the part worth the page: the split as designed is not the split as running

Fees collected in a block are distributed. The model is seventy per cent split equally among validators, twenty per cent to a treasury, and the remainder burned by simply not being credited.

The live call passes an empty validator list. A comment beside it names the reason: the value is not plumbed through the consensus configuration yet.

The function skips the validator share entirely when the list is empty. So the seventy per cent is computed for nobody, credited to nobody, and joins the burn.

Effectively: twenty per cent to the treasury and eighty per cent destroyed, against a stated model of seventy, twenty and ten.

Sized honestly, and then not dismissed

Nothing of value is being burned. The unit on this network has no market, no listing and no price, and the volumes involved are trivial because almost nothing transacts.

The reason it still matters is that the model people will argue about later is not the model that is running. Anybody reasoning about validator economics from this code would reason about a share that is never paid, and would find nothing in the running chain to contradict them.

What is genuinely right here

Fees are charged before the operation runs, so a failure still pays rather than being free to retry.

The exemptions are principled and the code says why: identifier anchors are value-free by construction.

And the burn is honest: the remainder is simply not credited to anybody, rather than sent to an address nobody holds and counted as supply.

What you can check yourself

fetch any block and look for a gas field, a limit, or a consumption figure

There is none. Then fetch a receipt and note that fee_paid is a flat figure per operation type, the same every time for the same kind of transaction.