Padrão de tokens regulados na EVM: a ERC-1450 trata da emissão, a ERC-3643 trata da conformidade de identidade e a ERC-7943 trata da integração.
Escrito por: @JayLovesPotato, Four Pillars
Tradução: AididiaoJP, Foresight News
Pontos principais
O padrão de token regulado na EVM não seguiu para uma única especificação unificada; em vez disso, fez uma divisão clara por função. Por isso, a ERC-1450, a ERC-3643 e a ERC-7943 não devem ser entendidas como padrões concorrentes entre si. Devem ser vistas como componentes complementares que, respectivamente, cuidam da emissão, conformidade de identidade, execução e integração.
Obs.: em termos simples, o padrão de tokens regulados é uma especificação técnica criada especialmente para “tokens regulados”. Tokens comuns (por exemplo, um ERC-20 comum) podem ser transferidos e mantidos livremente, com quase nenhuma restrição. Já tokens regulados (Regulated Token) são diferentes: geralmente correspondem a ativos do mundo real que estão sob supervisão, como valores mobiliários, cotas de fundos, títulos e RWA (ativos do mundo real). Assim, o token deixa de ser algo que “qualquer um pode transferir livremente” e passa a seguir regras técnicas que “atendem às exigências de regulamentação financeira”.
As diferenças-chave entre cadeias não estão em ter ou não funções de conformidade, mas sim em onde essas funções são implementadas e executadas. No nível de um contrato de ativo único, o EVM mantém alta flexibilidade; cadeias como Solana e aquelas baseadas em Move colocam mais funcionalidades em estruturas compartilhadas de tokens; Stellar e XRPL incorporam diretamente no livro-razão; Canton e Avalanche L1 ainda estendem isso para as camadas de operação de mercado e de rede.
A competitividade dos padrões de tokens regulados, no futuro, provavelmente dependerá mais da flexibilidade para se adaptar a mudanças regulatórias do que do número de funcionalidades. A direção mais pragmática é construir uma pilha de conformidade: padronizar funções de execução recorrentes como congelamento, transferência forçada e validação antes da transferência; e decompor políticas específicas do produto—como provedores de identidade, regras de jurisdição, limites máximos de posse—em módulos substituíveis.
Mesmo no ambiente EVM de Ethereum mais familiar para instituições, existem múltiplos ERCs que atendem a necessidades semelhantes para resolver tokens com finalidade regulatória. Eles geralmente suportam limites de transferência, verificações de elegibilidade de investidores, congelamento, transferências forçadas e recuperação de ativos perdidos. Mas as estruturas legais assumidas e as permissões operacionais de cada padrão diferem significativamente.
Além do EVM, outras cadeias também adicionam funções comparáveis aos programas de token, ao livro-razão ou à camada de rede, ampliando ainda mais as rotas de implementação para ativos regulados.
Isso reflete, em certa medida, que ainda não surgiu uma estrutura clara para os padrões de tokens regulados. A razão mais fundamental é que as funções necessárias para ativos regulados são difíceis de encaixar em uma única especificação. Quem mantém o registro legal dos títulos, qual instituição certifica a elegibilidade dos investidores, e quanta autoridade de controle o operador deve manter quando ocorre um incidente—essas questões variam conforme o produto e a jurisdição.
Assim, o mercado está caminhando para uma arquitetura: essas funcionalidades ficam distribuídas em múltiplas camadas e são combinadas sob demanda, em vez de buscar um único padrão totalmente auto-suficiente.
Padrões de tokens regulados no EVM
Os padrões iniciais tentavam, em sua maioria, copiar diretamente para contratos de tokens as estruturas operacionais das finanças tradicionais. No ERC-1450, o Registered Transfer Agent (Agente de Transferência Registrado), além de lidar com emissão e resgate, executa cada transferência; usuários comuns são impedidos de chamar transfer e approve. Isso deixa claro quem mantém o registro legal e quem deve responder a ordens judiciais ou recuperar chaves perdidas. Ao mesmo tempo, ele se afasta bastante do fluxo de ativos sem permissão presumido pelos DEXs e protocolos de empréstimo tradicionais.
O ERC-3643 distribui as funções de conformidade em contratos de token, Identity Registry, Trusted Issuers Registry e módulos de conformidade independentes, em vez de concentrá-las sob uma única autoridade. A transferência é validada com base em declarações emitidas por entidades confiáveis, incluindo status de KYC, local de residência e elegibilidade de investidor qualificado; o emissor também pode adicionar regras como número de investidores e limites máximos de detenção por país. Mantendo a estrutura base do ERC-20, a capacidade de substituir regras individuais é uma vantagem relevante. O custo é a sobrecarga operacional de coordenar múltiplos contratos, emissores de identidade e papéis de administração de privilégios.
O ERC-7943 mais recente segue um caminho diferente: ele não define a política de conformidade em si, mas expõe um conjunto de interfaces genéricas, incluindo canSend, canReceive, canTransfer, consulta de saldo congelado e funções de transferência forçada. Isso permite que carteiras, exchanges, custodiante e serviços DeFi interajam com diferentes ativos regulados de maneira consistente. Em outras palavras, o ERC-3643 é uma pilha para criar tokens regulados, enquanto o ERC-7943 se aproxima de uma camada de integração que conecta várias pilhas. Implementações recentes do CMTAT adicionaram suporte ao ERC-7943, reforçando que essa interface mínima pode ser sobreposta aos padrões de emissão existentes.
ERC-7518 e ERC-8047, por outro lado, atendem a necessidades mais específicas. O ERC-7518 aplica diferentes classes de ações, jurisdições e condições de período de bloqueio a uma única partição ERC-1155; o ERC-8047 registra a linhagem pai-filho quando o ativo circula, permitindo que a execução se concentre em fluxos de fundos específicos, e não na conta inteira. O primeiro torna mais clara a diferenciação de direitos dentro de um único ativo; o segundo permite rastreamento e execução posteriores mais precisos. É mais provável que atuem como módulos complementares de uma pilha de conformidade mais ampla, em vez de substituírem o padrão universal do ERC-3643.
Onde outras cadeias colocam as funções de conformidade
A abordagem da Solana se caracteriza por colocar funcionalidades repetitivas de tokens em uma camada compartilhada mais abaixo. Funções como Transfer Hook, Permanent Delegate e Confidential Transfer são fornecidas por uma biblioteca de Token Extensions genérica, enquanto o Solana Attestation Service permite que aplicações reutilizem informações fora da cadeia, como status de KYC, localização geográfica e elegibilidade de investidores. Isso reduz a necessidade de cada emissor reconstruir e auditar funções idênticas de forma independente. Ainda assim, quando uma carteira ou protocolo não suporta alguma extensão, a integração pode se fragmentar; além disso, para ativos configurados com Permanent Delegate (um controle forte por parte do emissor), aplicações DeFi precisam tratá-los como mais uma camada de risco contra a parte.
Stellar e XRPL expõem autorização, congelamento e recuperação como atributos nativos do ativo no livro-razão. Esses controles são aplicados de forma consistente nas funções de transferência e nas transações nativas, de modo que as aplicações não precisam reinterpretar lógica personalizada para cada contrato de token. O Stellar está expandindo a conexão entre ativos do livro-razão e ambientes de smart contracts por meio de Stellar Asset Contracts; o XRPL, por sua vez, gira em torno do MPT, evoluindo de posse licenciada, congelamento e recuperação para funcionalidades relacionadas à privacidade. No entanto, quanto mais profundas as regras ficam embutidas no livro-razão, mais a evolução depende de upgrades de rede e de consenso. As configurações de controle também podem restringir de modo mais direto a liquidez e o escopo de uso dos ativos.
Sui e Aptos ficam entre o modelo centrado em contratos do EVM e o modelo nativo do livro-razão. No Sui, o Currency Registry registra o estado da lista de rejeição de ativos regulados e a permissão global de pausa; já o Aptos congela contas por meio do framework de Fungible Asset usando TransferRef, ou, quando necessário, contorna essas restrições com transferências privilegiadas. Funções recorrentes de execução, como bloqueio de endereços e pausa emergencial, são fornecidas pelo framework; políticas mais complexas, como classificação de investidores e limites máximos de detenção específicos por país, ficam para módulos Move independentes. Nesse ponto, a arquitetura delas se aproxima do rumo modular que o próprio ecossistema EVM está seguindo.
Canton estende o escopo da conformidade do token para a operação de todo o mercado. O CIP-56 não só padroniza transferências de saldo, como também inclui divulgação de informações de partes específicas, aprovação do destinatário e entrega versus pagamento atômica (DvP); o Token Standard V2 está sendo testado em um DevNet independente em 2026. Esse desenho oferece maior consistência operacional e privacidade, mas requer identidades dedicadas e ambientes de desenvolvimento. Por isso, a liquidez e as aplicações da blockchain pública existente não podem ser migradas simplesmente.
O Avalanche L1 é mais adequado para ser entendido como uma opção para construir o próprio mercado regulado, e não apenas para emitir tokens regulados. Operadores podem restringir participantes de transações e implantadores de contratos usando uma white list, ao mesmo tempo em que exigem que validadores atendam a condições de KYC, AML ou licenciamento. Essa pilha também pode conectar provedores de identidade como Jumio e Keyring ao txAllowlist, o que é ideal para exchanges ou redes de pagamento apenas institucionais. O custo está na camada operacional: validadores, upgrades, pontes cross-chain e liquidez precisam ser geridos de forma independente, com custos e fragmentação bem maiores do que ao emitir um único token em redes EVM existentes.
Separar funções de execução genéricas das políticas de conformidade
Em conjunto, essas abordagens indicam que ambos os extremos têm limitações claras: seja ao embutir toda a pilha regulatória na rede, seja ao deixar todas as funcionalidades para um único ERC. As funcionalidades de execução genéricas que tendem a reaparecer em muitos ativos regulados—validação antes da transferência, congelamento, transferência forçada, pausa emergencial e metadados que divulgam as permissões de gerenciamento e os riscos associados—são mais bem colocadas próximas ao arcabouço do token, do livro-razão ou de interfaces mínimas como a do ERC-7943. Isso reduz diferenças de implementação entre emissores e custos de auditoria, além de permitir que carteiras, exchanges e custodiante identifiquem de forma consistente a estrutura de controle dos ativos.
Em contraste, decisões como em quais provedores de identidade confiar, quais jurisdições permitir, como calcular limites máximos de posse e períodos de bloqueio no nível do investidor, e quem pode executar ordens legais—são mais adequadas para ficarem a cargo do ERC específico do ativo ou de módulos independentes. Essas regras variam conforme o produto e a jurisdição, e precisam ser atualizadas à medida que a legislação muda. Se forem codificadas de forma rígida nas regras-base da rede, além de atrasar upgrades, também podem transformar escolhas de política de um mercado financeiro específico em configurações padrão de uma cadeia genérica.
Em outras palavras, o mercado de tokens regulados tem mais probabilidade de evoluir na forma de uma pilha de conformidade do que convergir para um único padrão. Nesse modelo, identidades substituíveis, jurisdições e regras específicas do produto seriam construídas sobre funções de execução genéricas. Ethereum e, de forma mais ampla, o ecossistema EVM ainda têm vantagens em flexibilidade de políticas e acesso à liquidez existente; cadeias nativas de livros-razão são mais fortes em consistência de execução e simplicidade operacional; e redes dedicadas como Canton destacam-se mais em privacidade e fluxos de trabalho institucionais.
Portanto, a adoção provavelmente não será determinada pelo conjunto de funcionalidades de qual padrão é o mais longo. Mais importante é se as políticas de conformidade conseguem mudar sem precisar reemitir os ativos e sem forçar carteiras, exchanges e custodiante a reconstruírem a integração do zero. Outro teste fundamental é: participantes externos conseguem identificar claramente, avaliar e gerenciar os poderosos controles embutidos nos ativos?