From e8d1c61b390cb2825572d78a4d6a5af106edbb9c Mon Sep 17 00:00:00 2001 From: Ben Cairns Date: Mon, 31 Aug 2026 08:45:06 -0500 Subject: [PATCH 1/2] sources: conform Code on IDs 4 and 5, and fix the version table Registry 1.3.1, editorial. 1.3.0 made Code name the venue rather than the matching engine, and left IDs 4 and 5 carrying SETAI_FINANCIALS and SETAI_COMMODITIES as a documented exception, on the grounds that a Code already in use downstream cannot be changed without coordination. That reasoning holds for the publishing venues and not for this one. Nothing carries these two values: the venue has no publisher, no metric series and no registered multicast group. A grep of this repository finds them only in the two table cells and the sentence explaining why they could not change. Both now read SETAI, and the exception paragraph is removed rather than reworded. The window for this closes at first deploy, since dz-publisher-metrics stamps venue and source_id on every series. Also corrects the VERSIONING.md row, which still read 1.2.0 after 1.3.0 moved sources/spec.md. That table is the fleet view and was the only place stating the wrong version. --- VERSIONING.md | 2 +- sources/spec.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/VERSIONING.md b/VERSIONING.md index 4c04037..7d19211 100644 --- a/VERSIONING.md +++ b/VERSIONING.md @@ -39,7 +39,7 @@ The current state of every feed: | [Order-Intent](./order-intent/spec.md) | `0x494F` | `3` | 3.0.1 | | [Perp Stats](./perp-stats/spec.md) | `0x4450` | `3` | 3.0.1 | | [Reference Data Distribution](./reference-data/spec.md) | *(host feed's)* | *(host feed's)* | 1.0.2 | -| [Source ID Registry](./sources/spec.md) | *(none)* | *(none)* | 1.2.0 | +| [Source ID Registry](./sources/spec.md) | *(none)* | *(none)* | 1.3.1 | | [Glossary](./GLOSSARY.md) | *(none)* | *(none)* | 1.3.0 | Midpoint sits at `1` while its siblings are at `3` because it was deliberately left on its 64-byte `InstrumentDefinition` variant when the shared layout changed at both `2.0.0` and `3.0.0`. This is the scheme working as intended: the specs are siblings, not a single versioned family, and a decoder reads each feed's byte to know which layout it is holding. diff --git a/sources/spec.md b/sources/spec.md index 5871495..14ffa95 100644 --- a/sources/spec.md +++ b/sources/spec.md @@ -6,7 +6,7 @@ A Source ID identifies the **matching engine** whose activity the message descri **A Source ID names a matching engine, not a venue.** One venue may run several matching engines and therefore hold several Source IDs. Two engines are distinct where their order-matching rules differ, and equally where they match independently over disjoint instrument sets under identical rules; a capacity shard the venue can rebalance is a channel rather than an engine. [GLOSSARY.md](../GLOSSARY.md) carries the full test and is the authority for it. A new engine at an already-registered venue is a new ID rather than a reuse of that venue's existing one. Because IDs are never renumbered, this only ever adds, and an ID already assigned keeps meaning whichever engine has been publishing under it. Venues split their own engines on their own schedule, so treat the set as open rather than assuming the current table is final. -This document specifies version **1.3.0**: the reserved ranges, the current assignment set, and the process for requesting a new ID. +This document specifies version **1.3.1**: the reserved ranges, the current assignment set, and the process for requesting a new ID. ## Reserved Ranges @@ -24,16 +24,14 @@ This document specifies version **1.3.0**: the reserved ranges, the current assi | `1` | Hyperliquid | `HYPERLIQUID` | Hyperliquid | Perpetual DEX | | | `2` | Phoenix | `PHOENIX` | Phoenix | Perpetual DEX | | | `3` | Kalshi | `KALSHI` | Kalshi | Perpetual Futures, Prediction Market | Registered under the codename `Lashay` until the venue launched. Carries two matching engines and is due to split; see below. | -| `4` | Setai Financials | `SETAI_FINANCIALS` | Setai | Futures | Interface versioned separately from `5`. | -| `5` | Setai Commodities | `SETAI_COMMODITIES` | Setai | Futures, Options on Futures | Interface versioned separately from `4`. | +| `4` | Setai Financials | `SETAI` | Setai | Futures | Interface versioned separately from `5`. | +| `5` | Setai Commodities | `SETAI` | Setai | Futures, Options on Futures | Interface versioned separately from `4`. | | `6` | Binance USD-Margined Futures | `BINANCE` | Binance | Perpetual Futures, Dated Futures | The venue's own `futuresType` for this engine is `U_MARGINED`. Spot, coin-margined futures and options are separate matching engines at this venue, unclaimed, and will share this `Code`. | `Code` is the machine-readable short name **for the venue**. It matches the `Venue` column and takes the same name TradingView uses. Uppercase, never an abbreviation, each space and hyphen a single underscore. **Several matching engines at one venue share a `Code`.** It names the venue, not the engine, so `Code` alone cannot key an engine: `Source ID` is the engine key, and anything carrying `Code` as a stable identifier — a metric label value, a composed product identifier — needs `source_id` beside it to name an engine. `Name` is where a human reader tells two engines apart. -IDs `4` and `5` predate this rule and still carry engine-level Codes, `SETAI_FINANCIALS` and `SETAI_COMMODITIES`. They are left alone here: a `Code` already in use downstream cannot be changed without coordinating with whoever carries it. - Downstream systems already carry these values, so this column documents what exists rather than introducing anything new. This registry is the authority for it; any table of these values held elsewhere is a [registry mirror](../GLOSSARY.md) and is derived, never authoritative. `Venue` is the external exchange or market operator running the engine, as [GLOSSARY.md](../GLOSSARY.md) defines it. It is recorded separately from `Name` so that several engines at one venue are legible as such, which is the case the `Name` column alone cannot show. @@ -83,6 +81,8 @@ Because assigned IDs are stable and MUST NOT be renumbered, reordered, removed, ### Changes +**1.3.1** — editorial. Conformed `Code` on IDs `4` and `5` to the venue-level rule from `1.3.0`; both now read `SETAI`. No assignment changed and no ID was renumbered. + **1.3.0** — assigned Source ID `6` to the USD-margined futures matching engine at Binance, and made `Code` name the venue rather than the matching engine. Several engines at one venue now share a `Code`, so `Code` alone no longer keys an engine and `Source ID` is stated as the engine key. This supersedes `1.2.1`'s statement that `Code` names the matching engine and stays unique. IDs `4` and `5` keep their engine-level Codes, because a `Code` already carried downstream cannot be changed without coordination. **1.2.1** — editorial. Name the venue as TradingView does. `Code` is unaffected, because TradingView cannot name a matching engine. From 7e9069966f63ac8e5ab1862cb1f371bc557c0ca6 Mon Sep 17 00:00:00 2001 From: Ben Cairns Date: Mon, 31 Aug 2026 16:28:41 -0500 Subject: [PATCH 2/2] sources: add the MIC column, and record it as a qualifier for distinct engines MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Raised in review of the MIAX venue record: a distinct market identifier code is a good test for a tradfi venue that needs separate Source IDs. Recorded as a column rather than as prose, so it is a value a requester fills in rather than an argument they have to remember to make. Phrased as sufficient rather than necessary, because the converse fails badly. One MIC routinely covers several matching engines — that is the ordinary case wherever a venue runs spot and derivatives under one code, and it describes two of the venues already in this table. Stating it as a two-way test would have merged engines the rule above correctly separates. The column earns its place immediately: Kalshi is KLSH. An em dash means the venue has none, which is normal for a decentralised exchange and for any venue outside the standard's scope. Withheld means one exists but naming it would identify a venue trading under a codename, which is the state of IDs 4 and 5 — their MICs are public and would defeat the codename in a public registry. MINOR rather than PATCH: adding a column to the assignment table is additive under this document's own rule, the same classification 1.1.0 took for Code and Venue. --- VERSIONING.md | 2 +- sources/spec.md | 26 +++++++++++++++----------- 2 files changed, 16 insertions(+), 12 deletions(-) diff --git a/VERSIONING.md b/VERSIONING.md index 7d19211..b9fd3c6 100644 --- a/VERSIONING.md +++ b/VERSIONING.md @@ -39,7 +39,7 @@ The current state of every feed: | [Order-Intent](./order-intent/spec.md) | `0x494F` | `3` | 3.0.1 | | [Perp Stats](./perp-stats/spec.md) | `0x4450` | `3` | 3.0.1 | | [Reference Data Distribution](./reference-data/spec.md) | *(host feed's)* | *(host feed's)* | 1.0.2 | -| [Source ID Registry](./sources/spec.md) | *(none)* | *(none)* | 1.3.1 | +| [Source ID Registry](./sources/spec.md) | *(none)* | *(none)* | 1.4.0 | | [Glossary](./GLOSSARY.md) | *(none)* | *(none)* | 1.3.0 | Midpoint sits at `1` while its siblings are at `3` because it was deliberately left on its 64-byte `InstrumentDefinition` variant when the shared layout changed at both `2.0.0` and `3.0.0`. This is the scheme working as intended: the specs are siblings, not a single versioned family, and a decoder reads each feed's byte to know which layout it is holding. diff --git a/sources/spec.md b/sources/spec.md index 14ffa95..29ebfc6 100644 --- a/sources/spec.md +++ b/sources/spec.md @@ -6,7 +6,9 @@ A Source ID identifies the **matching engine** whose activity the message descri **A Source ID names a matching engine, not a venue.** One venue may run several matching engines and therefore hold several Source IDs. Two engines are distinct where their order-matching rules differ, and equally where they match independently over disjoint instrument sets under identical rules; a capacity shard the venue can rebalance is a channel rather than an engine. [GLOSSARY.md](../GLOSSARY.md) carries the full test and is the authority for it. A new engine at an already-registered venue is a new ID rather than a reuse of that venue's existing one. Because IDs are never renumbered, this only ever adds, and an ID already assigned keeps meaning whichever engine has been publishing under it. Venues split their own engines on their own schedule, so treat the set as open rather than assuming the current table is final. -This document specifies version **1.3.1**: the reserved ranges, the current assignment set, and the process for requesting a new ID. +**A distinct market identifier code is strong evidence of a distinct engine.** Where a regulated venue operates under several ISO 10383 MICs, each names a market with its own rulebook and its own matching, so the MIC settles the test above without further argument. The converse does not hold: one MIC routinely covers several engines, which is the ordinary case wherever a venue runs spot and derivatives under one code. Treat a distinct MIC as sufficient, never as necessary. + +This document specifies version **1.4.0**: the reserved ranges, the current assignment set, and the process for requesting a new ID. ## Reserved Ranges @@ -19,14 +21,14 @@ This document specifies version **1.3.1**: the reserved ranges, the current assi ## Assigned Source IDs -| ID | Name | Code | Venue | Kind | Notes | -|----|------|------|-------|------|-------| -| `1` | Hyperliquid | `HYPERLIQUID` | Hyperliquid | Perpetual DEX | | -| `2` | Phoenix | `PHOENIX` | Phoenix | Perpetual DEX | | -| `3` | Kalshi | `KALSHI` | Kalshi | Perpetual Futures, Prediction Market | Registered under the codename `Lashay` until the venue launched. Carries two matching engines and is due to split; see below. | -| `4` | Setai Financials | `SETAI` | Setai | Futures | Interface versioned separately from `5`. | -| `5` | Setai Commodities | `SETAI` | Setai | Futures, Options on Futures | Interface versioned separately from `4`. | -| `6` | Binance USD-Margined Futures | `BINANCE` | Binance | Perpetual Futures, Dated Futures | The venue's own `futuresType` for this engine is `U_MARGINED`. Spot, coin-margined futures and options are separate matching engines at this venue, unclaimed, and will share this `Code`. | +| ID | Name | Code | Venue | MIC | Kind | Notes | +|----|------|------|-------|-----|------|-------| +| `1` | Hyperliquid | `HYPERLIQUID` | Hyperliquid | — | Perpetual DEX | | +| `2` | Phoenix | `PHOENIX` | Phoenix | — | Perpetual DEX | | +| `3` | Kalshi | `KALSHI` | Kalshi | `KLSH` | Perpetual Futures, Prediction Market | Registered under the codename `Lashay` until the venue launched. Carries two matching engines and is due to split; see below. | +| `4` | Setai Financials | `SETAI` | Setai | *(withheld)* | Futures | Interface versioned separately from `5`. | +| `5` | Setai Commodities | `SETAI` | Setai | *(withheld)* | Futures, Options on Futures | Interface versioned separately from `4`. | +| `6` | Binance USD-Margined Futures | `BINANCE` | Binance | — | Perpetual Futures, Dated Futures | The venue's own `futuresType` for this engine is `U_MARGINED`. Spot, coin-margined futures and options are separate matching engines at this venue, unclaimed, and will share this `Code`. | `Code` is the machine-readable short name **for the venue**. It matches the `Venue` column and takes the same name TradingView uses. Uppercase, never an abbreviation, each space and hyphen a single underscore. @@ -34,6 +36,8 @@ This document specifies version **1.3.1**: the reserved ranges, the current assi Downstream systems already carry these values, so this column documents what exists rather than introducing anything new. This registry is the authority for it; any table of these values held elsewhere is a [registry mirror](../GLOSSARY.md) and is derived, never authoritative. +`MIC` is the engine's ISO 10383 market identifier code. An em dash means the venue has none, which is the normal case for a decentralised exchange and for any venue outside the standard's scope; *(withheld)* means one exists but naming it would identify a venue trading under a codename. Where two rows at one venue carry different MICs, that alone establishes them as distinct engines. + `Venue` is the external exchange or market operator running the engine, as [GLOSSARY.md](../GLOSSARY.md) defines it. It is recorded separately from `Name` so that several engines at one venue are legible as such, which is the case the `Name` column alone cannot show. Name the venue as TradingView does, where TradingView lists it. Its [data coverage list](https://www.tradingview.com/data-coverage/) is the reference. That is one fewer name for a subscriber to map. This governs `Venue` and `Code`, which carry the same name. TradingView has one name per venue and distinguishes products in the symbol, so it cannot name a matching engine, and neither column tries to: `Source ID` and `Name` do that. @@ -67,7 +71,7 @@ Recorded because it is the first assignment resting on the second half of the ru To request a new Source ID, open a pull request against this file that: 1. Adds a row to the **Assigned Source IDs** table with the next unused ID in the production range. -2. Names the matching engine in `Name`, gives its uppercase `Code`, names the exchange running it in `Venue`, and fills in `Kind` and (optionally) `Notes`. +2. Names the matching engine in `Name`, gives its uppercase `Code`, names the exchange running it in `Venue`, records the engine's `MIC` where it has one, and fills in `Kind` and (optionally) `Notes`. 3. States what makes the engine distinct from any already-registered engine at the same venue, where there is one. 4. Does not renumber, reorder, or remove existing rows. @@ -81,7 +85,7 @@ Because assigned IDs are stable and MUST NOT be renumbered, reordered, removed, ### Changes -**1.3.1** — editorial. Conformed `Code` on IDs `4` and `5` to the venue-level rule from `1.3.0`; both now read `SETAI`. No assignment changed and no ID was renumbered. +**1.4.0** — added the `MIC` column, recording each engine's ISO 10383 market identifier code, and stated that a distinct MIC is sufficient though not necessary to establish a distinct engine. Conformed `Code` on IDs `4` and `5` to the venue-level rule from `1.3.0`; both now read `SETAI`. No assignment changed and no ID was renumbered. **1.3.0** — assigned Source ID `6` to the USD-margined futures matching engine at Binance, and made `Code` name the venue rather than the matching engine. Several engines at one venue now share a `Code`, so `Code` alone no longer keys an engine and `Source ID` is stated as the engine key. This supersedes `1.2.1`'s statement that `Code` names the matching engine and stays unique. IDs `4` and `5` keep their engine-level Codes, because a `Code` already carried downstream cannot be changed without coordination.