TL;DREmbedded wallets let users sign in with email, social, or passkeys — no seed phrases — while your app handles keys under the hood. Combined with ERC-4337 and EIP-7702, they enable batched actions, sponsored gas, and session-based automation that make crypto UX feel like web2. This guide walks developers through how embedded wallets work, how signing and key custody are split, how paymasters turn gas into an invisible cost, and what to evaluate when choosing a provider. Start here if you're picking between embedded-wallet platforms or designing onboarding for a consumer app, game, or fintech.
TL;DR Embedded wallets let users sign in with email, social, or passkeys — no seed phrases — while your app handles keys behind the scenes. Combined with ERC-4337 and EIP-7702, they unlock gasless transactions, batched actions, and in-app signing that converts like web2 onboarding.
What is an embedded wallet?
An embedded wallet is a non-custodial wallet provisioned directly inside your application. Instead of asking users to install a browser extension, you create the wallet during onboarding and surface signing as a native step in your flows — checkout, mint, payout, in-game purchase. Keys are protected with passkeys (WebAuthn) or MPC, so only the user can authorize transactions, but the UX lives entirely inside your product.
Why teams adopt them
- Frictionless onboarding — email, social, or passkey instead of a 12-word mnemonic
- In-app signing — no popups, no context switching, no "Connect Wallet" detour
- Policy controls — per-asset caps, allowlists, velocity checks, session TTLs
- Composable AA features — batched actions, sponsored fees, recoverable accounts
How embedded wallets work (behind the scenes)
- User authenticates with email, OAuth, or a passkey.
- Wallet is provisioned for EVM, Solana, or both. Keys are generated and split using your chosen model — device passkey + server share, MPC/Shamir, or another scheme.
- A short-lived session is issued so the client can request wallet actions without re-prompting on every interaction.
- Your app builds a transaction (or an ERC-4337 UserOperation) and shows the user a human-readable preview.
- The user signs in-app. The key signs locally; your relayer or bundler submits onchain; a paymaster optionally covers fees.
- The UI updates optimistically and confirms when the transaction lands.
Seedless onboarding vs. seed phrases
Seed phrases are the single biggest drop-off point in crypto onboarding. Replacing them with email, social, or passkeys removes that wall — and the underlying security model is stronger when it's implemented well:
- Passkeys (WebAuthn) — device-secure, phishing-resistant, hardware-backed. The default for mainstream users.
- MPC / secret-sharing — splits the key across device, server, and optionally a guardian. No single party can move funds, and recovery doesn't require exposing the full key.
- Recovery policies — step-up auth (email OTP, TOTP, guardians) plus an export option for power users who want raw control later.
Seed phrases still make sense for users who want full key custody from day one. For everyone else, seedless converts better.
Embedded vs. browser-extension wallets
| Criterion | Embedded wallet | Extension wallet |
|---|---|---|
| Onboarding | Email / OAuth / passkey in 1–2 taps | Install + connect, multiple steps |
| Signing UX | In-app modal, your branding | External popup, context switch |
| AA features | 4337 / 7702, batching, sponsored fees | Limited, varies by extension |
| Branding & flow control | Full | Minimal |
| Trade-off | You own risk controls and observability | You inherit the extension's UX |
Rule of thumb: choose embedded for consumer apps, games, fintech, and agent products — anywhere conversion and UX control matter. Keep "Connect external wallet" as an escape hatch for power users.
Security and key management
A well-built embedded wallet stack should give you:
- Device-anchored passkeys (WebAuthn) — phishing-resistant, hardware-backed; the default for mainstream sign-ups.
- MPC or secret-sharing — split trust across device, server, and optional guardians to remove single points of failure and enable recovery.
- Scoped permissions — per-method, per-asset, per-chain caps, daily limits, velocity checks, session TTLs.
- Recovery flows — email OTP, TOTP, guardian-based recovery, plus optional export for power users.
- Auditability — log every sign request (who, what, when, where) so you can answer "did it go through?" without a support ticket.
Account abstraction in practice (ERC-4337 and EIP-7702)
Embedded wallets become genuinely powerful when paired with account abstraction:
- ERC-4337 introduces UserOperations, bundlers, and paymasters — meaning one-click multi-step actions and gas sponsorship.
- EIP-7702 lets a regular EOA temporarily authorize smart-contract behavior — "stay an EOA, get smart-account powers" — which fits perfectly with email and passkey sign-ins.
Practical wins: batched actions in a single signature, sponsored gas so users never need a native token to pay fees, safer recovery patterns, and far fewer stuck-transaction support threads.
Sponsored fees and paymasters ("gasless" UX)
A paymaster lets your app cover gas for specific actions or user cohorts. The pattern that works:
- Scope when you sponsor — first N actions, specific methods, promotional windows.
- Add risk signals — velocity, device fingerprint, IP, geofencing.
- Communicate transparently — "Fees covered by [your app]" in the preview, not hidden.
Done well, sponsored fees are the single biggest UX improvement embedded wallets enable. Most users don't know — and shouldn't need to know — what gas is.
Use cases that convert today
Gaming — instant accounts, batched quest claims, sponsored starter actions.
E-commerce and loyalty — stablecoin payouts, on-chain points programs without making users install anything.
Agents and automations — scheduled or AI-initiated actions running under explicit policy guardrails.
DeFi for mainstream users — one-tap deposit and redeem with readable previews and sponsored gas.
Implementation quickstart (Openfort)
The path from zero to a working embedded wallet:
- Create a project for EVM, Solana, or both.
- Add auth — email, OAuth, or passkey.
- Provision a wallet automatically on first login.
- Build an action (send, mint, swap) with the SDK.
- Enable AA — 4337 by default, plus 7702 for "stay EOA" paths.
- Configure paymaster policies — when and how you sponsor.
- Ship the in-app signing modal plus activity and recovery screens.
Minimal "send USDC" — frontend (EIP-1193 + viem)
_20// User is authenticated and embedded wallet is ready_20import openfort from "./openfortConfig"_20import { createWalletClient, custom, erc20Abi } from "viem"_20import { base } from "viem/chains"_20_20// 1. Get an EIP-1193 provider from the embedded wallet_20const provider = await openfort.embeddedWallet.getEthereumProvider()_20_20// 2. Bind a viem wallet client to Base_20const client = createWalletClient({ chain: base, transport: custom(provider) })_20_20// 3. Transfer 15 USDC (6 decimals)_20await client.writeContract({_20 address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC on Base_20 abi: erc20Abi,_20 functionName: "transfer",_20 args: ["0xRecipient", 15_000_000n], // 15 * 10^6_20})_20_20// If a gas Policy is configured in the dashboard, this call is sponsored automatically.
The embedded wallet exports an EIP-1193 provider through embeddedWallet.getEthereumProvider(), so any wagmi- or viem-based code keeps working unchanged.
Minimal "send USDC" — backend (Transaction Intents + policy)
_18import Openfort from "@openfort/openfort-node"_18const openfort = new Openfort(process.env.OPENFORT_SECRET_KEY!)_18_18// Prereqs in dashboard:_18// 1. Register the USDC contract → returns "con_..."_18// 2. Create a gas policy → returns "pol_..."_18_18await openfort.transactionIntents.create({_18 account: "dac_...",_18 chainId: 8453, // Base_18 policy: "pol_...", // optional sponsorship rules_18 optimistic: true, // return fast, confirm via webhook_18 interactions: {_18 contract: "con_...",_18 functionName: "transfer",_18 functionArgs: ["0xRecipient", "15000000"], // 15 * 10^6_18 },_18})
Backend Transaction Intents accept a registered contract and an optional policy, which is where sponsorship and per-user limits get applied.
Choosing an embedded wallet provider
When evaluating Openfort, Privy, Magic, Alchemy/Account Kit, Sequence, Thirdweb, Fireblocks, or another platform, compare on:
- Login methods — email, OAuth, passkeys
- Chain coverage — EVM, Solana, L2s
- AA support — 4337 and 7702, not just one
- Paymaster controls — policies, rate limiting, fraud signals
- Self-host options — open-source signer, vendor neutrality
- Recovery model — passkey, MPC, guardian flows
- Observability — logs, webhooks, status, traceability
- Pricing model — MAU vs. per-tx, free-tier behaviour
For a side-by-side, see the Openfort comparison page.
Build with embedded wallets today
Start with the 4337 quickstart, the 7702 recipe, the paymaster guide, and Solana support. Each takes ten minutes and ships a real signing flow you can hand to users.
Or skip ahead and explore the full Openfort embedded wallet platform — non-custodial keys, smart accounts, gasless transactions, and a self-hostable signer in a single SDK.