Разработка кошелька с social recovery и ERC-4337

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

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

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

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

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

Мы сталкиваемся с потерянными seed-фразами каждый день: клиент записал 12 слов на бумажке, положил в ящик стола — и забыл. По оценкам Chainalysis, 20–25% всех биткоинов безвозвратно потеряны именно так. Наши инженеры разрабатывают кошельки с social recovery — механизмом, который спасает активы при потере ключа. Закажите такую реализацию под ключ: мы спроектируем контракт, настроим guardian-ов, проведём аудит. В среднем проект занимает от 4 до 12 недель в зависимости от сложности.

Social recovery — это идея Виталика Бутерина, реализованная в Argent и Loopring, а теперь нативно доступная через Account Abstraction (ERC-4337). Кошелёк — смарт-контракт с двумя режимами: owner key для повседневных транзакций и guardian set для восстановления.

Как работает social recovery на уровне контракта

Guardian set и threshold recovery

Guardians — адреса, которые коллективно могут сменить owner key. Владелец назначает N guardian-ов и порог threshold (обычно 3 из 5). Guardians не трогают активы — только вызов initiateRecovery и finalizeRecovery. Это ключевое отличие: скомпрометированный guardian не украдёт средства, а лишь запустит смену ключа.

contract SocialRecoveryWallet {
    address public owner;
    mapping(address => bool) public isGuardian;
    uint256 public guardianCount;
    uint256 public threshold;
    uint256 public recoveryDelay; // timelock в секундах

    struct RecoveryRequest {
        address proposedOwner;
        uint256 approvalCount;
        uint256 initiatedAt;
        mapping(address => bool) approvals;
    }

    RecoveryRequest public pendingRecovery;

    function initiateRecovery(address _proposedOwner) external onlyGuardian {
        require(pendingRecovery.initiatedAt == 0, "Recovery already pending");
        pendingRecovery.proposedOwner = _proposedOwner;
        pendingRecovery.initiatedAt = block.timestamp;
        pendingRecovery.approvalCount = 1;
        pendingRecovery.approvals[msg.sender] = true;
    }

    function approveRecovery() external onlyGuardian {
        require(pendingRecovery.initiatedAt != 0, "No pending recovery");
        require(!pendingRecovery.approvals[msg.sender], "Already approved");
        pendingRecovery.approvals[msg.sender] = true;
        pendingRecovery.approvalCount++;
    }

    function finalizeRecovery() external {
        require(pendingRecovery.approvalCount >= threshold, "Insufficient approvals");
        require(
            block.timestamp >= pendingRecovery.initiatedAt + recoveryDelay,
            "Timelock not expired"
        );
        owner = pendingRecovery.proposedOwner;
        delete pendingRecovery;
    }
}

Почему timelock критичен?

recoveryDelay — обязательный параметр. Без него: threshold скомпрометирован → мгновенная потеря контроля. С timelock (Argent использует 24-48 часов, для institutional — 72+ часа) у владельца есть окно для отмены. На практике это снижает риск потери активов в 3 раза по сравнению с мгновенным восстановлением.

Guardian management с задержкой

Добавление и удаление guardian-ов тоже через timelock — иначе owner может заменить всех guardian-ов перед продажей. Используем паттерн pendingGuardianAdd:

mapping(address => uint256) public pendingGuardianAdditions;
uint256 public guardianAddDelay;

function scheduleAddGuardian(address _guardian) external onlyOwner {
    pendingGuardianAdditions[_guardian] = block.timestamp + guardianAddDelay;
}

function confirmAddGuardian(address _guardian) external {
    require(pendingGuardianAdditions[_guardian] != 0, "Not scheduled");
    require(block.timestamp >= pendingGuardianAdditions[_guardian], "Timelock active");
    isGuardian[_guardian] = true;
    guardianCount++;
    delete pendingGuardianAdditions[_guardian];
}

Как выбрать guardian-ов?

Выбор guardian-ов — социально-архитектурная задача. Варианты:

  • Доверенные лица: 3 близких человека, каждый хранит ключ guardian в своём кошельке. Простейшая схема.
  • Hardware wallet + телефон + guardian сервис: резервный Ledger + телефон + сервис (Argent или кастомный). При потере двух из трёх — recovery.
  • Multisig как guardian: Safe{Wallet} в роли guardian. Для recovery нужен quorum в Safe. Подходит корпорациям.
  • Smart contract guardian: timelock контракт организации, recovery через governance голосование.
Тип guardian Удобство Децентрализация Подходит для
Trusted persons (3-of-5) Высокое Высокая Розничные пользователи
Hardware + mobile + service Среднее Средняя Power users
Corporate multisig Низкое Высокая Корпоративные
DAO governance Очень низкое Максимальная Protocol-owned

ERC-4337 и social recovery: газ без газа

Account Abstraction (ERC-4337) делает social recovery нативным паттерном. Кошелёк — уже смарт-контракт, не нужно конвертировать EOA. UserOperation позволяет:

  • Gasless recovery: Paymaster оплачивает gas за guardian-ов и пользователя.
  • Batched approvals: несколько guardian-ов в одном bundled batch.
  • Social login как guardian: key хранится в passkey/WebAuthn на телефоне.

Реализация через Kernel (ZeroDev) или Biconomy Smart Account v2: оба имеют plugin-систему, где social recovery — модуль.

ERC-4337 recovery flow

// Guardian подписывает UserOperation для approveRecovery
const userOp = await guardianSmartAccount.buildUserOperation({
    target: walletAddress,
    data: wallet.interface.encodeFunctionData('approveRecovery', [])
});

// Paymaster спонсирует gas
const sponsoredOp = await paymasterClient.sponsorUserOperation(userOp);
await bundlerClient.sendUserOperation(sponsoredOp);

Это меняет UX: guardian-у не нужен ETH для gas, он просто подписывает approval на телефоне.

Защита от атак

Griefing через spam recovery

Любой guardian может инициировать recovery и заблокировать кошелёк. Решение: recovery не блокирует транзакции owner-а, либо инициировать могут только несколько guardian-ов коллективно.

Social engineering

Злоумышленник убеждает guardian-ов, что пользователь потерял ключ. Защита: timelock + нотификации (email/push/telegram bot) + out-of-band верификация.

Front-running finalizeRecovery

Атакующий видит finalizeRecovery в мемпуле и подменяет адрес. Защита: commit-reveal или private mempool.

Off-chain guardian coordination

Guardian-ам нужна координация без on-chain газа. Варианты:

  • Centralized guardian service (Argent) — удобно, но центральная точка.
  • IPFS + signature aggregation — guardian-ы публикуют подписи в IPFS, aggregator отправляет batchApprove.
  • E2E encrypted messaging — через Signal/Matrix, low-tech, max независимость.

Наш гибрид: notification сервер уведомляет guardian-ов, они одобряют через dApp, aggregator батчит.

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

Мы предоставляем полный комплект: документация архитектуры, исходники смарт-контрактов (Solidity), frontend (wagmi+viem), конфигурации для Foundry, инструкцию по деплою, обучающий вебинар для команды и поддержку в течение месяца после запуска. Оценим ваш проект бесплатно — напишите нам.

Процесс работы

  1. Аналитика (3-5 дней). Целевая аудитория, выбор guardian-ов, нужна ли AA, gasless, multichain.
  2. Проектирование контракта (3-5 дней). Guardian management, timelock параметры, рековери флоу, интеграция с ERC-4337.
  3. Разработка (4-8 недель). Core контракт → guardian management → recovery flow → frontend → guardian coordination UI.
  4. Аудит. Обязателен: контракт управляет средствами. Проверяем reentrancy, timelock, griefing vectors.
  5. Тестирование. Fork-тесты mainnet, симуляция полного recovery flow.
Этап Длительность (дней) Результат
Аналитика 3-5 Техническое задание
Проектирование 3-5 Архитектура контракта
Разработка 28-56 Исходники, frontend
Аудит 7-14 Отчёт аудита
Тестирование 5-7 Fork-тесты

Стек и инструменты

Solidity 0.8.x + OpenZeppelin, Foundry, ERC-4337 SDK, wagmi + viem, WalletConnect v2. Используем Tenderly для мониторинга.

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

Базовый кошелёк без AA — 3-5 недель. С ERC-4337, gasless recovery и guardian UI — 8-12 недель. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки.

Мы выполнили 20+ проектов в области Social Recovery за 5 лет работы. Наши инженеры — авторы статей по ERC-4337 и участники разработки open-source решений.

Мы разрабатываем криптокошельки под ключ — от 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.

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