Editorial and commercial-interest disclosure: D-Central sells mining equipment and services. This is protocol education, not financial, custody, legal, tax, electrical, or product advice. A transaction display, mempool feed, or confirmation count should be interpreted under the recipient’s documented risk policy.
A Bitcoin payment moves through several distinct states. Wallet construction, signing, broadcast, local policy acceptance, relay, template selection, block validation, and chain selection are related but not interchangeable. This guide separates them without a live fee, volume, hashrate, timing, or finality claim.
1. Construct and sign
A wallet selects outputs, creates inputs that reference them, defines new outputs, and supplies the required unlocking data. A node’s contextual acceptance additionally requires the referenced outputs to be available and unspent in its current view, with scripts, signatures, amounts, lock conditions, and other applicable rules passing validation. A wallet interface is not itself consensus.
2. Broadcast, relay, and local mempools
Broadcast offers a transaction to one or more peers. Each node can decide whether to accept it into its own mempool and relay it under local resource and policy rules. Mempools are not a shared global queue. Absence from one view does not prove absence everywhere; presence does not establish inclusion.
| State | What it can show | What it cannot show |
|---|---|---|
| Wallet created or signed | A local candidate and signing result. | Peer acceptance, relay, or inclusion. |
| Local mempool accepted | One node applied its current policy and validation path. | Universal propagation or confirmation. |
| Template selected | A builder considered a transaction for a candidate block. | That a valid block will be found or accepted. |
| Included in accepted block | A confirmation for a node’s active chain. | Absolute finality or a universal business-risk decision. |
The fee is the sum of input values minus the sum of output values. Fee rate relates fee to transaction weight or virtual size; it is not a promise of priority. Replacement is a local policy decision rather than a consensus entitlement. In Bitcoin Core v31.1, replacement does not require BIP 125 opt-in signalling, but the candidate must still satisfy current replacement and mempool rules. See the pinned Bitcoin Core v31.1 replacement-policy document; BIP 125 records the earlier opt-in policy.
3. Template construction and hashing
A template builder chooses transactions under its policy and block constraints, constructs a coinbase transaction, and distributes work. Hashing devices work on supplied jobs. They do not necessarily choose transaction templates, and they do not replace the independently validating node. See how Bitcoin mining works for the role boundary.
4. Block publication, validation, and confirmations
A published block is independently checked by nodes: its proof of work, predecessor, transaction validity, and consensus rules must pass. A transaction gains a confirmation when it is in a block on the chain a node accepts; later accepted blocks add chainwork on top. Recipients should define their own evidence and risk policy rather than rely on a universal confirmation rule.
5. Competing chains and reorganizations
Nodes can receive competing valid blocks. Chain selection follows the most-work valid chain under the rules they enforce. A reorganization changes which previously accepted branch is active; a transaction can return to a mempool, be absent under current policy, or conflict with another accepted transaction. More accumulated work is relevant evidence, not an absolute finality guarantee.
A compact evidence record
- Transaction identifier and the exact wallet or signing context.
- Broadcast endpoint and any local error or acceptance result.
- Fee, weight, replacement signals, and package assumptions as observed.
- Block hash, height, and node-chain observation when included.
- Recipient policy for reorg, custody, accounting, and exception handling.
Pinned primary sources
Content and links reviewed 29 August 2026. Bitcoin Core links are pinned to tag v31.1; recheck later release documentation and policy before operational use.
- Bitcoin Core v31.1 validation source
- Bitcoin Core v31.1 mempool source
- Bitcoin Core v31.1 mempool-replacement policy
- BIP 125, pinned commit 7fe0b03
Related education: nodes and miners and hashrate measurement.
Frequently asked questions
Is a broadcast transaction guaranteed to reach every node?
No. Nodes apply their own policy and relay decisions. A local mempool observation is not a network-wide guarantee.
Does a transaction in a mempool have a confirmation?
No. A confirmation begins when a transaction is in a block on the chain a node accepts.
Does a higher fee guarantee next-block inclusion?
No. Fee rate and package context can affect local selection, but template policy, competing transactions, propagation, and block discovery remain uncertain.
Can an unconfirmed transaction be replaced?
Possibly. Replacement is local node policy, not a consensus entitlement. Bitcoin Core v31.1 no longer requires BIP 125 opt-in signalling, but a candidate replacement must still pass its current mempool-replacement rules; other software or configurations can differ.
Do miners validate transactions?
Nodes independently validate transactions and blocks under consensus rules. A template builder or miner can apply additional policy, but hashing does not replace independent validation.
Are confirmations final?
Confirmations add accumulated work and can reduce practical reorganization risk under stated assumptions. Bitcoin does not provide an absolute finality guarantee.
What can happen to a transaction after a reorganization?
Depending on conflicts and current node policy, it can return to a local mempool, remain absent, or conflict with a transaction on the newly selected branch. Its prior confirmation is not preserved merely because one node observed it earlier.
What evidence should a recipient record?
Record the transaction identifier, amount and destination context, the node or service observation, the accepted-chain block reference when applicable, and the risk policy used.
