Parallel transaction execution lets a blockchain process several transactions at the same time when they do not touch the same state, instead of running them strictly one after another. Sequential execution is simpler because every node applies transactions in one fixed order. Parallel execution must reach the same final result, but it can use several processor cores at once, which raises throughput when many transactions in a block are independent of each other.
Last updated: October 5, 2026.
What is parallel transaction processing?
Every blockchain keeps a shared state: account balances, contract storage, and other records. A transaction reads part of that state and writes changes to it. Two transactions conflict when one writes to state that the other reads or writes, such as two payments drawn from the same account. Transactions that touch entirely separate state do not conflict, and the order in which they run makes no difference to the result.
Parallel processing uses that fact. Independent transactions run side by side on different cores, and conflicting ones run in a set order. The hard requirement is determinism: every node must end up with exactly the same state, or the network cannot agree on the block.
How does parallel execution work?
There are two common designs, and both have to deal with conflicts.
| Approach | How conflicts are handled | What developers provide |
|---|---|---|
| Sequential | No conflicts are possible, since one transaction runs at a time | Nothing extra |
| Declared access | Each transaction lists the state it will touch before it runs, and a scheduler groups the ones that do not overlap | The list of accounts or storage each transaction uses |
| Optimistic (speculative) | Transactions run in parallel, conflicts are detected afterwards, and affected transactions are run again so the result matches the block order | Usually nothing extra |
Declared access avoids wasted work but asks more of developers and wallets. Optimistic execution keeps existing code unchanged but spends effort re-running transactions that collide.
Is parallel execution faster than sequential execution?
It depends on the workload. When most transactions in a block are independent, parallel execution gets more done in the same time. When many transactions hit the same popular contract or account, they conflict and have to run in order, so the gain shrinks.
Execution is also only one part of a blockchain's capacity. Consensus, network propagation, and reading and writing stored state set their own limits, so faster execution does not always mean more transactions per block.
Can EVM chains support parallel execution?
Yes, within the rules of the EVM. The EVM defines the result of a block as if its transactions ran one at a time, in the order they appear. An implementation can still execute them in parallel internally, as long as the state it commits matches that order. This is one reason parallel EVM designs often use the optimistic approach, since EVM transactions are not required to declare in advance all the state they will touch.
FAQ
Does parallel execution change the result of my transaction?
No. A correct parallel design produces the same state as running the block in a defined order. Only the way the work is scheduled changes.
Do smart contract developers need to change their code?
It depends on the design. Declared-access models need each transaction to state what it touches. Optimistic models usually run existing code as is, although contracts with heavily shared state see smaller gains.
How does execution on one chain affect cross-chain applications?
Each chain executes transactions under its own rules. When an application sends a cross-chain message, the destination chain processes the delivery as one of its own transactions, whatever execution model it uses.
Build across execution environments
For cross-chain concepts and supported integration paths, start with the LayerZero developer resources.