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 32-byte account address.

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 are defined natively in the protocol and live on testnet.

Pubkey Revelation

Accounts created by receiving transfers get a placeholder public key. On first send, the wallet includes the real Ed25519 public key alongside the signed bundle. The protocol verifies the key hashes to the account address, registers it, and proceeds -- seamless to the user.

Flow:

1. The wallet includes the sender's Ed25519 public key with the signed bundle
2. The network confirms the public key hashes to the sender's address
3. The network verifies the Ed25519 signature against the provided public key
4. On success, the public key is registered for the account -- future sends do not need revelation

The native wallet VexSpark handles pubkey revelation automatically.

Guardian Recovery

Setup

An account owner configures recovery with a SetRecovery operation that specifies:

• Guardians -- up to 10 trusted Vx0 addresses
• Threshold -- the M-of-N guardian approvals required to recover
• Timelock -- a delay before recovery can finalize (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: The pending recovery is recorded on the account
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 an NFT in the global VNS collection
• Resolve chris.vex -> find the NFT -> the owner's address IS the resolved address
• Transfer uses the existing TransferNft operation -- no new operation type 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.

Transfer Guard

Transfer Guard is a self-imposed account protection mechanism that lets users set rules on their own account to prevent unauthorized or accidental transfers.

Operations

Operation	Description
EnableTransferGuard	Activate transfer guard with configurable rules
DisableTransferGuard	Remove transfer guard (requires current guard key)
UpdateTransferGuard	Modify guard rules (whitelist, daily limits, cooldowns)
TransferGuardApprove	Pre-approve a specific transfer that would otherwise be blocked

Guard Rules

• Whitelist mode -- only allow transfers to pre-approved addresses
• Daily transfer limit -- cap total outgoing VXS per 24-hour period
• Cooldown period -- require a delay between enabling guard changes and them taking effect (prevents instant removal by an attacker)
• Guardian key -- optionally require a separate key to modify guard settings

Transfer Guard is entirely opt-in. Accounts without it enabled behave exactly as before.

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 -- post-quantum key generation works and signature verification already handles both Ed25519 and Dilithium3 signatures. A post-quantum block-signature field is already reserved 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.