In brief
Transaction evidence moves through layers: wallet intent, node or mempool response, block inclusion, virtual processing, and accepted UTXO effects.
What this page explains#
Block templates turn node state and mempool candidates into miner work. This page sits in Transactions, UTXO, Fees, And Mempool. It gives the topic a plain-language handle first, then shows the working idea, the mechanism, the source trail, and any limits that still matter. This category follows a transaction from ownership model to structure, signing, validation, mempool admission, template selection, and accepted-state evidence. The main danger it prevents is collapsing all transaction states into one word.
The writing follows a simple Kaspa documentation pattern: answer the practical question first, then link outward for details. The closest public sources for this page are RK-BLOCK-TEMPLATE, RK-TEMPLATE-SELECTORS, RK-MEMPOOL, WIKI-MINING. Local notes can help choose what to explain, but public-facing references resolve to upstream websites, repositories, papers, release pages, or docs.
How to think about it#
The practical model starts by naming the layer that owns the topic: wallet use, node operation, consensus, transaction validation, Toccata script behavior, tooling, or research. From there, the page shows which public source can support the explanation and where the explanation becomes incomplete.
For Block Templates And Transaction Selection, the model is built around these anchors: coinbase and selected transactions are assembled under block limits; template selectors propose candidates under mass, lane, gas, dependency, and readiness constraints; virtual processing validates selected batches and can reject invalid selections; being in a template does not guarantee accepted state; miners and pools add operational surfaces outside consensus rules. This model is useful, but it does not encode every constant, branch, error type, or edge case. Those details belong in the source path and the source notes.
How it works#
1. coinbase and selected transactions are assembled under block limits. Transaction pages follow the object through construction, identity, signing, resource accounting, validation, mempool admission, template selection, and accepted evidence. The explanation is careful about which stage has happened and which stage is still only a candidate.
2. template selectors propose candidates under mass, lane, gas, dependency, and readiness constraints. Mempool and relay behavior describe what a node is willing to hold, replace, forward, or package; they are not final acceptance. Block templates are candidate work for miners, and they can change as node state or policy changes. The guide names each stage separately: built, signed, submitted, admitted, relayed, templated, mined, and accepted.
3. virtual processing validates selected batches and can reject invalid selections. Virtual state is the bridge from ordered consensus consequences into the state surfaces that tools can inspect. Mempool visibility says a node is considering a transaction; accepted evidence says the transaction was incorporated through consensus processing. UTXO diffs, accepting data, and indexer replay are the review trail for applications that need durable state.
4. being in a template does not guarantee accepted state. Mempool and relay behavior describe what a node is willing to hold, replace, forward, or package; they are not final acceptance. Block templates are candidate work for miners, and they can change as node state or policy changes. The guide names each stage separately: built, signed, submitted, admitted, relayed, templated, mined, and accepted.
5. miners and pools add operational surfaces outside consensus rules. Mining and proof-of-work explanations belong to the node/miner path, not the ZK path. The node prepares candidate block templates from consensus and mempool state; mining hardware or pool software searches for acceptable work. Hardware catalogs and profitability references are volatile, while the durable protocol boundary is proof of work verification and template validity.
This mechanism section follows a transaction through construction, identity, signing, validation, mempool policy, block templates, and accepted evidence. The stage must be named before the claim is reused.
How to check it#
| Step | Check | Evidence gate |
|---|---|---|
| 1 | Check coinbase and selected transactions are assembled under block limits. | Use RK-BLOCK-TEMPLATE, RK-TEMPLATE-SELECTORS, RK-MEMPOOL; name the stage: built, signed, validated, admitted, templated, mined, or accepted. |
| 2 | Check template selectors propose candidates under mass, lane, gas, dependency, and readiness constraints. | Use RK-BLOCK-TEMPLATE, RK-TEMPLATE-SELECTORS, RK-MEMPOOL; add date, network, release or commit, tool version, and accepted/rejected evidence. |
| 3 | Check virtual processing validates selected batches and can reject invalid selections. | Use RK-BLOCK-TEMPLATE, RK-TEMPLATE-SELECTORS, RK-MEMPOOL; name the stage: built, signed, validated, admitted, templated, mined, or accepted. |
| 4 | Check being in a template does not guarantee accepted state. | Use RK-BLOCK-TEMPLATE, RK-TEMPLATE-SELECTORS, RK-MEMPOOL; name the stage: built, signed, validated, admitted, templated, mined, or accepted. |
| 5 | Check miners and pools add operational surfaces outside consensus rules. | Use RK-BLOCK-TEMPLATE, RK-TEMPLATE-SELECTORS, RK-MEMPOOL; name the stage: built, signed, validated, admitted, templated, mined, or accepted. |
When using this page for a transaction claim, name the stage precisely: built, signed, validated, admitted to a mempool, included in a template, mined, accepted, or reflected in a UTXO change. Each stage has a different evidence surface and should not be collapsed into a single success word.
Related Pages#
- 08-mempool-policy
- transactions-utxo-mempool
- 10-accepted-transaction-evidence