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 |
| Pre-flight validation | Balance, gas, and nonce checks run before buffering. Transactions that can't possibly succeed are rejected immediately at near-zero CPU cost. | Before buffer | Deployed |
| 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 (936,034 transactions across 30 minutes):
| Property | Evidence |
|---|---|
| Zero crashes under load | 1,000 TPS sustained for 10 minutes. Zero node crashes, zero manual restarts across 5 validators on 4 continents. |
| 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 latency remained 0.7-1.0ms average even under 1,000 TPS 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 + LeaderBuffer cap + per-sender limits + TTL + dedup. 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 + 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 |
Responsible Disclosure
If you discover a security vulnerability in Vexidus, please report it responsibly:
- Email: security@vexidus.io
- GitHub: Security Advisories
We take all reports seriously and will respond within 48 hours.