In brief
How node operation, mempool policy, block templates, and miner work relate.
First Contact#
Nodes validate and expose state. Mempools hold candidate transactions under policy. Block templates are candidate work for miners. Miners perform proof of work. None of these stages should be mistaken for the whole transaction evidence path.
Working Model#
If a transaction appears in a template, the template is candidate work, not a guarantee of accepted consequences. If a miner finds a block, later consensus processing still matters. The guide therefore links mining and node pages back to accepted evidence.
Expanded Node And Miner Evidence Path#
Nodes and miners sit in the middle of the evidence path. A node validates and relays according to protocol and policy surfaces. Its mempool holds candidate transactions. Its template builder can prepare work for miners. A miner searches for proof of work over candidate block data. These stages are connected, but each has its own evidence limits.
Template inclusion is a candidate-work statement. It can be important, but it is not the same as accepted transaction consequences. A mined block is stronger than a template candidate, but the guide still needs block/DAG processing, virtual processing, acceptance data, and UTXO diffs before making application-level acceptance claims.
Operational pages should also be freshness-sensitive. Commands, defaults, ports, logs, mining software, and node arguments can change. The page can explain the model, but command-level details require current docs, release notes, or source review.
For review, separate node health from transaction evidence. A synced node, a responsive RPC service, a mempool entry, a template candidate, and a mined block are all useful observations, but each answers a different question. This bridge should help an operator or developer avoid treating a successful template or mining observation as proof that a transaction's UTXO consequences are already settled.