Cryptocurrencies

[EricForgy]

Let's use this issue to discuss how to incorporate cryptocurrencies into the framework we've been outlining here.

@roshii

JuliaFinance/Currencies.jl#101

https://discourse.julialang.org/t/intro-juliafinance/20571/17

[roshii]

Thanks @EricForgy

First and foremost, I indeed want to make my project of crypto fund manager compatible with JuliaFinance. This will clearly allow me to focus on developing missing piece of code and accelerate project development by using ready made package, not to forget learning from others :)

Speaking of which, when I look at FinancialInstruments, it reminds me, we may want some special treatment for cryptocurrencies compared to traditional currencies issued by a central bank after all because the name I gave for currency as a financial instrument was “Cash”. I’m not sure that would be appropriate for a cryptocurrency though. What would you call a position in cryptocurrency? “Cash”? “Crypto”? Something else?

That is a much broader question than it seems at first!
First of all, lets clarify what we are meaning with Currencies.

Money in any form when in actual use as a medium of exchange

That is basically any asset, that two entities are willing to trade. And those assets can either be tangible (e.g. gold coin, real estate, raw iron, euro coin, etc) or intangible (e.g. dollars on a bank account, bitcoin, World of Warcraft items, etc...)

At this point already, we can argue, if tangible assets should be handle by Currencies and IMHO I don't think so, they deserve there own Commodities package.

So, we would be left with intangible assets, left to classify within Currencies and for which I'd propose to use Dr. Pavel Kravchenko framework whom defines five processes in a digital accounting system, which may have at least three states (centralized, decentralized, not possible):

• Governance
• Custody
• Issuance and distribution
• Transaction processing
• Audit

This leads to many possible combinations with central bank currency (Fiat ?) at one extreme with all processes centralized and bitcoin (Crypto ?) at the other extreme (all processes decentralized) with digital currency, commodity-backed tokens, equity tokens, accounting tokens, digital collectibles and utility tokens along the currency spectrum.
To make it short, I think each deserves its own Type since each has its very own specifics, e.g interest rate for Fiat, max supply for Bitcoin, etc.

This is just my opinion and I have not thought of the coding implication of such categorization yet, so more than open for discussion!
As far as I am concerned I do plan at using/implementing cryptocurrencies, digital currencies and commodity-backed tokens, with digital currency being only slightly different to crypto and commodity-backed tokens being only slightly different to fiat.

Once we settle how to properly deal with cryptocurrency as a financial instrument, the next thing to do would be to construct a market for cryptocurrencies. For that, off the top of my head, I imagine a Market called “Crypto”. Within that Market, you will have multiple Exchanges and each Exchange will provide buy/sell quotes for the cryptocurrencies listed on that Exchange. We could make some friendly defaults, e.g. a default market with a default exchange.

It is the Exchange that would connect to the actual exchange to provide market quotes.

I guess Ticker, Orderbook, Trades would sit within MarketData, which would sits itself within Market, right?
Within Exchange you'd read entity specific data and within Market, some sort of user created index using a mix of different Exchange, right?
In such case, it would make sense that Market (or maybe MarkeInterface) provides the methods (using HTTP, Websocket or FIX) for retrieving data from Exchange which would only have some specifics. In other word a common language for accessing all Exchanges within that Market and standardizing all answer.

FYI, I am now trying to define some standards types for Ticker, Orderbook and Trades answers I do receive from exchanges.

[EricForgy]

Hi @roshii

At this point already, we can argue, if tangible assets should be handle by Currencies and IMHO I don't think so, they deserve there own Commodities package.

I don't think you'll get any arguments from me. Currencies should be minimal and maybe SHOULD just keep it as labels for ISO currencies.

FinancialInstruments is supposed to accomodate anything handled by a contract, including currencies, cryptocurrencies and any other financial instrument.

To make it short, I think each deserves its own Type since each has its very own specifics, e.g interest rate for Fiat, max supply for Bitcoin, etc.

Yes, but all of these should fall under the FinancialInstrument umbrella. That is what I am trying to achieve 😊

As far as I am concerned I do plan at using/implementing cryptocurrencies, digital currencies and commodity-backed tokens, with digital currency being only slightly different to crypto and commodity-backed tokens being only slightly different to fiat.

This sounds great. I hope I can help you 😊

At the end of the day, all this needs to go into an accounting system somehow so my initial effort was around general ledgers (and a distributed ledger falls in this category) so my vision is to have all the crypto assets, traditional assets and alternative assets work together seamlessly 😊

I guess Ticker, Orderbook, Trades would sit within MarketData, which would sits itself within Market, right?

This is yet to be worked out and I'm happy to get input from you. In some of our earlier discussions we were suggesting MarketData should be Observables, i.e. https://github.com/JuliaGizmos/Observables.jl so we might call it MarketObservables ort something, but nothing is set in stone yet so I'm glad you're here to help think about all this stuff.

Within Exchange you'd read entity specific data and within Market, some sort of user created index using a mix of different Exchange, right?

Something like that. Yeah 👍

In such case, it would make sense that Market (or maybe MarkeInterface) provides the methods (using HTTP, Websocket or FIX) for retrieving data from Exchange which would only have some specifics. In other word a common language for accessing all Exchanges within that Market and standardizing all answer.

Agree. That would be awesome.

FYI, I am now trying to define some standards types for Ticker, Orderbook and Trades answers I do receive from exchanges.

Sounds good. Hope I can help 🙏

Keep up the good work @roshii 👍💪

[femtotrader]

I have some (quite old) Julia code with functions to get from (limit) order book

• highest bid
• lowest ask
• bid for a given volume (because cryptocurrencies can be a quite thin market where volume can impact price)
• ask (for a given volume)
• spread (for a given volume)

This code is composed of FiniteDepthOrderBook and InfiniteDepthOrderBook (inheriting from AbstractOrderBook)

InfiniteDepthOrderBook can be exposed to a backtest engine when you don't have real orderbook but only tick data and you don't want to consider market impact)

On the other side, Kyle's lambda could probably be implemented for FiniteDepthOrderBook (but I think it's an interesting metric... especially for this kind of market)

I also have some unit tests.

Maybe you can create a https://github.com/JuliaFinance/OrderBook.jl repository (with a default settings with Travis enabled) and give me some grants.

I'm currently quite pressed but could simply copy/paste code using Github web interface as a beginning.

This is only a work in progress which should be improved to manage orderbook events such as a new limit buy order is add at a given level price for a given volume, a limit sell order of a given volume is removed at a given level price...)

[roshii]

Yes, but all of these should fall under the FinancialInstrument umbrella.

That make sense yes. So we maybe could agree to a structure as follows:

FinancialInstrument
|_ Currencies (ISO 4217)  
     |_ Crypto
          |_  Cryptocurrencies
          |_  Digital currencies
          |_  Asset-backed tokens
|_ Commodities  
|_ Unique and non-fungible assets
     |_ Digital collectibles
     |_ Real Estate
|_ Stocks/Shares  
     |_ Equity tokens
|_ etc...

I do not think the different Crypto need a type of their own, a field might just be sufficient to differentiate.

At the end of the day, all this needs to go into an accounting system somehow so my initial effort was around general ledgers (and a distributed ledger falls in this category) so my vision is to have all the crypto assets, traditional assets and alternative assets work together seamlessly

I can only agree to this and since I am no accountant, I'd love to use functions that issue standard financial report whatever the assets are.

This is yet to be worked out and I'm happy to get input from you. In some of our earlier discussions we were suggesting MarketData should be Observables, i.e. https://github.com/JuliaGizmos/Observables.jl so we might call it MarketObservables ort something, but nothing is set in stone yet so I'm glad you're here to help think about all this stuff.

That make sense too, I'll take it from there and will try to fit Exchanges answers into a MarketObservables

[roshii]

I have some (quite old) Julia code with functions to get from (limit) order book

That's a good news :) We have something to start with !

Maybe you can create a https://github.com/JuliaFinance/OrderBook.jl repository (with a default settings with Travis enabled) and give me some grants.

I think we should en-globe all possible answers into a wider MarketObservables package in which OrderBook would be defined. As a matter of fact, if you connect to an Exchange, it will also provide Ticker and Trades on top of OrderBook and so I do not think those type should be delivered in a separate package.

InfiniteDepthOrderBook can be exposed to a backtest engine when you don't have real orderbook but only tick data and you don't want to consider market impact)

That's a nice one, I never thought of market impact but that is something that should be considered indeed.

This is only a work in progress which should be improved to manage order-book events such as a new limit buy order is add at a given level price for a given volume, a limit sell order of a given volume is removed at a given level price...)

OrderBook should indeed be singleton for each Exchange and should IMHO by limited to two Ask and Bid arrays, with only 3 field per item, i.e. Amount, Price and Count.
All other data (e.g. spread, highest bid, etc...) can be derived/calculated from the OrderBook when needed

[roshii]

I just created https://github.com/roshii/MarketObservables.jl to start with.
Do we want to move this to JuliaFinance? Or do you prefer me to give you write access while it's a work in progress?

[EricForgy]

I just created https://github.com/roshii/MarketObservables.jl to start with.
Do we want to move this to JuliaFinance? Or do you prefer me to give you write access while it's a work in progress?

Hi @roshii ,

I just sent you an invitation to become a member of JuliaFinance. If you want, feel free to add / transfer your repo to JuliaFinance. I think that would be awesome 😊

(Sorry I've been distracted lately and not helping as much as I wanted 🙏)

[roshii]

I just sent you an invitation to become a member of JuliaFinance

Thanks, much appreciated :) I'll transfer the repo today ;)

(Sorry I've been distracted lately and not helping as much as I wanted pray)

No bother, I have been distracted as well :D

[EricForgy]

I have some (quite old) Julia code with functions to get from (limit) order book

• highest bid
• lowest ask
• bid for a given volume (because cryptocurrencies can be a quite thin market where volume can impact price)
• ask (for a given volume)
• spread (for a given volume)

This code is composed of FiniteDepthOrderBook and InfiniteDepthOrderBook (inheriting from AbstractOrderBook)

InfiniteDepthOrderBook can be exposed to a backtest engine when you don't have real orderbook but only tick data and you don't want to consider market impact)

On the other side, Kyle's lambda could probably be implemented for FiniteDepthOrderBook (but I think it's an interesting metric... especially for this kind of market)

I also have some unit tests.

Maybe you can create a https://github.com/JuliaFinance/OrderBook.jl repository (with a default settings with Travis enabled) and give me some grants.

I'm currently quite pressed but could simply copy/paste code using Github web interface as a beginning.

This is only a work in progress which should be improved to manage orderbook events such as a new limit buy order is add at a given level price for a given volume, a limit sell order of a given volume is removed at a given level price...)

Sorry @femtotrader 🙏

I missed your comment. Been distracted. I sent you an invite to become a member of JuliaFinance as well. That should hopefully grant enough access that you guys can create repos 👍 (let me know if there is some problem)

[femtotrader]

Thanks @EricForgy for this invite as a member of JuliaFinance, I accepted it. I'm a owner of JuliaQuant

I will put my code in https://github.com/JuliaFinance/MarketObservables.jl when it will be transferred and CI with Travis set up.

I won't be available from Thursday to Monday. So I can help today and tomorrow and will have some free time next week.

[roshii]

MarketObervables.jl now belongs to JuliaFinance ;)
I also create a crypto team which would focus on enabling cryptocurrency trading in Julia and fitting in the broader JuliaFinance ecosystem.