Transaction Fees
Transaction fees are costs the Bittensor chain can attach to state-changing actions (Transaction Fees in Bittensor).
The term describes chain-processing costs. It is separate from chain reads, swap fees, batch grouping, and every other economic effect that can appear near a transaction.
Base Fee Components
The official fee documentation describes base transaction fees as having weight and length components (Transaction Fees in Bittensor).
Weight is tied to computational load, while length is tied to transaction size. This base-fee context belongs to the state-changing action, not to passive observation.
Fee-bearing extrinsics pay both components from the sender’s TAO free balance. The weight fee is
based on the ref_time part of transaction weight, and the length fee is charged per encoded byte
(Transaction Fees in Bittensor).
The fee documentation states the total base transaction fee as the sum of the weight fee and the
length fee. For length, the documented charge is 1 rao per byte of the encoded extrinsic. For
weight, the documented formula scales the ref_time component by 50,000 / 10^9 rao
(Transaction Fees in Bittensor).
This makes weight a fee-input measure, not a promise that an extrinsic will be included or succeed. The extrinsic reference still describes the runtime call being submitted, while the fee reference describes how a fee-bearing submission is charged (Subtensor extrinsics, Transaction Fees in Bittensor).
A base-fee example can therefore describe the charge formula without describing every economic effect around the transaction. Swap fees, batch wrapper overhead, and recycling accounting remain nearby fee concepts, but they answer different parts of the cost picture.
Fee-Free and Alpha Cases
The fee documentation lists fee-free extrinsics that pay neither the weight component nor the length
component. The examples include set_weights, commit_weights, reveal_weights, and sudo
(Transaction Fees in Bittensor).
Alpha fallback is a separate fee-payment case. When the sender’s TAO balance is insufficient, the fee documentation describes transaction fees being paid in alpha instead (Transaction Fees in Bittensor).
The fee-free list is about whether the chain charges the base components at all. Alpha fallback is about the asset used to pay fees when a fee-bearing transaction cannot be covered by TAO.
These cases should not be collapsed into one rule. A fee-free extrinsic is listed as not paying the base components; alpha fallback is still a fee-payment path, only with a different asset source (Transaction Fees in Bittensor).
Reads, Swaps, and Batches
The fee documentation identifies chain reads as free (Transaction Fees in Bittensor).
That distinction matters because reading chain state does not ask Subtensor to record a state change. Fee language should stay attached to state-changing actions rather than every form of chain inspection (Subtensor Storage, Transaction Fees in Bittensor).
The same distinction helps when a read appears immediately before a transaction. The read can show state used by the user or interface, while the later submitted action is the fee-bearing event (Transaction Fees in Bittensor, Subtensor Storage).
The fee documentation treats swap fees as separate from base transaction fees (Transaction Fees in Bittensor).
A stake-related action can therefore involve more than one cost concept. The base fee belongs to the chain action, while a swap fee belongs to the liquidity-linked part of the action. The two can appear near each other without meaning the same thing.
The fee page gives the swap fee as 0.05% of transacted liquidity for staking and unstaking operations (Transaction Fees in Bittensor). That percentage belongs to the amount-based swap-fee side of the action, while the base transaction fee still follows weight and length.
Batch transaction documentation describes grouped calls, and the fee documentation describes batch fees as combining inner-call behavior with batch-wrapper overhead (Batch Transactions, Transaction Fees in Bittensor).
This means grouped activity should still be read through its components. A batch is a grouped submission pattern, not a way to erase fee-bearing activity inside the batch.
Together, these neighboring concepts keep the transaction-fee term narrow. Reads are inspection, swap fees are liquidity-linked, and batches describe grouped submission; none of those labels replace the base fee components.
Recycling and Network Context
The recycling and burning glossary entry describes collected transaction fees as recycled tokens deducted from the issuance record for future emission (Recycling and burning).
That places transaction fees near issuance accounting. Recycling explains where collected fees go in the issuance record; it does not change what the fee was charged for.
The fee documentation also places paid base fees in that accounting context by describing collected
base fees as deducted from TotalIssuance
(Transaction Fees in Bittensor).
Bittensor documentation separates mainnet, testnet, and localnet contexts (Bittensor Networks).
A fee example from one environment should not be treated as proof about another environment. Localnet examples can show controlled behavior, testnet examples can show shared non-production conditions, and mainnet references need separate support from mainnet-specific material.
Network context is especially important for examples. A formula or category from the fee reference can describe the concept, while an observed fee from one environment remains an observation from that environment.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For transaction fees, that sequence changes how readers should interpret fee quotes and RAO-denominated charges across environments.
In localnet, transaction-fee examples can be exercised in an isolated environment. Local fee parameters reflect local chain configuration rather than production fee levels.
On testnet, transaction fees can be observed in a shared, non-production network. Testnet fee quotes are separate from mainnet extrinsic costs (Understanding Fees).
On mainnet, transaction fees are live production charges for extrinsic length and weight on the connected Bittensor network (Glossary: RAO).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A fee example from one environment should not be read as representing production transaction costs in another environment.
Relationship to Yuma Consensus
Transaction Fees and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).
For readers, transaction fees names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.
Reader Boundary
Transaction fees should not be read as a permanent quote for every action, a calculator result, or a complete description of all costs that can appear near a transaction. The term names chain-processing costs tied to state-changing extrinsics on Subtensor (Transaction Fees in Bittensor, Glossary: Subtensor).
Use transaction fee language for base weight-and-length costs on state-changing actions. Use neighboring vocabulary when the question is a read, swap fee, batch wrapper, recycling accounting record, or a fee observation tied to one network environment (Bittensor Networks).
Weight Submissions Can Be Fee-Free
Official Transaction Fees in Bittensor documentation
lists fee-free extrinsics that pay neither the weight nor the length component, including
set_weights, commit_weights, and reveal_weights. Consensus participation through weight
submission therefore does not carry the same base fee formula as many other state-changing actions
(Glossary: Validator Weights).
Fee-free listing is separate from swap fees or alpha fallback. It names extrinsics the chain does not charge through the standard weight-and-length base formula.
Staking and Unstaking Swap Fees Are Separate
The same fee documentation treats swap fees as distinct from base transaction fees and gives staking and unstaking swap fees as 0.05% of transacted liquidity. A stake-related action can therefore involve both a base chain fee on the extrinsic and a liquidity-linked swap fee on the converted amount (Staking and delegation overview, Understanding Slippage).
Transaction fee vocabulary should stay attached to the chain-processing charge, while swap fee vocabulary belongs to the pool conversion side of the same user action.
Collected Base Fees Reduce Total Issuance
Fee documentation states that paid base fees are deducted from total issuance, and the Recycling and burning glossary entry describes collected transaction fees as recycled tokens removed from the issuance record for future emission (Glossary: Emission).
That accounting path explains where base fees go after payment. It does not change what triggered the fee, but it connects chain charges to broader tokenomics vocabulary.