Orbitum

Demo

About

The problem it solves **The Problem (Market Gap)** Indonesia has the largest Muslim market globally, yet retail access to high-yield (5%+), Shariah-compliant government bonds is restricted by high entry barriers and complex traditional brokerage processes. Yield Gap: 5% annual returns in Indonesia vs. 2-3% globally. Accessibility: Demand is 3x supply (Green Sukuk), yet retail investors are underserved. **The Solution (Orbitum on Base)** Orbitum tokenizes Indonesian Sovereign Funds and Sukuk on Base, lowering the investment threshold to as little as $500 for retail and $10,000 for HNWI. Base L2: Ensures transactions are fast and cost pennies, making micro-investments viable.  **Impact & Market Size** - AUM Goal: Targeting $600M AUM (1% of Indonesia’s $60B Sovereign Fund). - Scalability: Projected RWA market to exceed $10T by 2030; Orbitum positions Base as the home for Shariah-compliant RWAs. 

How it's made

Challenges we ran into Hurdle: On-chain vs Off-chain State Mismatch in Instant Buy & Sell One of the biggest hurdles we faced while building Orbitum was maintaining data consistency between on-chain logic and off-chain systems, especially for the instant buy & sell feature of tokenized bonds. Because bond pricing is governed by NAV management, the actual buy/sell price depends on: - On-chain state (token supply, allowlist status, transaction execution) - Off-chain data (updated NAV, bond parameters, indexer-derived state) During early testing, we encountered a state desynchronization bug where: - The smart contract executed a buy/sell correctly on-chain - But the off-chain system responsible for pricing and authorization was still using an outdated NAV or allowlist state This resulted in invalid EIP-712 signatures being generated, which caused transactions to revert on-chain due to mismatched parameters. How We Solved It We addressed this problem by improving both architecture and data flow: - Event-Driven Indexing We redesigned the indexer to rely strictly on on-chain events (buy, sell, NAV update, allowlist changes) as the single source of truth, instead of inferred or cached state. - Explicit NAV Versioning Each NAV update now carries a version / timestamp that is emitted on-chain and included in the EIP-712 signature payload, ensuring signatures are only valid for a specific NAV state. - Strict Allowlist Validation We enforced allowlist checks at both: - Smart contract level (hard enforcement) - Backend level (signature generation is blocked if the address is not allowlisted) - Backend Revalidation Before Signature Generation Before issuing an EIP-712 signature, the backend now re-validates: - Latest NAV version - Allowlist status - Contract configuration This ensures that every signature matches the current on-chain state at the moment of execution. Result After these changes: - Pricing became deterministic and consistent - Signature reverts caused by stale off-chain data were eliminated - The system became more resilient and auditable, which is crucial for a financial product like tokenized bonds This hurdle ultimately helped us design a more robust on-chain/off-chain synchronization model, which is now a core strength of Orbitum.