Como funciona KYC on-chain e whitelist para tokens…

Como funciona o KYC e a lista branca on-chain se resume a um movimento: transformar uma decisão de KYC/AML off-chain em elegibilidade on-chain, verificável por máquina, que contratos inteligentes podem impor no momento da transferência ou acesso. A escolha de design não é "KYC ou sem KYC", mas onde o portão está na pilha e se as regras vivem dentro do token ou em módulos de conformidade atualizáveis.

Principais Conclusões

• Verificações de KYC/AML geralmente acontecem off-chain com provedores regulamentados, enquanto a camada on-chain armazena um resultado verificável de "elegível/não elegível + atributos" como reivindicações ligadas a uma identidade on-chain.
• ERC-3643torna a conformidade uma primitiva de transferência: o token verifica um Registro de Identidade e um Módulo de Conformidade, e a transação reverte se qualquer verificação falhar.
• A lista branca pode ser aplicada em múltiplas camadas além do contrato do token, incluindo ponte, RPC e consenso, com um claro trade-off entre controle e abertura.
• O plano de controle operacional é tipicamente o Registro de Identidade mais o Módulo de Conformidade, que concentra o risco de atualização e chave de administrador nesses contratos.

Onde o KYC on-chain se encaixa no cripto

Cadeias sem permissão permitem que qualquerendereçoreceber e enviarativos, que é exatamente o que emissores regulamentados não podem permitir para muitostítulos tokenizadose outros instrumentos restritos. A restrição não é filosófica. É mecânica: se um ativo deve ser mantido apenas por investidores elegíveis, o sistema precisa de uma maneira de impedir uma transferência antes que ela seja concluída na blockchain.

É aí que "conformidade por código" aparece. A frase on chain kyc é mal interpretada como "colocar documentos de identidade naEthereum." A arquitetura comum nas fontes é o oposto. As verificações de KYC e AML ainda acontecem off-chain com provedores regulamentados, enquanto a blockchain mantém o mínimo necessário para tornar a elegibilidade verificável por máquina no momento da transação.

A descrição da ONINO é explícita: o resultado da verificação off-chain é representado na blockchain como reivindicações criptográficas armazenadas na conta de um investidor.ONCHAINID e depois ler durante as transferências.

A lista branca é a regra de aplicação que consome essas reivindicações. Uma lista de tokens pode ser tão simples quanto um mapeamento de endereços aprovados, mas os designs modernos tratam “quem é permitido” como uma questão de identidade, não uma questão de endereço.

Essa é a diferença entre um modelo de carteira com permissão (este endereço é permitido) e um modelo vinculado à identidade (este endereço está vinculado a uma identidade elegível). Na abordagem vinculada à identidade, um endereço pode rotacionar enquanto a elegibilidade permanece ligada ao registro de identidade.

O outro termo que importa é endereço bloqueado.Nesses sistemas, um endereço bloqueado não é um rótulo social. É um endereço que falha em verificações de elegibilidade, então transferências para ele são revertidas, ou ele é negado acesso em algum outro ponto da pilha.

O mecanismo central por trás da lista branca

Duas alavancas impulsionam todo o sistema, e a maioria das explicações as mistura.

A primeira alavanca é a representação de identidade e elegibilidade. As fontes descrevem ONCHAINID como a camada de identidade on-chain usada com ERC-3643, com reivindicações ou credenciais emitidas por partes confiáveis ou autorizadas. AI CERTs destaca o padrão de privacidade: dados sensíveis permanecem off-chain, enquanto assinaturas ou reivindicações são mantidas on-chain. Essa divisão é o ponto.

A cadeia não precisa de uma digitalização de passaporte. Ela precisa de uma declaração verificável como “KYC aprovado” ou “jurisdição = UE”, assinada por um emissor em quem o sistema confia.

A segunda alavanca é a aplicação de regras. Uma vez que a elegibilidade é representada on-chain, algo ainda precisa aplicá-la. A aplicação pode existir dentro de um contrato de token, dentro de um aplicativo, ou mais acima na pilha. No nível do token, a aplicação significa que o token se recusa a se mover a menos que ambos os lados sejam elegíveis e a transferência satisfaça a lógica da regra. É aí que está o token na lista brancaa ideia se torna concreta: o token em si se torna o portão.

Um fluxo genérico se parece com isso:

1. O provedor off-chain verifica um usuário e decide quais atributos ele possui (KYC aprovado, acreditação, jurisdição). 2. Um emissor confiável escreve esses atributos on-chain como reivindicações ligadas a uma identidade on-chain. 3. Um registroligaum ou mais endereços de carteira a essa identidade e responde “este endereço é elegível agora?” 4. Um token ou aplicativo verifica o registro e qualquer mecanismo de regras durante uma transação. 5. Se uma verificação falhar, a transação reverte, de modo que o estado não muda e a transferência não se concretiza.

A saída não é “KYC on-chain.” A saída é um sim/não determinístico no momento da transferência, além de um registro de auditoria do que os contratos impuseram.

Como o ERC-3643 impõe KYC nas transferências

O ERC-3643 é posicionado em sua documentação como um conjunto de contratos inteligentes de código aberto para emissão, gerenciamento e transferência de tokens com permissão, com uma estrutura de identidade descentralizada embutida para que apenas usuários elegíveis possam se tornar detentores de tokens em blockchains sem permissão.

Ele também traça uma linha clara em relação ao ERC-20: o ERC-3643 verifica identidade e elegibilidade antes de permitir transferências, apoiando requisitos de conformidade como KYC e AML.

A arquitetura ERC-3643/T-REX da ONINO divide o sistema em quatro componentes conectados: identidades on-chain, um registro de identidade, módulos de conformidade plugáveis e o contrato do token. Essa decomposição é importante porque mostra onde as equipes realmente operam o sistema dia a dia.

A árvore de decisão de transferência descrita pela ONINO é simples e brutal, e é por isso que funciona:

1. Uma transferência é iniciada no contrato do token. 2. O token verifica o Registro de Identidade para a verificação do remetente e do receptor. 3. O token verifica um Módulo de Conformidade para violações de regras. 4. Se qualquer uma das verificações falhar, a transação reverte. Se ambas passarem, a transferência é executada.

Esta é a principal vantagem prática em relação a listas brancas ad-hoc. Um token com permissão construído sobre o erc 3643 não "tenta o seu melhor" e reconcilia depois. A cadeia aceita a transferência sob as regras ou não aceita.

O Módulo de Conformidade é onde a aplicação das regras se torna modular. A ONINO lista exemplos que podem ser codificados lá: limites de investidores, restrições jurisdicionais, períodos de bloqueio e limites de detentores. A ONINO também afirma que as regras podem ser atualizadas sem a necessidade de reimplantar o token, pois a lógica de conformidade é separada do contrato do token. Essa separação é o desbloqueio operacional e também é onde o risco de governança e atualização se concentra.

Nos mercados tradicionais, um agente de transferência é a parte que mantém o registro oficial de propriedade e processa certos eventos do ciclo de vida. Pilhas no estilo ERC-3643 são uma tentativa de codificar partes dessa função em contratos e papéis de agentes, para que o próprio token possa impor quem pode manter e transferir.

Outros lugares onde o KYC pode ser aplicado

O guia de DeFi com permissão da Conduit enquadra "onde você restringe" como uma escolha de pilha, não uma escolha de padrão de token. Ele descreve quatro camadas de infraestrutura onde a permissão pode ser implementada, classificadas da menos à mais impactante na abertura e descentralização de uma cadeia: protocolo, ponte, RPC e consenso.

A restrição em nível de protocolo é a mais direcionada. O exemplo da Conduit é a lista branca por ativo, apontando para padrões de token como o ERC-3643 que podem impor quem pode manter e transferir um token. É aqui que um token com permissão pode impedir transferências secundárias para detentores inelegíveis porque o próprio token se recusa a se mover.

A restrição em nível de ponte é controle de perímetro. A Conduit descreve a restrição de KYC em nível de ponte como uma forma de decidir quem pode entrar em um ecossistema. Isso pode impedir que carteiras não verificadas tragam ativos para uma cadeia, mas não para automaticamente impedir transferências dentro do ecossistema, a menos que os ativos em si também sejam permitidos.

A restrição em nível de RPC molda o caminho padrão do usuário. A Conduit dá exemplos como restrições geográficas ou fluxos de aprovação de transações em pontos finais de RPC oficiais. Esses controles podem ser atualizados como política e podem ser contornados por usuários que executam seus próprios nós em muitas redes. Isso torna a restrição de RPC útil para a postura de conformidade, mas mais fraca como uma garantia sólida.

O controle em nível de consenso é o mais forte e invasivo. O Conduit descreve isso como a definição de políticas de inclusão de transações no nível do sequenciador ou do conjunto de validadores. Ele fornece a aplicação mais profunda porque cada transação está sujeita à regra, e também tem o maior impacto na abertura.

A implicação de design é direta: a aplicação em nível de token é sobre controlar a posse e a transferência de um ativo específico, enquanto os controles de ponte e RPC são sobre controlar caminhos de entrada e acesso.

Compromissos práticos e modos de falha

O primeiro compromisso é controle operacional versus risco de atualização. A estrutura modular de conformidade da ONINO é atraente porque as regras podem mudar sem a necessidade de redistribuir o token. O custo é que o Módulo de Conformidade e o Registro de Identidade se tornam o plano de controle. Chaves administrativas, permissões de atualização e escopo de auditoria se agrupam ali, não na superfície semelhante ao ERC-20 do token.

O segundo compromisso é a experiência do usuário. A aplicação se apresenta aos usuários como transações revertidas, não como um aviso educado. Se um receptor não for elegível, a transferência falha e o gás ainda é gasto. Sistemas que não fornecem verificações prévias claras e razões de falha legíveis transformam a conformidade em tickets de suporte.

O terceiro compromisso é o que realmente significa "lista branca". Uma lista de endereços estática é frágil porque os endereços rotacionam, as configurações de custódia mudam e as instituições usam várias carteiras. Modelos vinculados à identidade reduzem essa fragilidade, mas introduzem dependências em registros e emissores confiáveis.

O quarto compromisso é a postura de descentralização. A classificação de camadas do Conduit é um modelo mental útil: o controle de protocolo é estreito e compostável, enquanto o controle de consenso é amplo e coercitivo. Equipes que afirmam "conformidade descentralizada" sem nomear onde a aplicação se encontra geralmente estão escondendo o verdadeiro ponto de controle.

Os modos de falha seguem a arquitetura. Se o Registro de Identidade estiver errado, usuários elegíveis são tratados como um endereço bloqueado. Se o Módulo de Conformidade estiver mal configurado, transferências que deveriam ser concluídas são revertidas. Se a governança em torno das atualizações for descuidada, as regras podem mudar mais rápido do que as contrapartes esperam.

É por isso que a conformidade por código não é apenas uma história legal. É uma história de design de sistemas com pontos de estrangulamento muito específicos.

Fontes

• Documentação ERC-3643
• ONINO)
• CERTs de IA
• Conduit