At its first Sibos, ENS Labs explored how onchain names could help institutions identify tokenized assets, connect them to existing identifiers, and work within established financial systems.
What does a bank see when it looks at a tokenized fund? In most cases, a 42-character contract address. But that address alone does not tell you who issued the asset or which legal entity stands behind it.
ENS Labs spent four days at Sibos in Miami, the annual conference Swift organizes for the banking and payments industry. It was the first Sibos for ENS. Three of us went, from partnerships, growth and product marketing, to hear how banks, market infrastructures and custodians describe the problems they run into when assets and payments move onchain, and to find out whether naming is one of them.
It is, although rarely under that word. People talked about identifiers, reference data, taxonomy and standards. Across those conversations, the same practical question kept coming up: how do institutions identify an onchain asset and connect it to the information they already rely on?
Almost every large institution on the exhibition floor had a tokenization or stablecoin story to tell. Two benefits kept coming up: markets that stay open around the clock, and settlement that can take seconds instead of days. One market infrastructure provider told us that its work on 24/7/365 markets is being pushed by its own members, which says a lot about where the demand is coming from.
In many of the sessions we attended, the discussion had moved beyond whether to use blockchains. The open questions were about structure: should the ledger be public or private? Who operates it? And when is a trade legally final? The distinction between onchain settlement and legal finality came up repeatedly. It was another sign that these conversations are moving into implementation.
Underneath the confidence we also met unease. A firm that can issue, trade and settle on its own stack takes over steps that used to belong to separate specialists, and several of those specialists were in the room working out what their role will look like in an onchain future. We also met bankers who do not touch crypto at all. For those conversations, the usefulness of ENS needs to be clear without assuming familiarity with the technology.
Over four days we spoke with exchange groups, market infrastructure providers, custodian banks, wallet and cloud providers. Sibos gave us access to people working on these projects and the chance to ask practical questions directly.
The registry problem needed the least explanation. When we showed one name resolving to the right contract on each chain where an asset exists, people understood it before the demo finished. Several of them were already keeping that mapping by hand, in spreadsheets or internal databases.
In his Sibos recap, ENS product marketing lead Harris described how blockchain pilots are maturing and, in some cases, moving into production. As tokenized funds, equities and other assets come onchain, the naming opportunity extends beyond accounts and wallets. He framed the question this creates for institutions: "As more value comes onchain … a new problem emerges: how do we keep track of everything?"
The word "naming" was often the wrong one. One exchange group preferred "taxonomy". Others spoke about identifiers or reference data. The need they described was the same, but it helps to describe it in the vocabulary the industry already uses.
One common question was how ENS relates to the identifiers institutions rely on today, including LEIs, ISINs and the newer identifiers for digital tokens. The answer that worked was that a name can point to those identifiers and does not replace any of them.
Payments came up less often than assets, with one exception. Software agents that pay on behalf of a person or a company need a destination they can look up and check, and that topic drew real interest.
The objections were consistent as well. People asked who keeps the records up to date, who is liable if a record is wrong, and which applications would read the names in the first place. Those are fair questions. Adoption will depend on clear responsibilities for maintaining records and applications that use them.
Traditional finance has long relied on standardized identifiers. A security has an International Securities Identification Number (ISIN). A legal entity has a Legal Entity Identifier (LEI). A bank has a Business Identifier Code (BIC). Financial messages follow standards such as ISO 20022. These systems help institutions refer to the same things and exchange information consistently..
The challenge is connecting onchain assets to that information. A tokenized fund may have a different contract address on each chain it exists, while an institution needs a consistent way to identify the fund and its issuer. The Standards Forum discussions about that gap were among the most relevant sessions for us.
On the Monday of Sibos, ENS and GLEIF announced a partnership to connect LEIs with ENS names. The proposed approach would let applications check that both sides authorized the association between a name and an organizational identity. Owning an ENS name proves nothing about legal identity by itself, which is why this work matters.
ENS head of growth James's recap connected those discussions to a practical priority for ENS: compatibility with the standards institutions already use. He pointed to the Standards Forum as a natural fit for that work, alongside the collaboration with GLEIF. As he put it, "The syntax of onchain naming must be incorporated into the syntax that all banks already use."
The GLEIF work is still in development. Making onchain names usable within existing financial standards, including ISO 20022, is a longer-term goal. That work moves at the pace of standard bodies, but compatibility with the systems banks already run will be essential to adoption.
For the tokenized fund in the opening question, a name could provide consistent reference to its contracts across networks. Applications could read the relevant records to find the contract on a particular chain, along with references to the issuer, LEI, a price feed or disclosure documents. An institution could publish those records under a DNS domain it already owns and imports into ENS.
The limits matter as much as the use. ENS does not issue the asset, settle the payment or verify the legal entity. The authoritative facts stay with the issuer, the depository, GLEIF or whoever maintains them today. The name gives applications one readable place to find them.
The next few months are follow-up work for the ENS team. Several institutions asked to see prototypes built around their own assets, and we will start there. The work with GLEIF continues, and we want to take part in the standards discussions where identifiers for digital assets are being defined.
Sibos also confirmed something we had hoped was true. A name instead of an address made sense within the first minute of almost every conversation. The next step is making those names work inside the systems these institutions already run.