# MPC key custody
MoonPay Wallets uses threshold signing instead of storing a full private key. A wallet key exists as multi-party computation (MPC) shares, and signing is a distributed protocol in which each participating share contributes without revealing the underlying key material. If MPC is new to you, start with [What is MPC?](/security/what-is-mpc).
In the current production model:
* The client share is required for standard signing. Access to that share depends on the user's passkey or identity-backed wrap.
* The server-side signer share is required for signing, so a compromised browser share cannot sign by itself.
* Standard signing does not assemble the full private key. Import, export, and exportable ed25519 key generation handle the complete key in the user's browser.
* A user can provision an [ephemeral signer](/wallets/ephemeral-signers/overview), which reconstructs the key inside an attested signing enclave. See [Delegated signing](/security/delegated-signing).
A 2-of-2 design means both shares are needed. MoonPay Wallets therefore treats encrypted share recovery and user-controlled export as part of the custody model, not optional add-ons. See [Passkeys and recovery](/security/passkeys-and-recovery).
## Signature schemes
The MPC layer supports the signing schemes required by the chains supported by MoonPay Wallets:
* ECDSA over secp256k1 for Ethereum, EVM chains, Tron, and Bitcoin Native SegWit and Legacy wallets, signed with the [DKLs23](https://eprint.iacr.org/2023/765) threshold protocol.
* EdDSA over ed25519 for Solana, signed with [FROST](https://datatracker.ietf.org/doc/rfc9591/) (RFC 9591).
* BIP340 Schnorr for Bitcoin Taproot, signed with a threshold Schnorr protocol.
The threshold cryptography implementation is independently audited on a recurring basis, by NCC Group (September 2025), Trail of Bits (September 2024), and NCC Group (July 2023).
## Key generation and import
How a new wallet key is generated depends on the signature scheme:
* secp256k1 keys for Ethereum, EVM chains, Tron, and Bitcoin are born distributed: key generation is a distributed ceremony between the browser and the signer, and no complete private key exists at any point in the flow. A secp256k1 private key is a single scalar value, so a key born distributed can still be exported later in a chain-appropriate format.
* ed25519 keys (Solana) are generated so that export always stays possible. Wallets like Phantom expect an ed25519 private key in its standard seed form, and a key born distributed has no seed to export. So the user's browser samples the complete key and splits it into shares with the signer in the same ceremony. The complete key exists only transiently in the user's browser, the party the user already trusts with the client share, and never reaches MoonPay Wallets.
Bitcoin exports use compressed mainnet WIF. WIF contains the private scalar and public-key compression convention, but not the Taproot, Native SegWit, or Legacy script type. See [Bitcoin Overview and Wallet Types](/wallets/using-wallets/bitcoin/overview) for the recovery implications.
When a user imports an existing private key, the split happens in the browser:
* The import ceremony runs between the user's browser and the MPC signer. The signer participates only as a share recipient; the request it receives has no field for the full private key, so the complete key never reaches MoonPay Wallets.
* After the ceremony, the browser discards the imported key and keeps only the new encrypted client share.
* The imported address is compliance-screened before the wallet is persisted. See [Compliance and data handling](/security/compliance-and-data-handling).
## What each party can do
The server-side signer share cannot sign without the client share. Standard signing does not assemble the complete private key.
A user can explicitly export a wallet's private key. Export is its own user-initiated MPC ceremony that reconstructs the key in the user's browser, never on MoonPay Wallets servers.
Passkey-only protection keeps DEK decryption dependent on the user's passkey secret. [Identity-backed encryption](/security/identity-backed-encryption) adds a MoonPay-operated KMS route to the same DEK. An eligible session can unlock the client share, so passkey-only custody guarantees do not apply to identity-backed wallets.
The explicit exception is [delegated signing](/security/delegated-signing): a user can opt a wallet in to an [ephemeral signer](/wallets/ephemeral-signers/overview), and those signatures are produced inside an attested signing enclave that the regular MoonPay Wallets infrastructure cannot read. It is never enabled by default.