> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plasma.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Preparation

> Preparing for future consensus node operation on Plasma mainnet

This guide outlines expected requirements, preparation steps, and how to gain early operational experience.

> [!NOTE]
>
> Consensus node access will begin post-mainnet. No fixed timeline is available, but early preparation improves readiness and positioning.

## Why Prepare Now

> [card] Early access advantage
>
> First operators will help shape network decentralization and may benefit from reduced validator competition.

> [card] Hands-on experience
>
> Operating non-validating nodes provides familiarity with Plasma's infrastructure, monitoring, and performance patterns.

> [card] Reputation and community alignment
>
> Active testnet contributors demonstrate long-term commitment and reliability.

> [card] Deployment readiness
>
> Early validation of infrastructure and operational processes ensures faster onboarding at mainnet.

## Requirements

> [!WARNING]
>
> Final requirements will be confirmed closer to mainnet. The following estimates are based on Plasma’s consensus design and comparable BFT-based networks.

### Hardware

> [tab] Minimum
>
> | Resource | Specification |
> | :- | :- |
> | CPU | 4+ cores at 3.0+ GHz |
> | RAM | 16+ GB |
> | Storage | 1+ TB NVMe SSD |
> | Network | 1 Gbps symmetric, \<50ms latency to major hubs |

> [tab] Recommended
>
> | Resource | Specification |
> | :- | :- |
> | CPU | 8+ cores at 3.5+ GHz (latest generation) |
> | RAM | 32+ GB |
> | Storage | 2+ TB NVMe SSD with high IOPS |
> | Network | Multiple 1 Gbps connections with redundancy |

> [tab] Enterprise
>
> | Resource | Specification |
> | :- | :- |
> | CPU | 16+ cores or dual-socket configuration |
> | RAM | 64+ GB |
> | Storage | Enterprise NVMe with RAID redundancy |
> | Network | 10+ Gbps with multiple providers |

### Infrastructure

* **Uptime**: ≥99.9% with failover mechanisms
* **Security**: HSM-backed key management, network isolation
* **Monitoring**: Real-time alerting for consensus status and system health
* **Redundancy**: Backup power, multi-path networking, spare hardware

## Preparation Steps

### 1. Start with Non-Validator Nodes

Deploy on testnet to establish baseline experience. See the [Non-Validator Node Setup Guide](https://docs.plasma.org/docs/node-operators/setup-and-configuration/non-validator-node-setup.md).

**Operational exposure:**

* Hardware sizing and performance tuning
* Consensus endpoint connectivity
* Monitoring and alerting stack
* Upgrade and maintenance cycles

**Experiment with:**

* Latency testing across regions
* Failover and restart behavior
* Cost vs. reliability tradeoffs
* Scale testing under simulated load

### 2. Build Operational Expertise

#### Monitoring

Set up observability systems using:

* **Prometheus** – Metrics collection
* **Grafana** – Dashboards and visualizations
* **Alertmanager** – Alert routing
* **Custom checks** – Plasma-specific probes and RPC health

#### Security

Define and test:

* Key management procedures
* Network segmentation and firewall rules
* Role-based access and authentication
* Incident detection and response plans

#### Documentation

Maintain internal runbooks for:

* Node deployment and config
* Routine operations and patching
* Failure recovery and incident handling
* Performance tuning and capacity planning

Preparing now ensures smoother onboarding when consensus participation opens. Operators with proven testnet performance, reliable infrastructure, and robust processes will be well-positioned for mainnet validator roles.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.