GH GambleHub

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): мультисиг/МРС; операції рідкісні, за процедурою з фізичним доступом і журналом.

Технології

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): участь в мультисиг/МРС для warm/cold.
Compliance: holds/EDD/SAR, Travel Rule/KYT рішення.
Security: управління HSM/KMS, ротація ключів, інциденти.


4) Ліміти і guardrails

КонтурЛіміт по транзакціїДенний лімітДоп. правила
HotНизький/середній (X)Низький/середній (Σ X)Velocity за адресою/мережі; тимчасові вікна; 2-фактор для ручних
WarmСередній/високий (Y)Середній/високий (Σ Y)4-очей, whitelist адрес, розклад вікон релізу
ColdДуже високий (Z)За рішенням РадиФізичний кворум, офлайн-підпис, «період охолодження»

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


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

5. 1 Поповнення hot з warm

1. Моніторинг'hot _ balance <threshold'→ заявка на поповнення.
2. КУТ/санкції за адресами призначення → збір батча.
3. Подвійне схвалення (4-очей), підпис (warm мультисиг/МРС).
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) Комплаєнс і контроль

КУТ/санкції: 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, мультисиг/МРС для 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 і мультисиг/МРС, KYT/Travel Rule і RBA, чіткі процедури поповнень і виплат, спостережуваність і плейбуки. Такий контур дає швидкі виплати з hot при мінімальній експозиції активів і стійкість до інцидентів - основу безпечної і прибуткової платіжної інфраструктури iGaming.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.