A prática mais comum de conformidade on-chain hoje é a lista de permissões: a equipe do projeto cobra uma rodada de documentos de KYC, e os endereços aprovados são registrados em um contrato. O problema é que o usuário precisa enviar novamente as informações de identidade para cada protocolo — passaporte, endereço e data de nascimento ficam dispersos e armazenados nos servidores de vários times; qualquer vazamento em um ponto é irreversível. Isso não é um design de segurança; é apenas a simples cópia do fluxo tradicional para a blockchain.
@Dusk_Foundation da Citadel segue outro caminho: separar a verificação da identidade da divulgação da identidade. O usuário conclui uma única verificação em uma instituição licenciada e, depois, usa prova de conhecimento zero para mostrar a diferentes aplicações a conclusão de que "cumpro os requisitos", sem precisar entregar os dados subjacentes. O protocolo recebe um resultado verificável de julgamento, e não uma ficha de dados que pode ser indevidamente extraída e usada a qualquer momento.
Essa diferença é crucial em cenários regulados. Um produto tokenizado voltado a investidores qualificados, por lei, precisa confirmar a elegibilidade do comprador, mas tecnicamente não precisa saber quem é o comprador. Finanças tradicionais unem essas duas coisas porque, no passado, não havia outras alternativas; não porque logicamente fosse necessário.
Um ponto ainda mais prático é a revogabilidade. A elegibilidade nunca é permanente — o investidor pode mudar a residência fiscal, perder a condição de qualificado ou ser incluído em uma lista restrita. Um sistema de identidade on-chain realmente utilizável precisa permitir expiração e revogação de credenciais; caso contrário, é apenas trocar uma lista branca desatualizada por um nome mais moderno.
Colocar essa capacidade na camada de protocolo, em vez de fazer cada aplicação construir seu próprio conjunto, significa que o emissor não precisa assumir a responsabilidade de custódia de dados sensíveis. Para equipes de conformidade, manter menos dados pessoais por si só já reduz o risco — e isso é especialmente real no contexto do GDPR.
No nível do token, a DUSK assume as funções de Gas da rede e Staking, e os incentivos econômicos do verificador ficam diretamente ligados à segurança da rede. Mas o valor da camada de identidade não está na narrativa do token; está em quanto os emissores realmente estão dispostos a migrar seus processos de conformidade.
O que mais me interessa são os detalhes de implementação: quem emite as credenciais, se as autoridades reguladoras reconhecem esse formato de prova e se o processo de apresentação é suficientemente simples para usuários comuns. Depois que essas questões forem resolvidas, a conformidade on-chain deixa de ser apenas uma demonstração e passa a ser utilizável.
@Dusk_Foundation $DUSK #dusk
@Dusk_Foundation da Citadel segue outro caminho: separar a verificação da identidade da divulgação da identidade. O usuário conclui uma única verificação em uma instituição licenciada e, depois, usa prova de conhecimento zero para mostrar a diferentes aplicações a conclusão de que "cumpro os requisitos", sem precisar entregar os dados subjacentes. O protocolo recebe um resultado verificável de julgamento, e não uma ficha de dados que pode ser indevidamente extraída e usada a qualquer momento.
Essa diferença é crucial em cenários regulados. Um produto tokenizado voltado a investidores qualificados, por lei, precisa confirmar a elegibilidade do comprador, mas tecnicamente não precisa saber quem é o comprador. Finanças tradicionais unem essas duas coisas porque, no passado, não havia outras alternativas; não porque logicamente fosse necessário.
Um ponto ainda mais prático é a revogabilidade. A elegibilidade nunca é permanente — o investidor pode mudar a residência fiscal, perder a condição de qualificado ou ser incluído em uma lista restrita. Um sistema de identidade on-chain realmente utilizável precisa permitir expiração e revogação de credenciais; caso contrário, é apenas trocar uma lista branca desatualizada por um nome mais moderno.
Colocar essa capacidade na camada de protocolo, em vez de fazer cada aplicação construir seu próprio conjunto, significa que o emissor não precisa assumir a responsabilidade de custódia de dados sensíveis. Para equipes de conformidade, manter menos dados pessoais por si só já reduz o risco — e isso é especialmente real no contexto do GDPR.
No nível do token, a DUSK assume as funções de Gas da rede e Staking, e os incentivos econômicos do verificador ficam diretamente ligados à segurança da rede. Mas o valor da camada de identidade não está na narrativa do token; está em quanto os emissores realmente estão dispostos a migrar seus processos de conformidade.
O que mais me interessa são os detalhes de implementação: quem emite as credenciais, se as autoridades reguladoras reconhecem esse formato de prova e se o processo de apresentação é suficientemente simples para usuários comuns. Depois que essas questões forem resolvidas, a conformidade on-chain deixa de ser apenas uma demonstração e passa a ser utilizável.
@Dusk_Foundation $DUSK #dusk