GH GambleHub

Carteiras castodiais e não-astodiais

1) Por que escolher um modelo de carteira é importante para iGaming

A carteira é o «núcleo de pagamento» dos fluxos cripto: depósitos, movimentações intra-jogo, conclusões, on/off-ramp, devoluções. Dependem do modelo (custodial vs non-custodial):
  • velocidade e previsibilidade da Time-to-Finality/SLA;
  • Custo per Approved e custos operacionais;
  • Nível de complacência (KYC/KYT/Travel Rule/Sanções);
  • segurança das chaves e facilidade UX.

2) Modelos básicos

2. 1 Custodial (custodial)

Chaves e balanços armazenam o provedor/VASP (ou você é como um custodiano). O usuário tem uma conta, não uma chave privada.
Vantagens: início rápido, SLA/24 x 7, pronto KYT/Travel Rule, simples devoluções e relatórios, friendly-UX.
Contras: credibilidade do provedor, requisitos regulatórios, foco de dê diligence e reserva de provedores.

2. 2 Não-astodiais (não-custodial/self-custody)

O usuário tem a chave (seed/passphrase, passkey, recovery social). Você interage com o endereço/contrato do usuário.
Benefícios: controle do cliente, menor risco castodial, menor exigência de armazenamento de PII/chaves.
Contras: mais difícil UX, erro de rede/tag/endereço - responsabilidade do cliente; para você - KYT/Travel Rule tratamentos para unhosted.

2. 3 Híbrido

Custody para fluxos de massa (faturas, conclusões rápidas).
Self-custody para público VIP/web 3 com maior flexibilidade.
Subcontinentes internas + listas brancas de endereços externos.

3) Tecnologia: Multissig, MPC, AA

TecnologiaOnde se aplicaBenefíciosRiscos/Notas
Multisig (m-of-n)Armazéns quentes/quentes, corporate flows«4 olhos», limites, separação de papéisControle de participantes, implementação cruzada varia
carteiras MPCCustody/enterprise, SDK móvelSem um único ponto de comprometimento da chave, UX suaveDificuldade de rotação, são necessários provedores confiáveis
AA / ERC-4337Smart-wallet UXPaymaster (sponsor gas), policy-guardrailsMaturidade do ecossistema por redes, monitorização dos bandlers
Permit / meta-txDepósitos de tokens- 1 transação onchain, acima de ARNem todos os tokens estão disponíveis

4) Segurança de chaves e operações

HSM/KMS para chaves castodiais; segregação de ambientes (pró/estágio), entropia de hardware, rotação.
Limites e políticas de saída: diurno/relógio, velocity em endereços/redes, duas assinaturas para somas> X.
RBAC/SoD: divisão de responsabilidades (criação/assinatura/lançamento).
Private relay/MEV proteção para grandes pagamentos.
Registros e logs de ação imutáveis de operadoras e clientes API.

5) Complaens: KYC/KYT/Travel Rule/RBA

Modelo KYC/Tier: acelerado para Low Risk; EDD+SoF/SoW para High/VIP.
KYT: endereços pré-check/bolsas/cluster antes da inscrição e antes da retirada; white/deny listagem de endereços com TTL.
Travel Rule: VASP↔VASP troca IVMS101; política unhosted - confirmação de posse de endereço (assinatura/microexame), limites.
Matriz RBA: Low/Ted/High → confirmação, limites, review manual/hold/SAR.

6) Patrões arquitetônicos

6. 1 Custode-pilha (árbitro)

Wallet/Custody Core: MRS/multisig, limites, políticas.
Crypto Gateway: faturas, estatais, mmo/tags, confirmações dinâmicas.
Risk & Compliance Hub: KYT/sanções/Travel Rule, soluções RBA.
Treasury: Conversão T0, RFQ/Multiplicy, revalidação entre redes/carteiras.
Accounting & Recon: lager, mapping 'invoice/withdrawal ↔ txid ↔ subaccount'.
Observabilidade: métricas SLA/fee/ETA, alertas, auditorias.

6. 2 Não-custody-pilha

Smart-wallet/AA с policy-guardrails (daily caps, trusted spenders).
Address book/whitelisting; Validação UX da rede/mmo/marcas de formatação.
Self-custody apoio: instruções, QR/deplinks, estatais de confirmação.

7) UX: como não quebrar a conversão

Seedless/passkeys/recovery social (para AA/MPC) em vez de uma frase de 12 a 24 palavras.
Detecção automática da rede no endereço, validação obrigatória mmo/tag (XRP/XLM/TON etc.).
QR/deplink, estatais: «endereço criado», «aguardando confirmações», «inscrito».
Explicação das comissões e da ETA antes do pagamento; dicas sobre TXID/mmo.
Parcial release em verificações (EDD/SoF) em vez de bloqueio «surdo».

8) Economia e operações

Comissão de rede + provedor + KYT/Travel Rule + ops → leia all-in em rede/ativo.
Time-to-Finality p50/p95 - SLA principal; suporta a rede primary/secundary por ativo.
Idempotidade: chaves 'invoice _ id/withdrawal _ id', anti-duplos, backoff + jitter.
Reconsilização T + 0/T + 1: quantia, comissão, FX/curso, estatais, sobras não reveladas.
Devoluções: é uma nova tradução onchain; regra para endereço/rede original ou nova confirmação.

9) Comparação de modelos: o que escolher

CritérioCastodialNão-astodial
Iniciar/velocidadeRápido (widget/SDK, SLA)Mais longo (Educação, CUB)
UXHabitual para Web2, menos errosLiberdade, mas maior risco de rede/marca errada
ComplaensKYT/Travel Rule incorporadoÉ preciso implementar o CUT/política unhosted
Controle de chavesO provedor/operadorNo cliente
Riscos operacionaisRisco do provedor (mitigate: dual-provider)Risco de perda de acesso do jogador
CustoMargem de provimento + redeMais carga de suporte/CUT
Limites VIP/Conveniente (mala manual, private relay)Possível customização em AA

Conclusão: para regiões de massa e novatos - custody (ou híbrido). Para cripto-nativo/VIP - não-custody/AA complementar.

10) Temas especiais

10. 1 Lista branca e livro de endereços

Confirmar a propriedade do endereço + KYT → whitelist com TTL; rápido T + 0/T + 1 conclusões.

10. 2 Redes e bicos

Mantenha o USDT/TRON e o USDC/L2 como conjunto básico; redes de reserva (BSC/SOL).
Confirmações dinâmicas RBA (soma/segmento/carga).

10. 3 Incidentes e degradação

Rede de peregruzhena/fee↑ → routing automático em segundary; informar o ETA em UI.
KYT high-risk → hold, SoF, Travel Rule; um possível SAR.
O provedor não está disponível → o feedback está disponível para o lançamento manual de pagamentos críticos.

11) Dados e privacidade

Minimizar PII, tornear identificadores, armazenar separadamente do PAN/PIN/PAN-safe.
Criptografia em paz/trânsito, assinatura de webhooks.
Retenção: logs de soluções/malas de acordo com a lei (muitas vezes 5 + anos).
DSR/acesso: processos de emissão/correção/remoção de dados (quando aplicável).

12) Métricas e OKR

Approval Rate e Time-to-Finality p50/p95 (depósitos/conclusões).
KYT reject %/sanções hits/SAR-conversion.
A proporção de erros de rede/tag, a repetição de erros de endereço.
Costa per Approved por rede/ativo/modelo, proporção de conclusões batch.
Provedores uptime, atrasos de webhooks, número de carros-switch-over.

13) Anti-pattern

«Aceitamos em qualquer rede» sem validação → perda.
Um provedor castodial sem reserva → SPOF.
Armazenamento de chaves sem HSM/KMS/multisig e limites.
Não há KYT/Travel Rule para unhosted («pequenas quantias - é possível») → bloquear.
Falta de idimpotência/anti-duplicação → duplos cancelamentos/inscrições.
Seed-UX sem alternativas (passkeys/recovery social) → churn alto e tíquetes.

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

  • Selecionar um modelo: custody, não-custody ou híbrido por segmento.
  • Segurança chave: HSM/KMS, MRS/multisig, limites, 4-olhos.
  • Redes/ativos: primary/segundary, confirmações dinâmicas, mmo/tags-validador.
  • KYT/sanções/Travel Rule, política unhosted (assinatura de endereço, whitelist).
  • Treasury: Conversão T0, RFQ/Multiplicy, pool de liquidez em 2 + redes.
  • Accounting/Recon: lager, 'invoice/withdrawal ↔ txid ↔ subaccount', fontes de cursos.
  • Idempotidade, anti-duplos, retraí com backoff + jitter; webhooks assinados.
  • UX: seedless/passkeys/AA, QR/deplink, ETA e comissões transparentes.
  • Playbooks de incidentes: rede/provedor/CUT, partital release/hold/SAR.
  • Métricas/alertas: AR, finalização, rejeitos KYT, farmácia, switch-over.

15) Resumos

As carteiras castodiais dão velocidade, SLA e «caixa» de complacência - ideal para o on-ramp/off-ramp em massa. Não-astodiais - controle e flexibilidade para o público cripto-nativo e VIP. A melhor opção para o iGaming é o híbrido: custody como default, self-custody/AA como complemento, além de disciplina de segurança (HSM/MPC/multisig), KYT/Travel Rule/RBA, contabilidade correta e UX (seedless/passkeys). Os trilhos de pagamento permanecem rápidos, seguros e lucrativos.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.