From Shared History to Per-Sender Sequence
In earlier modules, the blockchain was described as a shared history that many computers keep in sync. Changes to this shared history happen through transactions, which are signed proposals saying how balances or records should be updated.
Ownership in this setting means authorization: a valid signature from an address is permission to propose changes that affect that address. This article now zooms in on a narrower question: when one sender creates several signed proposals, how do those actions fit into the shared history, and why must they be arranged in a clear sequence?
- You already know that a blockchain is a shared record that many computers agree on.
- You already know that transactions are signed proposals to change that shared record.
- You already know that ownership means authorization to make certain changes, not physical possession of coins or tokens.
- New idea in this article: transactions from the same sender are not independent; they form a sequence that must make sense as a whole.
- This new idea will later explain why some transactions appear pending, stuck, or failed when viewed in wallets or explorers.
What Does “Ordered per Sender” Mean?
Ordered per sender means that, for each address, the network treats its transactions as if they are written in a single line, one after another. There is an implied sequence for that sender: a first transaction, a second transaction, a third transaction, and so on.
Before a transaction from that sender is accepted into the shared blockchain history, the network needs to know where it sits in that personal line. This per-sender order is enforced even if different computers first see the transactions in a different arrival order, so physical time or message timing does not by itself decide which one counts as “first” for that address.
How Same-Sender Transactions Depend on Each Other
Whenever an address spends, transfers, or interacts with an application, that action usually changes something about its situation: its balance, a stored setting, or some other piece of state. The next transaction from the same sender then starts from this new situation, not from the old one.
In practice, a later transaction often quietly assumes that an earlier one has already gone through. For example, it may assume that funds have already arrived, or that a permission has already been set. Looked at alone, each transaction might seem fine, but when they are placed in a sequence, some combinations and orders will no longer make sense or will no longer be possible. These hidden dependencies are very common, even if they are not obvious when pressing “send” in a wallet.
- Sending coins to a friend, then immediately trying to send the same coins again to someone else: the second send only makes sense if the balance after the first send is still enough.
- Setting a spending limit for an app, then asking the app to move funds for you: the move only makes sense after the limit has been set.
- Depositing tokens into a service, then asking to use features that require those tokens: the feature request only makes sense if the deposit has already taken effect.
Why the Network Enforces a Sequence per Sender
A blockchain is kept by many computers that all maintain the same shared history. For that shared history to make sense, they must agree on the story of each sender: which action was first, which was second, and what the sender’s situation looked like before and after each step.
Because messages travel across the internet, different computers can see the same two transactions in different arrival orders. To avoid confusion, they rely on an explicit per-sender sequence instead of just “who saw what first.” This sequence is checked before transactions are added into blocks, so that every participant ends up with the same ordered story for each address.
Key facts
Correct balances
Applying a sender’s transactions in a fixed order ensures that additions and subtractions happen in the right sequence, so the final balance is the same for everyone.
Correct app behavior
Many applications expect certain steps to happen before others, so per-sender ordering keeps their internal logic and permissions consistent.
Shared agreement
When all participants see the same ordered list of actions for an address, they can agree on what that address has done and what it is allowed to do next.
Pro Tip:What matters is the logical sequence the network enforces for each sender, not the exact wall-clock order in which messages were sent or received. The network can reshuffle arrival times as long as it keeps each address’s actions in a consistent story order.
When a Valid Transaction Becomes Invalid in Sequence
A single transaction can look fine when checked on its own: it is properly signed, it refers to a real address, and it asks for an amount that seems available at first glance. However, its true validity also depends on what else that sender has already done or is trying to do.
Once earlier or later transactions from the same address are taken into account, the situation can change. After applying other actions in the sequence, there may no longer be enough balance, or a required earlier step might be missing. For this reason, the network checks each transaction in the context of the sender’s ordered actions before it is accepted into the chain.
- An address has just enough funds for two separate payments. Looked at alone, each payment is affordable, but after one payment is applied, the other no longer fits the remaining balance, so the network must reject or delay it.
- A user plans to first set a permission for an app and then use that permission to move tokens. If the use action appears without the earlier setup in the sequence, the network must treat it as invalid or not yet allowed.
- If a later transaction assumes that some asset or setting exists, but an earlier transaction in the sequence removed or changed it, the later action can no longer be accepted as originally written.
A Simple Mental Model: One Personal Timeline
One way to picture per-sender ordering is as a personal timeline or journal for each address. Every new transaction is like adding the next line to that journal: it only makes sense if it follows naturally from the lines that came before.
The blockchain’s job is to weave many of these personal timelines into one shared record without breaking the story for any individual address. When thinking about pending or failed transactions, it helps to ask where each action sits on that personal timeline and whether the earlier lines in the story have already been accepted.
- I think of each address as having its own timeline or story of actions, not just isolated transactions.
- I understand that the network must agree on the order of that story before adding those actions to the blockchain.
- I realize that a later transaction may have to wait until earlier actions in the same story are accepted.
- I see that a transaction can fail or be rejected if it no longer fits the story created by earlier actions from the same sender.
From Ordering to Pending and Rejected Transactions
TL;DR
- Transactions from the same sender are not independent; they form a single sequence or story.
- Later transactions often rely on the balances or settings created by earlier ones.
- The network must agree on the exact order of each sender’s actions before adding them to the blockchain.
- A transaction can look valid on its own but become invalid once earlier actions from the same sender are applied.
- This need for per-sender ordering explains why some transactions have to wait, get stuck behind others, or are eventually rejected.
The next step is to see how this personal timeline idea shows up in the part of the system that holds transactions before they are added to blocks. Later articles will describe mempools and how they decide whether a transaction is acceptable right now, given what else that sender has already sent.
With the idea of per-sender ordering, it becomes easier to see that a pending or failed transaction is often about where it fits in the sequence, rather than a random glitch. One action can effectively block another until the story for that address makes sense again.