What is an embedded wallet?
An embedded wallet lives inside your application. The user signs in the way they already do, and the product resolves an on-chain account they can pay, receive, and sign with — no browser extension, no seed phrase, no trip to another app. The rest of this guide is about what that label does not decide: who holds the key, who can spend, and which chain account model you are actually shipping.
What an embedded wallet is
A wallet, here, is an on-chain account plus the means to authorize transactions from it. For years that meant a browser extension or a dedicated wallet app: the user installs software, writes down twelve words, switches networks, and approves every call in a window the product does not control.
An embedded wallet SDK inverts that. The wallet is a component of the product. Authentication selects which user this is. The SDK looks up or creates an on-chain address for that identity. A signer bound to the session or the device authorizes transactions from inside the app UI. Gas is often sponsored so the user does not need a native token to start.
Teams adopt this model when the audience is not crypto-native. Games, commerce, and consumer finance cannot ask a first-time user to understand seed phrases. The tradeoff is that the application now owns the wallet experience — including recovery, device changes, and how honest it is about who can sign.
Embedded wallets vs browser extensions
Browser-extension wallets keep keys in a separate application. The user installs it, controls the seed, and approves transactions in that UI. The dapp requests access; it does not provision the account. That is the right default when users already have wallets, hold assets across many apps, or must connect an existing address. It is a poor default when the user has never used crypto: another download, another permission prompt, and another place the session can break.
| Question | Browser extension | Embedded wallet |
|---|---|---|
| Who creates the account | The user, in another application | The product, from a login the user already has |
| Where approval happens | A wallet popup the app does not control | In the product UI |
| Portability | High — the same wallet across many sites | Product-scoped unless you also connect or export |
| Typical audience | People who already hold crypto wallets | People who should never see a wallet picker |
Cavos does not connect existing extensions. If connecting MetaMask or WalletConnect is a requirement, a connection-focused provider is the better fit, and the two models can coexist in one product. That split is spelled out on the Cavos vs Dynamic page.
Embedded vs hosted, MPC, and custodial wallets
“Embedded” only says where the wallet appears. It does not say who can move the funds. The same login modal is used for three different custody designs.
Hosted or delegated
The provider, or an HSM it operates, can produce a signature. Email magic-link login often sits on this model: access to the inbox is enough to spend, because the provider holds the signing capability. FinCEN describes hosted wallet providers as account-based money transmitters when they have total independent control over the value.
MPC
The private key is split into shares. Signing reconstructs or jointly computes a signature from those shares — typically some mix of the user’s device, the provider’s network, and a recovery factor. MPC is a legitimate design. It is not the same as “the provider never has a key.” The provider holds a share used in reconstruction. Export is often supported, which is a feature and a different threat model.
Self-custodial, device-native
The signing key is created on the user’s device and does not leave it. The provider cannot see it, cannot sign with it, and cannot move funds. New devices are added by an on-chain approval, not by reconstituting a master key on a server.
Calling a product non-custodial does not make it so. The test is whether the provider can complete a transaction without the user, or holds the means of access. That is the test the custody page cites under MiCA, FinCEN, California, and other regimes.
Key-management models
When a vendor says “embedded wallet SDK,” ask where the signing key lives. Four designs cover almost every product in the category.
Device-native keys
A non-exportable key is generated in the platform's secure store: WebCrypto in the browser, the OS keystore on iOS and Android. JavaScript cannot read the private material out. The device signs; the chain account lists that public key as an authorized signer. This is the Cavos default. In the browser the device key is a non-extractable P-256 key. On React Native it uses the OS keystore. Those platform primitives provide the isolation — the SDK does not enforce non-extractability on Node or other server runtimes.
Passkeys
Passkeys (WebAuthn) are often described as “the wallet.” They are not one thing. On Starknet and Solana in Cavos, the passkey is an on-chain approver that authorizes adding a new device. It never signs transactions; device keys still spend. On Stellar, a WebAuthn PRF credential derives an ed25519 key added as a Horizon signer. That is not 2FA: anyone with the synced passkey (iCloud Keychain or Google Password Manager) can spend, which is also how a synced passkey recovers the G… wallet. When a vendor says “passkey wallet,” ask whether the passkey signs spends, approves devices, or unwraps a key the vendor also holds.
MPC
Shares are distributed so that no single party should reconstruct the key alone. In practice you are trusting the share holders, the reconstruction protocol, and whoever can coerce enough shares. Web3Auth is the well-known social-login implementation of this pattern. Broad chain coverage and key export are the usual reasons to pick it. The cost is a reconstructable key and a provider share in the signing path. Cavos does not split or reconstruct a signing key with MPC.
Enclaves
A secure enclave (AWS Nitro, or a vendor HSM) holds key material that is supposed to be usable only inside a measured environment. Turnkey sits here as infrastructure: you build a wallet on top of policy-driven signing in remote hardware. Remote enclaves are not the user's device. Server-side signing is the point of that design. Cavos uses an enclave only for opt-in hardware-isolated social recovery: an AWS Nitro Enclave with pinned attestation, off by default, which can unwrap a spend key on Solana and Stellar or schedule at most one bounded add_signer on Starknet. It is not general server-side signing. The docs call that path non-custodial, and not trustless.
Custody and regulatory implications
If your company can move a user's crypto, you are holding it. The EU, US money-transmission rules, California, and the UK from 25 October 2027 put a price on that. Argentina writes exclusive self-custody wallet providers out of its registry; Brazil, Costa Rica, Mexico, and the UK never wrote that exception. Figures, statutes, and the control test live on the custody page. This guide does not repeat them.
Two product facts still belong here. Integrating a self-custodial SDK does not mean the rest of the product is unlicensed. Exchange, fiat on-ramps, and sending crypto for a customer are classified on their own. Recovery paths count: a provider that cannot sign in the ordinary flow but can restore a spend key in an incident is a different fact pattern than one that never can. Counsel has to read the recovery path, not only the happy path.
Chain considerations
“One embedded wallet, every chain” usually means an EOA-style key reused across networks, or an account-abstraction layer on EVM. Chains that are not EVM do not share that account model. If you are building on Starknet, Solana, or Stellar, the adapter has to be native — address derivation, signatures, execution, and fees stay explicit per chain.
Starknet
Accounts are smart contracts. Cavos provisions a Cairo DeviceAccount with on-chain secp256r1 (P-256) verification. Execution routes through a paymaster (SNIP-9 execute_from_outside) so users pay no gas. The account is derived on connect and deployed lazily on first execute.
Solana
Cavos provisions a device-account PDA controlled by a P-256 device key. Guarded actions pair Solana's native secp256r1 precompile with the device-account program. A relayer co-signs as fee payer so users hold no SOL to start. Arbitrary program calls (SPL, swaps) go through allowlisted programs.
Stellar
Cavos provisions a classic G… account — not a Soroban contract — so exchanges and existing tools already understand the address. Each device's ed25519 public key is a weight-1 Horizon signer. Extra devices, a passkey, and a recovery code are additional signers, not wraps of a shared seed. The relayer sponsors reserves and fee bumps.
A typed wallet object from one SDK is not the same as pretending every chain is Ethereum. Cavos currently ships those three adapters. It is not an EVM-wide wallet layer; if your product is EVM-first, Privy covers ground Cavos does not.
How to choose a provider
Ask the custody question first, then the chain question, then the product-shape question.
- Who can produce a valid signature without the user present?
- Where does the signing key live — device, MPC shares, HSM, or enclave?
- Which chains are native, and which are a compatibility layer?
- How does a second device get authorized?
- What does recovery actually do, and is it on by default?
- Do you need to connect existing wallets, or provision new ones?
Worked comparisons — including when the other product is the better choice — are on the compare pages: Privy, Dynamic, Turnkey, Web3Auth, and Magic.
Where Cavos fits
Cavos is device-native embedded wallet infrastructure. Applications resolve a self-custodial account from a stable user identity. Signing keys are created and used on the user's device — Cavos cannot see them, sign with them, or move funds. Adapters ship today for Starknet, Solana, and Stellar, via @cavos/kit on web and @cavos/kit/react-native on mobile (Expo Development Builds, EAS, or bare React Native — Expo Go is not supported).
Cavos is not an EVM-wide wallet layer, not a WalletConnect aggregator, and not a drop-in replacement for Privy. It is the better fit when you need those three chains' native account models and a signing architecture with no provider-held reconstructable key. It is the worse fit when you need broad EVM coverage, external wallet connection, or server-side signing as a product feature. The backend is built so it cannot spend user funds or add itself as a signer. Registries, recovery, paymasters, and relayers can coordinate a transaction; they cannot authorize one.
The free tier covers the first 1,000 wallet creates. Pricing and the Complete plan's enclave recovery are documented there. The security write-up is in the concepts and hardware-isolated recovery docs.
Frequently asked
What is an embedded wallet?
An embedded wallet is a crypto wallet that lives inside an application instead of in a browser extension or a separate wallet app. The user signs in with an identity the product already owns, and the app resolves an on-chain account they can pay, receive, and sign with — without installing software or handling a seed phrase.
How is an embedded wallet different from a browser extension?
An extension wallet keeps keys in a separate application the user installs and manages. An embedded wallet is provisioned by the product: login selects the user, the SDK looks up or creates an on-chain account, and approval happens in the app UI. Extensions are the better fit when users already hold wallets you must connect to.
Is an embedded wallet the same as an MPC wallet?
No. Embedded describes where the wallet appears. MPC is a key-management design that splits a private key into shares and reconstructs or jointly computes a signature. Some embedded wallets use MPC; others use device-native keys, delegated HSMs, or remote enclaves. The UX label does not decide custody.
What is a self-custodial embedded wallet?
A self-custodial embedded wallet is one the provider cannot spend from. The signing key is created and used on the user’s device, is not reconstructed from provider-held shares, and the on-chain account is the authority over signers. Calling a product non-custodial does not make it so — the test is who can move the assets.
Does choosing an embedded wallet make my app a custodian?
Only if your company can move the user’s crypto or holds the means of access. The name of the wallet is irrelevant. MiCA, FinCEN, California, and other regimes look at control. Integrating a self-custodial SDK also does not settle exchange, on-ramp, or payment licensing. Recovery paths count; counsel has to read them.
How should I choose an embedded wallet SDK?
Ask who can produce a valid signature without the user, where the key lives, which chains are native rather than compatibility layers, how a second device is authorized, and what recovery actually does. Then match that to the product: provision new accounts, or connect existing ones. Worked comparisons live on the Cavos compare pages.
Pick a chain, then the signing model.
Start with the quickstart, or compare Cavos with the provider you already have on a shortlist.