ONE WORLDONE ECONOMYONE LEDGER

Scroll to Explore

One world.
One economy.
One ledger.
One democracy.

SORA Nexus proposes one logical ledger for a connected economy: shared state for markets, payments, and public infrastructure, governed through sortition, isonomia, and isegoria, and designed to scale without breaking into separate chains.

One logical ledger

One shared ledger instead of fragmented chains, bridges, and duplicated state.

Democratic governance

Sortition, isonomia, and isegoria shape how the common ledger is governed.

Global governance

Humans and AI systems can participate in decision-making and conflict resolution at global scale.

World scale

Lanes and merge preserve the one-ledger model while expanding capacity.

WalletSORA WalletSelf-custodial mobile access to SORA assets, swaps, and on-chain activity.ExchangePolkaswapSwap interoperable assets through on-chain routing and cross-chain connectivity.ValidatorsRun InfrastructureRun validator infrastructure or nominate XOR on the live SORA network.BuildersLaunch on SORASupport for teams launching new products or migrating existing ones to SORA.CBDCPolicy InfrastructureExplore CBDC and tokenized-asset workflows on shared SORA infrastructure.

Engine

Hyperledger Iroha v3 Core

A deterministic runtime built to scale through lanes.

Hyperledger Iroha v3 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.

One runtime, many lanes, one ledger.

IVM

Runtime

Deterministic execution shared across the validator set.

Lane lifecycle

Scale

Expand capacity by updating the lane catalog and routing policy.

Sumeragi + Kura

Commit

Finalize blocks and persist one canonical ledger state.

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.

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

Add lanes

Scaling move

Increase capacity horizontally.

One ledger

User experience

Builders and users stay on one shared history.

Fewer bridges

Strategic result

Less fragmentation to stitch back together later.

Finality

Sumeragi Consensus

Deterministic finality for payments and settlement.

Sumeragi is designed for environments where a transaction must be final, not merely likely to remain final.

Validators agree on one history, collectors aggregate the signatures, and the network reaches settlement fast enough for payments, markets, and institutional workflows.

Fast Finality

Applications can treat a committed result as done instead of waiting through probabilistic delay.

Fault Tolerant

Safety can hold even when part of the validator set is faulty or offline.

Settlement-Grade

The model is designed for payment and institutional flows, not headline throughput demos.

Leader proposes a block, validators sign votes, collectors bundle the certificate, and the block becomes final.

Deterministic finality

User feel

Designed to feel like settlement infrastructure, not delayed confirmation.

Byzantine fault tolerant

Safety model

Safety holds even when some validators misbehave.

Public or sovereign

Deployment fit

The same model works across open and restricted deployments.

Topology

Sovereign Data Spaces

Boundaries for policy, privacy, and routing.

Sovereign data spaces let one platform support open markets and restricted environments without splitting into unrelated stacks.

Each space can enforce its own visibility and policy rules while still anchoring into a wider network, making room for CBDCs, regulated workflows, and open DeFi on the same base platform.

Different Trust Models

Open applications and policy-heavy deployments can coexist on the same platform.

Boundaries in the Architecture

Sensitive workloads keep clear operational boundaries without moving to separate infrastructure.

Shared Engine

One underlying system can serve both open and sovereign use cases.

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

Shared but segmented

Platform shape

Different workloads do not need one policy regime.

CBDCs + DeFi

Big payoff

Sovereign finance and open markets can share the same base infrastructure.

Explicit boundaries

Governance path

Cross-space interaction stays visible and auditable.

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.

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

High-level source

Developer model

Teams write intent instead of raw machine behavior.

Controlled execution

Trust model

Programs run inside one predictable runtime.

Beyond DeFi

What it enables

The same model serves markets, policy, and apps.

Primitives

Iroha Special Instructions

Native asset operations instead of repeated boilerplate.

Core asset flows do not need a custom contract every time. Registering assets, minting, burning, transferring, and changing permissions are native instructions.

That shortens implementation time, simplifies audits, and keeps behavior consistent across deployments.

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.

Built-in instructions cover the core asset-management jobs teams perform on every ledger.

More built in

Product speed

Common behavior ships with the network.

Fewer custom flows

Contract load

Teams reach for custom code less often.

One rulebook

Shared semantics

The same action means the same thing everywhere.

Automation

On-Chain Automation

Automation that executes inside the ledger.

Recurring and event-driven workflows can run on-chain instead of depending on an external bot or scheduler.

When a condition is met, the ledger can trigger the next action under the same budget, authority, and governance rules as everything else.

No Hidden Scheduler

Critical workflows stay inside the network rather than depending on a single external operator.

Event-Driven

Time, height, and ledger events can all trigger follow-up actions.

Policy Stays On-Chain

Automation follows the same fee, budget, and governance guardrails as the rest of the system.

Automation running inside the ledger instead of on an external bot or scheduler.

Network-native automation

Reliability

Follow-up logic does not depend on one operator remembering to run it.

Budgeted actions

Control

Automation stays inside the platform’s own guardrails.

Finance to apps

Range

The same trigger model serves payments, workflows, and apps.

Network

SoraNet

The same governed stack can serve applications, APIs, and media.

SoraNet extends the platform beyond financial state changes into services, APIs, and media delivery.

Together with SoraFS, it points to a stack where apps, content, and realtime products can live on the same governed infrastructure as payments and markets.

Apps and APIs

The stack is built to serve online services, not only financial state transitions.

SoraFS Storage Layer

Publishing, delivery, and storage remain part of the same platform.

Media-Ready Network

The same foundation can support video, rooms, and other internet-scale products.

One governed network and storage layer for apps, APIs, and media.

SoraNet + SoraFS

Stack

Networking and storage are treated as one platform layer.

Kaigi + Taikai

Examples

The same stack can support video, rooms, and media delivery.

Beyond finance

Big ambition

SORA Nexus extends beyond finance into broader internet infrastructure.

Proofs

FASTPQ zk-STARK

Prove correctness without exposing underlying data.

FASTPQ is the zero-knowledge layer for confidential data spaces.

A space can prove it followed the rules without revealing every underlying transaction, allowing open and sovereign deployments to share one standard of assurance.

Proofs for Whole Spaces

An environment can prove it followed the rules without exposing every event.

Privacy Without Blind Trust

Confidential workloads still participate in a shared standard of correctness.

Shared Assurance

Open and sovereign deployments can verify against the same rules.

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

Prove without revealing

Confidentiality

Sensitive workloads show correctness without exposing raw activity.

Shared assurance

Verification

Anyone with the public rules can verify the proof path.

Public and sovereign

Strategic fit

The same proof system supports open and confidential deployments.

010

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.

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

Recoverable by design

Durability

History stays reconstructable without every node storing everything forever.

Availability sampling

Checks

The network tests whether committed data can still be retrieved.

Infrastructure memory

Why it matters

Important records should outlast the moment they were created.

011

Codec

Norito Codec

A shared format for transactions, proofs, and streams.

Norito is the common data language across SORA Nexus.

Using one self-describing format for transactions, blocks, proofs, and streams reduces translation overhead and helps the platform behave as one system as it grows.

One Language Across the Stack

The same encoding model reaches across ledger data, proofs, and delivery surfaces.

Readable and Wire-Efficient

Teams get structured data that stays fast to move and parse.

Less Glue, More Platform

Shared encoding helps the stack behave like one coherent system.

One shared data language tying the ledger, proof, and application stack together.

Ledger to streaming

Reach

The same data language reaches across contracts, proofs, and delivery paths.

Less translation

Experience

Teams spend less time stitching formats together.

One coherent platform

Effect

Shared encoding helps SORA Nexus behave like one system.

ENTER THE NEXUS

Built on SORA Nexus/Hyperledger Iroha 3. The ultimate infrastructure for the new world economic order is ready.

Download Whitepaper

Follow on X Join Telegram

ONE WORLDONE ECONOMYONE LEDGER