Choosing Your Approach

You now understand the four cryptographic architectures underlying embedded wallets: MPC threshold signatures, TEE/HSM key storage, passkey-native smart wallets, and modular signer systems. This lesson provides a framework for choosing between them based on your specific requirements, not marketing claims.

The Decision Framework

Choosing an embedded wallet architecture isn't about finding the "best" option. It's about matching technical properties to user needs. Start with these questions:

Who are your users?

Crypto-native users have existing wallets, understand seed phrases, and may distrust third-party key management. They want optionality, not simplification.

Mainstream users don't know or care about blockchain. They want apps that "just work." Any friction beyond standard app authentication is unacceptable.

Enterprise users need audit trails, compliance documentation, and the ability to integrate with existing identity systems.

What does signing frequency look like?

Rare signing (e.g., monthly subscription, occasional purchase): External wallets via MWA may suffice. Simpler architecture, less vendor dependency.

Frequent signing (e.g., games, social interactions): Embedded wallets dramatically improve UX. Each external wallet prompt is friction.

Continuous signing (e.g., automated trading, bots): Session keys or API-authenticated wallets. Human approval for every action isn't feasible.

What are your recovery requirements?

Acceptable loss (e.g., small balances, gaming assets): Simpler recovery or even no recovery may be fine. Users can create new wallets.

Critical recovery (e.g., primary financial accounts): Multiple recovery paths are essential. Hardware backup, social recovery, or provider-assisted recovery.

Regulated recovery (e.g., financial services): May require custodial or semi-custodial arrangements with documented recovery procedures.

Architecture Comparison

MPC vs. TEE/HSM

Choose MPC when:

• Distributed trust is important

• You want multiple backup options

• Key export may be needed

Choose TEE/HSM when:

• Simpler architecture preferred

• Provider trust is acceptable

• Signing speed matters

MPC vs. Passkey-Native

Choose MPC when:

• Users need multiple authentication methods

• Provider-assisted recovery is important

• Key portability matters

Choose Passkey-Native when:

• Minimum trust assumptions are required

• Users have passkey-capable devices

• Provider infrastructure should not be in the critical path

Single-Signer vs. Modular

Choose single-signer when:

• Your auth method is fixed and known

• Simplicity is paramount

• Security audit scope should be minimal

Choose modular signers when:

• Different users need different auth methods

• Users may upgrade auth over time

• Business requirements may evolve

Provider Selection

Once you've determined your architectural needs, specific providers become relevant.

For Maximum Flexibility

Privy offers the broadest authentication options (email, phone, social, passkey, external wallets) with a polished mobile SDK. Their hybrid model serves both embedded and MWA-connected wallets.

Best for: Apps serving diverse audiences, gradual Web3 adoption, hybrid crypto-native + mainstream users.

For Key Portability

Dynamic provides full key export and Google Drive backup. Users can extract their complete private key if they choose self-custody.

Best for: Users who may want to graduate to self-custody, applications where key ownership matters philosophically.

For Infrastructure Control

Turnkey separates key infrastructure from authentication. You bring your own identity layer; Turnkey provides secure HSMs and signing.

Best for: Teams with existing auth systems, applications requiring custom identity flows, maximum integration flexibility.

For Passkey Purity

LazorKit is passkey-native with no provider in the signing path. The smart wallet is a PDA controlled directly by passkey signatures verified on-chain.

Best for: Maximum decentralization, apps where users have modern devices, when provider trust is unacceptable.

For Multi-Chain

Para (formerly Capsule) provides MPC wallets supporting Solana, EVM chains, and Cosmos from unified authentication.

Best for: Cross-chain applications, portfolios spanning multiple ecosystems, unified multi-chain identity.

For Modular Flexibility

Crossmint offers smart wallets with multiple signer types attachable to the same wallet. Start simple, add security as needed.

Best for: Evolving security requirements, diverse user bases, applications spanning custodial to self-custody spectrum.

For Solana-Native Trust

Phantom Connect creates embedded wallets via OAuth (Google/Apple) with TEE/HSM storage. Users get Phantom's transaction simulation and spam protection built-in.

Best for: Solana-focused apps where users already trust Phantom, consumer applications prioritizing familiar branding.

For Passwordless Simplicity

Magic Link uses email magic links or SMS codes with Fortanix SGX enclaves. The authentication flow is extremely simple for non-technical users.

Best for: Applications where email is the primary user identifier, simple onboarding with minimal decisions.

For Extensive Customization

Web3Auth (MetaMask Embedded) offers the most customizable MPC implementation with dozens of social login providers, custom authentication, and account abstraction integrations.

Best for: Applications requiring specific auth providers, enterprise integrations, account abstraction use cases.

Cost Considerations

Embedded wallets introduce costs beyond traditional wallet connections:

Direct Costs

Per-user fees: Most providers charge monthly active user (MAU) fees after free tiers.

Transaction fees: If using paymasters, you pay gas. This adds up with high transaction volume.

Infrastructure fees: API calls, webhook integrations, premium support.

Indirect Costs

Integration complexity: More sophisticated systems require more development time.

Testing requirements: Real device testing is mandatory. Emulators don't have secure enclaves.

Vendor lock-in: Switching providers requires user migration, which may mean new wallet addresses.

Estimating Your Costs

Consider these variables:

• Expected MAU in year 1, year 2, year 3

• Average transactions per user per month

• Whether you'll sponsor gas (paymaster costs)

• Support tier needed

Free tiers typically cover prototyping and early users. Budget for production pricing from the start.

Security Evaluation

When evaluating providers, look beyond marketing:

Key Questions

Key generation: Is it distributed (DKG) or does one party generate and split?

Threshold scheme: What's the t-of-n? Who holds shares? What happens if the provider is compromised?

Hardware security: Are HSMs used? What certification level? Who operates them?

Audit history: Have security firms audited the cryptographic implementation? When? Are reports public?

Incident response: What's the provider's track record? How do they communicate issues?

Red Flags

• No public security audits

• Vague descriptions of cryptographic architecture

• "Military-grade encryption" marketing without specifics

• No clear incident response process

• Single points of failure in key management

Due Diligence

Request:

• Architecture documentation

• Audit reports (or audit schedule)

• SOC 2 compliance status

• Key ceremony documentation for MPC providers

• Disaster recovery procedures

For applications handling significant value, this due diligence is essential.

Implementation Strategy

Start Simple

Don't implement every provider simultaneously. Pick one that matches your primary use case. Get it working end-to-end before considering alternatives.

Abstract the Interface

Design your application to work against an interface, not a specific provider:

interface EmbeddedWallet {
  connect(): Promise<string>;  // Returns public key
  signTransaction(tx: Transaction): Promise<Transaction>;
  signMessage(msg: Uint8Array): Promise<Uint8Array>;
  disconnect(): Promise<void>;
}

Provider-specific implementations conform to this interface. If you need to switch providers, only the implementation changes.

Plan for Migration

Users may need to move between providers. Design for this:

• Store user IDs in your backend, not just wallet addresses

• Keep wallet addresses in user profiles for reference

• Consider "add new wallet" flows that link new addresses to existing accounts

Test on Real Devices

This cannot be overstated: passkey functionality requires physical devices. Emulators don't have secure enclaves. Budget time for real device testing in your development workflow.

When Not to Use Embedded Wallets

Embedded wallets aren't universally superior. Consider alternatives when:

Users Are Crypto-Native

Experienced users often prefer their existing wallets. They've already solved recovery (seed phrase, hardware wallet). Forcing them into embedded wallets adds friction, not removes it.

Alternative: Support MWA connections alongside embedded options.

Your App Is Read-Heavy

If users mostly view data and rarely sign transactions, embedded wallet complexity may not be justified.

Alternative: Request wallet address for read access, deeplink to external wallets for the occasional signature.

Maximum Decentralization Is Required

MPC providers are trust dependencies. If your application's thesis requires zero third-party involvement, pure self-custody (external wallets) may be the only acceptable answer.

Alternative: Support only external wallet connections via MWA or Wallet Standard.

Budget Is Constrained

Embedded wallet providers charge for users. If your business model can't support per-user fees and you're not ready to sponsor gas, external wallets have zero marginal cost.

Alternative: Start with MWA, add embedded wallets when unit economics support it.

Production Readiness

Before launching with embedded wallets, verify:

Authentication

• All auth methods tested on physical devices (iOS and Android)

• Session persistence across app restarts

• Logout properly clears sensitive data

• Deep links configured for OAuth and passkey flows

Transactions

• Error handling for network failures, user cancellations, insufficient funds

• Transaction simulation before submission

• Clear confirmation feedback

• Fee display (if user pays) or sponsorship configuration (if you pay)

Security

• API keys not embedded in client bundles (or properly restricted)

• All provider communications over HTTPS

• Input validation on addresses and amounts

• Rate limiting on sensitive operations

Recovery

• Recovery flow tested and documented

• Users understand their recovery options

• Support process for locked-out users

Compliance

• Terms of service required before wallet creation

• Privacy policy addresses key management

• Regulatory requirements for your jurisdiction met

Conceptual Summary

Choosing an embedded wallet approach requires matching architecture to requirements:

For mainstream users + maximum flexibility: MPC providers (Privy, Dynamic, Para, Web3Auth) with multiple auth options

For hardware-backed simplicity: TEE providers (Phantom Connect, Magic Link, Turnkey) with isolated key storage

For minimum trust + maximum decentralization: Passkey-native (LazorKit) with hardware-bound keys

For evolving requirements + diverse users: Modular signers (Crossmint) with upgradeable security

For infrastructure control: Turnkey with bring-your-own authentication

For multi-chain applications: Para with unified cross-chain identity

The right choice depends on:

• Your users' technical sophistication

• Signing frequency in your application

• Recovery requirements

• Trust assumptions you're willing to make

• Budget for per-user costs

Embedded wallets transform onboarding by removing seed phrases and external wallet dependencies. But they introduce provider relationships, new cost structures, and architectural decisions that affect your application's trust model.

Choose based on understanding, not marketing. The cryptographic foundations you've learned in this course give you the vocabulary to ask the right questions and evaluate answers critically.

Build something. Ship it to users. Learn what your specific audience actually needs. The best architecture is the one that serves your users while meeting your security and business requirements.