Skip to content
ORBITRAONE™

Orbitra L1 · Execution layer

The runtime where applications join the market.

NexusWASM is the contract runtime of the execution layer in Orbitra L1. It is how a market-native chain stays open to everything else — payments, tokenization, games, data and agent services — while its market modules remain native and deterministic.

Explore NexusWASMOrbitra L1
Illustration: Orbitra L1 as six stacked layers: experience at the top, then market services, execution, consensus, data and network at the base. Light travels down through the layers as a transaction is executed and finalized, and back up as confirmed state.
  1. 01ExperienceOrbitra Prime · wallets · apps · institutional APIs
  2. 02Market servicesApexMatch · Aegis · Prism · clearing · settlement
  3. 03ExecutionVectorLanes · deterministic scheduler · NexusWASM
  4. 04ConsensusQSE quorum · finality certificates · validator policy
  5. 05DataState commitments · history · index streams · proofs
  6. 06NetworkRegional ingress · encrypted transport · availability mesh

Layer · Execution

Role in the Orbitra L1 stack

Inside the execution layer, NexusWASM runs contract code while VectorLanes and the deterministic scheduler decide where and in what order it runs. Each transaction declares its reads and writes, which lets contracts share parallel lanes with market activity instead of waiting behind it.

Contracts reach upward into the market-services layer — ApexMatch, Aegis and Prism — through granted capabilities rather than open access. Their results pass downward like any other transition: committed by the data layer and finalized by QSE.

Beside NexusWASM sits EVM Capsule, an isolated domain for Ethereum bytecode and tooling. It extends developer reach at the edge of the stack; it never replaces the primary runtime or places EVM constraints on it.

Illustration: A NexusWASM contract runs inside a sandbox. It can only reach the capabilities it declared — including native market modules — while compute and storage are metered and its declared state access lets the scheduler run it in parallel with unrelated work.
Contract

  • Capabilities

  • Metered compute

  • Metered storage

What NexusWASM contributes to the stack

  • 01

    Openness with boundaries

    General applications run on the network, yet each contract reaches only the assets, state and modules it has been granted.

  • 02

    Parallel-ready contracts

    Declared access sets let the scheduler place contract calls beside market transitions rather than behind them.

  • 03

    Accountable resources

    Explicit compute and storage pricing makes application demand pay for what it consumes, including long-lived state.

  • 04

    Composition with markets

    A contract can combine its own logic with order placement, risk checks and price reads in a single transition.

Canonical technology pageThe full runtime referenceThe canonical NexusWASM page covers the deterministic sandbox, the capability model, metering, upgrade controls, toolchains and specifications.Explore NexusWASM

Orbitra L1

Other Orbitra L1 modules