Inside Orbirium: The Three-Layer Architecture Behind the Game

Orbirium is a idle crafter & clicker game currently being developed by the ZkNoid team. While it looks and feels like a fast, responsive web2 game, it is actually powered by blockchain technologies under the hood. The architecture is designed to combine the best of both worlds: smooth gameplay for users and strong guarantees of data security and fairness.

At its core, Orbirium runs on three interconnected layers:

• Application Layer — includes a user-facing interface and multi-chain wallets. User interface updates instantly with every click, ensuring a seamless Web2-like experience. Multi-chain wallets ensure web3 user experience and onboarding capabilities.
• Sui Layer — the execution layer of the application. It records user actions once per Sui block (around every 2 seconds) and verifies the logic of the game.
• Zeko Layer — the settlement layer. It finalizes and secures all actions on a zk-based chain, providing cryptographic guarantees of integrity.

This layered design ensures that players get speed, reliability, and security all at once — something most blockchain games struggle to balance.

Application Layer

Multi-chain wallets

Orbirium’s cross-chain architecture supports Mina, Sui, and EVM-based networks by leveraging their respective frameworks. Below is a unified overview of the key toolkits used for dApp development:

• Mysten dApp Kit: A TypeScript SDK designed for building dApps on Sui. It offers React hooks, components, and utilities to simplify wallet integration and interactions with the blockchain.
• Reown AppKit: A toolkit for developing dApps with seamless onchain user experiences. It supports multiple blockchains (EVM, Solana, Bitcoin) and platforms, enabling efficient user onboarding through email, social login, and embedded wallets.
• Mina Signer: A Node.js SDK for Mina. It enables developers to sign strings, payments, and delegations using Mina’s key pairs across specified networks.
• Wagmi: A React Hooks library for Ethereum-based dApps, compatible with EVM chains. It simplifies wallet connections, smart contract interactions, and blockchain data access using TypeScript-friendly hooks, integrating with tools like WalletConnect, ethers.js, and viem.

This multi-chain wallet functionality enables smooth and seamless cross-chain interactions with core networks, enhancing the UX by allowing users to use their preferred wallets or onboarding options, such as email and social accounts. Additionally, this functionality allows the game engine to verify data and state simultaneously across different blockchains.

Front

The front layer of Orbirium behaves just like any traditional web2 application. Every click triggers an immediate update to the local game state, so players see results instantly. This approach is known as an optimistic UI: instead of waiting for blockchain confirmation, the game assumes the transaction will succeed and continues as if it already has.

All actions are later synchronized with the Sui chain. The only requirement is that every action performed locally must also be recorded on-chain in the same order and in the same quantity. In the rare case of a mismatch — for example, if a transaction fails or is dropped — the player’s progress simply reverts to match the current state of the Sui chain.

This design is what gives Orbirium its web2-like speed, making gameplay smooth and engaging while still being backed by blockchain security.

Sui Layer

On the Sui chain, Orbirium uses smart contracts to store and verify the game state for every player. Each player has three arrays, each containing 21 values — one for each crafting resource used to build black orbs (wood, stone, and so on).

• Resources — the current amount of each resource.
• Resources per Second (RPS) — the production rate of each resource.
• Storage — the storage capacity for each resource.

Rule Applications

Every action in the game — whether a simple click or an upgrade — is expressed as a rule. A rule is represented as the same three arrays, and applying a rule means summing these arrays with the player’s current state:

new_resources = resources + rule_resources
new_rps       = rps + rule_rps
new_storage   = storage + rule_storage

Example — Click Rule

[ 1, 0, 0, … ]   // resources (+1 wood)
[ 0, 0, 0, … ]   // rps
[ 0, 0, 0, … ]   // storage

This rule adds +1 wood (the first resource) while leaving RPS and storage unchanged.

Example — Upgrade Rule

[ 0, 0, 0, … , 1 ]   // +1 black orb
[ 0, 0.1, 0, … ]     // +0.1 stone per second
[ 0, 0, 0, … ]

This upgrade increases the number of black orbs and also boosts stone production by 0.1 per second.

Rule Protection

To prevent cheating, Orbirium enforces two protections on rules:

1. One-Time Upgrades — upgrade rules can only be applied once. The contract maintains a mapping of applied rules, marking each as true once used.
2. Admin-Signed Rules — every rule must be signed by the Orbirium admin. This prevents players from submitting arbitrary rules that would grant unlimited resources.

Zeko Layer

On Zeko, Orbirium uses contracts that mirror the Sui logic — every action is still applied as a rule summation. The difference is that these contracts are written as zkPrograms, so each action (click or upgrade) produces a zero-knowledge proof that it was computed correctly.

Why settle on Zeko?

Finalizing state on Zeko provides stronger security: instead of trusting a sequence of on-chain executions at face value, we verify them with zk proofs. This gives cryptographic assurance that user results are correct and tamper-resistant.

Over time, individual action proofs are merged using recursive proofs. This lets us compress many checks into one.

Quick example — “proofs of proofs”

• Suppose actions A₁, A₂, A₃ each produce proofs p₁, p₂, p₃.
• We create a new proof P₁₂ that verifies “p₁ and p₂ are both valid.”
• Then we create P that verifies “P₁₂ and p₃ are valid.”
• Now, verifying P is enough to trust all actions A₁..A₃.

Synchronizing with Sui

Periodically, Orbirium calls the Silvana API to:

1. Collect events from the Sui contract,
2. Generate a proof that these events occurred and were applied correctly,
3. Submit that proof to the Zeko zkApp.

This process transfers the game state from Sui to Zeko and solidifies user results under Zeko’s zk security guarantees.

Website | Docs | Twitter | Discord | Telegram | Medium