Moonlytics.io
Infrastructure / Entity resolution

Entity resolution

A digital asset has no universal identifier. Every provider invents its own, symbols collide, names change and prose carries neither. Resolution is the step that decides, for every incoming record, which asset it is about.

The problem

An equity has an ISIN. A digital asset has nothing of the kind. What it has instead is a different identifier at every provider, a ticker it may share with several unrelated projects, a display name it can change at will, and — for tokens — a contract address that differs per chain and per bridged wrapper.

one asset, three provider records
# The same asset, as three providers describe it

market aggregator     id: 1              symbol: BTC    name: Bitcoin
metadata provider     id: "bitcoin"      symbol: btc    name: Bitcoin
news extraction       (no identifier)                   name: "Bitcoin"

# Nothing here is a shared key. The only stable join is one
# Moonlytics assigns and holds itself.

Merge those incorrectly and every downstream number is wrong in a way that looks entirely plausible. A price attached to the wrong project does not throw an error; it produces a chart.

How bad the collision problem actually is

225
symbols shared by more than one asset
460
assets involved in a collision
3
assets on the most contested tickers
HYPER, NEIRO, SEND and others
7,461
assets in the registry

Measured across the production registry on 2026-08-31. Browse every collision.

Roughly one asset in sixteen shares its ticker with something else. Any pipeline that treats a symbol as a key is not handling a rare edge case — it is wrong about six percent of its universe.

The resolution rule

The rule the layer holds to is short: resolve on provider identifiers, never on symbols or names.

Provider Amarket aggregator
numeric idsymbolname
Provider Bmetadata provider
slug idsymbolnamechannels
Provider Cnews extraction
entity mentionno identifier
Entity resolution
exact match on provider idconfirmed manual linkambiguous → do not merge
Canonical asset
stable Moonlytics idall provider ids attachedone identity downstream
the canonical record the merge produces
{
  "id": 1,
  "symbol": "BTC",
  "name": "Bitcoin",
  "providers": {
    "market": 1,
    "metadata": "bitcoin"
  }
}

What the rule means in practice

  • A known provider identifier resolves. Deterministic, no heuristics, no ambiguity.
  • An unseen provider identifier creates a new asset. The layer would rather hold two records that later turn out to be one asset than one record that is silently two. Splitting is recoverable; a bad merge is not.
  • Cross-provider links are confirmed, not guessed. Attaching a metadata slug to a market identifier is a deliberate act, recorded on the asset. Where that link was corrected by hand, the record carries an explicit override flag.
  • Ambiguity does not merge. A news mention that could plausibly refer to two assets is delivered unmapped. Precision beats recall here, because a wrong attribution propagates and an absent one does not.
Why splitting is the safe failure

If two records for the same asset are held separately, the symptom is a duplicate in a list — visible, annoying, fixable by adding a link. If two different assets are merged into one, the symptom is a series that silently contains two projects' prices. Nobody notices until a conclusion has already been drawn from it. The asymmetry is why the resolver is conservative.

Names and symbols change; identifiers do not

Projects rebrand. A ticker is retired and reused by something unrelated. A token migrates and the new deployment takes the old name. In every one of those cases the canonical identifier stays put and the display fields are updated in place, so a series spanning a rebrand remains one continuous series about one asset.

The corollary matters for anyone integrating: do not cache a symbol as a key. Cache the canonical identifier. Symbols are display data.

What is not solved yet

Contract-level identity

Resolution today operates on provider identifiers. It does not yet resolve on network plus contract address, which means a token and a bridged wrapper of it are distinguished only as far as the upstream providers distinguish them. Address-level identity is planned and will be documented on asset metadata when it exists.

What is deliberately not published

The specific matching rules, confidence thresholds and manual review queue that make resolution work are not documented publicly. Describing them precisely would be a manual for producing records that resolve the way an author wants rather than the way reality does.

Related