Skip to main content

System Overview

Orbinum is a Substrate chain with two ways to hold value: public accounts, and a shielded pool of private notes. This page maps the parts and links to the page that owns each one.

The map​

PartWhat it doesOwner page
ChainProduces and finalizes blocks, holds accounts and balancesConsensus
Shielded poolHolds note commitments and nullifiers, checks every proof, credits spend feesPrivacy Architecture
EVMRuns Ethereum transactions and contracts; can shield into the poolEVM Compatibility
Wallet / appDerives keys, keeps notes, builds proofs, submits operationsKeys & Identity
IndexerServes the public feeds wallets scanNote Discovery

The chain​

The runtime is built on Substrate FRAME.

  • Block production and finality. Aura produces a block every 6 seconds; GRANDPA finalizes them, typically within about 12 seconds. The validator set is permissioned, up to 32 validators. See Consensus.
  • Accounts. Every account is a 32-byte AccountId32. sr25519, ECDSA (Ethereum) and ed25519 signers are accepted, ed25519 (Solana wallets included) only over a readable transaction text; an Ethereum address maps to a fixed AccountId32. See Accounts and EVM ↔ Substrate Mapping.
  • Fees. Substrate transaction fees are burned. Validators earn the spend fees of the shielded operations in their blocks and the priority tips of EVM transactions.
  • Proof verification. The runtime verifies Groth16 proofs through a native host function, so every node must run version 0.4.0 or later to import blocks.

The shielded pool​

The pool holds no balances. It holds notes: private records of value whose only on-chain trace is a commitment hash.

  • Notes, commitments and nullifiers. Creating a note inserts its commitment; spending it publishes a nullifier that cannot be linked back to the commitment. See Notes.

  • The Merkle forest. Commitments are leaves of depth-20 Merkle trees. A spend proves its note is in a tree by naming that tree's root, never the leaf. See The Merkle Forest.

  • Proofs. Every operation carries a Groth16 proof over BN254, checked against a verifying key stored on-chain by the zk-verifier pallet. Proofs are built on the user's device. See How Proofs Work and On-Chain Verification.

  • Operations.

    OperationOriginWho pays
    ShieldSigned by a public accountThe account pays normal gas or transaction fees
    Private transferUnsigned; authorized by its proofA spend fee taken from the spent notes
    UnshieldUnsigned; authorized by its proofA spend fee taken from the spent note

  • Spend fees. A transfer's or unshield's fee stays in the pool, credited to the validator that authored the block, which claims it later with a signed call. See Spend Fees.

  • Assets. One pool serves every asset, but only ORB (asset 0) moves through it today.

  • Validity. Every check a spend must pass, at pool admission and in the block, is listed in Spend Validity.

The EVM​

Frontier provides an Ethereum-compatible execution layer on the same chain and the same balances. Ethereum tools connect through the Ethereum JSON-RPC.

  • A transaction's priority tip goes to the validator that authored the block; the base fee is burned. block.coinbase is the zero address.
  • The shielded-pool precompile at 0x0000000000000000000000000000000000000801 exposes one function, shield. Every other selector reverts. Private transfers and unshields are not available from the EVM; they are unsigned Substrate extrinsics.

See EVM Compatibility and the shielded-pool precompile.

Off-chain readers​

Two off-chain parts read the chain. Neither can spend or censor a note.

The wallet (the app). It derives the private keys from a signature of the user's public wallet, keeps the user's notes encrypted on the device, builds Merkle paths and proofs locally, and submits operations to a node. Spends are submitted unsigned, so no account appears on them. See Keys & Identity and the Private Vault guides.

The indexer. It follows finalized blocks and republishes public pool data as feeds: commitments with their encrypted memos, spent nullifiers, and aligned leaf windows. Every wallet downloads the same feeds and filters them locally, so a read does not reveal which notes a wallet owns. See Note Discovery.

What each server learns from these reads is listed in Privacy Architecture.