A blockchain can process several transactions at once, but that does not mean every transaction benefits from parallel execution. The difference becomes clear when independent operations run alongside transactions that need to update the same data.
Imagine two people transferring tokens between separate accounts. Their transactions may have no effect on each other, so a network could execute them simultaneously. Now consider two traders swapping assets through the same liquidity pool on a decentralised exchange. Both trades change the pool’s reserves, meaning the result of one can affect the calculation for the other.
This is the central challenge behind parallel execution in blockchain. The technique allows a network to make better use of available computing power, but it cannot simply ignore dependencies between transactions. Understanding that distinction helps explain both the potential and the limitations of faster blockchain networks.
Parallel execution in blockchain starts with the data each transaction touches
Every blockchain maintains a state: the information that describes its current condition, including account balances and the data held by smart contracts. A transaction can read this information, change it, or do both.
When two transactions access separate, independent parts of the state, there may be no reason to execute them one after the other. A validator — a computer that helps process and verify transactions — can use multiple processor cores to handle compatible operations simultaneously.
The difficult part is preserving the correct result.
Transactions within a block still have a defined order. Parallel execution must produce the same final state as executing those transactions sequentially in that order. Otherwise, different computers processing the same block could disagree about account balances or contract data, undermining the network’s consistency.
This requirement rules out simply allowing every operation to change shared information whenever it reaches the processor. The network must identify which transactions can safely run together and ensure that their results remain valid.
In practice, this means tracking which accounts or pieces of contract storage a transaction reads and writes. If those accesses are independent, parallel execution becomes possible. If one transaction depends on data changed by another, the network must respect that dependency.
Why a busy liquidity pool can limit the speed gains
Consider a decentralised exchange that uses a liquidity pool to facilitate trades. The pool holds reserves of two tokens, and its pricing mechanism uses those reserves to calculate the outcome of each swap.
When a trader exchanges one token for another, the pool’s balances change. A second trade involving the same pool may therefore need to use the updated reserves to calculate its output correctly.
If both transactions execute using the same earlier snapshot of the pool’s data, the second could produce a result that does not reflect the first trade. The blockchain must detect and resolve that conflict before accepting an inconsistent state.
This is one example of a state conflict: two transactions access data in ways that mean their results cannot simply be combined without checking their relationship.
The same issue can arise when several operations update a shared smart-contract variable, such as a counter or a common balance. Even a network with many processor cores cannot remove the underlying dependency. It can only manage the work around it.
That creates an important limitation. If a large share of transactions touches independent accounts, the network has more opportunities to execute them simultaneously. If many operations compete to modify the same data, some work must be coordinated or repeated.
Parallel processing can reduce unnecessary waiting, but it does not make dependent transactions independent.
Solana, Monad and Sei approach the problem differently
Solana, Monad and Sei all use parallel execution, but their approaches to identifying compatible transactions and handling conflicts differ.
Solana: declare account access in advance
Solana transactions specify the accounts they need, including which accounts can be modified. Validators use this information to determine which transactions can run concurrently. Operations that write to different accounts are easier to schedule in parallel.
This makes the structure of a transaction important. If an application directs many operations towards the same writable account, those operations can become a bottleneck even when other parts of the network have capacity available.
Monad: execute optimistically, then check the result
Monad uses an approach known as optimistic execution. Rather than waiting for every earlier transaction in a block to finish, the network can begin executing subsequent transactions in parallel.
The potential problem is that a transaction may initially read a value that should have changed after an earlier transaction. Monad tracks the data used during execution and checks whether it remains consistent with the results that precede it in the block’s order.
If a transaction relied on outdated data, it must be executed again using the correct state. Work that does not depend on that state may be reusable, reducing the cost of repeating the operation.
The benefit is that the network can take advantage of parallel processing without assuming in advance that every predicted execution will be correct.
Sei: estimate dependencies and resolve conflicts
Sei also uses optimistic concurrency control, a method that allows transactions to run concurrently before checking whether their actual data accesses conflict.
Its execution engine estimates which parts of the state a transaction is likely to read or modify, then uses those estimates to help schedule compatible operations. During execution, it tracks the accesses that actually occur.
When conflicting transactions are identified, the affected operations can be re-executed in a deterministic sequence.
The distinction between these designs is not simply how many transactions can start at the same time. It is how each network identifies opportunities for parallel execution, handles uncertainty and ensures that the final state remains correct.
Why transaction throughput does not tell the whole story
Transaction throughput refers to the rate at which a blockchain processes transactions, often expressed as transactions per second (TPS). It is a useful measure, but it cannot fully describe how a network will perform under different workloads.
A benchmark dominated by simple transfers between independent accounts may give parallel execution plenty of room to work. A decentralised application in which numerous users interact with the same contract or liquidity pool can present a very different challenge.
The amount of computing power available is only one part of the equation. Accessing and updating data, coordinating execution, storing results and communicating across the network can also constrain performance. More parallel work does not automatically translate into a proportional increase in completed transactions.
Smart-contract design matters, too. Applications that distribute data across independent accounts or storage locations may offer more opportunities for parallel execution than those that repeatedly update a shared piece of state.
Comparisons between networks therefore need to consider the transactions being tested, the hardware and other test conditions, and whether the reported figures represent a measured result or a theoretical or advertised capacity.
A single TPS figure cannot establish which architecture will perform best for every application.
Can parallel execution solve blockchain scalability on its own?
Parallel execution can help a blockchain process more transactions by making better use of available computing resources. However, it does not remove every bottleneck involved in running a decentralised network.
The underlying constraint is the relationship between transactions. When operations can proceed independently, they offer an opportunity for simultaneous execution. When they rely on the same changing data, the network must still coordinate their effects or repeat work performed with an incorrect view of the state.
That is why the most useful question is not simply how many transactions a blockchain can execute at once. It is how effectively the network handles the kinds of transactions its applications actually generate.
Solana, Monad and Sei illustrate different ways to approach that challenge. Their mechanisms can improve throughput, but the gains depend on transaction dependencies, application design and the cost of maintaining a consistent result.
Parallel execution makes better use of processing capacity. It does not abolish the need for coordination — and that distinction is essential when assessing what faster blockchain infrastructure can realistically deliver.