QUANTARA • QUANTUM-RESISTANT L1
Integration guide for Quantara Devnet-0
How to connect apps, backends, and tools to Quantara Devnet-0: RPC, signing, environments, and best practices for early builders.
Docs • Builders
Integration guide for Quantara Devnet-0
A practical map for connecting to Quantara Devnet-0 from web apps, backends, scripts, and tools. Start here if you want your product talking to the chain.
Devnet-0 is our builder-first rehearsal network. It runs the same core primitives and token settings we plan for public testnet and mainnet — QTR, 12 decimals, SS58=73 — but with non-financial economics and faster change.
This page focuses on the integration surface for apps and infra: JSON-RPC endpoints, recommended client libraries, signing flows, and how to think about environments (Devnet-0 → public testnet → mainnet).
Use it alongside the RPC guide, Wallet & Faucet runbook and Release artifacts docs. Those cover the detailed endpoints and artifacts; this page is your integration blueprint.
Devnet-0 can and will change. Always pin against specific releases and check the /status page for runtime upgrades, breaking changes, and migration notes.
Devnet-0 integration snapshot
Last updated: 2025-11-23 22:00 UTC. For live endpoints, supported methods, and any temporary overrides, /status is the canonical source.
1 • Integration surface
How apps and tools talk to Quantara
Devnet-0 exposes a familiar Substrate-style surface: JSON-RPC over HTTP/WS, signed transactions, and event-based indexing.
1.1 — JSON-RPC (HTTP / WS)
- • Primary integration surface for all apps and tools.
- • Same core methods as Substrate / Polkadot SDK nodes.
- • Use WebSocket for subscriptions (events, newHeads) and HTTP for simple queries / jobs.
- • See the RPC guide for method examples.
1.2 — Accounts & addressing
- • Use SS58=73 for all devnet addresses.
- • QTR has 12 decimals; conversions should treat on-chain values as integer "plancks."
- • Wallet UX guidance lives in the Wallet & Faucet runbook.
1.3 — Indexing & explorers
- • Devnet-0 runs at least one public explorer.
- • Treat explorer URLs as debug helpers, not your only source of truth.
- • For production-style apps, plan to run light indexing or caching close to your backend.
- • See the Benchmarks & performance guide for deeper scaling notes.
2 • Client libraries
Recommended client libraries by stack
You can hit the RPC endpoints directly, but good libraries save a lot of boilerplate. These are the ones we target first in examples.
2.1 — TypeScript / JavaScript
- • Recommended: a Polkadot.js-API compatible client.
- • Connect using the Devnet-0 WS endpoint and chain metadata.
- • Use injected wallets (browser extensions, Quantara Wallet) for user signing.
- • Keep RPC URLs and chain hashes in NEXT_PUBLIC_QUANTARA_* environment variables where possible.
2.2 — Rust & on-chain tooling
- • For off-chain workers, bots, and CLI tools, Rust-based clients work well.
- • Use the same chain-spec and metadata artifacts described in Release artifacts.
- • Prefer typed APIs for extrinsic construction instead of raw hex payloads where possible.
2.3 — Other languages
- • Any language with WebSocket + JSON support can call the RPC surface.
- • Start from the examples in the RPC guide and port them.
- • For high-throughput services, focus on batching calls and reusing connections.
3 • Patterns
Patterns for web apps, APIs, and jobs
A few simple patterns go a long way: clean separation between front-end and backend, clear ownership of keys, and explicit environments.
3.1 — Browser & dApp pattern
- • Let the browser wallet (extension, injected provider) hold user keys.
- • Your dApp reads chain state via a shared WS provider and constructs unsigned extrinsics.
- • Users sign locally; the dApp submits the signed payload to the node.
- • Keep RPC URLs in client-side env vars so you can switch from Devnet-0 → testnet without code changes.
3.2 — Backend & jobs pattern
- • Backends maintain long-lived WS connections to 1–2 RPC nodes behind a load balancer.
- • Use HTTP RPC for simple batch reads and WebSocket for subscriptions.
- • Treat any backend-held keys (e.g. app hot wallets) as production secrets, even on Devnet-0.
- • Add metrics around RPC latency, error rates, and reconnect behaviour.
4 • Transactions & signing
Moving from read-only to state changes
Most integration bugs show up around signing, fees, and nonce handling. Get these right on Devnet-0 and you’ll be in great shape for testnet.
4.1 — Fee & nonce handling
- • Always query account nonce before constructing a transaction.
- • Use RPC helpers (e.g. payment_queryInfo equivalents) to estimate fees where available.
- • Handle "future" or "stale" nonce errors by refreshing state before retrying.
4.2 — Signing flows
- • Prefer user-held keys (browser wallets, hardware wallets) for end-user operations.
- • Keep backend-held keys limited to infrastructure tasks you can revoke quickly.
- • Make the chain name and address clearly visible in signing prompts to avoid confusion across stages.
4.3 — Error handling
- • Distinguish network errors from on-chain reverts.
- • Surface clear messages for common failures (ED, fees).
- • Log extrinsic hashes and block numbers to make debugging easier later.
- • See Troubleshooting for recurring patterns.
5 • Environments & versions
From Devnet-0 to public testnet and mainnet
Design your integration so switching networks is a config change, not a rewrite.
5.1 — Environment config
- • Keep per-environment settings (RPC URL, chain name, genesis hash) in configuration, not hard-coded.
- • Use explicit stage names like
devnet0,testnet,mainnetin your codebase. - • Make sure your staging / demo environments track Devnet-0 closely so issues appear early.
5.2 — Chain-specs & signed artifacts
- • Pin your nodes and clients against specific runtime and chain-spec versions.
- • Verify checksums / signatures for artifacts as described in Spec signing & verification.
- • Record which version your integration was tested against for each release.
- • Before mainnet, we'll publish clearer support windows and migration policies here.
6 • Observability & next steps
See what your integration is doing
You don’t need a giant observability stack, just enough insight to debug issues quickly and show that things are healthy.
For each environment, aim to have at least: basic logs, simple metrics, and a repeatable way to reproduce issues. Tie your app logs to extrinsic hashes and block numbers so you can jump between your system and the explorer quickly.
When something misbehaves, pair this guide with the Incident Response and Postmortem template docs — they'll help you turn edge cases on Devnet-0 into a stronger, more reliable product before users ever touch mainnet.
If you're building something serious on Quantara, we want to hear from you. Share what you're integrating, what's working well, and what's rough — Devnet-0 is the place where we shape this ecosystem together.