ENS com resolvedores IBAN: Unifique a camada de liquidação de DeFi e TradFi – Camada 2

O ecossistema Ethereum preencheu com sucesso a lacuna entre TradFi e DeFi por meio de rampas de acesso regulamentadas e stablecoins como EURe.
Enviar dinheiro da sua conta IBAN diretamente para a sua carteira funciona como um suspiro. A direção inversa, por outro lado, não funciona tão aparentemente.
A liquidação de uma carteira web3 diretamente para uma conta IBAN arbitrária permanece fragmentada, muitas vezes exigindo a chamada de APIs ou a saída manual.
Esta extensão do ENS anexa IBANs virtuais verificáveis ​​(vIBANs) aos domínios do ENS.
Ao implementar um sistema de resolução hierárquico, podemos permitir que as carteiras tratem um IBAN como um identificador de roteamento de primeira classe na cadeia.
Suporta liquidação p2p direta na cadeia ou fallback automatizado para proxies SEPA regulamentados.
Aproveitando a natureza estruturada e hierárquica dos IBANs (Código do País → Código do Banco → BBAN), podemos construir um diretório descentralizado dentro do ENS para automatizar esse fluxo.

Esquema de registro de texto ENS

Dois novos registros de texto para domínios ENS:

viban: uma string IBAN compatível com o padrão (por exemplo, EE471000001020145685).
accepted: Uma lista separada por vírgulas de ativos e cadeias preferenciais (por exemplo, eure@gnosis, usdc@base, eth@taiko).

Arquitetura Hierárquica do Resolvedor

O sistema encaminha consultas através de resolvedores especializados:

Resolvedor Global: resolvedor mantido por um DAO que analisa o país.
Resolvedor de país: Um contrato mantido por DAO ou Consórcio que analisa o país e o código do banco. Rotas para um resolvedor específico do banco.
Resolvedor Bancário: Mantido pela instituição. ele valida o BBAN e o resolve para um endereço de carteira e domínio ENS.
Cair pra trás: Se nenhuma rota na cadeia for encontrada (NOROUTE), o sistema aciona um proxy fora da cadeia.

Verificação e Segurança

Para evitar falsificação, o sistema implementa um modelo de verificação.

1. Consulta na cadeia: A carteira busca o registro ENS do destinatário e a reivindicação viban.
2. Correspondência de Assinatura: Verificação de uma mensagem assinada EIP-712 provando que o proprietário da carteira controla o IBAN reivindicado

   struct IBANClaim {
     string viban;
     address wallet;
   }
   

3. Confirmação Bancária: a reclamação é comparada com os dados mantidos pelo resolvedor do banco.

O fluxo substituto “Burn and Proxy”

Quando um IBAN de destino não pode ser resolvido na cadeia, o sistema assume como padrão um gateway regulamentado:

1. Rejeição: o resolvedor retorna NOROUTE.
2. Intenção: A carteira gera uma transação para um endereço de gravação designado (contrato de resgate).
3. Execução fora da cadeia: Um proxy regulamentado (por exemplo, Monerium) trata da transferência de crédito SEPA para o IBAN legado.
4. Transparência: O gateway fornece taxas de swap em tempo real se o ativo enviado (por exemplo, USDC) for diferente da exigência do banco (por exemplo, EUR).

Discussão

Este modelo abstrai a seleção de cadeia e liquidez, priorizando L2s de baixo custo e rollups baseados (com Sync Composability) para eficiência entre cadeias. No entanto, algumas questões permanecem.

• Como esse modelo pode funcionar mantendo a privacidade?
• Qual é a governança ideal para o Root Resolver e os Country Resolvers para garantir a neutralidade? (Consórcio Bancário?)

A expansão futura poderia estender isso além da SEPA para pagamentos mais rápidos do Reino Unido, eYuan e vIBANs multimoedas.
Ao tratar o IBAN como uma extensão da identidade dentro do ecossistema ENS, podemos criar um espaço financeiro unificado onde as fronteiras entre TradFi e DeFi são transparentes.