The Throughput Problem in Smart Contract Chains
Every general-purpose smart contract chain faces the same fundamental tension: correctness demands that state transitions be deterministic and ordered, but ordering transactions serially means only one CPU core does useful work at any given moment. Ethereum's EVM processes roughly 15 transactions per second on mainnet. That ceiling is not primarily a networking constraint. It is an execution constraint rooted in the design of the EVM itself: each transaction is applied to a global state trie sequentially, one after another, and no transaction can begin until the previous one has committed its changes.
Solana takes a different approach, advertising peak throughput above 65,000 TPS under ideal conditions. But Solana achieves this largely through account-based access lists that developers must declare manually, combined with a forgiving validator architecture that occasionally sacrifices liveness. When the scheduler cannot statically determine that two transactions are independent, it falls back to serial execution. Real-world sustained throughput on Solana under diverse workloads is significantly lower than the headline figure, and the architecture places a substantial burden on application developers to reason about concurrency themselves.
Qlorix takes the position that developers should not have to think about parallelism at all. The execution engine handles it, guided by compile-time information extracted from the Photon smart contract language. The mechanism that makes this possible is Block-STM.
What Block-STM Is
Block-STM stands for Block-level Software Transactional Memory. The algorithm was originally developed and published by Aptos Labs, drawing on decades of research in software transactional memory systems from academic computer science. The core idea is optimistic concurrency control: instead of acquiring locks before executing a transaction, you execute all transactions speculatively in parallel, then check afterward whether any two transactions accessed the same state in a conflicting way. If they did, you re-execute only the conflicting ones.
This approach works well for blockchains because real-world transaction sets have sparse state overlap. A token transfer between two accounts, a lending position update for a third account, and an NFT mint for a fourth account touch entirely disjoint pieces of state. There is no reason those three operations should wait on each other. Block-STM lets them run simultaneously. Qlorix builds on the original Aptos design with two major additions: the EffectManifest system from the Photon language, and a multi-version data store tuned for the QLVM's memory model. Together they push effective throughput well past what the original Block-STM design achieved on the Aptos network.
Wave-Based Scheduling
Qlorix's execution engine organizes each block into a series of execution waves. A wave is a batch of transactions dispatched simultaneously to a pool of worker threads, one transaction per thread. The wave scheduler uses a stride-based assignment as its baseline: transactions at positions 0, W, 2W, 3W go to wave 0; positions 1, W+1, 2W+1, 3W+1 go to wave 1; and so on, where W is the number of worker threads. This interleaving minimizes the probability that two transactions in the same wave are sequential in the block and therefore likely to conflict.
Before waves are assigned, the scheduler runs a pre-analysis pass using EffectManifest data. If two transactions in the same tentative wave are predicted to write to the same storage key, the scheduler promotes one of them to the next wave proactively. This converts many potential aborts into scheduled serializations, which are cheaper because they avoid redundant execution entirely.
EffectManifest: Static Conflict Prediction
The EffectManifest is Qlorix's most significant departure from the original Block-STM algorithm. In Photon, every public contract function must declare its complete read and write sets as part of its signature. These sets are expressed in terms of named storage slots, which can be parameterized by function arguments.
The Photon compiler statically verifies that every storage access in the function body falls within the declared manifest. If a function tries to write to a slot not listed in its writes set, the build fails. This guarantee means the QLVM can trust the manifest completely, without runtime verification of each individual storage operation. The scheduler receives manifest data as part of the signed transaction payload and can perform full conflict graphs before a single instruction executes.
For contracts with partitioned state, such as an AMM that tracks per-pool liquidity independently, the manifest system enables the scheduler to assign each pool's transactions to a dedicated thread bucket. Those transactions never enter the conflict-detection pipeline at all, because the scheduler can prove statically that they access disjoint storage regions.
The Multi-Version Data Store
Parallel execution requires that each transaction see a consistent view of state, even while other transactions are simultaneously modifying it. Qlorix solves this with a multi-version data store (MVDS), an in-memory structure that maintains multiple versions of every storage slot simultaneously, indexed by transaction position within the block.
When a transaction at position i reads storage slot K, the MVDS returns the latest version of K with a write index less than i. If no prior transaction has written K in this block, the MVDS falls through to the persistent trie and returns the committed value. When a transaction writes to K, it creates a new version entry tagged with index i, leaving all prior versions intact. This means every transaction reads a logically consistent snapshot, corresponding to the state that would exist if all transactions before it had already committed, without any of them actually having to wait.
The MVDS is implemented as a lock-free concurrent skip list, with per-slot version chains stored as append-only linked lists. Reader threads traverse the version chain in reverse order and return the first entry with an index below their own. Writer threads append to the chain with a single compare-and-swap operation. Lock contention is essentially eliminated: threads block only in the rare case where two writers race to append to the same slot at the same instant, which the pre-analysis wave scheduler has already minimized.
Validation and Abort
After each execution wave completes, the scheduler runs a validation pass over every transaction that executed in that wave. Validation checks each transaction's recorded read set against the finalized write sets of all transactions with lower indices. If transaction i read version V of slot K, and some transaction j with j less than i wrote a newer version of K after i began, then i read stale data and its result is invalid. The transaction is marked for re-execution and re-queued into the next wave, this time with the correct version of K available in the MVDS.
The abort rate is the dominant factor in Block-STM efficiency. In pure optimistic systems without pre-analysis, abort rates on DeFi-heavy workloads can reach 15 to 20 percent, because many users interact with the same liquidity pools simultaneously. Qlorix's EffectManifest pre-analysis reduces this dramatically. On benchmarked DeFi workloads with a realistic mix of swaps, transfers, and lending operations, Qlorix's abort rate is consistently below 3 percent. More than 97 percent of transactions complete in their first execution pass, meaning the overhead of re-execution is negligible at the system level. The small number of re-executed transactions typically complete in wave 2, because the scheduler can precisely identify and serialize only the conflicting subset.
BFT Finality Integration
Block-STM produces a speculative execution result: a fully computed post-block state root, generated from parallel execution with validated, conflict-free output. This result is deterministic. Every validator that receives the same block and runs Block-STM will produce the same post-state root, because the algorithm is defined to produce the same output as serial execution in transaction-index order, just faster.
Qlorix's consensus layer is a BFT Proof-of-Stake protocol requiring a supermajority of two-thirds plus one validators to sign a block before it achieves finality. The key design point is that execution and consensus run in parallel pipelines. While validators are exchanging pre-commit and commit messages for block N, the execution engine is already processing block N plus one. By the time the BFT quorum is collected for block N, its post-state root is already available and signed. There is no execution-after-consensus delay. This pipeline architecture, combined with a 400-millisecond target block time, enables Qlorix to achieve single-slot finality with end-to-end latency below one second under normal network conditions.
Key performance figure: Under sustained load on the Qlorix testnet, Block-STM with EffectManifest pre-analysis delivered 52,400 TPS at a 97.1 percent first-pass execution rate, with a measured abort rate of 2.9 percent on a mixed DeFi workload. Block time held at 398 milliseconds average, and BFT finality was confirmed in under 800 milliseconds end to end. No sharding, no rollup layers, no off-chain computation.
What This Means for DApp Developers
From a developer's perspective, Block-STM is almost entirely invisible. You write a Photon contract the same way you would write any sequential program: declare what you read, declare what you write, implement the logic. The Photon compiler enforces the manifest statically, so if your declarations are wrong the build fails immediately rather than causing a runtime abort on mainnet. Once deployed, the runtime handles all parallelism automatically. Your contract does not need to be aware of concurrency, use locks, or implement any sharding logic.
Qlorix also supports EVM-compatible Solidity contracts through the QLVM's EVM translation layer. For Solidity contracts, the manifest is inferred heuristically from bytecode analysis rather than declared explicitly, and the abort rate is slightly higher. Developers who want maximum throughput and minimum latency are encouraged to use Photon natively, but existing Solidity DApps can be deployed on Qlorix with no code changes and will still benefit significantly from parallel execution on transactions with non-overlapping state.
The practical consequence for DApp builders is profound. A decentralized exchange, a lending protocol, an NFT marketplace, and an on-chain game engine can all run simultaneously on the Qlorix base layer at Visa-scale throughput, with cryptographic finality, full validator decentralization, and quantum-safe signature schemes. No trusted sequencer is required. No off-chain data availability bridge introduces liveness risk. The throughput is native, in-protocol, and available to every application on the network from day one.