QUANTARA • QUANTUM-RESISTANT L1
Known issues on Quantara Devnet-0
Single place to track significant limitations, bugs, and caveats for Quantara Devnet-0 — with workarounds and status.
Docs • Ops
Known issues on Quantara Devnet-0
This page summarizes significant known issues for Devnet-0 — what they look like, who they impact, and how to work around them until we ship a fix.
Devnet-0 is a fast-moving rehearsal network. Bugs and rough edges are expected. The important part is that we describe them clearly, keep them in one place, and give you a safe workaround whenever possible.
This page focuses on issues that are repeatable and worth tracking: consensus or runtime limitations, node / networking quirks, RPC or wallet glitches, and gaps in tooling or documentation.
For live incident state and outages, always check /status first. This page complements the Incident Response and Postmortem Template docs.
This page is not a real-time feed. If you're diagnosing an active problem, /status and the validator / ops channels are the canonical sources of truth.
Devnet-0 snapshot
• Sev-1 / Sev-2 issues will always have an accompanying incident entry on /status.
• Minor quirks and cosmetic bugs may live only here and in GitHub issue trackers.
Last updated: 2025-11-23 22:00 UTC. Always cross-check with Status and the relevant repo before assuming an issue is still open.
1 • How to use this page
Severities, status labels, and scope
We keep the format predictable so you can quickly tell how bad something is, who it affects, and what to do about it.
1.1 — Severity
- • Sev-1 — network-wide / consensus or finality impact.
- • Sev-2 — partial degradation or major feature impact.
- • Sev-3 — local / cosmetic, limited blast radius.
- • Sev-0 — informational limitations or expected behavior.
1.2 — Status labels
- • Open — active and reproducible.
- • Mitigated — workarounds exist; fix in progress.
- • Resolved — fix shipped to Devnet-0.
- • Won't fix (Devnet) — accepted limitation on devnet.
1.3 — Scope & references
- • Impacted components (validators, RPC, wallet, explorer).
- • Link to incident / postmortem where applicable.
- • Link to GitHub issues or PRs tracking the fix.
- • Notes on whether it's expected before testnet.
2 • Consensus & runtime
Consensus, runtime, and protocol-level issues
These are the most serious items — anything that affects block production, finality, or core runtime behavior.
QNR-DEVNET-001 — Consensus / finality
Example entry- Severity: Sev-1 (would be incident-driven).
- Symptoms: stalled finality, blocks not produced, validators repeatedly dropped.
- Workaround: coordinated rollback or runtime patch (see Rollback & Recovery).
- Status: template — to be replaced with real entries as needed.
QNR-DEVNET-RT-LIMITS — Runtime limits & parameters
- Scope: describes temporary runtime parameters that are intentionally conservative on Devnet-0 (e.g. low block weights, small queues).
- Impact: may limit throughput or size of certain transactions.
- Workaround: stagger heavy transactions; rely on Benchmarks Guide for expected caps.
- Status: expected Devnet-0 behavior; will be relaxed before public testnet as we collect data.
3 • Node & networking
Node, networking, and infra limitations
Patterns that affect how you run validators, RPCs, and supporting nodes on Devnet-0.
QNR-NODE-001 — Archive workloads on small disks
- Severity: Sev-2 for archive / analytics nodes, Sev-3 for others.
- Symptoms: nodes running archive mode on small disks eventually hit disk pressure and slow down or fail.
- Workaround: use pruning for validators; reserve archive mode for appropriately sized NVMe volumes.
- Status: expected; will be documented in sizing guidance.
QNR-NODE-002 — Heavy RPC traffic on validators
- Severity: Sev-2 where validators serve mixed RPC and consensus traffic.
- Symptoms: validator falls behind during large wallet / explorer bursts.
- Workaround: use separate RPC / sentry nodes; avoid pointing public frontends directly at validators.
- Status: design guidance; considered normal Devnet-0 behavior.
Node & networking — checklist
- □ Follow Localnet guide for reproducing issues off-chain.
- □ Capture metrics / logs before restarts (see Incident Response).
- □ File persistent cases as issues with exact flags and hardware specs.
4 • Wallet, faucet & explorer
Frontend-facing quirks & integration notes
Known rough edges for the wallet, faucet, and explorer experience on Devnet-0.
QNR-WALLET-001 — Faucet rate limits
- Severity: Sev-3 (nuisance; no chain impact).
- Symptoms: frequent requests from the same IP or address are rejected with “rate limited” responses.
- Workaround: wait for the cooldown window or request from another member of your team.
- Status: expected anti-abuse behavior; limits will be tuned over time.
QNR-EXPLORER-001 — Slow index after restarts
- Severity: Sev-2 for UX; chain itself unaffected.
- Symptoms: explorer lags behind head for some minutes after infra restarts or upgrades.
- Workaround: use direct RPC calls or local nodes for authoritative height.
- Status: expected during early Devnet-0; indexing pipeline will be tuned as we gather usage data.
Frontend notes
- □ See Wallet & Faucet runbook for end-to-end flows.
- □ Use Integration guide for building dApps against Devnet-0.
- □ Report explorer discrepancies with block hash, height, and timestamps.
5 • Tooling & docs
Tooling, scripts, and documentation gaps
Rough edges in CLI tools, scripts, and docs that we already know about — plus where to look for updates.
QNR-TOOLS-001 — Scripts tuned for Linux first
- • Some shell scripts and make targets assume a Linux-like environment (GNU tools, bash).
- • macOS and WSL users may need minor adjustments or containers.
- • Status: expected in early Devnet-0; cross-platform notes will land in Devnet-0 launch checklist.
QNR-DOCS-001 — Docs lagging behind latest release
- • In fast iterations, docs may briefly lag the binaries or chain-specs.
- • If flags differ, trust the release notes and Release Artifacts first.
- • Status: permanent risk; minimized via post-incident reviews and docs checklists.
Tooling & docs — where to look
- □ STATUS — Devnet-0-wide change log and high-level notes.
- □ CHANGELOG / DEVLOG — per-release and per-week detail.
- □ Spec signing & verification — verifying you're running the intended bits.
6 • Reporting & lifecycle
How to report new issues and follow their lifecycle
A short path from “I saw something weird” to a tracked known issue with a clear status.
6.1 — Before you file
- □ Check /status and this page for existing matches.
- □ Run through the relevant sections of the Troubleshooting guide.
- □ Capture logs, metrics, timestamps, and recent changes.
- □ Decide whether it looks like Sev-1, 2, or 3.
6.2 — Filing & follow-up
- □ Share a concise incident report in validator / ops channels.
- □ Open or link a GitHub issue in the relevant repo with full reproduction details.
- □ Once triaged, we'll add it here with an ID, status, and workaround.
- □ For Sev-1/2, expect an associated incident entry and, when appropriate, a postmortem.
Next steps
From Devnet-0 rough edges to mainnet polish
Devnet-0 is where we deliberately surface problems early. The more we track here, the smoother public testnet and mainnet will be.
Treat this page as a living map of what's still rough on Devnet-0. If something bites you and it's not listed here, that's a strong signal we should document it.
Combined with Incident Response, Security checklist and Validator runbook, this page helps us turn Devnet-0 into a repeatable, predictable environment — the foundation for a serious public testnet and mainnet.