Pure Market Making

Hi Team, I’m trying to understand the pure market making, and i want to write pseudo code (and to develop it in python) for this strategy for some research , can some one help me with some questions !

Have you looked at the documentation for it yet?
https://docs.hummingbot.io/strategies/pure-market-making/
https://docs.hummingbot.io/developers/strategies/pure-market-making/

If so, list your questions and we’ll answer them!

Yes, thanks for your response, So I’m trying to implement the pure market making strategy using ccxt, so i have an exchange and some inventory (example : 1 BTC / 10 ETH ) , and i will try to create some limit orders ( in buy and sell sides), so to start i will start by creating 2 orders in both sides ( price : top of orderbook) and the amount (using ration in the algo and bid or ask order amount), but next i can’t see what exactly my algo must do !!!

I’m sorry but this is a forum for Hummingbot. If you’re building on ccxt, go ask them how to do it!

ah I see but my questions are just about the pure market making, your strategy

I actually was wondering about something similar a few weeks ago. Hummingbot is specialized in running a set of market maker like or custom strategies, ccxt on the other hand is specialized in connecting to exchanges programmatically.

From a architectural point of view you could look to see if it’s possible to build a hummingbot exchange connector that internally uses ccxt to connect to an exchange. That way the design of both projects are respected while you could run strategies inside hummingbot while hooking it up to probably most of the exchanges to which offers integration. If it’s possible to do that, that would generate an huge expansion of possibilities of hummingbot.

1 Like

We’ve been asked whether Hummingbot can leverage ccxt a number of times, so I’m happy to provide a more detailed answer here in the forum…

Intregating with ccxt was something that we evaluated a ton before building Hummingbot. We really wanted to use them, because if we didn’t have to build new connectors for each exchange, it would save everyone a lot of time and hassle. However after evaluation, we believed that building an independent codebase was necessary for two reasons:

Exchange abstraction

One of the primary design goals for Hummingbot is to abstract connectors from strategies, so that any strategy can run on any exchange, no matter what kind of exchange it is. This entails taking into account all exchange-specific idiosyncrasies that might cause a strategy to act differently.

For example, look at the difference btween our Binance connector and the ccxt Binance Python module. Among the many differences, the Hummingbot connector contains a module that synchronizes clock times because the Binance API locks out users if clock times differ.

These exchange-specific differences are even larger for decentralized exchanges, which ccxt currently doesn’t support.

Order management

Market making is hard because you’re placing and cancelling orders rapidly as the order book is also changing rapidly. Accounting for race conditions, network errors, how different exchanges respond to order fills, cancels, partial fills, and how decentralized vs centralized exchanges differ is a highly complex problem.

To manage this complexity, we implemented a logical structure for how orders are managed through this lifecycle (described in the Order Lifecycle in the documentation) and expect all exchange connectors to adhere to this logic. From speaking to hedge funds who have built their stack on top of ccxt, it appears that they wrote the order management logic after integrating with ccxt. However, since we want Hummingbot to be usable even by non-developers, our connectors need to take that into account.

To summarize, we’re huge fans of ccxt and know both professional and individual bot developers who have successfully build their bots on top of ccxt. However, building Hummingbot on top of ccxt doesn’t make sense from an architectural standpoint given that we’re focused on market making bots, which is more complex than taker bots, and that our goal is to abstract connectors entirely for non-developer users.

1 Like

That makes total sense, thank you for taking the time to share your insights, choices and elaborating on the matter!:smiley: