You press “Send” and see a spinning indicator. Is the operation complete? Not necessarily. A transaction is a signed instruction asking a network to change its ledger. Sending it and having it executed are different steps.
The wallet guide explained who signs. Now we follow the instruction, using Ethereum as an example. Other blockchains have different details.
What you ask the network to do
A simple transfer specifies a recipient and an amount. An application interaction may instead ask a program to exchange tokens or change a permission. The technical recipient may be a contract rather than the person who eventually receives an asset.
The wallet prepares the details and requests your signature. This authorises an instruction; it does not establish that an offer is honest. The Ethereum transaction documentation describes the information sent to the network.
From a click to a block
- Preparation. The wallet assembles the action, network and estimated fees.
- Signing. You approve the instruction under your account’s rules.
- Submission. It reaches the network and may remain pending.
- Execution. Inclusion in a block involves checking the rules and calculating the result.
- Confirmation and finality. The network consolidates its history through its consensus mechanism.
A block groups transactions. Inclusion and finality, when reversing that history becomes strongly constrained by the protocol, need not happen together. The Ethereum blocks documentation explains this progression. There is no universal completion time across networks.
What are fees for?
Executing an instruction uses resources. On Ethereum, gas measures computational work. Fees depend on the work consumed and its unit price, rather than simply being a percentage of the amount transferred.
An included transaction that fails can still incur fees: the network performed work before reaching the failure. A request you reject in the wallet before submission is different; the blockchain has not executed it. The gas documentation explains this distinction.
Read the result, not the animation
Consider a fictional example. Lina requests a transfer of 10 units to Sami. Her wallet says “sent”, but the explorer says “pending”. Sami should not treat the first screen as proof of final receipt.
A block explorer lets Lina search for the transaction identifier, also called a hash. On the correct network, she checks the status, addresses, amounts and actual fees. When a contract is involved, token transfers also matter: the native-currency amount field may not tell the full story.
If execution fails, Lina reads the reason before trying again. Repeating the same request blindly can repeat the problem. If it succeeds but goes to the wrong address, the network generally has no undo button.
Check your understanding
“My exchange failed, so I cannot have paid any fees.” True or false? False. A rejection before submission differs from an execution that fails after consuming network resources.
Remember: signing, submission, execution and finality answer different questions. A verifiable status matters more than a wallet animation.
Next: cryptocurrency, token and NFT: what is the difference?