ERC 3643 e ERC 1400: comparando arquiteturas de tokens

A comparação entre ERC 3643 e ERC 1400 se resume a onde a decisão de conformidade "sim/não" reside: dentro do caminho de transferência do token onchain (ERC-3643) ou em um fluxo de autorização offchain (ERC-1400). Essa única escolha de design molda a interoperabilidade, o risco operacional e quão próximo um emissor chega da conformidade por código com a verdadeira liquidação T+0.

Principais Conclusões

• ERC-20 move valor de forma limpa, mas não pode impor nativamente a elegibilidade do investidor e restrições de transferência necessárias para ativos, que é o motivo pelo qual os padrões de token de segurança surgiram.
• ERC 3643 utiliza um modelo de validador automático onchain ligado a identidades e regras de oferta, mantendo o controle do emissor ou agente mesmo quando os investidores auto-custódia.
• erc 1400 valida transferências com uma chave específica gerada offchain e adiciona recursos de mercados de capitais, como partições e gerenciamento de documentos.
• Os padrões diferem menos em "recursos" do que na microestrutura de mercado: o gating onchain (ERC-3643) tende a se integrar como o ERC-20, enquanto a autorização offchain (ERC-1400) adiciona uma dependência crítica que cada local deve operacionalizar.

Por que os tokens de segurança precisam de padrões especiais

O ERC-20 resolveu um problema de distribuição para tokens do tipo portador: os saldos se movem de peer-to-peer com uma única chamada de transferência onchain. Isso quebra no momento em que o ativo é regulamentado.

Um token de segurança representa umativo do mundo real como patrimônio, dívida, um interesse em fundo, ouimóveis tokenizados, e as transferências não são apenas “o remetente tem saldo?” Elas são “o destinatário é elegível, nesta jurisdição, sob as regras desta oferta, agora?” A Tokeny enquadra a lacuna diretamente: o ERC-20 permite transferências básicas, mas não impõe regras de transferência e regulamentos de conformidade que existem nos mercados de capitais.

Essa lacuna é onde a conformidade por código começa a parecer menos uma característica e mais como a infraestrutura do mercado. Se a elegibilidade não for aplicada no nível do token, ela é empurrada para processos manuais, controles de corretores ou regras específicas de locais. O resultado é uma liquidação fragmentada e etapas operacionais extras que se assemelham ao pós-negociação tradicional, apenas com uma camada de token.

Dois padrões do Ethereum são comumente posicionados como as principais respostas para isso: erc 3643 (anteriormente o padrão t rex, também escrito como T-REX) e erc 1400. A Tokeny descreve ambos como padrões de token de segurançaque impõem regras de conformidade e controlam transferências para investidores elegíveis, mas com mecanismos diferentes. Esse “mecanismo diferente” é todo o jogo.

Ele determina se um local pode tratar o token como um ERC-20 com verificações extras, ou se cada transferência precisa de um fluxo de autorização externo que se torna uma dependência para a liquidação.

Como o ERC-3643 impõe transferências conformes

Uma transferência sob o erc 3643 é projetada para falhar rapidamente se as partes não forem elegíveis. O fluxo central é um sistema de validador automático que verifica as regras de transferência ligadas aos usuários (identidades) e à oferta. A Tokeny e a NYALA descrevem o mesmo padrão: antes que uma transferência seja executada, a lógica do token verifica se o remetente e o destinatário satisfazem as regras definidas pelo emissor.

É aqui que a analogia do “motor de correspondência” se encaixa. O próprio token se comporta como um local com permissão que se recusa a liquidar uma negociação inelegível. O token se torna um token com permissão por construção, e o modelo mental mais comum que os usuários alcançam é um token de lista branca. A diferença é que a lista branca não é apenas uma lista estática.

A lógica do validador pode refletir atributos de identidade e restrições de oferta, e pode ser atualizada à medida que as regras mudam.

A identidade é a alavanca. A visão geral da Rejolut vincula explicitamente as verificações de elegibilidade do ERC-3643 ao ONCHAIN ID, descrevendo o onchainid como uma identidade digital com atestações assinadas por emissores de reivindicações confiáveis.

Seja uma equipe usando exatamente essa pilha de identidade ou um registro equivalente, a implicação operacional é a mesma: o registro de identidade e a configuração do validador se tornam o caminho crítico para cada transferência.

O controle do emissor e do agente é a outra alavanca. Tokeny e NYALA enfatizam que o emissor dos valores mobiliários, ou seu agente, mantém o controle dos tokens e das transferências mesmo quando os investidores fazem a custódia própria. A NYALA descreve controles como queima ou transferência forçada de tokens.

Isso é importante para as operações do dia 2: ações corporativas, atualizações de sanções, chaves perdidas e ordens judiciais não são casos extremos em mercados regulamentados. Eles são o trabalho.

Como o ERC-1400 estrutura tokens regulamentados

O ERC-1400 toma um caminho diferente para o mesmo destino: transferências compatíveis. Em vez de depender de um validador onchain, Tokeny e NYALA descrevem o ERC-1400 como validando cada negociação usando uma chave específica gerada offchain. Conceitualmente, isso é mais próximo de um bilhete pré-negociação. A transferência é permitida porque um sistema externo produziu a credencial certa para aquele movimento específico.

Esse fluxo de trabalho de chave offchain é combinado com recursos que se assemelham ao design de produtos de mercados de capitais, em vez de apenas controle de transferência. A NYALA descreve um sistema de gerenciamento de documentos que vincula tokens a documentos legais e informações relevantes. As mesmas fontes descrevem partições, que dividem tokens em subconjuntos com regras e restrições diferentes.

A Rejolut também enquadra o ERC-1400 como uma combinação de padrões ERC existentes e novos para cobrir as necessidades de tokens de segurança, incluindo restrições de transferência, metadados de transferência, gerenciamento de documentos, transferências forçadas e fungibilidade parcial via saldos particionados.

As partições são a parte que muda como o ativo se comporta na tela. Um único "token" pode representar vários baldes que não são intercambiáveis porque carregam direitos, bloqueios ou restrições diferentes. Isso é útil quando "mesmo ticker" não pode ser tratado como um único pool uniforme. Também significa que as integrações precisam entender qual partição está se movendo, não apenas o saldo total.

A troca operacional está embutida no modelo de autorização. Se cada transferência precisa de uma chave gerada offchain, então o pipeline de emissão e validação de chaves se torna infraestrutura de mercado. Se estiver fora do ar, as transferências falham. Se for mal gerenciado, as transferências podem ser abusadas.

A NYALA sinaliza explicitamente a dependência de uma chave offchain como um risco de segurança e operacional porque a chave pode ser comprometida ou perdida.

Diferenças chave que afetam a adoção

A maneira mais clara de comparar esses padrões de tokens de segurança é alinhar os eixos que determinam quem pode integrar e o que quebra durante a liquidação.

1. Onde a autorização reside. O ERC-3643 impõe elegibilidade onchain via um validador automático vinculado a identidades e regras de oferta. O ERC-1400 autoriza transferências via uma chave offchain específica por negociação. Essa é a bifurcação arquitetônica que se desdobra em tudo o mais. 2. Interoperabilidade e distribuição.

A NYALA afirma que o ERC-3643 é compatível com qualquer carteira ou exchange ERC-20, enquanto o ERC-1400 não é totalmente compatível com carteiras e exchanges ERC-20 devido à complexidade adicional. A descrição da Rejolut implica que o ERC-1400 se baseia no ERC-20 com extensões, o que pode ser lido como compatibilidade parcial, mas não faz a mesma ampla afirmação de "qualquer carteira/exchange". 3. Dependência operacional.

A dependência do ERC-1400 é o fluxo de trabalho da chave de autorização offchain. A dependência do ERC-3643 é o registro de identidade e validador mais controles de emissor ou agente. Ambos são caminhos críticos, mas falham de maneira diferente às 2 da manhã. 4. Estruturação de produtos.

As partições e o gerenciamento de documentos do ERC-1400 são construídos para ativos onde tranches, bloqueios ou direitos precisam ser representados como baldes separados. O ERC-3643 é posicionado mais como um portão de transferência uniforme que pode impor várias regras e jurisdições sem particionamento.

A Tokeny também posiciona o ERC-3643 como conformidade de codificação, preservando o controle do emissor ou agente, reduzindo custos por meio de liquidação automatizada onchain T+0 e aumentando a transferibilidade e liquidez. A afirmação T+0 não é mágica. Depende da decisão de conformidade ser automatizada no caminho de transferência. Se a conformidade for empurrada para etapas de coordenação offchain, o sistema pode voltar a uma latência operacional.

A adoção é um jogo de coordenação, portanto, a pegada relatada importa mesmo quando é relatada pelo emissor ou fornecedor. A Tokeny lista métricas de uso do ERC-3643 de mais de 120 funções, mais de 180 jurisdições aplicadas, €28 bilhões em valor tokenizado para clientes e mais de 120 emissores e instituições financeiras.

Nenhum conjunto de dados de adoção de terceiros comparável é fornecido para o ERC-1400 nas fontes fornecidas, portanto, a comparação não pode ser feita simetricamente.

Quando cada padrão faz sentido

A seleção geralmente começa com uma pergunta direta: o objetivo é uma distribuição ampla semelhante ao ERC-20, ou o objetivo é uma estrutura legal detalhada dentro do token?

O ERC-3643 tende a se encaixar em equipes que desejam que a conformidade seja aplicada na camada de transferência de tokens e querem que as integrações pareçam o mais próximo possível do ERC-20. A alegação de compatibilidade da NYALA é a razão chave pela qual ela aparece nas conversas de distribuição de RWA.

Se um token pode ser mantido e movido usando as infraestruturas existentes de carteira e troca, o emissor não está pedindo a cada local que implemente um fluxo de autorização sob medida. O custo é que a configuração de identidade e validador se torna o centro de gravidade operacional, e os controles do emissor ou agente devem ser governados de forma rigorosa.

O ERC-1400 tende a se encaixar em ativos onde partições e vinculação de documentos não são opcionais. Se o produto requer fungibilidade parcial, múltiplas tranches ou diferentes conjuntos de restrições que devem ser representados explicitamente, o sistema de partição do ERC-1400 é uma maneira nativa de fazê-lo. O custo é garantir o fluxo de trabalho de chave offchain como infraestrutura crítica, porque cada transferência depende disso.

Uma sequência de avaliação prática é direta.

1. Mapeie o modelo de restrição do ativo. Se o ativo é um único pool com regras de elegibilidade, o bloqueio onchain se alinha naturalmente. Se o ativo é composto por múltiplos buckets com diferentes direitos ou bloqueios, as partições podem ser o produto. 2. Valide os alvos de integração cedo.

Se a distribuição depende do suporte existente de carteira e troca ERC-20, teste a alegação de compatibilidade do ERC-3643 da NYALA com os locais que realmente importam. 3. Garanta o modo de falha. O ERC-1400 concentra o risco no pipeline de chave offchain. O ERC-3643 concentra o risco em registros de identidade, configuração de validadores e controles de agentes.

Ambos os padrões são tentativas de transformar a liquidação regulamentada em software. A diferença é se a decisão de conformidade é aplicada como uma regra de motor de correspondência onchain, ou como um ticket pré-negociação emitido offchain. Essa escolha determina quão próximo o sistema chega da liquidação automatizada sem reintroduzir a coordenação manual.

Equívocos comuns que desperdiçam tempo

“Ambos são apenas ERC-20 com uma lista de permissões.” Essa formulação perde a distinção central. O ERC-3643 é descrito como aplicando elegibilidade através de um validador onchain e verificações de identidade, enquanto o ERC-1400 é descrito como validando transferências com uma chave específica gerada offchain.

Um modelo mental de token de lista de permissões pode ser útil como ponto de partida, mas esconde onde a decisão real de autorização é tomada.

“Partições são apenas um recurso desejável.” Para muitos produtos regulamentados, as partições são o produto. NYALA e Rejolut descrevem partições como a divisão de tokens em subconjuntos ou sub-saldos com diferentes regras e restrições, o que muda como saldos, transferências e relatórios se comportam. Tratar partições como cosméticas leva a contabilidade quebrada e integrações confusas.

“T+0 é automático assim que você tokeniza.” O posicionamento T+0 da Tokeny está ligado ao liquidação automatizada onchain com conformidade incorporada no caminho de transferência. Se um design depende de etapas offchain, como emissão de chave por negociação, o sistema pode reintroduzir latência operacional, mesmo que a transferência final seja onchain.

“Autorização offchain é apenas um detalhe de implementação.” A NYALA sinaliza explicitamente a chave offchain como uma dependência de segurança e operacional, pois pode ser comprometida ou perdida. Isso não é uma nota de rodapé. É uma peça central da infraestrutura de mercado que deve ser operada como qualquer outro sistema crítico.

A Conclusão

Eu vi equipes tratarem a “escolha do padrão de token” como uma preferência de desenvolvedor, e depois descobrirem que na verdade é uma decisão de design de local. Se a elegibilidade é aplicada onchain como o ERC-3643, o token em si se torna o portão, e as integrações podem se parecer mais com o caminho ERC-20 que a NYALA afirma.

Se a elegibilidade é aplicada por uma chave offchain como o ERC-1400, o pipeline da chave se torna a coisa que pode interromper a liquidação quando falha.

O erro caro é otimizar para a demonstração em vez das operações do dia 2. Ações corporativas, transferências forçadas e atualizações de regras são onde a conformidade por código ou se mantém unida ou se transforma em uma pilha de exceções manuais.

Escolha o modo de falha que a organização pode realmente executar às 2 da manhã, porque é aí que esses padrões deixam de ser “padrões de token de segurança comparados” e começam a ser microestrutura de mercado.

Fontes

• Tokeny
• NYALA
• Rejolut