ONE WORLD
ONE ECONOMY
ONE LEDGER

Under the hood SORA Nexus is one big shared state machine. Hyperledger Iroha v3 defines the rules for how that state can change, so that if two honest validators see the same inputs in the same order, they always compute exactly the same result.

The Iroha Virtual Machine (IVM) is the calculator that applies those rules. It runs small programs and turns their effects into simple, well-defined updates to accounts, assets, and other on-chain objects.

Instead of letting programs poke at raw bytes, IVM uses typed pointers for things like accounts, assets, and data spaces. If a program tries to use an invalid pointer, execution stops in a clean, predictable way rather than corrupting state.

The VM avoids sources of disagreement: no floating-point arithmetic, no “read the local clock” syscalls, and no hidden side effects. Optional GPU or SIMD acceleration is allowed, but it must produce exactly the same answer, bit-for-bit, as the scalar CPU path.

Every execution can produce receipts and Merkle hashes that tie it back to the underlying state. This makes it possible to replay and audit what happened long after the fact, which is critical for regulated deployments.

Cryptography choices, allowed syscalls, and admission rules are all driven by configuration that is itself governed on-chain. Upgrades mean changing configuration and binaries in a controlled way, not spinning up a new forked chain.

Iroha Special Instructions (ISIs) are the verbs of the system: create an account, mint or burn an asset, transfer value between accounts, grant or revoke a permission, and so on.

Every transaction is simply an ordered list of ISIs. Validators check that each instruction is authorised and well-formed, then apply them one by one to update the world state.

Because ISIs are defined once in the protocol and reused everywhere, applications do not need to re-implement the same logic in custom contract code. That removes a whole class of subtle bugs where two teams interpret a rule slightly differently.

From a mathematical point of view, you can think of the instruction set as a small, controlled collection of transformations. All allowed state changes are built by combining these basic moves in different sequences.

For operators and auditors this makes reasoning far easier: instead of reading thousands of lines of ad-hoc smart contract code, they can look at a short list of well-specified instructions and see exactly what a transaction does.

Kotodama is the high-level language for writing smart contracts on SORA Nexus. Developers write normal, structured code; the Kotodama compiler turns it into IVM bytecode files (.to) that validators can execute.

Each compiled Kotodama artifact carries a header that describes which ABI version it expects, which syscalls it may use, and an upper bound on how many VM cycles it is allowed to consume. Validators check this header before the program ever runs.

Inputs arrive as Norito envelopes and are exposed to programs via typed pointers rather than raw memory. That prevents common bugs such as treating an account ID as an amount, or mis-parsing an arbitrary byte blob as a valid proof.

When a Kotodama program needs to interact with the host, it uses explicit, numbered syscalls. If the program calls a syscall that is not supported in the current runtime, the call simply fails in a deterministic way instead of falling back to legacy or undefined behaviour.

The combination of a high-level language, declarative headers, and a deterministic VM gives both builders and regulators strong guarantees. If needed, execution traces can be tied back to Merkle-backed receipts and examined down to the register level.

SORA Nexus presents itself as one global ledger, but different organisations and jurisdictions often need to keep their data separate. Data spaces are how the ledger gives each of them their own “room” while still staying on a single network.

A data space is a first-class partition of the ledger with its own policies, validator set, and routing rules. Private data spaces are permissioned: only authorised participants can see the contents, while still sharing the same underlying engine and unified address space.

Public data spaces are open to anyone, but they follow the same deterministic scheduling and data-availability rules. This allows open innovation without sacrificing predictable performance or auditability.

Every data space emits a compact summary each slot: state roots, data-availability commitments, and (for private spaces) attestation certificates. Gateways read a shared directory so they can route user requests to the correct data space without guessing.

When one data space needs to interact with another, the call is explicit and governed. Policies decide what information can cross the boundary, and hashes and proofs let one space trust the outcome of another without seeing raw private transactions.

The SORA Parliament is the on-chain governance system that steers parameters, data spaces, and runtime upgrades for the network. It is organized into multiple bodies populated by sortition-chosen SORA Citizens.

Proposals originate from the Rules Committee or Monetary Policy Committee (MPC). The Agenda Council filters these proposals to ensure they meet established rules. Accepted proposals are studied by volunteer Interest Panels, whose findings are collated by a Review Panel.

The final decision is made by a Policy Jury—a randomly selected, one-time panel. All rule changes, proposals, and punishments must be ratified by a Policy Jury. The Oversight Council monitors the entire process for violations, while the Financial Markets Authority (FMA) regulates financial markets and Polkaswap.

Votes use zero knowledge to protect the identities of the voters. Once a proposal reaches its quorum and approval threshold, its effect is scheduled for a specific future slot.

Because proposals, votes, and enactment records are all stored in Kura, anyone can replay the full history of governance and answer questions like “when did this parameter change, and how was it voted on?” instead of relying on off-chain minutes or wikis.

FASTPQ is the zero-knowledge STARK proof system used by SORA Nexus. A FASTPQ proof is a small piece of data that convinces everyone that a whole data space followed its rules correctly, without them having to re-run the computation or see the underlying transactions.

To build a proof, a data space encodes its rules as a large table of numbers called a trace. Each row describes one tiny step of the state transition. The prover shows that all rows in this table satisfy the rules indirectly, by committing to a collection of polynomials derived from that table.

Instead of sending the entire table, FASTPQ sends Merkle commitments to these polynomials and then answers a handful of randomly chosen spot checks from the verifier. If any rule was broken, the chance that all of these random checks still pass is extremely small.

In numbers: with the parameter choices in the whitepaper, the probability that a dishonest prover can cheat without being caught is about 2⁻¹²⁸. Even if an attacker tried billions of times per second, they would be vanishingly unlikely to succeed within the lifetime of the universe.

Each data space produces its own FASTPQ proof. Lane committees aggregate these into at most two proofs per slot — one for public data spaces and one for private ones — so that verification work per lane stays within a tightly-bounded time budget.

FASTPQ uses standard STARK ingredients such as hash-based commitments and the DEEP-FRI protocol, but all parameters are fixed and published through governance. Anyone can verify proofs using only public information and the same Norito-encoded envelopes that consensus already understands.