Embedded wallet vs smart wallet: in-app UX vs smart account. They can be the same wallet. Cavos on Starknet is an audited OpenZeppelin account contract.
An embedded wallet lives inside your application. A smart wallet is usually a smart-account or account-abstraction wallet: a contract that can enforce policy, batch calls, or sponsor gas. Searchers type embedded wallet vs smart wallet as if those were two products on a shelf. They are two different questions.
Embedded is where the wallet appears and who provisions it. Smart is what the on-chain account is. An embedded wallet SDK can wrap a smart account, a native system account, or an EOA-style key. A browser extension can wrap any of those too. The embedded wallets pillar is the category definition. This post is the split.
Cavos, LLC is a software and SaaS company. The wallet is the main product. On Starknet Cavos provisions an audited OpenZeppelin account contract. On Solana and Stellar it provisions native accounts, not contract wallets. If the honest answer is an EVM ERC-4337 stack, that stack is not Cavos.
| Question | Embedded wallet | Smart wallet / smart account | |---|---|---| | What it names | Where the wallet appears, and who creates it | What the on-chain account is | | User install | None, in the happy path | Independent of install. Can live in an app or an extension | | Approval UI | Product UI | Product UI, extension popup, or both | | Account type | Native key, MPC key, hosted key, or a contract | A contract account (EVM ERC-4337, Starknet account, similar) | | Typical reason to pick it | Users should never see a wallet picker | Policy, batching, session keys, or a paymaster |
The overlap is the interesting case. A Starknet account is a contract. An embedded Starknet wallet is therefore both: in-app UX, contract account. Calling that "smart wallet vs embedded wallet" as a fork is a category error.
The phrase is not a spec. Three uses show up in vendor copy and in RFPs:
Ask for the account type, the signature scheme, and who can produce a valid signature without the user. The non-custodial embedded wallet guide is that test. The custody page is the control test counsel actually cites.
Embedded is a UX and provisioning label. Login selects the user. The SDK looks up or creates an on-chain address. Approval happens in the app. There is no extension to install and no seed phrase to copy. That is the same definition as on what is an embedded wallet.
It does not decide:
Privy's public docs describe smart account support through integrations. Dynamic lists gasless transactions on EVM through account abstraction as an Enterprise feature. Those are smart-account features on finished embedded wallet products. They are not evidence that "smart wallet" and "embedded wallet" are competitors.
The commercial name for the hosted path is wallet as a service. Same job, sold as a platform.
Four combinations are all real:
The embedded wallet vs browser extension guide is the install-and-approval fork. This page is the account-model fork. You usually need both answers.
A paymaster can sponsor fees for a contract account. A bundler can submit UserOperations. Relayers on Solana and Stellar can pay fees. None of those are signers. Gas Sponsorship in Any Token on Cavos is the same idea, chain-native: SNIP-29 paymaster on Starknet, relayer as fee payer on Solana, sponsored reserves and fee-bumps on Stellar.
Account abstraction also does not make a vendor non-custodial. A hosted key that drives an ERC-4337 account is still hosted. A device-native key that drives an OpenZeppelin account is still device-native. Read the key model, not the AA badge.
Cavos custody is hardware-isolated and non-custodial. Private keys never leave the device in plaintext and are never used for signing on servers. Signing always happens on the user's device. The Nitro Enclave and the passkey only hold an encrypted copy of the master key for restore. Cavos cannot see the key, sign with it, or move funds.
Starknet. Each wallet is an audited OpenZeppelin account contract. Cavos does not ship its own account implementation. One stark key, derived from the MasterDEK and app salt, controls the account. There is no on-chain device list and no on-chain social recovery. execute is a multicall through the paymaster. If your RFP says "smart wallet on Starknet," this is the account you are asking for, inside an embedded SDK.
Solana. A native Ed25519 system account, the same shape as a Phantom address, not a PDA and not a program-derived smart account. A relayer can pay the fee. Arbitrary program calls go through an allowlist.
Stellar. A classic G account, not a Soroban contract wallet. One Ed25519 spend key is HKDF of the same MasterDEK. Exchanges already understand the address. The relayer can sponsor reserves and fee-bumps.
Cavos is not an EVM-wide ERC-4337 wallet layer. If the product is Ethereum-first and the requirement is a 4337 smart account plus MetaMask connection, Privy or Dynamic cover ground Cavos does not. The dated vendor table is embedded wallet providers. The decision tree is best embedded wallet.
Write four answers down before you read a pricing page:
If (4) is login, you want an embedded wallet. If (2) is a contract on Starknet, Cavos already is that. If (2) is ERC-4337 on Ethereum, look at EVM-first providers. If (4) is "connect the wallet they already have," you want a connector, which Cavos is not.
Setup is minutes: npm install @cavos/kit, wrap CavosProvider, sign in, execute. Free up to 1,000 wallets. Essential is $59/month. Complete is $139/month. The React path is how to add an embedded wallet. The App Router path is how to add an embedded wallet to Next.js.
Embedded describes where the wallet lives: inside the app, provisioned at login, with approval in the product UI. Smart wallet usually means a smart-account or account-abstraction wallet: a contract that can enforce policy, batch calls, or sponsor gas. The two are not opposites. An embedded wallet can be a smart account. A browser-extension wallet can be a smart account too.
Only if that product uses a contract account. Cavos on Starknet is an audited OpenZeppelin account contract (AccountUpgradeable v3.0.0) controlled by one stark key. Cavos on Solana is a native Ed25519 system account. Cavos on Stellar is a classic G account. Those last two are embedded wallets and are not contract wallets.
No. Account abstraction (ERC-4337 on EVM, SNIP-29 paymasters on Starknet) is how a chain lets a contract account pay fees, batch calls, or apply policy. Embedded is how the product provisions and presents the wallet. You can ship ERC-4337 behind MetaMask. You can ship an embedded EOA with no abstraction. Ask both questions separately.
Pick the account model the chain requires, then pick where the user signs. If users should never install an extension, you want an embedded wallet. If you need session keys, spending limits, or a paymaster on EVM, you may also want a smart account. Cavos ships the first on Starknet, Solana, and Stellar. It is not an EVM ERC-4337 layer.
On Starknet, yes in the account-model sense: each wallet is an audited OpenZeppelin account contract. Signing is still hardware-isolated and non-custodial. The key is derived and used on the user's device. Keys never leave the device in plaintext and are never used to sign on Cavos servers. On Solana and Stellar the accounts are native, not contract wallets.
Free up to 1,000 wallets. Hardware-isolated, non-custodial. Keys never leave the device in plaintext.
We use anonymous analytics to understand how developers use Cavos. No personal data is collected. Privacy Policy
