> As far as I know there isn't anything out there like this, in any market (not just cryptocurrencies).

How does Gryphon compare to Catalyst (Zipline)? https://github.com/enigmampc/catalyst

They list a few example algorithms: https://enigma.co/catalyst/example-algos.html

"Ask HN: Why would anyone share trading algorithms and compare by performance?" https://news.ycombinator.com/item?id=15802834 (pyfolio, popular [Zipline] algos shared through Quantopian)

"Superalgos and the Trading Singularity" https://news.ycombinator.com/item?id=19109333 (awesome-quant,)

Well documented. Looks like a nice way to learn about market making in a real life situations with small fractions of bitcoin. Curious to know if someone takes it for a real drive in a production environment.

Thanks! I hope they do.

I had considered adding a 'reading list' to the docs for people who are new to trading, so this could be used as a teaching tool (or just to make using it easier). I'll bump that up the priority list.

I would love that, too.

Would love that. Please and thank you.

Ditto. Heck you could combine all of it and make a nice udemy course for some extra $ if you wanted to.

Looks great!

Though looking at the code -> https://github.com/garethdmm/gryphon/tree/master/gryphon/lib...

Seems quite hard to extend it with new exchanges.

This is partially documented here, I'll add more soon: https://gryphon.readthedocs.io/en/latest/exchange_integratio...

Shouldn't be, you just need to write a wrapper for the exchange API with the interface defined in 'gryphon.lib.exchange.exchange_api_wrapper'. I'll add an article to the docs with more about that soon.

Would CCXT be useful here? https://github.com/ccxt/ccxt

> The ccxt library currently supports the following 135 cryptocurrency exchange markets and trading APIs:

It's possible CCXT could be used to easily wrap other exchanges into gryphon. I'm not familiar with the library so hard to guess if it would be a net win or not.

Thanks!

Which exchange is a good example?

I find the directory structure just a confusing, why does each exchange-market get it's own file, wouldn't it be better for the exchange just to define some markets as hashes?

Gemini is probably the best one, code-quality wise.

Agreed, the way the trading-pair-to-exchange relationship works right now is imperfect. It's ripe for a good refactor.

Thanks for taking the time to open source this.

So is its use case limited to arb? Or are other HFT strategies supported?

It's perfectly general: arb, market making, signal trading, ml, etc. Whatever strategy class you're thinking of, you can probably implement it on Gryphon.

Can you please explain to me how a tool written in python can be used for HFT or market making?

I’m asking because we generally used ASICS and c++ in the past, or more recently rust. Even GPUs are often difficult because they introduce milliseconds of latency.

If you want to restrict the definition of HFT to only sub-millisecond strategies you're correct. But then, all HFT is impossible in crypto, since with web request latency and rate limits, it would be very difficult to get tick speeds even in the 10s of milliseconds. It's fine if you want to call this "algo trading" instead of HFT, but I think a common understanding of the term would include Gryphon's capabilities.

In any case Gryphon uses Cython to compile itself down to C, which isn't quite as good as writing in native C but is a good chunk of the way there.

> In any case Gryphon uses Cython to compile itself down to C, which isn't quite as good as writing in native C but is a good chunk of the way there.

Would there be any advantage to asyncio with uvloop (also written in Cython (on libuv like Node) like Pandas)? https://github.com/MagicStack/uvloop

IDK how many e.g. signals routines benefit from asyncio yet.

I don't believe true crypto HFT strategies exist (i.e. sub-millisecond tick to trade). It's just not possible with websockets and http requests being the standard for data feeds and order placement on crypto exchanges.