Реализация Social Recovery для мобильного криптокошелька
Social Recovery позволяет восстановить доступ к кошельку без seed-фразы — через доверенных людей (guardians). Пользователь потерял телефон и не помнит seed — guardians подтверждают смену владельца кошелька. Механика работает на уровне смарт-контракта, мобильное приложение — это UX поверх него.
Как это работает на контрактном уровне
Kандидатный стандарт — EIP-2525 (не финализирован) и реализации в Safe, ZeroDev, Argent. Базовая логика:
- Кошелёк — смарт-аккаунт (ERC-4337 или кастомный).
- При настройке владелец задаёт список guardians (адреса) и threshold (N из M).
- При потере доступа: guardians подтверждают
initiateRecovery(newOwner). - После сбора N подписей и опционального timelock (24–72 часа) —
finalizeRecoveryменяет владельца.
Мобильное приложение реализует: экран настройки guardians, flow инициирования восстановления (для нового устройства), экран подтверждения (для guardians).
Кто такие guardians с технической точки зрения
Варианты разные: другие кошельки (адреса) доверенных людей, email через ZK-Email Guardian (верификация email без раскрытия содержимого), hardware wallet, другой смарт-аккаунт.
Для мобильного приложения самый практичный вариант — guardian-адреса других пользователей приложения. Flow:
- Пользователь A добавляет guardian → вводит адрес или сканирует QR пользователя B.
- Пользователь B получает push и принимает/отклоняет роль guardian.
- Принятие guardian-роли —
addGuardianв контракте кошелька A.
Flow восстановления на новом устройстве
Пользователь устанавливает приложение на новом устройстве. Генерирует новый keypair. Инициирует recovery с новым адресом — отправляет запрос guardians через push/email.
Каждый guardian видит: чей кошелёк восстанавливается, новый адрес, timestamp запроса. Подтверждает через свой кошелёк — approveRecovery UserOperation.
Timelock критически важен: если owner компрометирован, а не потерян, timelock даёт время отменить мошеннический recovery через cancelRecovery с оригинального ключа.
Что сложно в реализации
Состояние вне цепочки. Guardian не всегда онлайн в момент recovery. Нужна централизованная очередь уведомлений или push-механизм. Без этого recovery зависает.
Смена guardians. Если пользователь поссорился с guardian — нужен flow удаления. removeGuardian через owner-ключ. Что если owner-ключ уже потерян? Тогда только через других guardians с повышенным threshold.
Отображение статуса. Пользователь видит: «2 из 3 guardians подтвердили, ждём ещё 1, timelock истечёт через 18 часов». Это polling контракта или event-подписка через WebSocket (eth_subscribe).
Процесс
Аудит существующей контрактной архитектуры (или выбор из готовых: Safe, ZeroDev). Реализация UI настройки guardians, flow инициирования и подтверждения recovery, push-уведомления для guardians, мониторинг состояния recovery.
Сроки — 3–5 дней для интеграции с существующим смарт-аккаунтом, у которого уже есть Social Recovery в контракте. Если контракт ещё не написан — отдельный scope. Стоимость рассчитывается после анализа требований.







