À medida que as rampas de entrada reguladas, stablecoins e padrões de nomenclatura convergem, a infraestrutura ENS IBAN está emergindo como uma forma de conectar nativamente pagamentos bancários e liquidação on-chain.
Summary
De rampas de saída fragmentadas para liquidação unificada
O ecossistema Ethereum já move valor de TradFi para DeFi de forma eficiente, graças às rampas de entrada reguladas e stablecoins em euros como EURe. No entanto, o caminho inverso ainda parece desarticulado. Enviar fundos de uma conta IBAN diretamente para uma carteira é simples, mas retornar valor do web3 para contas bancárias é muito menos fluido.
Hoje, liquidar fundos de uma carteira web3 em contas IBAN arbitrárias é fragmentado. Além disso, os usuários frequentemente dependem de APIs personalizadas, exchanges centralizadas ou rampas de saída manuais. Isso quebra a experiência do usuário e enfraquece a visão do Ethereum como uma camada de liquidação neutra para ativos digitais e tradicionais.
Domínios ENS com vIBANs anexados
A extensão proposta para o ENS introduz IBANs virtuais verificáveis, ou vIBANs, anexados diretamente aos domínios ENS. Na prática, um nome ENS torna-se um identificador legível por humanos não apenas para endereços cripto, mas também para instruções de liquidação baseadas em IBAN.
Ao implementar um sistema de resolutor hierárquico, as carteiras poderiam tratar um IBAN como um identificador de roteamento on-chain de primeira classe. Dito isso, o mesmo fluxo pode suportar liquidação direta peer-to-peer on-chain quando possível, ou automaticamente recorrer a proxies regulados SEPA quando não existir uma rota totalmente on-chain.
Crucialmente, o design aproveita o formato estruturado dos IBANs (Código do País 14 Código do Banco 14 BBAN). Além disso, essa estrutura se encaixa naturalmente no modelo hierárquico do ENS, permitindo um diretório descentralizado que automatiza a lógica de roteamento e rampas de saída.
Esquema de registro de texto ENS para vIBANs
A proposta define dois novos registros de texto ENS para codificar preferências de liquidação em um domínio:
- viban: Uma string IBAN compatível com o padrão (por exemplo, EE471000001020145685).
- accepted: Uma lista separada por vírgulas de ativos e cadeias preferidos (por exemplo, eure@gnosis, usdc@base, eth@taiko).
Com esses campos, uma carteira pode descobrir não apenas o vIBAN de uma contraparte, mas também os ativos e redes que ela prefere. Isso permite escolhas de roteamento que minimizam taxas e latência, respeitando a configuração do usuário.
Arquitetura de resolutor hierárquico no ENS
O sistema depende de uma arquitetura de resolutor viban em camadas que espelha como os IBANs são estruturados. Cada camada se especializa em analisar e encaminhar consultas para o próximo nível, resolvendo, em última instância, um IBAN para um endereço de carteira e nome ENS.
No topo, um Resolutor Global é mantido por um DAO. Ele analisa o componente do país do IBAN e encaminha a solicitação para o contrato de nível de país apropriado. Esse papel raiz levanta questões importantes sobre neutralidade e governança de resolutores bancários.
Em seguida, um Resolutor de País, operado por um DAO ou consórcio, analisa tanto o código do país quanto o código do banco. Além disso, ele encaminha consultas para o Resolutor de Banco correto com base nessa informação, atuando como um registro para instituições participantes.
O Resolutor de Banco, mantido pela própria instituição, valida o segmento BBAN. Ele então resolve o vIBAN para um endereço de carteira específico e domínio ENS associado. Se não existir uma rota válida on-chain, o sistema retorna um status NOROUTE e pode invocar um proxy off-chain.
Modelo de verificação e segurança do ens iban
Para prevenir falsificações e garantir que as reivindicações de vIBAN sejam genuínas, o modelo usa um fluxo de verificação explícito. Isso combina registros on-chain, mensagens assinadas e verificações do lado do banco para vincular um IBAN a um proprietário de carteira.
Primeiro, a carteira realiza uma consulta on-chain, buscando o registro ENS do destinatário e a reivindicação de viban associada. Em seguida, o usuário assina uma mensagem de reivindicação eip-712 iban para provar que a mesma carteira controla o IBAN reivindicado.
A estrutura da reivindicação é definida como:
struct IBANClaim { string viban; address wallet; }
Após a verificação da assinatura, a reivindicação é comparada com as informações mantidas pelo Resolutor de Banco relevante. Além disso, essa verificação extra ajuda a garantir que apenas vinculações autorizadas de IBAN013carteira sejam aceitas, reduzindo o risco de fraude para usuários e instituições.
O fluxo de fallback “Burn and Proxy”
Quando uma rota on-chain não pode ser encontrada para um IBAN de destino, o sistema recorre a um gateway regulado. Este mecanismo de burn and proxy preserva a transparência enquanto ainda permite a liquidação em contas bancárias legadas.
Neste fluxo, o resolutor primeiro retorna NOROUTE. A carteira então gera uma transação para um Endereço de Queima designado, que é implementado como um contrato de resgate. Dito isso, os fundos não são perdidos; em vez disso, eles sinalizam uma intenção de saída via um intermediário confiável.
Um proxy regulado, como Monerium, executa a transferência de crédito SEPA para o IBAN legado final. Além disso, se o usuário enviar um ativo que difere do requisito do banco, por exemplo, USDC em vez de EUR, o gateway fornece taxas de troca em tempo real para manter a precificação e execução transparentes.
Governança, privacidade e estratégia cross-chain
Esta arquitetura abstrai a seleção de cadeias e a gestão de liquidez dos usuários finais. As carteiras podem priorizar redes de Layer 2 de baixo custo e rollups baseados com composabilidade de sincronização para eficiência cross-chain, mantendo a interface do usuário simples.
No entanto, várias questões em aberto permanecem. Um desafio chave é como este modelo pode preservar a privacidade do usuário ao usar identificadores no estilo IBAN. Outro é definir a governança ideal para o Resolutor Raiz e os Resolutores de País, potencialmente envolvendo um consórcio bancário ou DAO de múltiplas partes interessadas.
Versões futuras poderiam estender o modelo além do SEPA. Além disso, poderia alcançar sistemas como UK Faster Payments, infraestrutura eYuan, ou vIBANs multi-moeda, permitindo que um espectro mais amplo de trilhos de pagamento fiduciário se conectem ao ENS.
Rumo a uma camada de identidade unificada DeFi e TradFi
Ao tratar o IBAN como uma extensão da identidade dentro do ecossistema ENS, este design visa criar um espaço financeiro unificado. Em tal sistema, as fronteiras entre o banco tradicional e a liquidação nativa do Ethereum tornam-se amplamente transparentes, enquanto o roteamento, regulação e segurança permanecem programáveis.
Em última análise, a liquidação onchain de IBAN vinculada a nomes ENS poderia permitir que os usuários movimentassem valor entre contas bancárias e carteiras tão facilmente quanto enviar um e-mail. Se implementado com segurança e governado de forma neutra, posicionaria o ENS como um diretório central para pagamentos DeFi e TradFi.
