VSA v2 -- Quantum-Hardened Smart Accounts

Dual-Signature Architecture

Every Vexidus account uses Ed25519 (classical, Solana-compatible) alongside Dilithium3 (NIST-approved post-quantum lattice-based signatures). This provides quantum resistance TODAY while maintaining compatibility with existing Ed25519 wallets.

Algorithm	Purpose	Security Level
Ed25519	Transaction signing, block proposing	Classical (Solana-compatible)
Dilithium3	Post-quantum signatures (dormant, ready for activation)	NIST Level 3 (quantum-safe)
Blake3	Hashing (state root, tx hash, address derivation)	256-bit (quantum-resistant)

Address Derivation (Same Key, Three Views)

Ed25519 Keypair -> pubkey (32 bytes)
  +---> Vx0:    SHA256(pubkey)[0..20] -> base58 -> "Vx0abc..."   (native)
  +---> 0x:     last 20 bytes -> "0x71C7..."                     (EVM/MetaMask)
  +---> base58: raw pubkey -> "7xKXtg..."                        (Solana/Phantom)
       All resolve to the same internal Address([u8; 32]).

Address Formats

Format	Example	Used By
Vx0 (native)	Vx0abc...xyz	VexSpark, native SDK
0x (EVM)	0x71C7...	MetaMask, eth_* RPC
System (32-byte hex)	0x000...0001	Genesis accounts, internal

Key Management

VSA v2 provides protocol-level key management without requiring smart contracts:

• AddKey -- Add Ed25519 or Dilithium3 key to your account
• RemoveKey -- Remove a key by hash (must keep at least one)
• RotateKey -- Atomic swap of one key for another
• Guardian recovery -- 3-of-5 trusted guardians can recover access (configurable threshold, timelock delay, cancelable)
• No seed phrase required for recovery (protocol-level, not a service)

All key management operations (disc 6-12) are defined in the protocol and live on testnet.

Pubkey Revelation

Accounts created by receiving transfers get a dummy public key. On first send, the wallet includes the real Ed25519 pubkey (sender_pubkey field on TransactionBundle). The protocol verifies SHA256(pubkey)[0..20] matches the address, registers the key, and proceeds -- seamless to the user.

Flow:

1. Wallet includes sender_pubkey: Some(ed25519_pubkey_bytes) on the TransactionBundle
2. Node verifies SHA256(pubkey)[0..20] matches the sender address [12..32]
3. Node verifies the Ed25519 signature against the provided pubkey
4. On success, the pubkey is registered in active_keys -- future sends do not need revelation

The native wallet VexSpark handles pubkey revelation automatically.

Guardian Recovery

Setup

Operation::SetRecovery {
    guardians: Vec<Address>,   // Up to 10 Vx0 addresses
    threshold: u8,             // M-of-N required
    timelock_secs: u64,        // Delay before finalization (recommended: 48-72 hours)
}

Recovery Flow

1. User loses all keys
2. Guardians initiate: M-of-N guardians submit InitiateRecovery with a new public key
3. Timelock starts: Stored in account.recovery_config.pending_recovery
4. Owner can cancel: If they regain access during timelock, submit CancelRecovery
5. After timelock: Anyone submits FinalizeRecovery -- replaces all account keys with the recovery key

Operations

Operation	Who Signs	What Happens
SetRecovery	Account owner	Configures guardians, threshold, timelock
InitiateRecovery	Guardian	Starts recovery with new pubkey, records guardian approval
CancelRecovery	Account owner	Cancels pending recovery
FinalizeRecovery	Anyone	After timelock, replaces keys. Requires threshold guardian approvals.

VNS -- Vexidus Name Service

VNS provides human-readable .vex names as an extension of the VSA identity system. Each .vex name IS a VSC-21 NFT -- ownership of the NFT IS name resolution. Transfer the NFT, transfer the name. No separate registry update needed.

• Register chris.vex -> mints NFT in global VNS collection -> stored as vns:chris in RocksDB
• Resolve chris.vex -> find the NFT -> the owner's address IS the resolved address
• Transfer uses existing TransferNft (disc 21) -- no new discriminant needed

Pricing

Name Length	Fee
3-4 characters	1,000 VXS
5-7 characters	100 VXS
8+ characters	10 VXS

Fees are credited to the Foundation (0x...01).

Validation

• 3-64 characters, alphanumeric + hyphen
• No leading/trailing hyphen
• Normalized to lowercase, .vex suffix stripped before storage

RPC Endpoints

Method	Description
vex_registerName	Register a .vex name
vex_resolveName	Resolve name to address
vex_reverseResolve	Address to name lookup
vex_getNameInfo	Full name details

IntentVM Composition

VNS names compose atomically with IntentVM -- "send 10 VXS to chris.vex and stake the rest" is one intent, one signature.

Quantum Migration Path

• Phase 1 (Now): Ed25519 only. Wallet SDK compatible (Phantom, MetaMask via bridge).
• Phase 2 (~2028): Users add Dilithium3 key alongside Ed25519 via AddKey. Either key signs. Address unchanged.
• Phase 3 (~2032+): High-value ops require Dilithium3. V0-only accounts get warnings.

The infrastructure is ready -- QuantumKeyPair::generate_post_quantum() works, verification handles both sig sizes. The proposer_signature_pq field is already on every block for future dual-sig enforcement.

Why Not ML-KEM?

Dilithium3 is a signature scheme; ML-KEM is a key encapsulation scheme. Blockchains need signatures. Vexidus uses Ed25519 for speed and compatibility, Dilithium3 for quantum hardening.