Hot/Cold кошельки и политика доступа

1) Зачем разделять на Hot/Warm/Cold

• Hot — оперативные депозиты/выводы (T0/T+1), минимальные задержки, ограниченный баланс.
• Warm — промежуточные пулы для пополнений hot и крупных регулярных выплат.
• Cold — долгосрочное хранение (резервы/казначейство), максимально изолировано от сети.

Результат: меньше операционных рисков и предсказуемые SLA при контролируемой экспозиции.

2) Референс-архитектура хранения

Слои и их роль

Hot (онлайн, автоматизирован): подписывает мелкие/средние выплаты в пределах дневных лимитов. Защита — HSM/KMS, policy engine, алерты.
Warm (частично онлайн/аппаратный модуль): батч-выплаты, пополнение hot, повышенные лимиты, ручное подтверждение.
Cold (офлайн/air-gapped): мультисиг/MPC; операции редкие, по процедуре с физическим доступом и журналом.

Технологии

HSM/KMS для hot/warm ключей и токенов;

Мультисиг m-of-n или MPC для warm/cold;

Policy engine (лимиты, 4-глаз, списки разрешенных адресов, окна времени);

Private relay/защита от MEV для крупных транзакций.

3) Политика доступа (Access Policy)

3.1 Принципы

Наименьшие привилегии (PoLP): доступ ровно по роли и зоне (hot/warm/cold).
Разделение обязанностей (SoD): разные люди/сервисы инициируют, утверждают, подписывают, релизят.
4-глаз: минимум два независимых одобрения на критичные операции (лимиты, адресные списки, warm→hot).
Изоляция контуров: prod ≠ stage; сетевые ACL, отдельные учетные данные.

3.2 Роли

Operator (Payments): создает выплаты/батчи в рамках лимитов.
Approver (Treasury/Risk): одобрение свыше порогов, whitelist/hold.
Custodian (Key Owner): участие в мультисиг/MPC для warm/cold.
Compliance: holds/EDD/SAR, Travel Rule/KYT решения.
Security: управление HSM/KMS, ротация ключей, инциденты.

4) Лимиты и guardrails

Whitelist/denylist: адресная книга с TTL, KYT-порогами и обязательным подтверждением владения (для unhosted).

5) Операционные потоки

5.1 Пополнение hot из warm

1. Мониторинг `hot_balance < threshold` → заявка на пополнение.
2. KYT/санкции по адресам назначения → сбор батча.
3. Двойное одобрение (4-глаз), подпись (warm мультисиг/MPC).
4. Перевод и запись в лейджер; алерт об изменении лимитов.

5.2 Выплаты из hot

Автоматически в пределах per-tx и per-day лимитов.
Для превышения — эскалация в warm: батч/частичный релиз + проверка RBA (SoF/KYT/Travel Rule).

5.3 Ребаланс warm↔cold

Периодический (еженедельно/по порогу) или по решению казначейства; офлайн-подпись, два независимых канала подтверждения, журнал.

6) Ключевая безопасность

Генерация и хранение: только на HSM/air-gapped; отказ от экспорта приватных ключей.
Ротация: плановая (N месяцев), внеплановая при инциденте; документированные процедуры отзыва.
Backup/Shard-management: шифрованные шары (MPC) в разных локациях/юрисдикциях; периодические тесты восстановления.
Сетевой периметр: IP allow-list, mTLS, подписанные вебхуки, мониторинг аномалий.
Change-control: RFC на изменение политик/лимитов, журнал изменений (immutable).

7) Комплаенс и контроль

KYT/санкции: pre-check на вход/выход; разные профили риска по сетям.
Travel Rule: для VASP↔VASP — IVMS101, реплики сообщений и результаты доставки.
RBA: лимиты/подтверждения зависят от сегмента риска и суммы.
Аудит: полный след: кто/когда/что инициировал/одобрил/подписал; версия правил в момент операции.
GDPR/PII: минимизация, токенизация ID, раздельное хранение от платежных PAN.

8) Наблюдаемость, логи и реконсиляция

Лейджер: мэппинг `invoice/withdrawal ↔ txid ↔ wallet(subaccount)` по сети/активу.
Реконсиляция T+0/T+1: суммы, комиссии, курс (источник цен, timestamp), незакрытые остатки.
Мониторинг: баланс hot/warm/cold, скорость подтверждений, fee, аномальные выплаты, переключения на резервные сети.
Алерты: превышение лимитов/velocity, новые адреса вне whitelist, расхождения сверки.

9) Плейбуки инцидентов

Утечка/компрометация hot: немедленное снятие лимитов до нуля, перевод остатков в warm/cold, ротация ключей, расследование, отчет регуляторам/партнерам.
Аномалии выплат: freeze батча, KYT re-check, SoF запрос, частичный релиз безопасной части.
Деградация сети/fee-шторма: auto switch-over на резервную сеть/метод, обновление ETA в UI.
Недоступность провайдера custody/RPC: фейловер, ручной релиз критичных выплат через warm, пост-инцидентный разбор.
Несанкционированная смена политик: автоматический rollback, уведомление SecOps/Compliance, аудиторский отчет.

10) Метрики и OKR

Безопасность/комплаенс

Доля активов в cold/warm/hot (целевые диапазоны), число нарушений лимитов.
KYT reject %, санкционные хиты, SAR-conversion (если применимо).
Количество изменений политик/месяц, успешные/отклоненные запросы на повышение лимитов.

Надежность/операции

Time-to-Payout p50/p95 для hot/warm маршрутов.
Частота пополнений hot, средний размер пополнения.
Процент авто-выплат vs ручных, инциденты/квартал.

Экономика/UX

Cost per Approved (all-in по сети/активу), fee-процент от суммы.
Ошибки сети/мемо/тега, количество partial release, тикеты по задержкам.

11) Анти-паттерны

Переполненные hot кошельки без жестких дневных капов.
Один кастодиальный провайдер/одна сеть без резерва → SPOF.
Отсутствие 4-глаз и SoD на операции warm/cold.
Ключи без HSM/KMS, отсутствие регулярной ротации/тестов восстановления.
Нет whitelist/TTL и KYT перед выводом — повышенный риск.
Изменение лимитов «по мессенджеру» без RFC/аудита.
Отсутствие идемпотентности и анти-дублей при ретраях — двойные списания.

12) Чек-лист внедрения (коротко)

• Матрица слоев: hot/warm/cold с лимитами per-tx/per-day и долей активов.
• Роли и SoD: Operator/Approver/Custodian/Compliance/Security, 4-глаз.
• HSM/KMS для hot/warm, мультисиг/MPC для warm/cold, офлайн-подпись.
• Whitelist/denylist адресов с TTL, KYT-порогами, подтверждением владения.
• Процессы: пополнение hot, батч-выплаты из warm, ребаланс в cold.
• Наблюдаемость: лейджер, реконсиляция T+0/T+1, алерты превышений.
• Плейбуки инцидентов: компрометация, деградации сети, недоступность провайдера.
• Travel Rule/IVMS101, RBA-политики, аудит изменений.
• Идемпотентность, анти-дубли, backoff+jitter; подписанные вебхуки.
• Регулярные тесты восстановления ключей и учений по инцидентам.

13) Резюме

Правильная стратегия hot/warm/cold — это не просто «три кошелька», а режим управления рисками и доступом: лимиты и 4-глаз, HSM/KMS и мультисиг/MPC, KYT/Travel Rule и RBA, четкие процедуры пополнений и выплат, наблюдаемость и плейбуки. Такой контур дает быстрые выплаты из hot при минимальной экспозиции активов и устойчивость к инцидентам — основу безопасной и прибыльной платежной инфраструктуры iGaming.