Nacre is a two-chain protocol with a handful of moving parts. This page gives a top-down view; the rest of the section drills into each piece: the Pearl side, the Solana side, and the signature aggregator. For where the architecture is headed next, see the Roadmap.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.
Trust model in one sentence
Every state transition that moves PRL or mints/burns wPRL requires a threshold signature from a quorum of independent validators, and every user deposit has a unilateral 7-day emergency exit.
System components
Validators
The quorum is not a consensus group. Validators do not gossip, vote, or exchange messages. Each independently observes both chains, builds proposals deterministically from finalized state, and signs the proposal hash with its P-256 key. Determinism is enforced by cross-implementation test vectors and fuzz harnesses, so two honest validators produce byte-identical proposals and reach the sameproposal_id. Equivocation is
observable on chain.
Operator details, security commitments, and the genesis validator set live
on the Validators page.
Authority hierarchy
| Authority | Role | Surface |
|---|---|---|
| Validator quorum (3-of-4) | Authorizes all normal mint, burn, and sweep operations | Pearl key-path + Solana mint/burn attestations |
| Admin multisig (3-of-5) | Cold Reserve emergency recovery; program upgrades; parameter changes; fee distribution | Pearl script-path leaf 0; Solana admin instructions |
| Signature aggregator | Pre-flight checks; cannot authorize anything | HTTP service, subtractive only |
| Off-chain monitor | Detects anomalies and alerts; cannot authorize anything | Pages on-call humans |