Security & Privacy

Post-Quantum
Network Security

Every IronDAG node connection uses ML-KEM-768 — a NIST FIPS 203 post-quantum algorithm that protects the network layer against future quantum decryption. Live on testnet today.

● ML-KEM-768 Live ● Ed25519 TOFU Live ◌ zk-SNARK Tx Privacy Planned

Quantum-Resistant Network Layer

"Harvest Now, Decrypt Later" attacks are already occurring — adversaries record encrypted traffic today to decrypt once quantum computers arrive. IronDAG closes that window now, before quantum hardware exists.

Live
🔐

ML-KEM-768

NIST FIPS 203 post-quantum key encapsulation on every peer-to-peer connection. All node traffic is protected against both classical and quantum adversaries.

Live
🆔

Ed25519 TOFU Identity

Peer identity established via Trust-On-First-Use with Ed25519 keys, persisted per node. Prevents identity rotation attacks and cascading peer bans on restart.

Live

QUIC Transport

All peer connections use QUIC — a modern multiplexed transport with built-in encryption. Faster and more resilient than TCP+TLS for blockchain gossip protocols.

ML-KEM-768 Parameters

When two IronDAG nodes connect, they perform a post-quantum handshake before any chain data is exchanged. A future quantum computer cannot retroactively decrypt captured sessions.

Standard NIST FIPS 203 (ML-KEM, Module-Lattice Key Encapsulation) Security Level Category 3 — equivalent to AES-192 Public Key Size 1,184 bytes Ciphertext Size 1,088 bytes Shared Secret 32 bytes (used to derive QUIC session keys) Identity Layer Ed25519 TOFU (persisted to data_dir/node_key) Status Live on IronDAG testnet

Why FIPS 203?

Why it matters now: An adversary recording IronDAG peer traffic in 2026 cannot decrypt it even after a cryptographically-relevant quantum computer exists — ML-KEM-768 session keys are not vulnerable to Shor's algorithm.

Security at Every Layer

Layer Mechanism Algorithm / Standard Status
P2P Key Exchange Post-quantum KEM ML-KEM-768 (NIST FIPS 203) ● Live
Peer Identity TOFU verification Ed25519 ● Live
Transport Encrypted UDP QUIC ● Live
PoW — Stream A Proof-of-work hash Blake3 ● Live
PoW — Stream B Memory-hard PoW B3MemHash (256KB, SIMD) ● Live
Consensus BlockDAG finality GhostDAG ● Live
Transaction Privacy Zero-knowledge proofs Groth16 / BN254 (zk-SNARKs) ◌ Planned

Transaction Privacy — Coming to Mainnet

The cryptographic infrastructure for optional private transactions is in the IronDAG codebase — Groth16/BN254 proving system and nullifier set are built. Mainnet activation is a post-testnet milestone.

Planned
🎭

Optional Private Transfers

Hide sender, receiver, and amount using Pedersen commitments and a nullifier set. Privacy is opt-in — transparent transactions remain the default.

Planned
🔏

Groth16 / BN254 Proofs

~500ms proof generation, ~10ms on-chain verification. Infrastructure is in the codebase with performance validated on reference hardware.

Planned
📜

Private Smart Contracts

Execute EVM contracts without revealing inputs or outputs. Full EVM compatibility is maintained — existing contracts work with the optional privacy flag.

Status: The zk-SNARK proving circuit and nullifier system are written and passing internal tests. Activation requires a protocol hard fork. We are completing testnet stress-testing and fee model design before scheduling the upgrade.

Try the Testnet

The testnet is live with ML-KEM-768 active on all peer connections. Explore blocks, add IronDAG to MetaMask, or read the full technical architecture.

🔍 Block Explorer

View live blocks, DAG health, and dual-stream PoW in real time.

Open Explorer →

📄 Whitepaper

Full architecture: GhostDAG, BraidCore mining, ML-KEM-768, EVM, and the zk-SNARK roadmap.

Read Whitepaper →

💻 GitHub

Core concepts repository — protocol specification and architecture documents.

View on GitHub →