QUANTARA • QUANTUM-RESISTANT L1
Security & trust on Quantara
How we think about validators, keys, wallets, infrastructure, and incidents across Devnet-0, public testnet, and mainnet.
Security posture
Built like critical infrastructure, not a weekend fork
Devnet-0 is where we harden everything: consensus, tooling, key management, and incident response. Mainnet inherits those lessons — not the other way around.
Quantara is designed as a long-term settlement layer in a post-quantum world. That means we care as much about operational discipline as we do about throughput and UX: deterministic builds, explicit upgrade paths, clear runbooks, and rehearsed incident drills.
Devnet-0 is intentionally treated like a mini–production environment. Validators run real monitoring, we practice rollbacks, and we ship runtime upgrades under load. Public testnet and mainnet then inherit a battle-tested stack instead of experimental code.
This page gives you the high-level model. The full details live in our security checklist, threat model, and incident response docs which we update as Devnet-0 evolves.
Single canonical address format across devnet, public testnet, and mainnet.
Devnet-0 is online and used to harden validators, tooling, and ops.
Living documents versioned alongside the chain-specs and runtime.
Layers of defense
What Quantara secures across the stack
From consensus to wallets to infrastructure, security is layered and documented.
Consensus & validators
Validators are the backbone of Quantara. We focus on key hygiene, slashing safety, and predictable upgrade flows.
- • Aura + GRANDPA with deterministic chain-specs
- • Separate stash, controller, and session keys
- • Validator runbook and upgrade/rollback playbooks
Wallets & keys
QTR wallets prioritize key safety and clear UX over gimmicks. We aim to make the right thing the easy thing.
- • Clear separation between testnet and mainnet QTR
- • Strong defaults for derivation, SS58 prefix, and metadata
- • Guidance for hardware wallets and cold storage
Infrastructure & tooling
Tooling is part of the attack surface. We design our CLI, RPC, and explorer with that in mind.
- • Deterministic builds and pinned dependencies
- • Scripts and Docker images with minimal, auditable surface
- • Clear separation between dev, staging, and production use
Practices
How we operationalize security
Security is a process. Here’s how we practice it across Devnet-0 and beyond.
We treat documentation as part of the security surface. Every meaningful change to the Quantara node, runtime, or infra stack is paired with updates to runbooks, checklists, and threat models.
Incident response is rehearsed on Devnet-0 and public testnet before mainnet: controlled failures, simulated key loss scenarios, and runtime upgrade drills. The goal is not “never fail” — it’s “fail in rehearsed ways” where operators know exactly what to do.
As we approach mainnet, we expect to layer in independent audits of critical components and public postmortems for any security-relevant incidents.
Runtime upgrades, rollbacks, and failover tested before mainnet.
Pinned toolchains, reproducible chain-specs, and versioned releases.
Validator, stash, and session keys treated as distinct risk profiles.
Responsible disclosure
How to report a security issue
If you think you’ve found a vulnerability, we want to hear from you — early, clearly, and with as much detail as possible.
Security findings are welcome at any stage — Devnet-0, public testnet, or mainnet. We prefer responsible disclosure with clear reproduction steps, affected components, and any known impact.
Please avoid testing vulnerabilities against mainnet users or production infrastructure without prior coordination. Devnet-0 and public testnet exist specifically so you can push the system safely.
- • Include logs, configs, and reproduction steps where possible
- • Specify which network (Devnet-0 / testnet / mainnet preview)
- • Tell us if the issue is public or has been shared elsewhere
Never share seed phrases or private keys
No one from Quantara will ever ask for your seed phrase or private key. If someone claims otherwise — even if they appear to be staff — treat it as malicious and contact [email protected] immediately.