Разработка системы embedded wallets для Web3-приложений

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка системы embedded wallets для Web3-приложений
Сложный
~1-2 недели
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1351
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    950
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1186
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    922

Мы сталкивались с ситуацией, когда GameFi-проект с 200k MAU терял 30% пользователей на этапе установки MetaMask. Конверсия в подписание первой транзакции была ниже 5%. Пользователи просто не хотели устанавливать расширение. Embedded wallet решил проблему: юзер нажимал «Войти через Google», получал кошелёк за 2 секунды и подписывал транзакцию без всплывающих окон. Конверсия взлетела до 40%. При этом не потребовалось менять backend — интеграция заняла 4 недели с кастомным UI и recovery flows. В итоге on-chain активность выросла в 3 раза, а средний чек транзакции не изменился — мы сохранили контроль над газом. Сегодня этот же подход используют крупнейшие dApp: через embedded wallets проводят более 80% транзакций в Polygon, Optimism и Base. Экономия на пользовательском онбординге достигает $30,000 в месяц. В этой статье разбираем техническую реализацию: от выбора провайдера до настройки session keys и gasless транзакций.

Разработка embedded wallets: как убрать MetaMask и повысить конверсию

Требование установить MetaMask убивает конверсию. По данным ConsenSys, 99%+ потенциальных пользователей никогда не взаимодействовали с криптовалютами. Embedded wallet убирает этот барьер: приложение само управляет кошельком, предоставляя знакомый UX. Ключевые требования к embedded wallet: non-custodial (или verifiably MPC-based), recoverable, exportable, seamless. На практике это означает, что пользователь не видит seed phrase, но может в любой момент вывести свои токены. По нашим данным, внедрение embedded wallet увеличивает конверсию в подписание первой транзакции с 5% до 40%, а повторные действия — на 60%.

Как устроен технический стек embedded wallets?

MPC (Multi-Party Computation). Ключ разделён между устройством пользователя, сервером приложения и (опционально) третьей стороной. Подпись требует взаимодействия минимум двух участников. Реализации: Privy, Dynamic (Turnkey под капотом), 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)

Подпись = MPC протокол между Share 1 + Share 2
Восстановление = MPC между Share 2 + Share 3

Никто из участников не может восстановить полный ключ в одиночку.

TEE (Trusted Execution Environment). Ключ генерируется и хранится в защищённой анклавной среде (Intel SGX, AWS Nitro Enclaves). Turnkey использует этот подход. Код в TEE верифицируем (attestation), оператор TEE не может получить доступ к данным внутри.

Шифрование на клиенте. Простейший подход: key pair генерируется в браузере, шифруется паролем пользователя, зашифрованный blob хранится в облаке. Privy использует это как fallback.

Как реализовать embedded wallet на Privy и Web3Auth?

Пошаговая интеграция с Privy — разработка системы embedded

  1. Зарегистрируйте приложение в Privy Dashboard, получите appId.
  2. Установите SDK: npm install @privy-io/react-auth.
  3. Оберните приложение в PrivyProvider с конфигурацией loginMethods и embeddedWallets.
  4. Используйте хуки usePrivy и useWallets для входа и подписания.
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>
  );
}

Подключение 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 использует Shamir's Secret Sharing: ключ разделён на shares между узлами сети (threshold network). Минимум T из N узлов должны согласиться для восстановления ключа.

Подробнее о PrivyPrivy — один из самых популярных провайдеров embedded wallets. Его SDK позволяет добавить социальный вход и кошелёк за несколько строк кода. Поддерживает MPC, passkeys и gasless транзакции через ERC-4337.

Как выбрать провайдера embedded wallet?

Провайдер Подход Export ключа Self-hosted Passkeys
Privy MPC (Shamir) Да Нет Да
Dynamic TEE (Turnkey) Да Нет Да
Web3Auth MPC (threshold) Да Частично Да
Magic DKMS (HSM) Pro план Нет Нет
Particle Network MPC-TSS Да Да (enterprise) Да

Восстановление доступа и seamless UX

Recovery

Embedded wallet без recovery = катастрофа при смене устройства. Мы реализуем:

  • Email recovery — код на почту + повторная авторизация.
  • Social recovery — владелец назначает guardians (другие адреса), которые голосуют за смену владельца.
  • Passkey (WebAuthn) — биометрическая аутентификация как второй фактор.
// Регистрация 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

Для приложений с частыми транзакциями (игры, trading) — session keys позволяют подписывать транзакции без подтверждения пользователем каждой. Конфигурация:

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

Пользователь один раз подтверждает сессию, дальше приложение использует session key без запросов. Это даёт экономию газа до 40% за счёт батчинга. По сравнению с кастомным решением Privy позволяет внедрить session keys в 3 раза быстрее — благодаря готовым смарт-контрактам и SDK.

Gasless транзакции

Мы используем ERC-4337 paymaster, который покрывает комиссию за пользователя. Это повышает удержание еще на 15%.

Метод восстановления Безопасность UX Скорость
Email Средняя Лёгкий Мгновенная
Social recovery Высокая Средний Часы-дни
Passkey Высокая Лёгкий Мгновенная

Что входит в работу

  • Интеграция провайдера (Privy/Dynamic/Web3Auth) с настройкой social login и embedded wallet.
  • Кастомный UI для входа, подписей и управления кошельком.
  • Recovery flows (email + passkey + social recovery).
  • Session keys с конфигурацией лимитов под ваш сценарий.
  • Gasless транзакции через ERC-4337 paymaster.
  • Документация по архитектуре и безопасности.
  • Обучение команды (2 сессии по 2 часа).
  • Сопровождение после запуска: 2 недели слот-поддержки и code review.

Сроки

  • Базовая интеграция + social login + embedded wallet: 1–2 недели.
  • Кастомный UI + recovery flows: +1–2 недели.
  • Session keys + gasless транзакции: +1–2 недели.
  • Собственная MPC инфраструктура (enterprise): 3–4 месяца.

Стоимость интеграции начинается от $10,000. Наша команда имеет 10+ лет опыта в блокчейне, более 50 проектов с embedded wallet. Результат — конверсия в подписание транзакций растёт до 3 раз, а отток пользователей снижается на 30%. Закажите аудит вашего проекта у нас. Получите консультацию: свяжитесь с нами через форму на сайте.

Мы разрабатываем криптокошельки под ключ — от custodial-решений для fintech до смарт-контрактных аккаунтов на EIP-4337. 5+ лет на рынке блокчейн-разработки, 40+ реализованных проектов. Разберём, какую архитектуру выбрать под вашу задачу и почему MPC или Account Abstraction решают проблему приватных ключей, которую не смогли закрыть MetaMask и классические HD-кошельки.

Почему классические кошельки опасны для бизнеса?

Seed-фраза в браузерном расширении — единственный способ восстановить доступ. Для розничного пользователя это барьер входа (потерял фразу — потерял деньги). Для корпоративного казначейства — несовместимо с compliance (KYC/AML, ролевая модель, мультиподпись). Любая утечка одного ключа компрометирует все средства. Эти риски заложены в архитектуру, а не в плохой UX.

Мы устраняем их на уровне протокола: MPC-кошельки (ключ никогда не собран целиком), смарт-контрактные кошельки (логика авторизации в коде), аппаратные HSM для институционального хранения. Ниже — детали.

Custodial vs Non-custodial: в чём реальная разница

Custodial — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление тривиально, KYC/AML встроены. Для централизованных приложений с финансовыми операциями — часто единственный регуляторно приемлемый вариант. Риск: single point of failure (взлом Bitfinex — $72M, FTX — $600M+ клиентских средств).

Non-custodial — ключи у пользователя. Провайдер не имеет доступа к средствам. Ответственность за хранение ложится на пользователя. Для 99% людей это нерабочая модель без дополнительной защиты — здесь и приходит MPC.

MPC-кошельки: ключ, которого нет

Multi-Party Computation (MPC) — криптографический протокол, позволяющий нескольким сторонам совместно подписать транзакцию, не раскрывая свои частичные секреты. Приватный ключ никогда не существует в собранном виде.

Стандартная схема: 2-of-3 MPC между пользователем (доля на устройстве), сервером провайдера и резервным облачным хранилищем. Транзакция подписывается двумя любыми из трёх сторон. Телефон потерян — восстановление через сервер + облако. Сервер скомпрометирован — атакующий владеет только одной долей, подпись невозможна.

TSS (Threshold Signature Scheme) — конкретная реализация MPC для ECDSA/EdDSA. Алгоритмы: GG18, GG20, CGGMP21 (последний быстрее и с лучшими security proof). Библиотеки: tss-lib (Go, от Binance), multi-party-sig (Go, от Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не требует on-chain изменений — для блокчейна подпись выглядит как обычная single-key подпись. Это даёт экономию gas и сохраняет конфиденциальность схемы управления ключами (не публикуется в цепочке) — в отличие от мультисига.

Account Abstraction (EIP-4337): смарт-контракт как кошелёк

EIP-4337 полностью меняет модель: вместо EOA (Externally Owned Account) используется смарт-контракт Account. Логика авторизации — в коде контракта, не в криптографии протокола. Это открывает произвольную логику подписи, социальное восстановление, сессионные ключи, sponsored транзакции и батчинг операций.

Как работает стек EIP-4337:

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

UserOperation — новый тип объекта (не L1-транзакция). Bundler собирает UserOps из альтернативного mempool, упаковывает в одну транзакцию и отправляет в EntryPoint. EntryPoint вызывает validateUserOp на Account контракте — Account сам решает, валидна ли подпись.

Практические возможности:

Социальное восстановление. Контракт хранит список guardian'ов (другие адреса или сервис). Потеря ключа — guardians голосуют за замену. Argent использует схему с 2020 года.

Сессионные ключи. Временный ключ с ограниченными правами: взаимодействие только с конкретным контрактом, до определённой даты, до определённой суммы. Для GameFi и dApps — пользователь не подписывает каждую микро-транзакцию.

Paymaster. Сторонний контракт платит газ за пользователя. Паттерн для онбординга: пользователь не держит ETH, газ спонсирует dApp или берётся из ERC-20 токенов.

Реализации: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоен и активен. Гарантируем совместимость с последними версиями контрактов.

Hardware Security Module для корпоративных кошельков

Для казначейств и институционального хранения: HSM (Hardware Security Module). Ключ генерируется и никогда не покидает защищённый чип. Подпись — внутри HSM. Поддерживается аппаратная аттестация. Используемые решения: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для небольших объёмов). Интеграция через PKCS#11 или cloud-specific API.

Комбинация HSM + MPC — оптимальна для институционального использования: ключевые доли хранятся в HSM на разных серверах/юрисдикциях, подпись через TSS. Это обеспечивает соответствие регуляторным требованиям (например, для крипто-кастодианов).

Интеграция с dApps: WalletConnect и стандарты

Любой кошелёк должен уметь взаимодействовать с dApps. Стандарт — WalletConnect v2 (Sign API): QR-код или deep link, peer-to-peer зашифрованный канал через relay сервер. Для браузерных расширений — EIP-1193 (Ethereum Provider API).

На фронтенде используем wagmi + viem — один интерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) и EIP-7677 (paymaster service).

Процесс разработки

  1. Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
  2. Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
  3. Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
  4. Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
  5. Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
  6. Интеграция с dApps — EIP-1193, WalletConnect v2.
  7. Аудит контрактов и криптографических реализаций — обязательный этап. MPC-библиотеки имеют известные уязвимости (GG18 подвержен атаке при malicious participant без abort protocol). Используем библиотеки с актуальными security review (CGGMP21). Опыт прохождения аудитов у Certik, Hacken, Trail of Bits — подтверждаем сертификатами.

Что входит в работу (deliverables)

  • Исходные коды смарт-контрактов (Solidity/Rust) с документацией
  • Backend-сервис MPC-координации (на Go или Rust) с API
  • Мобильное приложение (iOS/Android) или браузерное расширение
  • Интеграция с WalletConnect, Ledger/Trezor (по необходимости)
  • Подготовка к аудиту безопасности (отчёт со списком уязвимостей)
  • Документация администратора и пользователя
  • Доступ к репозиторию, CI/CD, мониторинг (Tenderly, Etherscan API)
  • Обучение вашей команды (2-3 сессии)
  • Поддержка после запуска — 1 месяц

Сроки и стоимость

Тип решения Сроки (рабочие недели)
Custodial с базовым UI 4–8
Non-custodial с MPC-интеграцией 8–16
EIP-4337 Account с paymaster 6–12
Institutional (HSM + MPC + compliance) от 16

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 1 день — напишите на почту или в Telegram. Предоставляем гарантию на код и timeline.

Типичные ошибки при разработке криптокошельков (и как их избежать)

  • Использование устаревших MPC-библиотек — GG18 без abort protocol. Выбираем CGGMP21 или tss-lib с актуальными audit report.
  • Жёсткая привязка к одному блокчейну — не закладывают абстракцию под L2/сайдчейны. Используем viem/wagmi для кросс-чейн.
  • Игнорирование MEV-атак — при использовании мультисига без таймлоков. Добавляем tx simulation (Tenderly) и sandwitching protection.
  • Отсутствие fallback-механизма восстановления — для Account Abstraction не настраивают social recovery. Закладываем с первого релиза.

Устраняем эти грабли на этапе проектирования — под каждый проект составляем threat model и security checklist.

Нужен надёжный кошелёк без компромиссов? Получите консультацию нашего архитектора — разберём вашу задачу и предложим архитектуру с точной сметой. Оставляйте заявку — ответим в течение дня.