Hot/Cold carteiras e políticas de acesso

1) Por que dividir em Hot/Warm/Cold

• Hot - depósitos/conclusões operacionais (T0/T + 1), atrasos mínimos, equilíbrio limitado.
• Warm é um pool intermediário para reposição hot e grandes pagamentos regulares.
• Cold - armazenamento de longo prazo (reservas/tesouraria), o mais isolado possível da rede.

Resultado: menos riscos operacionais e SLA previsíveis com exposição controlada.

2) Arquitetura de armazenamento

Camadas e seu papel

Hot (on-line, automatizado): assina pagamentos pequenos/médios dentro dos limites diários. Proteção - HSM/KMS, policy engine, alertas.
Warm (plug-in em parte online/hardware): pagamentos de batch, reposição hot, limites elevados, confirmação manual.
Cold (offline/air-gapped): multisig/MRS; operações raras, por procedimento de acesso físico e registro.

Tecnologia

HSM/KMS para chaves hot/warm e tokens;

Multisig m-of-n ou MPC para warm/cold;

Policy engine (limites, 4 olhos, listas de endereços permitidos, janelas de tempo);

Private relay/proteção contra MEV para grandes transações.

3) Política de acesso (Access Policy)

3. 1 Princípios

Menores privilégios (PoLP): acesso exatamente por papel e zona (hot/warm/cold).
Separação de responsabilidades (SoD): Diferentes pessoas/serviços iniciam, afirmam, assinam, lançam.
4-olho: pelo menos duas aprovações independentes para operações críticas (limites, listas de endereços, warm→hot).
Isolamento de contornos: prod ≠ estágio; LCA de rede, credenciais individuais.

3. 2 Papéis

Operator (Payments): cria pagamentos/batches dentro dos limites.
Approver (Treasury/Risk): aprovação acima de liminares, whitelist/hold.
Custodian (Key Owner): participação no multisig/MRS para warm/cold.
Compliance: holds/EDD/SAR, Travel Rule/KYT.
Segurança: controle HSM/KMS, rotação de chaves, incidentes.

4) Limites e guindastes

Whitelist/denylist: livro de endereços com liminares TTL, KYT e confirmação de posse obrigatória (para unhosted).

5) Fluxos operacionais

5. 1 Reabastecimento hot de warm

1. Monitorar 'hot _ balance <threshold' → pedido de reposição.
2. KUT/sanções sobre os endereços de destino → coleta de batch.
3. Dupla aprovação (4-olhos), assinatura (warm multisig/MRS).
4. Tradução e gravação para o leigo; alert de alteração de limites.

5. 2 Pagamentos de hot

Automaticamente dentro dos limites per-tx e per-day.
Para excesso, escalação em warm: batch/lançamento parcial + verificação RBA (SoF/KYT/Travel Rule).

5. 3 Rebalance warm↔cold

Periodicamente (semanal/por limiar) ou por determinação do Tesouro; assinatura offline, dois canais de confirmação independentes, um diário.

6) Segurança chave

Geração e armazenamento: somente em HSM/air-gapped; Não exportar chaves privadas.
Rotação: programada (N meses), não programada no incidente; procedimentos documentados de retirada.
Backup/Shard-Management: bolas criptografadas (MPC) em diferentes locais/jurisdições; Testes de recuperação periódicos.
Perímetro de rede: IP allow-list, mTLS, webhooks assinados, monitoramento de anomalias.
Mudança-control: RFC para alteração de políticas/limites, registro de alterações (imutable).

7) Complaens e controle

KUT/sanções: pré-check para entrada/saída; perfis de risco diferentes em redes.
Travel Rule: para VASP↔VASP - IVMS101, réplicas de mensagens e resultados de entrega.
RBA: os limites/confirmação dependem do segmento de risco e do valor.
Auditoria: pista completa: quem/quando/que iniciou/aprovou/assinou; uma versão das regras no momento da operação.
GDPR/PII: Minimização, Tocenização de ID, armazenamento separado de PAN de pagamento.

8) Observabilidade, logs e reconsilação

Lager: mapping 'invoice/withdawal ↔ txid ↔ wallet' por rede/ativo.
Reconsilização T + 0/T + 1: somas, comissões, taxa de câmbio (fonte de preços, timestamp), sobras não abertas.
Monitoramento: balanço hot/warm/cold, velocidade de confirmação, fee, pagamentos anormais, mudanças para redes de reserva.
Alerts: excesso de limites/velocity, novos endereços fora do whitelist, discrepâncias.

9) Playbooks incidentes

Fuga/comprometimento hot: remoção imediata de limites para zero, transferência de sobras para warm/cold, rotação de chaves, investigação, relatório aos reguladores/parceiros.
Anomalias de pagamento: freeze batch, KYT re-check, SoF pedido, lançamento parcial da parte segura.
Degradação da rede/fee-tempestade: auto switch-over para rede de reserva/método, atualização ETA para UI.
O provedor custody/RPC não está disponível: feedback, lançamento manual de pagamentos críticos via warm, análise pós-incidente.
Mudança de políticas não autorizada: rollback automático, notificação de SecOps/Compliance, relatório de auditoria.

10) Métricas e OKR

Segurança/Complacência

Participação de ativos em cold/warm/hot (faixa de destino), número de violações de limites.
KYT reject%, hits de sanção, SAR-conversão (se aplicável).
Número de alterações de políticas/mês, pedidos de aumento de limites bem-sucedidos/rejeitados.

Confiabilidade/operações

Time-to-Payout p50/p95 para rotas hot/warm.
Taxa de reposição hot, média de reposição.
Porcentagem de pagamento de carros vs manual, incidentes/trimestre.

Economia/UX

Costa per Approved (all-in em rede/ativo), fee-percentual do montante.
Erros de rede/mmo/tag, quantidade de release parcial, tíquetes de atraso.

11) Anti-pattern

Carteiras de hot cheias sem caps diurnos rígidos.
Um provedor castodial/uma rede sem reserva → SPOF.
Falta de quatro olhos e SoD na operação warm/cold.
Chaves sem HSM/KMS, sem rotatividade regular/testes de recuperação.
Não há whitelist/TTL ou KYT antes de sair - risco elevado.
Altere os limites «por mensagem» sem RFC/auditoria.
Falta de idempotidade e anti-duplicação em retais - duplos descartados.

12) Folha de cheque de implementação (curta)

• Matriz de camadas: hot/warm/cold com limites per-tx/per-day e participação de ativos.
• Papéis e SoD: Operator/Approver/Custodian/Compliance/Security, 4-olhos.
• HSM/KMS para hot/warm, multisig/MRS para warm/cold, assinatura offline.
• Whitelist/denylist endereços com TTL, liminares KYT, confirmação de posse.
• Processos: reposição de hot, pagamentos de warm, revalidação em cold.
• Observabilidade: lager, reconsilização T + 0/T + 1, alertas de excesso.
• Playbooks de incidentes: comprometimento, degradação da rede, indisponibilidade do provedor.
• Travel Rule/IVMS101, políticas RBA, auditoria de alterações.
• Idempotidade, anti-duplos, backoff + jitter; webhooks assinados.
• Testes regulares de recuperação de chaves e exercícios de incidentes.

13) Resumos

A estratégia hot/warm/cold correta não é apenas «três carteiras», mas sim o modo de gerenciamento de risco e acesso: limites e 4 olhos, HSM/KMS e multisig/MRS, KYT/Travel Rule e RBA, procedimentos claros de reposição e pagamento, observabilidade e playbooks. Este caminho oferece pagamentos rápidos de hot com uma exposição mínima de ativos e resistência a incidentes - a base de uma infraestrutura de pagamento segura e lucrativa.