Exchange: DYDX

[just-nilux]

Feature Request

Hello everyone, 2022 has proven that CEXs are not the way to go forward, For 2023 I predict to see a massive migration to decentralized exchanges. In the past the liquidity was always an issue, but this changed. After the FTX collapse we saw a massive influx of users to DYDX. They are now doing >1.5B in daily trading volume and growing exponentially

Requirements: Integrate the DYDX Library: https://github.com/dydxprotocol/dydx-v3-python Reference: API Exchange Examples: https://github.com/chiwalfrm/dydxexamples

Benefits:

• Your keys, your coins
• I see a lot of triangular arbitrage opportunities between Binance and DYDX.

I was building a lot on freqtrade before and have solid python, DYDX/Ethereum authentication experience and will contribute as much as possible to make it happen.

What you think?

[ccitzen]

I'd like to see this integration happen. However, I think for most potential users this is a smaller use-case than CEXs. For the sake of expanding usage of the library and the commercial success of the team (not me, but I think commercial success roughly correlates with better package for all of us), adding more CEXs is likely more beneficial in the immediate.

Would encourage the team to add OKX and Deribit, and then adding DYDX.

In terms of size, if you include derivatives OKX is 10-15x higher daily volume than DYDX. Optimizing here for just throughput is probably best imo

[cjdsellers]

We will definitely add an adapter for and support DYDX at some stage, probably as the first DEX integration. I think their API is quite good.

I tend to agree with @DownBadCapital that we need a couple more CEX's, and I'm not prepared to make any kind of philosophical decision against CEX's at this stage, for now in the short-medium term - they will continue to be a part of the crypto landscape.

This is starting to highlight for me the need to introduce a clearer process for deciding on which integrations to implement, potentially including some kind of voting process. I'll have a think about this and may run a poll in Discord to gather more information at the very least.

@nomad5am thanks for posting these resources, definitely something to leverage for the inner clients for the integration.

DYDX integration

How this is likely to play out, is we want to be working as efficiently as possible. So I need to have another look over the current client base classes and the adapters implementing them, extract some common patterns - and push that logic down to the base classes where/if possible. Then all future integrations can likely proceed at a faster pace, with less code to write and test.

From there I can probably write the core of the integration the fastest, and where the community can really come in and help is through testing and reporting bugs, and also making PRs for functionality beyond the basics I'm likely to start with.

Thoughts?

[ccitzen]

This seems like the right approach. Making new adapters as simple as possible to create for additional venues will help, but realistically people likely create only a few. Once they are up and running, usage should be extensive and bugs will likely be found quickly.

Pushing out new venues in a state where only Test APIs are used is another option. Might allow for lower "correctness" on the developers end when spinning up these new adapters, if they are only to be used for backtesting and test APIs. Then, adding in the live component once some bug testing has occurred.

[cjdsellers]

So there's been some progress, I've managed to consolidate the steam between sync and async method for connecting, disconnecting and the main execution methods. The idea here is that an adapter implementation just needs to implement some defined async def _* methods, which will be more obvious from the template adapter and docs.

Next step here is to do the same for all the data functions, and there's efforts to provide some standardized test classes also.

Similar to your suggestions, at some point in the next few weeks I could be willing to push out some scaffolding for Deribit and/or DYDX which would just need to then be 'filled in / implemented' and tested. Bandwidth dependent too though.

[cjdsellers]

Just squeezing out a small update for this.

• We continue to push down boilerplate into the client base classes, that's been progressing well
• We've also been making some good progress with setting up test harnesses for the clients

I'm thinking over the next couple of weeks we'll get to a point where it will be much more straight forward to develop integrations. In any case they still involve a large investment of time though...

[poshcoe]

I am also interested in a DYDX adapter for the above reasons. Also, it shouldn't be overlooked that DYDX in provides access to derivatives that are becoming increasingly difficult to access through CEXs in many jurisdictions (for retail investors/traders)