Santara Protocol
Rupiah yield with real-time Indodax pricing
About
The problem it solves ### **The Problem: The "Rupiah-DeFi" Gap** For Indonesian users, participating in the Global DeFi ecosystem on Base Chain is currently fragmented, expensive, and technically intimidating. 1. **The "Double-Hop" Cost:** To convert ETH to spendable Rupiah, users typically must swap ETH USDC (paying swap fees & slippage), bridge to a CEX, and then sell USDC IDR (paying withdrawal fees). This erodes profit margins significantly. 2. **High Barrier to Entry (On-Ramp):** There is no direct, decentralized way to simulate local bank transfers to mint on-chain assets. Users are forced to rely entirely on centralized exchanges. 3. **Zero-Yield on Fiat:** Holding stablecoins often yields 0% unless deposited into high-risk protocols. There is no dedicated "Rupiah Savings Account" on-chain that offers sustainable yield. ### **The Santara Solution** Santara Protocol is the first end-to-end **Digital Rupiah Ecosystem** on Base Sepolia, designed to bridge the gap between traditional Indonesian banking and decentralized finance. **1. Direct Oracle Swap (The Engine)** We eliminated the need for USD intermediaries. Our custom **Oracle Node** fetches real-time ETH/IDR prices from **Indodax** and publishes them on-chain. * **Benefit:** Users swap **ETH directly to IDRX** at fair market rates with minimized slippage, bypassing the ETH USDC step entirely. **2. Fiat Settlement Gateway (The On-Ramp)** A simulated banking interface that bridges Web2 and Web3. * **Benefit:** Users can generate unique **Virtual Accounts (BCA/BRI/Mandiri)** and simulate direct Rupiah transfers. The smart contract validates these "deposits" to transfer IDRX directly to the user's wallet, creating a seamless onboarding experience. **3. NXS Yield Vault (The Savings)** A sustainable yield generation protocol for Rupiah holders. * **Benefit:** Users stake their IDRX tokens into the Vault to earn **Nexus (NXS)** rewards. We utilize an **Epoch-based distribution algorithm** that syncs with blockchain time, ensuring fair, auto-compounding yields similar to a high-interest time deposit (Deposito). **4. Treasury-Backed Redemption (The Off-Ramp)** A guaranteed exit strategy for yield farmers. * **Benefit:** The **Redemption Contract** is backed by a USDC Treasury. Users can burn their earned NXS tokens to receive USDC instantly at a transparent, **governance-adjustable on-chain rate** (e.g., 1 NXS = $0.02 USDC). This ensures that rewards always have tangible, realizable value while allowing the protocol to adapt to market conditions.
How it's made
Challenges we ran into ### 1. The "Stale Price" Dilemma (Oracle Security) Building a custom off-chain oracle introduced a critical risk: **availability**. If our Node.js bot were to crash, the Smart Contract would "freeze" on old prices, allowing arbitrageurs to drain the pool. **How I got over it:** I implemented a **"Heartbeat & Circuit Breaker"** pattern. The contract enforces a *MAX_DELAY* threshold (e.g., 1 hour). If *block.timestamp - lastPriceUpdate* exceeds this limit, the contract automatically **Reverts** any swap attempts. This ensures atomic safety: no fresh data, no execution. ### 2. Precision Loss in High-Denomination Fiat The Indonesian Rupiah (IDR) has a massive denomination (1 ETH ≈ 52,000,000 IDR). Combining this with Solidity's 18-decimal arithmetic often led to **precision loss** or **integer overflow** during rate calculation. **How I got over it:** I engineered a strict **"Multiply before Divide"** strategy in the Solidity math logic and implemented a unified *SCALE* constant (). This normalizes the raw integer feed from the Indodax API into 18-decimal precision before any division occurs, preserving significant figures down to the smallest Wei. ### 3. The "Lazy Reset" State Synchronization While building the **Fiat Settlement Gateway**, I encountered a logic mismatch between EVM storage and the UI. In Solidity, variables like *dailyLimit* don't automatically reset at midnight (00:00); they only update *lazily* when the next transaction occurs. This caused the Frontend to show "0 Quota Remaining" to users on a new day because it was reading the stale contract state. **How I got over it:** I implemented **Client-Side State Prediction**. Instead of relying solely on the raw contract return, the Frontend now subscribes to *useBlock* to get the latest block timestamp. * **Logic:** *if (currentBlockTime > lastResetTime + 24 hours) { return FULL_LIMIT; }* * This allows the UI to "anticipate" the contract's reset logic before the transaction is even sent, providing a correct and responsive UX. ### 4. Overcoming Regional Access Barriers (ISP Blocking) A unique challenge for the Indonesian market is that many ISPs block crypto-related domains (RPCs, Coinbase, etc.), causing the dApp to fail silently for local users. **How I got over it:** I built a custom **"Connectivity Guard"** component (*IndoAlert*). Instead of letting the app crash, it detects specific network error codes related to DNS resolution failure. It then triggers a non-intrusive system notification guiding users to switch to **Cloudflare DNS (1.1.1.1)** or enable a VPN, ensuring inclusivity for non-technical users in restricted regions.