Mempool
The Bittensor mempool is the pending-transaction holding area before block inclusion. It names the state where unconfirmed transactions wait before they become part of a block (Glossary: Mempool, Glossary: Block).
The useful distinction is pending versus included. A mempool entry is not yet final chain history; a block is the unit that records included transactions.
Pending Transaction Context
Mempool vocabulary belongs to the interval after a transaction enters the pending area and before block inclusion. During that interval, the transaction is waiting to be processed into chain history (Glossary: Mempool, Glossary: Block).
This makes the mempool a timing and state concept rather than a reward mechanism. It explains where pending transactions sit, not whether an action will ultimately succeed.
Submission Versus Inclusion
Submitting an extrinsic and seeing final chain history are separate moments. The Subtensor extrinsics reference describes extrinsics as calls submitted to the chain, while the glossary defines the mempool as the waiting area for transactions before block inclusion (Subtensor extrinsics, Glossary: Mempool).
For readers, that means a submitted action should not be treated as recorded just because it has entered the pending stage. The stronger claim starts after inclusion in a block, when the transaction belongs to chain history rather than the mempool.
Block Boundary
Blocks are the chain units that contain transactions. The mempool is the waiting area before that inclusion happens (Glossary: Block, Glossary: Mempool).
Once a transaction is included in a block, it should be treated as block history rather than a merely pending mempool entry.
Extrinsic Boundary
Extrinsics are runtime actions. In Bittensor context, an accepted extrinsic can pass through the pending-transaction stage before block inclusion (Subtensor extrinsics, Glossary: Mempool).
This keeps the concepts separate. Extrinsic names the action surface; mempool names the pending state before inclusion.
Fee Boundary
Some state-changing actions carry transaction fees. The fee model belongs to the action being processed, while the mempool names the pending area where unconfirmed transactions wait (Transaction Fees in Bittensor, Glossary: Mempool).
The mempool does not set fee rules. It sits before the block-processing stage where the chain evaluates the action. A fee reference should therefore describe the transaction being processed, not treat mempool presence as final fee settlement (Transaction Fees in Bittensor).
Visibility Context
Pending transactions can create an information-exposure window before block inclusion. MEV Shield documentation treats sensitive pending details as something that can be protected before processing (MEV Shield, Glossary: Mempool).
That makes mempool vocabulary important to safety articles, but the mempool itself is not the same thing as MEV Shield or any other protection mechanism.
Pending, Included, and Observed States
Mempool language is useful because it separates several nearby transaction states. The glossary defines mempool as the pending-transaction area before block inclusion, while block vocabulary names the unit that records included transactions (Glossary: Mempool, Glossary: Block).
| State | What the reader can say | What the reader should not infer | | -------------------- | ---------------------------------------------------- | --------------------------------------------------------- | | Submitted extrinsic | A runtime action was sent toward chain processing | It has not necessarily become block history. | | Mempool entry | The transaction is pending before inclusion | It is not final evidence of success. | | Included transaction | A block contains the transaction record | The mempool stage no longer describes it. | | Event record | The runtime emitted follow-up evidence | The event is not the same object as the pending entry. | | Storage state | Public chain state can be inspected after processing | A storage value is not proof of what was pending earlier. | | Fee context | A state-changing action may carry cost | Fee vocabulary does not define pending status. |
The table keeps timing and evidence separate. An extrinsic names the submitted action surface, mempool names the waiting area, and block vocabulary names the included chain-history surface (Subtensor extrinsics, Glossary: Mempool, Glossary: Block).
Events and storage answer later questions. Event references describe records emitted by the runtime, and storage references describe public state that can be inspected; neither source turns the pre-inclusion mempool into final chain history (Subtensor Events, Subtensor Storage).
Fee context is another neighboring layer. Transaction-fee documentation belongs to the cost of state-changing actions, while mempool vocabulary belongs to the pending interval before inclusion (Transaction Fees in Bittensor, Glossary: Mempool).
That distinction helps safety wording as well. MEV Shield documentation is concerned with sensitive pending transaction details, but MEV Shield is a protection context rather than a synonym for the mempool itself (MEV Shield, Glossary: Mempool).
For readers, the safest phrasing is stage-specific. Use mempool when the claim is about pending transactions before block inclusion, use block when the claim is about included chain history, and use events or storage when the claim is about evidence produced after runtime processing.
The same rule applies when a transaction later fails. A failure signal belongs to runtime outcome evidence, while mempool still names the earlier pending stage before the chain reached that outcome (Subtensor Error Codes, Glossary: Mempool).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. A mempool example from one environment should not be treated as proof about another environment (Bittensor Networks).
Localnet mempool examples can test pending-transaction mechanics in isolation. Testnet examples add shared non-production chain history. Mainnet mempool interpretation concerns production Subtensor pending state on the active network.
Relationship to Yuma Consensus
Mempool 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, mempool 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
Mempool does not name a transaction tutorial, monitoring guide, source for final chain status, or guarantee that a pending transaction will be included (Glossary: Mempool, Subtensor extrinsics).
Mempool identifies pending transaction state before block inclusion, while block records, extrinsics, fees, MEV Shield, and network context describe neighboring parts of the system.