Why do two crypto sources disagree about the same coin?

Ask two data providers for bitcoin's closing price on a given day and you will very likely get two different numbers. Neither is an error. The reason is structural and it is worth understanding precisely, because the same reasoning applies to any market without a primary venue.

There is no primary exchange

A US-listed stock has a listing exchange and a consolidated tape. Bitcoin has neither. Dozens of venues trade it simultaneously, each with its own order book, its own participants and its own price at any instant. There is no mechanism that forces them to agree and no authority that publishes an official print.

So a single number labelled BTC-USD is necessarily an aggregate, and every aggregate needs a method:

• Which venues are included, and which are excluded for being too small or too suspect?
• Weighted how — by volume, equally, by some liquidity measure?
• Sampled when — at a single instant, or averaged over a window?

Change any of those three and the answer changes. Two providers making different defensible choices produce different numbers, and asking which is correct is the wrong question. Crypto Markets and Data goes into why prices fragment and how much reported volume is real; the point for a data consumer is narrower: the number is a construction, so record whose construction it is.

And no official close either

The previous lesson established that crypto trades every calendar day. That creates a second, independent source of disagreement: with no closing bell, a "daily close" is whatever instant the provider cut the day at. Midnight UTC is the most common choice. It is still a choice.

This vendor writes its choice down. /exchange-details/CC reports Timezone UTC, TradingHours from 00:00:00 to 23:59:00, all seven WorkingDays and an empty ExchangeHolidays, so a .CC daily bar is one UTC calendar day. Whatever the other source uses, that is the half of the comparison you can state exactly.

Two providers using midnight UTC and 17:00 New York will disagree on every single daily bar, forever, by however much the price moved in those hours. On a quiet day that is small. On a volatile one it is not.

What the row itself tells you

Some of this is visible without leaving the response. Two observations from the live sample /eod/BTC-USD.CC?from=2026-07-10&to=2026-07-27:

adjusted_close equals close on every row. There are no splits and no dividends in a coin, so the column is structurally empty in the same way it is for FX. If you are testing adjustment logic, crypto is not your test case.

The precision changes at the newest bar. Values in this window carry the fingerprint of 32-bit floats — 64127.140625, 63802.02734375, .359375 — while the bar for the day of the pull itself read 65340.588834828 at full double precision. Two paths feed one series: a live path that hands you the freshest bar at whatever precision it computed, and a historical store that later rewrites the same bar onto the 32-bit grid. Re-fetch the identical window a month later and the exception is gone — 65340.588834828 has been rounded to 65340.58984375, which is now simply the open of 2026-07-27, and that day's close settled at 63724.8984375. The seam is not a fixed date in the series; it sits at the newest end and moves with it (on 28 September 2026 it was the bar before the newest that carried full precision). It is harmless in itself and it teaches something general. If you compare a stored historical value against a freshly fetched one and they differ in the eighth decimal place, that is why, and it is the reason exact equality comparisons on floating-point prices are a bug in any market-data code. Compare with a tolerance, always.

Do not average the disagreement away

The instinct when two sources differ is to take the mean. Resist it. An average of two aggregates built with different venue sets and different cut-offs is a third construction that nobody documented and that you cannot explain to anyone who asks.

The workable rule has three parts:

1. Find out the method — venues, weighting, cut-off — for each source.
2. Pick one and stay with it. Consistency inside a series matters far more than being right about a level that has no single right answer.
3. Record the choice next to the data, so that when the numbers are compared against someone else's a year from now, the difference is explainable rather than alarming.

This is the trust-but-verify discipline from Reading the Market, applied to a market where the ambiguity is not a flaw in the data but a property of the thing being measured.

Try it now

1. Take one date's close from /eod/BTC-USD.CC?filter=last_close and the same date from a second, independent source, and measure the gap in percent. Then find each one's stated cut-off time. The gap should stop looking mysterious.

2. The table in step 1 is the pattern: binary fractions in the decimals, .140625, .02734375, .359375. Here are the newest bars of /eod/BTC-USD.CC, read on the date beside the title. Find the close that does not fit the pattern and say which path it came from. When this was written on 28 September 2026 the odd one out was the second newest, not the newest, so do not assume the seam sits on the last row; check each one.

3. Write one sentence of provenance for a crypto series you use: source, aggregation method if published, and cut-off. If you cannot fill in all three, you have found what to ask about. For this data the cut-off is stated in the venue record below; say which field gives it to you.