Orbitra Prime
Trading intelligence
When Orbitra Prime marks a fill, transfer or liquidation as settled, a QSE certificate exists for it. Traders see a single state — final — instead of a confirmation countdown.
QSEOrbitra L1
Quorum-Staked Execution
Finality by quorum, not by waiting.
QSE — Quorum-Staked Execution — is the consensus protocol of Orbitra L1. It is a HotStuff-family BFT composition: stake provides economic security, authority assigns proposer and committee duties, and verified work measures availability, validation and service. A state transition is final when the configured Byzantine quorum signs it, not after a count of confirmations.
How it moves
Three forces, one certificate
- StakeEconomic security and slashing exposure
- AuthorityProposer and committee duties
- WorkVerified availability, validation and service
Validator votes
Quorum certificate
Finalized state
7 / 10
Three forces — stake, authority and verified work — flow into a ring of validators. The validators cast signed votes on one proposed state transition. When the votes reach the configured Byzantine quorum, they combine into a quorum certificate, and the certified state is marked final.
The problem
Why markets cannot settle on probability
On longest-chain networks, finality is a probability that grows with time. A payment is “probably final” after some number of confirmations, and a deep enough reorganization can still reverse it. Venues compensate with confirmation delays, and every delay is a window in which collateral, positions and deliveries are uncertain.
For a market, that ambiguity compounds. A fill that can be reorganized away can take a liquidation, a margin release and a withdrawal with it. Settlement needs one clear moment after which the state does not change.
Security that rests on burning computation, or on capital alone, leaves a second gap: neither measures whether operators actually serve the network. QSE pairs deterministic BFT finality with accountability for the work validators perform. It is not proof-of-work mining — verified work means measured availability, validation and service, not hash puzzles.
Operating sequence
From proposal to certificate
Consensus advances in views. In each view one scheduled proposer leads, validators check the proposal independently, and the quorum decides.
- 01
Select
Stake determines which validators form the security set for an epoch. The authority schedule, informed by each validator’s verified-work record, assigns proposer and committee duties.
- 02
Propose
The scheduled proposer assembles the ordered batch of transitions executed by VectorLanes and proposes it together with the resulting state commitment.
- 03
Validate
Validators re-execute the batch deterministically and check that they reach the same state root. A proposal that does not reproduce receives no vote.
- 04
Vote
Each validator signs the transition it verified. Votes flow to the proposer and are aggregated into one compact certificate instead of being broadcast to every peer.
- 05
Certify
When signatures reach the configured Byzantine quorum, they form the finality certificate. The transition is final, with no probabilistic confirmation ladder to climb.
- 06
Account
Availability, validation and service are measured and recorded as verified work. Provable misbehavior, such as signing two conflicting transitions, becomes slashing evidence.
Architecture
Components of the protocol
QSE composes well-understood BFT machinery with two additions: explicit authority and measured service. Each component has a single responsibility.
- 01
Stake registry
Records bonded stake and determines the security set for each epoch. Bonded stake is the collateral behind every signature a validator produces.
- 02
Authority schedule
Delegates proposer and committee duties across the security set. Authority decides who leads a view; it never decides what is final.
- 03
Work ledger
Measures verified work: availability when a duty falls due, correct and timely validation, and service to the network. The record shapes future duties and rewards.
- 04
Pacemaker
Keeps validators in step across views. If a proposer fails to deliver a valid proposal in time, a view change hands leadership to the next scheduled proposer.
- 05
Vote aggregation
Collects validator signatures into compact certificates with linear communication per view. Signature suites are versioned through Q-Switch.
- 06
Finality certificate
The portable proof of finality. Light clients, GateMesh and reconciliation systems verify a certificate instead of trusting any single node.
- 07
Evidence and slashing
Verifies proofs of misbehavior — equivocation or signing an invalid transition — and slashes the responsible stake.
Security and failure control
Safety, liveness and accountability
BFT protocols are judged by the properties they hold under a stated fault model. QSE’s properties hold while Byzantine validators stay below the threshold the configured quorum is designed to tolerate.
- Quorum intersectionUnder the stated fault model, any two quorums overlap in at least one honest validator, and an honest validator never signs two conflicting transitions. Two conflicting states therefore cannot both be certified.
- No reorganization after finalityA certified transition is not replaced under the stated fault model. Applications need no rollback logic for finalized state.
- Liveness through view changeA crashed, slow or malicious proposer can delay a view but cannot halt the network. The pacemaker rotates leadership and consensus resumes under the next proposer.
- Slashing for provable faultsSigning two conflicting transitions produces self-contained evidence: two valid signatures that cannot both be honest. The responsible stake is slashed.
- Protocol hygieneFormal specifications, client diversity and versioned signature suites reduce the chance that one implementation bug or one cryptographic weakness becomes a network failure.
Across the three systems
What finality means in each system
Orbitra L1
Settlement and compute
QSE is the consensus layer of Orbitra L1. It certifies the state commitments produced by VectorLanes, so an ApexMatch fill, its margin effect and its settlement become final under one certificate.
Orbitra Realm
Applications and commerce
Payments, tokenized-asset transfers and application state in Orbitra Realm inherit the same deterministic finality, and cross-chain routes present certificates as proof. Operators interested in running validator infrastructure can find participation details on the validators page.
Value
Why a clear finality signal matters
- Traders and users
- A trade or payment is either final or not yet final. There is no ambiguous middle state to wait out.
- Institutions
- Settlement finality maps directly onto internal settlement and collateral policies, and every certificate is verifiable evidence for reconciliation and supervisory review.
- Developers
- Build on one finality signal. Light clients verify certificates instead of trusting a node, and finalized state needs no reorganization handling.
Specifications
Specifications
- Protocol family
- HotStuff-family Byzantine fault-tolerant composition; not proof-of-work mining
- Security inputs
- Stake (economic security, slashing exposure), authority (proposer and committee duties), verified work (availability, validation, service)
- Finality rule
- The configured Byzantine quorum signs the same state transition
- Finality
- Deterministic BFT finality, sub-second finality class; no reorganization after finality under the stated fault model
- Leadership
- Scheduled proposer per view; view change on proposer failure
- Communication
- Votes aggregated into compact certificates
- Accountability
- Slashing for equivocation and other provable misbehavior
- Cryptography
- Versioned signature suites through Q-Switch
- Capacity
- Finalizes the 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
- Byzantine fault
- Any arbitrary failure of a validator, from a crash or delay to deliberately malicious behavior.
- Finality certificate
- The quorum certificate that proves a transition final: validator signatures on one state transition, aggregated until they reach the configured Byzantine quorum.
- Equivocation
- Signing two conflicting messages for the same step of the protocol. It is provable and slashable.
- View change
- The procedure that replaces a failed or slow proposer so that consensus can continue.
- Verified work
- Measured availability, validation and service by a validator. It shapes duties and rewards and involves no hash computation.
- Fault model
- The stated assumptions — how many validators may be Byzantine and how the network behaves — under which safety and liveness hold.