Pressing send does not move anything. It creates a message, signs it with a key held on the sending device, and broadcasts that message to whichever machines will listen. Everything after that is other people's software deciding whether to relay it, include it and build on top of it, and the sender's only remaining influence is the fee attached.
Signing, which happens entirely on the sender's device
A transaction is a small structured statement: sender, recipient, amount, fee terms, and on account-based chains a nonce that fixes its position in the sender's own sequence and prevents it being replayed. The wallet hashes that statement and produces a digital signature with the private key. Anyone can then verify, using the corresponding public key, that the holder of the key authorized exactly those contents and not some altered version.
Two things follow. The key never leaves the device, which is why a separate hardware signer is useful: malware can propose a payment but cannot sign one. And the signature covers the entire message, so amount and recipient cannot be edited in transit. An address altered by malicious software is altered before signing, not after, which is why address-poisoning attacks work by planting a lookalike address in a clipboard or in a list of recent recipients, where a person copying quickly will not notice the middle characters differ.
Broadcast, and the waiting room
The signed message goes to one or more nodes, which validate it at low cost against basic rules, then gossip it onward to their peers. It now sits in each node's mempool. There is no global queue and no guaranteed order of arrival; different nodes keep slightly different sets, and a transaction paying too little may be evicted from some mempools entirely while surviving in others.
At this point the transaction is public but not executed, and that gap is exploitable. Anyone watching can see the intent, which is the raw material for maximal extractable value. A large swap sitting visibly in the mempool can be surrounded by trades placed immediately before and after it, so the original sender receives a worse price than the quote implied. Private submission channels exist precisely to avoid this exposure, at the cost of relying on a specific relay.
Inclusion
Whoever produces the next block selects transactions from what they can see. On several large chains that role has been split: specialized builders assemble candidate blocks and bid for the right to have them proposed by a validator or a miner. Selection is mostly by fee density, with the builder's own ordering profits added on top, which is why raising the fee is the only reliable way to move up the queue and why no amount of waiting guarantees inclusion at a fee the market has left behind.
Inclusion is not the same as success. A transaction can be included and still fail: a contract call may revert because a required condition was not met, because a price moved beyond a specified tolerance, or because the gas limit was too low for the work involved. The fee for the computation performed is still consumed, because the network did the work. A failed transaction on-chain is a real event with a real cost, not a non-event, and it appears in transaction counts like any other.
Confirmation and finality are different claims
Once included, the transaction has one confirmation. Each subsequent block built on top makes reversal more expensive, since reversing means producing a competing chain branching from before that point and extending it further than the current one. Under proof of work this is probabilistic: no depth is mathematically final, the chance of a reorganization simply falls as depth grows. That is why custodians and exchanges each choose their own confirmation threshold, why those thresholds differ between assets, and why a service crediting funds quickly is accepting a quantified risk rather than following a rule.
Under Ethereum's proof of stake the guarantee is shaped differently. Blocks are proposed in fixed slots, and after roughly two epochs a checkpoint is justified and then finalized, meaning reverting it would require destroying a very large amount of bonded stake. That is a stronger and more explicit form of finality, though it takes minutes rather than seconds. Chains advertising sub-second confirmation are usually describing the moment a block is first seen, not the moment reversal becomes prohibitive, and the difference matters for anything that releases goods on receipt.
Settlement in the financial sense is a further step again. An exchange crediting a balance, or a merchant releasing an order, applies its own policy on top of whatever the chain guarantees, and that policy is where most of the waiting a person experiences actually comes from.
The common ways it goes wrong
A fee set too low leaves the transaction pending. On account-based chains it also blocks every later transaction from the same address, because nonces must be consumed in order, and the standard remedy is to resend with the same nonce and a higher fee rather than to send a second transaction.
Sending an asset over the wrong network, or to an exchange deposit address that does not support that network, is among the more common permanent losses, since the recipient may have no key for the destination even though the address looks valid. Sending a token to a contract that has no logic for handling it has the same effect. Both are consequences of a design in which addresses are just numbers and nothing checks intent.
None of this can be reversed by anyone. There is no support desk with an override, because the absence of one is exactly the property that makes the ledger credible. The only recourse is asking the recipient to send it back, where there is an identifiable recipient who can.
The network activity pages show pending transactions and block time, which together explain most of what someone waiting on a confirmation is experiencing, and the glossary defines each stage named above. The next lesson turns from mechanics to the claim itself, and asks what a holder actually owns.