ONE WORLDONE ECONOMYONE LEDGER

Scroll to Explore

91%of 93 central banks surveyed by the BIS in 2024 were exploring a retail CBDC, a wholesale CBDC, or both. BIS Papers No 159 · 2024 CBDC survey

Why now

Digital money is going sovereign. Payments cannot stay siloed.

Every jurisdiction must be able to govern its own money. The next monetary system also needs a shared protocol through which those sovereign systems can exchange value without surrendering their policy, privacy, or validator boundaries. SORA Nexus is the platform built for that interoperability.

Sovereignty without silos.

SORA Nexus gives CBDC systems policy-scoped data spaces and a common, programmable settlement layer. Institutions keep control of their own rules and data while authorized transactions coordinate across one logical ledger.

01 · Interoperability

Interoperability and sovereignty

Coordinate value across institutions while each sovereign data space retains its own policy and operating boundary.

Payments

ISO 20022 Gateway

Translate institutional payment messages into deterministic ledger actions and responses.

SORA Nexus gives institutional systems an ISO 20022-shaped path into programmable settlement. pacs.008 and pacs.009 messages can be validated at Torii, mapped to ledger-native instructions, and answered with a deterministic pacs.002 status.

The gateway does not ask a central bank to abandon its operating model. It gives CBDCs, tokenized deposits, and regulated assets a common protocol boundary where authorized value can coordinate with Iroha state.

Familiar Messages

Institutional payment intent arrives through pacs.008 and pacs.009 structures.

Deterministic Action

Validated messages resolve to explicit Iroha instructions under local policy.

Canonical Response

A pacs.002 status records whether the request was accepted, rejected, or settled.

Protocol atlas

ISO 20022 Gateway

pacs.008 and pacs.009 messages are validated, executed, and answered with a deterministic pacs.002 result.

ISO 20022 lets institutional payment messages cross into blockchain-based, programmable settlement and the digital economy.

A pacs.008 or pacs.009 message enters through Torii.
Schema and policy validation resolve the requested action.
Iroha executes the corresponding ledger instruction.
A deterministic pacs.002 status returns to the sender.

Sovereignty

Sovereign Data Spaces

Interoperate across explicit policy, privacy, governance, and validator boundaries.

A central bank should not have to give up monetary policy, governance, privacy, or its chosen validator boundary in order to interoperate. Sovereign data spaces make those controls part of the protocol topology.

Each space applies its own visibility and admission rules. When an authorized cross-space flow is requested, Nexus coordinates only the value, commitments, and proofs needed to settle it across one logical ledger.

Local Policy Survives

Each institution retains explicit rules for authority, visibility, and transaction admission.

Validator Boundaries Stay Legible

A restricted workload can use its own committee without becoming an unrelated chain.

Authorized Interoperability

Only approved value and evidence cross a space boundary; the whole private state does not.

Protocol atlas

Sovereign Data Spaces

Public and restricted spaces retain local policy while an explicitly authorized flow crosses the boundary.

Open and sovereign environments sharing one engine while keeping different boundaries.

Public and restricted spaces apply their own local policy.
An explicitly authorized request reaches the boundary.
Only approved evidence and value cross the space boundary.

Atomic coordination

Cross-data-space atomic transactions

Coordinate a transaction across sovereign systems without publishing a partial result.

An AMX transaction declares the data spaces and read/write sets it will touch. Each space prepares its part against a common snapshot, and Nexus publishes the state transition only when every required result is valid.

If any required space cannot prepare or its evidence does not verify, the exchange aborts without partial effects. Private spaces can contribute commitments and proofs while keeping their underlying transaction data local.

All or nothing

Every participating space commits together, or the transaction leaves no partial settlement behind.

Explicit scope

Declared data spaces and read/write sets make cross-boundary effects reviewable before commit.

Private by boundary

A restricted space can export state commitments and validity evidence instead of raw private data.

Interoperability

Cross-data-space atomic transactions

Two participant committees stage against one authority snapshot, exchange payment and delivery under a 2-of-2 latch, then commit or roll back together.

Commit both legs with a canonical AMX receipt—or restore both roots with no partial state.

Declare both data spaces, read/write sets, and one authority-context snapshot.
Stage A₀ → A₁ and B₀ → B₁ while both committees produce participant prepare QCs.
Deliver both proofs to the Nexus latch and wait for a visible 2-of-2 prepared state.
Move payment and delivery in opposite directions under one atomic lock.
Commit both legs with a canonical AMX receipt—or restore both roots with no partial state.

Settlement

Deterministic settlement router

Turn local obligations into canonical settlement evidence under one replayable policy.

The settlement router applies exact quantity conversion, configured margins and haircuts, and lane-specific buffer policy through deterministic arithmetic.

Each block aggregates settlement by lane and data space, records the resulting commitment and buffer state, and exposes receipts and telemetry that operators and auditors can reconcile.

Canonical conversion

Exact quantities, oracle inputs, margins, and rounding rules produce a replayable result.

Guard-railed reserves

Configured buffer states can alert, throttle, require XOR-only settlement, or halt settlement.

Evidence by lane

Settlement commitments and operational telemetry share the same lane and data-space identity.

Payments

Deterministic settlement router

Canonical amounts, policy-aware routing, lane commitment, and a reconciliation receipt follow one reproducible path.

Seal the lane commitment and emit a reconciliation receipt.

Validate the amount, oracle input, margin, and liquidity policy.
Calculate the canonical XOR obligation and applied haircut.
Check the lane settlement buffer and its policy state.
Seal the lane commitment and emit a reconciliation receipt.

02 · Execution

Execution and finality

Move from deterministic execution to independently verifiable commit evidence and one canonical result.

Engine

Hyperledger Iroha 3 Core

A deterministic runtime engineered for one scalable, programmable ledger.

Hyperledger Iroha 3 is the execution core of SORA Nexus. Torii receives traffic, Kotodama compiles high-level programs, and the IVM runs deterministic logic that every peer can verify.

Capacity grows through lane-native routing rather than by splitting the ledger. Lanes can be added or retired at runtime while Sumeragi, Kura, and shared state preserve one canonical history.

Turing-Complete Runtime

Kotodama compiles programs into validator-safe IVM bytecode so every peer executes the same bounded logic.

Lane Lifecycle at Runtime

Routing, manifests, and telemetry adapt when lanes are added or retired instead of forcing a new chain.

One Canonical Ledger

Parallel lanes raise throughput, but Sumeragi finality and Kura persistence still resolve into one authoritative history.

Protocol atlas

Iroha 3 Core

Torii admission, Kotodama compilation, deterministic IVM execution, lane routing, and one canonical commit.

One runtime, many lanes, one ledger.

Torii admits a signed request.
Kotodama compiles it for deterministic IVM execution.
The runtime routes the result through its assigned lane.
Sumeragi and Kura seal one canonical commit.

Scale

Lanes + Merge Ledger

Parallel execution without fragmenting shared state.

Lanes let independent workloads execute in parallel instead of competing for a single queue.

The merge ledger folds those lane commitments back into one canonical history, so the system can add capacity without forcing users, liquidity, or institutions onto separate chains.

Parallel by Default

Busy workloads spread across lanes instead of congesting one execution path.

One Shared History

The merge ledger keeps the network legible as one ledger, not a patchwork of shards.

Less Bridge Sprawl

Scaling adds throughput instead of more chains, wrappers, and bridge logic.

Protocol atlas

Lanes + Merge Ledger

Parallel workloads produce independent commitments that converge into one canonical merge-ledger block.

Parallel lanes converge back into one ledger rather than splintering into separate chains.

Independent workloads enter parallel execution lanes.
Each lane produces a certified state commitment.
The merge ledger orders those commitments into one block.

Elastic topology

Runtime lane lifecycle

Add, replace, or retire execution capacity through a consensus-controlled change.

An authorized, signed lifecycle transaction commits to the exact catalog and active lane incarnations its operator reviewed. Stale catalogs, invalid plans, and unauthorized requests are rejected without changing topology.

Once committed, every peer applies the same lane catalog, refreshes routing and limits, and reconciles storage. Retirement fails closed while a lane still has unmerged or unapplied certified work.

Consensus controlled

Lifecycle changes use normal signed transactions and publish only with a committed block.

Stale-safe changes

Catalog and incarnation commitments prevent delayed requests from mutating a different topology.

Coordinated cleanup

Routing, manifests, storage geometry, DA state, and relay caches move together.

Scale

Runtime lane lifecycle

Capacity can be added, routed, observed, and retired while one canonical ledger continues beneath it.

Bring the lane online, or retire it after outstanding work is clear.

Review the current catalog and sign a lane lifecycle plan.
Validate authority, catalog commitment, incarnation, and safety gates.
Commit the topology update and refresh queue routing.
Bring the lane online, or retire it after outstanding work is clear.

Finality

Sumeragi Consensus

Durable Byzantine finality with portable commit evidence.

Sumeragi advances an exact proposed block through Prepare and Commit quorum certificates, binding finality to its frozen validator roster, block hash, height, and deterministic state transition.

Validators durably store and validate the body before Prepare, persist their lock before Commit, and persist the Commit QC decision before applying it. A conflicting vote is rejected, reported as evidence, and never counted toward quorum.

Two Certified Phases

Prepare and Commit quorum certificates make the path to finality explicit.

Durable Before Signing

Body, vote intent, lock, and decision cross durable boundaries before the protocol advances.

Portable Evidence

Commit artifacts can travel with a result so relays and auditors can verify finality independently.

Protocol atlas

Sumeragi Consensus

An exact block advances through Prepare and Commit quorum certificates while conflicting votes are rejected and reported.

Validators certify the same exact body in Prepare and Commit phases; the Commit QC becomes portable finality evidence.

The expected leader broadcasts a signed proposal and payload manifest.
Validators reconstruct, validate, and durably store the exact body.
Count and voting-power thresholds form a Prepare quorum certificate.
Validators persist the exact lock before releasing Commit votes.
The Commit quorum certificate decides the subject.
The decision is persisted, the exact body is applied, and the next height opens.

Independent verification

Verifiable finality proofs

Carry exact commit evidence into another system—and bind it to trusted chain context before accepting finality.

A portable proof pairs the canonical block header with the exact durable Sumeragi finality artifact: frozen height context, certified block subject, execution commitment, Commit QC, and roster-aligned proofs of possession.

A verifier checks every structural binding, both count and voting-power quorum thresholds, ordered signer membership, validator key ownership, and the aggregate BLS signature. It accepts finality only after binding the first proof to an independently trusted chain and context anchor.

Exact evidence

The header and durable finality artifact preserve the subject, execution roots, Commit QC, frozen roster, and validator PoPs.

Dual quorum

The signer set must satisfy a distinct-validator threshold and voting power strictly greater than two thirds.

Trust stays external

A proof-carried roster cannot authenticate itself; the first accepted context is pinned through an independent trusted channel.

Finality

Verifiable finality proofs

A canonical header and exact Sumeragi finality artifact become portable evidence that a verifier checks against independently trusted chain context.

Verify structural bindings, dual quorum, signer order, PoPs, and the aggregate BLS signature before accepting finality.

Assemble the canonical header, certified subject, execution roots, Commit QC, frozen roster, and PoPs.
Seal the exact artifact into a portable Norito proof envelope.
Bind the proof to the expected chain and a separately trusted context anchor.
Verify structural bindings, dual quorum, signer order, PoPs, and the aggregate BLS signature before accepting finality.

03 · Programmability

Programmability

Compose native instructions, bounded IVM programs, explicit capabilities, and on-chain triggers.

Contracts

Kotodama Programs

High-level programs compiled into one deterministic runtime.

Kotodama lets teams write readable programs for markets, policy, automation, and apps.

Those programs compile to IVM bytecode, so every validator executes the same bounded logic inside the same runtime.

High-Level Source

Builders write readable programs instead of raw runtime internals.

Same Output Everywhere

Compilation targets one execution model shared by every validator.

Policy and Products

The same programming model can express market logic, automation, and controls.

Protocol atlas

Kotodama + IVM

Readable source compiles to bounded bytecode and produces the same deterministic state on every peer.

High-level programs compiling into one deterministic runtime shared across the network.

Readable Kotodama source is compiled to IVM bytecode.
Execution consumes a bounded cycle budget.
Every validator derives the same state transition.

Primitives

Iroha Special Instructions

Typed ledger operations compose into one deterministic state transition.

Core asset flows do not need a custom contract every time. Registering asset definitions, minting, transferring, granting permissions, and burning supply are native Iroha instructions.

Each instruction has explicit authority and policy semantics. Ordered batches can stage several dependent changes and commit them as one result—or discard every staged effect if any instruction fails.

Built-In Actions

Common ledger operations live in the platform itself.

Faster Product Work

Teams compose shared primitives instead of rebuilding the same flows from scratch.

Cleaner Audits

Auditors can reason about one rulebook instead of many near-duplicates.

Protocol atlas

Iroha Special Instructions

An ordered batch of typed register, mint, transfer, grant, and burn instructions stages deterministic ledger state under explicit authority.

An ordered batch of typed instructions stages deterministic ledger changes before one committed state.

Register CREDIT#CBDC with supply zero.
Mint 100 units to the issuer after authority and policy checks.
Transfer 30 units to the receiver without changing total supply.
Grant one permission while balances remain unchanged.
Burn 10 issuer units and commit final supply 90.

Policy

Capability manifests

Make dataspace authority specific, limited, revocable, and inspectable.

A capability manifest binds a universal account to one data space and scopes what it may do by program, method, asset, and optional AMX role. Activation and expiry epochs make that authority time-bound.

An optional maximum amount constrains the current request, while a successful grant returns its allowance window as metadata. Matching deny rules take precedence; activation, expiry, and revocation produce lifecycle events operators can monitor.

Least privilege

Authority is scoped to named data spaces, programs, methods, assets, and roles.

Deterministic limits

The requested amount is checked against the configured ceiling; the per-slot, per-minute, or per-day window returns with the grant.

Deny wins

A matching explicit denial overrides an allow candidate and returns a structured reason.

Policy

Capability manifests

A dataspace-scoped request is evaluated against explicit scope, a current-request amount ceiling, and deny-wins policy.

Scan matching deny rules, then return an allowed grant or structured denial.

Resolve the subject account to its universal account and active manifest.
Check the requested data space, program, method, asset, and role.
Check the request epoch and current amount against the manifest ceiling.
Scan matching deny rules, then return an allowed grant or structured denial.

Automation

On-Chain Automation

Ledger-native rules that react to deterministic events and execute bounded actions.

Each trigger stores one executable, one event filter, a declared authority, and a repeat policy on the ledger. Its filter can match a time schedule, an approved pipeline event such as an exact block height, a ledger data event, or an authorized by-call request.

When that one filter matches, Iroha runs the action under its registered authority through normal executor policy. Permissions, finite repeats, fuel or cycles, gas, and execution depth bound the work; the completion outcome identifies the trigger, execution hash, and step.

Network-Native Scheduling

Scheduled and event-driven flows do not depend on a separate bot or cron service.

One Exact Filter

A registered trigger listens to one deterministic event filter, not every source at once.

Bounded Execution

Permissions, repeats, fuel or cycles, gas, and execution depth constrain automated work.

Protocol atlas

On-Chain Automation

One registered event filter activates a bounded executable under its declared authority, then records the completion outcome.

One registered event filter activating a bounded action and recording its completion outcome.

Four supported trigger configurations appear; one exact approved-block filter is selected.
The matching event loads its registered executable, authority, and remaining repeats.
Filter, enabled state, action authority, and runtime bounds resolve in order.
The action stages a visible state change and consumes one finite repeat on success.
TriggerCompleted records the trigger ID, execution hash, step, and outcome.

Codec

Norito Codec

Typed values become schema-bound frames that can be checked and reconstructed exactly.

Norito encodes an Iroha value into a canonical payload, then frames it with a 40-byte NRT0 header carrying the format version, expected schema hash, compression mode, declared length, CRC64-XZ integrity checksum, and layout flags.

A reader validates those boundaries before reconstruction. With one schema and explicit uncompressed layout, the same value produces the same bytes; optional compression preserves decoded content without promising identical compressed frames across every backend.

Schema-Bound Frames

A 16-byte schema hash binds the payload to the type the decoder expects.

Streaming Validation

The reader consumes the declared payload, then verifies its CRC64-XZ integrity checksum.

Exact Reconstruction

Canonical field order and explicit layout rules remove ambiguity from the roundtrip.

Protocol atlas

Norito Codec

A typed value becomes a schema-bound NRT0 frame, crosses a chunked reader, passes format and integrity checks, and reconstructs exactly.

One typed value becoming a validated NRT0 frame and reconstructing without ambiguity.

Ordered fields serialize into one canonical payload.
The encoder seals a 40-byte NRT0 header around its schema, length, checksum, compression, and layout metadata.
Header and payload bytes cross the reader in visible chunks.
Magic, version, layout flags, schema, declared length, and CRC64-XZ resolve in order.
The same typed value reconstructs and the roundtrip closes.

Ecosystem extension

SoraNet + SoraFS

Select a private relay path, retrieve content-addressed chunks from available providers, and verify the reconstructed payload against its manifest.

SoraNet is the transport path: in strict relay mode, a blinded content request crosses distinct entry, middle, and exit roles. SoraFS is the retrieval layer: its manifest binds the root, chunk order, length, and expected digests before multiple providers return the bytes.

Every fragment is checked before the payload is reconstructed and returned with fetch evidence. An authorized ledger payment remains a separate, composable action—giving software agents a clean way to request a service, verify what arrived, and exchange value under explicit policy.

Selected Relay Circuit

A blinded request traverses the selected entry, middle, and exit route.

Manifest-Bound Retrieval

The manifest defines the exact chunks, order, length, and digests the fetch must satisfy.

Verify, Then Deliver

Provider chunks are checked and reassembled before the object returns; authorized payment can compose separately.

Protocol atlas

SoraNet + SoraFS

A blinded content request crosses a selected three-hop SoraNet circuit. SoraFS resolves its manifest, retrieves and verifies chunks from multiple providers, reconstructs the payload, and returns the verified object with fetch evidence.

SoraNet selects the relay path. SoraFS retrieves, verifies, and reconstructs the content.

A content-addressed request becomes a blinded key.
Role, version, and strict transport policy select the SoraNet path.
The request crosses entry, middle, and exit relay roles.
SoraFS resolves the manifest and its expected chunk digests.
Eligible providers return chunks into an ordered reconstruction buffer.
Each chunk and the completed payload match the manifest commitments.
The verified object and fetch evidence travel back through the selected circuit.
Delivery completes; any authorized ledger payment remains a separate composable action.

04 · Agent economy

A shared economy for AI agents

Apply Iroha accounts, assets, permissions, and automation to future machine-to-machine commerce.

Future use case

A shared economy for AI agents

Future use case · Iroha provides the account, asset, policy, and settlement primitives.

SORA Nexus will empower AI agents to pay one another, create new assets, and exchange them across applications and sovereign data spaces—under explicit human-defined permissions and deterministic settlement rules.

A software agent can act through an ordinary key-controlled Iroha account. People and institutions remain responsible for assigning its roles, permissions, budgets, spending limits, and transaction authority.

Authorized accounts can compose native asset registration, minting, transfer, and exchange instructions. That foundation can support compute credits, dataset access, model licences, storage capacity, energy units, task receipts, and digital output rights.

Kotodama/IVM programs and on-chain triggers can automate service payments, delivery conditions, recurring work, and settlement receipts. Cross-data-space atomic transactions can make payment and asset delivery succeed together or roll back together. Canonical Norito records and Sumeragi finality can give agents and their human operators an auditable history of what was authorized and what actually settled.

Iroha supplies economic, automation, and policy primitives. It does not run AI models, determine whether an account is controlled by AI, or grant any agent unrestricted autonomy.

Machine-readable value

Authorized accounts can create and exchange fungible assets, NFTs, and service rights.

Atomic exchange

Payment and digital delivery can commit together or leave neither side with a partial result.

Human-defined authority

Roles, capabilities, budgets, limits, and audit records bound what an agent may do.

Future use case

A shared economy for AI agents

Permissioned software agents can exchange payment and digital rights atomically, leave canonical receipts, or roll back without a partial transfer.

A third authorized account can acquire or exchange the asset under its own policy.

A buyer account requests data, compute, storage, or another machine-readable service.
The account passes authority, balance, and spending-limit checks.
An authorized provider account registers or mints the service asset.
Payment and asset delivery enter one atomic cross-data-space transaction.
Value moves to the provider while the service right moves to the buyer.
Both sides commit together, or both visibly roll back.
An on-chain trigger emits canonical receipts for operators to audit.
A third authorized account can acquire or exchange the asset under its own policy.

05 · Privacy

Privacy and durability

Verify the evidence a transaction requires without dissolving the data boundary that produced it.

Private evidence

FASTPQ Proof Pipeline

Turn private execution commitments into verifiable admission evidence.

FASTPQ provides the proof pipeline for confidential data-space execution. Private trace commitments can become proof inputs while the underlying activity remains inside its sovereign boundary.

The public side verifies the required evidence and reaches an admission decision without receiving the complete trace. Privacy changes what must be revealed, not whether correctness must be checked.

Private Trace

Sensitive execution remains within the data space that produced it.

Public Commitment

Canonical commitments bind the proof to the private result without publishing the result itself.

Verified Admission

A required proof can pass or fail the public admission rule before queueing.

Protocol atlas

FASTPQ Proof Pipeline

Private trace commitments become public proof inputs and a verified decision without exposing the trace.

Zero-knowledge proofs keeping one standard of trust across very different workloads.

A private execution trace stays inside its data space.
The trace becomes public commitment and proof inputs.
Verification resolves admission without revealing the trace.

Proof-gated policy

Privacy-proof admission

Require approved evidence before a private-lane transaction can enter the queue.

Lane manifests register the approved privacy commitments for a workload, including canonical Merkle roots or proof descriptors. A transaction can attach the corresponding witness without placing the protected state itself into the public flow.

Admission verifies the attachment against the routed lane registry and then applies the lane compliance rule. Proof-required flows fail closed when the witness is missing, malformed, or bound to an unregistered commitment.

Manifest-bound roots

Governance publishes stable commitment identifiers and approved verification parameters.

One admission path

The runtime and audit tooling evaluate the same canonical proof binding.

Fail closed

A proof-required transaction is rejected before queueing when acceptable evidence is absent.

Privacy

Privacy-proof admission

A private lane proves its commitment against an approved root without exposing the underlying sovereign activity.

Admit valid evidence and visibly reject the missing-proof path.

Route the transaction to its lane and load the live commitment registry.
Match the proof attachment to a registered commitment identifier.
Verify the witness and evaluate the lane compliance requirement.
Admit valid evidence and visibly reject the missing-proof path.

Proofs

Data Availability & Proofs

Committed data needs to remain retrievable.

Finality is not enough if the data behind a commitment cannot be recovered.

Data availability sampling and recovery keep committed history reconstructable, so proofs remain tied to data the network can still retrieve.

Recoverable History

Committed data should remain reconstructable long after it is written.

Proofs Backed by Retrieval

Availability checks keep trust anchored to the underlying data.

Long-Lived Records

The stack is designed for systems where records must remain useful for years.

Protocol atlas

Data Availability

Sharded data is sampled, survives partial loss, and reconstructs from the remaining pieces.

Sampling and recovery paths keeping the network’s memory intact.

Committed data is encoded into recoverable shards.
Validators sample random pieces as some shards disappear.
The remaining threshold reconstructs the original data.

Sovereign money. Permissioned software. One protocol.

Enter the Nexus

The CBDC era—and the emerging agent economy—need a common protocol.

SORA Nexus is building it on Hyperledger Iroha 3.

Download the whitepaper Explore Hyperledger Iroha 3

ONE WORLDONE ECONOMYONE LEDGER

Digital money is going sovereign. Payments cannot stay siloed.

Sovereignty without silos.

Interoperability and sovereignty

ISO 20022 Gateway

ISO 20022 Gateway

Sovereign Data Spaces

Sovereign Data Spaces

Cross-data-space atomic transactions

Cross-data-space atomic transactions

Deterministic settlement router

Deterministic settlement router

Execution and finality

Hyperledger Iroha 3 Core

Iroha 3 Core

Lanes + Merge Ledger

Lanes + Merge Ledger

Runtime lane lifecycle

Runtime lane lifecycle

Sumeragi Consensus

Sumeragi Consensus

Verifiable finality proofs

Verifiable finality proofs

Programmability

Kotodama Programs

Kotodama + IVM

Iroha Special Instructions

Iroha Special Instructions

Capability manifests

Capability manifests

On-Chain Automation

On-Chain Automation

Norito Codec

Norito Codec

SoraNet + SoraFS

SoraNet + SoraFS

A shared economy for AI agents

A shared economy for AI agents

A shared economy for AI agents

Privacy and durability

FASTPQ Proof Pipeline

FASTPQ Proof Pipeline

Privacy-proof admission

Privacy-proof admission

Data Availability & Proofs

Data Availability

Enter the Nexus

Many worlds. One economy.