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

Token Design and Interoperability

Details are provisional and may be updated during development.

Arichain's token system provides native token bridge functionality through a unified registry.

Unified Token Architecture

The Multi-VM Token Challenge: Traditional multi-chain systems require external bridges that create:

  • Security Vulnerabilities: Third-party bridge operators can be compromised

  • Liquidity Fragmentation: Same asset exists as different tokens on different chains

  • User Experience Friction: Complex bridging processes and waiting times

  • Economic Inefficiency: Multiple token supplies and price discrepancies

Arichain's Solution: A single, protocol-level native token registry that maintains canonical state across all VMs:

Native Token Lifecycle Management:

  1. Registration: Native token (ARI) metadata recorded in global registry

  2. Multi-VM Deployment: Native token representation deployed to all VMs automatically

  3. Supply Synchronization: Real-time native token balance updates across all VM instances

  4. Multi-VM Transfers: Atomic native token operations without external dependencies

  5. Audit Trail: Complete native token transaction history across all environments

Global Native Token Registry

Registry Architecture:

Global Native Token Registry:
├── Native Token Metadata Store
│   ├── Token ID (ARI)
│   ├── Name & Symbol
│   ├── Decimals & Total Supply
│   ├── Supported VMs []
│   └── Creation Block Height
├── VM Instance Tracker
│   ├── EVM Native Representation
│   ├── SVM Native Representation
│   ├── Active Supply Per VM
│   └── Transfer Events Log
└── Native Token State Proofs
    ├── Merkle Proofs for Supply
    ├── Transfer Validation Proofs
    └── Integrity Check Results
PreviousConsensus Protocol DetailsNextGas System Architecture

Last updated 24 days ago