Skip to content

Where each number comes from

Source bitcoinuniverseio/core (private)
Path backend provider registry, backend/packages/ecosystem-contracts/lib/protocols.js
Chain bitcoin, dogecoin
Network mainnet
Verified 2026-09-01

Every figure on a Core screen came from somewhere. This page names the paths, and the one request that answers the question for any protocol.

The three paths a figure takes to a Core screen

Path one: your browser asks the Core API, which reads Universe-operated Bitcoin and Dogecoin services. Path two: your browser asks the Core API, which reads an external provider for that protocol family. Path three, the dotted one: for TAP, DMT and UNAT deployment, mint progress and holder figures, your own browser fetches directly from a host Universe does not operate, bypassing the Core API entirely. The indexer-health endpoint reports which reader answered for every protocol.

Your browserCore in a tabCore APIapi origin, port 44301Universe-operated servicesChain, fees, blocks, addresses, ordinals02External providerFor some protocol families03A host Universe does not operateTAP, DMT, UNAT deployment and mint figures

Path 3 is the only case where a request leaves your own browser to a host Universe does not operate. The pages that show that data name it.

Chain height, blocks, transactions, address activity, address UTXOs, and fee estimates come from Universe-operated Mempool and Ordinals services. Internal protocol indexers use the same operator-owned block routes to verify chain continuity.

There is no public-provider fallback. If that source is unavailable, the API answers with an explicit unavailable response rather than a zero or a stale value.

Path 2: an external provider, through Core

Section titled “Path 2: an external provider, through Core”

Some protocol families are read through an external provider rather than a Universe-operated index. That is stated on the coverage page rather than hidden, and each protocol’s page names the provider.

The clearest examples: BRC-20 reads the UniSat Open API, and the registry adds that order freshness and inventory reconciliation are delegated there. Stamps and SRC-20 read StampDEX. Mezcal reads the mezcal.sh API. Alkanes reads an external Alkanes API set.

Core validates the exact proxy route and body it allows, but it does not compare an external provider’s tip with the Bitcoin tip. Several registry entries say so in those words.

TAP, DMT, and UNAT are a further step removed. Their deployments, mint progress, and holder counts are fetched by your own browser from a host Universe does not operate. They do not pass through a Universe index at all, so their availability and freshness are that host’s rather than Core’s.

Those three rows name their read source on the coverage page, and the same sentence appears on /index/tap, /index/dmt, and /index/unat beside the numbers it applies to.

The USD figures next to Bitcoin amounts come from one Universe-operated market price service, read by the browser once a minute. No exchange API is called from the page. Fiat prices covers what happens when it cannot answer.

One request answers it for all 29 at once:

Terminal window
curl -s https://api.bitcoinuniverse.io/indexer-health \
| jq -r '.data[] | [.protocolId, .indexerIdentity, .source,
.lag, (.lastSuccess // "never")] | @tsv'
FieldWhat it tells you
configuredIndexers.primaryWhat the registry declared
indexerIdentity, sourceWhat actually answered. Believe this pair
lag, tip, nodeTipHow far behind it was
lastSuccessnull means it has never been read successfully
status, reasonCode, reasonsWhy it is in the state it is in

Every material page here carries a source strip under its heading naming the owning repository, the path the facts were read from, the chain and network it applies to, and the date a maintainer last checked it against the product. The protocol pages go further: they are generated from a snapshot whose own provenance block names the exact Core commit it was taken from.