Network Defense Model
This page documents the complete threat mitigation posture of the Vexidus network across all attack categories. It is a living document -- updated as defenses are deployed and new threats are identified.
Last updated: March 2026 | Network stage: Public beta testnet
Defense Philosophy
Vexidus takes a structural elimination approach to network security. Rather than adding mitigations after vulnerabilities are discovered, the architecture is designed to make entire categories of attack structurally impossible.
Key principles:
- Eliminate preconditions -- remove the conditions that enable attacks, not just detect the attacks themselves
- Defense in depth -- every layer (P2P, consensus, RPC, economics) has independent protections
- Graceful degradation -- under attack, the network slows down but never crashes or forks
- Economic deterrence -- attacks that can't be structurally prevented are made economically irrational
MEV Elimination (~95% of Known Vectors)
Maximal Extractable Value (MEV) is the largest systemic risk to L1 blockchains. On Ethereum, MEV extraction exceeds $600M annually. Vexidus eliminates the preconditions for MEV through four independent mechanisms.
Attack Surface Removed
| Attack | How Traditional Chains Are Vulnerable | Vexidus Defense | Status |
|---|---|---|---|
| Front-running | Bots observe pending txs in gossip mempool | No mempool. Dragonfly Stream delivers txs directly to leader via sealed P2P pipeline. No public pool to observe. | Deployed |
| Sandwich attacks | Attacker wraps victim tx with front-run + back-run | No mempool + atomic execution. Can't see victim tx; IntentVM executes multi-step operations atomically with no inter-step window. | Deployed |
| Back-running | Bots position txs after profitable opportunities | Deterministic ordering. blake3(tx_hash || block_height) sort removes all proposer ordering discretion. | Deployed |
| Proposer reordering | Block proposer shuffles txs for profit | Content-determined order. Ordering is a pure function of transaction content -- proposer cannot influence it. | Deployed |
| Liquidation sniping | Bots race to liquidate positions they observe in mempool | No mempool. Liquidation txs flow directly to leader; no broadcast for bots to intercept. | Deployed |
| JIT liquidity | LPs add/remove liquidity around observed swaps | No mempool + deterministic ordering. Can't observe target swap or control position relative to it. | Deployed |
| Proposer censorship | Leader drops txs from competitors | Attestation commitments. Validators commit received tx hashes in attestation blocks. Censorship is cryptographically detectable. | Detectable |
| Quantum tx forgery | Future quantum computers forge transaction signatures | Dilithium3 PQ seals. Every forwarded tx carries a post-quantum cryptographic seal proving temporal provenance. | Deployed |
How It Compares
| Chain | Mempool | Proposer Ordering | Atomic Multi-Op | MEV Surface |
|---|---|---|---|---|
| Ethereum | Public gossip | Proposer-controlled (PBS mitigates redistribution) | No | ~100% exposed |
| Ethereum + Flashbots | Private relay (partial) | MEV-Boost auction | No | ~60-70% redistributed, not eliminated |
| Solana | No gossip (leader-based) | Leader FIFO (no deterministic sort) | No | ~40-50% (leader advantage) |
| Vexidus | No mempool (Dragonfly) | Deterministic blake3 sort | Yes (IntentVM) | ~5% remaining |
Most chains attempt to redistribute MEV (Flashbots, MEV-Share, PBS). Vexidus eliminates the preconditions for MEV to exist. The attack surface isn't mitigated -- it's structurally absent.
DDoS & Spam Protection
Transaction Layer
| Defense | Mechanism | Threshold | Status |
|---|---|---|---|
| Gas fees | Every transaction costs gas (10 nanoVXS/gas). Spamming 1M transactions costs ~21 VXS. | ~$0.0002/tx at $1/VXS | Deployed |
| LeaderBuffer cap | Hard limit of 100,000 pending transactions. When full, new submissions receive BufferFull rejection -- graceful degradation, not crash. | 100K transactions | Deployed |
| Per-sender limit | Each sender address can have at most 128 pending transactions in the buffer. Prevents single-account spam. | 128 per address | Deployed |
| Transaction dedup | Duplicate transactions are silently dropped (hash-based seen set). Replay of the same transaction has zero network cost. | Automatic | Deployed |
| Bundle TTL | Transactions expire after 120 seconds. Expired bundles are rejected on submission and skipped on drain. Prevents stale transaction buildup. | 120s default | Deployed |
| Nonce sequencing | Each account has a monotonic nonce. Out-of-order or replayed nonces are rejected before execution. | Per-account | Deployed |
| GBI pre-flight validation | Balance, gas, and nonce checks run before buffering. Transactions that can't possibly succeed are rejected immediately with user-friendly error messages (e.g., "Insufficient USDC balance for swap"). | Before buffer | Deployed |
| GBI failure throttling | Per-sender consecutive failure tracking. After 10 consecutive rejected submissions, sender is throttled for 60 seconds. Resets on successful submission. | 10 failures → 60s cooldown | Deployed |
| GBI failed gas charging | When --charge-failed-gas is active, failed bundles still pay 21K base gas × gas_price. Makes zero-cost spam economically unviable. | --charge-failed-gas | Wired (off by default) |
| Token creation rate limits | Per-account rate limiting on expensive operations (token creation, presale creation). Prevents resource exhaustion through state bloat. | Per-epoch per-account | Deployed |
| Dynamic gas pricing | Gas price auto-adjusts during sustained congestion, making spam progressively more expensive. | Governance-tunable | Planned |
P2P Network Layer
| Defense | Mechanism | Threshold | Status |
|---|---|---|---|
| PeerGuard reputation | Every peer has a score (0-100). Malicious behavior reduces score; score 0 = banned. Scores recover slowly through valid blocks. | Ban at 0, start at 100 | Deployed |
| Replay detection | 200-hash ring buffer per peer. Replaying a previously-seen block immediately deducts 20 points. 5 replays = ban. | 200 block hashes | Deployed |
| Rate limiting | Per-peer block rate capped at 30 blocks per 12-second interval. Validators get 3x allowance. Exceeding triggers score penalty. | 30/12s (90/12s validators) | Deployed |
| Invalid signature = instant ban | Forged block signature deducts 100 points (instant ban from starting score of 100). No recovery path for forgers. | -100 points | Deployed |
| Non-leader block rejection | Blocks from non-elected leaders deduct 15 points. Persistent impersonation leads to ban within 6-7 attempts. | -15 per offense | Deployed |
| Ban escalation | First ban: 1 hour. Repeat offense: 24 hours. Persistent attackers face exponentially increasing lockout. | 1h / 24h escalating | Deployed |
| Validator allowlisting | Authenticated validator P2P identity. On connection, validators prove Ed25519 signing key ownership via domain-separated signature over PeerId. Mutual authentication in one round-trip. --enforce-validator-allowlist rejects non-authenticated peers from block gossip. Bootnodes always exempt. Self-healing on PeerId regeneration. | --enforce-validator-allowlist | Deployed |
| QUIC transport | TLS 1.3 + UDP multiplexing with built-in connection-level flow control. Resistant to SYN floods and connection exhaustion. | Protocol-level | Deployed |
| Dragonfly O(1) bandwidth | Each transaction forwarded to exactly 2 targets (direct to elected leader + 1 bootnode backup), not broadcast to N peers. Eliminates gossip amplification -- an attacker's spam gets zero network multiplication. Falls back to all-bootnode routing when leader PeerId unknown. | 2 targets per tx | Deployed |
| GossipSub message size limit | GossipSub messages exceeding 10 MB are rejected before processing. Prevents single-message memory exhaustion through the gossip layer. | 10 MB max | Deployed |
| Sync request validation | GetBlocks requests with absurd count values (>1,000) are rejected with a reputation penalty. Server-side cap of 10 blocks per request regardless of client-specified count. | count ≤ 1,000; serve ≤ 10 | Deployed |
| Replay hash capacity | Ring buffer of recently-seen block hashes for replay protection. 1,000 hashes retained (32 KB memory). Replaying a previously-seen block costs -20 reputation points. | 1,000 hashes | Deployed |
| Request/response size limits | P2P sync requests capped at 1 MB, responses at 64 MB. Prevents single-request memory exhaustion. | 1 MB / 64 MB | Deployed |
| Sync timeout | Bulk sync requests time out after 60 seconds. Prevents slowloris-style connection holding. | 60s | Deployed |
| RPC connection limit | JSON-RPC server accepts maximum 4,096 concurrent connections. | 4,096 | Deployed |
| Response pagination | All list-type RPC methods (tokens, validators, transactions, history) are paginated with hard caps (50-1,000 items). Prevents single-query data explosion. | 50-1,000 per page | Deployed |
| Per-IP RPC rate limiting | Token bucket rate limiting on all RPC endpoints. Each IP gets an independent bucket (default 100 req/s sustained, 200 burst). Exceeded requests receive HTTP 429 with JSON-RPC error. IP extracted from X-Real-IP/X-Forwarded-For headers (proxy-aware). --rpc-rate-limit CLI flag (0 = unlimited). | 100 req/s default | Deployed |
| Per-peer bandwidth tracking | Per-peer byte volume tracking in PeerGuard. Rolling 60-second window, default 100 MB/min per peer (validators get 3x). Tracks gossip, sync, and Dragonfly payloads. Score penalty on exceed, ban on repeat. | 100 MB/min default | Deployed |
Consensus Layer
| Defense | Mechanism | Status |
|---|---|---|
| Staked validator set | Only validators with 1,000+ VXS staked can propose or attest blocks. No self-adding -- validator set loaded from on-chain state only. | Deployed |
| Leader rotation | Block proposer rotates every slot via deterministic selection (blake3(height + validator_set_hash)). No single validator can monopolize block production. | Deployed |
| Double-sign detection | Validators producing conflicting blocks at the same height are jailed with escalating penalties (1h, 24h, 7d, 30d). Evidence stored permanently. | Deployed |
| Attestation validation | Attestation blocks validated for correct signatures, uniqueness (one per validator per height), and zero transaction content. Duplicate attestations treated as double-sign violations. | Deployed |
| Jailing | Misbehaving validators removed from rotation. No slashing of stake (protects delegators) but missed rewards + reputation damage create strong economic disincentive. | Deployed |
| Upgrade grace period | 100-block (~200s) grace window after upgrade halt prevents jailing validators for upgrading. | Deployed |
Cryptographic Security
| Layer | Algorithm | Purpose | Quantum Status |
|---|---|---|---|
| Transaction signing | Ed25519 | Bundle authentication | Classical |
| Block signing | Ed25519 | Block proposer verification | Classical |
| Transaction seals | Dilithium3 (NIST Level 3) | Temporal provenance proof for Dragonfly Stream | Post-quantum |
| Address derivation | Blake3 | Deterministic address from public key | Quantum-resistant hash |
| State root | LtHash (homomorphic accumulator) | O(1) per-write state commitment, Blake3 finalization | Quantum-resistant hash |
| Transaction ordering | Blake3 | Deterministic content-based sort | Quantum-resistant hash |
| Key rotation | AddKey / RemoveKey / RotateKey | VSA v2 account key management | Supports Ed25519 + Dilithium3 |
Vexidus is quantum-hardened from day one. Dilithium3 keys are auto-generated on every validator startup. When quantum migration becomes necessary, key rotation is already built into the account model -- no protocol upgrade required.
Bridge Security (VexBridge)
Cross-chain bridges are historically the highest-value attack target in blockchain (>$2B stolen industry-wide). VexBridge uses a multi-layer defense model.
| Defense | Mechanism | Status |
|---|---|---|
| Vaultless architecture | No locked funds on source chain. Burn-and-mint model eliminates the "honeypot" that makes bridges attractive targets. | Deployed |
| Oracle consensus | Bridge deposits require majority oracle attestation with real Ed25519 signature verification. | Deployed |
| PQ oracle signatures | Oracle attestations support Ed25519, Dilithium3, and hybrid signatures. | Deployed |
| Oracle key governance | Oracle public keys registered on-chain via governance proposal. Key rotation requires validator vote. | Deployed |
| Execution-time verification | Every validator independently verifies bridge proofs during block execution -- not just the proposer. | Deployed |
| Emergency pause | Foundation can instantly pause all bridge operations. Resume requires governance vote (higher bar). | Deployed |
| Per-user rate limits | Rate limiting on bridge deposits per account to prevent rapid drain attacks. | Deployed |
| VSC-SAFE scoring | Heuristic safety scoring for bridged token contracts (5-factor analysis). Known scam contracts auto-blocked. | Deployed |
| Metadata sanitization | All bridge metadata (token names, URIs) sanitized for XSS, injection, null bytes, and dangerous patterns. | Deployed |
| Proof failure tracking | Failed verification attempts logged permanently for forensic analysis. | Deployed |
| Light client verification | Real Solana/Ethereum light clients for trustless proof verification. | Planned |
| ZK-STARK proofs | Zero-knowledge proof verification for bridge deposits (Winterfell integration). | Planned |
Network Resilience
These properties have been proven under sustained load testing (55,000+ transactions, 899K+ blocks, peak 2,856 tx/block):
| Property | Evidence |
|---|---|
| Zero crashes under load | Sustained load testing with 11 operation types across 5 validators on 4 continents. 1,210 bundles executed in under one second at peak. Zero node crashes, zero manual restarts. |
| Graceful buffer saturation | At buffer capacity, new transactions receive BufferFull rejection. Existing transactions continue processing normally. No cascading failure. |
| Geographic fairness | Vexcel attestation DAG ensures all validators produce blocks at 16-24% rate regardless of geographic latency. High-latency nodes (Singapore, Mumbai) are never disadvantaged. |
| Self-healing | No manual intervention required during any load test. Network recovers automatically when load decreases. |
| Sub-millisecond RPC | RPC p50 latency 0.5ms under sustained load. RocksDB reads offloaded to blocking thread pool to prevent tokio worker starvation. |
| Crash-safe state | All block writes committed atomically via RocksDB WriteBatch. No partial state on crash. |
Threat Model Summary
| Threat Category | Risk Level | Mitigation Status |
|---|---|---|
| MEV extraction | Minimal | ~95% eliminated (Dragonfly + deterministic ordering + IntentVM). Remaining: proposer censorship (detectable, enforcement planned). |
| Transaction spam | Low | Gas fees + GBI pre-flight validation + failure throttling + LeaderBuffer cap + per-sender limits + TTL + dedup + --charge-failed-gas (wired). Dynamic gas pricing planned. |
| P2P network flood | Low | PeerGuard reputation + rate limiting + per-peer bandwidth tracking + QUIC flow control + ban escalation. All deployed. |
| RPC abuse | Low | Connection limits + pagination + size limits + per-IP token bucket rate limiting (100 req/s default) deployed. |
| Consensus manipulation | Low | Staked validator set + leader rotation + double-sign detection + jailing + tombstone mechanism + correlation penalty + three-tier key separation + attestation validation. |
| Bridge exploitation | Low | Vaultless design + oracle consensus + execution-time verification + emergency pause + PQ signatures. Light client verification planned. |
| Sybil attacks | Low | 1,000 VXS minimum stake for validators. P2P allowlisting available. |
| Quantum threats | Minimal | Dilithium3 PQ seals deployed. Ed25519 + Dilithium3 dual-key accounts with key rotation. |
| Eclipse attacks | Low | Explicit bootnode peering + validator allowlisting. Full mesh peering planned. |
| State bloat | Low | ElasticState 3-tier storage (Hot/Warm/Cold) + per-CF compression + pruning modes + creation rate limits. |
Planned Hardening (Roadmap)
Items listed by priority. Updated as each is deployed.
Next Release
- Per-IP RPC rate limiting -- Token bucket middleware on JSON-RPC endpoints (100 req/s default,
--rpc-rate-limitflag) — Deployed - Authenticated validator allowlisting -- Ed25519 P2P identity proof +
--enforce-validator-allowlistflag — Deployed - Per-peer bandwidth tracking -- Byte volume tracking in PeerGuard (100 MB/min default, 3× for validators) — Deployed
During Beta
- Sync request validation -- Cap
GetBlockscount parameter (>1,000 rejected + reputation penalty, serve ≤ 10) — Deployed - GossipSub message size limit -- Reject messages exceeding 10 MB before processing — Deployed
- Increased replay hash capacity -- 200 to 1,000 block hashes (32 KB memory cost) — Deployed
- Dynamic gas pricing -- Auto-escalation during sustained congestion
- Signature pre-validation -- Ed25519 check at RPC layer before buffering (fail-fast for forged bundles)
- Per-sender buffer limit reduction -- 128 to 32 pending transactions per address
Mainnet Preparation
- ZK-STARK bridge proof verification -- Trustless bridge deposits via zero-knowledge proofs
- Light client verification -- Real Solana/Ethereum light clients for bridge proofs
- Censorship slashing -- Governance proposal to slash validators with provable censorship patterns
- PQ enforcement -- Reject classical-only seals; require Dilithium3 for all forwarded transactions
- External security audit -- Professional audit by a top-tier blockchain security firm
Comparison: Vexidus vs. Industry
| Feature | Ethereum | Solana | Vexidus |
|---|---|---|---|
| Mempool | Public gossip | No gossip (leader receives directly) | No mempool (Dragonfly sealed pipeline) |
| MEV protection | PBS/Flashbots (redistribution) | Jito (redistribution) | Structural elimination (~95%) |
| Tx ordering | Proposer-controlled | Leader FIFO | Deterministic blake3 sort |
| Atomic multi-op | No (separate txs) | No (separate txs) | Yes (IntentVM bundles) |
| Quantum readiness | None | None | Dilithium3 PQ seals + dual-key accounts |
| Bridge model | Lock-and-mint (honeypot) | Lock-and-mint (honeypot) | Burn-and-mint (vaultless) |
| Peer reputation | Basic scoring | Stake-weighted | PeerGuard (7-factor scoring + ban escalation) |
| Spam deterrence | EIP-1559 dynamic fees | Priority fees | Gas fees + buffer cap + per-sender limits |
Risk Management & Recovery
Vexidus implements a forward-only recovery model -- no chain rollbacks, no forks. All corrections happen through governance proposals with validator consensus.
Governance-Based Recovery Tools
| Tool | Mechanism | Governance Required |
|---|---|---|
| Account Freeze | Block all outbound operations from a compromised account | AccountFreeze proposal (67% vote) |
| Token Freeze | Suspend all transfers of a specific token | TokenFreeze proposal (67% vote) |
| State Correction | Adjust account balances to remediate exploits | StateCorrection proposal (67% vote + 100-block delay) |
| Emergency Mint | Mint tokens to cover verified losses | EmergencyMint proposal (67% vote + 100-block delay) |
Frozen accounts can still receive tokens, vote on governance proposals, and claim staking rewards. Only outbound operations (transfers, swaps, bridge exits) are blocked. This prevents collateral damage to innocent counterparties while containing threats.
Automated Protections
- Pool Drain Circuit Breaker -- Any single swap extracting >50% of a pool's output reserve is automatically rejected. Always-on, no governance needed.
- Bridge Emergency Pause -- Single transaction to halt all bridge deposits. Governance vote required to resume (asymmetric design: fast pause, slow resume).
- Per-User Bridge Rate Limiting -- Maximum 100K VXS equivalent per user per day, preventing circuit breaker manipulation.
- Validator Uptime Tracking -- Block production tracked on-chain for reputation scoring. Validators who miss blocks lose reputation, affecting delegator trust.
State Preservation
Full state export/import tooling for state-preserving genesis restarts:
vexidus state export-- Deterministic JSON snapshot of all state domains with SHA256 checksumvexidus state import-- Load exported state into fresh chain at block 0vexidus state verify-- Cross-validate export against live state
Round-trip verified: 1,390 accounts, 33 tokens, 5 validators, 6 pools, 18 stablecoins preserved through export-import cycle.
Responsible Disclosure
If you discover a security vulnerability in Vexidus, please report it responsibly:
- Email: security@vexidus.com
- GitHub: Security Advisories
We take all reports seriously and will respond within 48 hours.