An embedded crypto wallet brings wallet functions directly into another application. Users can receive assets and approve blockchain actions without installing a separate wallet app or browser extension. The application often creates the wallet during signup and links access to an email address, social login, one-time passcode (OTP), or passkey.
That simple interface still depends on signing keys, recovery rules, custody choices, and transaction controls. These layers determine who can move assets and what happens when a user loses a device or a provider becomes unavailable. This guide explains how each layer works and what product teams should examine before choosing an architecture.
New to private keys, addresses, and blockchain transactions? Start with our guide to how crypto wallets work.
An embedded wallet is created and used through the host application. A wallet provider typically supplies a software development kit (SDK) or application programming interface (API) for wallet creation, signing, recovery, and transaction tracking.
The application may create a wallet automatically when someone signs up or wait until the first wallet-related action. It connects the wallet to the application’s existing user identity and keeps transaction prompts inside the same interface. Recovery also becomes part of the product’s account lifecycle, including flows for new devices and lost credentials.
The visible experience varies. One application may show an address, balance, transaction history, and send screen. Another may expose only actions such as Pay, Claim, or Buy, while the wallet infrastructure runs behind those buttons.
In either case, the assets remain recorded on the blockchain. The application manages access credentials and transaction interactions; it does not literally hold tokens inside its interface.
Wallet terminology can describe where users interact, how an account behaves, or who controls access. These are separate dimensions.
An embedded wallet can control an externally owned account (EOA), where a private key directly authorizes transactions, or a smart account, where code applies custom rules.
“Embedded” describes the experience.
“Smart account” describes onchain validation and execution.
A programmable wallet may handle payouts, treasury transactions, or automated tasks through APIs without any user-facing wallet. An application can also support embedded and external wallets at the same time, giving newcomers a simpler path while allowing experienced users to connect their existing wallets.
For a broader overview, see our guide to types of cryptocurrency wallets.
The process starts with identity and ends with a confirmed onchain result.
A production system must also handle pending transactions, explain failures, retry safely after RPC outages, account for chain reorganizations, and manage indexing delays.
A single confirmation screen may trigger several systems. A weakness in any one of them can undermine the protections provided by the others.
Authentication establishes who is accessing the application. Email login, OAuth, OTP, SSO, and passkeys can all serve this purpose.
A successful login creates an application session. Blockchain signing may happen later through a separate credential or service.
Authorization determines which actions a user or session may request. Policies may restrict assets, destination addresses, contract interactions, transaction values, or session length.
Higher-risk actions can require step-up authentication, such as a fresh passkey confirmation. If a request breaks a rule, the policy layer should reject it before it reaches the signer.
Signing creates the cryptographic proof accepted by the blockchain or smart account. The operation may use a key on the user’s device, several MPC participants, a key inside a trusted execution environment, or a validation module attached to a smart account.
The signer needs the exact transaction data. If the interface is compromised, it may send the signer an incorrect destination, value, or permission.
Recovery restores or replaces control after a device or credential is lost. A system may use another passkey, an encrypted cloud backup, trusted guardians, stored shares, or a provider-managed verification process.
Recovery authority affects custody because it can change who controls the signer. A provider that can replace the user’s signer may have practical control even when routine transactions require user approval.
Submission broadcasts a signed request to the network. A relayer can perform this operational task without having the authority to create a valid signature itself.
Consider a high-value transfer by a user named Alice. Google login authenticates her, a passkey authorizes the request, an MPC quorum signs it, and a relayer submits it. The interface may show one confirmation screen, but four separate functions are involved.
Key management determines where signing authority lives and which components must remain available. A “seedless” wallet removes the user-managed recovery phrase from the experience; it does not remove cryptographic keys or trust relationships.
The application generates and uses a signing key on the user’s device, preferably with hardware-backed storage where available.
The main challenge is recovery. The system needs a secure way to restore control when the user changes devices, clears browser storage, or loses a phone.
Secret sharing divides one secret into several shares. A defined threshold of shares can reconstruct the original key, which may exist temporarily during signing.
The reconstruction environment is therefore an important security boundary. Teams should ask where reconstruction happens, how memory is isolated, and which shares can be used for recovery. Privy’s on-device architecture documents one key-sharding design that temporarily reconstructs keys in an isolated environment.
Multiparty computation and threshold signature schemes (MPC/TSS) allow several participants to produce a signature together. The complete private key normally remains distributed throughout the process.
A common setup gives the user one share and a server another. The signing threshold, recovery process, administrative combinations, and availability of each participant determine who has control and when transactions can proceed.
A trusted execution environment (TEE), sometimes called a secure enclave, isolates sensitive code and data. Remote attestation allows another system to confirm that approved code is running inside it.
A TEE may protect a complete key or a single share. The design depends on the hardware, enclave code, deployment controls, attestation process, and provider availability. Turnkey’s documented approach uses enclaves for key generation, signing, and policy evaluation.
A passkey is a Web Authentication (WebAuthn) credential tied to a relying party, usually the application’s domain. The W3C WebAuthn specification defines these public-key credentials for strong user authentication.
Some smart accounts can accept a compatible passkey signature directly. Other systems use the passkey to unlock a share, approve an MPC operation, or authorize a separate signer. Because “passkey wallet” can refer to several different designs, teams should trace the complete signing path.
| Model | Where signing authority lives | Is the full key reconstructed? | Main product challenge |
|---|---|---|---|
| Device-local key | User device | No separate reconstruction if generated as one key | Device loss and synchronization |
| Secret sharing | Across stored shares | Often temporarily | Secure reconstruction and recovery |
| MPC/TSS | Across participating shares | Normally no | Availability, latency, thresholds, and recovery |
| TEE | Protected execution environment | The key may exist inside the enclave | Hardware and code trust, plus provider availability |
| Passkey-controlled | Device credential or credential-gated signer | Depends on the architecture | Cross-device recovery and signer compatibility |
Table note: These categories can overlap. A TEE may hold an MPC share, while a passkey may authorize a separate signing system.
Yes. An embedded wallet can use a non-custodial, or self-custodial, model when the user retains the authority required to approve transactions and recover access.
The practical test is unilateral control: Can the application, wallet provider, or recovery operator authorize a transfer or replace the user’s signer without the user? Answering that question requires a map of the entire system.
Ask:
Key export can help with portability, but it does not answer the custody question by itself. Custody depends on every route to asset control, including administrative policy changes and recovery. A downloadable key offers limited protection if the user still needs an unavailable provider to authenticate, reconstruct a share, or replace a smart-account signer.
Read more about the non-custodial wallet model and the broader custodial versus non-custodial decision for businesses.
An EOA uses a blockchain key as its direct source of transaction authority. A smart account uses onchain code to apply custom validation and execution rules, including multiple signers, spending limits, and recovery modules.
Account abstraction brings that programmable behavior into ordinary product flows. ERC-4337 defines a higher-layer system in which bundlers package user operations for smart accounts and paymasters can sponsor network fees. EIP-7702 allows an EOA to delegate execution to code, enabling features such as transaction batching, fee sponsorship, and restricted sub-keys.
These systems can support:
“Gasless” does not mean the network waives its fee. The application, paymaster, or another party pays it on the user’s behalf.
An embedded wallet can work with either an EOA or a smart account. Account abstraction adds programmable behavior; the embedded model determines where users interact. See Ethereum wallets, smart accounts, and ERC-4337 for more detail.
Embedded wallets work well when users care about an outcome making a payment, trading, earning a reward, or owning an in-game item more than they care about managing a wallet. The wallet can stay in the background as long as approval screens still provide enough information for an informed decision.
Identity systems, frontend code, recovery flows, SDK updates, and provider dependencies all operate close to transaction authority.
Email, SMS, and social accounts may lead to asset access when recovery depends on them. Passkeys, multi-factor authentication (MFA), notifications, and step-up checks can better protect new-device access and high-value actions.
A weak recovery process can bypass a strong everyday signer. Test resistance to social engineering, waiting periods, user notifications, cancellation paths, and the exact parties that can replace access.
A compromised frontend may supply the wrong destination, value, or permission. Simulation and readable previews can show the likely result, while policy limits can block requests outside an approved range.
Wallet SDKs run close to authentication and transaction code. Pin reviewed versions, verify signed releases, control update procedures, and monitor changes to signing or recovery behavior.
A provider may lack unilateral control over funds and still be essential for authentication, signing coordination, policy checks, recovery, transaction submission, or indexing. Test degraded modes and document which user actions remain available during each type of outage.
A quiet in-app experience can make irreversible transfers and long-lived permissions easy to overlook. At the point of approval, show the network, asset, amount, recipient, fee payer, and material contract permissions in plain language.
These controls belong within a broader wallet security threat model. Update this link if ND Labs publishes a permanent descriptive URL for the security article.
Provider selection requires more than reviewing the onboarding flow. Teams should examine product behavior, signing control, recovery, portability, and day-to-day operations.
Legal classification depends on the actual control model, the services included, and the target market. Qualified counsel should review the final architecture in every jurisdiction where the product will operate.
The right approach depends on the role the wallet plays in the product and how much control the team needs.
An SDK or Wallet-as-a-Service (WaaS) is often the most direct route when the goal is to add wallet actions to an existing application. It can shorten implementation time if the provider’s supported chains, recovery model, policy tools, and operational dependencies fit the product.
A white-label foundation suits products where the wallet is a substantial branded surface and the team wants an existing mobile and backend foundation. Review ND Labs’ white-label non-custodial wallet and white-label wallet pricing for more information about this route.
Custom crypto wallet development makes sense when a product needs unusual signing policies, a differentiated recovery model, proprietary networks, deep system integrations, or tighter control over its infrastructure.
Define custody, recovery, and failure behavior before choosing an implementation route. These decisions shape the architecture more deeply than the first set of interface features.
An embedded crypto wallet integrates wallet functions into another application. Users can receive assets and authorize transactions through the host product, usually with familiar login methods and without a separate wallet app or browser extension.
They can be custodial or non-custodial. To determine which model applies, examine who can sign transactions, change signers, alter policies, and complete recovery.
Yes. A seedless design may keep a key on a device, split it into shares, distribute signing across MPC participants, protect it inside a TEE, or use a signer accepted by a smart account.
It depends on the design. A smart account may accept a passkey signature directly. Another system may use the passkey for login, to unlock a share, or to approve a separate signer. The important questions are what the passkey signs and what the blockchain ultimately verifies.
Recovery may use a synced passkey, another device, encrypted cloud backup, guardians, stored shares, or provider verification. Teams should test the new-device flow and identify every party that can replace signing authority.
Some implementations allow users to export a private key. Smart accounts may support migration by changing the signer. Portability can also depend on recovery data, account rules, provider availability, and replaceable infrastructure, so the exit path should be tested in practice.
An embedded wallet describes the in-app experience. A smart account is an onchain account with programmable rules. Embedded wallets can control EOAs or smart accounts, and external wallets can use smart accounts too.
Yes. An application can create an embedded wallet while also allowing users to connect an existing wallet. The product team must decide how identity, balances, permissions, and customer support work when one person uses both.
Embedded wallets can make blockchain actions feel like part of an ordinary product. Underneath that experience, the system still depends on signing keys, recovery authority, custody choices, and outside services.
Before implementation, define who can sign, who can recover access, what users will see before approval, and which functions will remain available after device loss or provider failure.
If your product needs an embedded wallet with custom authentication, recovery, transaction policies, or multichain integrations, discuss the architecture with the ND Labs wallet development team.
