QUANTARA • QUANTUM-RESISTANT L1
Release artifacts for Quantara Devnet-0
The canonical place to find Devnet-0 binaries, chain-specs, runtimes, and checksums — plus how to verify and use them safely.
Docs • Releases
Release artifacts for Quantara Devnet-0
Quantara Devnet-0 ships deterministic, signed artifacts for every network milestone. This page explains what we publish, how to verify it, and how to wire it into your nodes and tooling.
Every Devnet-0 release comes with a small, well-defined bundle of artifacts: node binaries or container images, chain-specs, runtime Wasm, and reference metadata. Together, they let you reproduce the exact network we're running.
This page is the companion to the Spec signing & verification and Devnet-0 launch checklist docs. Use those for the step-by-step commands; use this page as your map of what artifacts exist and how they fit together.
Devnet-0 is a non-financial rehearsal network — but our artifact pipeline is designed to look and feel like mainnet from day one. The same patterns will carry forward to public testnet and mainnet.
Never run binaries or chain-specs from random links or screenshots. Always start from the official release links and verify checksums / signatures as described in the verification guide.
Devnet-0 release snapshot
Last updated: 2025-11-23 22:00 UTC. The /status page lists the current live release tag and links to the corresponding artifacts.
1 • Artifact types
What we publish for each Devnet-0 release
Each Devnet-0 release has a predictable set of files. If something is missing, treat it as a red flag and check /status before proceeding.
1.1 — Node binaries / images
- • Quantara node binary (Linux x86_64, others as available).
- • Optional container image tags for Devnet-0.
- • Built with deterministic flags and pinned toolchains.
- • Checksums published alongside each artifact.
1.2 — Chain-specs & genesis state
- • Devnet-0 chain-spec in plain.json and raw.json forms.
- • SCALE-encoded genesis state blob produced by the genesis builder tooling.
- • SHA-256 hashes for each spec and genesis file.
1.3 — Runtime & metadata
- • Runtime Wasm blob for the current Devnet-0 version.
- • SCALE-encoded metadata export (V14/V15-compatible).
- • Helpful for explorers, wallets, and SDKs that need to decode calls / events.
- • Versioned to match on-chain runtime version and spec name.
2 • Locations
Where release artifacts live
We keep artifact discovery simple: every Devnet-0 release is anchored from two places — the Status page and the canonical release index.
2.1 — Status & release index
- • /status lists the current live Devnet-0 release with links to artifacts.
- • Historical releases remain discoverable from the same page or a dedicated release index.
- • If a link ever looks wrong, compare version / hash details against this doc and the verification guide.
2.2 — Mirrors & local copies
- • Some operators mirror artifacts locally for faster access.
- • Mirroring is fine — verification still must happen against official hashes / signatures.
- • For air-gapped setups, copy both the artifact and its checksum / signature files.
3 • Verification
Verifying what you download
Before a binary ever touches your servers, confirm that it’s exactly what we published — not a truncated download or a malicious lookalike.
3.1 — Checksums
- • Every artifact ships with a SHA-256 checksum.
- • Recompute locally and compare before using.
- • For scripts / examples, see Spec signing & verification.
- • Treat a mismatch as a hard stop — re-download from a fresh source.
3.2 — Signatures
- • Selected artifacts are signed with Quantara keys.
- • Public keys and fingerprint details are documented in the verification guide.
- • Verify signatures on any artifact that could impact consensus or user funds.
3.3 — Version sanity checks
- • After starting a node, confirm the spec-name and spec-version match the release notes.
- • Cross-check against the chain-spec and runtime metadata.
- • If anything disagrees, stop and consult Incident Response and /status.
4 • Example flows
Common ways to use release artifacts
Most operators fall into one of three buckets: local dev nodes, single validators, or multi-node Devnet-0 clusters. These flows cover the basics.
4.1 — Local dev / testing
- • Download the node binary and Devnet-0 chain-spec (plain or raw).
- • Verify checksum; run a single local node.
- • Point your wallets / tools at the local RPC while developing features.
- • See Localnet guide for multi-node setups.
4.2 — Single validator
- • Use the pinned node binary / image and the official Devnet-0 chain-spec.
- • Follow the launch checklist and validator runbook.
- • Record which release you're on, plus hashes, in your internal docs.
4.3 — Upgrade / rollback
- • Before upgrading, download both the new and previous release artifacts.
- • Verify all checksums; store them with your change logs.
- • Use the Rollback & Recovery doc to coordinate any rollbacks.
- • After the change, capture versions and block heights in your incident notes.
Next steps
Treat artifacts as part of your reliability story
Devnet-0 is the dress rehearsal for how we’ll ship and consume artifacts on mainnet. Getting comfortable with the flow now pays off later.
Keep this page close to Spec signing & verification, Devnet-0 launch checklist and Incident Response. Together they describe what we ship, how to trust it, and how to react when something goes wrong.
As we move from Devnet-0 to public testnet and mainnet, we'll extend this page with more networks, long-term support windows, and additional artifact types. The habits you build here — verifying, recording, and automating — are the ones that will keep your infrastructure safe when real value is on the line.