Реалізація Social Recovery для мобільного криптокошелька
Social Recovery дозволяє відновити доступ до кошелька без seed-фрази — через доверених людей (guardians). Користувач втратив телефон та не пам'ятає seed — guardians підтверджують зміну власника кошелька. Механіка працює на рівні смарт-контракту, мобільний додаток — це UX поверх нього.
Як це працює на рівні контракту
Кандидатний стандарт — 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 istechе через 18 годин". Це polling контракту або event-підписка через WebSocket (eth_subscribe).
Процес
Аудит існуючої контрактної архітектури (або вибір з готових: Safe, ZeroDev). Реалізація UI налаштування guardians, flow інціювання та підтвердження recovery, push-сповіщення для guardians, моніторинг стану recovery.
Сроки — 3–5 днів для інтеграції з існуючим смарт-аккаунтом, у якого вже є Social Recovery в контракті. Якщо контракт ще не написаний — окремий scope. Вартість рассчитується після аналізу вимог.







