How ens iban integration could unify DeFi and TradFi settlement

As regulated on-ramps, stablecoins, and naming standards converge, ens iban infrastructure is emerging as a way to natively bridge bank payments and on-chain settlement.

From fragmented off-ramps to unified settlement

The Ethereum ecosystem already moves value from TradFi to DeFi efficiently, thanks to regulated on-ramps and euro stablecoins like EURe. However, the reverse path still feels disjointed. Sending funds from an IBAN account directly to a wallet is simple, but returning value from web3 to bank accounts is far less seamless.

Today, settling funds from a web3 wallet into arbitrary IBAN accounts is fragmented. Moreover, users often rely on bespoke APIs, centralized exchanges, or manual off-ramping. This breaks the user experience and weakens the vision of Ethereum as a neutral settlement layer for both digital and traditional assets.

ENS domains with attached vIBANs

The proposed extension to ENS introduces verifiable virtual IBANs, or vIBANs, attached directly to ENS domains. In practice, an ENS name becomes a human-readable handle not only for crypto addresses but also for IBAN-based settlement instructions.

By implementing a hierarchical resolver system, wallets could treat an IBAN as a first-class, on-chain routing identifier. That said, the same flow can support direct on-chain peer-to-peer settlement when possible, or automatically fall back to regulated SEPA proxies when no fully on-chain route exists.

Crucially, the design leverages the structured format of IBANs (Country Code 14 Bank Code 14 BBAN). Moreover, this structure maps naturally into ENS’s hierarchical model, enabling a decentralized directory that automates routing and off-ramping logic.

ENS text record schema for vIBANs

The proposal defines two new ENS text records to encode settlement preferences on a domain:

• viban: A standard-compliant IBAN string (for example, EE471000001020145685).
• accepted: A comma-separated list of preferred assets and chains (for example, eure@gnosis, usdc@base, eth@taiko).

With these fields, a wallet can discover not only a counterparty’s vIBAN but also the assets and networks they prefer. This allows routing choices that minimize fees and latency while respecting the user’s configuration.

Hierarchical resolver architecture on ENS

The system relies on a layered viban resolver architecture that mirrors how IBANs are structured. Each layer specializes in parsing and forwarding queries to the next level, ultimately resolving an IBAN to a wallet address and ENS name.

At the top, a Global Resolver is maintained by a DAO. It parses the country component of the IBAN and forwards the request to the appropriate country-level contract. This root role raises important questions about neutrality and bank resolver governance.

Next, a Country Resolver, operated by a DAO or consortium, parses both country and bank code. Moreover, it routes queries to the correct Bank Resolver based on that information, acting as a registry for participating institutions.

The Bank Resolver, maintained by the institution itself, validates the BBAN segment. It then resolves the vIBAN to a specific wallet address and associated ENS domain. If no valid on-chain route exists, the system returns a NOROUTE status and can invoke an off-chain proxy.

ens iban verification and security model

To prevent spoofing and ensure that vIBAN claims are genuine, the model uses an explicit verification flow. This combines on-chain records, signed messages, and bank-side checks to tie an IBAN to a wallet owner.

First, the wallet performs an on-chain query, fetching the recipient’s ENS record and the associated viban claim. Then, the user signs an eip-712 iban claim message to prove that the same wallet controls the claimed IBAN.

The claim structure is defined as:

struct IBANClaim { string viban; address wallet; }

After signature verification, the claim is matched against information held by the relevant Bank Resolver. Moreover, this extra check helps ensure that only authorized IBAN013wallet bindings are accepted, reducing fraud risk for both users and institutions.

The "Burn and Proxy" fallback flow

When an on-chain route cannot be found for a destination IBAN, the system falls back to a regulated gateway. This burn and proxy mechanism preserves transparency while still allowing settlement into legacy bank accounts.

In this flow, the resolver first returns NOROUTE. The wallet then generates a transaction to a designated Burn Address, which is implemented as a redemption contract. That said, the funds are not lost; instead, they signal an intent to off-ramp via a trusted intermediary.

A regulated proxy, such as Monerium, executes the SEPA credit transfer to the final legacy IBAN. Moreover, if the user sends an asset that differs from the bank’s requirement, for example USDC instead of EUR, the gateway provides real-time swap rates to keep pricing and execution transparent.

Governance, privacy, and cross-chain strategy

This architecture abstracts away chain selection and liquidity management from end users. Wallets can prioritize low-cost Layer 2 networks and based rollups with sync composability for cross-chain efficiency, while keeping the user interface simple.

However, several open questions remain. One key challenge is how this model can preserve user privacy while using IBAN-style identifiers. Another is defining optimal governance for the Root Resolver and Country Resolvers, potentially involving a bank consortium or multi-stakeholder DAO.

Future versions could extend the model beyond SEPA. Moreover, it could reach systems such as UK Faster Payments, eYuan infrastructure, or multi-currency vIBANs, enabling a broader spectrum of fiat payment rails to plug into ENS.

Toward a unified DeFi and TradFi identity layer

By treating the IBAN as an extension of identity within the ENS ecosystem, this design aims to create a unified financial space. In such a system, the boundaries between traditional banking and Ethereum-native settlement become largely transparent, while routing, regulation, and security remain programmable.

Ultimately, onchain iban settlement tied to ENS names could let users move value between bank accounts and wallets as easily as sending an email. If implemented securely and governed neutrally, it would position ENS as a core directory for both DeFi and TradFi payments.