How Crypto Transactions Get Confirmed: From Send to Final

What does "confirmed" actually mean?

The word "confirmed" often sounds binary: first nothing, then certainty. Blockchains are more nuanced. A wallet may know a transaction was signed, a node may accept it into a local mempool, a block producer may include it, and a recipient may still wait for more assurance before treating the payment as settled. These are separate events.

A transaction can also execute unsuccessfully. On Ethereum, an included transaction whose contract call reverts is still confirmed as a transaction: it consumed gas, changed the sender nonce and produced a receipt with failure status, even though its intended state changes were rolled back. "Confirmed" therefore does not automatically mean "the application action succeeded".

Takeaway: Ask two questions, not one: Is the transaction included in the canonical chain, and has it reached the assurance level required for this particular payment?

What happens before a transaction reaches a mempool?

Construction and signature

A Bitcoin transaction identifies unspent outputs to consume, creates new outputs, sets amounts and scripts, and includes signatures or other witness data that satisfy the spending conditions. An Ethereum transaction identifies a sender-controlled account, a nonce, destination, value, optional data, gas limit and fee caps, then carries a signature authorising that exact payload.

Submission is not global broadcast

Most wallets submit a signed transaction to one of their own nodes, an infrastructure provider or a connected peer. The first receiver may then relay it over the peer-to-peer network. Some transactions instead go to a private relay, block builder, mining service or application-specific endpoint. A wallet saying "sent" often means only that one endpoint accepted the submission request.

Validity rules versus relay policy

Consensus rules decide whether a transaction could legally appear in a block: valid authorisation, no prohibited overspend, correct state transition and other chain rules. Node policy decides whether an unconfirmed transaction is worth storing and relaying before a block contains it. Policy can be stricter than consensus and can vary by software version or operator configuration. A transaction rejected from one mempool may still be valid in a block or accepted by another node.

Takeaway: "The network rejected it" is often too vague. Identify which node rejected it, whether the reason was consensus validity or local policy, and whether another version or route exists.

What is a mempool - and why is there no single one?

The term comes from "memory pool". It is not a protocol-owned waiting room in one place. Every participating node chooses what to accept, retain, evict, relay and replace within implementation and operator constraints. Nodes join at different times, have different peers, use different software and may allocate different memory. Their pending sets therefore diverge continually.

Bitcoin mempools

Bitcoin nodes store unconfirmed transactions and track their dependency graph because a child may spend an unconfirmed parent. Bitcoin Core 31 introduced a cluster-mempool design that evaluates connected transactions in groups and orders "chunks" by the feerate at which they are expected to be mined. This is more accurate than the old beginner model in which every transaction simply stands alone in one fee-ranked queue.

Ethereum transaction pools

Ethereum execution clients commonly distinguish executable or pending transactions from queued or gapped transactions. A transaction with the next usable nonce can be executable; a later nonce may wait because one or more earlier nonces are missing. Geth documents separate pending and queued pools and replacement of a same-sender, same-nonce transaction by a sufficiently higher-priced version.

Public mempool versus private order flow

A sender can route a transaction directly to a builder or specialised service instead of broadcasting it across the public gossip network. This may reduce public exposure to front-running or improve bundle handling, but it introduces endpoint availability, censorship and trust assumptions. Ethereum's own documentation explicitly notes that advanced users may send transactions to specialised builders rather than the public mempool.

Takeaway: Speak of "a node's mempool" or "public transaction gossip", not "the mempool" as though it were a globally consistent database.

How do Bitcoin fees and transaction selection work?

Absolute fee versus feerate

The absolute fee is the difference between the total value of spent inputs and the total value of new outputs. Feerate divides that fee by virtual size and is usually expressed in sat/vB. A 1,000-satoshi fee can be competitive on a small transaction and inadequate on a much larger one. Virtual bytes incorporate SegWit's weight discount and are not simply the raw file size.

Why dependencies change the auction

A child transaction cannot confirm before its unconfirmed parent because the output it spends does not yet exist on-chain. Rational block construction therefore considers the combined revenue and size of transactions that must be mined together. Bitcoin Core 31's cluster-mempool logic explicitly orders connected transactions using expected mined chunks rather than a naive one-row-per-transaction list.

What miners and pools are optimising

A pool usually builds a valid block template intended to maximise revenue within weight, dependency, policy and operational constraints. Feerate is central but not exclusive. Operators can prioritise transactions locally, accept transactions through private channels, include their own transactions, honour commercial agreements or omit transactions for policy reasons. Consensus nodes will accept any block whose contents obey consensus, regardless of whether it matches another node's mempool.

Takeaway: Bitcoin is an auction for block weight, but the economic unit can be a connected group of transactions rather than one isolated transaction.

How do Ethereum gas fees and nonce order work?

Gas used and gas limit

Gas measures the execution resources required by an Ethereum transaction. The gas limit is the most gas the sender authorises for that transaction. The sender pays only for gas actually consumed, up to the limit. A simple ETH transfer has a predictable intrinsic cost; contract interactions can consume much more and may vary with state.

Base fee, priority fee and max fee

EIP-1559 gives each block a protocol base fee that rises when prior blocks exceed the target gas usage and falls when they are below it, with a maximum 12.5 percent change per block. That base fee is burned. The sender also sets a maximum priority fee and a maximum total fee per gas. The actual per-gas charge is constrained by the base fee, the permitted tip and the sender's max fee; unused headroom is not paid.

Nonce order

An externally owned account's nonce increments with each executed transaction. A transaction using a later nonce cannot execute before every earlier nonce has been consumed. That is why one underpriced or missing transaction can block a queue of otherwise expensive later transactions from the same account. Different clients and wallet services may describe these as pending, queued or gapped.

Reverted execution still costs gas

If an Ethereum transaction is included and contract execution reverts, the protocol discards the intended state changes but keeps the nonce increment and charges for computation already performed. The receipt status indicates failure. By contrast, a transaction rejected before inclusion because it is intrinsically invalid does not consume on-chain gas.

Blob fees are separate

Transactions carrying EIP-4844 blobs, used primarily by rollups, participate in a separate blob-fee market in addition to ordinary execution gas. A normal ETH transfer does not pay a blob fee. This distinction matters when diagnosing rollup costs, but it is not part of the standard wallet-transfer calculation.

Takeaway: On Ethereum, separate the transaction's inclusion from the success of its execution, and separate the gas ceiling from the amount actually charged.

Who actually builds and proposes blocks?

Bitcoin: pools, template construction and proof of work

A mining pool coordinates hashpower from participating miners and usually supplies candidate work based on its block template. The pool or its infrastructure chooses transactions and constructs the coinbase transaction; miners search for a valid proof-of-work header. The miner or pool that finds a valid block broadcasts it. Independent Bitcoin nodes check the entire block and reject it if any consensus rule is broken.

Ethereum: proposer and builder can be different actors

Every 12-second slot has a selected validator proposer. A proposer can build an execution payload locally from transactions it knows, or use a builder market. Out-of-protocol proposer-builder separation, commonly implemented through the Builder API and MEV-Boost ecosystem, allows specialised builders to bid for the right to supply the execution payload. The proposer signs the selected block; other nodes re-execute and verify it. Ethereum's roadmap discusses enshrining this separation in the protocol, but roadmap proposals should not be described as already active unless deployed.

Why MEV affects ordering

Maximal extractable value is additional profit obtainable from selecting, inserting or ordering transactions. Examples include arbitrage and liquidation. A builder may prefer a bundle with high total value over a transaction with a slightly higher public tip. This is why "highest tip always goes first" is not an accurate description of Ethereum block ordering.

Private order flow trade-offs

Private submission can reduce public front-running exposure and support all-or-nothing bundles. It can also concentrate visibility and censorship power in builders, relays or endpoint operators. Users should distinguish privacy from trustlessness: a transaction hidden from the public mempool may still be visible to the private service receiving it.

Takeaway: The entity proposing a block may not be the entity that chose its transaction order, especially on Ethereum. Inclusion is a market-structure question as well as a fee question.

Why do transactions get stuck, disappear or show conflicting statuses?

Dropped does not mean universally forgotten

Nodes evict transactions because of local memory pressure, age or policy. Another node may retain and rebroadcast the same transaction later. A sender should not assume funds are safely reusable merely because one explorer stopped showing the transaction; verify the canonical UTXO or account nonce state and use the wallet's conflict handling.

Low fee is not the only cause

A transaction can pay a high nominal fee and still wait because it depends on a low-fee parent, sits behind a nonce gap, fails a local relay rule, is submitted to a private endpoint that withholds it, or loses builder preference to a more valuable bundle. Precise diagnosis prevents unnecessary or unsafe replacement attempts.

Takeaway: Start from observable chain and node state. Do not repeatedly resend random variants until you know whether you are dealing with fee priority, sequencing, policy, replacement or reorganisation.

How can a pending Bitcoin transaction be sped up or replaced?

Replace-by-fee (RBF)

RBF creates a new transaction that spends at least one of the same inputs as the pending transaction and pays enough additional fee to satisfy replacement policy. Bitcoin Core changed full-RBF to the default in version 28 and Bitcoin Core 31 further revised replacement evaluation around cluster feerate diagrams. For a simple singleton replacement under current Core policy, the replacement needs both a higher absolute fee and a higher feerate, plus enough incremental fee to pay for relay. Other implementations and services may differ.

Use the wallet's supported "bump fee" or "speed up" flow where possible. Manual replacement can accidentally alter recipients, change outputs, break application assumptions or create a transaction that does not propagate as expected. A replacement is not final until one version confirms.

Child-pays-for-parent (CPFP)

If the sender or recipient controls an output of the unconfirmed transaction, they can create a child transaction spending that output with enough fee to make the connected group attractive. This does not change the parent; it gives miners an economic reason to include parent and child together. Current Bitcoin Core package and cluster policy is more nuanced than the old "average the two feerates" shorthand, but the user-level principle remains: the child can subsidise the parent when the package is policy-compatible.

Third-party accelerators

Some mining services offer transaction acceleration, sometimes free and sometimes paid. They are not a protocol feature and cannot guarantee inclusion by miners they do not control. Never provide a seed phrase or private key, and treat unsolicited "accelerator support" as a scam. A legitimate service needs at most public transaction information and, if paid, an ordinary payment arrangement.

Takeaway: Bitcoin fee-bumping is conflict and package management, not a magic priority flag. Let the wallet construct the replacement whenever possible.

How can a pending Ethereum transaction be sped up or cancelled?

Speed-up replacement

A speed-up keeps the intended action but raises maxFeePerGas and, where appropriate, maxPriorityFeePerGas. The replacement must satisfy the wallet, execution client or provider's price-bump rules. Because base fee can move while the transaction is pending, raising only the tip may not help if the max fee no longer covers the base fee plus effective tip.

Cancellation attempt

A wallet can submit a simple self-transfer with the same nonce and higher fees. If that replacement is included first, the original becomes invalid because the nonce has been consumed. If the original reaches a block first, the cancellation loses. A private original transaction may also be invisible to the public endpoint used for cancellation, complicating the race.

Do not skip the blocked nonce

Sending a transaction with a later nonce does not cancel or bypass the earlier one. It usually joins the queue behind it. Resolve the earliest missing or pending nonce first, then inspect later transactions for stale assumptions or duplicate application actions.

Contract and approval caution

A successful cancellation prevents that specific transaction from executing. It does not revoke approvals, reverse an earlier confirmed contract call or undo an off-chain order submitted elsewhere. If the pending transaction is security-sensitive, also inspect the wallet, dapp and approval state rather than treating nonce replacement as complete incident response.

Takeaway: Ethereum "cancel" means "win a same-nonce race with a harmless replacement". It is not an undo message sent to validators.

Can a confirmed transaction be reversed?

What a reorganisation is

Nodes can briefly receive competing valid blocks near the chain head. Fork-choice rules determine which branch becomes canonical. When a previously accepted block loses, it is disconnected and the winning branch replaces it. Transactions from the disconnected block are reconsidered: some return to mempools, some confirm in the new branch, and some become invalid because a conflicting spend or account nonce already won.

Bitcoin: probabilistic finality

Bitcoin nodes choose the valid chain with the most accumulated proof of work. A transaction's assurance increases as valid blocks add work above it, but the protocol does not mark a particular depth as mathematically final. Six confirmations is a long-standing high-value convention; it is neither necessary for every transaction nor an absolute guarantee against an attacker with sufficient sustained hashpower.

Ethereum: latest, safe and finalised

Ethereum execution APIs distinguish recent states. "Latest" is the client's current canonical head and can reorg during healthy operation. "Safe" is expected not to reorg under honest-majority and synchrony assumptions. "Finalized" is the latest crypto-economically secure checkpoint; reverting it requires manual community intervention after a consensus failure and makes at least one-third of total staked ETH provably slashable, so the validators responsible forfeit and have burnt at least that share of stake, with the exact penalty scaling with how many validators are slashed together.

Finality is not metaphysical impossibility

"Finalised" is a strong protocol and economic guarantee, not a statement that software, governance or human coordination could never alter history after a catastrophic failure. Ethereum documents social recovery as a last resort after dishonest finality. Bitcoin also relies on users choosing software and chain rules under exceptional conditions. Ordinary users should treat these as extreme system-level contingencies, not routine chargeback mechanisms.

Takeaway: Confirmation depth measures growing assurance; protocol finality marks a stronger state. Neither creates a customer-service reversal path for an authorised mistake.

How long do confirmations and finality take?

Bitcoin time is probabilistic

Bitcoin retargets mining difficulty so blocks average roughly ten minutes over time. That is not a timetable for the next block. Proof-of-work discovery is random: the next valid block may appear immediately or after a long gap. A fee estimate targets a probability of confirmation within a number of blocks based on past mempool and mining observations; it cannot promise wall-clock delivery.

Ethereum time is slotted

Ethereum divides time into 12-second slots and 32-slot epochs. One proposer is selected per slot, but a block is not guaranteed in every slot. A transaction visible to the winning proposer or builder and paying adequate fees can be included quickly; private routing, builder strategy, fee caps, nonce order or a missed slot can delay it.

Finality can pause

Under normal conditions, checkpoint voting finalises history after roughly two epochs. If participation drops below the required two-thirds threshold, the chain can continue producing blocks without finalising. Ethereum's inactivity leak gradually reduces the weight of unavailable validators so the online set can eventually regain finality, but the delay is not fixed.

Layer 2 adds more clocks

On an Ethereum rollup, a user may see immediate sequencer acknowledgement, L2 block inclusion, data publication to Ethereum, proof or challenge completion, and withdrawal availability as distinct stages. The correct settlement standard depends on the rollup and application. Do not apply Ethereum mainnet's roughly 13-minute finality number to every L2 user experience.

Takeaway: Block cadence is an input to settlement time, not a service-level agreement. Quote ranges and states, not exact promises.

How many confirmations should a recipient wait for?

A low-value digital service can accept more reorganisation risk than an exchange crediting a large deposit or a merchant releasing irreversible physical goods. A recipient with real-time double-spend monitoring may choose differently from one relying on a single third-party explorer. Service deposit policies are risk controls, not direct statements of consensus law.

Why six Bitcoin confirmations became conventional

Six confirmations represents the containing block plus five later blocks - roughly one hour in expectation - and has long been used as a conservative high-value convention. It is not embedded as a settlement constant in Bitcoin consensus. Some services require fewer; some require more when values are large, chain security is lower or attack incentives are unusual.

Why Ethereum services may credit before finality

Applications sometimes act on latest or safe blocks because waiting for full finality would add latency. That is a deliberate risk choice. A robust system records the block hash, handles reorgs idempotently and delays irreversible downstream actions until the required state is reached.

Takeaway: Use confirmation thresholds as calibrated risk controls, not ritual numbers copied from another chain or another business.

How do you verify a transaction correctly?

For Bitcoin

• Confirm the transaction ID and network.
• Check whether the transaction is unconfirmed or included in a canonical block, and record the block hash rather than only the height.
• Verify every relevant output, not just the first address shown. Bitcoin transactions can have multiple recipients and a change output.
• Check the fee and virtual size if diagnosing delay.
• Inspect whether inputs are also spent by a conflicting transaction and whether unconfirmed parents exist.
• Count confirmations using the containing block as one.

For Ethereum

• Confirm the transaction hash, chain ID and network.
• Check from, to, value, input data and token-transfer events; a token transfer may not be represented by the top-level ETH value.
• Inspect the receipt status. Status 1 normally means execution succeeded; status 0 means the included call reverted.
• Check gas used and effective gas price rather than assuming the signed max fee was fully charged.
• Record the block hash and whether your provider reports latest, safe or finalised state.
• For contract interactions, verify the intended function, logs and resulting state, not only "confirmed".

Privacy and explorer risk

Pasting addresses and transaction hashes into a third-party explorer reveals interest and may expose IP or account-linkage metadata to that provider. Public chain data is already visible, but your query behaviour is additional information. For sensitive or institutional workflows, query your own node or a trusted infrastructure provider and avoid search-engine links or unsolicited "support explorers".

Takeaway: Verification means checking the exact chain object and its canonical state, not trusting a wallet notification, screenshot or copied explorer label.

Troubleshooting checklist

• Copy the transaction hash from the wallet. Confirm the network and chain ID.
• Check whether a trusted node or explorer sees the transaction. Use a second independent source for high value.
• If unconfirmed, inspect fee parameters, dependencies and whether the transaction was publicly broadcast or privately routed.
• On Bitcoin, check unconfirmed parents, current sat/vB conditions and whether the wallet supports RBF or CPFP.
• On Ethereum, identify the account nonce, the earliest pending nonce, max fee, priority fee and current base fee.
• Look for a conflicting replacement: same Bitcoin inputs or same Ethereum sender and nonce.
• If the transaction was confirmed and then disappeared, compare its old block hash with the canonical chain for a reorg.
• If an Ethereum transaction confirmed but the action failed, inspect receipt status, logs and revert information.
• Use the wallet's built-in speed-up or cancel feature rather than signing arbitrary instructions from support messages.
• Never reveal a private key or recovery phrase. Transaction diagnosis requires public hashes and local wallet information, not key material.

Takeaway: A methodical state check is faster and safer than repeatedly resubmitting, switching networks or following unsolicited "recovery" instructions.

Frequently asked questions

What is one confirmation in crypto?

One confirmation normally means the transaction is included in a canonical block. On Bitcoin, the containing block is confirmation number one. On Ethereum, inclusion is the latest state; applications may also wait for safe or finalised status.

Does a higher fee guarantee the next block?

No. A competitive fee improves expected priority, but block timing, dependencies, nonce order, local policy, private order flow, MEV and producer choice also matter. Fee estimates are probability estimates, not guarantees.

Can two versions of the same transaction both confirm?

Conflicting Bitcoin transactions that spend the same input cannot both remain in the same valid chain. Ethereum transactions from one account with the same nonce cannot both execute on the same chain. However, two non-conflicting payments that merely look similar can both confirm, which is why manual resending is dangerous.

Can a confirmed Bitcoin transaction be cancelled?

No conventional cancellation exists after confirmation. A shallow reorganisation can remove a recent block, but the sender cannot request a chargeback. Before confirmation, a wallet may attempt RBF or CPFP, depending on the transaction.

Can an Ethereum transaction be cancelled?

Only while it is pending, by attempting to replace it with a same-nonce transaction that pays enough to win the race. If the original confirms first, cancellation fails. A confirmed transaction cannot be recalled through nonce replacement.

Why is my Ethereum transaction pending even with a high tip?

An earlier nonce may be missing, the max fee may not cover the current base fee plus tip, the transaction may be visible only to one provider, or builders may prefer other bundles. Resolve the earliest nonce and inspect all fee fields, not only the tip.

What happens when a Bitcoin transaction is dropped from a mempool?

That node stops storing it, but other nodes may retain or rebroadcast it. The inputs remain unspent on-chain unless a version confirms. Check conflicts and wallet state before reusing the funds.

Why did a confirmed transaction become pending again?

Its block was probably disconnected during a chain reorganisation. The transaction may return to a mempool and confirm again, or it may become invalid if a conflicting transaction won in the new canonical history.

Is six confirmations always enough?

It is a widely used conservative Bitcoin convention, not a universal guarantee. Appropriate depth depends on value, attack incentives, chain conditions and recipient policy. Other chains use different assurance models.

How long does Ethereum finality take?

Under normal participation, roughly two 32-slot epochs - about 13 minutes. It can take longer if participation falls below the required threshold. Inclusion usually happens earlier and is not the same as finality.

Do more confirmations cost extra?

No additional sender fee is charged merely because later blocks build above the transaction. The original inclusion fee is paid once. Waiting costs time, while replacement transactions can require additional fees.

Does a successful block explorer status prove the recipient got the intended token?

Not by itself. Verify the correct network, contract, recipient and amount. On Ethereum, inspect token-transfer logs and receipt status; on Bitcoin, inspect the relevant outputs and change.

Sources and further reading

Key references for this article, current as of July 2026.

• Bitcoin Developer Guide - Transactions. https://developer.bitcoin.org/devguide/transactions.html
• Bitcoin Developer Guide - Block Chain. https://developer.bitcoin.org/devguide/block_chain.html
• Bitcoin Core 31.0 release notes. https://bitcoincore.org/en/releases/31.0/
• Bitcoin Core 31.0 bumpfee RPC. https://bitcoincore.org/en/doc/31.0.0/rpc/wallet/bumpfee/
• Bitcoin Core mempool replacement policy. https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
• Ethereum.org - Transactions. https://ethereum.org/developers/docs/transactions/
• Ethereum.org - Gas and fees. https://ethereum.org/developers/docs/gas/
• Ethereum.org - Proof of stake. https://ethereum.org/developers/docs/consensus-mechanisms/pos/
• Ethereum Execution APIs - block tags. https://ethereum.github.io/execution-apis/
• Ethereum.org - Maximal extractable value. https://ethereum.org/developers/docs/mev/
• EIP-1559. https://eips.ethereum.org/EIPS/eip-1559
• Geth documentation - command-line options. https://geth.ethereum.org/docs/fundamentals/command-line-options
• Ethereum.org - Proof-of-stake attack and defence. https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/
• Google Search Central - Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content