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.
Where it lands in Jayverse
- Wallet: draw the authority matrix for jayverse-wallet before shipping. Fill in who can sign, recover and export for the embedded wallet's own recovery mode, export flow and any server-side session signer, from observed behavior rather than the provider's docs.
- Rabbit: session keys and mandates are the scoped-app-signer row. ERC-4337/EIP-7702/7715 session keys need the same test as the PoC's fourth path — what a mandate can do without the user, and whether the app can widen its scope without a fresh user approval.
- Devnet: run the four failure paths there first. New device, lost auth factor, key export, and a scoped signer are cheap to reproduce on Devnet before testing them on Sepolia, and the matrix should be filled in from what actually happens, not from the wallet provider's marketing.
- Auditor: publish the wallet's authority matrix as a standing artifact. Since the end user never sees who can approve recovery or change signer policy, that matrix — not a custody claim in prose — is what the Auditor row should carry for jayverse-wallet.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| escape hatch | 문제 생겼을 때 빠져나갈 비상 수단 · "Verify the escape hatch" |
| cosmetic | 겉치레뿐인, 실속 없는 · "or the policy is cosmetic" |
| custody | 자산에 대한 보관·통제 권한 · "custody and authorization questions" |
| scoped signer | 권한이 제한된 서명 주체 · "a scoped application signer" |
| widen the scope | (권한) 범위를 넓히다 · "who can widen that scope later" |
| implementation detail | 겉으로 안 드러나는 구현상의 세부사항 · "an implementation detail instead of a prerequisite" |
| deplatform | 플랫폼 이용을 끊고 퇴출시키다 · "if Privy is down or deplatforms you" |
| availability veto | 접근 자체를 막을 수 있는 거부권 · "Privy holds an availability veto" |
| reveal itself | (숨어 있던 정체가) 드러나다 · "the real custodian reveals itself" |
| gate exposure | 노출·접근 범위를 제한하다 · "Can gate exposure — verify" |
| quietly concentrates | 눈에 안 띄게 한쪽으로 쏠리다 · "authority quietly concentrates in the app stack" |
| MFA | 다중 인증(Multi-Factor Authentication) · 로그인 시 추가 인증 수단, 복구 실패 시나리오에서 언급. "test device loss, key export, MFA recovery" |
| MPC | 다자간 연산(Multi-Party Computation) · 키를 한 곳에 두지 않고 여러 당사자가 공동 서명하는 방식. "the key never exists in one piece" |
| TEE | 신뢰 실행 환경(Trusted Execution Environment) · 서버 쪽에서 키 연산을 격리 실행하는 하드웨어 보안 영역. "a TEE on a server" |
| MetaMask | 메타마스크 · 브라우저 확장형 외부 지갑, 임베디드 지갑과 대비되는 전통적 지갑의 예시. "A conventional wallet (MetaMask) is external" |
| Shamir key sharding | 샤미르 비밀 분산 · 개인키를 조각으로 나눠 서명 시점에만 잠시 재조합하는 기법. "split into shares, reassembled briefly at signing time" |