日本語 Get in touch

Built on Hyperledger Iroha 3

SORA Nexus

One shared ledger. Sovereign data spaces.

SORA Nexus is designed to connect central banks, commercial banks and markets on a single network, so domestic payments, cross-border exchange and digital assets can work together while every institution keeps control of its currency, policies and data.

In development · architecture validation continuing

See how it works Talk to our team

Why SORA Nexus

Financial systems were built to be separate. The economy isn’t.

Payments, securities and digital currencies increasingly run on digital ledgers, but each one is an island. Connecting them means bridges, intermediaries and reconciliation, or handing control to someone else.

  • 01

    Fragmented ledgers

    Every system has its own rules and its own copy of the truth, so value and liquidity are split across networks.

  • 02

    Fragile connections

    Bridges and chains of intermediaries add cost, delay and new points of failure to cross-border settlement.

  • 03

    Control or connectivity

    Institutions should not have to choose between keeping sovereignty over their systems and connecting to everyone else.

How it works · 01

One network, many sovereign domains

Data spaces

Banks, central banks and other institutions each organise their data, authority, policies and applications in a data space, which may be public, permissioned or consortium-based, with its own access and visibility rules.

How it works · 02

Lanes

Each data space can contain multiple lanes, and each lane belongs to one data space. Lanes provide transaction routing and certification capacity, so throughput grows by adding lanes.

How it works · 03

The global chain

For public transaction processing, lanes certify admission and ordering; the global chain then merges eligible transactions, executes them and records the outcome in one shared history. A lane certificate alone does not establish a successful payment.

How it works · 04

Local finality

An independently signed data-space root has its own state and local finality, so private data and institutional policy stay with the institution.

How it works · 05

Coordinated settlement

The architecture aims to coordinate related obligations across independently executing data spaces: completing both legs of a currency exchange together, or linking the delivery of a security with its payment.

Inside Hyperledger Iroha 3

Words that become rules

Kotodama is named after 言霊, the old Japanese belief that words carry power. In Iroha 3 it is the language institutions write their rules in, and the Iroha Virtual Machine runs those rules the same way on every validator.

transfer.ko
// Transfer example
seiyaku TransferDemo {
    permission AssetTransferRole;

    kotoage fn do_transfer() authorize(AssetTransferRole) {
        ledger::asset::transfer(
            source: AccountId::parse("sorau…"),
            destination: AccountId::parse("sorau…"),
            asset_definition: AssetDefinitionId::parse("62Fk4F…"),
            amount: 10,
        );
    }
}

Kotodama’s transfer example. Every keyword has an exact Japanese equivalent.

One artifact, one result

Same state root

  • 誓約 seiyaku せいやく solemn pledge The contract itself: one deployable unit, compiled to one IVM artifact.
  • 言挙げ kotoage ことあげ raising one’s words A public function that changes state, callable only by those it authorizes.
  • 始まり hajimari はじまり beginning Runs once at activation to set up the contract’s state.
  • 改善 kaizen かいぜん improvement Runs once when the code is replaced, migrating state in place.

  • Deterministic by construction

    Contracts compile to a single IVM artifact. Hardware acceleration (SIMD, Metal, CUDA) is opt-in with deterministic CPU fallbacks, so every validator computes the same result.

  • Bounded and guarded

    Each program carries a cycle limit, and every call into the ledger passes one syscall gate that enforces the ABI and validates typed references to accounts, assets and data spaces.

  • Upgrades that keep their word

    A kaizen hook migrates state once when code is replaced, and upgrades that would rename or retype stored data are rejected.

  • Sumeragi BFT consensus

    Byzantine-fault-tolerant consensus targets finality in around a second under normal conditions, with a SORA Nexus block every second.

  • Proofs, not disclosure

    FASTPQ zk-STARK proofs, with no trusted setup, let a private data space show what it executed while exporting only proofs and commitments.

  • Post-quantum by default

    Data-space quorum certificates use ML-DSA-87, a Dilithium-class post-quantum signature scheme, unless configured otherwise.

  • One encoding everywhere

    Norito gives every message a single canonical encoding, so nodes and SDKs read exactly the same bytes.

  • Written in Rust

    A memory-safe core, with SDKs for Swift and Android and APIs in both Norito and JSON.

Technical details from the open-source Hyperledger Iroha specifications. Iroha 3 is in development, and details may change.

For central banks

Built for central bank money

A digital currency has to stay sovereign, private and under control, yet reach every bank, wallet and border. SORA Nexus is designed so the central bank keeps the keys while the network does the connecting.

  • Monetary sovereignty

    The central bank runs its own private data space, with its own validators, rules and records. Transaction data stays inside; only commitments are anchored to the shared ledger.

  • Two-tier by design

    Commercial banks join with their own data spaces and are approved through governance before they can transact atomically with the central bank.

  • Policy as code

    Capability manifests bind each account to allowances per slot, minute or day. An explicit deny always wins, and manifests expire on schedule.

  • Privacy with proof

    Private data spaces keep their records to themselves, and the central bank decides which proofs may leave.

  • Governed and auditable

    Manifests, whitelists and lane changes are approved through governance and recorded in the on-chain Space Directory, and lane evidence can be exported for regulators.

  • Emergency controls

    Governance can pause settlement on a lane, which then rejects new settlements with a deterministic error.

  • Isolated performance

    Each data space has its own mempool and execution, so public activity cannot slow a central bank’s own transactions.

  • One account across spaces

    Every participant has one universal account ID that spans all data spaces, with permissions set separately in each.

Proven on Hyperledger Iroha

  • BakongCambodia’s national payment system, in production since 2020, with 1.3 billion transactions in 2025.
  • Bokolo CashSolomon Islands proof of concept with two-tier KYC, interbank settlement and simulated cross-border transfers.
  • Digital KinaPapua New Guinea proof of concept with real-time payments and tested recovery of funds after theft or loss.
  • DLakLao PDR proof of concept for QR payments and cross-border use, building on lessons from Bakong.

Across borders

Settle across borders in one step

Today a cross-border payment hops between correspondent banks, each keeping its own ledger, and can take days to settle. SORA Nexus is designed to settle both currencies of an exchange in one atomic transaction, while each central bank keeps its own rules.

  1. Begin

    One submission names both data spaces and both legs of the exchange.

  2. Prepare

    Each data space checks its own rules and escrows its leg. Private data never leaves.

  3. Decide

    The global chain commits both legs together by a deadline, or aborts both with a documented reason.

  4. Settle

    Each data space finalises its leg, and the outcome is recorded in a single Nexus block.

  • Payment versus payment, delivery versus payment

    The same atomic commit links the two currencies of an FX trade, or a security with its payment.

  • Speaks ISO 20022

    Work on ISO 20022 covers credit transfers (pacs.008), returns (pacs.004) and cancellation requests (camt.056), so existing systems can connect.

  • Already crossing borders

    Bakong, built on Hyperledger Iroha, already links QR payments with eight regional economies.

Bakong connectivity: National Bank of Cambodia, Financial Stability Review 2025.

Use cases

What SORA Nexus is designed for

  • Domestic payments and CBDCs

    A central bank runs retail or wholesale currency in its own data space, with its own rules for access and privacy.

  • Cross-border payments and FX

    Both legs of a currency exchange complete together across independently governed data spaces.

  • Stablecoins and tokenised deposits

    Regulated issuers operate private data spaces that can still interoperate with the wider network, where policy allows.

  • Securities and digital bonds

    Link the delivery of a security with its payment, building on our work on Palau Invest savings bonds.

  • Open finance with guardrails

    Public data spaces interact with assets from regulated domains only where those domains’ policies permit.

Foundation

Grounded in a decade of production experience

SORA Nexus builds on ten years of Hyperledger Iroha in real institutions, most visibly Bakong, the national payment system SORAMITSU co-developed with the National Bank of Cambodia.

  • ≈45 millionBakong accounts
  • 450%of Cambodia’s GDP processed through Bakong in 2025
  • 10years of Hyperledger Iroha
  • 3central bank digital currency proofs of concept in the Pacific and Southeast Asia

Bakong figures: National Bank of Cambodia, Annual Report 2025 and Financial Stability Review 2025.

“With Iroha 3-powered SORA Nexus, our ambition is to connect economies globally, promoting high economic growth, while enabling central banks, corporations, and other institutions to retain control of their currencies, policies, and data.”

Dr Makoto TakemiyaCo-Founder and Group CEO, SORAMITSU

Status

Where SORA Nexus is today

Hyperledger Iroha 3 is in development, and SORAMITSU continues to develop and validate the SORA Nexus architecture. We work with central banks, financial institutions and developers who want to shape how it connects to the systems they operate.

  1. 01

    Define the need

    Who should the system serve? What must your institution control?

  2. 02

    Test a focused use case

    Agree the scope, participants and measures of success.

  3. 03

    Plan for operation

    Resolve integration, governance and operating responsibilities.

FAQ

Questions about SORA Nexus

What is SORA Nexus?

SORA Nexus is a next-generation network built on Hyperledger Iroha 3. It is designed as one shared ledger made up of data spaces, in which central banks, banks and other institutions organise their own data, authority, policies and applications while connecting with one another.

What is a data space?

A data space is an environment governed by an institution or group of institutions. It defines its own access and visibility rules and can be public, permissioned or consortium-based. Each data space can contain several lanes, and each lane belongs to one data space.

How is this different from a blockchain bridge?

Bridges connect separate chains by locking and re-issuing assets, which adds cost and risk. In SORA Nexus, data spaces are anchored in the same ledger, so related transactions can be coordinated by the network itself rather than by an external bridge.

What is Kotodama?

Kotodama is the smart-contract language of Hyperledger Iroha 3, named after 言霊, the Japanese idea that words carry power. A contract is a seiyaku (誓約, “solemn pledge”) and its public functions are kotoage (言挙げ, “raising one’s words”). Every keyword can be written in English or Japanese, and contracts compile to bytecode for the Iroha Virtual Machine.

What is the Iroha Virtual Machine?

The IVM executes Kotodama bytecode deterministically: the same transaction on the same state gives the same result on every validator, whatever its hardware. Programs carry a cycle limit, and every call into the ledger passes a single, validated syscall gate.

Why is SORA Nexus suited to central bank digital currencies?

A central bank can run its currency in its own private data space, set account-level allowances and permissions as code, approve participating banks through governance and decide which proofs leave its domain, while still connecting to other institutions. It builds on Hyperledger Iroha’s experience with Bakong and CBDC proofs of concept.

How would cross-border settlement work?

An exchange between two currencies becomes one atomic transaction across two data spaces. Each data space checks and escrows its leg under its own rules, and the global chain commits both legs together or aborts both, so neither side settles alone.

Do institutions keep control of their data and currency?

Yes. That is the central design goal. Each data space keeps its own policies and private data, and an independently signed data-space root has its own state and local finality.

Is SORA Nexus live?

Not yet. Hyperledger Iroha 3 is in development, and the SORA Nexus architecture is being developed and validated. Contact us to discuss pilots and integration.

How does SORA Nexus relate to Hyperledger Iroha and Bakong?

SORAMITSU originally developed Hyperledger Iroha, which underpins Cambodia’s Bakong national payment system. SORA Nexus is built on Hyperledger Iroha 3, the next generation of that open-source technology.

Will SORA Nexus work with existing banking systems?

That is the intent. Work on established financial messaging, including ISO 20022, is intended to support integration with existing systems.

Work with us

Shape SORA Nexus with us

Central bank, financial institution or developer? Tell us what your infrastructure needs to make possible, or email service@soramitsu.co.jp.

By clicking Send you agree to our Terms and Conditions and Privacy Policy.