Two crypto data providers can list the same assets and still hand you different numbers. The questions that separate providers are about provenance: which markets went into a number, which moment it describes and whether you can check it yourself. The W3C defines provenance as information about the entities, activities and people that went into producing a piece of data. A coverage count says nothing about any of that. Below are five questions and a checklist you can paste into an RFP.
Why coverage counts decide less than you expect
A coverage count tells you how many rows a catalog has. It does not tell you how any row was made. Two catalogs of equal length can differ in what each number is built from, how fresh it is and what happens when an input misbehaves.
Coverage still works as a filter, because a provider without your assets cannot help you. Apply it, then spend the rest of the evaluation on provenance. A label such as “institutional grade” states an intention. The questions below turn it into evidence you can ask to see.
Question 1: Where is the price born?
A published price is a summary of markets, so ask which markets. Some providers draw on lists of centralized exchanges. Others read on-chain liquidity pools. Some mix both. The answer decides what the number means: a reading built from order books describes those books. A reading built from pools describes those pools.
Then ask how the markets become one number. Is there a written methodology that says enough for you to see how the number is derived and to judge whether it represents the market you care about? The Principles for Financial Benchmarks, published by IOSCO in July 2013 after investigations into attempted manipulation of interest rate benchmarks, state the same expectation in Principle 11. The methodology should be documented and published or made available, with enough detail for stakeholders to understand how the benchmark is derived and to assess its representativeness.
That text is written for administrators of financial benchmarks, not for crypto data providers, so read it as a public reference for what a methodology document can cover.
A provider may keep exact formulas private. The composition behind one reading is a separate question: which venues contributed and how much each one counted.
Question 2: Which moment does the number describe?
A number needs a timestamp that says which moment of the market it describes. Ask what the timestamp means: when the market was observed, when the provider computed the number or when it reached you. The three can differ. For valuation or audit work you want the moment of observation. Ask whether a past reading can be reproduced as of that moment.
Ask also where the record starts. History usually begins on the day collection began, which can differ by asset and by chain, so ask for a start date per asset.
Then ask what happens when a market goes quiet. Some pairs do not trade for hours. A provider can carry the last observed price forward, show an older reading with its age or stop publishing. Each of these can be reasonable if it is disclosed. What you want is a feed that says which one is happening, so an old number is never mistaken for a fresh one. IOSCO’s Principle 11 points the same way: the methodology should cover procedures for periods of market stress or disruption and for periods when data sources may be absent.
Question 3: Can you verify it yourself?
Verification has a cost that depends on the input. If a reading is built from public chain state pinned to a block, anyone with node access can read the same inputs. With the method in hand they can recompute the result. If it is built from private venue feeds, checking runs through the provider’s own records and your contract. Both arrangements exist. What matters is that you know which one you are buying.
Useful follow-ups:
- What would a third party need to reproduce one reading?
- Can you retrieve the composition of a reading from last quarter, not just today’s?
- How long are records of inputs kept? IOSCO’s Principle 18 asks benchmark administrators to retain written records of market data and of deviations from standard procedures for five years, subject to local law.
Question 4: Who runs the pipes?
Data quality is an operations discipline. Ask who monitors the pipeline and when: round-the-clock on-call or office hours. Ask for the written process for an anomaly, from detection to client notice. Ask whether post-mortems are shared with clients.
Ask how errors are corrected. IOSCO’s Principle 11 list includes procedures for error reports and for deciding when a revision applies. You want a revised value marked as revised, so a number you stored last week can be reconciled with the corrected one. Ask too how a change to the methodology is announced and with what notice. Principle 12 asks administrators to publish the rationale for a material change and the procedure for making it.
Finally, ask about service levels. Request availability and latency terms in writing, together with the way each is measured, since a figure without a measurement method cannot be compared with another provider’s figure.
Question 5: What proof of process exists?
ISO/IEC 27001:2022 is the standard for information security management systems. A system that meets it preserves the confidentiality, integrity and availability of information. Certification is optional. ISO notes that a certificate from an accredited body can add a layer of confidence.
Read the wording closely. A certificate covers a management system for information security. It does not say that a price is correct. Ask for the effective date, the issuing body and the scope. Ask whether the scope documents can be shared with you under NDA. Put the same questions to any other attestation a provider cites, such as SOC 2: is the report issued or is the audit still underway? For a longer treatment of the standard, see why ISO 27001 matters for Web3 data.
Before you sign
Three practical questions sit outside the five:
- What use does the licence allow: internal analysis, display to your own users or redistribution? The article on crypto market data licensing covers the distinctions.
- Which delivery path and support terms apply? Are they in the agreement?
- Can you test with your own asset list against real workloads before the contract is signed?
The one-page checklist
Copy this list into your RFP and ask each provider for written answers.
Markets
- Which markets feed each price: exchange order books, on-chain pools or a mix?
- Is the methodology documented with enough detail to see how a number is derived?
- Can you see which venues contributed to a reading and how much each counted?
Moment
- What does the timestamp mean: observation, computation or delivery?
- Can a past reading be reproduced as of its moment?
- From what date does the record start for each asset?
- How does the feed report a market that has gone quiet?
Verification
- What would a third party need to reproduce one reading?
- How long are records of inputs kept?
Operations
- Who monitors the pipeline and at what hours?
- What is the written process for an anomaly, from detection to client notice?
- How are errors corrected and revisions marked?
- How are methodology changes announced?
- Which availability and latency terms are written into the agreement?
Proof of process
- Which certifications apply: effective date, issuing body and scope?
- Is any other attestation issued or still in progress?
Commercial
- Which uses does the licence allow?
- Can you evaluate with your own assets before signing?
Applying the list to ML Data
ML Data is a data provider: the measurement layer that applications and oracle networks read from. The same questions apply to it. This is where its pages answer them.
- The trust page states the certification wording: ML Data is operated by Matrixedlabs Technologies - FZCO, whose information security management system is certified to ISO/IEC 27001:2022. The page gives the certificate number, the certification body, the scope and the dates. Scoping documents are available under NDA.
- The methodology page describes the approach behind each number.
- The coverage page lists the catalog, which spans stablecoins, liquid staking tokens, major assets and yield-bearing assets.
- The API page describes delivery.
Feed pages show a block time and the age of each reading beside the rate, with a status such as live, delayed or unavailable. Inside a feed page walks through one. To see it, open the ETH/USD feed page or browse the stablecoin prices and liquid staking token prices hubs. The design behind a number is in DEX-native price feeds explained.
Evaluation access is scoped so a team can test coverage, methodology and operational fit against real workloads before anything is signed.
Sources
- Principles for Financial Benchmarks: Final Report, The Board of IOSCO, FR07/13, July 2013 (copy hosted by the Japan Financial Services Agency)
- PROV-Overview: An Overview of the PROV Family of Documents, W3C Working Group Note, 30 April 2013
- ISO/IEC 27001:2022, Information security management systems, ISO
