ONE WORLDONE ECONOMYONE LEDGER

Scroll to Explore

91%of 93 central banks surveyed by the BIS in 2024 were exploring a central bank digital currency (CBDC) for retail use, wholesale use, or both. BIS Papers No 159 · 2024 CBDC survey

Why now

Digital money is going sovereign. Payments cannot stay siloed.

Each jurisdiction needs control over its own money. Payments between those systems need a shared protocol that respects their different rules, private data, and validator networks. SORA Nexus brings those two needs together.

Sovereignty without silos.

Each institution can operate within a data space: an environment with its own policy and access rules. A common, programmable settlement layer connects these spaces, so authorized transactions can move across one logical ledger.

01 · Interoperability

Connect sovereign systems

Follow one illustrative exchange: an institution in one jurisdiction pays another for an asset. Each keeps its own rules and data. A shared protocol coordinates payment and delivery across their data spaces.

The questionHow do independent institutions settle one exchange?

Payment and asset delivery can settle together while each institution retains its own policy boundary.

Payments

ISO 20022 Gateway

Start with the payment messages institutions already use.

A payment enters Nexus through Torii, the Iroha interface for incoming requests. The gateway validates supported ISO 20022 messages, including pacs.008 and pacs.009, and maps them to ledger instructions under the applicable policy.

Inside the protocol

A pacs.002 status returns the outcome to the sender. This gives institutional systems a defined path from a familiar payment message to an authorized action on the shared ledger.

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.

Follow the transaction4 steps

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

Connect institutions while each keeps control of its rules and private data.

Once a request arrives, it must respect the institution responsible for it. A sovereign data space defines that boundary: its governance, validator committee, visibility rules, and conditions for accepting transactions.

Inside the protocol

Each space applies its own policy. For an authorized exchange between spaces, Nexus coordinates the required value, commitments, and proofs across one logical ledger while private transaction data stays within its boundary.

Local Policy

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

Defined Validator Committees

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.

Follow the transaction3 steps

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 payment and asset delivery so both settle together, even across different sovereign systems.

An atomic transaction (AMX) names every data space it touches and the state it will read or change. Each space prepares its part from a common snapshot. Nexus commits the change only when every required result is valid.

Inside the protocol

If any space cannot prepare or its evidence fails verification, the whole exchange aborts with no partial effects. Private spaces can supply commitments and proofs while keeping their transaction data local.

All or nothing

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

Explicit scope

The participating data spaces and intended reads and writes can be reviewed 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.

Two local changes become one shared outcome.

Follow the transaction5 steps

Declare both data spaces, read/write sets, and one authority-context snapshot.
Stage A₀ → A₁ and B₀ → B₁; both committees issue prepare quorum certificates (QCs).
Send both proofs to Nexus and wait until both spaces are prepared.
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 the exchange’s local obligations into settlement results that operators can reproduce and reconcile.

To reconcile the exchange, the settlement router calculates what is owed using exact quantity conversion, configured margins and haircuts, and reserve-buffer rules for each execution lane. The same inputs and rules always produce the same result.

Inside the protocol

Each block groups settlement by lane and data space, then records the resulting commitment and buffer state. Receipts and operational metrics give operators and auditors a common record to reconcile.

Canonical conversion

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

Reserve safeguards

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.

A reproducible obligation, a visible reserve state, and a receipt to reconcile.

Follow the transaction4 steps

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

Make every result verifiable

Now follow that exchange through execution. The network must process it consistently, govern the capacity it uses, and agree on a final result. The receiving institution needs evidence it can verify independently.

The questionHow can both sides trust the same final result?

Both sides can reconcile a committed result, and another system can verify its finality from a trusted starting point.

Engine

Hyperledger Iroha 3 Core

Give every participating validator the same rules for executing a transaction.

The exchanges described above need an engine that participants can verify. Hyperledger Iroha 3 provides it: Torii is the entry point for requests, Kotodama compiles programs, and the Iroha Virtual Machine (IVM) executes their logic deterministically.

Inside the protocol

Execution lanes process work in parallel. Sumeragi, the consensus mechanism, agrees on the result; Kura stores committed blocks. Together they preserve one ledger history as lanes are added or retired.

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.

Follow the transaction4 steps

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

Scale

Lanes + Merge Ledger

Process more work in parallel while keeping one ledger history.

As payment volume grows, independent workloads can enter separate execution lanes. Each lane processes its work and produces a commitment to the resulting state.

Inside the protocol

The merge ledger brings those commitments into one ordered history. Institutions can add execution capacity while their users and assets continue to share the same ledger.

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.

Follow the transaction3 steps

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

Adapt execution capacity to the institutions’ workload through a consensus-approved update.

An operator can add, replace, or retire a lane through an authorized, signed transaction. The plan is bound to the exact catalog and active lane instances the operator reviewed. Stale catalogs, invalid plans, and unauthorized requests leave the topology unchanged.

Inside the protocol

After consensus commits the update, every peer applies the same catalog, refreshes routing and limits, and reconciles storage. A lane cannot retire while certified work remains unmerged or unapplied.

Consensus controlled

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

Current-state checks

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

Coordinated cleanup

Routing, manifests, storage layout, data-availability state, and relay caches update together.

Scale

Runtime lane lifecycle

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

Capacity changes through one committed plan that every peer follows.

Follow the transaction4 steps

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

Turn parallel work into a committed result that validators agree on.

Sumeragi is the consensus mechanism that finalizes a proposed block. Validators certify it in two phases, Prepare and Commit. Each quorum certificate (QC) binds their votes to the exact block, its height, frozen validator roster, and state transition.

Inside the protocol

Validators validate and durably store the block before Prepare, save their lock before Commit, and persist the Commit QC decision before applying it. Conflicting votes are rejected and recorded as evidence; they never count 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.

Follow the transaction6 steps

The expected leader broadcasts a signed proposal and payload manifest.
Validators reconstruct, validate, and durably store the exact body.
Enough validators and voting power certify Prepare.
Validators persist the exact lock before releasing Commit votes.
A Commit quorum certificate finalizes that exact block.
The decision is persisted, the exact body is applied, and the next height opens.

Independent verification

Verifiable finality proofs

Give the receiving institution evidence that a transaction is final, verifiable from a trusted starting point.

A portable proof packages the canonical block header with the exact durable record of Sumeragi consensus. That record includes the frozen height context, certified block subject, execution commitment, commit quorum certificate (QC), and proofs of key possession aligned with the validator roster.

Inside the protocol

A receiving system checks how these records bind together, signer membership and order, validator key ownership, and the aggregate BLS signature. Both validator-count and voting-power thresholds must pass. Before accepting the first proof, it must also bind it to an independently trusted chain and context anchor.

Exact evidence

Preserve the certified subject, execution roots, commit certificate, frozen validator roster, and proofs of possession.

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.

Portable evidence connects one system’s final result to another system’s checks.

Follow the transaction4 steps

Assemble the header, certified subject, execution roots, commit certificate, frozen roster, and proofs of possession.
Seal the exact artifact into a portable Norito proof envelope.
Bind the proof to the expected chain and a separately trusted context anchor.
Check structural bindings, both quorum thresholds, signer order, key possession, and the aggregate BLS signature before accepting finality.

03 · Programmability

Put policy into action

The exchange also needs explicit terms. Define which accounts may act, encode payment and delivery conditions, and decide when authorized actions should run. Common records connect those rules to the applications around them.

The questionWho may act, on what terms, and under which limits?

Programs express the exchange terms; permissions define who can carry them out.

Contracts

Kotodama Programs

Express the rules of a market, payment, or application in code.

With a shared execution and finality model in place, teams can define application behavior. Kotodama is the language for writing programs that express market logic, payment conditions, and institutional policy.

Inside the protocol

The compiler translates those programs into Iroha Virtual Machine (IVM) bytecode. Validators execute the same logic within runtime limits and derive the same state transition.

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.

Follow the transaction3 steps

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

Build everyday asset flows from operations the ledger already understands.

Many application flows use the same basic actions: register an asset, mint units, transfer them, grant a permission, or burn supply. Iroha provides these as native, typed instructions.

Inside the protocol

Each instruction checks the required authority and policy. An ordered batch can stage several dependent actions and commit them together. If any instruction fails, every staged effect is discarded.

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.

Follow the transaction5 steps

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

Give each participant’s account precisely the authority it needs, for a defined period of time.

A capability manifest records what a universal account may do in one data space. It names the allowed programs, methods, assets, and optional role in an atomic transaction. Activation and expiry epochs define when that authority applies.

Inside the protocol

An optional maximum amount limits the current request. A successful grant also returns its allowance window as metadata. Matching deny rules take precedence, and operators can monitor activation, expiry, and revocation through lifecycle events.

Least privilege

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

Deterministic limits

Check the current amount against the configured ceiling and return the per-slot, per-minute, or per-day allowance window 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.

Every grant is tied to a specific account, action, and data space.

Follow the transaction4 steps

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

Run an authorized action when its registered event occurs.

Permissions define what an action may do; a trigger defines when it runs. Each trigger stores an executable, one event filter, its authority, and a repeat policy. The filter can match a schedule, an approved pipeline event such as an exact block height, a ledger data event, or an authorized by-call request.

Inside the protocol

When the filter matches, Iroha executes the action under the registered authority and normal executor policy. Permissions, repeat limits, fuel or cycles, gas, and execution depth bound the work. The recorded 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.

Follow the transaction5 steps

Select a trigger with a filter for one exact approved block.
The matching event loads its registered executable, authority, and remaining repeats.
Check the filter, enabled state, authority, and execution limits.
Stage the state change and consume one finite repeat on success.
TriggerCompleted records the trigger ID, execution hash, step, and outcome.

Codec

Norito Codec

Give every participant an unambiguous way to read the same data.

Programs, instructions, and proofs need a shared data format. Norito encodes typed values in a defined field order. A 40-byte NRT0 header identifies the version, expected schema, compression mode, length, checksum, and layout.

Inside the protocol

The reader checks these fields and the CRC64-XZ integrity checksum before reconstructing the value. With the same schema and explicit uncompressed layout, the same value produces the same bytes. Optional compression preserves decoded content; compressed bytes may differ between backends.

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.

Follow the transaction5 steps

Ordered fields serialize into one canonical payload.
Add the NRT0 header with schema, length, checksum, compression, and layout metadata.
The reader receives the header and payload in chunks.
Magic, version, layout flags, schema, declared length, and CRC64-XZ resolve in order.
Reconstruct the original typed value from the validated payload.

Ecosystem extension

SoraNet + SoraFS

Give applications a way to retrieve content and verify what arrived.

Applications also need data from outside a transaction. SoraNet carries the request: in strict relay mode, a blinded content request passes through entry, middle, and exit relays. SoraFS retrieves the content using a manifest that specifies its root, chunk order, length, and expected digests.

Inside the protocol

Provider chunks are checked before the content is reconstructed and returned with fetch evidence. An authorized ledger payment remains a separate action. These pieces can support software that requests a service, checks the delivered result, and pays 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.

Follow the transaction8 steps

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

Extend the economy to AI agents

The same exchange pattern could extend to a software agent buying compute or another service on an institution’s behalf. This is a future use case: people still define the accounts, permissions, and spending authority the agent may use.

The questionCould an authorized software agent participate?

A possible agent economy uses the same settlement building blocks, with authority assigned by people and institutions.

Future use case

A shared economy for AI agents

Future use case · Iroha provides the account, asset, policy, and settlement primitives. AI models run outside the protocol.

Extend the exchange pattern to a possible service economy: AI agents could pay for services under the same account, permission, and settlement rules.

Consider an institution authorizing an agent to buy compute from another provider. The agent would act through an ordinary key-controlled Iroha account. People and institutions would assign the roles, permissions, budgets, spending limits, and transaction authority it may use.

Inside the protocol

Authorized accounts can combine asset registration, minting, transfer, and exchange instructions. Those building blocks can represent compute credits, dataset access, model licences, storage capacity, energy units, task receipts, and digital output rights.

Kotodama programs running in the Iroha Virtual Machine (IVM), together with on-chain triggers, can automate payments, delivery conditions, recurring work, and receipts. An atomic transaction can make payment and asset delivery succeed or roll back together across data spaces. Canonical Norito records and Sumeragi finality can provide an auditable history of what was authorized and settled.

This is a future use case for Iroha’s economic, automation, and policy building blocks. 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 possible service economy built from accounts, assets, and human-defined rules.

Follow the transaction8 steps

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

Protect the data behind the transaction

Return to the original institutional exchange. The parties need evidence that the required checks passed, not unrestricted access to each other’s records. Protect the underlying data, admit approved proofs, and keep committed information recoverable.

The questionWhat must be proven, and what can remain private?

Participants can check the required evidence while protected state stays local and committed information remains recoverable.

Private evidence

FASTPQ Proof Pipeline

Check evidence of private execution while keeping its trace inside the data space.

Institutional payments and automated services can both involve sensitive activity. FASTPQ provides the proof pipeline for confidential execution: commitments to a private execution trace become proof inputs while the trace remains inside its data space.

Inside the protocol

The receiving side verifies the required evidence before deciding whether to admit the result. It can check that evidence without receiving the complete private trace.

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.

A private trace stays local; the receiving side checks its proof evidence.

Follow the transaction3 steps

A private execution trace stays inside its data space.
Publish a commitment and proof inputs while the trace stays local.
Verification resolves admission without revealing the trace.

Proof-gated policy

Privacy-proof admission

Require the approved evidence before a private transaction enters its execution queue.

A private exchange still needs verifiable evidence. Each lane manifest registers the privacy commitments approved for its workload, such as Merkle roots or proof descriptors. A transaction can attach evidence for that commitment while keeping the protected state out of the public flow.

Inside the protocol

Admission checks that evidence against the destination lane registry, then applies the lane compliance rule. A transaction that requires proof is rejected if its witness is missing, malformed, or tied 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.

Protected state stays local; admission depends on approved evidence.

Follow the transaction4 steps

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

Keep the data behind committed history available for recovery.

Verifying a result is one part of trust. The network also needs to recover the data behind its commitments after the transaction has finished.

Inside the protocol

Committed data is encoded into recoverable shards. Availability sampling checks whether pieces can be retrieved, and reconstruction uses the required threshold of shards to recover the original data.

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.

Follow the transaction3 steps

Committed data is encoded into recoverable shards.
Validators sample pieces to check availability, including when some shards are missing.
The remaining threshold reconstructs the original data.

Sovereign money. Permissioned software. One protocol.

Enter the Nexus

Start with the exchange your institution needs to make.

Evaluate the architecture, inspect the implementation, or discuss your use case with the SORA community.

01 · Architecture