Security Trust Center
Security is not a feature. It is the prerequisite. QNTM is built by a security engineer with continuous red team testing from day zero. We publish everything we find. We invite you to find what we missed.
Current Security Posture
Phase: pre-mainnet testnet
Red team running continuously against testnet. External audit funded from seed raise and required before mainnet launch. No mainnet without external audit. No exceptions.
Methodology
The operator has a professional security engineering background. Self-certification is conducted against documented methodology. Every finding is logged, classified, and traced to the commit that introduced it and the commit that fixed it. Red team attacks run continuously against testnet infrastructure on isolated hardware.
Network Layer
- Eclipse attack simulation
- Sybil attack (fake identity flood)
- P2P protocol fuzzing (malformed packets, oversized messages)
- DoS impact assessment
Consensus Layer
- Double-sign / equivocation detection
- Long-range attack simulation (genesis + tip ancestry probe)
- Validator slashing verification
PQC Implementation
- ML-DSA-65 timing attack suite (6 payload classes, stddev/mean ratio check)
- Falcon-512 timing verification
- Key uniqueness testing (chi-square randomness, no collision verification)
- Mnemonic determinism audit
EVM Layer
- Slither static analysis on all contracts
- Echidna property-based fuzzing
- Custom PQC-specific checks (signature malleability, replay protection, hardcoded key size literals)
- Assembly block audit
Wallet Security
- Key generation entropy (chi-square uniform distribution check)
- WASM timing side-channel
- BIP-39 mnemonic entropy audit
Supply Chain
- All dependencies pinned by checksum (go.sum + package-lock.json)
- Weekly CVE scan (govulncheck + npm audit)
- gitleaks scan on full git history
- SBOM on every release (syft)
Standards Alignment
| Standard | Body | What It Covers | QNTM Alignment |
|---|---|---|---|
| FIPS 203 | NIST | ML-KEM (Kyber) - Key encapsulation | Used for node TLS and key exchange |
| FIPS 204 | NIST | ML-DSA (Dilithium) - Digital signatures | Primary signature scheme, all validator keys |
| FIPS 205 | NIST | SLH-DSA (SPHINCS+) - Hash-based signatures | Available as optional fallback |
| FIPS 206 | NIST | FN-DSA (Falcon) - Digital signatures | Transaction signature scheme |
| FIPS 202 | NIST | SHA-3 / Keccak | Hash function throughout |
| SP 800-218 | NIST | Secure Software Development Framework | Build pipeline, audit trail, SBOM |
| CNSA 2.0 | NSA | Post-quantum algorithm requirements for national security | ML-KEM + ML-DSA meet CNSA 2.0 |
| EU ENISA | ENISA | PQC guidance for European systems | Monitored for regulatory alignment |
CNSA 2.0 (NSA Commercial National Security Algorithm Suite 2.0) mandates ML-KEM and ML-DSA for all national security systems. QNTM implements both. The compliance is structural, not retrofitted. An external security firm is engaged for audit in May 2026 before mainnet launch.
Bug Bounty
Bug bounty via Immunefi is active from mainnet launch. Pre-mainnet findings are acknowledged, credited, and fixed. Severity classification follows the same framework as our internal red team.
Scope
- Core protocol node
- PQC implementation
- Consensus mechanism
- EVM runtime integration
- Wallet SDK
Out of Scope
- Social engineering
- Third-party services
- Spam or DoS without protocol impact
- Theoretical attacks without PoC
Responsible Disclosure
Report to security@qntmchain.ai. 90-day disclosure policy. We fix first, publish after patch is live. Never publish exploit code.
Findings Log
Full findings log is maintained in the open-source repository at docs/security/findings-log.md. Every finding includes: date, severity, component, status, and the commits that introduced and resolved it.
View findings log on GitHub