Quem já passou por auditorias de conformidade tem uma sensação em comum: o que mais assusta não é a auditoria em si, mas ter de provar que o cliente não infringiu nada — sem, ao mesmo tempo, expor toda a privacidade do cliente. O método tradicional usa comprovantes de fluxo bancário, de identidade e de endereço; depois da auditoria, ainda é preciso arquivar tudo. Cada registro arquivado vira um risco.
Por isso, quando vejo iniciativas como a Dusk, que usam o “cartão” de “privacidade e conformidade”, minha primeira reação é entender como ela lida com essa contradição. A camada de identidade da Citadel segue a via de divulgação seletiva: o usuário mantém credenciais emitidas por uma instituição. Na hora da transação, usa provas de conhecimento zero — uma ferramenta criptográfica que não revela informações específicas, mas consegue provar que “atendo aos requisitos”. Comprova que a condição foi cumprida, sem entregar os documentos originais. A Moonlight lida com transferências comuns ao nível da conta pública; a Phoenix usa privacidade via UTXO, um modelo semelhante às saídas de transações não gastas do Bitcoin. Cada transação fica isolada, sem expor saldos; trata transações sensíveis. E são dois caminhos distintos. @Dusk
Para ativos sob regulação, essa lógica funciona: a transferência de ativos precisa de verificação de conformidade e, ao mesmo tempo, de proteção de privacidade; não dá para abrir mão de KYC por causa da privacidade.
Não vou “embelezar” isso. A raiz de confiança da Citadel está embutida no emissor: quem tem credenciais para emitir, como as credenciais são revogadas, e se credenciais antigas continuam válidas quando a instituição sai do ar — isso não se resolve com criptografia, é um problema de governança. Vire a página dos documentos: os detalhes do mecanismo de revogação estão um pouco fracos. Jurisdições diferentes também são um problema: a definição de investidor qualificado na União Europeia não é igual à dos Estados Unidos, então as credenciais não podem ser reaproveitadas diretamente. Em abril de 2026, uma vulnerabilidade num cofre de senhas foi corrigida, mas ainda fica a pergunta: existem outros problemas?
O ecossistema também é fraco. O GitHub atualiza devagar, há poucos aplicativos de terceiros e a documentação não é amigável para iniciantes. A direção técnica está certa, mas ninguém construiu a casa; uma boa fundação também é só terreno.
Minha visão: a Dusk enfrentou o desafio técnico de “conformidade e privacidade ao mesmo tempo”, e a direção está correta. O resto é tudo negociação comercial e comunicação com reguladores — e isso costuma ser bem mais lento do que escrever código.
Como convencer uma instituição licenciada a desistir da sua “fortaleza” de dados de clientes? #dusk $DUSK
Por isso, quando vejo iniciativas como a Dusk, que usam o “cartão” de “privacidade e conformidade”, minha primeira reação é entender como ela lida com essa contradição. A camada de identidade da Citadel segue a via de divulgação seletiva: o usuário mantém credenciais emitidas por uma instituição. Na hora da transação, usa provas de conhecimento zero — uma ferramenta criptográfica que não revela informações específicas, mas consegue provar que “atendo aos requisitos”. Comprova que a condição foi cumprida, sem entregar os documentos originais. A Moonlight lida com transferências comuns ao nível da conta pública; a Phoenix usa privacidade via UTXO, um modelo semelhante às saídas de transações não gastas do Bitcoin. Cada transação fica isolada, sem expor saldos; trata transações sensíveis. E são dois caminhos distintos. @Dusk
Para ativos sob regulação, essa lógica funciona: a transferência de ativos precisa de verificação de conformidade e, ao mesmo tempo, de proteção de privacidade; não dá para abrir mão de KYC por causa da privacidade.
Não vou “embelezar” isso. A raiz de confiança da Citadel está embutida no emissor: quem tem credenciais para emitir, como as credenciais são revogadas, e se credenciais antigas continuam válidas quando a instituição sai do ar — isso não se resolve com criptografia, é um problema de governança. Vire a página dos documentos: os detalhes do mecanismo de revogação estão um pouco fracos. Jurisdições diferentes também são um problema: a definição de investidor qualificado na União Europeia não é igual à dos Estados Unidos, então as credenciais não podem ser reaproveitadas diretamente. Em abril de 2026, uma vulnerabilidade num cofre de senhas foi corrigida, mas ainda fica a pergunta: existem outros problemas?
O ecossistema também é fraco. O GitHub atualiza devagar, há poucos aplicativos de terceiros e a documentação não é amigável para iniciantes. A direção técnica está certa, mas ninguém construiu a casa; uma boa fundação também é só terreno.
Minha visão: a Dusk enfrentou o desafio técnico de “conformidade e privacidade ao mesmo tempo”, e a direção está correta. O resto é tudo negociação comercial e comunicação com reguladores — e isso costuma ser bem mais lento do que escrever código.
Como convencer uma instituição licenciada a desistir da sua “fortaleza” de dados de clientes? #dusk $DUSK