> ## 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.

# Pearl side

> Taproot reserves on Pearl: Deposit Address and Cold Reserve.

Nacre uses BIP-341 Taproot on Pearl. The per-user Deposit Address and the
shared Cold Reserve are both Taproot outputs with a key-path controlled by
the validator quorum (indirectly, via a TEE-enforced signing quorum) and
a single script-path leaf for emergency recovery.

The BIP-341 internal key used for both reserves is a single secp256k1
public key, "Wallet A", held inside a **TEE-enforced signing quorum**.
The 3-of-4 P-256 validator quorum is the wallet's authorization set: the
TEE will only produce a Wallet A signature when the validators' P-256
signatures meet threshold. The actual Schnorr signature that lands on
Pearl comes from Wallet A's single secp256k1 key, not from the validators
directly. This is what we mean below when we say a path is "controlled
by the validator quorum".

## Deposit Address (per user)

```
Deposit Address = Taproot(
  internal_key = TEE-enforced signing quorum (secp256k1, Wallet A),
  script_tree  = [
    leaf 0: <1008> OP_CSV OP_DROP <user_xonly_pubkey> OP_CHECKSIG
  ]
)
```

* **Key-path** sweeps user deposits into the Cold Reserve once the
  validator quorum authorizes Wallet A to sign.
* **Script-path** lets the user reclaim their deposit after 7 days (1,008
  blocks) with no validator involvement.

Each user gets a *distinct* Deposit Address. The user-emergency x-only
in the script-path leaf is produced client-side by signing a canonical
message with the user's Solana wallet (`signMessage`) and feeding the
ed25519 signature through HKDF-SHA256. Only the Solana secret key
holder can reproduce the signature — and therefore only they can sign
the script-path spend. The resulting x-only is committed on-chain at
`create_hot_reserve`; anyone can re-derive the Deposit Address from
that x-only and verify it against the on-chain record before
depositing.

## Cold Reserve (shared vault)

```
Cold Reserve = Taproot(
  internal_key = TEE-enforced signing quorum (secp256k1, Wallet A),
  script_tree  = [
    leaf 0: <1008> OP_CSV OP_DROP <admin_3of5_musig2_pubkey> OP_CHECKSIG
  ]
)
```

* **Key-path** pays out user redemptions and rotations: the validator
  quorum authorizes Wallet A, and Wallet A produces the on-chain Schnorr
  signature. This is the normal-operations path.
* **Script-path** is **emergency only.** Admin (3-of-5 multisig, aggregated
  via MuSig2) can sweep the Cold Reserve after a 7-day timelock if the
  validator quorum is permanently lost. Off-chain monitors publicly log any
  use of this path.

## Deposit Address derivation

A user's Deposit Address is built as follows:

1. **User-emergency x-only.** The user's Solana wallet signs a canonical
   message — a fixed-layout 62-byte payload containing a domain tag,
   the network, and the owner's Solana pubkey. HKDF-SHA256 over the
   resulting 64-byte ed25519 signature (with tag
   `nacre-hot-reserve-user-key-v2`) yields a secp256k1 secret; its
   x-only is the user-emergency pubkey committed on-chain at
   `create_hot_reserve`.
2. **Internal key.** The TEE-enforced signing quorum (Wallet A,
   secp256k1) is the Taproot internal key — shared across all users.
3. **Taproot tweak.** BIP-341 tweak of the internal key against the
   single-leaf script `<1008> OP_CSV OP_DROP <user_emergency_xonly>
   OP_CHECKSIG`. The tweaked key is the Deposit Address.

ed25519 is deterministic (RFC 8032), so the same Solana wallet on the
same message always produces the same signature and therefore the same
Deposit Address. Implementations of the derivation are cross-validated
against shared test vectors so the SDK, validator, indexer, and reclaim
CLI all agree byte-for-byte.