How Privy embedded wallets work
Inside Privy’s architecture: how TEEs and key sharding power secure, performant embedded wallets at scale.
Andrew Hollenbach
|Jun 17, 2025
Embedded wallets have changed how users interact with onchain apps. When we started 3 years ago, wallets were effective but clunky and inaccessible. Users had to be sent off-platform just to get started, breaking flows, and killing conversion.
Today, instead of installing browser extensions or managing seed phrases, users can now log in with familiar methods like email or Google, and start using crypto with self-custodial wallets embedded directly into the app.
This shift has unlocked better products and better experiences, reducing friction and dropoff by enabling users to remain in-app while accessing crypto rails. Wallets are finally becoming what they were meant to be: intuitive, secure, and deeply integrated.
At Privy, we’ve built the infrastructure behind this shift, powering over 75M accounts across 1,000+ developer teams in more than 180 countries. Under the hood, we combine trusted execution environments (TEEs) with distributed key sharding to provision wallets that are seamless, secure, and built for scale.
This allows developers to spin up self-custodial wallets instantly, while also enabling complex transaction management, enabling batched actions, gas sponsorship, delegated approvals, and more – all tailored to their apps and their users’ needs.
Let’s take a closer look at how it works.
What is Privy?
Privy lets developers embed secure non-custodial wallets directly into their apps. With just a few lines of code, users can onboard using email, social login, or an existing external wallet, and instantly get access to a fully functional onchain account.
What users can do with these wallets continues to grow. Privy gives developers low-level access to key management, session signers, and flexible policy controls, making it easy to tailor wallet infrastructure to their users’ needs.
From spinning up wallets at signup to orchestrating complex transactions across fleets of accounts, Privy makes wallet management scalable, secure, and customizable.
As standards like EIP‑7702 push account abstraction forward, embedded wallets are evolving from simple key pairs into programmable accounts – unlocking additional features like transaction bundling, gas sponsorship, and more.
Under the hood
When a user creates a wallet with Privy, we provision and manage their key securely within trusted execution environments (TEEs), without compromising UX or developer flexibility.
TEEs are isolated, hardware-protected environments that prevent anyone, including Privy, from accessing the data and code running inside them. This ensures that private keys remain secure, and are never exposed, even during signing.
Here’s how it works:
1. Wallet creation: key generation + sharding
When a user signs up, a private key is generated inside a TEE and immediately split into two shares:
The enclave share secured by the TEE, and only accessible within it
The auth share, encrypted and stored by Privy, retrievable only with valid authentication.
This forms a 2-of-2 share set, meaning both shares are required to reconstruct the key and generate a signature. On their own, neither share reveals anything about the key or grants access to the wallet.
The full key is never stored or persisted, and only temporarily reconstructed when needed for signing.
2. Secure execution: signing inside isolated environments
When a user initiates a transaction, Privy reconstructs the key inside a secure enclave, only after verifying the user’s authentication.
The key exists just long enough to sign the transaction, then is immediately wiped, ensuring it is never exposed or retained.
3. User authentication and signature flow
Before a wallet can sign a transaction, the user must be authenticated. This ensures that only the rightful user can trigger key reconstruction and signing.
Privy enforces this by issuing time-bound authorization keys after a user logs in through a verified authentication session (like email, Google, or passkey). These tokens are required for signing and expire quickly, ensuring that control of the wallet remains in the hands of the authenticated user at all times.
User custody is cryptographically enforced, i.e. signatures are only possible with a valid signature generated by the user.
4. Programmability and policy control
Privy exposes full key infrastructure via APIs, so developers can layer on custom logic and control how their wallets are used. For example, you can:
Set signing policies: require biometrics, restrict to specific devices, or define transaction limits
Customize recovery: configure fallback methods, session expiration, or multi-device support
Enable passkeys and approvals: build workflows for transaction confirmations or delegated access
In short: wallets are no longer static keypairs. They’re programmable accounts, built to evolve with your product. Set up a wallet for a user, add a signer to it to enable automated actions, and more – all through a simple API.
Why this architecture
When designing Privy’s architecture, we prioritized three things:
Verifiable security guarantees
Performance at scale
Practical developer control
TEEs alone offer strong hardware-backed isolation. But Privy goes further by combining TEEs with key sharding to reduce reliance on any single infrastructure provider for key security (in this case the TEE provider). Simply put, key material never exists in full in any one place and execution happens in a secure environment.
The key splitting algorithm used (Shamir’s Secret Sharing) is used at scale in a number of high-security applications beyond crypto. For instance:
1Password and Cloudflare secret distribution systems
HashiCorp Vault uses it for secrets management
Ledger’s PVSS recovery system
Privy picked this approach over alternatives (like TSS-based MPC) based on threat modeling and performance reasons. For embedded wallets, where usability and trust must go hand in hand, Privy’s model delivers both robust security and practical flexibility for real-world applications.
Here’s how the approaches differ in practice:
Privy’s model ensures keys are never stored whole, and that every wallet operates in secure, auditable, and user-authenticated environments, without compromising developer control.
Privy by the numbers
Privy’s architecture isn’t just designed for security. It’s built to power real-world applications operating at scale.
Today, we power over 75 million accounts across a wide range of use cases, from consumer social to enterprise fintech. Our infrastructure processes:
47M+ monthly signatures
85M+ monthly transactions
500M+ total RPC calls
Built for performance and reliability, Privy runs in production across some of the most demanding environments in crypto, processing billions in transaction volume with user trust at the core.
Here are some of the ways teams are using Privy today:
Enterprise & Fintech: Infrastructure-grade wallet provisioning for stablecoin movement with HiFi, and secure dollar access via WhatsApp onboarding with Zar.
Trading: Low-latency, high-performance transactions at scale for platforms like pump.fun and Jupiter Exchange.
Payments: Onchain payment infrastructure for dining loyalty app Blackbird and global workforce payout platform Toku.
Social & Creator Platforms: Seamless onboarding and creator earnings for platforms like Zora and Farcaster.
Closing thoughts
We built Privy to make crypto easy to use and completely extensible. This starts with better wallets.
By combining trusted execution environments with key sharding, we’ve created infrastructure that balances strong security guarantees with the flexibility developers need. It’s secure, scalable, and built to meet users where they are.
Whether you’re building a trading app, social platform, or fintech product, Privy helps you deliver seamless, secure onboarding, without compromising on security or control.
Want a deeper look at how Privy wallets work? Explore the full architecture breakdown here.
