Non-fast Blocks
Non-fast blocks are ordinary local block timing in Bittensor development context. The term is paired with fast blocks: non-fast blocks keep the default local interval, while fast blocks accelerate local block production (Glossary: Non-fast blocks, Glossary: Fast blocks, Bittensor Networks).
The distinction matters because both terms belong to local development. They are timing labels for an isolated local chain, not labels for subnet rewards or public network status.
Local Timing Context
Non-fast blocks describe the ordinary timing side of local block production. In this mode, local blocks follow Subtensor’s default twelve-second interval rather than the accelerated cadence used by fast blocks (Glossary: Non-fast blocks, Glossary: Fast blocks).
For readers, the useful point is the tradeoff. Non-fast blocks preserve production-like timing for a local chain, while fast blocks make local feedback quicker.
Localnet block processing can run at one block every 0.25 seconds in fast-block mode or one block every 12 seconds in non-fast-block mode (Bittensor Networks). Non-fast blocks therefore name the local mode that keeps the ordinary 12-second cadence.
Mainnet and testnet also use one block every 12 seconds (Bittensor Networks). The matching cadence does not make a local non-fast-block example equivalent to mainnet or testnet evidence; the environment label still matters.
This separates cadence from evidence scope. Non-fast blocks can make local timing feel closer to public-network timing, but the result still comes from an isolated local chain. A matching 12-second cadence can help comparisons, but it does not move the evidence out of localnet.
Local Blockchain Context
Non-fast blocks sit inside local blockchain context. A local blockchain is a private chain for development and testing, and non-fast blocks name one timing choice inside that private environment (Glossary: Local Blockchain, Glossary: Non-fast blocks).
This keeps the chain concept separate from the timing setting. Local blockchain names the isolated chain; non-fast blocks describe how quickly that chain produces blocks.
The private-chain boundary matters when an example depends on block passage. Non-fast blocks can make local waiting time longer than fast-block mode, but the behavior still belongs to the local chain being run for development.
Localnet Boundary
Localnet is the local network environment. Non-fast blocks are a block-timing mode within that environment rather than a separate network type (Bittensor Networks, Glossary: Non-fast blocks).
For readers, localnet answers where the example belongs. Non-fast blocks answer what timing cadence the local chain is using.
This is why the phrase should stay attached to local examples. Non-fast blocks are a local timing mode, while localnet is the environment where that timing mode is used.
Fast-Block Contrast
Fast blocks and non-fast blocks name opposite sides of one local timing distinction. Fast blocks speed up local block production; non-fast blocks keep the ordinary local cadence (Glossary: Fast blocks, Glossary: Non-fast blocks).
That contrast is local-only. It helps readers understand testing cadence without turning either term into a production-network rule.
The pair is useful when an example depends on blocks passing. Fast blocks shorten the wall-clock wait for local block-counted behavior, while non-fast blocks keep the local wait closer to the 12-second cadence used outside fast-block local mode (Rate Limits, Bittensor Networks).
The block count and the timing mode answer different questions. A block-counted rule still counts blocks, while the selected local mode changes how quickly those local blocks are produced.
This distinction is useful for cooldowns, epochs, and other block-counted examples. The rule may be described in blocks, while the chosen local timing mode determines how much wall-clock waiting a developer sees.
Block-Counted Rules
Some Bittensor behavior is easier to reason about in block counts than in wall-clock seconds. Rate limits, epochs, and local testing examples can all depend on how many blocks have passed (Rate Limits, Glossary: Epoch).
Non-fast blocks do not change the rule being counted. They change the local cadence at which blocks arrive, so a block-counted example takes longer in non-fast-block mode than it would in fast-block mode. That makes the timing mode important for local testing while leaving the block-counted rule as the underlying reference.
Development Stage Context
Bittensor separates localnet, testnet, and mainnet environments. Non-fast blocks belong to localnet timing, while testnet and mainnet use their own shared network contexts (Bittensor Networks, Introduction to Bittensor: Subnet development).
A local non-fast-block example can illustrate ordinary local timing. It should not be read as a testnet or mainnet outcome, even when the 12-second cadence matches the public-network cadence.
Relationship to Yuma Consensus
Non-fast Blocks 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, non-fast blocks 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
Non-fast blocks should be read as a concept article term for local timing. They are not a subnet mechanism, reward rule, public-chain status label, or claim about every Bittensor environment (Glossary: Non-fast blocks, Bittensor Networks).
The stable point is that non-fast blocks keep ordinary block timing in local Bittensor development context, mainly by contrast with fast blocks. A block-counted rule still counts blocks; the selected local timing mode changes how quickly those local blocks arrive (Rate Limits).