The blocks provide a shared transaction history. They do not by themselves establish an asset's market value, the quality of an investment, or the truth of information supplied from outside the network.
What the chain contributes
Someone can also recompute hashes for a rewritten sequence. The reason a network rejects or resists that alternative lies in its validation, consensus and security rules—not in the existence of a hash link alone.
Keep these jobs separate:
| Job | Question it answers |
|---|---|
| Hash commitments | Does this data match the history to which the hashes commit? |
| Transaction validation | Is this change permitted from the preceding state? |
| Consensus and fork choice | Which valid history does the network accept when candidates compete? |
| Finality | Under what conditions can an accepted history still be displaced? |
A transfer that balances
| Account | Before | Change | After |
|---|---|---|---|
| A | 100 | −30 | 70 |
| B | 0 | +30 | 30 |
| Total | 100 | 0 | 100 |
The accepted transfer changes the account balances without changing the total. A block can commit to that transfer's position in the history. Hashing a different record that credits B without the required debit would not make that record valid under these toy rules.
The order matters when requests conflict. Suppose A submits pending requests to transfer 30 and 80 units from its original balance of 100. Each is affordable in isolation, but together they require 110. If the 30-unit request executes first, A has 70 left and the 80-unit request fails the balance check. If the 80-unit request executes first, A has 20 left and the 30-unit request fails. This is one simple reason transaction ordering risk belongs in execution analysis.
Included is not automatically final
A transaction can be valid and included in a block while that block's place in the accepted history is still unsettled. Competing valid blocks can arise, and the protocol needs rules for selecting a history.
For a trading or reconciliation system, retain the network, transaction identifier, block reference and the confirmation or finality policy used. A pending transfer, a transfer in the current chain and a transfer meeting that policy are different observations. Treating them as identical can understate settlement risk.
Sources
- Bitcoin Developer Guide, Block Chain: hash-linked history, independent node validation, unspent outputs, competing chains and proof of work.
- Ethereum developer documentation, Blocks: parent references, ordered transactions and checking the resulting state.
- Ethereum developer documentation, Proof-of-stake: transaction execution, fork choice and checkpoint finality. Protocol descriptions checked on 2026-10-27.