> ## 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. # Risks & mitigations > Where Nacre's trust assumptions are weakest, and how the protocol is designed to limit blast radius. Nacre is an **early-stage protocol**. Both the on-chain Solana programs and the off-chain validator code are **unaudited** as of this writing. The sections below describe the most material risks and the design choices, operational controls, and roadmap items that mitigate them. None of this substitutes for a formal audit; the protocol is designed so that even under worst-case assumptions, user funds remain recoverable through the documented emergency paths. Do not deposit more PRL than you are willing to put at risk while audits and operational hardening are still in progress. Always verify reserve and program addresses against the [addresses page](/protocol/addresses) before signing. ## Smart-contract risk The Anchor programs (`nacre_two_way_peg`, `nacre_liquidity_management`, `nacre_layer_ca`, `nacre_protocol_config`) and the supporting off-chain crates have not yet received an external security audit. Bugs in any of them — particularly the mint/burn state machine — could result in incorrect supply or stuck funds. **How the design limits the blast radius:** * The Solana side is intentionally **small and narrow**. Across the four Anchor programs, only a handful of instructions are callable by non-admin, non-validator accounts (e.g. `request_withdrawal`, `cancel_expired_withdrawal`, `create_hot_reserve`, `recover_hot_reserve`, `init_user_setting`). Every instruction that actually moves PRL on Pearl or mints/burns wPRL on Solana requires a validator-quorum attestation, so the user-callable surface area cannot unilaterally move funds. * `wPRL` is a **standard Token-2022 mint**. The token itself does not introduce custom transfer hooks beyond the protocol's transfer-fee configuration, so wallets, DEXs, and indexers interact with it the same way they interact with any other Token-2022 mint. * Every program is independently upgradeable by the admin multisig under a timelock, so a discovered bug can be patched without redeploying the rest of the system. ## Validator risk The validator binary (`nacre-validator`) is also unaudited. A bug in proposal construction, signing, or deduplication could cause validators to attest to invalid state. Validators are independent oracles — they do not gossip — so determinism bugs are the primary class of concern. **How the design limits the blast radius:** * **Independent infrastructure per validator.** Each validator runs its own Pearl full node and subscribes to a distinct set of upstream Pearl RPC providers that it hosts itself. Those Pearl nodes have different peer sets and only treat a Pearl block as final after observing the configured confirmation depth (6 confirmations). A single upstream Pearl outage or reorg cannot move the bridge. * **Multiple reputable upstream RPC connections per validator.** Each validator multiplexes across multiple reputable upstream RPC providers for both Pearl and Solana. A single upstream provider being wrong, censoring, or compromised is not sufficient to advance the bridge. * **Validators are not externally addressable.** The validator nodes accept no inbound connections from the public internet, and **no one has shell access** to the running validator hosts. Operator changes go through a reproducible rebuild-and-deploy pipeline, not interactive sessions. This sharply reduces the surface for remote compromise. * **Distributed operators are coming.** The genesis set is operated by the founding team; the roadmap moves the validator set to independent third-party operators with disjoint key custody and jurisdictions, so no single party can produce a quorum. * **Quorum-only authority.** A single validator cannot move any funds. All fund movements require a 2-of-3 quorum (see the [validators page](/protocol/validators) for the active topology). * **Deterministic, equivocation-detectable signing.** Proposals are built from finalized state with canonical Borsh encoding, so two honest validators must produce byte-identical signatures over the same `proposal_id`. Any validator that signs conflicting proposals is publicly observable on chain. ## Custody risk (Pearl reserves) The Pearl-side reserves (Cold Reserve and Hot Reserve) hold the PRL backing all outstanding wPRL. If the keys controlling those reserves were compromised, an attacker could move user funds on Pearl directly. **How the design limits the blast radius:** * **The private key has never existed outside Privy's secure infrastructure.** The Cold Reserve key is held inside a Privy wallet; Nacre never generates, exports, or stores the raw key material. Validators sign authorization payloads through Privy's API rather than ever touching the underlying secret. * **2-of-3 Privy signer quorum.** Three independent authorization signers are attached to the Privy wallet, and **a quorum of 2 of those 3 signers must independently cryptographically sign** each Privy request before any PRL can move out of the Cold Reserve. A single compromised signer cannot move funds. * **Self-custodial 7-day emergency exit.** The Cold Reserve Taproot output has a script-path leaf that lets the admin multisig recover funds after a 7-day CSV (≈1008 blocks) timeout. This is a strict fallback for the case where validators or Privy become unavailable, and the timelock window gives users time to react. * **Reserve addresses are pinned and verifiable.** Every reserve address is published on the [addresses page](/protocol/addresses) and pinned in the open-source clients. Any divergence between the published address and what you see in a wallet is grounds to refuse to sign. ## Liveness risk Validators, Privy, the signature aggregator, and the underlying Pearl and Solana networks can each individually go offline. Most failure modes are **liveness-only** — they delay mints and burns but do not put user funds at risk. The 7-day Cold Reserve emergency exit is the ultimate liveness escape hatch: even if the entire validator + Privy stack is permanently unavailable, the admin multisig can recover the reserve and users can be made whole. ## Reporting issues Please report suspected vulnerabilities responsibly. Coordinated disclosure details and the security contact will be published on the [validators page](/protocol/validators) ahead of mainnet.