Quantara • Devnet-0
Devnet-0 is liveView global status

QUANTARA • QUANTUM-RESISTANT L1

Localnet guide for Quantara Devnet-0

How to run a private Quantara network on your own machine or lab — for experiments, dApp development, and rehearsing Devnet-0 operations.

Docs • Dev & Ops

Localnet guide for Quantara Devnet-0

Spin up a private Quantara network that behaves like Devnet-0, without touching the public validators — ideal for experiments, rehearsals, and integration tests.

A Quantara localnet is a self-contained network you run on your own hardware or cloud account. It uses the same core primitives and runtime shape as Devnet-0, but with your own validators, your own RPC, and your own faucet / wallets.

Use localnets to test upgrades, rehearse validator operations, run CI pipelines, and iterate on dApps without waiting for shared Devnet-0 windows.

This guide pairs with the Devnet-0 launch checklist, Validator runbook and RPC guide. Think of this page as the “how to run it locally” counterpart.

Devnet-0Localnet guideQTR • 12 decimals • SS58=73

Localnets are not connected to public Devnet-0. Treat them as disposable labs where you can break things, reset, and experiment freely.

Devnet-0 reference profile

Reference networkDevnet-0
Token / Decimals / SS58QTR / 12 / 73
Public WS RPCwss://rpc.devnet-0.quantara.xyz
Public explorerhttps://explorer.devnet-0.quantara.xyz

Use these as reference when comparing your localnet to the real Devnet-0. For live endpoints and parameters, see /status and STATUS.

1 • When to use a localnet

Good use cases for a Quantara localnet

You don’t need a localnet for everything — but when you do, it’s the fastest way to iterate without impacting shared networks.

1.1 — dApp & integration development

  • • Building against Quantara RPC, balances, and events.
  • • Testing wallet flows and signatures end-to-end.
  • • Running automated test suites on CI.
  • • Experimenting with custom pallets or runtime parameters before they ever hit Devnet-0.

1.2 — Validator rehearsals

  • • Practicing key generation and rotation flows.
  • • Testing monitoring / alerting setups.
  • • Rehearsing upgrades, restarts, and rollbacks.
  • • Simulating failure scenarios without risking shared devnet uptime.

1.3 — Education & workshops

  • • Training new team members on Quantara ops.
  • • Running workshops or hackathons.
  • • Demonstrating block production and finality.
  • • Teaching key management and security basics.

2 • Requirements

What you need before spinning up a localnet

Hardware, software, and access assumptions for running a small localnet comfortably.

2.1 — Hardware profile

  • • For a single-node localnet: 4 vCPUs, 8–16 GB RAM.
  • • For 3-node validator localnet: 8–16 vCPUs, 32+ GB RAM.
  • • Fast SSD or NVMe storage strongly recommended.
  • • Stable network; localhost is ideal for first runs.

2.2 — Software prerequisites

  • • Git and a recent Rust toolchain installed.
  • • Ability to build the Quantara node from source.
  • • Optionally Docker / container runtime for isolated labs.
  • • Basic familiarity with terminal and systemd (or Docker).

3 • Single-node localnet

Quick start: one-node localnet on your machine

The fastest way to get a local Quantara chain running — ideal for dApp development and light experimentation.

3.1 — Boot a single-node chain

  1. 1) Clone the Quantara node repository.
  2. 2) Build the node binary with Rust (debug or release).
  3. 3) Start a local chain with a --dev or local chain-spec preset.
  4. 4) Confirm the node is producing blocks and reachable over local RPC.

The exact commands and flags live in the Devnet-0 launch checklist and RPC guide.

3.2 — Connect tools to your localnet

  • • Configure the Quantara wallet to point at your local WS RPC.
  • • Update your dApp's RPC URL to ws://127.0.0.1:PORT.
  • • Use Integration guide for code snippets and client configuration.
  • • Optionally run a local faucet compatible with your chain config for automated funding.

Single-node localnets are perfect for development, but not for realistic consensus tests. Use a multi-validator localnet when you want to exercise finality, failures, and network splits.

4 • Multi-validator localnet

Upgrade to a 3-node validator localnet

Practice full validator flows, including keys, sessions, and block production across multiple nodes.

4.1 — Topology & roles

  • • 3 validators (or 2 validators + 1 full node) minimum.
  • • Optional dedicated RPC node for wallets / dApps.
  • • Each node with its own keys, ports, and data directories.
  • • Optional sentry layout to mirror production practices.

4.2 — Bringing a validator set online

  1. 1) Generate a local chain-spec with your validator keys.
  2. 2) Distribute the same chain-spec to all nodes.
  3. 3) Start each node with appropriate role and ports.
  4. 4) Verify authority set and finality using RPC and logs, then exercise restart / failure scenarios.

For checklist-style guidance, combine this section with the Validator runbook and Backup & Restore docs.

5 • Testing on localnet

Patterns for effective local testing

Turn your localnet into an automated test lab, not just a one-off demo.

5.1 — Automated test suites

  • • Start a localnet as part of your CI pipeline.
  • • Run integration tests against local RPC endpoints.
  • • Tear down and rebuild between test runs.
  • • Capture logs and artifacts for flaky test investigations.

5.2 — Failure rehearsals

  • • Manually kill nodes to simulate outages.
  • • Introduce artificial latency or packet loss.
  • • Practice key rotation and validator handovers.
  • • Follow Incident Response and Rollback & Recovery flows as if it were mainnet.

5.3 — Wallet & faucet rehearsals

  • • Point wallet and faucet at local RPC URLs.
  • • Exercise account creation, funding, and transfers.
  • • Validate fee calculations and nonce handling.
  • • Use Wallet & Faucet runbook as your E2E checklist.

6 • Maintenance & resets

Reset, upgrade, and debug your localnet safely

Because localnets are disposable, you can be aggressive about resets — as long as you understand what you’re testing.

6.1 — Reset & rebuild

  • □ Stop all nodes and related services cleanly.
  • □ Wipe data directories (after backing up if needed).
  • □ Recreate chain-spec and keys if you want a fresh network.
  • □ Document your reset flow so teammates can repeat it.

6.2 — Upgrades & troubleshooting

  • □ Test new node binaries and runtimes on localnet before Devnet-0.
  • □ Use the Troubleshooting and Known issues docs to debug common patterns.
  • □ Capture logs, metrics, and configs for any bugs you file.
  • □ Mirror promising test scenarios on the real Devnet-0 once they look stable.

Next steps

From localnet to Devnet-0 to public testnet

A healthy workflow flows from local experiments → Devnet-0 rehearsals → public testnet hardening → mainnet confidence.

If you can spin up a localnet, rehearse validator flows, and tear it down repeatedly, you're already ahead of most ecosystems. Quantara is designed to reward that level of preparation.

Next, pair this guide with the Devnet-0 launch checklist, Validator runbook and Integration guide. Together, they form the full path from single-node local experiments to serious participation in Quantara's early networks.