Architecture Overview

Vexidus is a Layer 1 blockchain built on eight integrated pillars. This page provides a high-level view of the system architecture, transaction lifecycle, and how the pillars compose.

The Eight Pillars

1. IntentVM (U.S. Patent App. 19/571,463) -- 1 intent, 1 signature, N operations. Declarative execution.
2. HyperSync Consensus + Vexcel -- Leader rotation with weighted selection, adaptive attestation DAG for global latency fairness, jailing, and reputation scoring.
3. VexBridge (U.S. Patent App. 63/987,929) -- Vaultless canonical token bridge using burn-and-mint and stateless/limbo resolution.
4. VSA v2 -- Smart accounts with Ed25519 + Dilithium3 dual-signature quantum hardening. Includes VNS (.vex name service) as an identity extension.
5. VexForge -- Ten token standards (VSC-7, VSC-8, VSC-20, VSC-21, VSC-55, VSC-88, VSC-99, VSC-LAUNCH, VSC-REP, VSC-SAFE) with protocol-level anti-rug protection, programmable staking pools, and on-chain DAOs.
6. VexiDEX -- Native on-chain AMM with constant-product pools and LP token management.
7. ElasticState -- Intelligent 3-tier storage engine (Hot/Warm/Cold) with automatic data lifecycle management.
8. Atomence (U.S. Patent App. 63/998,160) -- Cross-chain settlement layer. Market-maker matched exits back to origin chains without reverse bridging.

System Layers

+-----------------------------------------------------+
|            APPLICATION LAYER                         |
|  VexSpark | VexScan | VexForge | VexiDex | VexSwap  |
+-----------------------------------------------------+
|            API LAYER (JSON-RPC)                      |
|  100+ endpoints: vex_* (native) + eth_* (EVM compat) |
+-----------------------------------------------------+
|            EXECUTION LAYER                           |
|  IntentVM | VexForge | VexBridge | VexiDEX | VNS | Atomence | VIP |
+-----------------------------------------------------+
|            CONSENSUS LAYER (HyperSync + Vexcel)       |
|  Leader Rotation | Attestation DAG | Epoch Management |
+-----------------------------------------------------+
|            STATE LAYER (ElasticState)                 |
|  Hot (DashMap) -> Warm (LZ4) -> Cold (ZSTD) -> RocksDB |
|  StateMachine | WriteBatch Atomics | Checkpoints     |
+-----------------------------------------------------+
|            NETWORK LAYER (libp2p)                    |
|  QUIC | GossipSub | Dragonfly Stream | Bulk Sync     |
+-----------------------------------------------------+

Implementation

• Language: Rust -- 15 crates, memory-safe, zero-cost abstractions
• Database: RocksDB with atomic WriteBatch commits (crash-safe, no partial state)
• Storage: ElasticState 3-tier engine -- Hot (DashMap, <1us), Warm (RocksDB LZ4), Cold (RocksDB ZSTD). Zero-copy checkpoints every 1K blocks.
• Networking: libp2p with QUIC transport (TLS 1.3, multiplexing over UDP)
• State Root: LtHash homomorphic accumulator -- O(1) per write, Blake3 finalization once per block. Same approach as Solana SIMD-0215.
• Transaction Model: Account-based with bundle semantics (atomic multi-operation)

Transaction Lifecycle

Dragonfly Stream (direct delivery):

1. User submits bundle (signed Ed25519)
      |
2. RPC validates signature + format
      |
3. Validator creates PQ seal (Dilithium3 signature over blake3 commitment)
      |
4. Sealed bundle added to local LeaderBuffer + forwarded to seed peers
      |
5. Seeds relay to all connected validators via DragonflyRelay
      |
6. Elected leader drains LeaderBuffer, proposes block
      |
7. begin_block() -> execute bundles -> commit_block() (WriteBatch)
      |
8. recompute_state_root() -> flush()
      |
9. Block gossiped to peers -> verified -> finalized
      |
10. Explorer indexes updated (RocksDB "explorer" CF)

There is no gossip mempool. All transactions flow through the Dragonfly Stream sealed pipeline. PQ sealing is always on. See Dragonfly Stream for details.

Wallet Compatibility

Wallet	Status	RPC Layer	Signature
VexSpark (native)	Live	vex_*	Ed25519
MetaMask	Live	eth_*	secp256k1/ECDSA
Phantom	Planned	svm_*	Ed25519 (same curve)

One Ed25519 keypair works on both Vexidus and Solana. The same key generates three address formats (Vx0, 0x, base58) that all resolve to the same internal account.

How the Pillars Work Together

The eight pillars are not isolated features -- they compose:

Example: "Bridge 10 SOL from Solana and swap to VXS"

1. IntentVM parses the natural language into Goal::Composite([Bridge, Swap])
2. VexBridge verifies the SOL limbo proof (Tier 2 light client)
3. VexForge credits canonical SOL token to the user's account
4. VexiDEX routes the SOL to VXS swap through the best pool
5. VSA v2 verifies the single Ed25519 signature over the entire bundle (VNS resolves chris.vex to the user's address)
6. HyperSync includes the bundle in the next block (weighted leader selection)
7. ElasticState serves the user's account from the hot cache (<1us) -- no RocksDB lookup needed. The bridge proof is written through to warm tier for later archival.

All of this happens atomically -- one intent, one signature, one block slot. If any step fails, the entire operation rolls back.

Modules

Module	Purpose
Core Types	Primitives, 103 transaction operation types, addresses, signatures
State Machine	RocksDB-backed accounts, token registry, reputation, pools, validators
VXS Economics	Token constants, supply schedule, block rewards
HyperSync Consensus	Block production, finalization, Vexcel attestation DAG, voting, epoch management
RPC Server	JSON-RPC -- 100+ endpoints (vex_* + eth_* compatibility)
Node	Binary entry point -- genesis, P2P networking, block production
P2P Network	libp2p + QUIC transport, GossipSub, peer discovery
SDK	Wallet, validator, DEX client, intent parser, bundle builder
CLI	17 command groups, 95+ subcommands
Quantum Crypto	Ed25519 + Dilithium3 (post-quantum) keypairs
VexBridge	Cross-chain bridge -- deposit, withdraw, oracle verification
VexForge	Token validation (VSC-7, VSC-21, VSC-55 standards)
IntentVM	Intent-based execution engine (U.S. Patent App. 19/571,463)
ElasticState	3-tier hot/warm/cold state management
VIP	Vexidus Intent Programs -- declarative on-chain programs (no bytecode, no VM)
Atomence	Cross-chain settlement layer -- market-maker matched exits to origin chains

Network Parameters

Parameter	Value
Chain ID	1618032 (0x18b070)
Block time	~2s adaptive (500ms-12s range)
Max transactions/block	10,000 (configurable via --max-txs-per-block)
Transaction delivery	Dragonfly Stream (direct, PQ-sealed)
PQ seal algorithm	Dilithium3 (NIST Level 3) with Ed25519 classical fallback
Bundle TTL	120 seconds
P2P transport	QUIC (TLS 1.3 + multiplexing, UDP)
Gas price	10 nanoVXS/gas (configurable)
Auto-checkpoint interval	Every 1,000 blocks
Checkpoints retained	Last 5