Wallets, exchanges e custódia: quais evidências técnicas importam em um litígio envolvendo criptoativos?

Em criptoativos, “quem tinha a wallet?” quase nunca é pergunta suficiente: a resposta depende da arquitetura de custódia, das credenciais, dos fluxos de aprovação e dos registros on-chain e off-chain.

Em uma frase

Controle criptográfico, controle operacional e titularidade não são a mesma coisa — e cada um deixa evidências diferentes.

Resumo executivo

Disputas envolvendo criptoativos frequentemente usam a palavra “wallet” como se ela descrevesse um único objeto técnico. Na prática, uma wallet pode ser software autocustodial, hardware wallet, conta custodial em exchange, multisig, MPC, smart contract ou infraestrutura institucional. Cada arquitetura distribui controle, autenticação e responsabilidade de forma diferente. Este artigo mostra quais evidências são relevantes para reconstruir uma movimentação, como distinguir posse de credencial, controle operacional e custódia jurídica, e por que a análise deve integrar dados on-chain, logs de autenticação, políticas de chaves e trilhas internas da plataforma.

Palavras-chave: wallet; exchange; custódia; MPC; multisig; criptoativos; evidência digital.

1. A primeira pergunta é: que tipo de “wallet” estamos analisando?

Uma wallet não “guarda moedas” no sentido físico. Em termos simplificados, ela gerencia ou viabiliza o uso de credenciais capazes de autorizar operações sobre ativos registrados em uma blockchain.

Mas as arquiteturas variam:

• self-custody software wallet:

  a chave ou seed é controlada pelo usuário;

• hardware wallet:

  a chave privada é mantida em dispositivo dedicado;

• custodial exchange account:

  a plataforma controla a infraestrutura de chaves e mantém um ledger interno de clientes;

• multisig:

  várias chaves podem ser necessárias para autorizar uma operação;

• MPC:

  a capacidade de assinatura é distribuída entre partes ou componentes sem reconstruir necessariamente uma chave privada única;

• smart contract wallet:

  regras de autorização são implementadas em contrato;

• institutional custody:

  políticas de aprovação, HSMs, segregação de funções e múltiplas camadas operacionais.

A palavra “wallet” sozinha, portanto, diz pouco sobre quem podia movimentar o ativo.

2. Controle criptográfico, controle operacional e titularidade são conceitos diferentes

Em perícia, é útil separar três dimensões:

Controle criptográfico: quem tinha capacidade de produzir a autorização exigida pela blockchain?

Controle operacional: quem podia acionar o processo, aprovar a retirada, redefinir credenciais ou instruir o custodiante?

Titularidade jurídica/econômica: quem tinha direito sobre os ativos segundo contrato e demais fatos?

Uma exchange custodial pode possuir controle criptográfico sobre uma hot wallet que contém fundos de milhares de clientes. O cliente, por sua vez, controla uma conta interna e instrui saques. Associar o endereço on-chain diretamente ao cliente seria tecnicamente incorreto sem compreender o ledger interno.

3. Em exchanges, o evento crítico pode ocorrer antes da blockchain

Uma operação em exchange frequentemente passa por:

1. login;

2. autenticação multifator;

3. criação de ordem ou solicitação de saque;

4. controles de risco;

5. aprovação interna;

6. atualização do ledger da plataforma;

7. agregação/batching;

8. assinatura e broadcast on-chain.

O hash da transação registra apenas a etapa pública final. Uma investigação sobre saque não autorizado deve reconstruir também o caminho interno.

Registros relevantes incluem:

• account ID;

• histórico de login;

• IP/porta/timestamp;

• dispositivos;

• MFA;

• mudança de senha;

• reset de 2FA;

• alteração de e-mail/telefone;

• criação ou alteração de whitelist;

• endereço de saque cadastrado;

• alertas de risco;

• aprovação manual;

• identificador interno do withdrawal;

• vínculo entre withdrawal e txid;

• ledger antes/depois;

• comunicação ao cliente;

• tickets de suporte.

4. Seed phrase e private key: evidência crítica, mas sensível

A posse de uma seed phrase ou private key pode demonstrar capacidade de controle de endereços derivados, mas a coleta deve ser realizada com cautela extrema.

Não é necessário — e pode ser contraproducente — reproduzir uma seed em laudo público. Uma metodologia adequada pode demonstrar controle por procedimentos de verificação que preservem segredo, documentando derivation path, endereços e provas criptográficas quando cabível.

Além disso, a seed pode ter sido copiada. O fato de duas pessoas terem acesso à mesma seed impede inferência simples de exclusividade.

5. Hardware wallets: assinatura local não elimina hipóteses de comprometimento

Hardware wallets reduzem a exposição da chave privada, mas a segurança da operação depende de mais elementos:

• firmware;

• supply chain;

• PIN;

• passphrase adicional;

• interface de confirmação;

• computador/telefone host;

• seed backup;

• verificação de endereço na tela confiável;

• processo de recuperação.

Em incidentes sofisticados, a assinatura legítima pode ocorrer sobre uma transação apresentada de forma enganosa ao usuário. Portanto, “assinada por hardware wallet” é uma informação importante, mas não responde sozinha à questão de consentimento informado.

6. Multisig: quem assinou e qual política estava ativa?

Em multisig, a análise deve identificar:

• esquema M-de-N;

• signers autorizados;

• chaves alteradas ao longo do tempo;

• contratos ou scripts;

• processo de coordenação;

• hardware/software utilizado;

• política institucional de aprovação;

• assinaturas efetivamente presentes.

Uma transação 2-de-3 demonstra que duas autorizações compatíveis foram produzidas. A investigação precisa depois atribuir cada chave e reconstruir se o processo corporativo foi respeitado.

7. MPC: não procure necessariamente uma “chave privada inteira”

Multi-Party Computation altera a forma tradicional de pensar custódia. Em determinadas arquiteturas, shares criptográficos permanecem separados e cooperam para gerar uma assinatura sem que uma única private key seja reconstruída em um ponto.

Por isso, perguntas periciais devem migrar de “onde estava a chave?” para:

• quais participantes/shares eram necessários?

• quais políticas de threshold estavam configuradas?

• como os shares eram protegidos?

• quais dispositivos ou serviços participaram?

• houve recovery/re-sharing?

• quais logs demonstram participação na assinatura?

• havia aprovação humana adicional?

A evidência pode estar distribuída por HSMs, serviços, aplicações e sistemas de workflow.

8. Proof of reserves não é prova completa de solvência ou titularidade

Provas de reservas ganharam relevância regulatória e de mercado. No Brasil, a regulamentação de 2026 prevê remessa de informações relacionadas a provas de reservas e staking para prestadoras de serviços de ativos virtuais em determinadas condições.[1]

Tecnicamente, demonstrar controle sobre certos endereços não prova sozinho:

• todas as obrigações da entidade;

• inexistência de passivos off-chain;

• segregação por cliente;

• ausência de empréstimos temporários;

• propriedade econômica integral dos ativos.

Uma análise de custódia deve relacionar reservas, liabilities, política contábil e controles internos.

9. Hot, warm e cold wallets: a classificação influencia o risco

Arquiteturas de custódia normalmente distribuem fundos conforme necessidade operacional.

Hot wallets priorizam disponibilidade e automação; cold storage reduz exposição online; estruturas intermediárias podem combinar controles.

Em uma disputa sobre incidente, importa saber:

• qual tier de wallet foi afetado;

• quem podia mover fundos;

• limites automáticos;

• política de rebalanceamento;

• alertas;

• HSM/MPC/multisig;

• segregação de funções;

• procedimento emergencial.

A causa de uma perda pode estar na blockchain, na aplicação, no processo operacional ou na governança de chaves.

10. Smart contract wallets e account abstraction

Wallets programáveis podem implementar social recovery, guardians, spending limits, session keys e múltiplas políticas.

Nesse cenário, “assinatura do endereço” pode não seguir o modelo simples de uma chave EOA. A perícia deve analisar:

• contrato da conta;

• versão de implementação;

• módulos instalados;

• guardian set;

• recovery events;

• session keys;

• bundlers/paymasters quando aplicáveis;

• eventos e estado do contrato no bloco relevante.

O código é parte da evidência.

11. Cadeia de custódia digital continua sendo necessária

Em ambientes de custódia, a cadeia de custódia da prova precisa alcançar também a interpretação dos sistemas internos. Um withdrawal ID, um ledger interno e uma transação on-chain podem pertencer ao mesmo fluxo, mas essa relação deve ser demonstrada por chaves de correlação, timestamps, documentação de arquitetura e procedimentos de extração. A ISO/IEC 27042 reforça que os processos analíticos devem ser documentados de forma suficiente para permitir escrutínio independente, validade, reprodutibilidade e repetibilidade.[9]

A blockchain preserva eventos públicos, mas logs internos, configurações, dumps de banco, arquivos de wallet e dispositivos continuam sujeitos a preservação forense.

A ISO/IEC 27037 recomenda práticas para identificação, coleta, aquisição e preservação de evidência digital.[2] O NIST SP 800-86 oferece estrutura para coleta, exame, análise e relato.[3]

No contexto de criptoativos, é importante registrar:

• fonte;

• data/hora;

• operador;

• ferramenta e versão;

• hash de arquivos;

• método de exportação;

• segredo excluído/redigido;

• relacionamento entre dado off-chain e txid on-chain.

12. Regulação aumenta a importância da arquitetura de controle

A Resolução BCB 520/2025 passou a disciplinar constituição e funcionamento de prestadoras de serviços de ativos virtuais no Brasil.[4] Normas de 2026 expandiram requisitos de autorização, reporte e tratamento prudencial.[1][5]

Internacionalmente, a FATF vem destacando custódia, unhosted wallets, stablecoins e DeFi como áreas de risco e supervisão.[6][7]

Para litígios, isso tende a tornar mais relevantes documentos de governança, segregação de funções, políticas de chaves, registros de custódia e controles internos.

A Instrução Normativa BCB nº 713/2026, por exemplo, disciplina remessas de informações relacionadas a provas de reservas, staking e custódia. Esses registros podem ampliar pontos de correlação, mas não devem ser confundidos, isoladamente, com prova de titularidade, autorização de uma operação específica ou solvência integral da entidade.[1]

13. Perguntas periciais úteis

• a arquitetura era custodial, self-custodial, multisig, MPC ou smart contract?

• quem controlava a autorização criptográfica?

• quem podia iniciar uma retirada?

• quais fatores de autenticação foram exigidos?

• houve mudança de credencial ou recovery?

• qual registro interno se relaciona à transação on-chain?

• houve batching com fundos de vários clientes?

• quais políticas de aprovação e limites existiam?

• a transação respeitou essas políticas?

• quais dados suportam a atribuição de determinada chave ou conta a uma pessoa?

14. Conclusão

Em criptoativos, “quem tinha a wallet?” quase nunca é pergunta suficiente. O trabalho técnico deve mapear arquitetura de custódia, controle criptográfico, workflow operacional e evidência on-chain/off-chain.

Uma transação válida pode demonstrar que as condições criptográficas foram satisfeitas. A responsabilidade por ela depende de como as credenciais eram governadas, quem podia acionar os fluxos e quais controles falharam ou foram contornados.

Quanto mais sofisticada a custódia, menos útil se torna procurar um único artefato mágico. A evidência está na correlação entre chaves, políticas, logs, dispositivos, aprovações e blockchain.

Referências

1. Banco Central do Brasil.

   Instrução Normativa BCB nº 713/2026 — informações relativas a provas de reservas, staking e custódia

   . https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?numero=713&tipo=Instru%C3%A7%C3%A3o+Normativa+BCB

2. ISO/IEC.

   ISO/IEC 27037:2012

   . https://www.iso.org/standard/44381.html

3. NIST.

   SP 800-86

   . https://doi.org/10.6028/NIST.SP.800-86

4. Banco Central do Brasil.

   Resolução BCB nº 520/2025

   . https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?numero=520&tipo=Resolu%C3%A7%C3%A3o+BCB

5. Banco Central do Brasil.

   Resolução BCB nº 580/2026

   . https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?numero=580&tipo=Resolu%C3%A7%C3%A3o+BCB

6. FATF.

   Targeted Report on Stablecoins and Unhosted Wallets

   . 2026. https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-stablecoins-unhosted-wallets.html

7. FATF.

   Targeted Report on Regulatory Challenges from Decentralised Finance

   . 2026. https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-decentralised-finance-2026.html

8. NIST.

   Blockchain Technology Overview — NISTIR 8202

   . https://doi.org/10.6028/NIST.IR.8202

9. ISO/IEC.

   ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence

   . https://www.iso.org/standard/44406.html

Nota editorial: custódia é um problema de arquitetura e governança de credenciais; a blockchain registra somente parte do processo operacional.