Mempool Visibility
Mempool visibility is the exposure of transaction details while a transaction is still pending (Glossary: Mempool, MEV Shield).
The term is useful because pending information can matter before a transaction becomes part of ordered block history. It belongs to transaction-safety context, especially MEV risk, rather than to final chain-state evidence (MEV, Glossary: Block).
Pending Transaction Context
The mempool glossary entry places pending and unconfirmed transactions before block inclusion (Glossary: Mempool).
Mempool visibility asks what information is observable during that waiting period. The transaction has not yet become part of a block, so the relevant context is exposure while it is still waiting for inclusion.
That timing separates mempool visibility from ordinary block evidence. The mempool term describes a pending pool of transactions, while a block is the ordered chain data unit that contains accepted transactions and a block hash (Glossary: Mempool, Glossary: Block).
MEV Risk Context
The MEV glossary entry connects maximal extractable value to transaction ordering and information available before inclusion (MEV).
That makes mempool visibility a safety concept. If sensitive pending details are visible before a block is produced, another observer may have information that matters for ordering-sensitive behavior.
Mempool visibility is therefore one part of MEV risk, not the whole risk by itself. MEV context also depends on ordering, inclusion, and the surrounding transaction environment (MEV, MEV Shield).
MEV Shield Boundary
MEV Shield documentation describes encrypted mempool protection for sensitive transaction contents while they are pending (MEV Shield).
That places MEV Shield directly beside mempool visibility. The protection is about reducing what can be seen while the transaction is pending, while block inclusion and runtime processing still determine the later record (MEV Shield, Glossary: Block).
Pending Privacy Boundary
Mempool protection should not be read as hiding the final transaction record. MEV Shield addresses what can be observed before inclusion, while a block still provides the ordered chain context after the transaction is accepted.
That distinction keeps privacy timing separate from chain history. A shielded pending transaction can reduce pre-inclusion exposure without changing the fact that included transactions belong to recorded block context.
References: MEV Shield, Glossary: Block
Block Inclusion Boundary
A block is the chain data unit that contains transactions and has a block hash (Glossary: Block).
This boundary matters because pending visibility and final chain history answer different questions. Mempool visibility concerns the pre-inclusion window; block evidence concerns inclusion and ordering after the chain records the transaction.
Recorded Evidence Context
Pending visibility is not the same thing as recorded chain state. Chain events and storage are better sources for what happened after inclusion, while mempool visibility concerns what could be observed beforehand (Subtensor Events, Subtensor Storage).
Events and storage are still important, but they answer later questions. Events name runtime records emitted during processing, and storage exposes readable state surfaces after the chain has recorded state (Subtensor Events, Subtensor Storage).
In short, mempool visibility describes pending exposure; blocks, events, and storage describe recorded chain context.
Development Stage Context
Bittensor documentation separates mainnet, testnet, and localnet contexts (Bittensor Networks, Introduction to Bittensor: Subnet development).
A mempool visibility 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.
Relationship to Yuma Consensus
Mempool Visibility 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 visibility 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 visibility should be read as pending-exposure vocabulary. It identifies what can be visible while a transaction is waiting, which is why it sits near MEV and MEV Shield in Bittensor safety context (Glossary: Mempool, MEV Shield).
Block, event, storage, and network references supply the surrounding record context once the topic moves from pending exposure to included transaction history.
Staking and Unstaking Rely on the Same Pending Window
The Glossary: MEV states that MEV attacks can affect staking and unstaking when knowledge of pending transactions lets another party manipulate token prices. Those conversions pass through subnet pool reserves (Understanding Slippage), so a visible pending stake can reveal an upcoming pool move before inclusion.
Mempool visibility therefore includes delegation conversions, not only discretionary swaps. The exposure question is what pending details are readable while the transaction waits in the mempool.
Ordering Attacks Need Readable Pending Details
The MEV glossary lists front-running, sandwich attacks, and back-running as ordering shapes that depend on observing pending transactions. Managing Your Stakes documentation describes sandwich patterns around visible stake activity.
Those attacks require foreknowledge of pending trade details. Mempool visibility names that observation window rather than the final execution outcome once a block includes the transaction.
Coldkey-Signed Actions Can Route Through MEV Shield
MEV Shield documentation limits the feature to transactions signed by a coldkey. Hotkey-signed submissions are not supported for shielded pending privacy.
That boundary sits directly on mempool visibility. Shielding encrypts sensitive pending contents for eligible coldkey-signed actions, reducing what other observers can read before inclusion without changing runtime acceptance rules after reveal.