Address rotation and privacy

1) Why address rotation in iGaming

Rotation (regular change of addresses during deposits/conclusions) reduces the connectivity of the online graph, protects trade secrets (turnover, liquidity pool), reduces the risks of targeted attacks and "address reputation," and also improves the quality of KYT (fewer "dirty" inherited connections). An important difference: privacy ≠ anonymity - rotation is done within the RBA/KYT/Travel Rule and does not interfere with reporting.

• minimize address-reuse and gluing transactions by graph,
• increase dox/phishing resistance,
• maintain AML/sanctions compliance and transparent accounting.

2) Rotation policy: where and when to change address

Deposits

Invoice address: a new unique address for each invoice/payment attempt.
TTL addresses: account lifetime (for example, 60-120 minutes) with the possibility of extension.
Tagged networks (XRP/XLM/TON): Destination Tag/Memo rotation instead of new primary address; strict tag validation.

Conclusions

Use whitelist customer addresses (proof of ownership + KYT).
Rotation of source (operator) addresses according to exposure limits (for example, N transactions or the amount of ≥ X → change of address/wallet).

Internal movements

For internal calls - dedicated "service" addresses with regular rotation and understandable labeling in the ledger.

3) Address Derivation and Management Framework

3. 1 HD wallets (UTXO networks: BTC, etc.)

BIP32/BIP44/BIP84: hierarchical derivation with a clear path structure.
Gap limit: configurable (for example, 50-100) so as not to lose uncollected deposits.
Change addresses: always separate, also rotated.
UTXO hygiene: periodically combining small UTXOs on a "warm" circuit so as not to inflate withdrawal fees.

3. 2 EVM networks (ETH/L2, BSC, etc.)

Proxy contracts/pseudo-accounts: unique "receivers" associated with invoices by mapping.
Subaccounts/virtual addresses at the custodial provider.
Permit/meta-tx: Reduce unnecessary approve calls and connectivity leaks in the online track.

3. 3 Tagged Networks/Memo

One primary address + unique memo/tag per payment.
TTL and tag reuse are prohibited - only one-time tags.

4) Privacy vs Compliance: How to Combine

KYT in/out: rotation does not cancel screening; conversely, reduces the "inherited noise" of the graph.
Travel Rule (VASP↔VASP): the exchange of IVMS data is tied to the payment identifier/address, and not to the "eternal" public wallet.
RBA-threshold logic: the higher the risk/amount, the stricter the confirmation and less aggregation.
Whitelist with TTL: for frequent customers - fixed addresses, but with periodic reversals and limits on the amount.

5) Accounting, Mapping and Reconciliation

Leyger of the first class: table'invoice_id  derived_address  txid  wallet_subaccount  client_id'.
Address attributes: 'created _ at', 'expires _ at (TTL)', 'status (issued/paid/expired)', 'network', 'tag/memo'.
T + 0/T + 1 reconciliation: reconciliation of amounts, network/provider fees, rates; alerts by "hangs" (address paid without invoice, payment after TTL, etc.).
Audit log: who and when reserved/issued the address, changed TTL, rebalanced.

6) Operational practices (pools and rebalance)

Hot-pool: small exposure, frequent rotation of outgoing addresses, limits per-tx/per-day.
Warm pool: periodic consolidation and replenishment hot; pooling addresses are also rotated.
Cold pool: long-term storage, offline signature, rare address change (when exposure thresholds are reached).

7) UX patterns (to avoid breaking the conversion)

Clear TTL and timer on the payment page; Update Account button → new address/tag.
Auto-detect network at, incorrect network/missing tag warnings.
QR/deeplink with the correct 'memo/tag'; disallowing untagged copy paste.
Statuses: 'account created → awaiting confirmations → offset' with progress by blocks.
Forwarding payments after TTL: policy - accept with the flag "late" or return (register in ToS).

8) Metrics and quality control

Address reuse% - target minimum.
The average life of the address before payment (p50/p95) and the "late after TTL" share.
Share of payments with network/tag errors and their dynamics after UX improvements.
KYT reject% for input/output (over networks and providers).
Leakage indicators: how many external analyses/queries correlate your known pools (indirectly through incidents/partner queries).
Rebalance frequency/volume, commission on UTXO consolidation (as% of turnover).

9) Security and Operations

HSM/KMS/MPC for keys; multisig/4-eye role on warm/cold surgery.
Idempotency for issuing addresses ('address _ request _ id') and receiving webhooks.
Anti-duplicate: protection against re-crediting/writing off the same tag/invoice.
Private relay/MEV protection for large outgoing transactions (VIP/rebalance).
Monitoring: RPC health, confirmation delays, fee storm, "suspicious" address correlation.

10) Special topics

10. 1 "Address reputation" and link inheritance

Historically, "clogged" addresses can pull unwanted links in KYT; rotation and net receivers reduce false positive.
If a negative connection is detected, replace the address, recreate the invoice, notify the client.

10. 2 UTXO hygiene

Consolidating small UTXOs during off-peak times (low fee) so as not to inflate gas at withdrawals.
Avoid "merging" UTXO from addresses that have KYT flags without analysis.

10. 3 Stealth addresses and PayJoin (prudent)

Privacy techniques (stealth, PayJoin, CoinJoin) may conflict with AML/partner policies. In iGaming, use only if they are compatible with your RBA policy and do not contradict the requirements of providers.

11) Anti-patterns

Address reuse for many customers/invoices - direct deanonymization and KYT noise growth.
Endless TTL addresses - "forgotten" payments and complex disputes.
Accepting payments "on any network/without a tag" - guaranteed losses.
One-bag consolidation of UTXO without origin analysis.
Conclusions from the "eternal" operational address - easy tracing of pools and attacks.
Accounting violation rotation (no mapping'invoice ↔ address') - scattered reconciliation.

12) Implementation checklist (short)

• HD derivation (BIP32/44/84), path directory, gap limit ≥ 50.
• One address/tag per invoice, TTL and auto-generate new on renewal.
• Mapping in the leader: 'invoice ↔ address/tag ↔ txid ↔ subaccount'.
• Outgoing address rotation and exposure limits (N tx or ≥ X).
• KYT pre-check in/out; whitelist with TTL and proof of ownership.
• UTXO hygiene and planned off-peak consolidations.
• UX network/tag validation, QR/deeplink, statuses/confirmation progress.
• Idempotency/anti-duplicates; signed webhooks; audit-log.
• Travel Rule (VASP↔VASP) - Payment ID IVMS data
• Metrics: reuse%, network/tag errors, KYT reject%, rebalance/fee.

13) Summary

Address rotation is an operational discipline, not a "privacy trick." Generate unique addresses/tags for each invoice, maintain strict mapping and TTL, keep UTXO hygiene and outbound address rotation, and combine privacy with KYT/Travel Rule/RBA. This approach protects business data, reduces risk and does not interfere with reporting or conversion.