Combining scalability, low fees and isolation between virtual chains with a first-grade developer experience, online IDE and smart contracts in familiar languages, Orbs provides developers the perfect mix of performance, cost, security and ease of use.

General Overview

Orbs is a public blockchain infrastructure designed for mass usage applications and close integration with EVM-based L1’s such as Ethereum and Binance SmartChain. Unlike private and permissioned blockchain solutions typically used for such applications, the Orbs infrastructure is open and permissionless. The Orbs protocol is decentralized and executed by a public network of permissionless validators using Proof-of-Stake (PoS) consensus.

The Orbs protocol relies on the ORBS token, which is used for the settlement of fees related to app execution and provides the system of incentives used to elect validators (who are referred to as “Guardians”) in a secure and decentralized manner.

Layer 3 Infrastructure

Orbs’ unique features designed for interoperability with EVM-compatible blockchains, together with its decentralized network of nodes, allow it to be set up as a separate L-3 execution layer operating to enhance the capabilities of EVM smart contracts. By working in conjunction with other L1 and L2 solutions as part of a tiered blockchain stack, Orbs opens up a whole new spectrum of possibilities for DeFi, NFT, Metaverse and GameFi.

Learn more here.


The Orbs platform is a decentralized serverless cloud allowing developers to build backend services (applications) that are then deployed to be executed by Orbs Guardians. The main offerings of the platform include compute under consensus (execution of “smart contracts”) and storage under consensus.

Applications running on public blockchain are unique in their ability to facilitate trust by providing blockchain-backed guarantees to their users. Whereas many popular public blockchain solutions like Ethereum are designed primarily for purely decentralized applications (dapps), Orbs expands the offerings of public blockchains by also supporting permissioned applications developed by existing for-profit businesses. The Orbs project is currently focused primarily on DeFi applications, where Orbs’ independent consensus layer can be used to enrich DeFi contracts on EVM-based L1’s such as Ethereum - where most existing liquidity in DeFi resides. For example, consider an EVM-based DeFi vault where external Guardians act as oracles over EVM data and allow EVM contracts to make external decisions that are impossible to implement in the EVM alone.


The Orbs project includes a full blockchain stack designed and implemented from scratch by the core team, and is not a fork of any existing solution. The project is active on open source with about 150 repositories publicly available on Github. The codebase provides an end-to-end developer experience with everything needed to create and execute blockchain applications including:

  • grid image

    Microservice implementation of the node core

  • grid image

    Consensus algorithm

  • grid image

    Smart contract SDKs for building backends in multiple languages

  • grid image

    Layer 3 architecture

  • grid image

    Local development server (Gamma)

  • grid image

    Block explorer (Prism)

  • grid image

    Client SDKs for building web and mobile frontends in multiple languages, and more

  • grid image

    Multi-chain staking

Virtual Chains

Every application running on Orbs typically runs on its own virtual chain. Virtualization provides applications with an isolated environment while utilizing a shared physical infrastructure of nodes. Each virtual chain maintains its own separate chain of blocks, state, and runs its own concurrent instance of consensus. All Orbs validators run all virtual chains in parallel, making the permissionless pool of validators completely shared and staked across the full network. This provides applications with the security and decentralization of the entire network while maintaining a strong degree of independence.

Consensus on transactions of different virtual chains can be run independently and are run concurrently on separate resources. The ledgers of virtual chains can also be maintained independently and their compute can be performed in parallel. Moreover, the isolation of state for each virtual chain reduces the memory requirements of the network’s virtual machine.

More on Virtual Chains

Virtual chains provide the feel and benefit of a dedicated blockchain while running on top of a shared physical node infrastructure, enjoying the security and decentralization provided by the shared environment as well as the isolation and customization provided by virtualization.


  • Each application operates its own virtual chain
  • App developers choose their virtual chain’s consensus protocol and governance model
  • Autonomous governance and flexibility
  • Isolation from congestion in other virtual chains
  • Ability to start with a private instance and later switch to public without having to migrate blockchains

    Every virtual chain is allocated separate computing, storage and consensus resources providing a guaranteed SLA to its users. Congestion in one virtual chain does not propagate to other virtual chains, making performance predictable and reliable. Resource isolation also prevents fee surges resulting from competition for network resources between applications and enables a predictable fee model absent from most shared-resources blockchains.

    box image

    Isolation between virtual chains allows each app to make its own protocol governance decisions, such as fixing a vulnerability in a deployed smart contract or customizing a protocol parameter like its consensus block rate. This provides applications with the stability lacking in shared infrastructure solutions and reduces protocol forks as interests are less likely to conflict. Applications are also no longer at risk of having their block history reverted due to a network-wide decision such as The DAO fork or prevented from deploying a fix like with the Parity bug.

    box image

    The parallel and concurrent operation of different virtual chains results in virtual separation, as smart contracts are likely to interact mostly with smart contracts deployed on the same virtual chain. When a new virtual chain is created, Orbs validators dynamically allocate more resources for its execution (eg. instantiate a new AWS machine in the node cluster) allowing for a virtually limitless number of virtual chains to run on the network in parallel.

    box image

Cross-chain Interoperability

Orbs smart contracts provide seamless cross-chain access to Ethereum state under consensus, thus allowing applications to read the Ethereum state directly using the above mechanism. This allows applications running on Orbs to leverage the power of Ethereum directly without leaving the platform. An example of this technology is autonomous swap, a secure mechanism that allows developers to move part of the base-layer assets (ex: ERC-20 tokens) to run on Orbs for their utility while keeping other parts on the base-layer for trade.

More on Cross-chain Interoperability

As blockchain development becomes mainstream, platforms must offer a lower barrier to entry for blockchain developers to remain competitive.

  • grid image

    Avoid painful token migrations when moving between blockchains

  • grid image

    Developers can use their base-layer’s token ecosystem (wallets and exchanges)

  • grid image

    Tokens can be kept on a Proof-of-Work (PoW) base-layer for added security without the performance and cost drawbacks

  • grid image

    Take advantage of the liquidity of the base-layer while using Orbs’ scalable production environment


    Orbs pioneers the paradigm of smart contracts as a library in any language, like Go and JavaScript, instead of dedicated languages like Solidity. This flexibility allows existing teams to transition to blockchain development and existing tools and libraries to be reused. Smart contracts are deployed on-chain as source code, making them easier to read and thus safer, and compiled locally on-demand by validators. Implementation challenges include efficient sandboxing and dealing with non deterministic outputs that cannot undergo consensus.

    box image

    Since execution engines of standard languages are not deterministic in nature (eg. heap addresses), dealing with non-determinism is a core requirement of the platform. Starting from fail-safe mechanisms in the consensus algorithm itself for failing transactions where consensus is impossible, to APIs defining acceptable thresholds for consensus when the results for each validator differ (while storing each validator’s result for future audit), the Orbs Network employs a variety of methods for solving these issues.

    box image

    Providing non-determinism as a feature opens up new use cases for smart contracts such as accessing web oracles and off-chain data that isn’t straightforward to access under consensus. The benefits are clear, as many real-world applications require the ability to interoperate with existing systems or databases that are not on-chain. Native support for direct query of external data by validator nodes makes reliance on dedicated oracle nodes, that often become the weak links in the system, obsolete.

    box image

orbs Smart Contracts Overview

We use cookies to ensure that we give you the best experience on our website. By continuing to use our site, you accept our cookie policy.