Ротація адрес і приватність

1) Навіщо ротація адрес в iGaming

Ротація (регулярна зміна адрес при депозитах/висновках) зменшує зв'язність ончейн-графа, захищає комерційну таємницю (обороти, пул ліквідності), знижує ризики таргетованих атак і «адресної репутації», а також покращує якість KYT (менше «брудних» успадкованих зв'язків). Важлива відмінність: приватність ≠ анонімність - ротація робиться в рамках RBA/KYT/Travel Rule і не заважає звітності.

• мінімізувати адресу-reuse і склеювання транзакцій по графу,
• підвищити стійкість до dox/фішингу,
• зберегти відповідність AML/санкціям і прозорий облік.

2) Політика ротації: де і коли змінювати адресу

Депозити

Адреса на інвойс: нова унікальна адреса на кожен інвойс/спробу оплати.
TTL адреси: час життя рахунку (наприклад, 60-120 хв) з можливістю продовження.
Мережі з тегами (XRP/XLM/TON): ротація Destination Tag/Memo замість нової основної адреси; сувора валідація тегу.

Висновки

Використовувати whitelist адрес клієнта (підтвердження володіння + KYT).
Ротація адрес джерела (оператора) згідно з лімітами експозиції (наприклад, N транзакцій або сума ≥ X → зміна адреси/гаманця).

Внутрішні переміщення

Для внутрішніх пулювань - виділені «службові» адреси з регулярною ротацією і зрозумілим лейблінгом в лейджері.

3) Архітектура деривації та управління адресами

3. 1 HD-гаманці (UTXO-мережі: BTC та ін.)

BIP32/BIP44/BIP84: ієрархічна деривація зі зрозумілою структурою шляхів.
Gap limit: настроюється (наприклад, 50-100), щоб не втратити незараховані депозити.
Change-адреси: завжди окремі, теж ротуються.
UTXO-гігієна: періодичне об'єднання дрібних UTXO на «теплому» контурі, щоб не роздувати комісії при висновках.

3. 2 EVM-мережі (ETH/L2, BSC та ін.)

Проксі-контракти/псевдолічення: унікальні «приймачі», маппінгом зв'язуються з інвойсами.
Субрахунки/віртуальні адреси у кастодіального провайдера.
Permit/meta-tx: скорочують зайві approve-виклики і витоки зв'язності в ончейн-трасі.

3. 3 Мережі з тегами/мемо

Одна основна адреса + унікальний мемо/тег на платіж.
TTL і повторне використання тегу заборонені - тільки одноразові мітки.

4) Приватність vs Комплаенс: Як поєднати

KYT на вхід/вихід: ротація не скасовує скринінг; навпаки, зменшує «успадкований шум» графа.
Travel Rule (VASP↔VASP): обмін IVMS-даними прив'язується до платіжного ідентифікатора/адреси, а не до «вічного» публічного гаманця.
RBA-порогова логіка: чим вище ризик/сума - тим суворіше підтвердження і менше агрегація.
Whitelist с TTL: для частих клієнтів - закріплені адреси, але з періодичною реверифікацією та обмеженнями за сумою.

5) Облік, мепінг і реконсиляція

Лейджер першого класу: таблица `invoice_id ↔ derived_address ↔ txid ↔ wallet_subaccount ↔ client_id`.
Атрибути адреси: `created_at`, `expires_at (TTL)`, `status (issued/paid/expired)`, `network`, `tag/memo`.
Реконсиляція T + 0/T + 1: звірки сум, комісій мережі/провайдера, курсів; альберти по «висяках» (адреса оплачена без інвойсу, платіж після TTL і т. п.).
Аудит-лог: хто і коли зарезервував/видав адресу, змінив TTL, провів ребаланс.

6) Операційні практики (пули і ребаланс)

Hot-пул: невелика експозиція, часта ротація вихідних адрес, ліміти per-tx/per-day.
Warm-пул: періодична консолідація та поповнення hot; адреси пулювання теж ротуються.
Cold-пул: довгострокове зберігання, офлайн-підпис, рідкісна зміна адрес (при досягненні порогів експозиції).

7) UX-патерни (щоб не ламати конверсію)

Чіткий TTL і таймер на платіжній сторінці; кнопка «оновити рахунок» → нову адресу/тег.
Авто-детекція мережі за адресою, попередження «невірна мережа/відсутній тег».
QR/deeplink з коректним'memo/tag'; заборона копіпасти без тегу.
Статуси: «рахунок створено → очікуємо підтверджень → зараховано» з прогресом по блоках.
Переадресація платежів після TTL: політика - прийняти з прапором «late» або повернути (прописати в ToS).

8) Метрики та контроль якості

Address reuse% (частка повторно використаних адрес) - цільовий мінімум.
Середнє життя адреси до платежу (p50/p95) і частка «late after TTL».
Частка платежів з помилками мережі/тегу та їх динаміка після UX-поліпшень.
KYT reject% на вхід/вихід (по мережах і провайдерам).
Leakage індикатори: скільки зовнішніх аналізів/запитів корелюють ваші відомі пули (побічно через інциденти/запити партнерів).
Ребаланс частота/обсяг, комісія на консолідації UTXO (як% від обороту).

9) Безпека та операції

HSM/KMS/MPC для ключів; мультисиг/роль «4 ока» на операції warm/cold.
Ідемпотентність на видачу адрес ('address _ request _ id') і прийому вебхуків.
Анти-дублі: захист від повторного зарахування/списання однієї і тієї ж мітки/інвойсу.
Private relay/MEV-захист для великих вихідних транзакцій (VIP/ребаланс).
Monitoring: RPC-здоров'я, затримки підтверджень, fee-шторму, «підозріла» адресна кореляція.

10) Спеціальні теми

10. 1 «Адресна репутація» і успадкування зв'язків

Історично «засмічені» адреси можуть тягнути небажані зв'язки в KYT; ротація і чисті приймачі знижують false positive.
При виявленні негативного зв'язку - заміна адреси, пересоздание інвойсу, нотифікація клієнта.

10. 2 UTXO-гігієна

Консолідація дрібних UTXO в непіковий час (низький fee), щоб не роздувати газ при виводах.
Уникайте «злиття» UTXO з адрес, де є KYT-прапори, без аналізу.

10. 3 Стелс-адреси і PayJoin (обачно)

Техніки підвищення приватності (stealth, PayJoin, CoinJoin) можуть конфліктувати з політикою AML/партнерів. У iGaming використовуйте тільки якщо вони сумісні з вашою RBA-політикою і не суперечать вимогам провайдерів.

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

Address reuse для багатьох клієнтів/інвойсів - пряма deanonymization і зростання KYT-шуму.
Нескінченний TTL адрес - «забуті» платежі і складні диспути.
Прийняття платежів «в будь-якій мережі/без тегу» - гарантовані втрати.
Консолідація UTXO «в один мішок» без аналізу походження.
Висновки з «вічної» операційної адреси - легке трасування пулів і атак.
Ротація, що порушує облік (немає мепінгу'invoice ↔ address') - розсипана реконсиляція.

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

• HD-деривація (BIP32/44/84), каталог шляхів, gap limit ≥ 50.
• Одна адреса/тег на інвойс, TTL і автогенерація нового при продовженні.
• Меппінг в лейджері: `invoice ↔ address/tag ↔ txid ↔ subaccount`.
• Ротація вихідних адрес і ліміти експозиції (N tx або ≥ X).
• KYT pre-check вхід/вихід; whitelist з TTL і підтвердженням володіння.
• UTXO-гігієна і планові консолідації поза піків.
• UX-валідації мережі/тегу, QR/deeplink, статуси/прогрес підтверджень.
• Ідемпотентність/анти-дублі; підписані вебхуки; аудит-лог.
• Travel Rule (VASP↔VASP): IVMS-дані по платіжному ідентифікатору.
• Метрики: reuse%, помилки мережі/тегу, KYT reject%, ребаланс/fee.

13) Резюме

Ротація адрес - це операційна дисципліна, а не «хитрість приватності». Генеруйте унікальні адреси/теги під кожен інвойс, ведіть строгий мепінг і TTL, тримайте UTXO-гігієну і ротацію вихідних адрес, а приватність поєднуйте з KYT/Travel Rule/RBA. Такий підхід захищає бізнес-дані, знижує ризики і не заважає ні звітності, ні конверсії.