What Privy actually does

To understand why embedded wallets are secure, we must look beneath the React hooks and study the cryptographic mechanics. If a web application manages private keys directly in memory or local storage, a single Cross-Site Scripting (XSS) vulnerability or compromised npm package could steal every user's wallet.

Privy prevents this using Multi-Party Computation (MPC) and Hardware Security Modules (HSMs).

1. Key Sharding: Shamir's Secret Sharing in Practice

Instead of generating a standard private key file and saving it to a server, Privy uses MPC to split the wallet credentials into three distinct mathematical pieces called shares:

1. The Device Share: Stored on the user's physical device (safeguarded by secure browser storage like IndexedDB, protected by browser sandboxing).
2. The Auth Share: Maintained by Privy's authentication servers, tied directly to the user's identity validation (like their Google OAuth token).
3. The Recovery Share: Encrypted with a user-defined password or recovery system, stored separately.

                  +-----------------------------------+
                  |        ORIGINAL PRIVATE KEY       |
                  |     (Never reconstructed whole    |
                  |       in single memory space)     |
                  +-----------------------------------+
                                    │
               ┌────────────────────┼────────────────────┐
               ▼                    ▼                    ▼
     +-------------------+ +------------------+ +-------------------+
     |   DEVICE SHARE    | |    AUTH SHARE    | |  RECOVERY SHARE   |
     | (IndexedDB / iOS) | |  (Privy HSM)     | | (User Recovery)   |
     +-------------------+ +------------------+ +-------------------+
               │                    │
               └─────────┬──────────┘
                         ▼
             [ Threshold: 2-of-3 MPC ] ──> Sign UserOperation

To sign a transaction, the client-side SDK coordinates a cryptographic handshake. It uses a 2-of-3 threshold signature protocol (typically threshold ECDSA):

• The device share and the auth share collaborate mathematically to generate a valid ECDSA signature.
• CRITICAL: The full private key is never assembled in a single memory space or sent over the network. The signature is computed distributively.

2. Hardware Security Modules (HSMs)

Where does the Auth Share live? It resides inside an HSM (Hardware Security Module) hosted by Privy.

• An HSM is a physical, tamper-evident computer hardware component that executes cryptographic operations inside a hardened, isolated environment.
• The auth share is stored inside the HSM's volatile memory.
• The HSM will only release or use its share to generate signatures if the user presents a valid, authenticated JWT (JSON Web Token) from the social login provider (e.g. Google's OAuth server validating the email address).

3. Non-Custodial Guarantee

Because Privy requires two shares to sign transactions:

• Privy cannot sign transactions on behalf of the user (Privy only holds the Auth Share).
• The developer cannot steal user funds (the developer holds zero shares).
• The user can recover their account on a new device by combining the Auth Share with their Recovery Share.

This ensures the user maintains sole authority over their cryptographic identity, meeting the decentralization requirements of Web3 while matching the UX of Web2.