Identifier for Tokenized Securities: A Clear Guide

An identifier for tokenized securities is a standardized code that points to a single financial instrument, such as a tokenized Treasury or money market fund share, no matter how many blockchains it is issued on. Traditional securities identifiers (ISIN, CUSIP) name the underlying instrument but have no concept of a per-chain deployment. Newer onchain-native identifiers add the missing layer, mapping each individual token contract on each network back to one canonical asset identity.

Key takeaways

• A tokenized security has two identities: the legal instrument (named by ISIN or CUSIP) and the onchain token (defined by a contract address on a specific chain). Neither identifier alone tells you both.
• The same tokenized fund can exist as separate contracts on Ethereum, Solana, and other networks. Without a common key, reconciling those deployments into one position is manual and error-prone.
• Legacy identifiers describe the security. Onchain-native identifiers describe each deployment and tie them together, which is what reference-data teams actually need.
• DASID, an open standard published in 2026 and maintained by Allium, is one current example of a human-readable identifier built for per-deployment mapping.
• This is a young space. Standards are still maturing, and no single onchain identifier is yet universal across the industry.

Why this matters now

Tokenized securities have moved from pilots to real balance sheets. Asset managers now issue tokenized money market funds, and tokenized U.S. Treasuries have become one of the most visible categories in real-world assets. Established firms have shipped products that live directly on public blockchains, and many of these instruments are intentionally issued on more than one network to reach different users.

That multi-chain reality is where identification breaks. A tokenized Treasury fund might have one ISIN and yet exist as three or four distinct token contracts, each with its own address, its own decimals, and its own transfer rules. A middle-office team trying to strike a net asset value or reconcile holdings has to know that all of these represent the same fund. When the mapping lives in a spreadsheet, it does not scale, and it does not survive an audit. For background on the instruments themselves, see how tokenized Treasuries work and why they matter and the broader guide to what tokenization is.

How an identifier for tokenized securities works

Different identifier systems solve different parts of the problem. Here is how the pieces fit, step by step.

1. The security gets a traditional identifier

When a tokenized fund or note is structured as a regulated security, it typically receives an ISIN and often a CUSIP, the same codes used for conventional securities. These name the instrument for clearing, custody, and regulatory reporting.

2. The token gets a contract address

Once issued onchain, the security becomes a smart contract on a specific blockchain. Its raw onchain identity is the contract address plus the chain it lives on. This is precise but not human-readable, and it changes with every new chain deployment.

3. Deployments need to be tied together

If the same fund launches on a second chain, that is a new address. Nothing in the contract address itself says the two are the same asset. This is the gap an onchain-native identifier closes.

4. A canonical identifier maps deployments to one identity

An onchain-native standard assigns one identifier to the asset and records each per-chain deployment underneath it. That way a query for the fund returns every contract that represents it, across every network, under a single key.

How DASID structures the identifier

DASID (Digital Asset System Identification) is an open, human-readable identifier standard for digital assets, covering networks, tokens, protocols, and issuers. It is issued and maintained by Allium, a data infrastructure company that standardizes onchain data across many blockchains. DASID is one concrete example of the onchain-native approach, and its design shows what these identifiers need to carry.

A DASID is a fixed, hyphen-delimited string of six segments: an entity type (three characters, such as TKN for a token), a ticker (three to five characters), a sequence number for collision handling (three digits), a primary class for hierarchical classification (two to four characters), a mechanism sub-type (two characters), and a check digit derived using the Luhn algorithm (one digit). Multi-chain deployments add a colon-delimited suffix, so a token that lives on Ethereum reads as something like TKN-USDC-001-ST-RB-3:ETH. The check digit lets systems catch typos before they become failed transfers, and the suffix is exactly the per-chain layer that ISIN and CUSIP do not model. You can read the full DASID standard at its source. Note that the specification is published (v0.1, May 2026) while the reference registry and resolution API are still in progress.

How this compares to established identifiers

Each existing standard does something well. The question is what layer it addresses. Contract addresses are exact but chain-bound. ISIN and CUSIP are trusted across finance but predate multi-chain issuance. The ISO Digital Token Identifier (DTI, ISO 24165) targets digital tokens directly but is machine-oriented rather than human-readable.

For a deeper side-by-side on the traditional codes, see digital asset identifier vs CUSIP and digital asset identifier vs ISIN. The full landscape is covered in the definitive guide to digital asset identifiers.

What changes in practice

Concrete before and after, for teams that hold or service tokenized securities:

• Reconciliation: Before, an operations analyst manually maps three contract addresses to one fund each morning. After, one identifier returns all deployments, so the position rolls up automatically.
• NAV and reporting: Before, a chain migration or a new deployment silently breaks a report that was hard-coded to a single address. After, the report references the canonical identifier and picks up the new deployment without a code change.
• Error prevention: Before, a mistyped contract address routes value to the wrong token. After, the check digit rejects the malformed identifier before anything settles.
• Cross-team communication: Before, front, middle, and back office each keep their own naming for the same asset. After, one human-readable key travels across systems and audit trails.

The same naming problem shows up outside securities. For how it plays out with dollar-pegged tokens, see how stablecoin identifiers work and the primer on what a stablecoin is.

Where the data underneath comes from

Any identifier is only as good as the ground truth it maps to. Knowing that a contract on one chain is the same asset as a contract on another requires clean, standardized onchain data across many networks. That reference data (which contracts exist, who issued them, how they behave) is the foundation an identifier registry sits on. For the basics of that layer, see what onchain data is.

Risks and open questions

• Adoption is early. Onchain-native identifiers are new. DASID's specification is published, but its registry and resolution API are still in progress, so it is not yet a settled industry default.
• Multiple standards coexist. ISIN, CUSIP, FIGI, DTI, and newer schemes all address overlapping needs. Institutions will likely have to map between several, not pick one.
• Governance matters. An identifier is only trustworthy if issuance rules, collision handling, and the registry are transparent and accountable. Who maintains it, and how, is as important as the format.
• Ground truth can be ambiguous. Wrapped tokens, bridged versions, and upgradeable contracts raise genuine questions about what counts as the same asset. These are policy decisions, not just technical ones.
• Regulatory alignment is unfinished. Reporting regimes still center on traditional codes, so tokenized-security identifiers have to interoperate with existing infrastructure rather than replace it. For the wider risk picture on onchain instruments, see this stablecoin risk guide.

The short version: a tokenized security needs both a securities identifier and an onchain-native one, because each answers a question the other cannot. As issuance spreads across chains, the value of a single canonical key that ties every deployment together only grows.

Frequently asked questions

What is an identifier for tokenized securities?

It is a standardized code that points to one financial instrument, such as a tokenized Treasury or fund share, regardless of how many blockchains it is issued on. In practice a tokenized security carries two identities: a traditional securities code (ISIN or CUSIP) for the legal instrument, and an onchain identity (a contract address, and increasingly an onchain-native identifier) for the token itself.

Why isn't a contract address enough to identify a tokenized security?

A contract address is exact but chain-bound. The same fund issued on Ethereum and Solana has two different addresses, and nothing in either address says they represent the same asset. An onchain-native identifier maps each per-chain deployment back to one canonical identity so the positions can be rolled up correctly.

How is DASID different from ISIN or CUSIP?

ISIN and CUSIP name the underlying security and are trusted across finance, but they have no concept of a per-chain deployment. DASID resolves the layer beneath them, assigning one human-readable identifier to the asset and recording each individual token deployment underneath it. DASID is meant to interoperate with existing codes, not replace them.

What does a DASID look like?

A DASID is a fixed, hyphen-delimited string of six segments: entity type, ticker, a sequence number, a primary class, a mechanism sub-type, and a Luhn-derived check digit. Multi-chain deployments add a colon-delimited chain suffix, for example TKN-USDC-001-ST-RB-3:ETH. The full specification is published at dasid.org.

Is DASID a live, adopted industry standard?

It is an open standard published in 2026 (v0.1, May 2026) and maintained by Allium. The specification is defined, but the reference registry and resolution API are still in progress, so it is an emerging option rather than a settled industry default. Multiple identifier standards currently coexist.

How does DASID relate to the ISO Digital Token Identifier (DTI)?

The DTI (ISO 24165) is the ISO standard for identifying digital tokens and is machine-oriented. DASID is a separate, human-readable standard focused on the reference-data needs of financial institutions, including per-deployment mapping. They address overlapping needs in different ways, and institutions may map between them.