How Do You Identify a Tokenized Fund Across Chains?

An identifier for tokenized funds is a stable reference code that names a fund token as one canonical asset, even when the same fund is deployed across several blockchains with different smart contract addresses. Traditional securities identifiers like ISIN and CUSIP name the fund as a legal instrument. An onchain-native identifier adds the missing layer: which network a given deployment lives on, and how each per-chain version maps back to the single underlying fund.

The reason this matters is simple. When a tokenized money market fund launches on Ethereum, then adds Solana, Avalanche, and a couple of app-chains, each version has its own contract address. Nothing about those addresses tells a downstream system they represent the same fund. Reference data breaks, reconciliation gets manual, and risk teams cannot answer a basic question: how much of this fund exists, and where.

Key takeaways

• A tokenized fund often exists as multiple onchain deployments, each with its own contract address and no shared key linking them to one fund identity.
• Legacy identifiers (ISIN, CUSIP) name the fund as a security but have no concept of a per-chain deployment, so they cannot tell you which address on which network you are looking at.
• An onchain-native identifier resolves the layer beneath the security: it maps each deployment to one canonical asset and encodes the network explicitly.
• DASID is one emerging (2026) open standard built for this, with a human-readable structure and an optional per-chain suffix. It is new, and its registry and resolution API are still being built.
• For fund administrators, custodians, and auditors, a shared identifier is the difference between automated reconciliation and manual address-matching across chains.

What a security master is, and why a fund needs one

A security master is the reference-data record that every operations, accounting, and risk system reads from to know what an instrument actually is. It holds the fund's identifiers, its issuer, its share classes, its currency, its pricing source, and the rules that govern it. When a trade settles or a position is reconciled, systems look up the security master to confirm they are all talking about the same thing.

For a tokenized fund, the security master has to describe not just the fund but every place it lives. A single fund can have multiple share classes (an accumulating class and a distributing class, say, or an institutional and a retail tranche), and each of those can be deployed on more than one network. The record has to answer three questions cleanly: which legal instrument is this, which share class is it, and which onchain deployment am I looking at right now.

The fields a tokenized fund needs to be identified across chains and share classes include a canonical fund identity, a share-class identifier, a per-deployment network and contract address, the pricing and NAV source, and the issuer or administrator of record. Get those modeled separately and the fund reconciles cleanly. Collapse them into a single contract address and the record breaks the moment a second deployment appears.

Why this matters now

Tokenized funds have moved from pilots to production. Money market funds and treasury funds from large asset managers now circulate onchain, and many are intentionally multi-chain because issuers want reach across the networks their clients use. That is good for distribution and bad for reference data, because the same fund now has several onchain addresses that no legacy system was designed to reconcile.

Custodians, transfer agents, and auditors increasingly need to treat these funds like any other book of holdings: priced, reconciled, and reported. To do that reliably, a firm has to know that the token at address A on Ethereum and the token at address B on Solana are the same fund, not two different assets. Without a canonical identifier, that mapping lives in spreadsheets and tribal knowledge, which does not survive an audit or scale to hundreds of instruments.

Reference data is the foundation the rest of fund servicing sits on. Once a fund can be identified cleanly across chains, downstream processes like corporate actions for tokenized securities and proxy voting for tokenized securities have something reliable to hang on to. For the wider picture of how these functions fit together, see onchain financial market infrastructure explained.

How identifying a tokenized fund actually works

There are three distinct layers you need to name, and mixing them up is where most confusion starts.

1. The fund as a security. This is the legal instrument, the thing with a prospectus, a NAV, and an issuer. Identifiers like ISIN and CUSIP live here. They answer "which fund is this," and they do it well for the instrument itself.
2. The onchain deployment. This is a specific smart contract on a specific network. It has a contract address that is unique to that chain. An address on Ethereum is a real, verifiable pointer, but it means nothing on Solana and carries no information about which fund it represents.
3. The canonical asset identity. This is the connective layer that says: these four deployments across four networks are all the same fund. This layer is what has been missing, and it is what an onchain-native identifier is designed to supply.

A per-deployment-aware identifier works by assigning one stable code to the fund token as an asset, then attaching a network-specific suffix for each deployment. That way a reconciliation system can collapse many addresses into one identity for reporting, while still resolving down to the exact contract when it needs to verify holdings on a specific chain.

Where DASID fits as a concrete example

DASID (Digital Asset System Identification) is an open identifier standard for digital assets, including tokens, networks, protocols, and issuers. It is issued and maintained by Allium, the data infrastructure company for onchain finance. It was published as v0.1 in May 2026, so it is new, and it is one option in a still-forming landscape rather than a settled industry default.

Its structure is a fixed, hyphen-delimited string of six segments: an entity type (three characters, such as TKN for token), a ticker (three to five characters), a sequence number (three digits, to handle collisions between assets that share a ticker), a primary class (a hierarchical classification), a mechanism sub-type, and a Luhn-derived check digit for basic error detection. A tokenized fund would carry the TKN prefix and a classification describing what kind of instrument it is.

The part that speaks directly to multi-chain funds is the deployment suffix. A single token gets one canonical code, and each per-chain deployment is expressed with a colon-delimited network suffix, for example TKN-USDC-001-ST-RB-3:ETH. The same asset on another network would share everything before the colon and change only the suffix. That is the mechanism that lets a fund administrator record "one fund, four deployments" in a single, human-readable key that a security master can store directly. You can read the full structure in the DASID standard.

Identifiers compared, on their own terms

None of these standards is wrong. They were each built for a different job, and a tokenized fund touches several of them at once.

ISIN and CUSIP do exactly what fund operations have relied on for decades: they give the instrument a globally recognized code that clearing and reporting systems already understand. The limitation is scope, not accuracy. Neither has a concept of a deployment on a specific chain, so when one fund lives on many networks, they name the fund correctly but cannot distinguish the versions. DTI (ISO 24165) is the ISO route to a machine-readable digital token identifier and is a serious effort in this space. DASID is a separate, human-readable standard that sits alongside it, aimed at the reference-data ergonomics that operations and risk teams work with directly.

What changes for the people who run tokenized funds

The benefits are concrete once a shared identifier exists across deployments.

• Automated reconciliation instead of address-matching: a custodian can roll up holdings of the same fund across four chains into one position without a human deciding which contract addresses belong together.
• Cleaner audits: an auditor can trace one canonical identifier down to each onchain deployment and verify balances, rather than accepting a spreadsheet that asserts the mapping.
• Faster onboarding of new chains: when a fund adds a fifth network, the new deployment inherits the same canonical identity with a new suffix, so downstream systems recognize it immediately instead of treating it as a brand-new asset.
• Accurate exposure reporting: a risk team can answer "how much of this fund exists and where" from the identifier itself, which is difficult when the only keys are unrelated contract addresses.

Tokenized funds are a subset of tokenized securities, and many of the same reference-data pressures show up there. If your question is specifically about tokenized equities and other securities, our guide to identifiers for tokenized securities covers that adjacent case.

Risks and open questions

A new standard is only useful if it is adopted, and honesty about status matters here.

• DASID is new. It was published as v0.1 in 2026. A reference registry is in progress and a resolution API is planned, but they are not live, so it is not yet something you can wire into production as a lookup service today.
• Standards compete and coexist. DTI, FIGI, and DASID solve overlapping problems in different ways. Firms may need to map between them rather than pick one, and mapping tables carry their own maintenance cost.
• Governance and canonicality. Any identifier that claims to be "canonical" depends on a trusted issuer maintaining the mapping consistently. The value of the system rises and falls with the discipline of that maintenance.
• Multi-chain reality keeps moving. New networks, bridged versions, and wrapped representations of the same fund complicate the question of what counts as the same asset. A suffix scheme handles clean deployments well, but edge cases like wrapped or bridged tokens will test any standard.

For most teams the practical move today is to understand the layers clearly, track how the standards develop, and design the security master so that a canonical fund identity, its share classes, and its per-chain deployments are modeled separately. That structure pays off regardless of which identifier standard wins the most adoption.

Frequently asked questions

Why can't a contract address just be the identifier for a tokenized fund?

A contract address identifies exactly one deployment on one network. If the same fund runs on Ethereum, Solana, and Avalanche, it has three unrelated addresses, and nothing in those addresses tells a system they are the same fund. An identifier for tokenized funds needs to link every deployment to one canonical asset, which a raw contract address cannot do.

Doesn't a tokenized fund already have an ISIN or CUSIP?

Often yes, and those identifiers correctly name the fund as a security. Their limitation is that they have no concept of a per-chain deployment. They tell you which fund it is, but not which network a given onchain version lives on or that several addresses map to that single fund.

What does a security master need to hold for a tokenized fund?

At minimum it needs a canonical fund identity, a share-class identifier, a per-deployment network and contract address, the pricing and NAV source, and the issuer or administrator of record. Modeling the fund, its share classes, and its deployments as separate fields is what lets the record survive a fund adding a new chain or class.

What is DASID and who maintains it?

DASID (Digital Asset System Identification) is an open identifier standard for digital assets, including tokens, networks, protocols, and issuers. It is issued and maintained by Allium, the data infrastructure company for onchain finance. It was published as v0.1 in May 2026 and is one emerging option in a wider identifier landscape.

How does DASID handle a fund deployed on multiple chains?

DASID assigns one canonical code to the token and adds a colon-delimited network suffix for each deployment, for example TKN-USDC-001-ST-RB-3:ETH. Every per-chain version shares the same code before the colon, so systems can collapse many deployments into one fund identity while still resolving to a specific network.

Is DASID an industry standard I can use in production today?

Not yet. It is a new open standard published in 2026. The specification is defined, but a reference registry is still in progress and a resolution API is planned rather than live. It is worth understanding and tracking, but it is not a finished production lookup service at this stage.

How is DASID different from DTI (ISO 24165)?

DTI is the ISO digital token identifier, a machine-readable standard maintained through the ISO process. DASID is a separate, human-readable standard designed around the reference-data ergonomics that operations and risk teams work with. They address overlapping problems, and firms may end up mapping between them rather than choosing one.