Orbitra Prime
Trading intelligence
Assets that cross the gateway become ordinary core assets. Once listed under the usual rules, they trade in Orbitra Prime through ApexMatch with the same Aegis risk treatment as any other asset.
EVM CapsuleOrbitra L1
Isolated EVM compatibility domain
Ethereum compatibility, contained by design.
EVM Capsule is an isolated compatibility domain at the edge of Orbitra L1. Existing Ethereum bytecode and tooling run inside a metered capsule with its own gas and resource ceilings, and assets reach the core only through a governed, rate-limited gateway. The core execution environment is NexusWASM; the capsule extends developer reach without changing it.
How it moves
A sealed domain with one governed door
Orbitra L1 coreEVM CapsuleGoverned gateway
- Resource ceilings
- Rate limits
- Circuit breaker
- Migration path
The illustration draws the EVM Capsule as an isolated domain beside the Orbitra L1 core, bounded by its own resource ceilings. The only connection between the two is a governed gateway: assets cross it under rate limits, and a circuit breaker can close it without stopping either domain. A migration path leads from the capsule toward NexusWASM.
The problem
Why compatibility belongs at the edge, not the core
A vast body of smart-contract code, reviewed libraries and developer practice is written for the Ethereum Virtual Machine. A new network that ignores it asks every team to start from zero. A network that adopts the EVM as its core inherits its execution model — one blended gas unit, implicit state access and processing organized around a single global order — none of which was designed for parallel, deterministic market state.
Orbitra L1 needs both at once: a core runtime engineered for financial state, and a direct path for teams that already build with Ethereum languages and tools. Merging the two would compromise the first. Ignoring the second would narrow the ecosystem.
EVM Capsule resolves the tension with a boundary. Compatible applications run inside the capsule under familiar rules, the core runtime carries no EVM constraints, and everything that moves between them passes through a gateway with explicit limits, monitoring and circuit breakers.
Operating sequence
How an EVM application meets the core.
The capsule is a place to run existing code, not a shortcut into core state. Every interaction with core assets follows the same governed path.
- 01
Deploy
Existing EVM bytecode is deployed into the capsule with familiar Ethereum tooling. Addresses, calls and events behave as EVM developers expect within the capsule domain.
- 02
Meter
Capsule transactions pay capsule gas under ceilings set independently of the core, so demand inside the capsule is priced and bounded inside the capsule.
- 03
Execute
The capsule runs in its own domain with its own state. A fault inside it cannot write to NexusWASM contracts, market modules or core balances.
- 04
Request
When an application needs a core asset, it submits a transfer request to the gateway. No direct call path leads from capsule code into the core.
- 05
Gate
The gateway checks the request against per-asset and per-route rate limits, circuit-breaker status and bridge monitoring before anything moves.
- 06
Settle
Approved transfers commit on both sides in one transition finalized by QSE. Refused or paused requests leave both domains unchanged.
- 07
Migrate
When a team is ready, components move into NexusWASM one at a time, with the gateway carrying assets between capsule and native versions during the transition.
Architecture
Components of the capsule
The capsule is deliberately simple at its boundary: one domain, one gateway, one set of limits. Complexity stays on the side of the wall where it belongs.
- 01
EVM execution domain
Runs EVM bytecode with Ethereum semantics in a sandboxed domain that keeps its own state, apart from core state, and exposes familiar interfaces for deployment, calls and events.
- 02
Independent resource ceilings
Capsule gas, execution and storage growth are bounded by ceilings set separately from the core. Congestion inside the capsule is priced and absorbed inside the capsule.
- 03
Governed asset gateway
The single path for assets moving between capsule and core. Transfers are rate-limited per asset and per route, and every movement leaves a matching record on both sides.
- 04
Circuit breakers
Automatic triggers pause the whole gateway or a single route when flows exceed limits, reconciliation fails or monitoring detects an anomaly.
- 05
Monitored bridges
Capsule-side representations of core assets are reconciled continuously against the core holdings that back them. A mismatch pauses the affected route instead of letting it grow.
- 06
Migration path
Patterns and tooling for moving an application into NexusWASM progressively, from a single performance-critical path to the whole codebase.
Security and failure control
Containment before convenience.
The capsule is designed on the assumption that some EVM applications will fail — through reentrancy defects, faulty upgrades or compromised keys. The boundary decides how far such a failure can reach.
- Domain isolationCapsule code cannot call NexusWASM contracts or market modules directly and cannot write core state. Its only way out is a gateway request.
- Rate-limited flowsPer-asset and per-route limits bound how much value can cross the gateway within a window, capping what any single exploit can extract.
- Automatic circuit breakersLimit breaches, reconciliation gaps or monitoring alerts pause the affected route without halting the core or other routes.
- Backed representationsThe gateway issues a capsule-side representation only against a core asset it holds, and never issues more than it can account for.
- Resource containmentIndependent gas and resource ceilings stop a surge of capsule activity from consuming execution capacity that markets depend on.
- Core independenceThe core runtime carries no EVM constraints. Upgrades to NexusWASM, VectorLanes or QSE never wait on EVM compatibility, and capsule changes never alter core semantics.
Across the three systems
The capsule’s place in the system
Orbitra L1
Settlement and compute
EVM Capsule is a bounded compatibility domain of Orbitra L1 that runs beside the NexusWASM runtime — never beneath it or in its place. Its transitions are finalized by QSE together with the rest of the network.
Orbitra Realm
Applications and commerce
Teams with existing Ethereum applications can enter Orbitra Realm quickly, reach users and liquidity through the gateway and move performance-critical components into NexusWASM when they choose. Assets from other chains arrive through GateMesh; the capsule gateway connects only capsule and core.
Value
What isolation makes possible
- Traders and users
- Familiar applications with visible limits. Gateway caps, breaker status and the backing of capsule-side assets can be inspected, so you can see how an application connects to core assets.
- Institutions
- A contained risk surface. Compatibility workloads are separated from market infrastructure by explicit ceilings, rate limits and pause controls that can be assessed on their own terms.
- Developers
- Deploy existing bytecode with the tools you know, then migrate component by component when native performance matters. The migration path is documented in the developer documentation.
Specifications
Specifications
- Role
- Isolated compatibility domain; never the core execution environment
- Compatibility
- Ethereum bytecode and tooling within the capsule domain
- Resource model
- Independent gas and resource ceilings, separate from core pricing
- State
- Capsule state held apart from core state; no direct writes across the boundary
- Asset movement
- One governed gateway with per-asset and per-route rate limits
- Protection
- Automatic circuit breakers, monitored bridges and continuous reconciliation
- Finality
- Capsule transitions finalized by QSE with the rest of Orbitra L1
- Migration
- Progressive path from capsule contracts to NexusWASM
Terminology
Terminology
- Compatibility domain
- A bounded environment that runs another platform’s code under its own rules and limits, separate from the core runtime.
- Governed gateway
- The only channel between capsule and core, enforcing rate limits, breaker status and reconciliation on every transfer.
- Rate limit
- A cap on the value or number of transfers along a route within a time window.
- Circuit breaker
- An automatic control that pauses a route when predefined conditions — limit breaches, reconciliation gaps, anomalies — are met.
- Progressive migration
- Moving an application from the capsule into NexusWASM one component at a time rather than in a single cutover.