Yuma Consensus

An explanation of Yuma Consensus, the Bittensor mechanism that aggregates validator weights into miner incentives and validator dividends.

Yuma Consensus is the Bittensor consensus mechanism that turns validator weight signals into miner incentives and validator dividends. Validators evaluate miner work inside a subnet, submit weights, and Yuma Consensus aggregates those weights into the reward outcomes used by the subnet (Yuma Consensus, Glossary: Yuma Consensus, Glossary: Validator Weights).

The term belongs to the consensus layer of subnet incentives. It does not describe the off-chain scoring system that produced the weights, and it does not replace the emission process that later allocates value through Bittensor tokenomics (Understanding Incentive Mechanisms, Emissions).

Aggregation and Outcomes

Yuma Consensus aggregates validator evaluations into miner incentives and validator dividends. Incentives are the miner-side reward outcome, while dividends are the validator-side reward outcome inside the same consensus flow (Yuma Consensus, Glossary: Incentives, Glossary: Dividends).

That makes Yuma Consensus an allocation mechanism rather than a general performance label. It answers how many validator signals are combined into reward outcomes, not what task a subnet asks miners to perform or how a validator produced each score (Glossary: Incentive Mechanism).

The output vocabulary is also role-specific. Incentives belong to miner-side outcomes, dividends belong to validator-side outcomes, and Yuma Consensus is the mechanism that links validator weights to those outcomes inside a subnet.

Bonds and Alignment

Validator-miner bonds are part of the Yuma Consensus reward path. Bond values represent smoothed relationships between validators and miners and help connect validator-side outcomes to evaluation quality over time (Glossary: Validator-Miner Bonds, Yuma Consensus).

YC3 belongs near this context because it refines validator-miner bond scaling. The base term Yuma Consensus names the broader aggregation process, while Yuma Consensus 3 names a later refinement around bond responsiveness (How Yuma Consensus 3 Makes Bittensor More Fair).

When a validator assigns a miner weight above the clipped consensus benchmark, the bond update blends that submission toward the benchmark rather than accepting the full value. A configurable penalty factor controls how strongly out-of-consensus weights are pulled back toward the consensus level, and an exponential moving average then smooths validator-miner bonds across epochs (Yuma Consensus, Consensus-based Weights).

Validators who stay near consensus build stronger smoothed bonds and therefore participate more fully in validator-side emission allocation, while repeated over-evaluation relative to the benchmark erodes bond contribution over time.

Input and Output Scope

Yuma Consensus turns validator weighting activity into consensus and incentive outcomes. It is not a single raw score, a subnet task definition, or a substitute for emission accounting (Yuma Consensus, Emission).

Weights, consensus measures, ranks, trust, bonds, incentives, dividends, and emissions are related but not interchangeable. A precise claim needs the part of the mechanism it is using.

Validator weights are the main input vocabulary for Yuma Consensus. They are per-validator evaluation signals for miners, formed after subnet-specific scoring and then used by consensus to calculate outcomes (Glossary: Validator Weights, Understanding Incentive Mechanisms).

That input boundary separates Yuma Consensus from the off-chain scoring process. A subnet’s incentive mechanism defines how work is measured, while Yuma Consensus combines the resulting validator weights after they are available to the consensus process (Yuma Consensus, Glossary: Yuma Consensus).

Development Stage Context

The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Yuma Consensus on a subnet such as netuid 1, that sequence changes how readers should interpret weight aggregation, miner incentives, and validator dividends.

In localnet, Yuma Consensus examples can be exercised in an isolated environment. Local weight aggregation and emission outcomes reflect local chain configuration rather than production subnet rewards.

On testnet, Yuma Consensus can be observed in a shared, non-production network. Testnet consensus outcomes on a selected netuid are separate from mainnet subnet state (Yuma Consensus).

On mainnet, Yuma Consensus is the live production mechanism that aggregates validator weights into subnet emission outcomes on the connected Bittensor network.

The Bittensor Networks reference separates mainnet, testnet, and localnet. A Yuma Consensus example from one environment should not be read as representing production consensus outcomes on another network.

Trust Measures How Much Rank Survived Clipping

Inside Yuma Consensus, trust is the ratio of final rank to pre-rank. It shows how much of the original validator support remained after consensus clipping (Glossary: Rank).

That ratio describes clipping impact rather than subnet task quality. A miner can show strong pre-rank support yet lower trust when outlier weights were removed before the aggregate rank was calculated. Trust therefore answers how much evaluation signal survived filtering, not whether the miner performed useful work under the subnet’s incentive mechanism.

Validator trust is a separate validator-side metric. It sums clipped weights a validator successfully contributed across neurons, which measures that validator’s influence inside the consensus process rather than miner-side rank change.

Dividends Combine Bonds With Miner Incentives

Each validator’s share of validator-side emissions equals the sum of that validator’s validator-miner bonds multiplied by each miner’s incentive outcome (Yuma Consensus: Validator emissions).

That pairing links the two reward sides inside one consensus flow. Incentives name miner-side outcomes produced from clipped and aggregated weight signals, while dividends name validator-side outcomes derived from bond strength relative to those miner results.

Dividend calculation uses smoothed exponential moving average bond values rather than instantaneous bond readings alone, so a dividend claim depends on both bond history and the miner incentive outcomes being paired in the same epoch (Consensus-based Weights).

Clipping Compares Submissions to a Consensus Benchmark

Yuma Consensus runs a clipping step before final reward outcomes are calculated. Clipping is designed to punish inaccurate miner evaluation, especially patterns that could manipulate consensus to favor certain miners (Yuma Consensus: Clipping).

For each miner column, Yuma derives a per-miner clipping benchmark from validator-submitted weights using the subnet’s kappa stake fraction. Documentation describes that consensus score benchmark as the maximum weight level that still has at least that fraction of stake-weighted validator support (Yuma Consensus: Clipping, Glossary: Consensus Score).

Each validator’s submitted weight toward a miner is then capped to that benchmark before it contributes to final rank and downstream incentive allocation (Yuma Consensus: Clipping).

When a submitted weight exceeds the clipped benchmark for a miner, neither the miner nor the submitting validator receives emissions for the excess portion. Clipping therefore turns raw validator submissions into a post-filter signal that later drives incentive allocation rather than passing every submitted value through unchanged.

With the default kappa near 0.5, at least half of stake-weighted validator support must agree that a miner deserves weight above a given level before more generous weights are left unclipped (Yuma Consensus: Clipping, Subnet Hyperparameters).

Readers should not treat kappa as a miner-quality score. It governs how aggressively outlier weights are trimmed relative to stake-backed consensus, not how useful a miner’s subnet work was in isolation (Glossary: Consensus Score).

The Weight Matrix Feeds Each Consensus Pass

Each validator on a subnet submits a weight vector ranking miners it has evaluated. Yuma Consensus treats those vectors as rows in a matrix of validator evaluations rather than as isolated scores. The on-chain process reads that combined input and resolves it into two emission vectors — one for miners and one for validators — that allocate each tempo’s subnet emissions by role (Yuma Consensus).

That matrix framing keeps input and output vocabulary separate. Validator weights name the submitted evaluations; miner and validator emission shares name the two allocation results produced after aggregation, clipping, bonding, and normalization inside the same epoch (Glossary: Weight Matrix, Emissions).

Distinction from Epoch

Yuma Consensus names how validator weights are aggregated into miner incentives and validator dividends. Epoch names the consensus period in which those weights are processed on the selected subnet (Yuma Consensus, Glossary: Epoch).

  • Yuma Consensus — aggregation rules for weights, clipping, and bonds.
  • Epoch — the bounded period when those rules run.

Distinction from Tempo

Yuma Consensus produces miner and validator outcomes from submitted weights. Tempo is the subnet epoch boundary where accumulated injection is distributed to participants (Glossary: Tempo, Emission, Yuma Consensus).

Consensus vocabulary belongs to weight processing inside the pass. Tempo vocabulary belongs to the payout cadence at the end of that subnet epoch.

Distinction from Coinbase

Coinbase is the per-block runtime step that advances emission processing on Subtensor. Yuma Consensus is the validator-weight aggregation process that runs at epoch boundaries to turn those weights into miner incentives and validator dividends (Coinbase Implementation, Yuma Consensus).

Coinbase vocabulary belongs to per-block issuance advancement. Yuma vocabulary belongs to epoch consensus aggregation on the selected subnet.

Distinction from Kappa

Kappa sets the stake threshold used when clipping validator weights during Yuma Consensus. Yuma Consensus is the broader aggregation process that includes clipping, bonding, and emission allocation (Glossary: Kappa, Yuma Consensus).

Kappa vocabulary names one clipping parameter inside the pass. Yuma vocabulary names the full consensus flow that uses that parameter.

Distinction from Consensus Score

Consensus score is the per-miner clipping benchmark derived from stake-weighted agreement at the subnet’s kappa threshold. Yuma Consensus is the full process that uses that benchmark when producing miner rank and validator-side outcomes (Glossary: Consensus Score, Yuma Consensus: Clipping).

Consensus-score vocabulary names the per-miner agreement benchmark inside clipping. Yuma vocabulary names the aggregation process that applies it on the selected subnet.

  • Consensus score — per-miner agreement benchmark inside the clipping step.
  • Yuma Consensus — full aggregation process that applies that benchmark on the selected subnet.

Distinction from Governance

Yuma Consensus allocates subnet incentives from validator weights and stake context on a subnet, while governance handles privileged network changes through proposal review (Yuma Consensus, Governance Overview).

Senate stake thresholds and proposal review do not replace validator scoring or emission allocation on a subnet; the two name different layers of the network.

Distinction from Flow-Based Emissions

Yuma Consensus resolves validator weight signals into tempo-bound miner and validator outcomes inside a subnet, while flow-based emissions compare subnets before that within-subnet consensus path runs (Yuma Consensus, Emission: Distribution).

Flow vocabulary belongs to cross-subnet injection ranking; Yuma vocabulary belongs to within-subnet allocation once a subnet’s share has arrived.

Distinction from Emission Split

An emission split states how much alpha each role receives at tempo end, while Yuma Consensus then divides the miner share by rank and credits the validator share through bonded evaluation (Yuma Consensus, Emission: Distribution).

The split names the role proportions; Yuma names the rules that subdivide each role’s share once those proportions are set.

Distinction from Subnet Stake Burn

Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends through clipping, bonding, and emission calculation, while subnet stake burn names a specific tokenomics mechanism within that incentive picture (Yuma Consensus, Subnet Stake Burn, Emission).

Consensus-process vocabulary and stake-side tokenomics vocabulary answer different questions. Yuma Consensus names how validator weights become incentives and dividends; subnet stake burn names a stake-side movement rather than the consensus math (Yuma Consensus).

  • Yuma Consensus — process that turns validator weights into incentives and dividends.
  • Subnet stake burn — stake-side tokenomics mechanism, not consensus computation.

Distinction from Subnet 1: Apex

Apex on netuid 1 is a competition-based subnet where validators score miner submissions against rotating benchmark tasks. Yuma Consensus is the separate mechanism that aggregates those validator weights into emission shares each tempo (Yuma Consensus, Emission).

  • Subnet 1 (Apex) — competition-scored benchmark subnet.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Subnet Weights

Subnet weights name the relative cross-subnet share of TAO injection assigned to each netuid. Yuma Consensus is the separate mechanism that converts validator weight submissions into emission shares within a subnet each tempo (Yuma Consensus, Emission).

  • Subnet weights — relative cross-subnet share of TAO injection.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Bittensor Platform Components

Bittensor platform components is a high-level map across subnets, chain state, tokens, roles, tools, and network environments. Yuma Consensus is the mechanism that aggregates validator weights into emission shares each tempo (Introduction to Bittensor, Yuma Consensus).

  • Bittensor platform components — orientation map across major system pieces.
  • Yuma Consensus — consensus mechanism that turns validator weights into incentives and dividends.

Orientation vocabulary and consensus-mechanism vocabulary answer different questions on the same platform path (Emission).

Distinction from Subnet Deregistration

Subnet deregistration names the removal of an entire subnet when the global subnet cap binds. Yuma Consensus is the separate mechanism that converts validator weight submissions into emission shares each tempo on subnets that remain active (Yuma Consensus, Emission, Subnet Deregistration).

  • Subnet deregistration — lifecycle removal of a whole subnet at the cap.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Subnet Hyperparameters

Subnet hyperparameters name the per-subnet protocol settings that govern timing, limits, and registration behavior. Yuma Consensus is the separate mechanism that converts validator weight submissions into emission shares each tempo (Yuma Consensus, Emission, Subnet Hyperparameters).

  • Subnet hyperparameters — owner-settable protocol envelope for a subnet.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Subnet Markets

Subnet markets name the incentive-based economic setting where miners, validators, and stakers interact inside a subnet. Yuma Consensus is the separate mechanism that converts validator weight submissions into emission shares each tempo (Yuma Consensus, Emission, Understanding Subnets).

  • Subnet markets — work-and-evaluation economic setting inside a subnet.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Yuma Consensus 3

Yuma Consensus 3 and Yuma Consensus relate as a refinement and the broader process. Yuma Consensus is the aggregation that turns validator weight signals into miner incentives and validator dividends, while YC3 is a bond-scaling refinement inside that process rather than a separate consensus system (Yuma Consensus, How Yuma Consensus 3 Makes Bittensor More Fair).

  • Yuma Consensus — the process that aggregates weights into emissions.
  • Yuma Consensus 3 — a bond-scaling refinement inside that process.

Distinction from Arbitrage

Arbitrage names trading that exploits price differences across markets or pools. Yuma Consensus is the separate subnet mechanism that converts validator weight submissions into emission shares each tempo and does not by itself execute trades (Yuma Consensus, Emission).

  • Arbitrage — trading that exploits price differences.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Bittensor Emissions

Bittensor emissions name the full generation and allocation process that distributes TAO and alpha to participants inside and across subnets. Yuma Consensus is the subnet-level mechanism that converts validator weight submissions into miner and validator shares within that broader process each tempo (Emission, Yuma Consensus).

  • Bittensor emissions — full generation and allocation of network rewards.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Bittensor EVM Smart Contracts

Bittensor EVM smart contracts name Ethereum-compatible contracts executed on Subtensor. Yuma Consensus is the separate subnet process that converts validator weight submissions into emission shares each tempo and is not itself an EVM contract execution path (Bittensor EVM Smart Contracts, Yuma Consensus, Emission).

  • Bittensor EVM smart contracts — EVM-compatible contracts on Subtensor.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Blockchain Validator vs Subnet Validator

Blockchain validator versus subnet validator names two validator roles at different layers: network block production and subnet work evaluation. Yuma Consensus is the separate subnet mechanism that converts subnet validator weight submissions into emission shares each tempo (Glossary: Blockchain Validator vs Subnet Validator, Glossary: Subnet Validator, Yuma Consensus, Emission).

  • Blockchain vs subnet validator — chain production versus subnet evaluation roles.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Crowdloans

Crowdloans name the collective funding structure that pools TAO toward a specified extrinsic or transfer, with subnet creation as the primary documented example. Yuma Consensus is the separate mechanism that converts validator weight submissions into emission shares each tempo (Crowdloans, Yuma Consensus, Emission).

  • Crowdloans — collective funding toward a specified on-chain action.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Delegate

A delegate is a subnet validator that receives staked TAO from delegators and performs validation tasks in one or more subnets. Yuma Consensus is the separate mechanism that converts validator weight submissions into emission shares each tempo (Glossary: Delegate, Yuma Consensus, Emission).

  • Delegate — validator role that receives delegated stake.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Drand Time-Lock Encryption

Drand time-lock encryption and Yuma Consensus act at different stages. Time-lock encryption controls when committed weights become readable, while Yuma Consensus aggregates the revealed weights into miner incentives and validator dividends after the concealment interval ends (Glossary: Drand/time-lock encryption, Yuma Consensus).

  • Drand time-lock encryption — controls when committed weights can be read.
  • Yuma Consensus — aggregates the revealed weights into emissions.

Distinction from Liquidity Provider Rewards

Liquidity provider rewards name returns earned from providing liquidity in subnet pools. Yuma Consensus is the separate mechanism that converts validator weight submissions into miner and validator emission shares each tempo (User Liquidity Positions, Yuma Consensus, Emission).

  • Liquidity provider rewards — returns from subnet pool liquidity provision.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Mechanism Count

Mechanism count is the hyperparameter that sets how many incentive mechanisms run on a subnet. Yuma Consensus is the aggregation path those mechanisms use to combine validator weights (Subnet Hyperparameters, Yuma Consensus).

  • Mechanism count — configured number of incentive mechanisms on a subnet.
  • Yuma Consensus — weight-aggregation path inside each mechanism.

Count vocabulary sets how many paths run; Yuma vocabulary names how weights combine on each path (Multiple Incentive Mechanisms Within Subnets).

Distinction from Metagraph

The metagraph is Bittensor’s structured view of state for a selected subnet. Yuma Consensus is the separate on-chain mechanism that converts validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).

  • Metagraph — bittensor metagraph describes subnet neuron state at a particular block height.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Mining And Validating

Mining and validating name the complementary work-producing and evaluation roles inside Bittensor subnets. Yuma Consensus is the separate mechanism that converts validator weight submissions into emission shares each tempo (Mining, Yuma Consensus, Emission).

  • Mining and validating — complementary miner and validator roles.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Max Validators

Max validators is a per-subnet hyperparameter that caps how many neurons may hold validator permits and submit weights that can enter consensus. Yuma Consensus is the separate tempo process that aggregates those permitted validator weight submissions into emission shares each epoch (Subnet Hyperparameters, Yuma Consensus, Emission).

  • Max validators — configured ceiling on validator permits for a subnet.
  • Yuma Consensus — mechanism that turns validator weights into emission shares.

Distinction from Timing

Yuma Consensus runs across subnet timing concepts such as tempo and epoch. Tempo is the block-based cadence for subnet epochs, and an epoch is the consensus period in which submitted weights are processed into outcomes (Glossary: Tempo, Glossary: Epoch).

Commit Reveal is a related visibility layer. It can conceal validator weight information until a later reveal time, while Yuma Consensus is the aggregation layer that uses available weights for reward outcomes (Commit Reveal, Yuma Consensus).

The timing vocabulary matters because Yuma Consensus is not a continuously visible score for every moment. It is read through subnet cadence, weight availability, and the consensus period being processed.

Distinction from Mechanism

Some subnets can run multiple incentive mechanisms, each with its own evaluation context and bond pool for Yuma Consensus calculations. A Yuma Consensus statement should therefore keep the relevant mechanism context visible when a subnet has more than one mechanism (Multiple Incentive Mechanisms Within Subnets, Glossary: Multiple Incentive Mechanisms).

  • Incentive mechanism — subnet evaluation setting that defines what work is scored.
  • Yuma Consensus — aggregation path that combines validator weights for each mechanism context.

Reader Boundary

Yuma Consensus is a reference term for Bittensor’s validator-weight aggregation process. It is not a validator strategy, subnet ranking table, point-in-time reward report, or guide to changing subnet behavior (Yuma Consensus, Bittensor Networks).

Concrete examples need the selected subnet, mechanism context, network environment, epoch context, and source. Without those boundaries, a Yuma Consensus claim can overstate what the mechanism alone proves.

Further Reading

Topics ConsensusIncentives