Mervey Ecosystem Docs

Title: Cloud Backup Recovery (supersedes 2-of-3 SSS/Guard approach) Status: proposed Owner: Artur Date: 17.01.2026

Context

Рассматривались два подхода к recovery:

1. 2-of-3 SSS с guard + server shard + user shard (decision-2026-01-13)
2. Cloud backup с шифрованием на клиенте

Проблема: SSS+guard — избыточная сложность для B2C non-custodial wallet без чёткого целевого пользователя.

Decision

Принимаем подход: Encrypted Cloud Backup в облако пользователя (iCloud/Google Drive).

Отказываемся от SSS/guard для основного флоу. Концентрируем ресурсы на escrow.

Обоснование

1. Анализ индустрии

Сравнение топовых non-custodial кошельков:

Вывод: Ни один успешный кошелёк не использует SSS для массового пользователя. Быть может они глупее нас? Нет — они выбрали простоту.

2. Целевой пользователь (Максат)

Кто: Максат, 29–35, не крипто-гик, пользуется Kaspi/банками. Хочет хранить небольшую/среднюю сумму, переводы, P2P/escrow.

Проблема: "Боюсь потерять доступ при утере телефона. Не хочу разбираться в seed-фразах."

Что нужно: "Потерял телефон → купил новый → восстановил кошелёк". Точка.

Что НЕ нужно: Разбираться в шардах, гвардах, OOB-подтверждениях, процедурах rewrap.

3. Риск-анализ SSS для B2C

Формула риска:

risk = кол-во объектов хранения × кол-во операций × человеческий фактор

Для 2-of-3 SSS:

• 3 объекта (U-shard, S-shard, G-shard)
• N операций жизненного цикла:
  • Генерация, раздача долей, подтверждение принятия
  • Смена телефона, переустановка ОС, миграция
  • Rewrap при смене guard pubkey
  • OOB-подтверждения, таймауты

Оценка (оптимистичная):

• Вероятность потери/порчи одного объекта за 2–3 года: 10–15%
• Вероятность ошибки на одной критической операции: 2–5%

Результат: Даже при небольших рисках долей и операций, для B2C 2-of-3 SSS даёт ≈7% вероятность полной потери за 2–3 года. Для массового продукта это слишком высокий риск.

4. Инженерные проблемы SSS

Фрагментация стандартов:

• Отсутствуют единые константы (SLIP-39, Trezor SSS, другие реализации несовместимы).
• Исторические уязвимости (интерполяция, восстановление с меньшим порогом): https://btcarmory.com/fragmented-backup-vuln/
• Отсутствие единого "API" для SSS долей → lock-in на 5–10 лет.

Сложность реализации:

• Требует команды опытных криптографов.
• Огромная поверхность для багов: rewrap, ротация, guard lifecycle, OOB.
• Бэкенд: оркестрация шардов, метаданные, guard registry, аудит, таймауты.

Вердикт: "Мы лечим кашель бегом под ледяным дождём."

5. Аргумент "для кого?"

Будь мы B2B-провайдером для миллионных сетей — SSS был бы необходимостью. Там другая ответственность, суммы, SLA.

Но мы делаем B2C consumer wallet. SSS+guard — это "технологичность ради технологичности", без целевого пользователя, проблему которого это решает.

Решение: Cloud Backup (Best Practice)

Как работает

Онбординг:

1. "Создать кошелёк"
2. "Сделать резервную копию"
3. Выбрать способ:
   • Cloud backup: "Сохранить зашифрованную копию"
   • Вариант UX: "Придумай пароль восстановления" (только для шифрования; мы его не знаем)
   • И/или: passkey (локальная биометрия + платформенный keychain)
4. Готово: в облаке пользователя лежит зашифрованный бэкап.

Восстановление (новое устройство):

1. "Восстановить кошелёк"
2. Войти в своё облако (iCloud/Google Drive)
3. Ввести пароль восстановления
4. Seed расшифровывается локально → кошелёк восстановлен

Технический флоу

1. Seed создаётся на устройстве, никуда не уходит.
2. При бэкапе: seed шифруется локально паролем восстановления (или passkey).
3. Ciphertext сохраняется в iCloud / Google Drive пользователя (не на наш сервер).
4. При восстановлении: пользователь входит в своё облако, скачивает ciphertext, вводит пароль → seed расшифровывается локально.

Преимущества

Что даёт:

• Мы не храним ничего — ни ключей, ни шифртекстов. Регулятору нечего требовать.
• Пользователь сам отвечает за своё облако и свой пароль. Это честный non-custodial.
• Если забыл пароль — есть seed phrase (всегда). Это fallback, а не дыра.
• Бэкенд минимальный: профиль, escrow-статусы, уведомления. Без криптографической оркестрации.

Ответственность = Некастодиальность

Подход "бэкап в облако юзера" — Best Practice:

• Ответственен за свои решения пользователь.
• Мы не можем восстановить его кошелёк, даже если захотим.
• Это полностью совпадает с концепцией некастодиальности: "твои ключи — твоя ответственность".

Consequences

Positive:

• Простота реализации и поддержки
• Минимальный бэкенд (нет шардов, guard registry, rewrap)
• Регуляторная чистота (не храним ничего)
• Знакомый UX (как у MetaMask/Trust/Phantom)
• Ресурсы команды → на escrow (основной продукт)

Negative:

• Зависимость от облачных провайдеров пользователя (но они надёжнее нашего гипотетического guard-сервиса)
• Нет "wow-фактора" для crypto-гиков (но это не наша аудитория)

Neutral:

• Для enterprise/китов можно добавить SSS позже как опциональный "Advanced tier"

Implementation

MVP:

1. Seed phrase generation + onboarding с проверкой бэкапа
2. Encrypted cloud backup (iCloud/Google Drive)
3. Recovery flow: download ciphertext → decrypt locally
4. Fallback: seed phrase restore (всегда доступен)

Backend scope:

• Никаких шардов, guard registry, rewrap
• Только: профиль, escrow-статусы, уведомления, аудит

Mobile scope:

• Платформенные API для iCloud/Google Drive
• KDF (Argon2/scrypt) для пароля восстановления
• Passkey support (опционально)

Links

• Supersedes: wallet/decisions/decision-2026-01-13-recovery-2of3.md
• Related: escrow/decisions/decision-2026-01-14-kyc-provider-integration.md
• Target users: Notion (см. контекст decision)

Next Steps

• Прототип encrypted cloud backup (iOS/Android)
• UX копирайт для онбординга ("пароль восстановления" vs "seed phrase")
• Интеграция с iCloud/Google Drive API
• Документация для пользователей: "Что делать, если забыл пароль?" → seed phrase
• Отменить/архивировать SSS-related tasks

Вывод: Простота спасёт продукт. SSS — в архив.