From Owning Value to Changing History
In the previous step, we described how a blockchain maintains a shared record of who currently controls which assets. A transaction is the mechanism that proposes changes to that record.
Owning value in a blockchain system does not mean holding an object. It means having a permission defined by past history. A transaction does not move an object - it proposes to move that permission to someone else.
Crucially, creating a transaction is not the same as the network accepting it. A transaction is a request, not a committed change. Only when the network later accepts it does history actually update.
Core Definition: A Proposal to Change State
A transaction is a signed message that proposes a change to a blockchain's shared state. Signing proves that the sender is authorized to request that change.
A transaction does not guarantee inclusion, speed, or permanence. It becomes part of history only if the network later accepts it.
Why Transactions Exist
Blockchains have no central operator, so they need a neutral and verifiable way for participants to request changes to shared history. Transactions provide that mechanism.
In practice, many valid requests can exist at the same time. Nodes need a way to verify them, reject conflicting ones, and converge on one ordered history.
Without transactions, a blockchain would have no reliable way to compare, validate, or order competing requests.
What a Transaction Must Answer
Every blockchain transaction, regardless of the protocol, must answer the same basic questions.
Key facts
Who is authorized?
The address or account currently allowed to spend the value.
What change is proposed?
Which asset is being transferred, and in what amount.
Who receives control?
The destination address or account.
Is it valid?
A cryptographic signature proving authorization.
Different blockchains encode transactions differently, but every transaction answers the same fundamental questions. At this level, the exact fields do not matter - the logic does.
Different blockchains track ownership differently (for example, accounts or unspent outputs), but the proposal model remains the same.
How a Transaction Becomes History
- A user decides to change ownership (intent).
- A wallet constructs and signs a transaction proposal.
- The transaction is broadcast to the network.
- Nodes independently verify basic rules.
- A block producer includes it in a block.
The key separation is between proposing a change and recording it. Wallets can create valid proposals, but only block inclusion updates shared history.
“Confirmations” simply reflect how many additional blocks build on top of the block that included the transaction. They increase the cost of reversal over time.
What Wallets Do — and What They Don’t
Wallets manage keys and create signed transaction proposals. They do not decide what becomes history.
Different wallets may display different statuses for the same transaction.
Only the network - independent nodes applying shared rules - determines whether a transaction is accepted, ordered, and treated as final. Wallet labels like sent or pending describe local status, not global agreement.
Pro Tip:“Sent” means broadcast. Only block inclusion means accepted. Only confirmations increase confidence.
What Transactions Do Not Guarantee
Because transactions are proposals, they come with no guarantees. Even valid transactions may be delayed, replaced, or never included if conditions change.
Recent history can sometimes be reorganized, so confidence increases gradually as more blocks build on top of the one that included your transaction. These are natural properties of decentralized, proposal-based systems.
The Mental Model
- Transactions propose changes.
- Wallets sign proposals.
- Nodes verify proposals.
- Blocks order accepted proposals.
- History is the ordered result.
If you remember one thing: transactions request changes, blocks decide ordering, and shared history is the result of accepted requests.
Where This Leads Next
Transactions explain how changes are proposed. The next question is how many competing proposals are batched, ordered, and referenced over time into one timeline. That is the role of the block.