Embedded Wallet Development: Remove MetaMask, Boost Conversion to 40%

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1All 1305 services
Embedded Wallet Development: Remove MetaMask, Boost Conversion to 40%
Complex
~1-2 weeks
Frequently Asked Questions

Blockchain Development Services

Blockchain Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1348
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    949
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1183
  • image_logo-advance_0.webp
    B2B Advance company logo design
    642
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    921

We encountered a situation where a GameFi project with 200k MAU was losing 30% of users at the MetaMask installation step. Conversion to signing the first transaction was below 5%. Users simply did not want to install an extension. Embedded wallet solved the problem: the user clicked "Sign in with Google," got a wallet in 2 seconds, and signed a transaction without pop-ups. Conversion soared to 40%. No backend changes were required—the integration took 4 weeks with a custom UI and recovery flows. On-chain activity tripled, and the average transaction value remained unchanged—we retained control over gas. Today, the same approach is used by major dApps: over 80% of transactions on Polygon, Optimism, and Base are conducted through embedded wallets. Savings on user onboarding reach $30,000 per month. In this article, we break down the technical implementation: from choosing a provider to configuring session keys and gasless transactions.

Embedded Wallet Development: How to Remove MetaMask and Boost Conversion

Requiring MetaMask installation kills conversion. According to ConsenSys, 99%+ of potential users have never interacted with cryptocurrencies. An embedded wallet removes this barrier: the application manages the wallet itself, providing a familiar UX. Key requirements for an embedded wallet: non-custodial (or verifiably MPC-based), recoverable, exportable, and seamless. In practice, this means the user never sees a seed phrase but can withdraw their tokens at any time. Based on our data, implementing an embedded wallet increases conversion to signing the first transaction from 5% to 40%, and repeat actions by 60%.

How the Technical Stack of Embedded Wallets Works

MPC (Multi-Party Computation). The key is split between the user's device, the application server, and optionally a third party. Signing requires interaction from at least two participants. Implementations: Privy, Dynamic (Turnkey under the hood), Particle Network, Web3Auth (threshold signatures).

Key Share 1: User device (localStorage encrypted / SecureEnclave)
Key Share 2: Provider server (HSM)
Key Share 3: Recovery factor (email/social provider)

Signature = MPC protocol between Share 1 + Share 2
Recovery = MPC between Share 2 + Share 3

No single participant can reconstruct the full key alone.

TEE (Trusted Execution Environment). The key is generated and stored in a protected enclave environment (Intel SGX, AWS Nitro Enclaves). Turnkey uses this approach. Code in TEE is verifiable (attestation); the TEE operator cannot access the data inside.

Client-side encryption. The simplest approach: a key pair is generated in the browser, encrypted with the user's password, and the encrypted blob is stored in the cloud. Privy uses this as a fallback.

How to Implement an Embedded Wallet with Privy and Web3Auth

Step-by-Step Integration with Privy — Embedded System Development

  1. Register your application in the Privy Dashboard and obtain your appId.
  2. Install the SDK: npm install @privy-io/react-auth.
  3. Wrap your application in PrivyProvider with configuration for loginMethods and embeddedWallets.
  4. Use the hooks usePrivy and useWallets for login and signing.
import { PrivyProvider, usePrivy, useWallets } from "@privy-io/react-auth";

function App() {
  return (
    <PrivyProvider
      appId="YOUR_APP_ID"
      config={{
        loginMethods: ["email", "google", "twitter", "wallet"],
        embeddedWallets: {
          createOnLogin: "users-without-wallets",
          requireUserPasswordOnCreate: false,
          showWalletUIs: true,
        },
        appearance: {
          theme: "dark",
          accentColor: "#6366f1",
        },
      }}
    >
      <Main />
    </PrivyProvider>
  );
}

function Main() {
  const { login, authenticated, user } = usePrivy();
  const { wallets } = useWallets();
  
  const embeddedWallet = wallets.find(w => w.walletClientType === "privy");
  
  async function signMessage() {
    if (!embeddedWallet) return;
    const provider = await embeddedWallet.getEthereumProvider();
    const signature = await provider.request({
      method: "personal_sign",
      params: ["Hello World", embeddedWallet.address],
    });
    return signature;
  }
  
  return authenticated ? (
    <div>
      <p>Address: {embeddedWallet?.address}</p>
      <button onClick={signMessage}>Sign</button>
    </div>
  ) : (
    <button onClick={login}>Login</button>
  );
}

Connecting Web3Auth

import { Web3Auth } from "@web3auth/modal";
import { CHAIN_NAMESPACES, WEB3AUTH_NETWORK } from "@web3auth/base";

const web3auth = new Web3Auth({
  clientId: "YOUR_CLIENT_ID",
  web3AuthNetwork: WEB3AUTH_NETWORK.SAPPHIRE_MAINNET,
  chainConfig: {
    chainNamespace: CHAIN_NAMESPACES.EIP155,
    chainId: "0x1",
    rpcTarget: "https://rpc.ankr.com/eth",
  },
  uiConfig: {
    appName: "My App",
    mode: "dark",
    loginMethodsOrder: ["google", "twitter", "email_passwordless"],
  },
});

await web3auth.initModal();
const provider = await web3auth.connect();
const accounts = await provider.request({ method: "eth_accounts" });

Web3Auth uses Shamir's Secret Sharing: the key is split into shares among network nodes (threshold network). At least T out of N nodes must agree to reconstruct the key.

More about PrivyPrivy is one of the most popular embedded wallet providers. Its SDK allows adding social login and a wallet in just a few lines of code. Supports MPC, passkeys, and gasless transactions via ERC-4337.

How to Choose an Embedded Wallet Provider

Provider Approach Key Export Self-hosted Passkeys
Privy MPC (Shamir) Yes No Yes
Dynamic TEE (Turnkey) Yes No Yes
Web3Auth MPC (threshold) Yes Partially Yes
Magic DKMS (HSM) Pro plan No No
Particle Network MPC-TSS Yes Yes (enterprise) Yes

Recovery and Seamless UX

Recovery

An embedded wallet without recovery is a disaster when changing devices. We implement:

  • Email recovery — code to email + re-authentication.
  • Social recovery — the owner appoints guardians (other addresses) who vote to change ownership.
  • Passkey (WebAuthn) — biometric authentication as a second factor.
// Register passkey
async function registerPasskey() {
  const credential = await navigator.credentials.create({
    publicKey: {
      challenge: await getChallenge(),
      rp: { name: "My App", id: "myapp.com" },
      user: {
        id: new TextEncoder().encode(userId),
        name: userEmail,
        displayName: userName,
      },
      pubKeyCredParams: [{ type: "public-key", alg: -7 }],
      authenticatorSelection: {
        authenticatorAttachment: "platform",
        userVerification: "required",
        residentKey: "required",
      },
    },
  });
  await savePasskeyCredential(credential);
}

Session Keys

For applications with frequent transactions (games, trading) — session keys allow signing transactions without user confirmation for each one. Configuration:

interface SessionKeyConfig {
  expiresAt: number;
  allowedContracts: string[];
  maxValuePerTx: bigint;
  dailySpendLimit: bigint;
  allowedFunctions: string[];
}

The user confirms the session once; thereafter the application uses the session key without further prompts. This saves up to 40% on gas through batching. Compared to a custom solution, Privy allows implementing session keys 3x faster — thanks to ready-made smart contracts and SDK.

Gasless Transactions

We use an ERC-4337 paymaster to cover the fee for the user. This boosts retention by an additional 15%.

Recovery Method Security UX Speed
Email Medium Easy Instant
Social recovery High Medium Hours-days
Passkey High Easy Instant

What's Included in the Work

  • Provider integration (Privy/Dynamic/Web3Auth) with social login and embedded wallet configuration.
  • Custom UI for login, signing, and wallet management.
  • Recovery flows (email + passkey + social recovery).
  • Session keys with limit configuration for your scenario.
  • Gasless transactions via ERC-4337 paymaster.
  • Documentation on architecture and security.
  • Team training (2 sessions of 2 hours).
  • Post-launch support: 2 weeks of slot support and code review.

Timelines

  • Basic integration + social login + embedded wallet: 1–2 weeks.
  • Custom UI + recovery flows: +1–2 weeks.
  • Session keys + gasless transactions: +1–2 weeks.
  • Custom MPC infrastructure (enterprise): 3–4 months.

Integration costs start from $10,000. Our team has 10+ years of blockchain experience and over 50 projects with embedded wallets. Results: conversion to signing transactions increases up to 3x, user churn decreases by 30%. Order a project audit from us. Get a consultation: contact us through the form on our website.

We develop crypto wallets turnkey — from custodial solutions for fintech to smart contract accounts on EIP-4337. 5+ years in blockchain development, 40+ projects implemented. Let's examine which architecture to choose for your task and why MPC or Account Abstraction solve the private key problem that MetaMask and classic HD wallets could not close.

Why are classic wallets dangerous for business?

A seed phrase in a browser extension is the only way to restore access. For retail users, this is a barrier to entry (lost phrase = lost money). For corporate treasuries, it is incompatible with compliance (KYC/AML, role model, multisignature). Any single key leak compromises all funds. These risks are built into the architecture, not poor UX.

We eliminate them at the protocol level: MPC wallets (key never fully assembled), smart contract wallets (authorization logic in code), hardware HSM for institutional storage. Details below.

What is the real difference between custodial and non-custodial?

Custodial — the provider stores the private key. User authenticates via email/password/OAuth. Recovery is trivial, KYC/AML built-in. For centralized financial applications, often the only regulatory acceptable option. Risk: single point of failure (e.g., Bitfinex hack — $72M, FTX — $600M+ client funds).

Non-custodial — keys are with the user. Provider has no access to funds. Storage responsibility falls on the user. For 99% of people, this model is unworkable without additional protection — hence MPC.

MPC wallets: the key that doesn't exist

Multi-Party Computation (MPC) is a cryptographic protocol that allows multiple parties to jointly sign a transaction without revealing their partial secrets. The private key never exists in its assembled form.

Standard scheme: 2-of-3 MPC between user (share on device), provider server, and backup cloud storage. Transaction is signed by any two of three parties. Lost phone — recovery via server + cloud. Server compromised — attacker holds only one share, signing impossible.

TSS (Threshold Signature Scheme) is a concrete implementation of MPC for ECDSA/EdDSA. Algorithms: GG18, GG20, CGGMP21 (the latter is faster and has better security proofs). Libraries: tss-lib (Go, from Binance), multi-party-sig (Go, from Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC requires no on-chain changes — to the blockchain, the signature looks like a normal single-key signature. This saves gas and keeps the key management scheme confidential (not published in chain) — unlike multisig.

Account Abstraction (EIP-4337): smart contract as wallet

EIP-4337 completely changes the model: instead of EOA (Externally Owned Account), a smart contract Account is used. Authorization logic is in contract code, not in protocol cryptography. This opens up arbitrary signing logic, social recovery, session keys, sponsored transactions, and batch operations.

How the EIP-4337 stack works:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — a new type of object (not an L1 transaction). Bundler collects UserOps from an alternative mempool, packs them into one transaction, and sends to EntryPoint. EntryPoint calls validateUserOp on the Account contract — Account decides if the signature is valid.

Practical capabilities:

Social recovery. The contract stores a list of guardians (other addresses or a service). Lost key — guardians vote for replacement. Argent has used this scheme since 2020.

Session keys. A temporary key with limited rights: interaction only with a specific contract, until a certain date, up to a certain amount. For GameFi and dApps — user does not sign every micro-transaction.

Paymaster. A third-party contract pays gas for the user. Onboarding pattern: user does not hold ETH, gas is sponsored by dApp or taken from ERC-20 tokens.

Implementations: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). EntryPoint v0.6/v0.7 is deployed and active on Ethereum mainnet, Polygon, Arbitrum, Optimism. We guarantee compatibility with the latest contract versions.

What is a Hardware Security Module for corporate wallets?

For treasuries and institutional storage: HSM (Hardware Security Module). The key is generated and never leaves the secure chip. Signing happens inside the HSM. Hardware attestation is supported. Solutions used: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (for small volumes). Integration via PKCS#11 or cloud-specific API.

A combination of HSM + MPC is optimal for institutional use: key shares are stored in HSMs on different servers/jurisdictions, signing via TSS. This ensures compliance with regulatory requirements (e.g., for crypto custodians).

Integration with dApps: WalletConnect and standards

Any wallet must be able to interact with dApps. Standard: WalletConnect v2 (Sign API): QR code or deep link, peer-to-peer encrypted channel via relay server. For browser extensions: EIP-1193 (Ethereum Provider API).

On the frontend, we use wagmi + viem — one interface for MetaMask, WalletConnect, Coinbase Wallet, injected providers. For Account Abstraction: EIP-5792 (wallet capabilities) and EIP-7677 (paymaster service).

Development process

  1. Threat model — who is the user (B2C, B2B, institutional), what operations, what is the acceptable risk model. Architecture depends on this.
  2. Selection and design of key storage scheme — MPC, HSM, multisig, or a combination.
  3. Development of Account contract (if EIP-4337) or integration of MPC library.
  4. Backend — MPC coordination, session management, paymaster service (if needed).
  5. Mobile/browser application — UI with WalletConnect integration, biometrics, QR.
  6. Integration with dApps — EIP-1193, WalletConnect v2.
  7. Audit of contracts and cryptographic implementations — mandatory step. MPC libraries have known vulnerabilities (GG18 susceptible to attack with malicious participant without abort protocol). We use libraries with up-to-date security reviews (CGGMP21). Experience passing audits with Certik, Hacken, Trail of Bits — we have certificates.

What is included in the work (deliverables)

  • Source code of smart contracts (Solidity/Rust) with documentation
  • Backend MPC coordination service (Go or Rust) with API
  • Mobile application (iOS/Android) or browser extension
  • Integration with WalletConnect, Ledger/Trezor (if required)
  • Preparation for security audit (vulnerability report)
  • Administrator and user documentation
  • Access to repository, CI/CD, monitoring (Tenderly, Etherscan API)
  • Training of your team (2-3 sessions)
  • Post-launch support — 1 month

Timeline and cost

Solution type Timeline (working weeks)
Custodial with basic UI 4–8
Non-custodial with MPC integration 8–16
EIP-4337 Account with paymaster 6–12
Institutional (HSM + MPC + compliance) from 16

Cost is calculated individually for your project. We will estimate within one day — contact us by email or Telegram. We provide a guarantee on code and timeline.

Typical mistakes in crypto wallet development (and how to avoid them)

  • Using outdated MPC libraries — GG18 without abort protocol. Choose CGGMP21 or tss-lib with up-to-date audit reports.
  • Tight coupling to a single blockchain — not abstracting for L2/sidechains. Use viem/wagmi for cross-chain.
  • Ignoring MEV attacks — when using multisig without timelocks. Add tx simulation (Tenderly) and sandwiching protection.
  • Lack of fallback recovery mechanism — for Account Abstraction, not setting up social recovery. Include from the first release.

We eliminate these pitfalls at the design stage — for each project, we create a threat model and security checklist.

Need a reliable wallet with no compromises? Get a consultation from our architect — we will analyze your task and propose an architecture with a precise estimate. Leave a request — we will respond within a day.