Introduction to X3 Atomic Star
Relevant source files
The following files were used as context for generating this wiki page:
X3 Atomic Star is a Substrate-based blockchain architecture designed for high-survivability and native cross-VM (Virtual Machine) execution. It functions as a specialized infrastructure that enables atomic state transitions across three distinct execution domains: X3Native, X3Evm, and X3Svm. The system prioritizes technical dominance through verifiable benchmarks, deterministic replay, and a specialized settlement engine that enforces strict supply invariants across all internal routes.
Sources: README.md:3-5, X3_END_TO_END_GAPS_MASTER_PLAN.md:12-15, knowledge-audit-report.md:307-310
Core Architecture and Execution Domains
The architecture of X3 Atomic Star is built upon the Substrate framework, utilizing Aura for block production and GRANDPA for finality. The system's primary innovation is its tri-domain execution model, which allows for unified state management across different virtual machine environments.
Execution Tiers
The system partitions logic into three primary domains:
- X3Native: Handles native token transfers, staking, and core blockchain logic.
- X3Evm: Provides an Ethereum-compatible execution environment.
- X3Svm: Implements a Solana VM (SVM) compatible execution environment.
Sources: README.md:63-69, plans/PHASE_4_STRATEGIC_OVERVIEW.md:123-125
The Atomic Settlement Stack
The following diagram illustrates the high-level relationship between the consensus layer, the execution domains, and the cross-VM routing mechanism.
The diagram shows the flow of finalized blocks through the Atomic Kernel and Cross-VM Router to coordinate state across domains while the Supply Ledger enforces invariants.
Sources: README.md:63-74, X3_END_TO_END_GAPS_MASTER_PLAN.md:118-125
Cross-VM Routing and Supply Invariants
The Cross-VM Router manages a 6-route matrix that facilitates the movement of assets and state between the native, EVM, and SVM domains. To maintain economic integrity, the system enforces a strict supply invariant where the canonical_supply must always be greater than or equal to the represented_total.
Route Matrix and Invariants
The system defines specific internal routes and verification rules to prevent double-spending or supply inflation during cross-domain operations.
| Component | Responsibility | Enforcement Mechanism |
|---|---|---|
| Cross-VM Router | Dispatches messages across 6 internal routes | Replay protection and duplicate nonce rejection |
| Supply Ledger | Tracks total represented supply across all domains | check_invariant() calls on every supply change |
| Settlement Engine | Manages atomic state machine transitions | Automated refund paths for failed destination credits |
Sources: README.md:70-74, MAINNET_LAUNCH_CHECKLIST.md:46-67
Supply Formula
The canonical supply is calculated based on the following formula to ensure consistency across all balance buckets:
canonical_supply == native + evm + svm + external_locked + pending
Sources: knowledge-audit-report.md:275-279
Mainnet Launch and Security Hardening
The project utilizes a binary pass/fail checklist to track readiness for mainnet deployment. This process involves multiple phases of verification, ranging from local devnode testing to full 3-validator testnet performance audits.
Launch Readiness Phases
- Phase 1-3: Focuses on node binary stability, devnode block production, and 3-validator peered testnets.
- Phase 4-5: Validates Cross-VM transfer proofs and the implementation of the
pallet-x3-supply-ledgerinvariants. - Phase 6-12: Security hardening, audit closure (Certik, Trail of Bits), and the establishment of bug bounty programs.
Sources: MAINNET_LAUNCH_CHECKLIST.md:7-145, plans/PHASE_4_STRATEGIC_OVERVIEW.md:22-30
Genesis Ceremony Requirements
Before the "Genesis Ceremony" (the irreversible creation of the first block) can occur, several critical parameters must be locked:
- Chain ID: A unique numeric identifier.
- Supply Allocation: Sum of all allocated accounts must equal the
canonical_supply. - Governance Keys: Configuration of the emergency governance multisig (at least 3-of-5).
Sources: launch-gates/GENESIS_CEREMONY_CHECKLIST.md:16-52, MAINNET_LAUNCH_CHECKLIST.md:154-158
Security Enforcement Workflow
To prevent "agent cheating" or unauthorized state transitions, the project implements a surgical enforcement script (x3_enforce.py) that monitors for assertion weakening or consensus-path modifications.
The sequence diagram details the local enforcement path that protects consensus-critical code from unauthorized or unsafe modifications.
Sources: scripts_infrastructure/install_x3_enforcement.sh:163-220
Project Milestones and Roadmaps
X3 Atomic Star follows a strategic roadmap moving from Testnet Alpha to a public Mainnet Genesis launch.
| Quarter | Milestone | Key Deliverables |
|---|---|---|
| Q1 2024 | Testnet Alpha | Stellar Consensus implementation; 4,200 TPS benchmark |
| Q3 2024 | Testnet Beta | 1,847 Public validators; ZK bridge to Ethereum |
| Q1 2025 | Mainnet Genesis | 10,000 validators; TGE (Token Generation Event); All contracts live |
| Q3 2025 | Sharding | Horizontal sharding; Target 50,000 TPS |
Sources: production/public/x3star-mission-terminal.html:150-205
Conclusion
X3 Atomic Star represents a significant advancement in multi-VM blockchain architecture, providing a secure and verifiable foundation for decentralized execution. By enforcing strict supply invariants and utilizing a specialized Cross-VM Router, the system ensures that atomic state transitions remain consistent across X3Native, X3Evm, and X3Svm domains, even under hostile network conditions.
Sources: X3_END_TO_END_GAPS_MASTER_PLAN.md:12-25, README.md:63-74