# Running a Validator

## Become a Goliath Validator

{% hint style="warning" %}
**Preview Testnet Phase**

Validator onboarding is currently coordinated and approval-based during the preview testnet phase.
{% endhint %}

If you want to run a validator, start here:

* Contact **Onyx DAO** on Telegram: <https://t.me/theonyxdao>

***

## Validator Deployment Process

This is the official non-technical onboarding flow for validator operators.

It follows Goliath’s validator onboarding lifecycle operated by Onyx DAO.

### Before You Start

On Goliath, validator onboarding uses a **managed deployment model**:

* Onyx DAO provides the approved validator software package.
* Onyx DAO coordinates activation windows and network-side steps.
* Validator teams focus on hosting, operations readiness, and ongoing uptime.

This makes onboarding easier and reduces setup risk.

***

## System Requirements

## Minimum Hardware Specifications

| Component    | Minimum               | Recommended            | Critical Notes                      |
| ------------ | --------------------- | ---------------------- | ----------------------------------- |
| CPU          | 24 cores / 48 threads | 32+ cores              | Intel Xeon or AMD EPYC, x86-64 only |
| RAM          | 256 GB DDR4 ECC       | 320+ GB DDR5 ECC       | ECC is mandatory                    |
| Boot Storage | 240 GB SSD (RAID 1)   | 2x 480 GB SSD (RAID 1) | Redundant OS volume                 |
| Data Storage | 5 TB NVMe             | 8+ TB NVMe (RAID 10)   | 2+ GB/s write, 250K+ IOPS           |
| Network      | 1 Gbps sustained      | 10 Gbps port           | Static IP required, no NAT          |
| Hosting      | Dedicated bare metal  | Tier 1 data center     | VPS/VM NOT acceptable               |

## CPU Requirements

| Attribute            | Specification                                       |
| -------------------- | --------------------------------------------------- |
| Architecture         | x86-64 (Intel Xeon Scalable or AMD EPYC)            |
| Minimum Cores        | 24 physical cores / 48 threads                      |
| Clock Speed          | 2.5 GHz+ base, 3.0 GHz+ turbo                       |
| Benchmark (Passmark) | Single-thread 2300+ (required), 2800+ (recommended) |

Why it matters: Consensus nodes perform intensive cryptographic operations. A slow CPU causes the node to fall behind and trigger consensus failures.

Avoid:

* ARM processors (not supported)
* Consumer-grade CPUs (inadequate cache, no ECC support)
* Low-frequency server CPUs (single-thread performance matters)

## Memory Requirements

| Attribute        | Specification                             |
| ---------------- | ----------------------------------------- |
| Minimum Capacity | 256 GB                                    |
| Recommended      | 320 GB+                                   |
| Type             | DDR4 ECC Registered (3200MHz) or DDR5 ECC |
| ECC              | MANDATORY                                 |

Why ECC is mandatory: A single bit flip in the in-memory state causes the node to compute a different state hash than other validators, triggering consensus failure. At the scale of 256 GB with constant activity, soft errors are statistically inevitable without ECC.

What happens with insufficient memory:

| Heap Size  | Observed Behavior             |
| ---------- | ----------------------------- |
| 6 GB       | Out of memory within hours    |
| 16 GB      | Out of memory after \~5 days  |
| 48 GB      | Stable at low TPS with tuning |
| 192-256 GB | Required for mainnet loads    |

## Storage Requirements

Boot Volume (OS):

* 2x 240 GB SSD minimum in RAID 1 (mirror)
* Purpose: Operating system, logs, management tools

Data Volume (Blockchain State):

| Attribute        | Specification                   |
| ---------------- | ------------------------------- |
| Capacity         | 5 TB minimum, 8+ TB recommended |
| Type             | NVMe SSD (enterprise-grade)     |
| Configuration    | RAID 0 or RAID 10               |
| Sequential Write | 2,000+ MB/s                     |
| Random Read IOPS | 250,000+                        |

Storage Growth Projections:

| Network Load         | Daily Growth | Year 1 Total |
| -------------------- | ------------ | ------------ |
| 10 TPS (testnet)     | \~500 MB     | \~200 GB     |
| 50 TPS (low mainnet) | \~3 GB       | \~1.1 TB     |
| 200 TPS (moderate)   | \~15 GB      | \~5.5 TB     |

## Network Requirements

| Attribute  | Specification                    |
| ---------- | -------------------------------- |
| Bandwidth  | 1 Gbps sustained (not burstable) |
| IP Address | Static IPv4, publicly routable   |
| NAT        | Not supported                    |
| Latency    | <100ms to other validators       |

Required Ports:

| Port  | Protocol | Direction | Purpose                        |
| ----- | -------- | --------- | ------------------------------ |
| 50111 | TCP      | In + Out  | Gossip protocol (node-to-node) |
| 50211 | TCP      | Ingress   | gRPC API                       |
| 50212 | TCP      | Ingress   | TLS-encrypted gRPC             |
| 123   | UDP      | In + Out  | NTP time synchronization       |

## Hosting Requirements

## VPS vs. Bare Metal: Why VPS is NOT Acceptable

| Factor              | VPS Risk            | Consensus Impact                                 |
| ------------------- | ------------------- | ------------------------------------------------ |
| CPU steal           | Noisy neighbors     | GC pauses extend -> node falls behind -> failure |
| Memory overcommit   | Hypervisor swapping | Catastrophic performance degradation             |
| Disk I/O contention | Shared storage      | State writes stall -> consensus failure          |
| Network jitter      | Virtual networking  | Gossip delays -> consensus divergence            |

Acceptable Hosting Options:

| Option                                        | Verdict                   | Notes                           |
| --------------------------------------------- | ------------------------- | ------------------------------- |
| Dedicated bare metal (Hetzner, OVH, Equinix)  | Recommended               | Full hardware isolation         |
| Cloud bare metal (AWS i3en.metal, Azure LSv3) | Acceptable                | No hypervisor, but expensive    |
| Colocation                                    | Ideal for large operators | Own hardware, rented rack space |
| Standard VPS / cloud VM                       | NOT ACCEPTABLE            | Causes failures                 |

Data Center Requirements:

* Tier III or higher (N+1 redundancy)
* Redundant power (UPS + generator)
* Redundant cooling
* Physical security (badge access, cameras)

## Operating System

| Attribute    | Specification              |
| ------------ | -------------------------- |
| Supported OS | Ubuntu 22.04 LTS (64-bit)  |
| Alternative  | RHEL 8/9, Oracle Linux 8/9 |
| Kernel       | 5.15.x or 6.x LTS          |

Required Software:

| Component      | Version  | Purpose                 |
| -------------- | -------- | ----------------------- |
| Docker Engine  | 20.10.6+ | Container runtime       |
| Docker Compose | 1.29.2+  | Container orchestration |
| JQ             | 1.5+     | JSON processing         |
| cURL           | 7.58+    | API health checks       |

***

## Step 1: Contact Onyx DAO and Apply

### What you do

1. Reach out to Onyx DAO on Telegram.
2. Share your organization name and validator interest.
3. Provide a technical and operational point of contact.

### What Onyx DAO does

1. Opens your onboarding thread.
2. Shares the onboarding checklist and target timeline.
3. Schedules kickoff.

### Exit criteria

* Your onboarding request is accepted and tracked.

***

## Step 2: Kickoff and Planning

### What you do

1. Join the kickoff telegram group.
2. Confirm your team roles (technical owner, operations owner, on-call owner).
3. Confirm preferred deployment windows (UTC).

### What Onyx DAO does

1. Explains the full validator deployment path.
2. Defines responsibilities between your team and Onyx DAO.
3. Confirms communication and incident escalation channels.

### Exit criteria

* Roles, timeline, and communications are agreed.

***

## Step 3: Infrastructure Readiness Review

### What you do

1. Prepare production-grade validator infrastructure.
2. Confirm stable connectivity, static public networking, and operational monitoring.
3. Confirm your team can support 24/7 operations.

### What Onyx DAO does

1. Reviews your readiness evidence.
2. Validates your host and network profile against validator standards.
3. Approves or returns a remediation list.

### Exit criteria

* Your environment is approved for deployment.

***

## Step 4: Validator Package and Environment Preparation

### What you do

1. Prepare the host environment for the managed validator package.
2. Follow the setup checklist exactly as provided by Onyx DAO.
3. Complete pre-deployment checks.

### What Onyx DAO does

1. Provides the approved validator package.
2. Provides deployment instructions and required settings.
3. Verifies package integrity and readiness with you.

### Exit criteria

* Environment is prepared and validated for activation.

***

## Step 5: Identity, Security, and Node Registration

### What you do

1. Complete validator identity and key readiness requirements.
2. Submit required public onboarding artifacts to Onyx DAO.
3. Confirm your security and backup procedures are in place.

### What Onyx DAO does

1. Validates onboarding artifacts.
2. Handles network registration and node activation transactions.
3. Schedules the activation window.

### Exit criteria

* Your validator is approved for activation.

***

## Step 6: Deployment Window and Network Activation

### What you do

1. Join the live activation window.
2. Execute only the operator steps requested by Onyx DAO.
3. Keep your team available until activation completes.

### What Onyx DAO does

1. Runs the network-side activation sequence.
2. Coordinates restart and activation order.
3. Validates consensus health during rollout.

### Exit criteria

* Your validator joins the active validator set successfully.

***

## Step 7: Post-Activation Validation

### What you do

1. Confirm your validator remains healthy after activation.
2. Monitor for stability during the agreed soak period.
3. Report anomalies immediately in the onboarding channel.

### What Onyx DAO does

1. Verifies network stability after validator addition.
2. Confirms your node status and onboarding acceptance checks.
3. Clears your validator for steady-state operations.

### Exit criteria

* Post-activation checks pass and onboarding is marked complete.

***

## Step 8: Handover to Ongoing Operations

### What you do

1. Move to normal validator operations.
2. Keep on-call coverage active.
3. Follow ongoing maintenance and incident procedures.

### What Onyx DAO does

1. Finalizes operational handover.
2. Confirms reward and participation configuration.
3. Transitions your team to steady-state governance and operations.

### Exit criteria

* Validator is fully onboarded and in normal operations.

***

## Important Operational Rules

To protect network stability, these rules apply during and after onboarding:

1. Do not perform unplanned validator restarts.
2. Never perform unilateral restart actions during an incident.
3. For any validator status problem, contact Onyx DAO first and follow coordinated recovery steps.
4. Keep backups and operational monitoring active at all times.

These controls are critical for avoiding consensus instability during validator operations.

***

## Typical Onboarding Timeline

| Stage                     | Typical Duration |
| ------------------------- | ---------------- |
| Application + Kickoff     | 1-3 days         |
| Readiness Review          | 2-7 days         |
| Package Prep + Validation | 1-3 days         |
| Activation Window + Soak  | 1-2 days         |

Actual timing depends on infrastructure readiness and scheduling windows.

***

## Rewards and Next Reading

After onboarding, review:

* [Validator Rewards](/rewards/validator-rewards.md)
* [Slingshot Yield (Primary Staking)](/defi/slingshot/yield.md)
* [Validator Dashboard](/rewards/validator-dashboard.md)

If you are ready to begin, contact Onyx DAO:

* <https://t.me/theonyxdao>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.goliath.net/rewards/running-a-validator.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.