A block is not created the moment a user presses send. The signed transaction first travels through a peer network, where computers check basic validity and may hold it among other pending proposals. A miner, validator, or permissioned leader later chooses an ordered batch and proposes it to the rest of the network.
Block production separates proposing from accepting. The producer has discretion over timing and transaction order, but cannot force independent validators to accept an invalid block. Understanding this path explains why fees affect inclusion, why a visible pending transaction is unsettled, and why two valid blocks can briefly compete.
What you will learn
- Trace a transaction from signing through block proposal and validation
- Explain the producer's ordering power and the limits imposed by validators
- Relate block intervals, confirmations, and reorganizations to settlement confidence
Broadcast begins a process, not a settlement
A wallet constructs a transaction containing the requested action, required references, and a cryptographic signature. It sends that message to one or more nodes. A receiving node checks properties such as signature validity, available funds, sequence numbers, and fee rules before relaying the message to peers or storing it in a pending pool.
Pending pools are local rather than one universal waiting room. Two nodes can know about different transactions because of network delay, capacity policies, or fee thresholds. A transaction displayed as pending has reached some infrastructure, but it has not yet gained a place in the network's agreed sequence and may still be replaced or dropped.
The producer assembles a candidate
The protocol determines who may propose next through proof of work, proof of stake, a rotating permissioned schedule, or another mechanism. The eligible producer selects transactions it knows, orders them, executes any required state changes, and constructs block metadata. Capacity limits mean it may leave otherwise valid transactions for later.
Producers commonly prefer transactions that offer higher compensation relative to scarce block space, but economics is not the only influence. They can include their own transactions, exclude selected senders, or order interacting trades advantageously. The protocol can constrain this power, yet transaction ordering remains an important source of censorship and value-extraction risk.
Other nodes validate independently
After proposing the candidate, the producer sends it to peers. Each validating node checks the producer's eligibility or proof, the link to the parent block, capacity limits, and every transaction. It independently computes the resulting ledger state. A valid producer credential cannot rescue an unauthorized transfer or an incorrectly calculated state transition.
Acceptance first occurs locally. If the block follows the node's rules and extends the history selected by its consensus algorithm, the node stores it and relays it. Widespread agreement emerges from many compatible local decisions. A block explorer is merely one observer of this process, not the authority that makes the block official.
Competing proposals and confirmations
Network communication takes time. Two eligible producers may publish different valid blocks referencing the same parent before learning about each other. Different nodes can temporarily follow different tips. The consensus rules provide a way to prefer one branch as later blocks or votes arrive, while transactions from the displaced block may return to pending status.
This replacement is called a chain reorganization. Systems vary widely in how often it occurs and whether they later provide explicit finality. A confirmation means inclusion plus some degree of subsequent support; it is not a universal guarantee. Payment policies should consider the chain's actual rules, transaction value, and consequences of reversal.
Common misconceptions
“A block is created as soon as users click send.”
Sending broadcasts a proposed transaction. An eligible producer must later select it, place it in a candidate block, and have that block accepted by validators.
“All transactions inside a block have identical settlement certainty.”
They share the block's current status, but application dependencies, cross-chain actions, and later finality requirements can give them different practical settlement risks.
“The block producer can include any transfer it wants.”
A producer controls selection and ordering among proposals, but validating nodes reject invalid signatures, overspending, malformed execution, and other rule breaches.
Risks and limitations
- Pending transactions can be delayed, replaced, or dropped when fees, nonce ordering, local policies, or congestion work against inclusion.
- Producers may censor selected transactions or reorder interacting operations to benefit themselves or favored participants.
- Short-lived competing blocks can reorganize recent history, reversing an inclusion that an application treated as settled too early.
- A wallet or explorer may present a simplified status that does not match the chain's precise confirmation and finality conditions.
Key takeaways
- Broadcast transactions are proposals that remain unsettled until accepted in the ordered history.
- An eligible producer chooses and orders transactions within protocol capacity constraints.
- Independent nodes verify the complete block rather than trusting the producer's claim.
- Network delay can create competing valid tips and temporary reorganizations.
- Settlement policy should follow the specific chain's confirmation and finality model.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.