Skip to main content

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.

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 custody 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

Validator 1

Operator: TBD Region: TBD P-256 pubkey: TBD Solana pubkey: TBD Pearl node: TBD

Validator 2

Operator: TBD Region: TBD P-256 pubkey: TBD Solana pubkey: TBD Pearl node: TBD

Validator 3

Operator: TBD Region: TBD P-256 pubkey: TBD Solana pubkey: TBD Pearl node: TBD

Validator 4

Operator: TBD Region: TBD P-256 pubkey: TBD Solana pubkey: TBD Pearl node: TBD
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.

​
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 Hot Reserve.
  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 — 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 — 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.