Market Data for Tokenized Assets: Identity, Price, Evidence
Exchange feeds tell a desk where the price is. Onchain settlement data tells it where the money actually moved. Pricing, marking and reporting a crypto book requires both, and they rarely agree out of the box.
The hardest question in market data for tokenized assets is not the price. It is what the thing is. A single economic asset can exist at once as a tokenized wrapper (a blockchain representation of a security or fund) on several chains, as the traditional instrument you already hold with a CUSIP or ISIN (the standard reference identifiers used across capital markets), and as positions sitting on several trading venues. Before anyone can price it or report it, all of those have to resolve to one asset. Today most institutions do that by hand.
If you have never touched crypto, here is the plain version. Tokenization means issuing a claim on a real asset, a Treasury fund, a stock, a dollar deposit, as an entry on a blockchain, which is a shared ledger that many parties can read and no single party can quietly edit. The appeal for an institution is that the token can settle in minutes, trade outside normal market hours, and move without a chain of intermediaries. The catch is that the same fund can be issued on three different blockchains, each version with its own address, and none of them announces on its own that it maps back to the instrument sitting in your book under an ISIN.
Why this is a data problem, not a trading problem
Think of a bond you own in a traditional account. It has one identifier, one custodian record, and one closing price you can defend to an auditor. Now imagine that same bond also existed as three separate blockchain entries, each priced on a different venue, some of them trading at 2am on a Sunday. Nothing tells you those four things are the same bond. That is the situation an institution walks into the moment a security is tokenized.
The people who feel this are not crypto trading desks. They are the teams inside banks, asset managers and broker-dealers responsible for tokenized securities, real-world assets (RWAs, meaning traditional assets represented onchain) and stablecoins (tokens designed to hold a fixed value, usually one dollar). Their problem is reconciliation, not speed. They need three things, in this order.
One asset, one market view
The first job is identity: mapping every wrapper, on every chain, on every venue, back to the reference data the institution already uses. A tokenized Treasury fund issued on Ethereum and bridged to two other chains is one holding, not three, and it has to tie back to the fund's identifier in the systems your finance and risk teams already run.
This is what canonical identity means. Allium's DASid does exactly this narrow thing: it assigns a stable identity to a tokenized instrument and maps it back to the instrument it represents, so a position is one number regardless of how many chains it lives on. Without that mapping, an analyst is reconciling symbols and venue datasets by hand, and the map goes stale every time a new chain or a new bridged version appears.
The significance goes beyond one firm's operations. When the Federal Reserve cited Allium data on tokenized assets, and when Bloomberg cited Allium data on tokenized pre-IPO stock volume, the underlying requirement was the same: to say anything true about a tokenized market, you first have to agree on which tokens represent which assets.
One view of price and liquidity across fragmented markets
Once identity is settled, the second job is knowing where the asset actually trades and what executing there would cost. Tokenized assets trade across many venues, spot and perpetual, and they do not stop when traditional markets close. A price you saw on one venue at one moment tells you very little if the same asset was trading in more size somewhere else.
To be exact about what this article claims: Allium normalizes onchain trade and transfer records so that activity across chains and venues resolves to one asset. It does not supply centralized exchange order books, quotes or funding rates, and it is not the place to compete on raw feed speed. The value here is a consolidated, reconcilable view of onchain trading conditions, not the fastest tick.
Data you can act on and defend
The third job is evidence. A number is only useful to a regulated institution if it can be reproduced months later for an auditor, a regulator or a client. That means a transparent methodology, historical records you can reconcile against, and inputs you can pull up again and get the same answer.
The relevant standard here is documented controls, not a certification of any single dataset. Allium is covered by a SOC 2 Type II report, an independent attestation of an organization's controls over a period of time. It attests to controls at the organization, not to any individual field or pipeline.
A worked position, priced and evidenced
Take one illustrative holding at end of day: a tokenized US Treasury fund the institution issued on one chain and later bridged to a second. The book has to answer three questions with numbers, not with a yes or no.
| Question | Value | How it resolves | Evidence behind it |
|---|---|---|---|
| What do we hold? | 10,000 units total (7,000 on chain A, 3,000 on chain B) | Both contract balances map to one fund identity via canonical identity | Block-level balances per address and contract, joined to the fund's reference ID |
| What is it worth? | $10,020,000 | 10,000 units at a $1,002.00 mark from a fixed pricing policy applied at the chosen daily timestamp | Named price source plus timestamp recorded in the pricing methodology, reproducible on rerun |
| Can we prove it? | Yes for the quantity and timestamp; the price leg is only as defensible as the written policy | Onchain records fix quantity, contract and time; policy fixes the price input | Normalized settlement records for quantity and time, retained pricing policy for the mark |
The mark is defensible when the two onchain balances, the fund's reference record, and the internal ledger all reconcile to the same 10,000 units, and when the $1,002.00 price traces to a source and timestamp anyone can rerun. Change the price policy and the number changes, which is why the policy, not the number, is the thing to write down and keep.
The field-level problem underneath all three
To compare that fund on chain A with its bridged version on chain B, and then against the reference instrument, every record has to resolve to the same fields: asset, issuer, chain, contract, sender, recipient, amount, USD value at a chosen timestamp, and transaction type such as transfer, mint or burn. Raw blockchain nodes do not hand this over. They return low-level, chain-specific logs and encoded call data, and a transfer on one chain does not decode into the same shape as the same transfer on another. A team that builds this in-house spends its time writing and maintaining decoders, and every new chain restarts the work.
Allium normalizes onchain records across 150+ blockchains into standardized fields and verticals including stablecoins, RWAs, lending and staking, delivered through databases, APIs and data streams. That normalization is what lets a reconciliation join a position on one chain to the same position on another and back to the instrument the institution already holds. Allium's RWA datasets and its research and strategy use case document the specific fields available.
How a team wires this together
- Enumerate the universe. For every instrument, list the reference identifier (CUSIP or ISIN), each wrapper's chain and contract address, and each venue where it trades.
- Resolve identity. Map every wrapper and venue symbol to one canonical asset that ties back to the reference record.
- Ingest normalized settlement. Pull transfers, balances, mints and burns for the contracts in scope as standardized fields.
- Fix a pricing methodology. Choose the price source and timestamp for marking, and apply it consistently so marks are reproducible.
- Apply a finality rule. Set a per-chain confirmation threshold before treating an inbound transfer as settled.
- Reconcile on a schedule. Compare internal records against normalized onchain data, and retain the lineage so any number can be traced to a source.
Choosing an access model to fit the job
The same data can arrive three ways, and the right one depends on the job.
| Access model | Best fit | Latency profile | Typical consumer |
|---|---|---|---|
| Real-time stream | Position monitoring, deposit crediting | Lowest, event-driven | Operations, alerts |
| API query | On-demand position and balance checks | Low, request-driven | Applications, internal tools |
| Database / warehouse | Reconciliation, reporting, research | Batch, correctness first | Finance, risk, research |
Reporting and reconciliation, the parts that face an auditor, usually run against warehouse access where completeness and reproducibility matter more than speed. For teams deciding how to serve that data internally, the tradeoffs between SQL access versus APIs in institutional blockchain systems matter as much as the data itself.
What is still unsettled
Identity mapping is never finished. New chains, new bridged versions, and contract migrations mean the map from wrapper to instrument keeps changing. A stale map silently understates or double-counts a holding.
Pricing methodology is a judgment. Two defensible price sources at the same timestamp can produce different marks. The exposure is the absence of a written, consistently applied rule, not the number itself.
Finality is a policy choice. Confirmation thresholds trade settlement risk against capital tied up while waiting. The chain does not tell you when a transfer is safe to credit; you decide.
Regulatory treatment is still forming. How a tokenized security is treated for custody, settlement and reporting is being worked out in several jurisdictions and is not fully resolved. Practitioners are watching questions such as how 15c3-3 applies to tokenized securities, what atomic settlement means for tokenized securities, and what role a central securities depository plays. None of this is legal advice; it describes the state of play.
Allium provides onchain data infrastructure. Companies named in this article may be Allium customers, prospects or commercial counterparties. This article is informational only and is not investment, legal or tax advice. Data and information last reviewed: September 25, 2026.
Interested in learning more about Allium's onchain data infrastructure? Speak to someone on the team.
Frequently asked questions
What makes market data for tokenized assets different from ordinary market data?
The core difficulty is identity, not price. One economic asset can exist as a tokenized wrapper on several blockchains, as a traditional instrument with a CUSIP or ISIN, and as positions on several venues. Before it can be priced or reported, all of those have to resolve to one asset that ties back to the reference data an institution already uses.
What is canonical identity, and what does DASid do?
Canonical identity means every wrapper, chain and venue symbol maps to one asset. Allium's DASid assigns a stable identity to a tokenized instrument and maps it back to the instrument it represents, so a holding is one number regardless of how many chains it lives on.
Does Allium supply exchange order books, quotes or funding rates?
No. Allium normalizes onchain trade and transfer records so activity across chains and venues resolves to one asset. It does not supply centralized exchange order books, quotes or funding rates, and it does not compete on raw feed speed.
How does an institution make a tokenized-asset mark defensible?
By fixing a written pricing methodology, the price source and timestamp used to value a holding, and applying it consistently. Onchain records fix the quantity, contract and time; the pricing policy fixes the price input. A mark is only as defensible as the policy behind it, which is why the policy should be documented and retained.
What does SOC 2 Type II mean for a data provider?
SOC 2 Type II is an independent attestation report on an organization's controls over a period of time. Allium is covered by such a report. It attests to controls at the organization, not to any single field, dataset or pipeline.
Why can't a team just read tokenized-asset data from blockchain nodes directly?
Raw nodes return low-level, chain-specific logs and encoded call data. Turning that into standardized fields such as asset, issuer, chain, contract, sender, recipient, amount, USD value and transaction type requires per-chain decoders that must be maintained and rebuilt for every new network. Many teams consume already-normalized data instead so their analysts reconcile positions rather than write decoders.