Embedded wallets 101: a practical guide to digital wallet types for builders

Wallets went from a browser extension on a single laptop to something that quietly lives inside games, fintech apps, and consumer products.

As builders, we now expect users to “have a wallet” without ever installing one.

That’s where embedded wallets come in.

Openfort in one line: Openfort is a wallet orchestration platform that gives apps embedded, non-custodial wallets plus self-hostable key management, without vendor lock-in.

This post is vendor-neutral, but I’ll use Openfort as a concrete example when it helps – especially when we talk about embedded and global wallet solutions.

What is an embedded wallet?

An embedded wallet is a non-custodial crypto wallet that lives inside your app instead of a separate browser extension or external app.

The private key is controlled by the user, but your app owns the UX: signup, sign-in, and transaction prompts, often with email, social login, or passkeys instead of seed phrases.

In practice:

• The user signs up with email / OAuth / passkey.
• Your app generates or connects a wallet key behind the scenes.
• The user interacts with that wallet through your UI: making payments, trading, claiming rewards, etc.
• The user doesn’t need to install MetaMask, Phantom, or write down a seed phrase to get started.

With Openfort’s JS SDK, that wallet is typically a smart or AA wallet backed by OpenSigner – a self-hostable key management layer – and can later be connected to other signers or smart contracts without forcing users to migrate.

What are embedded wallets used for?

Embedded wallets show up wherever you want “crypto rails” but web2-level UX:

• Games that want users to start playing in seconds and only later expose wallet concepts.
• Fintech & neobanks that settle in stablecoins under the hood.
• Prediction markets or DeFi frontends that want to onboard with email and then progressively disclose risk.
• Loyalty & points systems that quietly use tokens in the background.

Instead of asking users to “connect your wallet”, your app creates and owns the UX, while the user owns their keys.

If you want to see real-world patterns, the Openfort recipes show how games, apps and fintechs wire this into their flows.

What are digital wallets?

A digital wallet is any software that stores payment credentials or cryptographic keys and lets users make transactions from a phone or computer.

Examples:

• Your banking app.
• Apple Pay / Google Pay on your phone.
• PayPal, Venmo, Revolut.
• Crypto wallets like MetaMask, Rainbow, or an embedded wallet inside an app.

They all do three things:

1. Store credentials (card numbers, bank tokens, or private keys).
2. Initiate transactions (tap to pay, send to a friend, sign a blockchain transaction).
3. Apply policies and protections (limits, 2FA, device binding, notifications).

Embedded wallets are just digital wallets specialized for blockchain and packaged inside another product.

The three main types of digital wallets

People use slightly different taxonomies, but for most builders it’s useful to think in three buckets.

Short answer:

The three main types of digital wallets are custodial wallets, non-custodial wallets, and embedded or in-app wallets that are usually non-custodial but tightly integrated into an app.

1) Custodial wallets

• A provider (exchange, fintech, CEX) holds the private keys for you.
• You log in with email/password or KYC, and they show you a balance.
• Think: centralized exchanges, some neobanks.

2) Non-custodial device wallets

• The user directly controls the private key on their device.
• Could be a browser extension (MetaMask), a mobile app, or hardware wallet.
• “Not your keys, not your coins” in its pure form.

3) Embedded / in-app wallets

• The wallet lives inside a specific app.
• It’s usually non-custodial (user owns key material) but everything happens through the app’s UX and auth.

How many types of digital wallets are there?

You can slice this further (hot/cold, mobile/desktop, MPC/hardware, etc.), but most UX and infra decisions can be made using the three categories above.

The three types of crypto wallets

For crypto specifically, another common classification is:

The three main types of crypto wallets are custodial wallets, non-custodial EOAs (externally owned accounts), and smart or embedded wallets.

1. Custodial crypto wallets
   • Your exchange account; the platform signs transactions on your behalf.
   • Easier UX, but you accept platform risk and limited composability.
2. Non-custodial EOAs
   • Classic wallets based on a seed phrase and a single private key.
   • You sign everything, you manage backup and recovery.
3. Smart / embedded wallets
   • Wallets implemented as smart contracts or account abstraction accounts.
   • They support policies: spending limits, session keys, social recovery, multi-signer setups, etc.
   • Embedded wallets are usually smart or AA wallets hidden behind web2-style UX.

Openfort is firmly in the third bucket: non-custodial smart/embedded wallets, controlled via OpenSigner and compatible with standards like EIP-4337 and EIP-7702.

If you want to explore the SDKs, the code is open at

github.com/openfort-xyz/openfort-js and

github.com/openfort-xyz/openfort-react.

A very rough (pseudo-)example with the JS SDK

The exact APIs evolve, so treat this as pseudo-code – the point is the pattern:

// 1) Install
// npm install @openfort/openfort-js

import { Openfort } from "@openfort/openfort-js";

const openfort = new Openfort({
  publishableKey: process.env.NEXT_PUBLIC_OPENFORT_PUBLISHABLE_KEY!,
});

// Somewhere in your auth flow
async function loginAndCreateWallet(email: string) {
  // 2) Log the user in with email (or bring your own auth)
  const user = await openfort.auth.loginWithEmail({ email });

  // 3) Provision an embedded wallet for that user
  const wallet = await openfort.wallets.createEmbeddedWallet({
    userId: user.id,
  });

  // 4) Use the wallet to sign a transaction
  const txHash = await openfort.wallets.sendTransaction({
    walletId: wallet.id,
    to: "0xProtocolOrGameContract",
    data: "0x...",
  });

  return { user, wallet, txHash };
}

In a real app, you’d likely use the React SDK with wagmi/viem, or follow one of the recipes to plug into an existing Next.js or Expo template.

How do embedded wallets work under the hood?

Implementation details differ, but a modern embedded wallet stack usually looks like this:

1. Authentication
   • User signs in with email, social login, or passkey.
   • The app gets a stable user ID (from your auth provider or its own system).
2. Key generation and storage
   • A private key (or key shares) is generated, often client-side.
   • Keys might be split using MPC, stored across device + server + secure enclave, or represented via a smart contract account.
3. Wallet representation on-chain
   • That key or set of keys controls an EOA or a smart account (account abstraction).
   • This wallet can send, receive, swap, or interact with contracts, same as any other wallet.
4. UX orchestration
   • The app shows balances, actions (send, swap, bridge, claim), and transaction confirmations.
   • Users see “Approve purchase” or “Confirm withdrawal”, not raw calldata.
5. Policies and recovery
   • You can add policies: daily limits, whitelisted contracts, 2FA for high-risk actions, social recovery, etc.

With Openfort, this stack is modular:

• OpenSigner handles key management in a self-hostable way (you can run it in your own infra).
• The Openfort SDKs (JS, React, Swift, etc.) embed the wallet into your app’s UI.
• You can plug in any signer or delegator contract later, so you’re not locked into one vendor or one account model.

For a hands-on walkthrough, there’s a guide on how to create and recover embedded wallets and a live demo you can play with in the browser.

When should you use embedded wallets vs extensions or custodial accounts?

There isn’t a universal answer, but there are clear patterns.

You probably want embedded wallets if:

• You care about conversion and retention more than “wallet sovereignty” on day one.
• Your users are not crypto-native.
• You want to ship features like “sign in with email, pay with USDC” without teaching users about chains and RPCs first.
• You want to keep self-custody (no balance on your balance sheet) but still control UX and risk policies.

You probably want bring-your-own self-custodial wallets if:

• Your users already live in DeFi.
• They expect to choose their wallet (hardware, extension, mobile).
• You don’t want to touch key management at all.

You might accept custodial accounts if:

• You’re operating as a regulated custodian anyway.
• You need strong KYC / AML and fiat integration from day one.
• You’re okay with holding users’ assets on your books.

The nice part is you don’t have to choose once and for all.

With Openfort, you can:

• Start with embedded non-custodial wallets.
• Offer a “connect your own wallet” option for power users.
• Later, bring some or all of the key management in-house by self-hosting OpenSigner, without forcing users to migrate wallets.

When you’re ready to try it in your own stack, you can jump into the

Openfort dashboard or follow one of the integration recipes.

Summary

• Embedded wallets are non-custodial crypto wallets that live inside your app and are accessed via familiar logins instead of seed phrases.
• They sit inside the broader world of digital wallets, alongside banking apps and Apple Pay.
• For crypto, you can usually think in three types: custodial wallets, non-custodial EOAs, and smart/embedded wallets.
• Embedded wallets give you the best shot at web2-grade UX with web3 rails, especially when paired with account abstraction and strong key management.

If you’re building an app and want this kind of UX without giving up control or getting locked into one vendor, you can start from the Openfort dashboard and explore the embedded wallet docs to see how it fits your stack.