An embedded wallet lives inside your application. The user signs in the way they already do. The product resolves an on-chain account they can pay, receive, and sign with. Privy vs Turnkey is the question Search Console keeps sending at that category: one vendor is a finished auth and wallet product, the other is lower-level signing infrastructure. This guide is that comparison — product scope, key model, chains, developer experience, pricing, and who each is for.
Cavos, LLC is a software and SaaS company. Positioning for Cavos comes after the table is fair. If the honest answer is Privy or Turnkey, that is the answer. One-to-one pages live at Cavos vs Privy and Cavos vs Turnkey. Teams leaving Privy for a broader shortlist can start at Privy alternatives. The multi-vendor listicle is embedded wallet providers.
Product scope
The usual mistake is treating these as two SDKs with different logos. They sit at different layers.
Privy is a finished authentication and embedded wallet product. The public pricing page lists unified login (email, SMS, socials, passkeys), embedded wallets, JWT-based authentication (Auth0, Firebase, or homegrown), and wallet connectors for EVM and Solana. Privy’s own embedded-wallet docs describe user wallets (no separate extension or mobile wallet app), organization and treasury wallets, agent wallets, and the option to connect external wallets such as MetaMask or Phantom. In 2026 Privy also documents optional custodial wallets backed by Bridge, a Stripe company, chosen per wallet. Stripe announced it was acquiring Privy in June 2025. Acquisition is a vendor-risk input. It does not change who can produce a signature.
Turnkey is key-management and signing infrastructure. Private keys persist as ciphertext and decrypt only inside a trusted execution environment. Turnkey’s embedded-wallet overview is explicit that you are buying wallet infrastructure: authenticate a user, create keys, configure custodial, non-custodial, or hybrid custody, enforce a programmable policy engine, and get a signature back. You can broadcast through another provider or with Turnkey Transaction Management. The recommended React start is the Embedded Wallet Kit — pre-built auth and wallet UI, hook-based, no backend of your own. That kit does not turn Turnkey into Privy. The core surface is still the enclave, the policy engine, and the API.
Privy vs Turnkey is usually build-versus-buy. Buy Privy when login, an in-app wallet, and connectors should arrive as one product. Build on Turnkey when policy, quorums, and server-side signing primitives are the product.
Key model and custody
Write down who can produce a valid signature without the user present. The custody page is the control test. This section is what each vendor publishes.
Privy combines TEEs with distributed key sharding. Official security docs say Privy uses AWS Nitro Enclaves; keys exist as encrypted shares; shares are combined only inside the enclave. A wallet is a 2-of-2 Shamir split: an enclave share that can be decrypted only in the TEE, and an auth share that Privy stores encrypted and releases with valid authentication credentials. Privy’s user-wallet docs say neither Privy nor the application sees the user’s keys on that path; secrets are reconstituted in a secure environment under the user’s control. Users can export the key. Separately, Privy ships custodial wallets backed by a licensed custodian — today Bridge — on the same authorization and policy framework.
Turnkey never returns the private key as part of signing. Official docs: keys live in TEEs; derivation and signing happen inside verifiable infrastructure; only the signature leaves. Custody is who holds the credentials that can authorize the enclave:
- Non-custodial. Only the user’s authenticator (passkey, email, biometric) can authorize a signature. Users can export keys.
- Custodial. Your application holds signing authority via API key and can authorize transactions without per-action user approval.
- Hybrid. Both hold credentials; policy decides what each party can authorize.
Turnkey recommends a sub-organization per end user so wallets, credentials, and policies stay isolated. Import and export are documented. A breach of your app or backend is not supposed to expose key material; the enclave still has to approve the request.
Neither design is device-native in the Cavos sense. Both reconstruct or use a key inside an enclave the vendor operates. The difference is product wrapping (Privy) versus policy-gated primitives (Turnkey), plus Privy’s optional licensed-custodian path.
Chains supported
Coverage is not a boolean. Both vendors publish tiers.
Privy documents three wallet tiers on its chain support page. Higher tiers include the ones below.
| Privy tier | What Privy manages | Published networks |
|---|
| Send (tier 3) | Construct, sign, broadcast, and track | Ethereum and other EVM, Solana and other SVM, Tempo, TRON |
| Sign transactions (tier 2) | Decode and sign a transaction | XRPL, Sui, Stellar, Aptos, Near |
| Sign (tier 1) | Create a wallet and produce a signature | Bitcoin, Cosmos, TON, Starknet, Pearl, and other supported secp256k1 / Ed25519 chains |
Gas sponsorship, smart wallets, batching, and wallet actions are called out as additional, chain-dependent capabilities on the send tier. Feature parity still varies by network. Privy’s own page says to confirm current coverage before you promise a chain.
Turnkey works at the cryptographic-curve level: secp256k1, Ed25519, and P-256. Official copy: asset-agnostic as long as the curve is supported; all EVM and SVM chains; you do not wait for a per-network integration to sign. Deeper tiers add address derivation, SDK construction, then transaction parsing and policies. The published parsing-and-policy list is shorter than the curve list — EVM, SVM, Bitcoin, and TRON are called out at that depth; Cosmos, Sui, Aptos, TON, XRP, and Sei are listed at curve and address tiers. Starknet is not on that table. If you need transaction-aware policy on a specific chain, read the current Turnkey network page.
The practical fork: Privy is stronger when you want managed send on EVM and Solana. Turnkey is stronger when you want curve-level signing and will handle broadcast and chain semantics yourself — or when Turnkey’s higher tier already covers that chain.
Developer experience
Privy is the shorter path to a consumer wallet in a React or mobile app. You get hosted or JWT login, an embedded wallet bound to that user, optional connectors for wallets they already hold, UI components or bare APIs, and SDKs listed for web, mobile, and gaming. Pregenerating a wallet for an email or phone before first login is documented. Export is the documented escape hatch. You are integrating a product.
Turnkey is the shorter path to policy-gated keys. Every sensitive operation is an authenticated request the enclave evaluates. Auth includes passkeys / WebAuthn, email or SMS OTP, OAuth (Google, Apple, Twitter, Discord, GitHub, LinkedIn, and others), API keys, and sign-in with an external Ethereum or Solana wallet. Client SDKs exist for React (Embedded Wallet Kit), React Native, Swift, Kotlin, and Flutter; fully custom work calls the API. Gas sponsorship is listed on Turnkey’s public pricing page as an Enterprise feature. You are integrating infrastructure, even when you start from the kit.
Time-to-first-signature is not the same as time-to-product. Privy collapses login, wallet, and connectors. Turnkey collapses key lifecycle, policy, and signing; auth and UI are available, but broadcast, recovery UX, and chain adapters are still your design unless you adopt Transaction Management and the kit.
Pricing, at a high level
They do not sell the same unit. A cheap free tier on one side is not a cheaper bill on the other. Figures below are from each vendor’s public pricing page as of October 2026 and can change. Where a number is unpublished (Turnkey Transaction Management per-transaction fees, Enterprise volume rates), this page does not invent it.
Privy bills monthly active users, with a signature and volume allowance on Developer plans. A MAU is a Privy-authenticated user with at least one session in the last 30 days. A signature is a cryptographic signature request from a Privy embedded wallet in that window.
| Privy plan | Public list price | Published allowance |
|---|
| Developer — Free | $0 | 0–499 MAU; 50,000 signatures and $1M volume / month |
| Developer — Core | $299 / month | 500–2,499 MAU |
| Developer — Scale | $499 / month | 2,500–9,999 MAU |
| Enterprise | Custom | Per-transaction or per-transacting-wallet; volume discounts |
Privy’s public FAQ states that exceeding 10,000 MAU or 50,000 signatures in a month moves Developer usage to pay-as-you-go. Stay on the list prices above; do not treat overage as a quote.
Turnkey bills signatures, with a wallet cap per tier. The Pay as you go tier is free until you exceed the included signatures.
| Turnkey plan | Public list price | Published inclusion |
|---|
| Pay as you go | $0.10 / signature after the free allotment | 1,000 wallets; 25 free signatures / month |
| Pro | $99 / month | $0.05 / signature; 2,000 wallets |
| Enterprise | Custom | As low as $0.0015 / signature; unlimited wallets; gas sponsorship listed here |
Turnkey Transaction Management, swaps, and Earn are priced separately. Contact Turnkey for those rates.
Cavos publishes fees on this site: free for the first 1,000 wallet creates, Essential at $59/month, Complete at $139/month. See pricing. The unit is wallet creates, not MAU or signatures.
Privy vs Turnkey, side by side
| Privy | Turnkey |
|---|
| Product scope | Finished auth + embedded wallets + external wallet connectors. Optional custodial wallets (Bridge). | Key-management and signing infrastructure. Embedded Wallet Kit is the opinionated React path. |
| Key / custody model | Shamir 2-of-2 shares; reconstruct in AWS Nitro Enclaves. User wallets described as non-custodial with key export. Separate custodial path via Bridge. | Keys decrypt only in a TEE. Custody is who can authorize the enclave: user, your API key, or both under policy. Import and export documented. |
| Chains | Managed send on EVM, Solana/SVM, Tempo, TRON. Sign-transaction and sign-only tiers for additional networks, including Starknet at sign-only. | Curve-level (secp256k1, Ed25519, P-256). All EVM and SVM. Deeper policy/parsing on a shorter published list. |
| Developer experience | Login, wallet, and connectors as one product. Web, mobile, and gaming SDKs. UI components or APIs. | Enclave + policy + API. React Embedded Wallet Kit, plus React Native, Swift, Kotlin, Flutter, or raw API. |
| Auth | Email, SMS, socials, passkeys; JWT from Auth0, Firebase, or your own stack. | Passkeys, email/SMS OTP, OAuth, API keys, Sign-In With Ethereum or Solana. |
| Pricing model | MAU tiers. Free 0–499 MAU with 50K signatures and $1M volume/mo. Core $299/mo. Scale $499/mo. | Per signature. 1,000 wallets and 25 free signatures/mo, then $0.10/signature. Pro $99/mo. |
| Best for | Teams that want one vendor for login, an in-app wallet, and connecting wallets users already hold — especially on EVM. | Teams building a wallet or custody product that need policy, quorums, and server-side signing primitives. |
Worked Cavos comparisons: Cavos vs Privy, Cavos vs Turnkey. The rest of the shortlist is on embedded wallet providers and Privy alternatives.
Who each is best for
Choose Privy when the user should get an in-app wallet from a login you already understand, and you also need to connect MetaMask, Phantom, or WalletConnect for people who already hold assets. EVM-first consumer apps, games, and anything that wants one vendor for auth plus wallet sit here. The optional Bridge custodial path matters if counsel wants a licensed custodian on some wallets and a non-custodial embedded wallet on others.
Choose Turnkey when you are building the wallet or the custody layer. Server-side signing, organizational quorums, per-user sub-organizations, and a policy engine that runs inside the enclave are the reason to pick it. The Embedded Wallet Kit is there if you want a faster React start; it does not remove the need to own broadcast, chain semantics, and recovery UX if you go below that kit.
Choose neither when the requirement is a device-native key on Starknet, Solana, or Stellar, or when the review says the vendor must not be able to reconstruct a signing key in its infrastructure. That is a different product shape. The next section is that shape, not a third row pretending to be the same layer.
Where Cavos fits
Cavos is an embedded wallet, not an extension, and not signing infrastructure.
Signing keys are created and used on the user’s device. Cavos cannot see them, sign with them, or move funds. Login produces a stable identity for a registry lookup; it never signs a transaction. There is no MPC. There is no hosted spend key.
On Starknet the on-chain account is an audited OpenZeppelin account contract (AccountUpgradeable v3.0.0), controlled by one stark key derived from the wallet’s MasterDEK and app salt. Cavos does not ship its own account implementation. There is no on-chain device-signer list and no on-chain social recovery. A new device restores the MasterDEK off-chain with a passkey or an opt-in AWS Nitro Enclave; it does not add a signer on-chain. Execution is paymaster-sponsored. Connect does not deploy — the first execute deploys and runs atomically.
Solana and Stellar are native adapters, not EVM compatibility. Solana provisions a native Ed25519 system account; a relayer co-signs as fee payer. Stellar provisions a classic G… account so existing tools already understand the address; the relayer can sponsor reserves and fee-bumps. Both restore the same MasterDEK on a new device rather than adding a second on-chain signer.
Auth is hosted Google, Apple, or email, or an identity you pass in from your own stack. The React path is @cavos/kit; mobile is @cavos/kit/react-native. Pricing publishes the free 1,000 wallet creates, Essential at $59/mo, and Complete at $139/mo.
Choose Cavos when the user should never see a wallet picker, the chain is Starknet, Solana, or Stellar, and the review requires that the vendor cannot reconstruct a signing key.
Stay with Privy or Turnkey when the product is EVM-first, when you must connect an existing extension, when you need server-side signing or organizational quorums as a product feature, or when you want a single vendor across dozens of EVM networks. Cavos does not inject into window.ethereum and does not speak WalletConnect. Those are honest gaps, not a smaller feature set.
What to read next
- What is an embedded wallet? — definitions, key models, and how to choose an SDK.
- Embedded wallet providers — Cavos, Privy, Dynamic, Turnkey, Magic, and Web3Auth in one table.
- Cavos vs Privy and Cavos vs Turnkey — when the other product is the better pick.
- Privy wallet alternatives — the same vendors, framed as replacements for Privy.
- How to add an embedded wallet —
@cavos/kit install and the first sponsored transaction.
- Embedded Starknet wallet — audited OpenZeppelin account contract, paymaster, SNIP-12. Also Solana and Stellar.
- Pricing — Cavos fees. Privy and Turnkey set theirs independently.
- Custody — the control test, not the UX label.