LogoLogo
  • Introduction
    • What is Arichain
    • Why Arichain
    • Vision: Redefining Layer 1, Empowering Every Builder.
    • TL;DR Summary for Builders
    • Details to read
  • Architectural Philosophy
    • Monolithic vs Modular: Why Multi-VM
    • Native Composability over Interoperability
    • Unified Chain State and Execution Environment
    • Chain Structure: Multi-VM under One Consensus
    • Identity & User Abstraction
  • General Architecture Overview
    • Multi-VM Execution Environment
    • Consensus Mechanism
    • Token Design
    • Unified Gas System
    • GAID: Global Account Identity
    • Future Roadmap
  • Technical Overview
    • Consensus Protocol Details
    • Token Design and Interoperability
    • Gas System Architecture
    • GAID Architecture
    • State Management
    • Bridge Infrastructure
  • Developer Experience
    • SDK
    • Developer tools
  • Validator
    • Validator Roles & Node Types
    • Reward System
    • Staking
    • Use Cases
    • Node Operations
  • Security
    • Design Goals
    • Threat Model and Risk Assessment
    • Continuous Security Verification
  • Token Economics & Validator Incentives
    • Token Utility
    • Validator Incentives
    • Token Supply and Distribution
    • Onboarding Workflow
  • Roadmap
Powered by GitBook
On this page
  1. Technical Overview

Bridge Infrastructure

Details are provisional and may be updated during development.

Arichain's bridge infrastructure enables native token (ARI) transfers between VMs and provides mirror token systems for cross-VM liquidity.

Native Token Bridge Architecture

Protocol-Level Native Token Bridge: Arichain's native token (ARI) bridge is built into the blockchain protocol itself, ensuring maximum security and seamless user experience:

Native Token Behavior:

  • In EVM: ARI behaves exactly like ETH (gas payments, smart contract interactions)

  • In SVM: ARI functions as the native token (transaction fees, program interactions)

  • Instant Transfers: Move ARI between VMs within a single block

  • Unified Balance: Users see total ARI balance across all VMs

Native Token Bridge Security Model:

Traditional Bridge:          Arichain Native Bridge:
┌─────────────┐             ┌──────────────────────┐
│ External    │             │ Protocol-Level       │
│ Validators  │             │ Validators           │
│ (Separate)  │             │ (Same as Consensus)  │
└─────────────┘             └──────────────────────┘
      │                              │
      ▼                              ▼
┌─────────────┐             ┌──────────────────────┐
│ Bridge      │             │ Multi-VM Consensus   │
│ Contracts   │             │ Engine               │
└─────────────┘             └──────────────────────┘
      │                              │
      ▼                              ▼
┌─────────────┐             ┌──────────────────────┐
│ Separate    │             │ Unified State        │
│ Security    │             │ Management           │
└─────────────┘             └──────────────────────┘

Mirror Token System for DEX Liquidity

Cross-VM Liquidity Challenge: ERC-20 and SPL tokens exist only within their respective VMs, creating liquidity fragmentation for DEX applications.

Arichain's Mirror Token Solution:

pub struct MirrorTokenManager {
    pub evm_token_registry: HashMap<TokenId, EVMTokenInfo>,
    pub svm_token_registry: HashMap<TokenId, SVMTokenInfo>,
    pub mirror_pairs: HashMap<TokenId, MirrorPair>,
    pub liquidity_pools: HashMap<PoolId, LiquidityPool>,
}

pub struct MirrorPair {
    pub original_vm: VMType,
    pub original_address: Vec<u8>,
    pub mirror_vm: VMType,
    pub mirror_address: Vec<u8>,
    pub total_locked: u128,
    pub total_mirrored: u128,
}

Mirror Token Lifecycle:

  1. Token Registration: Original token (ERC-20 or SPL) registers for mirroring

  2. Lock & Mint: Users lock original tokens, receive mirror tokens in target VM

  3. DEX Trading: Mirror tokens trade alongside native tokens in unified liquidity pools

  4. Redeem & Unlock: Users burn mirror tokens to unlock original tokens

Example: ERC-20 to SVM Mirror:

// Lock ERC-20 USDC in EVM
fn lock_erc20_for_mirror(token_address: [u8; 20], amount: u128, user_gaid: [u8; 32]) -> Result<MirrorReceipt> {
    // Lock tokens in EVM contract
    let lock_receipt = evm_lock_contract.lock_tokens(token_address, amount, user_gaid)?;
    
    // Mint mirror tokens in SVM
    let mirror_tokens = svm_mirror_program.mint_mirror_tokens(
        token_address,
        amount,
        user_gaid,
        lock_receipt.proof
    )?;
    
    Ok(MirrorReceipt {
        original_lock: lock_receipt,
        mirror_mint: mirror_tokens,
        redeemable_at: current_timestamp(),
    })
}

External Chain Bridge Strategy

Third-Party Bridge Integration: Arichain doesn't provide bridges to external chains directly. Instead, we enable specialized bridge builders to create secure connections:

For EVM-Compatible Chains (Ethereum, Polygon, BSC, etc.):

  • Bridge to Arichain EVM: Connect external EVM chains to Arichain's EVM environment

  • Leverage Existing Tools: Use familiar bridge infrastructure (LayerZero, Axelar, etc.)

  • Standard Interfaces: Implement Arichain's standard bridge interfaces for seamless integration

For Solana and SVM-Compatible Chains:

  • Bridge to Arichain SVM: Connect Solana ecosystem to Arichain's SVM environment

  • Wormhole Integration: Utilize Solana's mature cross-chain infrastructure

  • SPL Token Support: Direct bridging of SPL tokens to Arichain SVM

Bridge Security Features

Native Token Bridge Protection:

  • Consensus-Level Validation: Same validators secure native token transfers

  • Cryptographic Proofs: Mathematical verification of all bridge operations

  • Atomic Operations: Transfers complete fully or not at all

  • Emergency Pause: Governance can halt bridge operations if needed

Mirror Token Security:

  • Collateral Verification: All mirror tokens backed 1:1 by locked originals

  • Audit Trail: Complete history of lock/mint and burn/unlock operations

  • Liquidation Protection: Automatic liquidation if collateral ratio drops

  • Cross-VM State Sync: Real-time synchronization between original and mirror tokens

External Bridge Standards:

  • Security Audits: All external bridges must pass security audits

  • Insurance Requirements: Bridge operators must maintain insurance funds

  • Monitoring Integration: Real-time monitoring of bridge health and performance

  • Emergency Response: Coordinated response protocols for bridge incidents

This architecture ensures Arichain maintains security while enabling maximum flexibility for ecosystem development and external integrations.

PreviousState ManagementNextDeveloper Experience

Last updated 24 days ago