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

# Become a Validator

> Understand the validator program, operator requirements, and the fastest path to a live Superform validator node.

<Note>
  The validator program is currently permissioned. Ready to join? [Apply to become a validator](https://docs.google.com/forms/d/e/1FAIpQLSc63kVcrBLYYs2dtl16ZMABjNy5lRNBrHHcfOS6RUiARYU-fg/viewform?usp=send_form\&pli=1\&authuser=0).

  Before you start, confirm you have an onboarding contact at Superform and access to the validator artifacts you plan to run (published image or source repository), bootstrap peers, and the chain-specific contract addresses for your assigned deployment.
</Note>

Ready to join? [Apply to become a validator](https://docs.google.com/forms/d/e/1FAIpQLSc63kVcrBLYYs2dtl16ZMABjNy5lRNBrHHcfOS6RUiARYU-fg/viewform?usp=send_form\&pli=1\&authuser=0).

## What this program is

The SuperVaults Validator Network is the oracle layer that keeps vault price-per-share (PPS) data fresh and tamper-resistant. Validators run an OCR2-based node that:

* observes PPS on each configured chain
* signs consensus reports with a dedicated onchain key
* helps submit a single quorum-backed update onchain
* earns validator rewards for reliable participation

## Who should run a validator

This program is designed for operators who can run production infrastructure consistently, manage keys safely, and respond to incidents quickly. It is not a casual self-serve node today.

## Before you touch a server

Have these inputs lined up first:

* **Program access** — confirmation from Superform that your organization is approved to join
* **Runtime artifacts** — access to the published container image or the source repository and templates
* **Infrastructure** — a Linux or macOS host, PostgreSQL, stable outbound connectivity, and reliable RPC providers
* **Network metadata** — bootstrap peers, the current config version, and the contract addresses Superform wants you to monitor
* **Operator contact path** — a place to submit your public key bundle and coordinate registration

If any of those are missing, stop there. Most validator setup failures come from missing onboarding inputs, not from the software install itself.

## Read this section in order

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/build/become-a-validator/quickstart">
    The shortest safe path from approval to a running node.
  </Card>

  <Card title="Node Setup" icon="server" href="/build/become-a-validator/node-setup">
    Canonical install and runtime guide for Docker or source deployments.
  </Card>

  <Card title="Configuration Reference" icon="sliders" href="/build/become-a-validator/configuration-reference">
    Config reference for config.toml, chains.yaml, and OCR2 timing presets.
  </Card>

  <Card title="Monitoring" icon="chart-line" href="/build/become-a-validator/monitoring">
    Health endpoints, metrics, and alert rules for production operators.
  </Card>

  <Card title="Operations" icon="wrench" href="/build/become-a-validator/operations">
    Registration, upgrades, key rotation, monitoring checks, and troubleshooting.
  </Card>
</CardGroup>

## Supporting context

<CardGroup cols={2}>
  <Card title="How It Works" icon="diagram-project" href="/build/become-a-validator/how-it-works">
    OCR2 rounds, quorum, failure modes, and validator config mechanics.
  </Card>

  <Card title="Economics" icon="chart-pie" href="/build/become-a-validator/economics">
    Rewards, staking, slashing, insurance, and rollout phases.
  </Card>
</CardGroup>

## Operator model at a glance

| Topic                  | Current model                                              |
| ---------------------- | ---------------------------------------------------------- |
| Access                 | Permissioned onboarding through Superform                  |
| Validator registration | Superform submits `setValidatorConfig()`                   |
| Node reconfiguration   | Automatic from `ValidatorConfigSet` events                 |
| Key custody            | Operator-managed; onchain key should use KMS in production |
| Rewards and slashing   | Phase 2 design, not live in Phase 1                        |

## Safe order of operations

1. Confirm access and receive the required network metadata.
2. Stand up the node and validate local health.
3. Export and submit your public key bundle.
4. Wait for Superform to register your validator onchain.
5. Verify your node loads the new config and starts participating.
6. Put monitoring and incident response in place before treating the node as production.