The problem Santara Terminal 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.

Challenges I 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).