Hot/Cold Wallets and Access Policy

1) Why split into Hot/Warm/Cold

• Hot - operational deposits/withdrawals (T0/T + 1), minimum delays, limited balance.
• Warm - intermediate pools for hot replenishment and large regular payments.
• Cold - long-term storage (reserves/treasury), isolated from the network as much as possible.

The result: fewer operational risks and predictable SLAs at controlled exposure.

2) Storage reference architecture

Layers and their role

Hot (online, automated): signs small/medium payments within daily limits. Protection - HSM/KMS, policy engine, alerts.
Warm (partially online/hardware module): batch payments, hot replenishment, increased limits, manual confirmation.
Cold (offline/air-gapped): multisig/MRS; operations are rare, according to the procedure with physical access and a journal.

Technologies

HSM/KMS for hot/warm keys and tokens;

m-of-n multisig or MPC for warm/cold;

Policy engine (limits, 4-eyes, lists of allowed addresses, time windows);

Private relay/MEV protection for large transactions.

3) Access Policy

3. 1 Principles

Least Privileges (PoLP): Access is exactly by role and zone (hot/warm/cold).
Separation of duties (SoD): different people/services initiate, approve, sign, release.
4-eye: at least two independent approvals for critical operations (limits, address lists, warm→hot).
Isolating paths: prod ≠ stage; network ACLs, individual credentials.

3. 2 Roles

Operator (Payments) - creates payments/batches within limits.
Approver (Treasury/Risk): approval over thresholds, whitelist/hold.
Custodian (Key Owner): Participation in multi-game/MRS for warm/cold.
Compliance: holds/EDD/SAR, Travel Rule/KYT solutions.
Security: HSM/KMS management, key rotation, incidents.

4) Limits and guardrails

Whitelist/denylist: address book with TTL, KYT thresholds and mandatory proof of ownership (for unhosted).

5) Operating flows

5. 1 Replenishment hot from warm

1. Monitoring 'hot _ balance <threshold' → replenishment request.
2. TAC/sanctions by destination addresses → butch collection.
3. Double approval (4-eye), signature (warm multisig/MRS).
4. Translation and recording in the ledger; alert about changing limits.

5. 2 Payouts from hot

Automatically within per-tx and per-day limits.
To exceed - escalation in warm: batch/partial release + RBA check (SoF/KYT/Travel Rule).

5. 3 Rebalance warm↔cold

Periodic (weekly/by threshold) or by treasury decision; offline signature, two independent confirmation channels, log.

6) Key security

Generation and storage: only on HSM/air-gapped; refusal to export private keys.
Rotation: planned (N months), unplanned at the incident; documented recall procedures.
Backup/Shard-management: encrypted balls (MPC) in different locations/jurisdictions; periodic recovery tests.
Network perimeter: IP allow-list, mTLS, signed webhooks, anomaly monitoring.
Change-control: RFC for changing policies/limits, immutable.

7) Compliance and control

KUT/sanctions: pre-check for entry/exit; different risk profiles across networks.
Travel Rule: for VASP↔VASP - IVMS101, replicas of messages and delivery results.
RBA: Limits/confirmations depend on risk segment and amount.
Audit: full trail: who/when/what initiated/approved/signed; The rule version at the time of the operation.
GDPR/PII: minimization, ID tokenization, separate storage from payment PANs.

8) Observability, logs and reconsilation

Lager: mapping 'invoice/within ↔ txid ↔ wallet (subaccount)' by network/asset.
T + 0/T + 1 reconciliation: amounts, fees, rate (price source, timestamp), open balances.
Monitoring: hot/warm/cold balance, confirmation speed, fee, abnormal payments, switching to backup networks.
Alerts: over limits/velocity, new addresses outside whitelist, reconciliation discrepancies.

9) Incident playbooks

Leak/compromise hot: immediate removal of limits to zero, transfer of balances to warm/cold, key rotation, investigation, report to regulators/partners.
Payment anomalies: freeze batch, KYT re-check, SoF request, partial release of the safe part.
Network/fee storm degradation: auto switch-over to standby network/method, ETA update in UI.
Inaccessibility of the custody/RPC provider: feilover, manual release of critical payments via warm, post-incident analysis.
Unauthorized policy changes: automatic rollback, SecOps/Compliance notification, audit report.

10) Metrics and OKR

Security/Compliance

Share of assets in cold/warm/hot (target ranges), number of limit violations.
KYT reject%, sanctioned hits, SAR-conversion (if applicable).
Number of policy changes/month, successful/rejected limit escalation requests.

Reliability/Operations

Time-to-Payout p50/p95 for hot/warm routes.
Replenishment frequency hot, average replenishment size.
Percentage of auto payments vs manual, incidents/quarter.

Economics/UX

Cost per Approved (all-in by network/asset), fee-percentage of the amount.
Network/memo/tag errors, number of partial releases, latency tickets.

11) Anti-patterns

Overflowing hot wallets without hard daytime mouthguards.
One custodial provider/one network without SPOF → reserve.
No 4-eyes and no SoD on warm/cold surgery.
Keys without HSM/KMS, no regular rotation/recovery tests.
No whitelist/TTL and KYT before withdrawal - increased risk.
Changing limits "by messenger" without RFC/audit.
Lack of idempotency and anti-doubles in retrays - double write-offs.

12) Implementation checklist (short)

• Layer matrix: hot/warm/cold with per-tx/per-day limits and asset shares.
• Roles and SoDs: Operator/Approver/Custodian/Compliance/Security, 4-eye.
• HSM/KMS for hot/warm, multisig/MRS for warm/cold, offline signature.
• Whitelist/denylist addresses with TTL, KYT thresholds, proof of ownership.
• Processes: hot replenishment, batch payments from warm, rebalance to cold.
• Observability: lager, T + 0/T + 1 reconstitution, excess alerts.
• Incident playbooks: compromise, network degradation, provider unavailability.
• Travel Rule/IVMS101, RBA policies, audit changes.
• Idempotency, anti-takes, backoff + jitter; signed webhooks.
• Regular key recovery tests and incident drills.

13) Summary

The correct hot/warm/cold strategy is not just three wallets, but a risk and access management mode: limits and 4-eyes, HSM/KMS and multisig/MRS, KYT/Travel Rule and RBA, clear replenishment and payment procedures, observability and playbooks. This circuit gives quick payments from hot with minimal asset exposure and incident resilience - the basis of iGaming's secure and profitable payment infrastructure.