A medida que las rampas de acceso reguladas, las stablecoins y los estándares de nomenclatura convergen, la infraestructura de ens iban está emergiendo como una forma de conectar nativamente los pagos bancarios y la liquidación en cadena.
Summary
De rampas de salida fragmentadas a liquidación unificada
El ecosistema de Ethereum ya mueve valor de TradFi a DeFi de manera eficiente, gracias a las rampas de acceso reguladas y las stablecoins en euros como EURe. Sin embargo, el camino inverso aún se siente desarticulado. Enviar fondos desde una cuenta IBAN directamente a una billetera es sencillo, pero devolver valor de web3 a cuentas bancarias es mucho menos fluido.
Hoy en día, liquidar fondos desde una billetera web3 en cuentas IBAN arbitrarias está fragmentado. Además, los usuarios a menudo dependen de APIs personalizadas, intercambios centralizados o rampas de salida manuales. Esto rompe la experiencia del usuario y debilita la visión de Ethereum como una capa de liquidación neutral para activos digitales y tradicionales.
Dominios ENS con vIBANs adjuntos
La extensión propuesta para ENS introduce IBANs virtuales verificables, o vIBANs, adjuntos directamente a los dominios ENS. En la práctica, un nombre ENS se convierte en un identificador legible para humanos no solo para direcciones cripto, sino también para instrucciones de liquidación basadas en IBAN.
Al implementar un sistema de resolutores jerárquico, las billeteras podrían tratar un IBAN como un identificador de enrutamiento en cadena de primera clase. Dicho esto, el mismo flujo puede admitir liquidaciones directas entre pares en cadena cuando sea posible, o recurrir automáticamente a proxies regulados SEPA cuando no exista una ruta completamente en cadena.
Crucialmente, el diseño aprovecha el formato estructurado de los IBANs (Código de País 14 Código Bancario 14 BBAN). Además, esta estructura se adapta naturalmente al modelo jerárquico de ENS, permitiendo un directorio descentralizado que automatiza la lógica de enrutamiento y rampas de salida.
Esquema de registro de texto ENS para vIBANs
La propuesta define dos nuevos registros de texto ENS para codificar preferencias de liquidación en un dominio:
- viban: Una cadena IBAN conforme a estándares (por ejemplo, EE471000001020145685).
- accepted: Una lista separada por comas de activos y cadenas preferidos (por ejemplo, eure@gnosis, usdc@base, eth@taiko).
Con estos campos, una billetera puede descubrir no solo el vIBAN de una contraparte, sino también los activos y redes que prefieren. Esto permite opciones de enrutamiento que minimizan tarifas y latencia mientras respetan la configuración del usuario.
Arquitectura de resolutor jerárquico en ENS
El sistema se basa en una arquitectura de resolutor viban en capas que refleja cómo están estructurados los IBANs. Cada capa se especializa en analizar y reenviar consultas al siguiente nivel, resolviendo finalmente un IBAN a una dirección de billetera y nombre ENS.
En la parte superior, un Resolutor Global es mantenido por un DAO. Analiza el componente de país del IBAN y reenvía la solicitud al contrato de nivel de país apropiado. Este rol raíz plantea importantes preguntas sobre la neutralidad y la gobernanza del resolutor bancario.
A continuación, un Resolutor de País, operado por un DAO o consorcio, analiza tanto el código de país como el código bancario. Además, enruta las consultas al Resolutor Bancario correcto basado en esa información, actuando como un registro para las instituciones participantes.
El Resolutor Bancario, mantenido por la propia institución, valida el segmento BBAN. Luego resuelve el vIBAN a una dirección de billetera específica y dominio ENS asociado. Si no existe una ruta válida en cadena, el sistema devuelve un estado NOROUTE y puede invocar un proxy fuera de cadena.
Verificación de ens iban y modelo de seguridad
Para prevenir suplantaciones y asegurar que las reclamaciones de vIBAN sean genuinas, el modelo utiliza un flujo de verificación explícito. Esto combina registros en cadena, mensajes firmados y verificaciones del lado del banco para vincular un IBAN a un propietario de billetera.
Primero, la billetera realiza una consulta en cadena, obteniendo el registro ENS del destinatario y la reclamación de viban asociada. Luego, el usuario firma un mensaje de reclamación eip-712 iban para demostrar que la misma billetera controla el IBAN reclamado.
La estructura de la reclamación se define como:
struct IBANClaim { string viban; address wallet; }
Después de la verificación de la firma, la reclamación se compara con la información mantenida por el Resolutor Bancario relevante. Además, esta verificación adicional ayuda a asegurar que solo se acepten vinculaciones IBAN013wallet autorizadas, reduciendo el riesgo de fraude tanto para los usuarios como para las instituciones.
El flujo de respaldo «Burn and Proxy»
Cuando no se puede encontrar una ruta en cadena para un IBAN de destino, el sistema recurre a una puerta de enlace regulada. Este mecanismo de burn and proxy preserva la transparencia mientras permite la liquidación en cuentas bancarias heredadas.
En este flujo, el resolutor primero devuelve NOROUTE. La billetera luego genera una transacción a una Dirección de Quema designada, que se implementa como un contrato de redención. Dicho esto, los fondos no se pierden; en cambio, señalan una intención de salir de la rampa a través de un intermediario de confianza.
Un proxy regulado, como Monerium, ejecuta la transferencia de crédito SEPA al IBAN heredado final. Además, si el usuario envía un activo que difiere del requisito del banco, por ejemplo USDC en lugar de EUR, la puerta de enlace proporciona tasas de intercambio en tiempo real para mantener la transparencia en precios y ejecución.
Gobernanza, privacidad y estrategia de cadena cruzada
Esta arquitectura abstrae la selección de cadenas y la gestión de liquidez de los usuarios finales. Las billeteras pueden priorizar redes de Capa 2 de bajo costo y rollups basados con composibilidad de sincronización para eficiencia de cadena cruzada, manteniendo la interfaz de usuario simple.
Sin embargo, quedan varias preguntas abiertas. Un desafío clave es cómo este modelo puede preservar la privacidad del usuario mientras utiliza identificadores estilo IBAN. Otro es definir la gobernanza óptima para el Resolutor Raíz y los Resolutores de País, potencialmente involucrando un consorcio bancario o un DAO de múltiples partes interesadas.
Las versiones futuras podrían extender el modelo más allá de SEPA. Además, podría alcanzar sistemas como UK Faster Payments, infraestructura eYuan, o vIBANs multicurrency, permitiendo que un espectro más amplio de rieles de pago fiat se conecten a ENS.
Hacia una capa de identidad unificada de DeFi y TradFi
Al tratar el IBAN como una extensión de la identidad dentro del ecosistema ENS, este diseño busca crear un espacio financiero unificado. En tal sistema, los límites entre la banca tradicional y la liquidación nativa de Ethereum se vuelven en gran medida transparentes, mientras que el enrutamiento, la regulación y la seguridad permanecen programables.
En última instancia, la liquidación de iban en cadena vinculada a nombres ENS podría permitir a los usuarios mover valor entre cuentas bancarias y billeteras tan fácilmente como enviar un correo electrónico. Si se implementa de manera segura y se gobierna de manera neutral, posicionaría a ENS como un directorio central para pagos tanto de DeFi como de TradFi.
