Defining Pair Normalization

[bmoscon]

There are some discrepancies between exchanges and instrument types in terms of trading pairs. It would be best to define how all types should be normalized and then go from there to fix all the exchanges and ensure newly supported exchanges adhere to this standard (via a unit test). @olibre and @yohplala have shown some interest in this. Any others who are interested should feel free to chime in as well. My proposal:

Cryptocurrencies bought and sold in other currencies should be as follows:

BASE-QUOTE
Both BASE and QUOTE in the normalized format will be in uppercase. An example of this is BTC-USD. The Base currency is BTC and the quoted price will be USD denominated.

Futures Contracts

??? Looking for input here.

Other weird formats

Off the top of my head the only one I can think of is Bitfinex - it uses f in front of currencies for its Funding data. eg. fBTC

[yohplala]

@bmoscon
Yes regarding futures & perpetual, it would nice to agree something.
Some examples:

• for perpetual:
  - when margin is made in a stable coin (most of tyhe time USDT)
  - Binance: BTCUSDT
  - Bitmex: not available as far as I can see
  - Huobi: BTC-USDT
  - OKEx: BTC-USDT-SWAP
  - when margin is made in said coin, called 'inverse contract'
  - Binance: BTCUSD_PERP
  - Bitmex: XBTUSD, LINKUSDT
  - Huobi: BTC-USD
  - OKEx: BTC-USD-SWAP (I think it is an inverse contract - not so sure)
• for futures (with a fixed term contract)
  - Binance: BTCUSD_210326
  - Bitmex: [XBTZ20](https://www.bitmex.com/app/contract/XBTZ20)
  - Huobi: BTC_CQ
  - OKEx: BTC-USD-210326

Well, all this said, my proposal is not to go too deep in normalization for these, keeping normalization for spot when possible:
base-quote
And if any additional information / suffix, just adding it after _.

• For a fixed term contract on Bitmex or on Binance, this would give base-quote_contractEnd
• But for perpetual OKEx, this would also give BTC-USD_SWAP

This is a proposal: ?simple and convenient?

• splitting base/quote coin with -: yes
• keeping a single name for coin: yes
  • XBT (Bitmex, Kraken) -> BTC
  • UST (Bitfinex) -> USDT
  • BCHN (Bitfinex) -> BCH
  • MIOTA (Coingecko) -> IOTA
• (new) adding any further suffix information not being a base or quote coin after _

[olibre]

I agree with your ideas. Below some other ideas:

Ticker symbols (symbol codes)

1. Unify the symbol codes in order to identify the same instrument (spot, future, option…) independently of the market of origin.
2. Choose a short symbol code suitable for display and human understood (and filename/URL constraints).

symbol	Description
USDT	An asset (currency or token), here the Tether USD
BTC-USDT	A spot (pair of assets)
BTC-USDT.perp	Perpetual contract on a pair of assets
BTC-USDT.swap	Swap contract on a pair of assets
BTC-USDT.1Z	Future with expiry time coding (1Z = 2021-Dec)
BTC-USDT.1Z24	Future expiring another day than the third Friday
BTC-USDT.1Zc9000	Call option with expiry time and strike price
BTC-USDT.1Z2Z	Futures calendar spread (two expiry dates)
BTC-USDT.1Zp9000	Put option with expiry on Dec. 2021
BTC-USDT.1Z23wc9000	Weekly call option with expiry on 2021-12-23
BTC-USDT.w51c9000	Weekly call option with expiry on the 51th week (TODO remove?)
BTC-USDT.1Z23dp9000	Daily put option with expiry on 2021-12-23
BTC-USDT.d357p9000	Daily put option with expiry on the 357th day (TODO remove?)

Symbol details

The details of the symbol (instrument type, expiry...) are represented within the symbol code.
But Cryptofeed should also provide these details in another way to be more understood by both software and humans.
Other software should not need to extract the symbol details from the symbol code.

I do not know how Cryptofeed could provide these details, but I would suggest to reuse the FIX protocol tags. The symbol code corresponds to the FIX tag 55 Symbol. To go further, the symbol can also be used as the FIX tag 48 SecurityID when tag 22 SecurityIDSource set to "ExchangeSymbol".

Wording and abbreviation

As you can notice, to designate the pair I use here the FIX wording: symbol. I think Cryptofeed, should also conforms with the FIX Protocol wording and abbreviations. I would perform some mass renaming:

• price -> px
• amount -> qty
• ...

Asset naming (currencies)

I think Cryptofeed should conform to ISO 4217 when possible, except:

• Cryptofeed should use the asset naming the most understood y the community, even if the asset code uses four or more letters such as in DASH-USDT and as PITCH (Pitcheum is a digital currency token issued on Ethereum market).
• Bitcoin is represented by BTC instead of XBT (Bloomberg and Kraken use XBT).
• Bitcoin Cash is represented by BCH instead of XBC or BCHABC (Bitcoin ABC).
• The other Bitcoin Cash fork (Bitcoin SV) is represented by BSV.

I agree with @bmoscon: to represent a pair of assets, Cryptofeed should continue to use the format BBB-QQQ:

• BBB is the base currency (or transaction currency)
• QQQ is the quote currency (or counter currency)

The base currency (BBB) represents how much of the quote currency (QQQ) is needed to get one unit of the base currency.

Each currency, BBB or QQQ, is represented by two, three or more capital letters.

Character separators

Cryptofeed should use the following separators:

• "-" dash is the separator between assets as in "BTC-USD" for the following reasons:

  1. No separator at all saves some room but make harder the identification of the two assets, especially when some asset codes use more than three letters (DASH, PITCH).
  2. The slash "/" separator is more suitable for the display but cannot be used in URL, neither in filename.
  3. The dash "-" separator is already widely used in crypto-currencies pair names.

• "." dot is used for derivatives, between the underlying ticker symbol and the details of the option/future/perpetual/...

    BTC-USDT.1Zc9000
  

• "_" underscore is reserved to delimit the symbol, the market and other elements (used in filename). Thus the underscore is not used within the symbol code (if possible).

    future-file-produced-by-Cryptofeed_BTC-USD_HUOBI_trades.csv
  

Expiry coding

To represent the expiry, I propose Cryptofeed uses a time coding based on few characters such as 1Z and 1Z24:

• 1 = Digit representing the expiry year: 0 for 2020, 1 for 2021
• Z = Uppercase letter representing the month (see below list)
• 24 = Day of the month (optional, by default it's usually the third Friday of the month)

Cryptofeed should represent each month using the standardized uppercase letters:

F ⟶ January G ⟶ February H ⟶ March J ⟶ April K ⟶ May M ⟶ June

N ⟶ July Q ⟶ August U ⟶ September V ⟶ October X ⟶ November Z ⟶ December

[yohplala]

@olibre
A small comment regarding your sentence related to BCH:
Bitcoin Cash is represented by BCH instead of XBC or BCHABC (Bitcoin ABC).

The way it is phrased makes me feel you are not aware that BCH got a new fork approximately mid November 2020 (well after the BCH/BSV fork)
BCH becames on one hand Bitcoin Cash Node and on the other Bitcoin Cash ABC.
Bitcoin Cash Node is the group that refused a change
Bitcoin Cash ABC is the group that proposed a change.
Said change is taking part of the transaction fees to fund future developments of BCH blockchain.
(while the idea appears a good one, these funds are supposed to go nearly all into a single wallet which ownership is discutable...)

Well all of this to clarify why the trouble regarding BCHN / BCHABC recently with Bitfinex.
Most of the other exchanges made things simpler: they refused to support BCHABC and only kept BCHN, keeping then the legacy naming BCH.

[olibre]

Thank you very much @yohplala I was not aware about the fork last month (I have too much work to follow all these news).
I have just stroked the wrong information. 👍