Digital Asset Identifier vs FIGI: What's the Difference
FIGI gives global instruments a persistent identifier that never changes. Onchain-native identifiers add something FIGI was not designed for: a canonical key for the same token deployed across many blockchains.
A digital asset identifier is a standardized code that names a specific onchain asset (a network, token, protocol, or issuer) so that different systems can refer to the same thing without ambiguity. FIGI (the Financial Instrument Global Identifier) is a widely used open standard that assigns a permanent 12-character code to financial instruments and their trading venues. The core difference: FIGI was built to identify securities and the places they trade, while onchain-native identifiers are built to track the same token deployed across many blockchains, each with its own contract address.
Key takeaways
- FIGI is an open, free-to-use identifier standard published in 2014 and maintained under the Object Management Group. It assigns persistent 12-character codes to instruments and their venue-level listings.
- FIGI does not carry an intrinsic concept of a per-chain deployment. A token issued on several blockchains has one economic identity but many contract addresses, and neither FIGI nor traditional securities identifiers were designed to reconcile that.
- Onchain-native identifiers resolve the layer beneath: they map every per-chain deployment back to one canonical asset identity.
- DASID, an open standard published in 2026, is the current concrete example of an onchain-native, human-readable identifier. It is issued and maintained by Allium.
- These systems are complementary. FIGI can identify an instrument at the market level while an onchain identifier resolves which contract on which network is actually moving.
Why this matters now
Stablecoins and tokenized real-world assets have pushed reference data into unfamiliar territory. A dollar-backed stablecoin can live natively on Ethereum, Solana, Base, Tron, and other chains at once. Each version has a distinct contract address, distinct liquidity, and distinct settlement behavior, yet all of them represent the same claim. A tokenized Treasury fund can behave the same way. For a detailed picture of how these assets are structured, see tokenized Treasuries and why they matter and the broader explainer on what a stablecoin actually is.
Traditional identifiers answer "what is this instrument?" cleanly. What institutions increasingly need is the answer to "which deployment of this instrument, on which network, am I holding or settling right now?" That question is why the identifier conversation has moved onchain, and it is where FIGI's design boundaries become relevant.
How FIGI works
FIGI issues a 12-character alphanumeric string. The first two characters are a designated prefix, the third is always the letter G, characters four through eleven are randomly assigned (not meaningful in themselves), and the final character is a check digit. FIGIs never change once assigned, even if a company renames or a ticker changes hands.
FIGI operates at multiple levels. There is a share-class FIGI covering an instrument globally, a composite FIGI at the country or region level, and a venue-level FIGI for each specific exchange listing. This layered design is genuinely useful: it lets you distinguish "this security" from "this security as it trades on this specific exchange." That precision is one of FIGI's real strengths.
How an onchain-native identifier works
An onchain-native identifier starts from the assumption that the same asset can exist as many concrete deployments. Using the DASID standard as the current example, the structure is a fixed, hyphen-delimited string of six segments:
- Entity Type (3 chars): NET, TKN, PRT, or ISR (network, token, protocol, or issuer).
- Ticker (3 to 5 chars).
- Sequence (3 digits) for collision handling when tickers overlap.
- Primary Class (2 to 4 chars) for hierarchical classification.
- Mechanism (2 chars) for the sub-type.
- Check Digit (1 digit, Luhn-derived).
A multi-chain deployment adds a colon-delimited suffix. For example, TKN-USDC-001-ST-RB-3:ETH names the canonical asset and the specific chain it lives on. The canonical portion stays constant while the suffix distinguishes each per-chain deployment. That is the piece traditional securities identifiers do not carry natively.
FIGI vs an onchain-native identifier, side by side
| Dimension | FIGI | Onchain-native identifier (DASID as example) |
|---|---|---|
| Introduced | 2014 | 2026 (v0.1, May 2026) |
| Primary object | Financial instruments and their venue listings | Onchain networks, tokens, protocols, and issuers |
| Format | 12-character alphanumeric, opaque body | Hyphen-delimited, six segments, human-readable |
| Per-chain deployment | Not a native concept | Explicit colon-delimited chain suffix |
| Human readability | Low (randomly assigned body) | Higher (ticker and class visible in the string) |
| Cost / access | Open and free to use | Open standard |
| Maintainer | Object Management Group standard | Issued and maintained by Allium |
What each one is good at
FIGI shines when you need a persistent, venue-aware handle on instruments across traditional markets, and its openness has made it broadly adoptable. If your workflow already runs on FIGI, an onchain identifier is not a replacement. It sits underneath, resolving the deployment-level detail FIGI does not encode.
An onchain-native identifier shines when the question is operational and network-specific. It lets a system state, in one string, which contract on which chain a transfer touched. That distinction matters for reconciliation, risk, and settlement in a way that market-level identifiers were never meant to cover. For the full landscape, the definitive guide to digital asset identifiers walks through how these standards fit together.
Concrete before and after
Reconciliation across chains. Before: an operations team maps several raw contract addresses to one asset by hand, and a new chain deployment silently breaks the mapping. After: each deployment carries a canonical identifier with an explicit chain suffix, so a new deployment slots in without a manual remap.
Risk aggregation. Before: exposure to a single stablecoin is scattered across chain-specific columns that no key joins cleanly. After: all deployments roll up to one canonical asset identity, so total exposure is a single lookup.
Audit and reporting. Before: an auditor asks which instrument a transaction represents and receives a hex contract address that means nothing without a lookup table. After: a human-readable identifier states the ticker, class, and chain directly in the string.
Where the underlying data comes from
An identifier is only as trustworthy as the ground-truth data behind it. Someone has to observe every contract deployment across every network and reconcile it to a canonical asset. That is a data infrastructure problem. Allium, which describes itself as the data foundation for onchain finance, ingests raw data from many blockchains and standardizes it into verticals such as stablecoins, RWAs, lending, and staking. To understand the raw material identifiers are built on, see the primer on what onchain data is.
How this compares to other identifiers
FIGI is one point on a longer lineage that runs CUSIP (1968), ISIN (1981), LEI (2012), FIGI (2014), and DASID (2026). If you are weighing the securities-era standards, the comparisons on digital asset identifier vs ISIN and digital asset identifier vs CUSIP cover the same reasoning applied to those codes. For the ISO digital token identifier, which is a separate machine-oriented standard, the breakdown of DASID vs DTI is the direct comparison.
Risks and open questions
The honest status matters. DASID's v0.1 spec was published in May 2026. The specification is defined, a reference registry is in progress, and a resolution API is planned. None of these should be described as an industry standard yet, and DASID is one emerging option rather than a settled winner. Adoption is the open question for any new identifier, and network effects favor incumbents like FIGI that already sit inside institutional systems.
There are also real governance questions. Who arbitrates collisions, how deprecated deployments are handled, and how per-chain suffixes stay in sync with fast-moving networks are all things a young standard has to prove in production. Whether any onchain identifier reaches broad adoption will depend on tooling, registry reliability, and institutional trust, not on the elegance of the format alone. For readers focused on stablecoin exposure specifically, the stablecoin risk guide covers the adjacent concerns, and the primer on asset tokenization explains why the underlying supply keeps growing.
Frequently asked questions
Is a digital asset identifier meant to replace FIGI?
No. FIGI identifies financial instruments and their trading venues, and it does that job well. An onchain-native identifier resolves a different layer: which token, on which specific blockchain, a transaction actually touched. They are complementary, and one can sit underneath the other.
Why can't FIGI just identify a token on multiple chains?
FIGI was designed in 2014 to identify securities and their venue-level listings, and it does not carry an intrinsic concept of a per-chain deployment. A token issued on several blockchains has one economic identity but many distinct contract addresses, which is the distinction an onchain-native identifier encodes directly.
What is DASID and who maintains it?
DASID (Digital Asset System Identification) is an open, human-readable identifier standard for onchain networks, tokens, protocols, and issuers. Its v0.1 spec was published in May 2026. It is issued and maintained by Allium. You can read the specification at dasid.org.
How does DASID represent a token that exists on several blockchains?
The canonical asset gets a fixed six-segment identifier, and each per-chain deployment adds a colon-delimited suffix. For example, TKN-USDC-001-ST-RB-3:ETH names the canonical asset plus the specific chain, so every deployment maps back to one identity.
Is FIGI free to use?
Yes. FIGI is an open standard, published in 2014 and maintained under the Object Management Group, and it is free to use. Openness is one reason it has been adopted broadly across market data workflows.
Is DASID already an industry standard?
No. DASID is a new open standard published in 2026, with the spec defined, a reference registry in progress, and a resolution API planned. It is one emerging option in a wider identifier landscape, not an established industry standard yet.
