TL;DR Embedded wallets let users sign up with familiar auth (email, social, passkeys) and use crypto inside your app—no extensions, no seed phrases. You keep UX control (in-app signing, branded modals), unlock AA features (ERC-4337 + EIP-7702), and can sponsor fees with paymaster policies. Below: how it works, trade-offs, and a quick path to shipping.
What is an embedded wallet?
An embedded wallet is a non-custodial wallet created and surfaced directly inside your product. Instead of sending people to install a browser extension and come back, you provision a wallet during onboarding and present signing as a native step in your flows (checkout, game action, payout, deposit, mint, etc.).
Why teams adopt them
- Frictionless onboarding: email/social/passkey instead of seed phrases.
- In-app signing: no popups or context switching.
- Policy controls: rate limits, allowlists, risk checks.
- Composable features: batching actions, sponsored fees, safer recovery.
How embedded wallets work (behind the scenes)
- User authenticates with email/OAuth or a passkey (WebAuthn).
- Wallet is provisioned (EVM and/or Solana). Keys are generated and protected using the model you choose (device passkey + server share; MPC/shamir split; etc.).
- Session is issued (short-lived) so the client can request wallet actions.
- Your app builds a transaction (or 4337 UserOperation) and shows a human-readable preview.
- User signs in-app. The key signs; your relayer/bundler submits; a paymaster may cover fees.
- UI updates optimistically; final status confirms on-chain.
Seedless onboarding vs seed phrases
Email/social/passkeys remove the “write down 12 words” step that causes drop-off. Security hinges on your key policy:
- Passkeys (WebAuthn): device-secure, phishing-resistant; ideal default.
- MPC/secret-sharing: no single point of failure; enables recovery without exposing the full key.
- Recovery policies: step-up auth (email OTP, TOTP, guardians), plus export options for power users.
When mnemonics still make sense: early adopters who want raw key control 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 | Requires install + connect |
| Signing UX | In-app modal, branded | External popups, context switch |
| Features | 4337/7702, batching, sponsored fees, policies | Broad ecosystem tools |
| Control | Full control over flows and copy | Limited UI control |
| Trade-offs | You own risk controls & observability | Higher drop-off at install step |
Rule of thumb: choose embedded for consumer apps, games, fintech, agents—anywhere conversion and UX control matter. Keep “Connect your wallet” as an escape hatch for power users.
Security & key management
- Device-anchored passkeys (WebAuthn): phishing-resistant, hardware-backed; great default for mainstream users.
- MPC / secret-sharing: split trust across device/server/guardian to avoid a single point of failure and enable recovery.
- Scoped permissions & policies: per-method/asset/chain caps, daily limits, velocity checks, session TTLs.
- Recovery: step-up flows (email OTP, TOTP, guardians) + optional export for power users.
- Auditability: log every sign request (who/what/where) to reduce “did it go through?” tickets.
Account Abstraction in practice (ERC-4337 & EIP-7702)
- ERC-4337 brings UserOperations, bundlers, and paymasters → 1-click multi-actions and fee sponsorship.
- EIP-7702 lets an EOA temporarily authorize contract-like behavior → “stay EOA, get smart-wallet powers” (great for email/passkey sign-ins).
Practical wins: batching, sponsored gas, safer recovery patterns, fewer stuck-tx support threads.
Sponsored fees and paymasters (“gasless” UX)
Sponsor fees for specific actions or cohorts:
- Scope when you pay (first N actions, certain methods, promo windows).
- Add risk signals (velocity, device, IP, geofence).
- Message transparently: “Fees covered by the app.”
Use cases that convert now
Gaming: instant accounts, quest batching, sponsored starters.
E-commerce & loyalty: stablecoin payouts, on-chain points without extensions.
Agents & automations: scheduled or AI-initiated actions under policy guardrails.
DeFi for mainstream: one-tap deposit/redeem with readable previews.
Implementation quickstart (Openfort)
- Create a project (EVM and/or Solana).
- Add auth (email/OAuth/passkey).
- Provision wallets on first login.
- Build an action (send/mint/swap) with the SDK.
- Enable AA: 4337 by default; add 7702 for “stay EOA” paths.
- Configure paymaster policies (when and how you sponsor).
- Ship the in-app signing modal + activity & recovery screens.
Minimal “send USDC” (Frontend, EIP-1193 + viem)
_21// assumes user is authenticated and embedded wallet is ready_21import openfort from "./openfortConfig";_21import { createWalletClient, custom } from "viem";_21import { base } from "viem/chains";_21import { erc20Abi } from "viem"; // standard ERC-20 ABI_21_21// 1) Get an EIP-1193 provider from the embedded wallet_21const provider = await openfort.embeddedWallet.getEthereumProvider();_21_21// 2) Create a viem wallet client bound to Base_21const client = createWalletClient({ chain: base, transport: custom(provider) });_21_21// 3) Transfer 15 USDC (6 decimals) to a recipient_21await client.writeContract({_21 address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // <-- USDC addr for your chain (example only)_21 abi: erc20Abi,_21 functionName: "transfer",_21 args: ["0xRecipient", 15_000_000n], // 15 * 10^6_21});_21_21// If you set a gas Policy in the dashboard, matching calls will be sponsored.
Why this is “by the book”: Openfort explicitly documents exporting an EIP-1193 provider via embeddedWallet.getEthereumProvider() and passing it to libraries like viem
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 -> you'll get contract id "con_..."_18// 2) Create a Gas Policy "pol_..." that defines when to sponsor_18_18await openfort.transactionIntents.create({_18 account: "dac_...", // backend or user account_18 chainId: 8453, // Base_18 policy: "pol_...", // optional: sponsors fees per your rules_18 optimistic: true, // return quickly; confirm via webhook/poll_18 interactions: {_18 contract: "con_...", // your registered USDC contract_18 functionName: "transfer",_18 functionArgs: ["0xRecipient", "15000000"] // 15 * 10^6_18 }_18});
This mirrors the official Node SDK examples for transactionIntents.create (account/chainId/policy/interactions) and the guidance to configure gas policies for sponsorship.
Choosing an embedded wallet platform
When you compare providers (Openfort, Privy, Magic, Alchemy/Account Kit, Sequence, Thirdweb, Fireblocks, etc.), evaluate on:
- Login methods: email, OAuth, passkeys.
- Chains: EVM, Solana, L2s.
- AA features: 4337, 7702 support.
- Paymaster: policies, rate limiting, fraud checks.
- Self-host options: open-source signer components, vendor neutrality.
- Recovery: passkey + guardian/MPC flows.
- Observability: logs, webhooks, status, traceability.
- Pricing model: MAU/tx-based, free tier behavior.
Build with embedded wallets today.
Start with the 4337 quickstart, the 7702 recipe, the Paymaster guide, and Solana support. Add them as internal links from this post so readers can go hands-on in minutes
FAQs
How does an embedded crypto wallet actually work behind the scenes in a consumer mobile app?
It provisions a non-custodial key at signup, protects it (passkeys/MPC), and exposes a branded signing modal. Your backend builds the tx/op, the wallet signs, a relayer/bundler submits, and your UI confirms.
How do embedded wallets work when clients sign up with just an email?
Email (or OAuth) bootstraps identity; the key is created and bound to that identity plus a device factor (passkey) or MPC share. Recovery policies let users regain access later.
How does embedded onboarding compare to traditional seed-phrase flows?
Seedless onboarding removes a scary step, reduces drop-off, and lets you gate risky actions with step-up checks instead of a mnemonic.
What’s the difference between embedded wallets and asking customers to connect a browser extension?
Extensions require installs and context switching; embedded runs inside your UI, supports sponsored fees/batching, and typically converts better—at the cost of owning your security and observability.
Do embedded wallet platforms support in-app signing?
Yes. Show human-readable previews (“Send 15 USDC on Base”), one-tap confirms for safe actions, and step-up for risky ones.
How do I add embedded stablecoin wallets to my app without handling private keys?
Use a non-custodial embedded model (passkeys/MPC) so the user controls signing. Sponsor gas for critical actions via a paymaster, and offer deposits via on-ramp or external transfer.
What are the advantages of using embedded crypto wallets in my app?
Higher signup → first-action conversion, fewer “how do I install a wallet?” tickets, full UX control, and modern AA features (4337/7702, paymasters).