
A candidate block is a “preliminary block” that has not yet been officially accepted by the blockchain. It is assembled by miners or validators who select a batch of transactions from the transaction pool (mempool). Candidate blocks exist in a transitional state between “transactions submitted” and “confirmed blocks.”
You can think of a candidate block like a shipment box at a logistics sorting center: it’s packed with user transactions but hasn’t been dispatched yet. The box only counts as confirmed once it’s accepted by the network and recorded on-chain. The process is influenced by factors such as transaction fees, block capacity, network propagation, and the block production mechanism.
Candidate blocks act as “proposals” awaiting acceptance by the consensus mechanism to be written into the next block at a new height. Once accepted, a candidate block becomes an official block on the chain, providing confirmation for its included transactions.
“Consensus” refers to the standardized voting and verification process among network nodes. In Proof of Work (PoW), this involves solving computational puzzles; in Proof of Stake (PoS), validators are selected based on staked assets. Candidate blocks are broadcast, verified, and ultimately, the network determines which candidate becomes the next valid block. This decision affects both the speed and security of transaction confirmations.
Step 1: Selecting Transactions from the Mempool.
The transaction pool (mempool) is a collection of pending transactions. Nodes check signatures and basic rules; only valid transactions are considered for inclusion in a candidate block.
Step 2: Setting Block Parameters.
This includes defining the block header, timestamp, size/weight or gas limits, and miner/validator rewards (such as Bitcoin’s coinbase transaction or Ethereum’s priority fee). All must comply with protocol-specified limits.
Step 3: Triggering Block Production.
In Proof of Work, miners repeatedly try different nonces to meet the network’s difficulty target. In Proof of Stake, chosen validators bundle and sign candidate blocks in designated slots (as adopted by Ethereum post-merge).
Step 4: Broadcasting and Verification.
When nodes receive a candidate block, they revalidate transaction correctness and state changes. They then decide whether to adopt it based on current chain height and fork rules.
Step 5: Becoming an Official Block or Being Replaced.
If another candidate is accepted first or forms a longer chain, this candidate may be discarded; otherwise, it is recorded as the next official block.
The goal is to maximize economic value within the block’s capacity while minimizing conflicts. Typically, transactions with higher fees, no dependencies or conflicts, and immediate executability are prioritized and sorted by profitability and viability.
In Bitcoin, miners favor transactions with higher “fee rates” (fees per virtual byte), subject to the block’s weight cap (around 4 million weight units as of 2025). On Ethereum, EIP-1559 introduced base and priority fees; builders select non-conflicting transactions offering higher priority fees, constrained by the block gas limit (usually tens of millions of gas units).
Additional considerations include account nonce order (e.g., Ethereum requires strictly increasing nonces), replacement transactions (users raising fees to speed up confirmation), and read/write conflicts across transactions. A well-constructed candidate block minimizes state conflicts and execution failures, improving its chances of network acceptance.
While candidate blocks serve similar functions in both networks, their creation and acceptance differ. Bitcoin uses Proof of Work, where miners win by finding a valid hash for their candidate block. After the Ethereum Merge, Proof of Stake designates validators to propose candidate blocks in fixed time slots, confirmed by votes from other validators.
Bitcoin’s block interval averages 10 minutes (protocol target, observed through 2025), emphasizing fee rate and weight constraints for transaction selection. Ethereum’s slots are about 12 seconds each (protocol parameter, observed through 2025), with Proposer-Builder Separation (PBS): specialized builders create candidate blocks, proposers select and sign them—enabling more precise management of transaction ordering and potential gains such as MEV.
Multiple candidate blocks can coexist on the network. Nodes select the most “effective” chain—often the longest or most validated one—causing some candidates to be discarded or triggering a chain reorganization (reorg).
Common causes include propagation delays leading to simultaneous blocks from different miners, competing proposals from validators in PoS systems, or attacks stemming from concentrated hash power or stake. Ethereum introduced “finality,” meaning blocks are highly unlikely to be reverted after a certain period; Bitcoin uses “confirmation counts,” where risk drops rapidly as more blocks are added.
For users, candidate blocks determine how quickly their transactions are likely to be confirmed. Low-fee or conflicting transactions may remain in the mempool for extended periods, missing inclusion in several candidate blocks.
For example, when you initiate an on-chain withdrawal via Gate, your transaction first enters the mempool, then awaits inclusion in a candidate block before being broadcast. The “confirmation count” shown on withdrawal pages indicates whether your transaction’s block has moved beyond candidate status to become widely accepted—and your risk diminishes as confirmation numbers increase.
A candidate block is merely a proposal. Once accepted by the network, it becomes an official block and starts accumulating confirmations. Only after reaching sufficient confirmations or finality is it considered irreversible with minimal fund risk.
Practical advice: pay reasonable fees when remitting or withdrawing to avoid long waits in the mempool; for Bitcoin, wait for multiple confirmations before considering funds secure; for Ethereum, watch for finality (typically within minutes, depending on network conditions). If your transaction is stuck, you can accelerate it by increasing the fee or canceling and resubmitting.
Candidate blocks are a critical intermediate stage in block production: selecting transactions from the mempool, constructing and broadcasting according to protocol rules, then becoming official upon consensus acceptance. Their fate depends on fees, capacity, production mechanisms, and network propagation—and they may be replaced through competition. Understanding candidate blocks helps you interpret “pending confirmation” statuses accurately, set appropriate fees and wait times, and better manage fund arrivals and risk control in platforms like Gate.
If a candidate block is not accepted by the network, it will be discarded by miners or validators. The transactions inside may return to the mempool for future inclusion. This is normal and does not endanger user funds—unconfirmed transactions are simply not yet on-chain. During times of congestion, lower-priority candidate blocks are more likely to be replaced.
Your transaction being in the candidate block stage means it has been picked up and packaged by a miner or validator but has not yet been finally confirmed on-chain. This usually takes seconds to minutes depending on network conditions—it’s a standard pending state. You can check transaction hash status on Gate or other block explorers for real-time confirmation updates.
The Gas estimate displayed for candidate blocks is typically a projection. Miners or validators adjust dynamically based on actual network congestion. The final Gas fee consumed is often lower than initial estimates shown in candidate blocks. For better Gas prices, it’s best to transact during off-peak periods.
The mempool serves as a “waiting room” for all unconfirmed transactions; candidate blocks are curated collections selected from this pool by miners or validators. Transactions enter the mempool first; if chosen, they’re included in a candidate block; only upon that block’s confirmation do they become officially on-chain.
Confirmation speed depends primarily on each blockchain’s block interval and consensus mechanism. Bitcoin’s average 10-minute intervals are slower; Ethereum’s ~12-second slots are much faster; Layer 2 solutions like Arbitrum can confirm in milliseconds. The time from generation to final confirmation for candidate blocks is determined entirely by each chain’s underlying design.


