Node Deployment & Operations
Relevant source files
The following files were used as context for generating this wiki page:
Node Deployment & Operations encompasses the lifecycle management, infrastructure setup, and real-time monitoring of X3 Chain validators and relayers. This system ensures network survivability through deterministic execution, GPU-parallel verification, and rigorous launch gates designed for institutional-grade reliability.
The scope includes initial genesis ceremonies, automated bootstrapping of local and public testnets, and the management of high-throughput relayer services that connect EVM and SVM environments. Operational excellence is maintained through structured incident response playbooks and performance baselines that track blocks polled and proofs submitted.
Sources: launch-gates/GENESIS_CEREMONY_CHECKLIST.md, MAINNET_LAUNCH_CHECKLIST.md, crates/x3-relayer/PHASE_13F_QUICK_REFERENCE_GUIDE.md
1. Genesis & Deployment Lifecycle
The deployment process follows a strictly gated progression from local development to a 3-validator local testnet, and finally to a mainnet genesis ceremony. The genesis ceremony is a one-time irreversible event where Chain IDs, canonical supplies, and initial validator sets are finalized.
1.1 Deployment Gate Progression
Deployment is segmented into distinct phases to ensure binary pass/fail readiness before moving to more complex environments.
| Phase | Description | Key Requirement |
|---|---|---|
| Phase 1 | Node Binary | cargo build --release -p x3-chain-node completes without error |
| Phase 2 | Single Dev Node | Block production begins within 10 seconds with --chain=dev |
| Phase 3 | 3-Validator Local | All 3 validators peered with GRANDPA finality active |
| Phase 13 | Genesis Ceremony | Raw spec SHA256 computed and published; TAG pushed |
Sources: MAINNET_LAUNCH_CHECKLIST.md:16-56, 185-201
1.2 Genesis Configuration Workflow
The genesis ceremony involves locking protocol versions and immutable chain specifications. This ensures all network participants start from a synchronized state root.
The diagram shows the sequential steps required to finalize the network identity and initial state before the first block is produced.
Sources: launch-gates/GENESIS_CEREMONY_CHECKLIST.md:15-132
2. Relayer Infrastructure & Operations
Relayers are critical components that facilitate cross-VM transfers by polling blocks from external chains and submitting proofs to the X3 runtime.
2.1 Relayer Start-up & Health
Launch execution for the relayer service is time-bound, focusing on immediate performance verification within the first hour of operation (T+0h to T+1h).
- Service Management: Managed via
systemctl(e.g.,sudo systemctl start x3-relayer). - Log Monitoring: Tracking "Block X polled" entries to confirm active synchronization.
- Verification: Confirming EVM and SVM polling starts within 5 minutes of execution.
Sources: crates/x3-relayer/PHASE_13F_QUICK_REFERENCE_GUIDE.md:28-56
2.2 Relayer Operational Tasks
The diagram illustrates the relayer's continuous polling loop across different execution environments and the submission of cryptographic proofs to the central runtime.
Sources: crates/x3-relayer/PHASE_13F_QUICK_REFERENCE_GUIDE.md:96-103, crates/x3-relayer/PHASE_13F_DAILY_STATUS_TEMPLATE.md:73-81
3. Validator Management
Validators are responsible for block production using Aura round-robin mechanisms and GRANDPA finality.
3.1 Performance Baselines
Validators are measured against specific throughput and resource targets to ensure network stability.
| Metric | Target (EVM) | Target (SVM) | Target (Proofs) |
|---|---|---|---|
| Throughput | 4-5 blocks/min | 8-10 blocks/min | 2-4 proofs/min |
| Latency | 60-180s | 10-50s | 5-30s |
| Resource Utilization | < 70% CPU | < 60% Memory | < 70% Disk I/O |
Sources: crates/x3-relayer/PHASE_13F_DAILY_STATUS_TEMPLATE.md:71-105
3.2 Operational Lifecycle
Validator operations include adding/removing nodes, rotating session keys, and recovering from slashing events. High-availability setups often involve GPU acceleration to handle parallel execution requirements.
Sources: crates/x3-relayer/PHASE_13F_MASTER_INDEX.md:46-56, plans/PHASE_5_IMPLEMENTATION_PLAN.md:15-30
4. Incident Response & Monitoring
The project utilizes a structured "Something Is Wrong" decision tree for rapid incident triage during launch and steady-state operations.
4.1 Incident Triage Flow
The triage flow helps operators quickly identify whether a failure resides in the local service, the RPC provider, or the blockchain runtime.
Sources: crates/x3-relayer/PHASE_13F_QUICK_REFERENCE_GUIDE.md:58-71
4.2 Recovery Procedures
| Incident | Detection | Immediate Action |
|---|---|---|
| Relayer Crash | systemctl status down | sudo systemctl restart x3-relayer |
| RPC Down | Polling stops in logs | Failover to backup provider |
| Memory Leak | Memory > 80% utilization | Restart service; check GPU/CUDA |
| Proof Failure | Proof queue > 20 | Verify account nonces and X3 runtime |
Sources: crates/x3-relayer/PHASE_13F_QUICK_REFERENCE_GUIDE.md:73-86, crates/x3-relayer/PHASE_13F_MASTER_INDEX.md:143-150
5. Security & Infrastructure Hardening
Before mainnet launch, several security gates must be passed, including the removal of development seeds and the pinning of toolchains.
- Binary Integrity: Verification that no
unwrap()orpanic!()calls exist in production paths reachable from extrinsics. - Credential Security: Ensuring no private keys or "Alice/Bob" dev seeds are committed to the repository or included in the chain spec.
- Infrastructure: Monitoring via Prometheus/Grafana with alerts for block production stalls exceeding 2 minutes.
Sources: MAINNET_LAUNCH_CHECKLIST.md:73-85, 126-130, launch-gates/GENESIS_CEREMONY_CHECKLIST.md:215-225
The Node Deployment & Operations framework provides a rigorous path from development to a secure mainnet environment. By combining strictly gated deployment phases, detailed incident response playbooks, and standardized performance monitoring, the system maintains high survivability and institutional-grade reliability for the X3 Chain ecosystem.