Orbitra Prime
Trading intelligence
When a strategy, vault or structured workflow needs onchain logic, it runs as a NexusWASM contract and trades through the same ApexMatch and Aegis paths as an order placed in Orbitra Prime.
NexusWASMOrbitra L1
Primary smart-contract environment
Every contract declares what it can touch.
NexusWASM is the primary smart-contract environment of Orbitra L1. Contracts compile from Rust, C/C++ and other modern toolchains to WebAssembly, run in a deterministic sandbox and reach assets, state and market modules only through the capabilities they are granted. Compute and storage are priced explicitly, and declared state access lets VectorLanes run unrelated contracts side by side.
How it moves
Inside the metered sandbox
Contract
Capabilities
Metered compute
Metered storage
The illustration shows a NexusWASM contract sealed inside a sandbox. Around it sit only the capabilities it declared, native market modules among them; nothing else is reachable. Two meters track compute and storage separately as the call runs, and the contract’s declared state access passes to the scheduler, which runs it in parallel with unrelated work.
The problem
Why a market-native chain needs its own contract runtime
In many contract environments, every contract holds ambient authority. It can call any other contract, move any asset it controls and touch state it never declared. That model is easy to start with and hard to secure: one unexpected call path can turn a small defect into a drained treasury, and reviewing a single contract means reasoning about everything it might reach.
Openness of that kind also limits performance. A runtime that cannot know in advance which state a transaction will touch must run transactions one after another, or execute speculatively and roll back on conflict. Pricing often folds computation, storage and long-term state growth into one abstract unit, so the lasting cost of state is poorly reflected in what a transaction pays.
NexusWASM starts from the opposite assumptions. Authority is granted, not ambient. State access is declared, not discovered. Compute and storage are metered and priced separately. Applications can therefore call real market infrastructure — ApexMatch order books, Aegis risk checks, Prism prices — without inheriting the risks of an open-ended execution model.
Operating sequence
From source code to certified state.
Every contract — a payment router, an asset registry, an agent treasury — follows the same path from compiler to finality.
- 01
Build
Rust, C/C++ or another language that targets WebAssembly compiles against NexusSDK interfaces, producing the module and a manifest of the capabilities it requests.
- 02
Validate
Before a module can run, the network checks it: only deterministic instructions are accepted, every import must match a declared capability and resource limits are recorded against the code hash.
- 03
Grant
Each requested capability — hold an asset, call a market module, read a price feed, invoke another contract — is bound to the contract’s address. Anything not granted simply does not exist for the contract.
- 04
Declare
Every transaction lists the state it will read and write. The deterministic scheduler uses these sets to place non-conflicting transactions on parallel lanes.
- 05
Execute
The module runs in a metered sandbox. Compute is charged as instructions execute and storage as state is written and retained; any access outside the declared sets aborts the call and reverts its effects.
- 06
Finalize
Results commit with the other transitions of the block and become final when a QSE quorum certifies them.
Architecture
Components of the runtime
NexusWASM separates what a contract computes from what it is allowed to reach.
- 01
Deterministic engine
Executes WebAssembly under rules that give every validator the same result. Anything that could differ between machines — clocks, randomness, host-specific numeric behavior — is excluded or supplied by the protocol as a deterministic input.
- 02
Capability host
The only bridge between a contract and the rest of the network. Host functions for assets, storage, identity and market modules are exposed per capability, and every call is checked against the contract’s grants.
- 03
Resource meter
Counts compute as instructions execute and storage as state is written and retained, with a separate price for each. Per-call limits stop any single contract from monopolizing a lane.
- 04
Scheduler interface
Turns each transaction’s declared reads and writes into a conflict map for the deterministic scheduler, so independent contracts run on separate lanes while dependent ones are ordered.
- 05
Market module bindings
Typed interfaces into ApexMatch, Aegis and Prism. A contract can place an order, request a risk evaluation or read a confidence-scored price in the same transition as its own logic.
- 06
Upgrade controller
Code changes are explicit, versioned transitions under a policy fixed at deployment — immutable, time-delayed or subject to multi-party approval, for example. Every version keeps its code hash and capability manifest.
Security and failure control
How the runtime contains failure
NexusWASM keeps a defect inside the contract that contains it, and enforces that boundary in the runtime rather than by convention.
- Sandbox isolationEach contract runs in its own linear memory, with no access to host memory, other contracts’ memory or the validator’s environment. An out-of-bounds access traps, and the call reverts.
- Least authorityCapabilities are explicit and narrow. A contract allowed to read a price feed cannot move assets, and a contract allowed to move one asset cannot move another.
- Bounded executionMetering caps every call. Runaway loops, deep recursion and oversized writes end in a deterministic out-of-resources result, charged to the caller, with state rolled back.
- Access-set enforcementA transaction that touches state outside its declared sets is aborted, so parallel scheduling can never conceal a conflict between lanes.
- Market guardrailsOrders placed by contracts pass the same Aegis pre-risk checks and policy limits as orders from any other source. A contract gains access to the market, never a way around its controls.
Across the three systems
One runtime across Prime, L1 and Realm
Orbitra L1
Settlement and compute
NexusWASM is the contract runtime of the Orbitra L1 execution layer. It runs on VectorLanes, commits to shared state and hands results to QSE for finality. EVM Capsule sits beside it as an isolated compatibility domain, never in its place.
Orbitra Realm
Applications and commerce
Orbitra Realm applications — payments, tokenization, games, agent services — run natively as NexusWASM contracts, sharing identity, assets and liquidity with the rest of the network through NexusSDK primitives and VaultID permissions.
Value
What each audience gains
- Traders and users
- Applications that cannot reach further than they declare. A contract’s capabilities and upgrade policy are visible before you interact with it, so you know what it can do with your assets.
- Institutions
- A reviewable execution model. Capability manifests, code hashes and upgrade policies give risk and compliance teams concrete artifacts to assess, and deterministic execution means any outcome can be replayed.
- Developers
- Familiar languages, explicit costs and direct access to market infrastructure. Build in Rust or C/C++, see resource costs before deployment and call order books, risk checks and price feeds as typed interfaces. Start at the developer gateway.
Specifications
Specifications
- Runtime
- WebAssembly with a deterministic instruction profile
- Languages
- Rust, C/C++ and other modern toolchains that target WebAssembly
- Authority model
- Capability-scoped; no ambient access to assets, state or other contracts
- Resource pricing
- Explicit, separate pricing for compute and for storage written and retained
- State access
- Declared read and write sets per transaction, enforced during execution
- Parallelism
- Conflict-aware scheduling across VectorLanes
- Upgrades
- Versioned, policy-bound and recorded onchain for every contract
- Compatibility
- Ethereum bytecode runs separately in EVM Capsule, with a progressive migration path
Terminology
Terminology
- Capability
- An explicit grant that lets a contract use one resource — an asset, a state namespace, a market module or another contract.
- Declared access set
- The state a transaction says it will read and write, used for parallel scheduling and enforced while it executes.
- Metering
- Deterministic counting of the compute and storage a call consumes, used for both pricing and hard limits.
- Host function
- A runtime-provided operation — reading state, transferring an asset, placing an order — available to a contract only through a granted capability.
- Upgrade policy
- The rule fixed at deployment that determines whether, how and by whom a contract’s code can change.