Orbitra Prime
Trading intelligence
An order in one Orbitra Prime market does not queue behind unrelated activity in another, and the index stream feeds Prime’s positions, books and history directly from finalized state.
VectorLanesOrbitra L1
Parallel deterministic execution
Parallel lanes. One deterministic answer.
VectorLanes is the execution layer of Orbitra L1. Transactions that touch independent state run side by side across 256+ parallel lanes, a conflict-aware deterministic scheduler orders only what genuinely conflicts, and QSE converges every lane into one globally ordered, finalized truth. It is the execution design behind the 1,000,000 TPS full-capacity architecture.
How it moves
Hundreds of lanes, one finality beacon
Independent lanesFinality beacon
- 256+
- Parallel lanes
- Batched
- Signature checks
- Local
- State access
- Streamed
- Index output
Hundreds of independent execution lanes move in parallel across the field, pass through validation rings and converge on a single finality beacon. The parallel lanes show independent state executing at the same time; the beacon represents the QSE certificate that joins every lane into one ordered, final state.
The problem
Why sequential chains leave capacity idle
Most blockchains execute transactions one after another, even when they have nothing in common. A payment in one application waits behind a trade in another market and a game move in a third, while the processor cores that could run them together sit idle.
Naive parallelism is worse than none for a financial ledger. If validators run threads in whatever order the hardware allows, two honest machines can reach different results, and a market cannot settle on a state that depends on timing.
VectorLanes runs in parallel only what is provably independent and orders everything else canonically. The outcome is identical to executing the whole batch one transaction at a time in canonical order, so every validator reaches the same state.
Operating sequence
From ordered batch to final state
Every batch follows the same path. Only the middle of the path runs in parallel; its entry and its exit are canonical.
- 01
Verify
Signatures are checked in batches at ingress, before scheduling, so lanes spend their time executing rather than verifying.
- 02
Declare
Each transaction carries its read and write sets: the accounts, order books and contract storage it will touch.
- 03
Schedule
The deterministic scheduler builds a conflict graph over the ordered batch. Independent transactions go to separate lanes; conflicting ones share a lane in canonical order.
- 04
Execute
Lanes run in parallel against lane-local state and produce state deltas without cross-lane locks.
- 05
Merge
Deltas combine in canonical order into one state commitment — the same root a serial execution of the batch would produce.
- 06
Finalize
QSE validators re-derive the commitment and certify it. Every lane becomes part of one globally ordered, final state.
- 07
Stream
Finalized changes stream to indexers, Orbitra Prime and APIs as ordered output, so consumers follow state instead of polling for it.
Architecture
Components of the execution layer
VectorLanes sits between the market services above it and QSE consensus below. Each component removes one source of serialization or one source of nondeterminism.
- 01
Batch verifier
Verifies signatures in batches as transactions arrive, taking the most expensive per-transaction check off the execution path.
- 02
Access-set model
Native modules and NexusWASM contracts expose their state access explicitly. Parallel-friendly state access is what makes conflict-aware scheduling possible.
- 03
Deterministic scheduler
Derives lane assignments from the ordered batch and its conflict graph alone. Timing, thread count and hardware never change the outcome.
- 04
Lane executors
Run compact deterministic code against lane-local state, with hardware-aware validation that keeps cores busy without shared locks.
- 05
Canonical merge
Combines lane deltas in canonical order and computes the state commitment that QSE validators certify.
- 06
Index streamer
Emits finalized state changes as ordered streams for Orbitra Prime, explorers, analytics and institutional reconciliation.
Security and failure control
Determinism under parallel load
Parallel execution belongs in a financial ledger only if it can never change an outcome. These properties make that claim checkable.
- Serial equivalenceHowever many lanes run, the committed state is the one a sequential run in canonical order would produce. Any validator can confirm it by replay.
- Declared-access enforcementA transaction that reads or writes outside its declared sets fails deterministically. Hidden dependencies cannot corrupt a neighboring lane.
- Contention isolationWhen many transactions target the same state — a busy market or a popular contract — they serialize on one lane. Unrelated lanes continue unaffected.
- Metered resourcesCompute and storage are priced explicitly, so no workload can monopolize lanes without paying for the capacity it consumes.
- Quorum-checked commitmentsA state commitment becomes final only after a QSE quorum has independently reproduced it. A divergent executor is detected before finality, not after.
Across the three systems
Parallel execution across the three systems
Orbitra L1
Settlement and compute
VectorLanes is the execution layer of Orbitra L1. It runs ApexMatch transitions and NexusWASM contracts in parallel and hands QSE one ordered commitment to certify.
Orbitra Realm
Applications and commerce
Payments, tokenization, games and data applications in Orbitra Realm run alongside markets instead of competing with them for a single execution thread. Contracts that declare narrow state access gain the most parallelism, while the EVM Capsule runs in its own isolated domain with independent limits.
Value
What parallel determinism delivers
- Traders and users
- Your order does not wait behind activity it has nothing to do with, and the state you see is the finalized state every validator agrees on.
- Institutions
- Capacity grows with the number of independent markets and applications, while every result remains reproducible for audit and reconciliation.
- Developers
- Design state for parallelism and the scheduler rewards it. Deterministic semantics leave no race conditions to reason about: conflicts are ordered, never raced.
Specifications
Specifications
- Execution model
- Parallel lanes over independent state
- Lane configuration
- 256+ parallel lanes (engineered configuration)
- Scheduling
- Conflict-aware and deterministic, derived from declared read and write sets
- Equivalence
- Identical to serial execution of the batch in canonical order
- Signatures
- Batched verification before scheduling
- State access
- Lane-local, with deterministic failure on undeclared access
- Output
- Streamed index output from finalized state
- Finality
- One global state commitment certified by a QSE quorum
- Capacity
- 1,000,000 TPS full-capacity architecture
1,000,000 transactions per second represents the engineered aggregate full-capacity architecture of ORBITRA ONE™ and is intended for validation under defined benchmark conditions.
Terminology
Terminology
- Lane
- An execution path that processes transactions touching state no other lane touches in the same batch.
- Read and write sets
- The state a transaction declares it will read and modify. The scheduler uses them to detect conflicts before execution.
- Conflict graph
- A map of which transactions in a batch touch overlapping state and therefore must be ordered.
- Serial equivalence
- The correctness criterion VectorLanes shares with serializable databases: parallel execution must yield exactly the state of a sequential run over the same ordered batch.
- State commitment
- A cryptographic digest of the full state after a batch, which QSE validators reproduce and certify.