RIP Embedded Wallets: Stop Paying Privy - Your Browser Does This for Free.

There's a category of developer tooling that exists not because the underlying problem is hard, but because it was hard at a specific moment in time. The companies that sprung up to solve it never gave you a reason to notice when that moment passed.

Embedded wallets are that category, and the moment passed in the summer of 2025.

The Pitch vs. The Reality

The pitch from Privy, Thirdweb, Turnkey, Web3Auth, and friends goes something like this: generating and securing a blockchain private key on behalf of your users without seed phrases or browser extensions is genuinely complex infrastructure. Trust us to handle it, and we'll charge you accordingly.

That framing was reasonable in 2022. It's not anymore.

What these products are fundamentally doing is generating a private key and storing it somewhere the user can access it after authenticating. The hard part was always the authentication, secure storage, onchain smart wallet deployment and P256 signature verifications. As of the summer of 2025, every major browser and mobile operating system handles that natively, for free, using a W3C standard called WebAuthn PRF.

You are paying Privy $500 a month for a wrapper around something your users' devices already do well.

What You're Actually Paying

Let's be specific, because the pricing deserves scrutiny:

• Privy — free for 500 users, $300/month for up to 2,499, $500/month for up to 10,000. Enterprise accounts pay $0.001 per wallet signature on top of that.
• Thirdweb — $100–$1,500/month for the server wallet platform, then $0.0015–$0.01 per user wallet depending on volume.
• Turnkey — $0.10 per signature on the variable plan; $0.05 per signature on the $99/month plan.
• Coinbase Developer Platform — $0.005 per wallet operation.
• Web3Auth — $69/month for 3,000 MAUs, $0.045 per MAU over that; $399/month for 10,000 MAUs.

The fees add up fast. But the money isn't even the most insidious part. Every one of these vendors requires a business account which means another vendor relationship, another set of team permissions, another API key to rotate and secure before you can let Cursor or Claude Code build your onchain feature. For smaller teams, that's real overhead at exactly the stage when resources are tightest.

And then there's the technical debt baked into the architecture. Many of these products are built on EIP-4337, a smart wallet standard that carries at least 2x the gas overhead per transaction compared to the newer EIP-7702 smart account approach. You'll need to pre-fund a 4337 paymaster before a single user can transact. So in addition to paying the embedded wallet vendor you are also paying extra on every transaction, forever, and your users are locked into their specific smart wallet implementation. Not very web3 for products that claim to be.

What Changed: WebAuthn PRF

The W3C proposed the PRF extension to the WebAuthn specification in January 2023. By summer 2025, Chrome, Safari, Firefox, and Edge all shipped support. iOS and Android followed.

Note the timing: nearly every embedded wallet product on the market was designed before this proposal existed.

The PRF extension lets a website ask a WebAuthn authenticator (a passkey, Face ID, Touch ID, or a hardware security key) to produce a deterministic cryptographic output tied to a specific credential. That output is suitable for use as a private key seed. Specifically, it can generate secp256k1 keys for EVM and Bitcoin networks, or Ed25519 keys for Solana.

What that means in plain terms: your user's browser can now deterministically derive a real blockchain private key, secured by the same biometric or passkey they use to log into everything else. The key never leaves the browser. There's no third-party infrastructure involved. No one is charging you $0.10 every time your user signs a transaction or SIWE message.

The PRF extension also doesn't change WebAuthn's privacy properties, and it cannot be phished or triggered silently as it requires the same user gesture as any other WebAuthn ceremony. There is no workaround or a hack as it uses a first-class W3C standard for its intended purpose.

How to Actually Build It

Knowing PRF exists is one thing. Doing it right requires thinking through a few details — which is exactly what we've done at 1Shot.

The pattern that works best: host the passkey credential on a dedicated subdomain of your app, and serve the wallet logic from an iframe embedded in your product. This approach gives you the optionality to allow your iframe wallet to be embedded in other sites so your users can benefit from interoperability and your app can benefit from network effects.

This is the same architecture payment processors like PayPal, Block and Stripe use for their embedded payment wallets on traditional rails. The iframe handles credential creation and key re-derivation via assertion, and because it runs in an isolated JavaScript context, the derived key in memory is protected from any other scripts running on the parent page. Your app communicates with the wallet via a postMessage interface.

You can implement the full EIP-1193 connector interface or EIP-7715 permissions, so the wallet works out of the box with standard web3 libraries like Ethers, viem, or MetaMask's smart account kit. The key persists in iframe memory for the page session, so users authenticate once with their passkey and are done — no re-prompting per transaction.

When you're ready for smart account features like batch transactions or gas sponsorship, you upgrade to EIP-7702 instead of legacy 4337. Roughly half the gas overhead. No vendor required.

The Recovery Question

The obvious objection: what if a user loses their passkey?

It's a real risk, and anyone selling you a PRF-based wallet without a recovery strategy is cutting corners. Here's the answer that doesn't require handing user keys to a third party:

The wallet iframe encrypts the derived key client-side using browser-native cryptographic APIs, pairs it with a UUID assigned to your user, and your application stores the encrypted blob in your own database. If a user loses their passkey, they supply their UUID — the iframe decrypts the key in their new session. Your server stores something it can never decrypt. You remain fully non-custodial.

We've implemented this in production in 1ShotPay — you can see it working yourself.

What You Actually Own

With a third-party embedded wallet vendor, you own an integration. When they change their pricing, and they will, your options are renegotiate or rebuild. When they get acquired, you wait and see what the new owners decide. When they deprecate an API version, you scramble.

With a PRF wallet, you own the source code. Your wallet is an implementation of a W3C standard, running on cryptographic APIs that ship in every browser and mobile OS. There are no per-user fees because there's no third party touching your users' keys. There are no per-signature fees because signing happens locally. User credentials are secured by Chrome, Safari, iOS, and Android — software that already protects credentials for billions of people.

The technical moat that justified these vendors' pricing no longer exists. The question is just whether you know it yet.

Get Started

The 1Shot team has packaged this entire implementation pattern into an open-source WebAuthn PRF skill at 1shotapi.com/solutions/webauthn-prf-wallet. It covers credential creation, key derivation, corner-cases and environment detection, the iframe isolation pattern, the recovery flow, and EIP-1193 connector integration — in enough detail that a modern coding agent can implement it end-to-end in one or two prompts.

Zero third-party dependencies. No business account. No per-signature fees. No per-user fees.

The infrastructure for doing embedded wallets right is already in your users' browsers. You just have to use it.