Transactions, blocks, and finality

From request to record

Pressing Send starts a sequence with five distinguishable steps. Your wallet constructs a transaction describing what should change. You authorize it with a signature produced by your private key. The wallet broadcasts it to network nodes, which check it against the rules—is the signature valid, does the account hold enough, is the fee sufficient. A validator or miner then includes valid transactions in a block. Finally, other nodes verify that block and extend the chain on top of it.

Only the second step involves you, and it is irreversible in a way most interfaces do not emphasize. Once a valid signature is broadcast, no part of the remaining sequence asks for your consent again. Everything you can control happens before you approve.

Between broadcast and inclusion, a transaction sits in a waiting area often called the mempool. During busy periods the queue grows and transactions offering higher fees are typically selected first. This is why a transfer can appear to hang: it is not lost, it is queued.

Confirmations and finality are not the same

A confirmation is evidence that a transaction was included in a block. Each additional block built on top makes reversing that history more expensive, so services often wait for several confirmations before crediting an account. The number they wait for is a risk policy, not a protocol constant.

Some networks add explicit finality: after a defined point the protocol treats a block as settled, and reverting it would require an attack the rules are designed to make prohibitively costly. Others offer only probabilistic assurance that strengthens with depth. Neither approach is universally better, but the practical consequence differs, and a rule learned on one network can be wrong on another.

The honest general statement is narrow: more depth means less chance of reversal, the required depth depends on the network and on how much the transaction is worth, and no network offers a customer-service reversal after the fact.

Read status before reacting

Pending, replaced, failed, and confirmed are four different states with four different responses. Pending means broadcast but not yet included—usually the answer is to wait, or to use the wallet's replace-by-fee option if it offers one. Replaced means a later transaction with the same nonce took its place. Failed means the network processed the attempt and rejected the outcome.

A failed smart-contract call can still consume a fee. That surprises people, but it follows from how the network works: validators expended real computation to run the code and discover that it reverted, and that work is paid for regardless of the result.

The most expensive mistake at this stage is sending the same payment twice because the first appeared to do nothing. Before resending anything, find the transaction hash and look it up on an explorer for the correct network. A transfer that is merely slow and a transfer that genuinely failed look identical in a wallet interface and completely different on the chain.

• Locate the transaction hash before drawing any conclusion.
• Check it on an explorer for the network you actually used.
• Distinguish service status from network status—they can disagree.
• Never resend until the first attempt's state is known.

What the chain shows, and what it does not

Public explorers can show addresses, amounts, contract calls, fees, timestamps, and status. This makes independent verification possible without asking anyone's permission, which is genuinely valuable when a service and a network disagree about what happened.

What an explorer does not show is who anyone is. It does not display a legal name, and it cannot tell you whether an address belongs to a person, a company, or a contract. But activity can often be linked—through address reuse, through services that verified identity, through public posts, or through analysis of transaction patterns. Public does not mean anonymous, and a record that is permanent today may be analysed with better tools tomorrow.