Ask a mainstream user to write down twelve random words, store them somewhere they will never lose them but no one else can find, install a browser extension, fund it with gas, and bridge assets to the right network before they can place a single trade — and most of them will close the tab. Crypto's onboarding flow was designed by and for people who already understand crypto. Everyone else treats it as a wall. For a consumer trading app, that wall is the difference between a signup and a customer.
Embedded wallets take that wall down. They let a user log in with an email address or a social account and start trading in seconds, while still holding their own keys. This guide explains what embedded wallets are, how "self-custodial with no seed phrase" is technically possible, the trade-offs against custodial and traditional self-custody, and what the pattern enables for an exchange.
Why Crypto Onboarding Loses Mainstream Users
The standard web3 entry path stacks several unfamiliar tasks on top of each other before any value is delivered:
- Seed phrases. A twelve- or twenty-four-word mnemonic is the master key to everything. Lose it and funds are gone; expose it and funds are stolen. That is a brutal first interaction to hand someone who just wanted to try your app.
- Browser extensions. Installing and configuring a wallet extension is friction, and it ties the user to a specific browser and device.
- Gas. Users must hold a network's native token to pay for transactions — a chicken-and-egg problem when they have not deposited anything yet.
- Bridging. Assets often sit on the wrong chain, so users face a separate, error-prone bridging step before they can trade.
Each step is a place to get confused, get scared, or get phished. Web2 products taught people to expect "sign in and go"; crypto onboarding front-loads its hardest concepts instead. The result is predictable: high intent at the top of the funnel, heavy drop-off before the first trade.
What an Embedded Wallet Is
An embedded wallet is a wallet that the application creates and provisions for the user inside the product itself, typically at the moment they log in with email or a social account. There is no extension to install and no seed phrase to copy down. From the user's perspective, signing up for a trading app feels like signing up for any web2 service. Underneath, a real blockchain wallet is generated and tied to their authenticated identity.
The category is sometimes called social login wallets because the login method — email, Google, Apple, a passkey — doubles as the entry point to the wallet. Providers such as Privy and Dynamic offer this as infrastructure, handling key provisioning, authentication, and signing so the exchange does not have to build the cryptography from scratch.
The interesting engineering question is the one that sounds like a contradiction: if there is no seed phrase, who holds the key, and is it still self-custodial? The answer depends on which of two technical approaches the wallet uses.
How "Self-Custodial With No Seed Phrase" Works
There are two main ways to give a user a wallet they control without ever showing them a mnemonic. They solve the problem differently, and it is worth being precise about each.
MPC and threshold signatures
Multi-party computation (MPC) wallets never assemble a single private key in one place. Instead, the key material is split into shares, and signing is performed collaboratively: each party computes over its own share so that a valid signature is produced without any party ever reconstructing the full key. A common arrangement splits the key into shares held across different parties — for example, one on the user's device, one held by the wallet provider's infrastructure, and a backup share gated behind the user's authentication or a recovery factor.
The security property is a threshold: a defined number of shares must cooperate to sign, and no single share is sufficient on its own. Because the full key is never materialized, there is no seed phrase to lose or steal. Self-custody here means the user's authenticated participation is required to sign; the provider's share alone cannot move funds. The honest trade-off is that the security model now depends on the specific share distribution and the provider's implementation — it is self-custodial, but the guarantees rest on how the shares are split and protected, not on a single secret the user physically holds.
Smart-contract accounts and account abstraction
The second approach moves custody logic on-chain. With account abstraction, the user's account is a smart contract rather than a plain externally owned account. The contract defines its own rules for what counts as a valid transaction — which signers are authorized, what limits apply, how recovery works — instead of relying solely on one private key.
This enables features that are awkward or impossible with a raw keypair: social recovery (designated guardians can help restore access), spending policies, gas sponsorship so users do not need to pre-fund a native token, and batched actions. A signing key still authorizes transactions, but the contract account is the source of truth for authorization, which is what makes flexible recovery and permissioning possible.
The two approaches are not mutually exclusive — a product can use an MPC-secured signer to control a smart-contract account. Conceptually, MPC is about how the key is held, while account abstraction is about how the account decides what is authorized.
Session Keys and Scoped Signing for Smooth Trading
Even with a frictionless wallet, a trading app that prompted the user to approve every single order would feel broken. Active traders place and cancel constantly; a signature pop-up per action is unusable.
The pattern that solves this is scoped, time-limited signing authority, often called session keys or agent keys. The user grants the application a key that is permitted to sign only a constrained set of actions — for instance, placing and cancelling orders on a specific venue — for a limited window, without authority to withdraw funds. The session key signs the high-frequency trading actions silently; the user's primary key is only needed to grant or revoke that permission.
Two properties make this safe rather than reckless:
- Scope. The delegated key's powers are deliberately narrow. It can trade, but it cannot drain.
- Revocability. The permission can be withdrawn at any time, and it expires on its own.
PropHub's web3 stack applies exactly this model: email or social login creates an embedded self-custodial wallet with no seed phrases or extensions, and execution on a venue is authorized through scoped, revocable agent permissions, so the private key itself never leaves the user. The user gets a web2-grade trading experience; the signing authority stays bounded and reversible.
Funding, Recovery, and the Trade-Offs
A wallet is only useful once it has money in it, and the deposit step is where many crypto apps reintroduce the friction they removed at signup. The mainstream-friendly answer is to accept familiar payment methods and handle chain logistics behind the scenes. PropHub funds accounts via Pix, SEPA, UPI, cards, Apple Pay, Google Pay, or crypto, and routes deposits from any supported source chain to the trading venue, orchestrating the bridging so the user never has to think about which network their balance lives on. Settlement happens on Hyperliquid, with wallet infrastructure provided through partners including Dynamic.xyz.
On recovery, be realistic about what each model offers. Traditional self-custody puts recovery entirely on the user via the seed phrase — maximum sovereignty, maximum personal risk. Embedded wallets shift some of that burden to the login method and, depending on the architecture, to recovery shares or on-chain guardians. That is a genuine usability win, but it ties account security to the user's email or social account and the provider's design. Account-takeover protection on the login layer matters as much as the cryptography.
Here is how the three models compare:
| Dimension | Custodial | Embedded (self-custodial) | Traditional self-custody |
|---|---|---|---|
| Who holds the key | The exchange | The user, via key shares or a smart account | The user, as a single private key |
| Onboarding | Email signup, easy | Email/social login, easy | Seed phrase, hard |
| Can the provider move funds alone | Yes | No | No |
| Seed phrase | None | None | Required |
| Recovery | Provider-managed | Login + recovery share or guardians | Seed phrase only |
| Counterparty risk | High | Limited to signing design | None |
What This Enables for Exchanges
The payoff of embedded wallets is not just a nicer signup screen — it changes who an exchange can serve. A product that onboards with a social login wallet reaches users who would never have made it past a seed phrase, while keeping the trust posture of self-custody rather than holding customer funds. Combined with fiat on-ramps and automatic deposit routing, the app can meet users where they already are — Pix in Brazil, SEPA in Europe, UPI in India — and quietly handle the cross-chain mechanics that used to be the user's problem.
For founders, this is the bridge between two worlds. The infrastructure questions — non-custodial signing, MPC or account abstraction, session-key UX — are now solvable with mature tooling, freeing a small team to compete on product and distribution. If you are weighing the broader build, our guides on launching a white-label crypto exchange and what a Hyperliquid builder is cover the venue and economics side of the same decision.
The deeper point is that "self-custodial" and "easy" stopped being opposites. For most of crypto's history, sovereignty cost convenience: you either trusted a custodian or you managed a seed phrase. Embedded wallets dissolve that trade-off by splitting the hard problem — key custody, recovery, and signing — into pieces that can each be made both safe and invisible. The exchanges that internalize this will not market themselves as crypto products at all. They will simply be trading apps that happen to settle on-chain, and their users will never know, or need to know, that there was ever a seed phrase to lose.