TL;DRMost 'self-custody crypto wallet' guides assume you're a person downloading an app. This one is for the developers embedding a wallet into their product. Self-custody no longer means a seed phrase — Openfort's open-source OpenSigner splits the key into three shares (any two reconstruct it) across the user's device, their login, and an encrypted recovery share, recombining only inside a sandboxed iframe at signing time. The result is a wallet the user fully controls, created silently at sign-up, with email/social/passkey login and built-in gasless transactions. Both Openfort and Privy offer self-custodial embedded wallets (Privy uses Shamir's Secret Sharing too), but Openfort is open-source, has native ERC-4337/7702 smart accounts and built-in paymasters, supports any OIDC provider, and exports keys with no vendor lock-in — while Privy is now part of Stripe and leans on third-party smart-account integrations.
Most guides about the self-custody crypto wallet assume you are a person looking for an app to download. This one is for the people on the other side of the screen: the developers who have to put a wallet inside a product.
Here is the thesis, stated plainly. Self-custody is no longer a consumer download. It is an SDK decision. You can give every user a wallet they fully control without ever showing them a seed phrase — and you can ship it this week.
That reframe matters because the search results for "self-custody crypto wallet" are crowded with consumer apps. The builders searching the same term are underserved. This guide fills that gap, explains how embedded self-custody actually works, and compares how Openfort and Privy approach it.
What "self-custody" actually means (and what it doesn't)
Custody is about who can move the funds. There are three models, and the words get muddled constantly.
| Model | Who holds the keys | Who can move funds |
|---|---|---|
| Custodial | The provider | The provider (e.g. an exchange) |
| Non-custodial / self-custodial | The user | Only the user |
| Embedded self-custody | The user (split key) | Only the user, via your app's UX |
A self-custodial crypto wallet means the user — not you, not the provider — controls the keys. The common assumption is that self-custody requires a 12-word seed phrase the user must guard forever. That assumption is outdated.
Modern self-custody splits the key so no single party ever holds the whole thing. The user keeps custody; the seed-phrase ritual disappears. That is the difference between self-custody as a security model and the seed phrase as a user-experience tax. You can keep the first and drop the second. See how Openfort frames the trust boundary on the security page.
Self-custody as infrastructure, not an app
This is the angle the high-volume search results underplay. Almost every top result is a wallet you download. But if you are building a game, a fintech app, or a consumer crypto product, you do not want to send users somewhere else to get a wallet. You want the wallet in your product.
That is the difference between the two ways to read "cryptocurrency wallet software":
- Wallet as a destination — the user leaves your app, installs a wallet, copies a seed phrase, comes back. Most drop off.
- Wallet as infrastructure — the wallet is created silently when the user signs up, lives inside your app, and stays self-custodial.
Openfort is built for the second reading. It is turnkey embedded self-custody: one SDK, the user holds the key, no seed-phrase onboarding. That is what the embedded wallet and wallet-as-a-service products are for — and it is the framing the consumer-wallet results around this keyword largely skip.
How embedded self-custody works under the hood
If the user never writes down a seed phrase, where does the key live? The answer is secret sharing — splitting one private key into multiple shares so no single location ever holds the whole key.
OpenSigner, Openfort's open-source signer, splits the key into three shares, any two of which can reconstruct it (a 2-of-3 scheme). The shares live in three different places:
- Device share — held in the browser's domain-protected storage on the user's device.
- Auth (hot) share — released only against the user's auth-provider tokens (their blockchain login).
- Recovery (Shield) share — an encrypted recovery share that acts as the stepping stone for every login on a new device.
No server ever holds the full key. The shares are combined only inside a sandboxed iframe, which is the only component that ever sees the fully reconstructed key, and only for the moment a transaction is signed.
Because two shares (device + auth) cover the everyday case and the third (recovery) covers the lost-device case, the user gets self-custody and recoverability — without a seed phrase. The implementations are audited and open source, so you can verify the trust boundary rather than take it on faith (opensigner.dev).
On top of the signer, an account abstraction layer adds smart-account features — gasless transactions, batched calls, and programmable recovery — so self-custody does not mean a worse experience than a custodial app.
Self-custody auth without the seed phrase
"Blockchain login" usually conjures a browser extension and a pop-up. It does not have to.
Because one key share is bound to the user's identity, you can let people sign in with email, a social account, or a passkey — the web2 patterns they already know — and still resolve to a self-custodial key. The user authenticates like it is 2026; custody stays on-chain. Openfort handles this through its authentication layer, which works with any OIDC provider.
This is not a cosmetic win. Seed-phrase onboarding is where consumer crypto products lose most new users. Removing it while keeping self-custody is the single biggest activation lever for a builder, which is exactly why it belongs at the center of any honest "self-custody crypto wallet" conversation.
Openfort vs Privy: self-custody approaches compared
Both companies offer self-custodial, embedded wallets for developers — so this is a fair fight, not a strawman. Privy has strong brand authority, clear self-custodial messaging, and, since its June 2025 acquisition by Stripe, deep stablecoin-payment integration through Bridge. Where the difference shows up for builders is how open the infrastructure is and how much of the wallet stack is native versus stitched together from third parties.
A useful detail for this guide: Privy's key management uses Shamir's Secret Sharing — the same "secret sharing" mechanism described above. So both products are genuinely self-custodial via split keys; the divergence is everything built around the key.
| Dimension | Openfort | Privy |
|---|---|---|
| Custody model | Self-custodial (user holds key) | Self-custodial (user holds key) |
| Open source | OpenSigner (MIT) | Proprietary |
| Key management | OpenSigner + TEE backend wallets | TEE (Shamir's Secret Sharing) |
| Smart accounts | Native (ERC-4337, EIP-7702) | Third-party integrations |
| Authentication | Any OIDC provider | Socials / email / wallets |
| Gasless transactions | Built-in paymasters | Basic |
| Vendor lock-in | None — exportable keys | High — Stripe ecosystem |
| Permission model | On-chain (session keys) | Off-chain (policy API) |
| Pricing | Usage-based (per operation) | Free tier, then $299/mo up to 2,500 MAUs |
| Parent company | Independent | Stripe |
The angle Privy's content underplays for builders is right there in the table: native smart accounts, built-in gasless paymasters, any-OIDC auth, and exportable keys with no ecosystem lock-in. Privy covers the self-custodial-wallet basics well — but smart accounts and gas sponsorship lean on third parties, and post-acquisition you inherit Stripe-ecosystem gravity. For the full breakdown, see the Openfort vs Privy comparison and our Privy alternatives guide.
How to add a self-custody wallet to your app
The whole point of treating self-custody as infrastructure is that the integration is short. With Openfort the path looks like this:
- Wrap your app in the Openfort and wagmi providers, passing your publishable key and the Shield key that backs the cold-storage recovery share.
- Configure your login methods (email, social, or passkey).
- Create the embedded wallet on sign-up — the user's self-custodial key is sharded silently (2-of-3, as above).
- Sign a transaction or message; shares combine only inside the iframe, custody stays with the user.
- Optionally enable gasless transactions via the account-abstraction layer.
_31import { OpenfortProvider, getDefaultConfig } from "@openfort/react";_31import { WagmiProvider, createConfig } from "wagmi";_31import { QueryClient, QueryClientProvider } from "@tanstack/react-query";_31import { sepolia } from "viem/chains";_31_31const wagmiConfig = createConfig(_31 getDefaultConfig({_31 appName: "My App",_31 chains: [sepolia],_31 ssr: true,_31 })_31);_31_31const queryClient = new QueryClient();_31_31export function Providers({ children }: { children: React.ReactNode }) {_31 return (_31 <WagmiProvider config={wagmiConfig}>_31 <QueryClientProvider client={queryClient}>_31 <OpenfortProvider_31 publishableKey={process.env.NEXT_PUBLIC_OPENFORT_PUBLISHABLE_KEY!}_31 walletConfig={{_31 shieldPublishableKey: process.env.NEXT_PUBLIC_SHIELD_PUBLISHABLE_KEY!,_31 }}_31 >_31 {children}_31 </OpenfortProvider>_31 </QueryClientProvider>_31 </WagmiProvider>_31 );_31}
The shieldPublishableKey wires up the cold-storage recovery share described above — it is what lets a user restore their self-custodial wallet on a new device without a seed phrase. Pricing scales with usage (per operation), not per seat — check the current tiers on the pricing page.
When you should not build self-custody yourself
Honest counter-section, because the turnkey claim only holds if the alternative is real work. Rolling your own secret-sharing scheme means owning:
- A security audit of your key-splitting and signing code.
- Key rotation and share-refresh logic.
- Account recovery for lost devices, without a custodial backdoor.
- Ongoing maintenance as chains and standards change.
If your product is the wallet, that investment may be worth it. If your product is a game, a payments flow, or a consumer app and the wallet is a means to an end, embedding turnkey self-custody is the faster, lower-risk path.
Frequently asked questions
What is a self-custody crypto wallet? A wallet where the user — not a provider or exchange — controls the private keys, so only they can move the funds. Embedded versions keep that control while hiding the seed-phrase complexity.
Is an embedded wallet still self-custodial? It can be. If the key is split so no single party (including the provider) ever holds the whole key, the user retains custody even though the wallet lives inside your app.
How is self-custody possible without a seed phrase? Through secret sharing. Openfort's OpenSigner splits the private key into three shares — tied to the user's device, their login, and an encrypted recovery share — and any two can reconstruct it. The user signs in with email, social, or a passkey, and the shares combine only inside a sandboxed iframe to sign. There is no seed phrase to write down.
What's the difference between Openfort and Privy for self-custody? Both offer self-custodial embedded wallets, and both split the key (Privy uses Shamir's Secret Sharing). The difference is the surrounding stack: Openfort is open-source (OpenSigner, MIT), has native ERC-4337/7702 smart accounts, built-in paymasters for gasless transactions, any-OIDC authentication, and exportable keys with no vendor lock-in. Privy relies on third-party smart-account integrations and is now part of Stripe. See the full comparison.
Is self-custody safer than a custodial wallet? It removes the single-point-of-failure risk of a provider holding everyone's funds, but it shifts responsibility for access and recovery to the user. Sharded self-custody aims to keep the safety of user control while adding recoverability through an encrypted recovery share.
How long does it take to add a self-custody wallet to an app? With a turnkey SDK like Openfort, a basic embedded self-custody wallet is a same-day integration — you wrap your app in a provider, configure login methods, and the wallet is created automatically when the user signs up.
Related reading
- Openfort vs Privy — the head-to-head comparison.
- Top Privy alternatives in 2026 — the wider landscape after the Stripe acquisition.
- Wallet-as-a-Service — the pillar overview.
- Embedded wallets — the product this guide is built around.
- Security — how the custody boundary is enforced.