Who Actually Controls an Embedded Wallet?

Convenience is not the same as control

If an embedded wallet disappears with its provider, it was never truly the user's wallet. Before choosing a provider, enterprises should ask whether the wallet is genuinely non-custodial, whether users will retain access if the provider becomes unavailable, and whether the service's economics align with the business.

Embedded wallets have made blockchain applications substantially easier to use. A user can create an account inside an application without installing a separate wallet, recording a seed phrase, or learning how public and private keys work.

Our embedded-wallet overview explains the category and its high-level tradeoffs; this article goes deeper on operational continuity—what must remain available for users to keep signing and accessing assets if the original provider is no longer in the loop.

But a simple interface does not necessarily mean the underlying wallet is independent of the provider that created it.

Some provider-managed embedded wallets rely on proprietary, cloud-hosted cryptographic infrastructure to authorize transactions. The user may be described as controlling the account, but continued access still depends on the provider's servers, policies, pricing, and continued operation.

That distinction matters because nominal ownership means little without continued access.

Is the wallet genuinely non-custodial?

A wallet is genuinely non-custodial only when the user controls transaction approval and the provider cannot move assets independently. Enterprises should begin by asking who holds the key, who can move assets, and who approves transactions.

These are necessary questions, but they do not fully address operational control.

A wallet can be described as self-custodial while still requiring a particular provider to reconstruct credentials, coordinate signatures, or approve access. If that service becomes unavailable, the user may still own the assets onchain while losing the practical ability to access or recover them.

MPC is not itself the source of lock-in. The mechanical question is where the signing participants live and whether the user can satisfy the quorum independently. Web3Auth, for example, describes a self-custodial MPC model in which users can sign without the server, while its own comparison explains that server-only MPC executes signing across provider-hosted nodes. Privy documents a separate 2-of-2 key-share architecture in which its API and TEE participate in each signature; Turnkey uses a secure-enclave model in which encrypted private keys are decrypted and used only inside the enclave under policy. The label matters less than the actual signing path.

Will users retain access if the provider disappears?

Durability is the practical test of user control. Users should retain the same address, assets, and usable signing path if the provider suffers an outage, changes ownership, or shuts down.

Some architectures provide meaningful escape hatches. Privy documents private-key export, as does Turnkey, while Privy also offers cloud recovery for some on-device configurations. Those features can improve recovery and cross-application portability, but they reduce dependency only if users can exercise them without provider cooperation, preserve the same address, and restore a usable signing path before an outage or termination.

Because a wallet can outlast the application that created it, choosing wallet infrastructure is not a one-time integration decision. A wallet may hold funds, credentials, permissions, and transaction history long after the user leaves the product. This persistence turns provider dependency into an ongoing operational risk.

Replacing an analytics tool may disrupt reporting, but replacing a wallet provider can affect access to assets users already own. When account access, user growth, and transaction volume all depend on a third party, the enterprise gives up both margin and part of the customer relationship.

Ownership changes are not hypothetical. Web3Auth's 2025 change-of-ownership notice moved the service under Consensys, and Stripe now identifies Privy as a Stripe company. An acquisition may strengthen a provider, but enterprises still need to know whether contracts, data handling, export rights, and the signing path survive a change in control.

For enterprises, provider dependence creates two immediate operational risks: service continuity and switching costs.

First, the provider becomes part of the application's critical path. A provider outage can prevent users from transacting even when the blockchain remains operational.

Second, switching costs increase over time. The more users and assets tied to a proprietary signing system, the harder it becomes to change providers.

Beyond continuity and portability, enterprises need to ask a third question: whether the provider's economics support growth or quietly tax it.

Are the provider's economics aligned with the business?

Economic alignment means the provider gets paid for the value it adds without turning wallet creation, user growth, or routine signing into recurring tolls. Fees tied to wallet creation, active-user tiers, or signatures can make adoption more expensive without creating corresponding value.

Users may reasonably question whether “self-custody” means anything if access still depends on a single company's infrastructure.

Convenience should not require that tradeoff.

What enterprises should require

Enterprises should convert these three principles into concrete, testable requirements before selecting a provider:

• Can users access the same address and assets without the original application?
• Does every signature depend on the provider's infrastructure?
• What happens during an outage or service termination?
• Do changes in provider pricing affect users who already hold assets or the business's ability to allow new signups?
• Is the wallet compatible with other applications and interfaces?
• What SLA and remedy apply if the signing path fails?
• Who controls recovery data, logs, subprocessors, incident notice, and retention?
• Can the provider demonstrate export, recovery, and migration in a test environment rather than only through a support process?

The answers determine whether the wallet is truly part of the user's digital identity or simply an account inside one company's system.

Together, these requirements preserve user control without forcing the enterprise to rent access to its own users through account, user, or signing fees.

Keys should remain under the user's control if a wallet is to be truly non-custodial. Authentication should rely on established web standards and device security rather than a proprietary signing environment. The wallet should be portable and retain the same address and assets across compatible applications. The service provider should help users interact with the wallet without becoming a permanent condition of access.

This architecture preserves the UX benefits of an embedded wallet without sacrificing self-custody or durability. Users remain in control after the vendor relationship ends, and enterprises keep a direct relationship with them.

Providers can still add value through onboarding, payments, automation, and other financial infrastructure without becoming permanent intermediaries between enterprises and their users. Enterprises should pay for the value a provider creates, not for control over the wallet or continued access to the customer.

How 1Shot answers the three tests

Who owns and controls the wallet after it is created? A durable wallet architecture separates a seamless product experience from permanent provider dependence.

1Shot separates the end-user wallet from the service provider. Users retain control of their keys, addresses, and assets through infrastructure based on existing web standards and device security. The wallet is not inherently tied to a proprietary, cloud-hosted signing platform.

This architecture is built around the WebAuthn PRF extension, which allows a compatible authenticator to produce deterministic cryptographic output used to derive a blockchain signing key inside the user's browser. When passkey synchronization and PRF support are available, users can access the same account across compatible devices without relying on a centralized signing provider.

Developers can integrate that browser-native capability through a customizable embedded-wallet interface without a business account, API key, MAU fee, signing fee, or user limit. See the 1Shot Wallet quickstart to get started.

Applications get a native embedded-wallet experience while users keep an account that remains theirs. The best embedded wallet should disappear into the product during normal use, but it should never disappear with the provider.

Frequently asked questions

How do you test whether an embedded wallet is genuinely non-custodial?

Ask who holds the key, who can move assets, and who approves transactions—and then trace the signing path. MPC labels alone are not enough. A wallet can be described as self-custodial while still requiring a provider to reconstruct credentials, coordinate signatures, or approve access.

Will users retain access if the embedded wallet provider disappears?

Only if the architecture survives the provider. Users should keep the same address, assets, and usable signing path through an outage, ownership change, or shutdown. Export and recovery features help only when users can exercise them without provider cooperation and restore signing before termination.

Are embedded wallet provider economics aligned with enterprise growth?

Not always. Fees tied to wallet creation, active-user tiers, or signatures can tax growth without adding value. Usage caps can block new signups during a surge while existing users keep working—creating a commercial dependency that looks like a product outage.

What should enterprises require before selecting an embedded wallet?

Convert the three tests into concrete requirements: portability across applications, independence of the signing path, outage and termination behavior, pricing impact on existing users and new signups, SLA and remedy, recovery-data control, and demonstrated export or migration in a test environment—not only through support.

How does 1Shot answer the three evaluation tests?

1Shot separates the end-user wallet from the service provider. Keys are derived locally through the WebAuthn PRF extension inside the browser, the wallet stays portable across compatible applications, and developers can integrate without MAU fees, signing fees, or user limits.