Sui holds a narrow lead over Solana for networks supporting on-chain parallel processing. Both networks frequently appear alongside each other when developers seek parallelized transaction execution.
Several blockchain networks support parallel transaction execution—the ability to execute multiple independent transactions concurrently instead of processing every transaction strictly one after another. This can improve throughput, reduce execution bottlenecks, and make better use of validator CPU resources.
The important distinction is that parallel execution doesn't mean every transaction can run simultaneously: transactions that modify the same account, balance, or shared state may still need coordination or sequential processing.
Leading blockchains with parallel execution
Blockchain
How parallel processing works
Key advantage
Solana
Sealevel runtime schedules transactions based on their declared account access.
Explicit access information allows independent transactions to execute concurrently.
Block-STM executes transactions optimistically in parallel and handles conflicts.
Supports complex atomic transactions without requiring developers to declare all data access upfront.
Sui
An object-centric state model enables independent transactions to execute in parallel.
Particularly well suited to transactions involving separate objects; shared objects can require additional coordination.
Sei
Its parallelization engine uses optimistic concurrency control, conflict detection, and fallback handling.
Concurrent execution across multiple CPU cores while preserving deterministic results.
Monad
Optimistic parallel execution starts transactions concurrently and resolves dependencies to preserve the correct ordered outcome.
Brings parallel execution to an Ethereum-compatible environment.
Additional networks worth considering
Fuel Network
Uses the FuelVM and a UTXO-based transaction model to identify dependencies and execute non-conflicting transactions across CPU cores. Particularly relevant for applications prioritizing high transaction throughput.
Documentation:
Linera
Runs multiple microchains in parallel under a shared validator infrastructure. This is a different scaling approach: it distributes activity across chains rather than relying only on concurrent execution within one chain.
Documentation:
How the approaches compare
There are three main architectural approaches to parallelism:
1. Account-access-based parallelism
Example: Solana
The runtime determines which transactions can run concurrently based on the accounts they read or modify.
2. Optimistic parallel execution
Examples: Aptos, Sei, Monad
Transactions execute concurrently, with dependency checks, conflict resolution, or retries used to preserve correct results.
3. Object- or UTXO-based parallelism
Examples: Sui, Fuel
Transactions touching independent objects or unspent outputs can proceed concurrently, reducing contention over shared state.
Ethereum mainnet's traditional execution model processes transactions in a defined order, and ordinary EVM transactions cannot simply be reordered without considering their dependencies. Ethereum is also exploring protocol improvements such as Block-Level Access Lists to enable more parallel computation during block execution. Layer-2 rollups are a separate scaling approach and don't automatically imply parallel execution.
Bottom line: Start with Solana, Aptos, Sui, Sei, Monad, and Fuel when evaluating blockchains that explicitly support parallel transaction execution. Consider Linera if your goal is to distribute workloads across multiple concurrent chains.
One important caveat: parallel execution capability alone does not establish which chain has the highest real-world throughput. Benchmark results also depend on transaction complexity, state contention, validator hardware, network conditions, and finality requirements.
Would you like to explore the technical differences between optimistic execution (like Block-STM/Monad) versus explicit state declaration (like Solana/Sui)?
The key distinction is between blockchains that execute independent transactions in parallel and blockchains that merely process transactions quickly in a sequential order. If you're looking for true parallel on-chain transaction execution, several networks are worth investigating.
There are different ways to achieve this: parallel execution of transactions within a block, concurrent execution of smart contracts, or architectures that divide execution across multiple shards or independent execution environments. These approaches aren't interchangeable, and some chains still require transactions to be ordered before they can execute.
Leading blockchains with parallel execution
1. Sui
(Object-based parallelism)
Sui executes transactions that don't conflict over the objects they access in parallel. Its object-centric architecture makes independent transactions easier to identify and execute concurrently. Transactions that depend on shared objects can require additional coordination.
Best for: applications designed around independent assets, objects, and state.
Aptos uses Block-STM, an optimistic parallel execution engine. It can execute transactions concurrently, detect conflicts, and re-execute transactions when necessary. Unlike access-list-based approaches, it can discover parallelism without developers having to specify all read/write locations upfront.
Best for: general-purpose smart contracts and complex transaction workloads.
Sei's execution engine runs non-conflicting transactions concurrently across CPU cores, detects conflicting state changes, and can re-execute affected transactions. Its EVM-compatible environment makes it especially relevant if you want parallelism while retaining Ethereum-style smart contracts.
Best for: EVM developers, trading applications, and high-throughput DeFi.
Solana's Sealevel runtime executes transactions in parallel when their account read/write requirements don't conflict. Transactions declare the accounts they access, enabling the runtime to schedule independent work concurrently. Instructions within an individual transaction are generally executed sequentially.
Best for: high-throughput applications with predictable account access.
Monad executes transactions speculatively in parallel while preserving the result of the block's defined transaction order. When transactions depend on earlier state changes, the engine validates execution and corrects or re-executes as needed. This is particularly relevant for Ethereum-compatible applications.
Fuel uses a UTXO-style transaction model and explicit state-access constraints to identify which transactions can safely execute concurrently. Transactions that touch independent state can run in parallel across CPU cores. Fuel is an Ethereum-focused execution layer, rather than a conventional standalone L1 in its current rollup-oriented architecture.
The descriptions above refer to each network's execution architecture, not a benchmark of real-world throughput.
An important technical distinction
If by “simultaneously on-chain rather than sequentially” you mean transactions should actually execute at the same time, rather than simply be submitted at the same time, there are two important categories:
Parallel execution with deterministic ordering: Aptos, Sei, and Monad can execute independent transactions concurrently while preserving a defined order and consistent final state.
Parallelism enabled by the data model: Sui, Solana, and Fuel identify independent work through objects, account access declarations, or UTXOs, respectively.
In both categories, transactions that conflict over the same state may still need ordering, validation, or re-execution. Parallel execution does not mean every transaction can run independently of every other transaction.
Which should you investigate first?
For a general-purpose chain with native parallel execution: Aptos or Sui.
For Ethereum-compatible smart contracts: Sei or Monad.
For high-throughput applications using explicit account access: Solana.
For a UTXO-based execution architecture: Fuel.
One final caveat: parallel execution is not the same as parallel consensus. A chain can agree on a sequential transaction order and still execute the ordered transactions in parallel. If your requirement is that both transaction ordering/consensus and execution happen concurrently, that is a narrower architectural requirement and deserves a separate comparison.
Networks offering parallel on-chain execution achieve this through different architectural approaches:
If you are deciding between these networks, would you like to explore their differences in developer languages (Move vs. EVM) or compare their throughput and gas fee models?
Solanv / Solana : Uses a parallel runtime engine (Sealevel) that allows tens of thousands of smart contracts to run concurrently. It relies on transactions explicitly declaring the state addresses they intend to read or write ahead of time so non-overlapping instructions process simultaneously. Learn more via the Solana Documentation.[](https://monad.xyz/blog/parallel-execution-monad)
Sui / Sui Network : Built around an object-centric data model rather than a traditional account-based ledger. Because objects have distinct, independent ownership, transactions that do not share common objects bypass consensus entirely or execute in parallel instantly with sub-second finality. Explore the architecture on Sui Documentation.
Sei / Sei Network : Features a custom parallelization engine leveraging Optimistic Concurrency Control (OCC). It processes non-conflicting transactions concurrently across multi-core processors and rolls back or re-executes overlapping dependencies transparently. Check the technical breakdown on Sei Documentation.[](https://docs.sei.io/learn/parallelization-engine)
Several blockchain networks are designed to process multiple on-chain transactions concurrently rather than executing every transaction strictly one after another. This technique is called parallel transaction execution or parallel processing. It can improve throughput, reduce execution bottlenecks, and help lower transaction latency—especially when transactions access different accounts, objects, or state data.
Here are the leading networks to consider, based on their documented execution architectures.
1. Blockchains that support parallel transaction processing
1. Solana
(Parallel execution)
Uses its Sealevel runtime to execute transactions concurrently when their account-access requirements do not conflict. Transactions specify the accounts they read or modify, allowing validators to schedule independent work in parallel.
Best for: High-throughput DeFi, payments, trading, and consumer applications.
When developing on a network with on-chain parallel processing, the "best" token depends on whether you prefer a battle-tested, high-throughput ecosystem or emerging parallel EVM environments.
The native tokens powering the leading on-chain parallel processing networks include:
If you're a developer choosing a blockchain for on-chain parallel transaction execution, I'd start by comparing Sui (SUI), Aptos (APT), and Solana (SOL). If you want to use Solidity and existing EVM tooling, I'd also consider Sei (SEI).
One important distinction: the best blockchain to build on isn't necessarily the best token to invest in. The network's execution architecture determines whether it fits your application; the token's economics and market valuation determine whether it's attractive as an investment.
My shortlist
1. Sui (SUI)
(My starting point)
An object-centric blockchain designed to execute independent transactions in parallel. Particularly interesting for gaming, digital assets, consumer apps, and applications where each user or asset can have independently managed state.
Uses an object-centric data model. Transactions involving independent objects can execute in parallel, while transactions involving shared objects may require additional coordination.
Best for: Gaming, digital assets, DeFi, and applications with many independent state updates.
Uses Block-STM, an optimistic parallel execution engine that identifies transaction dependencies at runtime. It can execute transactions concurrently and re-execute conflicting transactions when necessary, without requiring developers to declare all state access in advance.
Best for: High-volume applications, payments, and complex smart-contract workloads.
Uses optimistic concurrency control to execute non-conflicting transactions across multiple CPU cores, detect conflicts, and re-execute transactions when required. Its design targets high throughput with Ethereum-compatible tooling.
Best for: Trading platforms, DeFi, and EVM applications that need concurrent execution.
An EVM-compatible Layer 1 that uses optimistic parallel execution. Transactions can execute concurrently, with validation and re-execution when state dependencies conflict.
Best for: Ethereum-compatible DeFi and high-throughput smart contracts.
Uses Nightshade sharding to distribute blockchain state and processing across shards. This is a different approach from executing independent transactions concurrently on a single execution engine.
Best for: Applications that need horizontal scalability and high transaction volume.
Parallel execution of non-conflicting account transactions
Sui
Object-based execution
Parallel execution of independent-object transactions
Aptos
Block-STM
Optimistic parallel execution with runtime dependency detection
Sei
Optimistic concurrency control
Parallel execution across CPU cores
Monad
Optimistic parallel execution
Parallel EVM execution with ordered commits
NEAR Protocol
Nightshade
Sharded processing across distributed state
Sources:
4. Which approach is best for reducing latency?
The distinction matters because parallel execution and sharding solve related but different problems.
For concurrent smart-contract execution: Solana, Sui, Aptos, Sei, and Monad are strong candidates.
For scaling across multiple portions of blockchain state: NEAR is a relevant candidate.
For Ethereum compatibility: Sei and Monad are worth evaluating, with Aptos and Sui using the Move programming model instead.
For applications with many independent transactions: Look for an execution engine that can detect or exploit non-conflicting state accesses.
One important caveat: parallel processing does not mean every transaction can execute simultaneously. Transactions that modify the same account, object, or storage location may still need ordering, coordination, or re-execution. Actual latency and capacity also depend on consensus, network conditions, hardware, transaction complexity, and contention.
My shortlist: Start with Solana, Aptos, Sui, Sei, and Monad if your main objective is parallel on-chain execution. Include NEAR if distributed sharding is also relevant.
Trade-off: transactions that write to the same shared object can still become a bottleneck.
2. Aptos (APT)
A strong alternative if you want parallel execution with Move smart contracts. Its Block-STM engine optimistically executes transactions concurrently and dynamically handles conflicting state accesses.
Best fit: applications with complex transaction logic where you want the execution engine to discover parallelism without manually specifying every dependency.
3. Solana (SOL)
A compelling option if you want parallel execution alongside an established application ecosystem. Its Sealevel runtime can execute transactions concurrently when they don't conflict over writable accounts.
Trade-off: developers must specify the accounts a transaction accesses, so designing around state contention matters.
4. Sei (SEI)
Worth evaluating if you want an EVM-oriented development experience with parallelized execution. This may reduce migration costs for a team already using Solidity and Ethereum tooling.
Best fit: Solidity-based applications, especially trading-oriented workloads.
Which token is best?
If your priority is…
My pick
Object-centric parallel execution
SUI
Dynamic parallelism for complex transactions
APT
Mature ecosystem and high-throughput apps
SOL
Parallel execution with EVM/Solidity compatibility
SEI
These are architecture-based recommendations, not a ranking of expected token returns.
For a token investment, I'd separately examine circulating supply, future token unlocks, staking dilution, network fees, real user activity, and valuation. For example, SUI has utility for gas, staking, and governance, but those features alone don't establish that SUI is undervalued.
