Seleção de blockchain: L1/L2 e comissões

1) O que escolhemos e porquê

• comissões e taxa de inscrições/conclusões,
• disponibilidade de bits/provedores,
• sustentabilidade da infraestrutura e riscos operacionais,
• requisitos KYT/Travel Rule e UX (endereços, mmo/tags).

2) Conceitos básicos: L1 vs L2

L1 (camada básica): seu próprio consenso e segurança (Ethereum L1, Bitcoin, Solana, BNB Smart Chain, TRON etc.).
L2 (acima do Ethereum): escala com segurança herdada L1 (Optimistic rollups: Arbitrum/Optimism/Base; ZK rollups: zkSync/Linea/Polygon zkEVM и др.).

• Finalização/confirmação: O L2 oferece um UX rápido, mas a segurança final é associada ao L1 (challenge/commit período para optimistic; validity-proof para ZK).
• Custo: L2 normalmente mais barato que L1 (especialmente vs Ethereum L1).
• Conclusões em L1: no optimístico - finalização adiada (challenge period) para a ponte; A ZK é mais rápida.

3) Critérios de seleção de rede (matriz de classificação)

1. Comissões e variabilidade

Comissão média por depósito/retirada/transferência interna; volatilidade do fee nos picos.

2. Tempo até a finalização

p50/p95 antes do status «inscrito/pronto para retirada» no produto; a possibilidade de reorganização.

3. Confiabilidade e ecossistema

Farmácia, maturidade nod/RPC, ferramentas de monitoramento, disponibilidade de provedores on/off-ramp.

4. Disponibilidade e liquidez de stablocoins

Disponibilidade de USDT/USDC/FDUSD, profundidade de vapor dos seus provedores e bolsas.

5. Complacência e características operacionais

Suporte a Travel Rule em castodianos, qualidade dos sinais KYT, riscos das marcas de sanções.

6. Fatores UX

Formato de endereço/necessidade de mmo/tag, suporte a QR/deplink, frequência de erros dos usuários.

4) Redes típicas e seu perfil (em corte de pagamento)

TRON (USDT/USDC): comissões extremamente baixas, finalização rápida, amplo suporte dos provedores. É popular para depósitos em massa nas regiões de custo-sensível.
Ethereum L2 (Arbitrum/Optimism/Base): equilíbrio preço/velocidade, forte integração com infraestrutura e USDC. Bom para os mercados com foco em relatórios/compatibilidade.
BNB Smart Chain (BSC): baixo custo, amplo ecossistema de carteira; acompanhe o fornecimento e os requisitos da complacência.
Solana: alta largura de banda e baixas comissões; verifique a maturidade dos provedores, a estabilidade do RPC e seus processos DevOps.
Ethereum L1: confiável e compatível com bancos/relatórios, mas caro; apropriado para cálculos VIP/corporativo ou como «âncora» de liquidez.
Redes mmo/tag (XRP/XLM/TON etc.): Baratos e rápidos, mas exigem validação rigorosa das marcas de formatação → risco de erro UX sem bloqueio.

5) Modelo de Comissão e Orçamento (Costa per Approved)

• redes (gas/fee) para depósito/retirada,
• comissões do provedor/bolsa (entrada/saída/conversão),
• KYT/Travel Rule/webhooks,
• custos de operação (malas manuais, safort),
• perdas decorrentes de erros de rede/mmo (se não houver validação).

Prática: Leia o all-in em cada rede, em vez de «nu gas». Mantenha o limiar switch-over - quando o median fee/tempo crescer, mude para a rede de reserva.

6) Política de confirmação e finalização

Janelas dinâmicas de confirmação: N blocos depende da soma/risco do segmento e da carga atual da rede.
Lógica RBA: Low Risk + stable na rede de baixo fio → confirmação mínima; High Risk/novo livro de endereços → mais confirmações/hold.
Estados UX: «Endereço recebido → Aguardamos confirmações → Inscrito». Mostre o timer/progresso.

7) Routing e feelover de várias cadeias

Primary + Secondary per asset: напр., USDT на TRON (primary) и BSC (secondary); USDC на Arbitrum (primary) и Base (secondary).
Regras de mudança automática: latência, fee, incidentes RPC, aumento de falhas KYT.
Pool de liquidez: mantenha o float de trabalho em 2 + redes, automatize a revalance através de RFQ com várias bolsas.
Idempotidade: chaves 'invoice _ id/withdrawal _ id' e anti-dublagem em retais.

8) Complaens e segurança

Sanções KYT +: endereços pré-check/bolsas/cluster antes da inscrição e antes da retirada; redes diferentes → perfis de risco diferentes.
Travel Rule: Para VASP↔VASP, mantenha o IVMS101 e a passarela; política para unhosted (assinatura de endereço/microexame, white-list).
Armazéns e chaves: HSM/KMS, multisig, limites de saída, quatro olhos.
Dados: logs de soluções, origem de curso, tocenização PII, armazenamento separado do PAN.

9) X-pattern que salvam dinheiro

Detecção automática da rede em/QR, avisos em caso de inadequação.
Mmo/tag é «severamente obrigatório» onde necessário: validador para UI + API, folha de cheque antes de ser enviado.
Livro de endereços/Whitelist com revalidação, TTL e KYT.
Explicação da comissão e ETA antes do pagamento para reduzir os tíquetes na saforta.
Deplink na carteira e suprimento automático de campos.

10) Exemplo de política de seleção (esboço)

11) Contabilidade, reconsilização, curso

Lager por redes/ativos, mapping 'invoice/withdrawal ↔ txid ↔ subaccount'.
Cursos (VWAP/multi-fid) com timestamp fixo; regras de arredondamento.
Relatórios T + 0/T + 1: redes, comissões, soluções KYT, eventos Travel Rule.

12) Métricas e OKR

Approval Rate, Time-to-Finality p50/p95, custo/transação online.
KYT reject %/sanções hits/SAR-conversion.
Proporção de erros de rede/tag, repetição de endereços problemáticos.
Frações de fluxo nas redes, número de auto switch-over, farmácia RPC.
Exposição por ativos/redes, frequência de rebalance.

13) Anti-pattern

«Aceitamos em qualquer rede» sem validação rigorosa - perda garantida.
Um provedor/uma rede sem reservas - single point of failure.
Nota apenas gas, valor all-in ignorado e SLA.
Falta de confirmação dinâmica/ETA - avalanche de tíquetes.
Não há RBA/Travel Rule/KYT - os parceiros estão bloqueados.
Armazenamento de chaves sem HSM/multisig e limites - riscos operacionais.

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

• Matriz de redes Primary/Segundary por ativo; regras switch-over.
• Confirmações dinâmicas + estados UX e ETA.
• Validação de endereços/mmo/marcas (UI + API), QR/deplink.
• CUT/sanções pré-check, política unhosted e livro de endereços.
• Travel Rule Hall (IVMS101) para VASP↔VASP.
• Pulas de liquidez em 2 + redes, RFQ/Multiplicy, conversão T0.
• Lager e reconsilização pelas redes; fontes de cursos.
• Idempotidade, anti-duplos, retraí com backoff + jitter.
• Monitoramento de fee/ETA/SLA, alertas de degradação, playbooks de incidentes.
• Treinamento de safort: erros frequentes de rede/tag, modelos de resposta.

15) Resumos

A escolha da rede é uma estratégia operacional, não uma lista de logos. Mantenha o custo mínimo de aprovação, finalização rápida e previsível, redes de reserva e disciplina de complacência. Combine o L1/L2 sob geo e segmentos, automatize o roteiro e as confirmações, proteja a UX com validações - e os roteiros de pagamento cripto serão rápidos, seguros e rentáveis.