Turnkey vs Privy: choosing embedded wallet infrastructure

The verdict

Privy is the bundled product. It ships authentication, embedded wallets, policies, and funding flows as one SDK, and Stripe announced its acquisition of Privy in June 2025. Turnkey is the lower-level primitive. It gives you key management, signing, and a policy engine inside verifiable enclaves, with pricing per signature, and expects you to build the product around it.

Choose Privy if you are launching a consumer or fintech app and want login-to-wallet in one integration. Choose Turnkey if you are assembling your own stack, sign at high volume, or need verifiable proofs of what the signer did and multi-user consensus on sensitive actions. Both run on AWS Nitro enclaves, both treat a request that no rule allows as denied once policies are in place, and both let users export keys. The differences are in how much product you get, how the key is held at rest, and how you pay.

If the "embedded wallet" you are actually building is a business account with roles, approval queues, and finance reporting, neither ships that as a finished product, and we cover the alternative at the end. Den publishes this blog and builds that alternative.

Two products at different layers

Privy describes its embedded wallets as self-custodial wallets built into your app, powered by secure hardware, with both user-controlled and app-controlled configurations, and an export escape hatch so users can leave. Its authentication layer covers email, SMS, passkeys, social logins, external wallets, hardware keys, and existing OIDC providers such as Auth0, Firebase, and Cognito. The framing in its authentication docs is blunt: account access is wallet access.

Turnkey describes itself through organizations, sub-organizations, users, credentials, wallets, activities, and policies. Every action is an activity evaluated by the policy engine inside an enclave. It offers authentication too, but its own comparison page positions the company as infrastructure-first and says Privy trades flexibility for ready-made flows. That is a fair summary from a biased source.

Side by side

How the key is protected

Both vendors put the sensitive work inside AWS Nitro enclaves, which have no persistent storage, no interactive access, and no network connectivity. From there the designs diverge.

Turnkey's secure enclave documentation says key generation, signing, and the policy engine all run inside enclaves on a minimal operating system called QuorumOS, with attestation from the Nitro Security Module. Its non-custodial key management page states that raw private keys are never exposed to Turnkey, your software, or your team, and are decrypted only inside a verified enclave when the end user authenticates. Turnkey Verified adds boot proofs and app proofs so a client can check that an address was derived, and a policy decision made, by the expected code in the expected enclave.

Privy's architecture documentation describes Shamir secret sharing into two encrypted shares. The enclave share can only be decrypted inside the TEE. The auth share is stored by Privy and released only with valid user authentication. Both are required to sign, and the full key exists only temporarily in enclave memory during a signing operation. The enclave also verifies the authorization key signature on the request and evaluates wallet policies before signing.

Our read: these are two defensible designs with the same trust anchor, the AWS Nitro platform and the vendor's code. Turnkey has invested more in letting you verify that code from the outside. Privy has invested more in making sure no single stored artifact is a key. Fireblocks' embedded wallet comparison criticizes both approaches. It is a competitor's page, and you should weigh it as such.

Authentication and sessions

Privy's authentication overview separates delegated methods, where a third party such as Google or an SMS carrier controls the credential, from direct methods such as passkeys, hardware keys, and TOTP apps, where the user owns the credential outright. It recommends pairing delegated logins with a direct second factor. That distinction is useful for any wallet product, whichever vendor you pick.

Turnkey's authentication overview covers passkeys, email and SMS one-time codes, OAuth providers, sign-in with Ethereum and Solana, and API keys for servers. In September 2026 it shipped native MFA and scoped sessions. An MFA policy does not grant permission, it adds a proof requirement to an activity, and a scoped session limits what an authenticated session can do and for how long. The motivation Turnkey gives is that MFA enforced only in a UI can be bypassed by calling the API, so it belongs in the policy layer.

Policies and who can change them

Privy's policy engine attaches a list of rules to each RPC method a wallet can perform. Conditions can test the recipient, value, chain, decoded calldata and parameters, typed-data fields, contract and program allowlists, and time windows. For a wallet that has a policy attached, any matching DENY rule denies, at least one ALLOW must match, and a request that matches no rule is denied. Every Solana instruction must pass individually. Wallets and policies have owners, which can be users, authorization keys, or key quorums, and only owners can change policies, signers, or export the key.

Turnkey's policies are JSON documents with an effect of EFFECT_ALLOW or EFFECT_DENY, a consensus expression that says which users, and how many of them, must approve, and a condition over the activity, for example the destination address of an Ethereum transaction. Evaluation runs in a fixed order: if a quorum of root users takes the action it is allowed, otherwise any applicable deny wins, otherwise at least one allow is needed, and anything left is implicitly denied. That first step matters: the root quorum is the ultimate authority in each organization or sub-organization, so its membership and threshold are the most important settings in your configuration.

Both vendors have written about using these engines to constrain AI agents. Privy's agentic apps guide recommends transfer caps per time window and contract allowlists for agent-owned wallets. We go deeper on that in wallet infrastructure for AI agents.

Custody models and the regulatory question

Privy's docs offer user-controlled wallets, where neither Privy nor your application ever sees the keys, and app-controlled wallets for fleets and organizational use. Its September 2026 post on selecting a custody model makes a point every fintech should hear: custody exists on a spectrum, ownership and signing authority are distinct, and technical configuration alone does not determine your regulatory obligations. Talk to counsel.

Turnkey models the same choice with sub-organizations. Create one per end user with a root quorum only the user controls and you have a non-custodial wallet where, in Turnkey's words, the company is like a safety deposit box operator. Give your own service the root quorum and you have a custodial wallet. The parent organization has read-only visibility into sub-organizations either way.

Export and exit

Users can leave both platforms. Turnkey exports a mnemonic or private key encrypted with HPKE to a target key you generate, or displays it in an iframe on a Turnkey origin that neither your app nor Turnkey can read. Privy exports the private key assembled on a separate origin so that neither you nor Privy can access it. Export is restricted to wallet owners and can be disabled with a DENY policy, and a two-party key quorum can require both the user and your server to agree. For smart wallets, Privy exports the signer key rather than the smart account.

Which one should you pick?

Pick Privy when you want one vendor for login and wallets, your users are consumers or small businesses, your team is small, and time to launch matters more than control over the stack. The Stripe relationship also matters if fiat funding and card programs are on your roadmap.

Pick Turnkey when you already have an identity system, you want to design the wallet system from primitives, you sign at volumes where per-signature pricing wins, or your security team wants attestation proofs and consensus requirements on administrative actions.

Check current pricing on the Turnkey and Privy pages rather than relying on any article. Model both against your expected users and signatures per user, because the two pricing shapes reward different usage patterns.

Where Den fits

Turnkey and Privy are built around wallets that belong to individual users, and both can model organizational control through consensus policies and key quorums if you assemble it. If your product gives business customers a wallet with several employees, approval thresholds, spending limits, and an audit trail, that operating model is what Den's Wallet-as-a-Service is built around. Den's API and SDK documentation describes issuing wallets to your customers with full API control, and the model underneath is organizations, members, groups, accounts, and policies, with API members for automation and admins whose changes require a configurable threshold. Policies are enforced by the signing client, a Guardian service, and onchain contracts, which is a different guarantee from enclave-only enforcement.

Know the integration work. In the pages we read, Den does not document a ready-made consumer login kit or per-user device key shares of the kind Privy and Turnkey provide. A consumer product built on Den would supply its own authentication and decide how its users map to members and accounts, and it would run on EVM networks only. For a B2B fintech giving each business customer a governed account, Den is a direct fit. For a consumer app that wants login and wallet in one SDK, the two vendors above are the direct fit.

Continue with the best wallet infrastructure for fintechs for the wider decision, or Fireblocks alternatives if institutional custody is also in scope.