Skip to main content

System Overview

Orbinum is a privacy-focused blockchain that combines Zero-Knowledge cryptography with full Ethereum compatibility. Built on Substrate's FRAME framework with Frontier integration, it enables confidential transactions while maintaining interoperability with the Ethereum ecosystem.

The Privacy-Transparency Paradox

Traditional blockchains expose all transaction details on-chain, creating permanent public records that can be analyzed, traced, and linked across time. While transparency is essential for distributed consensus, it conflicts with the growing demand for financial privacy in institutional and personal use cases.

At its core, Orbinum addresses this fundamental tension by embedding privacy at the protocol level through cryptographic commitments and zero-knowledge proofs, allowing users to transact confidentially while maintaining the verifiability and integrity that blockchains provide.

Architecture Overview​

The architecture is built on a foundation of modular layers, each serving a distinct purpose while working together to enable both private and public computation. Understanding how these layers interact reveals how Orbinum achieves its dual mandate of privacy and programmability.

The application layer sits at the top, providing multiple interfaces for interaction. Developers can work with native Substrate APIs when building privacy-focused applications, or use familiar Ethereum JSON-RPC endpoints when deploying smart contracts. This dual-interface approach recognizes that privacy and programmability serve different use cases, and both deserve first-class support in the architecture. The SDK & Developer Tools section details the tooling available for both approaches.

Dual Execution Environments

The runtime is split into distinct execution environments that operate on the same state but follow different rules. This separation allows privacy operations and smart contract execution to coexist without compromising either.

Beneath this interface layer lives the runtime—the heart of the blockchain where all computation happens. The privacy runtime handles confidential transactions through a UTXO-based model inspired by Zcash Sapling, where value is represented by cryptographic commitments stored in a Merkle tree. When users want to transact privately, they interact with the shielded pool, generating zero-knowledge proofs that validate the transaction without revealing its details. The Privacy Architecture section explores this model in depth, explaining how commitments, nullifiers, and Merkle proofs work together to create a system where privacy is the default, not an afterthought.

Running parallel to the privacy runtime is the EVM runtime, which provides full Ethereum compatibility through Frontier. This isn't a compromise or a second-class feature—it's a deliberate architectural choice that recognizes the value of the existing Ethereum ecosystem. Smart contracts written in Solidity deploy without modification, standard precompiles work as expected, and tools like MetaMask, Hardhat, and Remix integrate seamlessly. The EVM Compatibility section details how this integration works, including the account mapping strategy that unifies Substrate and Ethereum address spaces.

Consensus Independence

Block production and finality operate independently of whether a transaction is private or public. This separation ensures consistent performance regardless of transaction type.

The consensus layer operates independently of whether a transaction is private or public. Block production follows Aura's time-based authority rotation with six-second intervals, while GRANDPA provides deterministic finality in approximately twelve seconds. This separation between block production and finality allows the network to continue making progress even during temporary network partitions, ensuring both liveness and safety. The Consensus documentation explains these mechanisms and their trade-offs in detail.

Supporting all of this is the cryptographic foundation that makes privacy possible. Zero-knowledge proofs in Orbinum use Groth16 over the BN254 curve, chosen for its compact proof size and fast verification time. The Poseidon hash function, optimized for use in zero-knowledge circuits, provides the cryptographic commitments that hide transaction details while remaining verifiable. These aren't abstract concepts—they're concrete implementations that power every private transaction on the network.

Privacy​

The shielded pool represents Orbinum's approach to private value transfer. Unlike account-based models where balances are visible on-chain, the shielded pool uses a UTXO model where value exists as cryptographic commitments. When you shield assets, you're creating a note—an off-chain data structure containing an amount, asset identifier, owner public key, and random blinding factor.

How a private transaction flows through the system:

Your note sits in the same Merkle tree as everyone else's notes, indistinguishable from hundreds of thousands of other commitments. Observers can see that some note was consumed and some new notes were created, but cannot determine ownership or link inputs to outputs. The proof reveals a nullifier—a unique value derived from the commitment and your spending key—which prevents the same note from being spent twice. This nullifier is publicly recorded on-chain, but it cannot be linked back to the original commitment without knowledge of the spending key.

Multi-Asset Privacy​

Privacy becomes more powerful when it extends beyond a single asset type. Orbinum's shielded pool supports any registered fungible asset, and critically, all asset types share the same Merkle tree.

Design ChoicePrivacy Impact
Separate trees per assetObservers narrow anonymity set by asset type. A 100 ORB transaction is distinguishable from a 50 USDT transaction.
Unified tree (Orbinum's approach)All commitments are indistinguishable 32-byte hashes. Full transaction set becomes the anonymity set, regardless of asset.

The asset type information is only revealed within the zero-knowledge proof itself, which is validated without exposing the underlying data. Asset registration and management happen through the core runtime, separate from the shielded pool itself. This separation maintains clean boundaries between privacy mechanisms and asset governance, allowing new assets to be added or verified without modifying the underlying privacy infrastructure.

Explore the privacy implications of this design in the Privacy Architecture documentation.

Node Operations​

Running a node on Orbinum involves participating in both consensus and state synchronization. The network supports different node types depending on your needs:

  • Validator Nodes: Produce blocks and vote on finality. Active participants in consensus with staking requirements.
  • Full Nodes: Maintain complete state and serve RPC requests. Essential for dApps and explorers.
  • Light Clients: Supported through Substrate's runtime-agnostic design, though privacy operations require additional consideration around proof generation and Merkle path retrieval.

Network parameters reflect intentional trade-offs between performance, security, and usability:

  • Merkle tree depth: 20 levels → ~1 million note capacity
  • Block time: 6 seconds → balance between latency and network efficiency
  • Finality: ~12 seconds → deterministic settlement via GRANDPA

These aren't arbitrary choices; they directly shape how the network functions in production.

Developer Experience​

Building on Orbinum requires understanding both its privacy mechanisms and its Ethereum compatibility layer. The approach differs based on what you're building:

Privacy-Focused Applications
Work with the shielded pool through extrinsics that handle shield, transfer, and unshield operations. Rather than requiring every application to implement proof generation and note management from scratch, the SDK provides high-level abstractions that handle the complexity. Applications request operations by providing transaction parameters, and the SDK manages witness generation, proof creation, and submission.

Ethereum-Compatible Applications
The development experience mirrors what you already know from other EVM chains:

  1. Deploy contracts → Remix or Hardhat
  2. Interact with contracts → Web3.js or ethers.js
  3. Connect users → MetaMask or WalletConnect

The EVM runtime handles execution identically to other Ethereum-compatible chains, with the added option of integrating privacy operations through cross-layer messaging.

Implementation Status and Future Direction​

As of February 2026, Orbinum has implemented core confidential transaction functionality, multi-asset privacy support, full EVM compatibility, and consensus through Aura and GRANDPA. The shielded pool operates with shield, private transfer, and unshield operations, and the Merkle tree maintains a unified anonymity set across asset types.

Development continues on selective disclosure circuits that will enable compliance features like range proofs and audit trails without compromising privacy for normal operations. The architecture described here isn't static. Substrate's modular design allows runtime upgrades without hard forks, meaning the protocol can evolve as cryptographic techniques advance and new use cases emerge. The goal is not to create a perfect system frozen in time, but to build a foundation flexible enough to adapt while maintaining the core privacy guarantees that define Orbinum's purpose.

Learn More​