# Security at MoonPay Wallets MoonPay Wallets uses multi-party computation (MPC) shares for standard signing. The client share is protected by passkeys, identity-backed encryption, or both. The server-side share participates through an isolated signer. The wallet's recovery and custody guarantees depend on how the client share is protected. [Identity-backed encryption](/security/identity-backed-encryption) adds trust in account access and a MoonPay-operated KMS key. MoonPay Wallets signs with published, peer-reviewed threshold protocols: DKLs23 for ECDSA and FROST for EdDSA. See [MPC key custody](/security/key-custody) for protocol references and audit history. ## Architecture at a glance Standard wallets use a 2-of-2 MPC model. One share participates from the client, and the server-side MPC signer holds the other. Both shares must participate to produce a signature. The full private key is not assembled during standard signing.
Signing architecture 2-of-2 signing: the client share and the signer share must both participate Client-share access depends on the user's passkey or identity-backed wrap.
Browser Secure wallet iframe MoonPay Wallets wallet and session APIs Signing infrastructure isolated signer and relay Client MPC share DEK unlocked by a passkey or an identity-backed wrap decrypted in the iframe to sign Wallet API key create / sign / prove Authentication API identity and sessions encrypted client shares MPC signer holds the server share TEE (AWS Nitro Enclave) cloud KMS at rest Relay room end-to-end encrypted MPC messages, no key material MPC protocol messages orchestrates the room
A standard signature requires both the client share and the signer share. Passkey-only wallets require the user's passkey to unlock the client share. Identity-backed wallets also permit access through an eligible signed-in session. The MPC signer runs in an AWS Nitro Enclave and encrypts its share at rest with cloud KMS. The relay is untrusted by design. All MPC protocol traffic through it is end-to-end encrypted between the participating shares, it holds no key material and provides no cryptographic services, so a relay compromise can cause downtime but cannot expose key shares or forge signatures. ## The security model in depth Multi-party computation from scratch: threshold signing versus key splitting, and why recovery needs the user. How wallet keys exist as shares, the signature schemes and audit history, and what each party can and cannot do. How client-share protection determines recovery and private-key export requirements. Session-authorized wallet access, the KMS trust model, and recovery without a passkey. The token model, refresh rotation and reuse detection, and the presence checks behind high-risk operations. User-provisioned agents, enclave attestation, and the two credentials required to sign. Wallet screening, address integrity proofs, blocked-account behavior, and what MoonPay Wallets does not hold.