QUANTARA • QUANTUM-RESISTANT L1
Spec signing & verification for Quantara Devnet-0
How we sign Devnet-0 specs and release artifacts — and how you can verify them before they ever touch your infrastructure.
Docs • Security
Spec signing & verification for Quantara Devnet-0
Devnet-0 artifacts are built to be deterministic and verifiable. This guide explains what we sign, how we publish hashes, and the exact checks you can run before trusting any binary, chain-spec, or runtime.
Strong security starts with knowing exactly what code you're running. For Quantara Devnet-0, that means deterministic builds, published checksums, and signed specs that anyone can verify with standard tools.
This page is the practical companion to the Release artifacts and Security checklist docs. Use those to discover what files exist; use this page to confirm they're genuine before running them on your validators, RPC nodes, or localnets.
The patterns here will stay the same as we move from Devnet-0 to public testnet and mainnet — only the keys, networks, and levels of formality change.
If a checksum or signature doesn't match, stop immediately. Do not “fix it later.” Treat it as a potential security incident and cross-check links, mirrors, and keys before proceeding.
Devnet-0 signing snapshot
Last updated: 2025-11-23 22:00 UTC. The current live release tag, checksums, and signatures are always linked from /status and the official release notes.
1 • Threat model
Why spec signing and verification matter
Devnet-0 is a rehearsal network, but we still treat binaries and specs as security-critical artifacts.
1.1 — What could go wrong
- • Malicious binary with hidden backdoor or key exfiltration.
- • Tampered chain-spec pointing to an attacker's network.
- • Truncated or corrupted downloads causing subtle issues.
- • “Lookalike” links shared in chats or screenshots.
1.2 — What verification defends against
- • Confirms artifacts match what Quantara actually released.
- • Detects tampering between our build pipeline and your disk.
- • Gives you a repeatable audit trail for incidents.
- • Builds habits you'll rely on for mainnet later.
1.3 — Operator responsibilities
- • Download artifacts only from official links.
- • Verify checksums and signatures before deployment.
- • Record versions and hashes in internal runbooks.
- • Treat mismatches as incidents, not annoyances.
2 • Artifacts
Which Devnet-0 artifacts are signed or hashed
Not every small helper script needs a signature — but anything that can influence consensus, keys, or user funds gets additional protection.
2.1 — Chain-specs & genesis
- • Devnet-0 plain.json and raw.json specs.
- • SCALE-encoded genesis state used to construct the network.
- • SHA-256 hashes published for each spec and genesis blob.
- • Selected specs accompanied by detached signatures.
2.2 — Runtime & node binaries
- • Runtime Wasm blob for the active Devnet-0 runtime.
- • Quantara node binaries (Linux x86_64, and other targets as available).
- • Checksums for every binary and image we publish.
- • Runtime hash recorded in release notes and /status.
2.3 — Release manifest
- • A small manifest (JSON / text) listing all artifact names, versions, and hashes.
- • Designed for scripts and CI to consume automatically.
- • Helps detect missing or unexpected files in a release.
3 • Keys & fingerprints
Which keys we use and how to recognize them
Before you trust any signature, you need to know which public key it should be made with — and how to confirm that key is legitimate.
3.1 — Quantara release keys
- • Quantara maintains separate keys for Devnet-0, public testnet, and mainnet.
- • Key fingerprints and usage policies are published in this doc set and linked from /status.
- • Treat the fingerprints as long-lived identifiers and verify them via multiple channels where possible.
3.2 — Your own trust store
- • Import Quantara release keys into a dedicated keyring.
- • Record fingerprints in your internal runbooks.
- • Limit which operators can add or modify trusted keys.
- • For highly sensitive setups, verify fingerprints out-of-band (video call, multiple team members, etc.).
4 • Verification flows
How to verify hashes and signatures in practice
These flows use standard Unix-style tooling. You can adapt them to your own security stack as long as the underlying checks remain equivalent.
4.1 — Verify checksums
- 1) Download artifact and its
.sha256file. - 2) Run sha256sum <file> locally.
- 3) Compare output against the published hash.
- 4) If they differ, re-download from an official link and treat the mismatch as an incident.
4.2 — Verify signatures
- 1) Import the Quantara release key into your keyring.
- 2) Download artifact and its detached signature (for example
.sigfile). - 3) Run your verification tool (GPG, minisign, etc.) against the pair.
- 4) Confirm both the signature status and key fingerprint match expectations.
4.3 — Sanity check against the chain
- • After starting your node, query system_version and runtime hash via RPC.
- • Confirm the spec-name and spec-version match the release notes.
- • Compare runtime hash with what's recorded in the artifact manifest.
You don't have to use the exact commands we suggest — but you should always be performing equivalent checks. Automate them in your CI or deployment scripts wherever possible.
5 • Air-gapped flows
Verifying artifacts in air-gapped or high-sensitivity setups
For some operators, Devnet-0 is a rehearsal for mainnet-grade, air-gapped deployments. These patterns help you practice now.
5.1 — Offline verification pattern
- • Download artifacts and signatures on an online host.
- • Transfer them to an air-gapped machine via a vetted medium (USB, offline storage).
- • Run checksum and signature verification on the air-gapped machine.
- • Only then move binaries into your deployment pipeline.
5.2 — Recording results
- • Log which operator verified which release and when.
- • Store hashes and fingerprints with your change logs.
- • In incident reviews, cross-check which nodes were running which verified artifacts.
- • Use Devnet-0 as a safe place to tune these workflows before mainnet.
6 • Rotation & incidents
What happens if keys rotate or something looks wrong
Key rotation and verification failures should feel routine, not mysterious. Here’s how we handle them together.
6.1 — Key rotation
- • Planned key rotations are announced on /status and validator channels.
- • New fingerprints are published in multiple places.
- • Old keys may be kept for verifying historical releases.
- • Update your internal docs and trust stores as part of the rotation window.
6.2 — Verification failures
- • Stop deployment of that artifact immediately.
- • Capture commands, outputs, and the exact files used.
- • Check /status and Incident Response for active advisories.
- • Share a concise report (time, file, hash, key, output) in validator / ops channels.
Next steps
Trust the math, not just the marketing
Devnet-0 is the perfect place to make verification muscle memory — so by the time real value is at stake, these checks feel automatic.
Keep this page close to Release artifacts, Security checklist and Incident Response. Together, they describe how we ship Devnet-0, how you can verify it, and how we'll respond if anything ever looks off.
As we move into public testnet and mainnet, the same principles apply — just with more signatures, stricter policies, and higher stakes. Practicing now means your infrastructure, your team, and your users will all be safer later.