Santara Terminal

Demo

About

The problem it solves **Santara Terminal** acts as a unified liquidity gateway designed to solve the fragmentation of assets between the emerging **Lisk (Layer 2)** ecosystem, other L2s like **Base**, and the foundational **Ethereum (Layer 1)**. As the L2 landscape expands, moving assets often becomes a friction point. Users face fragmented liquidity and complex bridging processes when trying to move between Optimism-based chains (Lisk, Base) and the main settlement layer (Ethereum). **Santara Terminal** unifies these layers into a single **"Multi-Layer Terminal"**, positioning **Lisk Sepolia** as the liquidity hub. **Key Solutions:** 1. **Multi-Layer Interoperability (L2 <-> L2 <-> L1):** We implement a secure "Lock-and-Mint" and "Burn-and-Release" mechanism connecting three distinct layers: * **Lisk Sepolia (L2):** Acts as the **Home Chain (Origin)** for native assets. * **Base Sepolia (L2):** Demonstrates seamless L2-to-L2 bridging. * **Ethereum Sepolia (L1):** Demonstrates L2-to-L1 settlement and liquidity flow. This ensures verifiable 1:1 asset pegging across the entire stack. 2. **Hybrid Smart Contract Architecture:** We solve the dilemma of flexibility vs stability by employing a hybrid model: * **SAN Ecosystem:** Utilizes **OpenZeppelin Transparent Proxies** (Upgradeable). This allows us to upgrade bridge logic on Lisk without migrating liquidity. * **SIDR (Stablecoin) Ecosystem:** Utilizes **Immutable Standard Contracts**. This guarantees trust and stability for fiat-pegged assets. 3. **Integrated Liquidity (DEX):** Users don't just bridge; they can trade immediately. We deployed **Santara DEX** (AMM) on all connected chains, facilitating instant arbitrage and liquidity provision between Lisk L2 and the broader Ethereum ecosystem. 4. **Relayer Security:** We address the "hot wallet" vulnerability common in bridges. Our custom Relayer uses **Web3 Secret Storage Definition V3** (Encrypted Keystore) running inside a hardened **Docker** container with **PM2**, ensuring keys are never exposed in plain text.

How it's made

Challenges we ran into Building a bridge that connects L1 and L2 infrastructure came with specific technical hurdles: **1. The "Fresh Deploy" vs. "Upgrade" Dilemma** * **Challenge:** We wanted to use an Upgradeable Proxy pattern for the SAN Vault to allow future fee adjustments. However, initializing a proxy usually sets values to zero. We needed a V2 contract (with Fee logic) to be the "Genesis" deployment. * **Solution:** We customized the *initialize* function in our V2 implementation to accept specific arguments (Fee & Token Address) during the proxy creation. This allowed us to perform a "Direct V2 Deployment" using Hardhat Upgrades, ensuring the system was production-ready from block 0. **2. Docker Permission & Keystore Management** * **Challenge:** Our Relayer runs on Docker for stability. Initially, mounting the keystore volume (-v) caused *EACCES* (Permission Denied) errors because the container user lacked read access to host files. * **Solution:** We shifted to a "Secure Build" strategy. We created a *setup-keys.js* script that generates encrypted JSON keystores and places them in a dedicated directory. The Dockerfile then **COPIES** these keys into the image during the build process, and we use **PM2** for robust process management inside the container. **3. Hybrid Contract Standards** * **Challenge:** Managing two different standards (Upgradeable for SAN, Immutable for SIDR) in a single frontend codebase was complex. * **Solution:** We standardized the ABI interaction in the frontend while keeping deployment scripts separate. This creates a uniform UI experience for users, even though the underlying asset logic differs (Mutable vs Immutable).