Dragonfly Stream -- Mempoolless Transaction Pipeline

Dragonfly Stream replaces the traditional gossip-broadcast mempool with a sealed, direct-delivery pipeline. Transactions flow from client to block leader without pooling -- eliminating the primary attack surface for MEV (Maximal Extractable Value).

Why No Mempool?

Every major MEV attack requires observing pending transactions before they are included in a block. On traditional chains, the mempool is a public broadcast channel where bots watch for opportunities to front-run, sandwich, or reorder transactions.

Dragonfly Stream removes the pool entirely. Transactions are forwarded directly to the current block leader via authenticated P2P channels, sealed with post-quantum cryptographic signatures that prove temporal ordering.

Traditional chain:
  User -> Broadcast to ALL peers (mempool) -> Bots observe -> Leader includes
  Risk: Front-running, sandwich attacks, censorship

Dragonfly Stream:
  User -> RPC node -> Sealed forward to Leader + 2 backups -> Block
  Risk: None of the above -- no public pool to observe

How It Works

Transaction Flow

1. User submits bundle to any RPC node (signed Ed25519)
2. RPC validates signature and format
3. Seal creation -- the receiving validator creates a post-quantum seal over the transaction:
   • Commitment: blake3(tx_hash + block_height + validator_pubkey)
   • Signature: Dilithium3 (NIST Level 3 post-quantum) or Ed25519 (classical fallback)
4. Direct forwarding -- sealed transaction sent to the current leader and next 2 pipeline backups via dedicated P2P command (not gossip)
5. Leader includes the transaction in the next block
6. Seal verification -- leader verifies seals on received transactions

PQ Seals (Post-Quantum Cryptographic Seals)

Every forwarded transaction carries a cryptographic seal that proves:

• Who saw the transaction (validator identity)
• When they saw it (block height binding)
• Authenticity (quantum-resistant Dilithium3 signature)

Validators auto-generate Dilithium3 keypairs on startup. No manual key management required.

Seal types:

• PQ (Dilithium3) -- Primary. NIST-approved lattice-based post-quantum signatures. ~3.3 KB per seal.
• Classical (Ed25519) -- Fallback for validators without PQ keys. 64-byte signature.

Pipeline Failover

Dragonfly Stream forwards transactions to three targets: the current leader and the next two validators in the rotation. If the leader fails:

1. Pipeline backup #1 already holds the transactions
2. Vexcel attestation promotion seamlessly transitions to the new leader
3. No transactions lost, no re-submission needed

This builds on the existing Vexcel adaptive attestation DAG -- Dragonfly Stream and Vexcel form a self-reinforcing system.

MEV Protection

Dragonfly Stream is one component of a multi-layer MEV elimination strategy:

Layer	Mechanism	What It Prevents
No mempool	Dragonfly direct delivery	Front-running (no pool to observe)
Deterministic ordering	blake3(tx_hash + block_height) sort	Proposer reordering (content-determined order)
Atomic execution	IntentVM composite intents	Sandwich attacks (no inter-step window)
PQ seals	Dilithium3 temporal proofs	Quantum tx forgery
Attestation commitments	Validators commit received tx hashes	Censorship (provably detectable if leader drops attested txs)

At full deployment, Vexidus has zero known MEV vectors: no mempool to observe, the proposer cannot control ordering, intents execute atomically, and censorship is cryptographically detectable. Achieved without BLS/DKG threshold encryption -- simpler, faster, stronger.

Phased Rollout

Dragonfly Stream deploys incrementally via VexVisor on-chain governance -- no genesis restart required at any phase.

Phase	Status	Description
Phase 1	Live	Dual-mode binary. --dragonfly-stream flag enables direct forwarding alongside existing mempool.
Phase 2	Live	PQ sealing. Auto-generated Dilithium3 keys. Seal creation and verification on every forwarded transaction.
Phase 3	Planned	Mempool removal. Gossip broadcast topic removed. All transactions flow through Dragonfly pipeline only.
Phase 4	Planned	PQ enforcement. Classical-only seals rejected. Validator registration requires Dilithium3 pubkey.

Key Properties

• O(1) bandwidth -- each transaction forwarded to 3 targets (leader + 2 backups), not O(N) gossip flood
• Pipeline failover -- backup validators already hold transactions when the leader drops
• Censorship accountability -- attestation blocks commit to received transaction hashes; leader censorship is provably detectable
• Adaptive timing synergy -- Dragonfly Stream + Vexcel + pressure-aware micro-blocks form a self-regulating throughput engine
• No hard restart -- all parameters (buffer sizes, PQ requirements, max transactions per block) adjustable via governance or CLI flags
• Quantum-safe from day one -- Dilithium3 seals protect transaction ordering against future quantum computers

Dragonfly Stream + Vexcel

Dragonfly Stream and Vexcel are complementary systems:

• Vexcel handles block-level consensus (attestation DAG, leader promotion, geographic fairness)
• Dragonfly Stream handles transaction-level delivery (sealed forwarding, PQ proofs, MEV elimination)

Together they form a complete pipeline: transactions flow directly to the leader via Dragonfly, and if the leader fails, Vexcel promotes the next validator who already holds those transactions via the pipeline backup. Zero gap, zero loss.

Configuration

Flag	Default	Description
--dragonfly-stream	off	Enable Dragonfly Stream direct forwarding and PQ sealing

When disabled, the node uses the traditional gossip-broadcast mempool. When enabled, transactions are sealed and forwarded directly to block leaders.

RPC Endpoints

Method	Description
vex_getDragonflyStats	Returns Dragonfly Stream statistics (forwarded count, received count, seal type, enabled status)