Skip to content
ORBITRAONE™

Developers

Build on the market itself.

NexusSDK exposes the primitives of ORBITRA ONE™ — order books, risk, identity, assets, agents and payments — as first-class services. Applications call the same deterministic modules that run the markets instead of rebuilding a venue around them.

Read the documentationRegister developer interest
  • NexusSDK
  • NexusWASM
  • EVM Capsule
  • Node tooling

NexusSDK overview

Market primitives as first-class services.

NexusSDK is the developer surface of the whole system. It reaches into the market-services layer of Orbitra L1 — ApexMatch, Aegis, Prism, clearing and settlement — and into the execution layer, where NexusWASM contracts run.

Every call is made by an identity with scoped permissions, and every state change returns signed evidence. The hardest parts of a financial application — matching, risk, eligibility and finality — already exist as protocol modules, so the distance between an idea and a trusted application gets shorter.

  • Typed services over native protocol modules
  • Signed receipts for every state change
  • Scoped credentials issued through VaultID
  • Sandboxed samples in TypeScript, Python and Rust
Start with the quickstart
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

Primitives

Six services. One permission model.

Each service is a typed interface over a native module. All six share one account model, one risk view and one evidence format.

Market APIs

Orders, books and clearing

Place, amend and cancel orders on ApexMatch, stream book and trade state, request RFQ quotes and read clearing deltas. API orders pass the same Aegis pre-risk gate as orders from the interface.

Asset Studio

Issuance and lifecycle

Issue and administer tokenized assets with issuer permissions, lifecycle events such as distributions and redemptions, and eligibility rules enforced on every transfer. See tokenization.

Agent identity

Accountable automation

Register AI agents and bots as identities of their own, each bound to a Cortex policy. Every agent action is signed, attributable and revocable.

Data exchange

Data with provenance

Publish and license datasets and signals with verifiable provenance. Buyers see source and freshness; contributors keep control of access terms.

VaultID

Credentials, not documents

Check eligibility and permissions through VaultID. Your application learns what a user may do without ever handling the documents behind it.

Payments

Settlement in application logic

Request, authorize and settle payments on the same deterministic finality as trades, with conditions expressed in code rather than reconciled afterwards.

NexusWASM

Contracts that declare what they can touch.

NexusWASM is the primary contract environment of Orbitra L1. Contracts compile from Rust, C and C++ to WebAssembly and run in a metered sandbox where compute and storage carry explicit prices.

Each contract declares its capabilities at deployment: the market primitives it may call and the state it may read or write. The runtime refuses anything outside that declaration, and declared state access lets independent contracts execute in parallel on VectorLanes.

  • Capability-scoped contracts
  • Explicit compute and storage pricing
  • Native calls into ApexMatch and Aegis
  • Rust, C and C++ toolchains
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

EVM Capsule migration path

Start in the capsule. Move into the core.

The EVM Capsule runs existing Ethereum bytecode and tooling in an isolated domain with its own resource ceilings. It is a compatibility boundary, never the core runtime.

  1. 01

    Arrive

    Deploy existing contracts with familiar tooling. They run unchanged inside the capsule, metered against independent gas and resource limits.

  2. 02

    Connect

    Assets reach the core only through the governed gateway, with rate limits, route caps and circuit breakers on every transfer.

  3. 03

    Profile

    Find the code paths that need native performance or direct market access — usually order handling, settlement and risk logic.

  4. 04

    Port

    Rewrite those paths as NexusWASM contracts that call ApexMatch and Aegis natively, keeping the capsule version as a behavioral reference.

  5. 05

    Retire

    When both versions produce the same results from the same inputs, move users to the native contracts and wind the capsule deployment down.

A fault inside the capsule is contained by its own limits and circuit breakers. Capsule workloads never constrain the core runtime.

Validator and node tooling

Run a node against real state.

Developers and operators use the same node client. Developers replay and query finalized state; validators add signing duties on top.

Local replay
Replay finalized transitions to develop and test against real protocol state
Index streams
Subscribe to streaming state output for applications, analytics and reconciliation
Proof verification
Check state commitments and QSE finality certificates on the client side
Release integrity
Signed releases, verified before installation or upgrade
Operator signing
HSM and MPC signer integration for validator keys — see validators

Resources

Examples, status and release notes.

ExamplesSandboxed code examples
Samples in TypeScript, Python and Rust read credentials from environment variables, never from source, and run in sandbox environments. Browse them in the documentation gateway.
API statusService status
The status page reports the website, access intake, and network and trading services, and shows where incident updates are published.
ChangelogRelease notes with every version
Release notes are published with each NexusSDK version in the documentation gateway: interface changes, deprecations and migration steps, versioned beside the reference they describe.

Developer interest

Tell us what you are building.

SDK access, sandbox credentials and published package names are issued to registered developers. Describe your application and the primitives it needs.

  1. 01Each request is reviewed against the primitives and environments it needs.
  2. 02Approved developers receive scoped sandbox credentials and documentation access.
  3. 03Published package names are shared with SDK access.
  4. 04We never ask for private keys, seed phrases or passwords.

Never include passwords, private keys, seed phrases or identity documents.