Skip to main content
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)

  • 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)

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