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

# Validator set

> The four independent operators that secure Nacre v1.

Nacre v1 is secured by a **3-of-4 quorum of independent validators**. Each
validator runs its own Pearl full node and Solana RPC, holds exactly one P-256
key in the TEE-enforced signing quorum, and signs attestations entirely on its own. There
is no leader, no shared state, and no gossip. Equivocation is observable on
chain.

## Why four independent operators

* **No single point of compromise.** Three of four validators must agree
  before PRL can move or wPRL can be minted or burned.
* **Liveness through redundancy.** Any one validator can be offline without
  halting the bridge.
* **Geographic and operational diversity.** Validators operate from different
  jurisdictions, on independent infrastructure, with disjoint key custody.
* **Open observability.** Each validator publishes its signing public key and
  its uptime metrics; anomalous behavior is publicly auditable.

## The Genesis Validators

<CardGroup cols={2}>
  <Card title="Validator 1" icon="server">
    **Operator:** `TBD`
    **Region:** `TBD`
    **P-256 pubkey:** `TBD`
    **Solana pubkey:** `TBD`
    **Pearl node:** `TBD`
  </Card>

  <Card title="Validator 2" icon="server">
    **Operator:** `TBD`
    **Region:** `TBD`
    **P-256 pubkey:** `TBD`
    **Solana pubkey:** `TBD`
    **Pearl node:** `TBD`
  </Card>

  <Card title="Validator 3" icon="server">
    **Operator:** `TBD`
    **Region:** `TBD`
    **P-256 pubkey:** `TBD`
    **Solana pubkey:** `TBD`
    **Pearl node:** `TBD`
  </Card>

  <Card title="Validator 4" icon="server">
    **Operator:** `TBD`
    **Region:** `TBD`
    **P-256 pubkey:** `TBD`
    **Solana pubkey:** `TBD`
    **Pearl node:** `TBD`
  </Card>
</CardGroup>

<Note>
  The genesis validator set will be announced ahead of mainnet launch. The four
  operators are independent organizations with no shared infrastructure,
  beneficial ownership, or key custody.
</Note>

## What each validator does

Every validator runs the same open-source binary, `nacre-validator`, and
performs the same loop independently:

1. **Watch Pearl.** Index every confirmed block, detect deposits to any
   Nacre-registered Deposit Address.
2. **Watch Solana.** Index events from `nacre_two_way_peg`: new withdrawal
   requests, completed attestations, parameter updates.
3. **Build proposals deterministically.** From finalized state alone, with no
   coordination, construct the next sweep, redemption, or attestation.
4. **Sign and publish.** Sign `sha256(canonical_borsh(proposal))` with the
   validator's P-256 key and POST to every signature aggregator.
5. **Repeat.** No persistent shared state, no leader rotation, no view changes.

Because the encoding is canonical and the state is finalized, two honest
validators must produce *byte-identical* proposals and therefore the same
proposal ID. Validators that produce different IDs are equivocating.

## Validator security

Each validator commits to:

* Running `nacre-validator` from a reproducibly-built release.
* Holding its P-256 key in an HSM or equivalent hardware-isolated store.
* Operating from infrastructure that is independent of the other validators.
* Publishing its uptime and signing latency.
* Disclosing any key compromise within 24 hours.

A validator can be rotated out (or in) by the admin multisig under §10.5 of
the protocol spec. In an emergency where a validator's key is compromised,
the emergency rotation flow in §10.6 lets the remaining quorum replace it
without waiting for the timelock.

## Becoming a validator

Validator slots are limited in v1 (four total). The path to a larger and more
diverse validator set is laid out on the [Roadmap](/protocol/roadmap); Phase
2 (FROST self-custody) is designed to scale the quorum and lower the
operational burden of each validator.

If you operate Pearl + Solana infrastructure and would like to be considered
for future validator slots, reach out via `TBD`.