A chain that can only tell a throughput story gets overtaken the moment another chain shows up with a bigger number. What actually decides how far a chain can go is which position in the landscape it chooses to occupy, and whether that position holds up under real load. Earlier pieces in this series already laid the groundwork: where the ceiling of single-threaded EVM execution sits, what parallel execution, Rollups, and sharding each solve on the scaling roadmap, the trade-offs between the deterministic, optimistic, and object-model approaches to parallelism, and how optimistic concurrency control — a method proven over decades in the database world — made its way into the blockchain execution layer. This piece brings those frameworks together and applies them to one specific project: which coordinates Bitroot has chosen on that map, and why.
What Bitroot is, in one sentence
Bitroot is a high-performance Layer 1 built on optimistic parallel EVM, aimed at payment settlement, composable DeFi, and large-scale on-chain coordination. Every word in that sentence carries a trade-off. Choosing Layer 1 over Rollup means giving up the shortcut of inheriting Ethereum's security and building its own consensus and validator set from scratch. Choosing optimistic parallelism over deterministic parallelism means shifting the burden of dependency analysis from the developer onto the runtime system. Choosing full EVM compatibility over a new object model or account model means giving up some of the theoretical ceiling on parallelism in exchange for letting existing Ethereum contracts and tooling migrate over directly.
This trade-off isn't unique to Bitroot. Among other projects pursuing the same optimistic-parallel-plus-EVM-compatible path, Monad positions itself around giving developers who already know the Ethereum toolchain a speed experience close to Solana's, with an architecture built around MonadBFT (which decouples consensus from execution), deferred execution, and its own MonadDb database. Sei's 2026 roadmap commits explicitly to becoming a pure EVM chain, shifting its narrative from a trading-specific chain to a settlement layer for automated financial agents, emphasizing sub-second finality and a parallel EVM refined over more than two years. Both cases point to the same thing: in the high-performance L1 category, the window for winning purely on raw TPS numbers is closing, and the term that keeps coming up instead is settlement layer. Bitroot's chosen position sits in that same direction, but its technical path combines the pieces differently.
The technical combination: three pieces, none optional
Bitroot's architecture isn't a pile of point solutions — it's the result of co-designing consensus, execution, and state as three coordinated layers, which is exactly what sets it apart from designs that only optimize one layer.
The consensus layer runs Pipeline BFT. Traditional BFT-style consensus advances strictly in series through four phases — propose, pre-vote, pre-commit, commit — so a block can't be confirmed until the previous block has finished every phase, and the messaging complexity between validators grows roughly quadratically with the size of the validator set. Pipeline BFT turns those four phases into a pipeline, letting phases from different block heights overlap, while using VRF to rotate the block leader (reducing single-point risk) and BLS12-381 signature aggregation to collapse validator signatures into a verification cost that's close to constant. The direct consequence: growing the validator set no longer means the consensus layer's communication cost rises linearly, let alone quadratically — a key enabler for the decentralization-versus-performance tension discussed later (see the ninth piece in this series).
The execution layer is the optimistic parallel EVM engine, built around dynamic transaction grouping plus three-stage conflict detection. Transactions within a block first have their dependencies mapped from read/write sets, so conflict-free transactions can be grouped into the same batch and run in parallel. Conflict detection is split into three stages — static dependency analysis before execution, version-conflict monitoring during execution, and state-root consistency checks after execution — rather than the single validation pass that early, naive OCC designs relied on once execution finished. The payoff from this layered detection is explored further in Series B; in short, it catches conflicts earlier and narrows the blast radius of re-execution, instead of throwing out an entire batch every time a single conflict shows up.
The state layer is sharding. Accounts or storage slots are partitioned by rule, with parallel execution inside each shard and an explicit cross-shard communication protocol between shards; hot data is served from a tiered cache to cut read latency, and larger objects are stored off-chain with only their hash kept on-chain, easing the storage burden on full nodes. Sharding addresses the bottleneck that remains even after execution has been parallelized: the capacity ceiling of single-machine memory and a single state tree.
The relationship between the three layers is decoupling, not splitting apart. The consensus layer is responsible for quickly finalizing transaction order, while the execution layer pushes the actual state transitions forward in parallel in the background — so the next block's consensus doesn't have to wait for every transaction in the current block to finish executing, avoiding the wasted serial time of "queuing for execution." That's also why understanding Bitroot means looking at the execution engine and the consensus protocol together — the coordinated design across all three is the real answer.
| Layer | Core mechanism | Problem it solves |
|---|---|---|
| Consensus | Pipeline BFT + VRF leader rotation + BLS signature aggregation | The serial phases and quadratic communication overhead of traditional BFT |
| Execution | Optimistic parallelism + dynamic grouping + three-stage conflict detection | The throughput ceiling of single-threaded EVM execution |
| State | Account/slot sharding + tiered caching + off-chain large objects | The single-state-tree and full-node storage bottleneck |
Why not the object model, and why not give up EVM compatibility
As covered in the third piece of Series A, the design space for parallel execution splits roughly into three paths: the deterministic, declarative model represented by Solana Sealevel; the object model represented by Sui; and optimistic concurrency control. Bitroot sits on the third path, and insists on full bytecode-level EVM compatibility — a choice rooted in a judgment about the cost of the developer ecosystem.
Object models and declarative account models do have a higher theoretical ceiling on parallelism, because dependencies are either explicitly declared or naturally isolated at the moment a transaction is submitted, so the system doesn't need to guess and verify after the fact. The cost is that developers have to rethink their application structure around a new programming paradigm: Sui uses the Move language to model assets as owned or shared objects, and Solana requires transactions to declare upfront every account they will read or write. These designs are friendly to new applications built natively for them, but offer existing Ethereum contracts almost no migration path — porting a DeFi protocol or NFT marketplace over amounts to rewriting it essentially from scratch.
Ethereum's ecosystem — nearly a decade's worth of accumulated contracts, audit tooling, developer frameworks, and user habits — is an asset no new chain can easily replicate. Bitroot's judgment is that it's better to keep the complexity inside the protocol than to ask developers to rewrite code in exchange for a higher parallelism ceiling: through finer-grained conflict detection and dynamic grouping, it aims to get as close as possible to the throughput parallel execution should deliver, while leaving Solidity, Foundry, and Hardhat exactly as they are. This lines up with what the Monad team has said publicly — using software engineering to make the EVM itself run faster, rather than routing around the EVM to design a new execution environment. It's a classic case of pushing complexity into the runtime rather than onto development time, a trade-off the fourth piece of Series A already surfaced when discussing OCC.
The settlement-layer mindset: a positioning that matters more than throughput
Looking only at the numbers, more than one project in the optimistic-parallel-EVM category is already touting high TPS. What actually separates them is what that throughput ends up serving. Bitroot positions itself as infrastructure for payment settlement, composable DeFi, and large-scale on-chain coordination — not another chain driven by token narrative — and that positioning decides what gets prioritized in the protocol design.
Payment and settlement scenarios demand far more certainty around confirmation latency and finality than they demand a high peak-TPS number. However high a chain's theoretical peak throughput is, if confirmation latency is volatile and execution congestion shows up easily under load, it can't support real merchant settlement or high-frequency clearing. That's exactly why, in Bitroot's architecture, decoupling consensus from execution and running them as a pipeline matters not just for raising throughput but for keeping confirmation latency within a predictable range. Based on figures from the project's testnet, single-shard throughput reaches roughly 3,200 to 35,200 TPS (the exact number varies by test batch, depending on the hardware and load configuration used for that run), scaling linearly across multiple shards, with confirmation latency around 1.2 seconds; for comparison, Ethereum mainnet runs at roughly 15 TPS with confirmation times on the order of ten-plus seconds. All of these figures are testnet-condition results and do not represent stable mainnet production performance — a later piece in Series F looks specifically at how to correctly interpret and disclose benchmark numbers like these.
Composable DeFi is another test. DeFi protocols call into each other heavily, and a single transaction can touch the state of multiple contracts at once — exactly the scenario where optimistic parallel execution is most prone to conflicts and where hot spots most easily drag down throughput (the 25th piece of Series B is dedicated to dissecting high-conflict contracts like AMMs, lending protocols, and NFT minting). Bitroot chooses to take this scenario on directly rather than avoid it, which is, in a sense, an unavoidable consequence of its settlement-layer positioning: a chain that can only handle low-conflict transfers and degrades into serial execution the moment it hits a complex contract doesn't deserve to be called real high-performance settlement infrastructure.
Large-scale on-chain coordination points to a longer-term direction — DAO governance, multi-party on-chain workflows — where the demands on state scale and cross-shard coordination climb as the number of participants increases; state sharding and the cross-shard communication protocol (covered in Series D) play the key role here.
A judgment still being tested
To be clear: this entire positioning and technical combination is still being validated on testnet. Community-facing figures — team size, number of test users, number of validator nodes — will change over time, and the current numbers should be read as whatever the project has most recently disclosed. Whether the technical path is actually correct can only be settled by real load after mainnet launch, including whether the consensus and execution layers can hold stable latency under high concurrency and high conflict, and whether validator decentralization can be preserved without being sacrificed for performance — the tension the ninth piece in this series takes on directly.
Put back on the full scaling map, Bitroot isn't inventing a wholly new paradigm. It's taking the optimistic-parallel path already proven viable by projects like Aptos, Monad, and Sei, and using a specific set of engineering choices — decoupled consensus and execution, three-stage conflict detection, state sharding — to close in on a concrete goal: a chain that keeps full EVM compatibility while holding up under payment-settlement and high-frequency DeFi load. Whether that goal is reachable is what the next pieces will take apart, starting with what EVM compatibility actually means, one layer at a time.
Further Reading
- Previous: "Optimistic Concurrency Control for Beginners: A Database Lens on Blockchain Execution"
- Next: "What EVM Compatibility Actually Means: Bytecode, Precompiles, and Tooling"
- Related: "Bitroot's Parallelised EVM Technology Explained: Optimistic Parallelisation", "A Deep Dive into Bitroot's Multi-Engine Parallel Execution Design: Breaking the EVM Performance Bottleneck", "In-Depth Analysis of Bitroot: Pipeline BFT and the Synergy Architecture of Multi-Engine Parallel Execution", and "A Deep Dive into Bitroot's Parallelized EVM State Sharding" (not yet published)