Field notes · Blockchain education
Transaction submitted versus transaction confirmed
Separate broadcast, inclusion, execution success, confirmations, and finality, with Bitcoin and Ethereum examples and a plan for reorganizations.
By Rakibul Islam · Updated and technically reviewed
General transaction lifecycle; Bitcoin confirmations and Ethereum receipts/finality are labeled separately.
A submission response is an acknowledgment
A user clicks Pay, the application calls a node, and a transaction identifier appears. That identifier is useful for tracking, but it is not proof that the recipient was paid. A transaction can be constructed and identified before any block includes it. A node’s response describes what that node knows, not a promise from every participant.
Separate the application’s states: prepared; submission outcome unknown or acknowledged; pending; included; execution failed or succeeded where applicable; and settled under a declared policy. These are application labels, not a universal protocol enum. Preserve uncertainty instead of turning every timeout into Failed or every successful HTTP response into Paid.
Primary sources: Bitcoin · sendrawtransactionEthereum · Transactions
Pending is a local observation
Pending often means a node knows a candidate transaction that is not yet included. Nodes can have different transaction pools. A request may be rejected, a transaction may be evicted, or a conflicting candidate may be selected. Fees and transaction validity influence what happens next; merely waiting does not guarantee inclusion.
If submission times out, first look up the already-known transaction identifier. A missing result can reflect the queried node’s limited view, not proof that no transaction exists. Keep the operation unresolved while reconciling. Creating another payment immediately can turn a transport failure into a duplicate business payment.
Primary sources: Bitcoin · Payment processingEthereum · JSON-RPC receipts and block tags
Bitcoin: inclusion begins the confirmation count
For a transaction in the active Bitcoin chain, its containing block is commonly counted as confirmation one. Each following block adds another. If inclusion height is 100 and the active tip is 102, the count is three: 102 − 100 + 1. That arithmetic only applies after verifying that the containing block is still in the active chain.
Bitcoin settlement confidence is probabilistic. Confirmation counts are risk inputs, not universal guarantees or a fixed safety threshold for every payment. A system should choose its policy based on the transaction’s consequences and its threat model, then document that policy rather than borrowing a number from a different network.
Primary sources: Bitcoin · Payment processingBitcoin white paper · Sections 4–6 and 11
Ethereum: a receipt is not the whole payment check
Ethereum’s eth_getTransactionReceipt returns a receipt or null if none was found. For an included transaction, status 0x1 indicates execution success; 0x0 indicates failure. A failed transaction can still be included and consume gas. Inclusion and successful execution are therefore distinct observations.
Even a successful receipt is not a business-level payment assertion. Check the intended chain, recipient, asset, and amount. For a contract interaction, verify the relevant execution result or event from the intended contract; a successful unrelated call is not payment for your order. Preserve the receipt’s block hash as well as its number so a later check can detect changed history.
Primary sources: Ethereum · JSON-RPC receipts and block tagsEthereum · Transactions
Ethereum: finality is more than counting blocks
Ethereum currently uses proof of stake. Gasper combines fork choice with checkpoint finality. Validators representing at least two-thirds of the stake establish the supermajority links used to justify and finalize checkpoints. Finalized history has stronger consensus assurances than recent head blocks; conflicting finalization would violate safety assumptions and imply substantial slashable stake.
Ethereum JSON-RPC exposes safe and finalized block tags where supported. To judge a receipt, establish that its block belongs to the relevant canonical history and is covered by your policy’s checkpoint; comparing block numbers without checking ancestry is insufficient. Finality can stall, so elapsed time alone is not a substitute for observing it. Other networks and layer 2 systems can have different settlement boundaries.
Primary sources: Ethereum · Proof of stake and finalityEthereum · Gasper fork choice and finalityEthereum · JSON-RPC receipts and block tags
A reorganization changes the observed history
A reorganization replaces a suffix of the chain a node had selected. A previously included transaction might appear in a replacement block, return to pending, or conflict with the replacement history. Confirmation counts can fall. An application must be able to move an observed payment back into an unresolved state rather than treating inclusion as an irreversible database fact.
Record the operation identifier, all known transaction identifiers, inclusion block hash and height, execution outcome, and settlement policy. Recheck canonical inclusion before fulfillment, deduplicate repeated notifications, and retain an audit trail when an observation changes. If a reorganization affects already-delivered goods, route that to an explicit recovery policy rather than silently paying again.
The chaining exercise demonstrates why ancestry matters but does not simulate competing branches, receipts, or finality. Adding a local block is not a network confirmation. Continue with the retry article to see how one business operation can survive an ambiguous submission response.
Primary sources: Ethereum · Gasper fork choice and finalityBitcoin · Payment processing