Validator FAQ for Quantara Devnet-0

1.1 — Who should run a validator on Devnet-0?

• • Teams comfortable with Linux, systemd, and basic networking.
• • Infra providers, validators, and funds who want to rehearse before public testnet / mainnet.
• • Builders running wallets, explorers, or infra that depend on stable full nodes.
• • Operators willing to join incident drills and provide feedback.

1.2 — What’s the difference between Devnet-0 and public testnet?

• • Devnet-0 is closed and fast-moving — we break things on purpose.
• • Public testnet mirrors mainnet parameters more closely and is open to the wider community.
• • Lessons from Devnet-0 feed directly into testnet launch criteria.
• • Strong Devnet-0 operators are first in line for public testnet slots.

2.1 — Minimum hardware for Devnet-0

• • 4–8 vCPUs.
• • 16–32 GB RAM.
• • 1 TB NVMe SSD (higher IOPS is better).
• • Stable bandwidth, low packet loss.

See Devnet-0 launch checklist and Benchmarks guide for more detailed sizing and targets.

2.2 — Bare metal vs. cloud

• • Both are acceptable on Devnet-0.
• • Use bare metal if you want to practice your eventual mainnet topology.
• • Use cloud if you optimize for faster iteration and rebuilds.
• • Whatever you choose, document it in your internal runbooks.

2.3 — Observability requirements

• • Metrics stack (e.g., Prometheus + Grafana) strongly preferred.
• • Central log aggregation recommended.
• • Alerts for node down, no blocks, low peers, disk.
• • For patterns, see the Monitoring & observability doc.

3.1 — Is Devnet-0 real money?

• • No. Devnet-0 runs on QTR (devnet) — test tokens, no real-world value.
• • Balances and participation may inform future recognition, but there's no promise of automatic mainnet rewards.
• • Treat this as rehearsal for behaviors that will later carry economic weight.

3.2 — How does slashing work on Devnet-0?

• • Slashing on Devnet-0 is mostly simulated / experimental.
• • Expect us to run drills around downtime, equivocation, and other risky behaviors.
• • The point is to make sure you understand what would be dangerous on mainnet.
• • For deeper discussion, see the Runtime overview and future economics docs.

4.1 — How should I store validator keys?

• • Keep mnemonics offline in a password manager or HSM.
• • Separate stash, controller, and session roles.
• • Never paste mnemonics into random terminals or UIs.
• • Use dedicated, documented machines for signing where possible.

See Key management & backups and Security checklist for detailed guidance.

4.2 — What backup strategy should I use?

• • Backup node configs, systemd units, and scripts.
• • Store encrypted seed backups in multiple locations.
• • Consider periodic database snapshots for faster recovery.
• • Track backups and restores using an internal checklist.

The Backup & restore doc covers practical patterns and gotchas.

4.3 — What if I think a key is compromised?

• • Immediately rotate session keys and stop the node.
• • Move any remaining test funds to a safe account.
• • Document the event using the postmortem template.
• • Share a short summary with the Quantara team.

5.1 — How do I know if it’s just my node?

• • Compare your block height to the Status page and explorer.
• • Check peers and logs for obvious local errors (disk, network).
• • If others report healthy nodes at the same time, start with Troubleshooting steps.

5.2 — What if it looks like a network-wide issue?

• • Check for an active incident on the incidents page.
• • Capture a short log snippet and current block height.
• • Share details in validator / ops channels.
• • Follow the Incident response playbook and any incident-specific notes.

6.1 — What carries over from Devnet-0?

• • Your muscle memory: upgrades, incidents, key rotation, monitoring.
• • Your infra patterns: how you structure validators, sentries, and observability.
• • Your relationship with the Quantara team and other validators.
• • Lessons that shape launch criteria for public testnet.

6.2 — How do I stay close to updates?

• • Watch the Status and Devnet status pages.
• • Periodically skim STATUS.md and the CHANGELOG docs.
• • Keep an eye on DEVLOG entries for deeper engineering notes.
• • Stay active in validator and builder channels for early notices.