Why
The trend is not "wallets became easy." Wallet responsibilities moved into the application. The PoC measures whether the user has an exit and whether the app can act beyond what the UI implies.
Embedded wallets and passkeys remove the seed phrase from onboarding. They do not remove custody and authorization questions; those questions move into recovery, export, additional signers, and policies controlled through the application stack.
How it works
Build one login-to-first-transaction flow with an embedded wallet, then test device loss, key export, MFA recovery, and a scoped app signer. Draw the authority matrix before judging the UX.
PoC
Build login-to-first-transaction with an embedded wallet. Then test four paths: a new device, lost authentication factor, key export, and a scoped application signer. Produce the authority matrix before comparing click counts.
| Actor | Can sign? | Can recover? | Can export? |
|---|---|---|---|
| User | Under configured authentication | Test explicitly | Verify the escape hatch |
| Application signer | Only within policy — or the policy is cosmetic | No | No |
| Provider | Depends on custody and key architecture | Document the exact role | Document the exact role |
Reference: Privy embedded-wallet overview.
Notes — background for the PoC (2026-09-02)
What an embedded wallet is
A conventional wallet (MetaMask) is external: a separate app or extension the user installs, holding a seed phrase, that websites connect to. An embedded wallet lives inside the application. Logging in with email, Google, or a passkey silently provisions a real on-chain wallet — no extension, no seed-phrase ceremony, no visible "wallet" concept at all. The wallet becomes an implementation detail instead of a prerequisite, which is why this is now the default onboarding pattern for consumer crypto apps.
The technical trick is that no single place ever holds the whole private key: either MPC (the key never exists in one piece; parties co-sign) or Shamir key sharding (split into shares, reassembled briefly at signing time), with signing inside an isolated environment — a sandboxed iframe on the client, or a TEE on a server.
Privy specifically
- Shamir 3-share model — a device share (browser/app storage), an auth share (held by Privy, released after login), and a recovery share. Any two reconstruct the key briefly inside an isolated iframe; Privy's servers never see the full key.
- Recovery — the recovery share sits with Privy (default "automatic" mode) or is user-controlled (password-encrypted, or in iCloud/Google Drive). This choice is the custody decision — it is the answer to the lost-auth-factor path.
- Export — users can export the full private key through a Privy-hosted flow; the app configures whether this is exposed.
- Server wallets & session signers — TEE-based server-side wallets plus scoped signers with a policy engine ("this signer may only call this contract, up to this amount"). That is the fourth path.
- Context — Stripe acquired Privy in June 2025 (paired with its stablecoin acquisition, Bridge): embedded wallets are becoming mainstream payments plumbing. Farcaster and Hyperliquid ship on it. Competitors — Dynamic, Web3Auth, Magic, Turnkey, Coinbase Embedded Wallets, thirdweb — differ exactly along the authority-matrix dimensions: who holds which share, how recovery works, who can change policy.
What each of the four paths measures
- New device — a fresh device has no device share, so login requires Privy's servers to participate. The uncomfortable question: if Privy is down or deplatforms you, can you sign at all? Expected answer: not without a prior export. Privy holds an availability veto — it cannot take the assets, but it can block access.
- Lost authentication factor — recovery is where the real custodian reveals itself: whoever can approve recovery can, in effect, take the wallet. If recovery is "email a support team," the custody story is weaker than the marketing.
- Key export — the exit door, and the strongest evidence for the self-custody claim. Test more than existence: the friction, whether the app developer can disable it, and whether the exported key is complete (it should reconstruct the same address in a vanilla wallet).
- Scoped app signer — the delegation boundary: what can the app do without the user, and who can widen that scope later? A policy the developer can rotate silently is a different object from one the user must re-approve.
The matrix before click counts
Click counts measure onboarding friction; the matrix measures the trust model. Comparing UX first is how "2 clicks to a wallet" hides that several parties can act on the funds. Expanded matrix — rows are actions, columns are actors; fill each cell as alone / needs cooperation / cannot, from observation, not docs. Expected values to verify:
| Action | User | Privy | App developer |
|---|---|---|---|
| Sign a transaction | Alone, after login | Cooperation — releases the auth share | Within signer policy only |
| Export the key | Alone, if exposed | Cooperation — hosts the flow | Can gate exposure — verify |
| Approve recovery | Depends on recovery mode | Default holder of the recovery share | Chooses the recovery mode |
| Add / scope a signer | Consent per config — verify | Executes policy | Initiates |
| Change policy | Re-approval? — verify | Enforces | Often alone — verify |
| Block access (availability) | — | Auth-share veto | Can remove the UI |
The most interesting cells are usually "approve recovery" and "change policy" — that is where authority quietly concentrates in the app stack. Prediction to test: the app developer holds more authority than users assume, and Privy holds the availability veto. Neither appears in a click-count comparison.
The developer is the auditor
The end user never sees any of this — that is the point of embedded wallets, and the risk. Whatever the integrator configures becomes the custody reality users silently inherit. And the answers are configuration choices, not fixed properties: "Privy is non-custodial" is a marketing sentence, and two apps on the same Privy SDK can have genuinely different custody models. Run the four paths by hand because docs describe the design; the paths reveal deployed behavior — unnoticed defaults, failing flows, support-team backdoors. That is also why the matrix comes first: it forces "who can do what" onto paper as observed facts before any UX judgment.