[Feedback & Discussion] Off-chain market making for Gnosis Protocol & Mesa

TL;DR
Gnosis Protocol is a fully decentralized trading protocol currently challenged with attracting liquidity. Takers only see a sparsely populated orderbook and makers are effectively prohibited from taking part due to the costly nature of constant on-chain order submissions. We propose a solution that would implement a service on top which requires makers only to submit an order on-chain when there is likely a trade happening, whilst the taker is able to see that quote already beforehand and include it in a decision for their limit order. This will not influence GP’s decentralized nature in any way.

Background
Any two sided market platform - such as GP, where buyers and sellers are matched - must overcome the initial liquidity problem for relevant network effects to take off and the platform to be a success. In short: liquidity attracts more liquidity.

After talking with several market makers about the inactivity on GP since its launch mid-April, the response was quite clear: market making on the entirely on-chain protocol is extremely expensive due to re-adjusting orders every batch with an unclear success rate whether orders are matched, which is mainly due to the absence of takers coupled with the high and rising gas prices.

One of the core challenges of GP is to bring maker and taker together at the same time/ the same batches. The suggestion by Protofire discussed here for a simple swap interface addresses the critical user experience for a taker (which are needed for makers). However, another service would additionally be required, namely a way to show these swap-traders available market makers’ offers without the cost and inefficiency of doing it all on-chain. Both proposals would complement each other to solve this “chicken-and-egg” problem.

Proposal
We suggest integrating an off-chain orderbook (or “virtual” orderbook) into Mesa’s on-chain orderbook and the price estimation service. Important to note is that this will not influence the decentralized nature of Gnosis Protocol, which is one of its core features: order submission, matching, settlement etc. will all remain on-chain. The core difference is that a user will see more orders in the orderbook (those on and off-chain) and can make an informed decision on placing a limit order. Once the user has submitted their order, the market maker will be informed and in turn place their order on-chain if the user’s decision was made based on an off-chain quote.

Worst case scenario for the user is that their order is not filled. Best case scenario is that many more offers are available and the traders find a match (at a better price). They might still be matched against better offers in the same batch: single price clearing and optimizing for traders’ welfare is still intact.

Call for action: Discussion
As the dxDAO hosts Mesa and adds significantly to the decentralization of Gnosis Protocol, we would love to hear thoughts and discussions around the addition of an off-chain orderbook service.

(1) Would you be interested in including this on Mesa (and possibly on the simple swap interface if that goes forward)?
The implementation of the service on Mesa could take many ways: A user could switch the service on and off or be exposed to it without explicit consent (but noting the existence).

(2) Would you be able to either build the adaptation to Mesa yourselves or would be keen to fund it? We (=Gnosis Ltd.) would dedicate our development resources in building this backend service if it sparks members’ enthusiasm and likewise commitment.

(3) For more detailed documentation and the technical implementation details, please see this document. We are also interested to hear thoughts and feedback on this proposed technical back-end implementation (you can also comment into that document directly).

7 Likes

Initial thoughts are that Mesa has strengths and weaknesses. IMO the strengths lie in trading stablecoins and its potential for having fair dex offerings. It’s already not the easiest for me to read the onchain order book. Adding another one probably won’t make things any easier.

Where would this off chain order book be stored? How does the DXdao benefit?

1 Like

All really good questions.
So first and foremost the benefit should go to the users of Mesa (and other interfaces maybe such as dxSwap). Hence, the dxDAO would “indirectly” benefit from having more (happy) users.
It is an idea to fix the chicken and egg problem for making integration easier (=less costly) for market makers. The off-chain orderbook would be (initially) a centralized service hosted by Gnosis Ltd and could be integrated into the already existing on-chain orderbook for users to see both in one combined orderbook (one implementation option would be for the user to select which ones to include).
I agree that reading the orderbook is somewhat difficult, so it’s important to note that these quotes would also be include in the price estimate when a user types in how much they’d like to sell, they could see better prices when we include the off-chain quotes also.

I would like to see this feature implemented as it provides better prices for the user (and even best market prices) which increase the user experience of Mesa and increase the total volume of Gnosis Protocol.

(2) Would you be able to either build the adaptation to Mesa yourselves or would be keen to fund it? We (=Gnosis Ltd.) would dedicate our development resources in building this backend service if it sparks members’ enthusiasm and likewise commitment.

The current developers working for the DXdao are fairly busy with DXswap and Omen. I am not sure that the DXdao would accept funding the development as it has no real clear financial benefit.

Do you expect that the virtual off-chain orderbook is just an intermediate solution to bootstrap the liquidity on Mesa or will it always be “useful” and stick around forever?

I would expect that the virtual orderbook is something that sticks around - if there is going to be an improved, scalable GP-V2 in the future, I think a gas-efficient solution for marketmakers (maybe side-chain?) will still be needed, however, implementation has not yet been discussed and could take different forms. This service is, in my opinion, needed to validate V1 first.

I definitely agree that there is no immediate monetary effect for the dxDAO that would capture the improvement. In theory, no Mesa related change would actually be required but I think it’s valuable to signal the use of both orderbooks to the users especially as Mesa is a decentralized dapp. Benefits for the dxDAO would be through better prices for users on Mesa and through integration on other dxDAO-funded(?) interfaces (of course also open).

@ingalandia: How does the DXdao benefit?

Market Makers and users are willing to use the platform if they get a better price, but if the order that has an appealing price is never posted, because users need to pay gas in order to reveal their willingness to match at that price, then neither the party or the counterparty will take the initiative to send the order onchain.
I believe that allowing any party to reveal it’s price without any cost it’s a great feature to have in Mesa, and combined with the power of the protocol to liquidate big orders with a small slippage, I think can bring attention to dxDAO.

@ingalandia: Adding another one probably won’t make things any easier.

The way Mesa displays the order book and price is improvable, there’s ideas to improve those two that are orthogonal to the topic here discussed.
I would view this service useful for both, Mesa and dxSwap. Even it could make sense for dxDAO to market make DXD.

One proposal for showing this price, that should come together with other UI changes (that would probably need another forum post) could be:

Imagine we never fill the price input for the user. Instead, the user get a list of price estimates for his selling amount, that act just as references, and then he clicks on one of them to fill the input. He could of course modify the price and make adjustments.

If Mesa/dxSwap takes the approach above, it would be easy to suggest, as 2 different price references, the onchain price, or the off chain price. These could be branded us nicely, I can only come up right now with “Onchain: Likely Matched in next batch”, “Off Chain: Advertised price for private Market Makers”

I can see how these list of “references” could grow for different other decentralized/centralized exchanges (dex.ag, uniswap, coinbase, …)
The same I said for the price could apply for the order book. Each price can have an associated order book.

1 Like

I would expect it to be forever. Of course the technology could evolve, and use a side chain for example to do this, but the workflow would be the same.

Think about for example if you want to Market Make DXD, would you be posting orders and doing the deposit in case someone would show up?. Or if the price is very volatile, would you be updating the orders to reveal your new price, and paying gas for that?
Instead, you could have a market making bot, revealing the price to this service, and posting the order only when a counterparty send his.

1 Like

Thanks, Chris for this brave idea - off chain MM for GP and Mesa! I see a lot crypto liquidity beyond CEXes and DEXes. For example this aggregator connect hundreds of local crypto MM and sometimes rates are better compare with CEXes and DEXes https://www.bestchange.com/
I am not dev and I cant offer any skills to create off chain MM software or UI GP tool but as potential MM between bestchange and GP and also dxDAO member I am ready to vote for developing and funding this. I think dxDAO it is not just For direct profit organization - dxDAO it is for creating social (public) goods. DeFi and fair trading are social (public) goods!

1 Like

Hi @ykplayer8 - thanks for your nice response and commenting that the “dxDAO it is for creating social (public) goods. DeFi and fair trading are social (public) goods!” - I think this is super valuable information.

–> Does that mean that you are marketmaking between those two and if so, are there any additional integration pieces we need to consider when building the off-chain orderbook that will help you with this?

How off-chain MM might be from my view

  1. Lets say I am find good deal for WETH-USDC on my local market. Current Uniswap price is 2300 for selling 10 WETH to USDC, current GP price estimation 2280. I am creating GP off chain order for selling 10 WETH for 2320 USDC.
  2. Taker accepting my offer.
  3. I receiving telegram message and press confirm button on off-chain UI (my time deadline 10 min for pressing confirm button). Then I have 20 min to deposit funds and create on chain order on GP for 10 WETH for 2320.
    Is it correct and realistic?

One more

Lets say Gnosis safe multisig GP MM app created

  1. MM funded GS multisig. 10 WETH
  2. Set up and create selling order without funding GP account.
  3. When taker accepting order with MM selling parameters and limits auto execution script starting. Fund GP account, create order, request withdraw, claim funds.

Maybe this scenario is also Gelato style

Hey @ykplayer8 so the initial proposal is more inline with your second scenario. How we initially envisioned MM with the off-chain orderbook is:

  1. MM continuously updates its price preference by placing non-binding (and more importantly, without gas costs) virtual orders to the off-chain orderbook for selling 10 WETH for 2320 USDC; you can kind of think of this as a price feed or ticker from MM to users
  2. User sees virtual order (with the help of the price estimation widget and/or bid/ask spread page) and places an on-chain order with a limit price that overlaps with the MM counter order buying 10 WETH for 2325 USDC (plus fees).
  3. MM bot wakes up near end of batch and uses the price estimator API to determine that there is a high chance that placing an order at virtual order price is likely to trade 10 WETH, so MM places the order selling 10 WETH for 2320 USDC valid for the next batch, deposits 10 WETH.
  4. Trades get matched :tada: :money_mouth_face:

This way, if no users place any overlapping orders to the advertised price (in other words step 2 doesn’t happen), then the gas costs for step 3 don’t have to be paid. We already do something similar for our SNX trading bot linked in the requirements document (with the notable exception that it cannot advertise the price it is willing to pay because there is no virtual orderbook). Essentially, the bot wakes up at the end of the batch and checks to see if there are on-chain orders placed that would trade at its desired price and only place an on-chain order if it is likely to be matched. The original implementation was placing orders continuously every batch which burned A LOT of ETH for gas.

The only downside I see to your first scenario is that a user would have to wait for 4 batches for that to be matched. Note, however, that this is just how we initially envisioned it and all still up for discussion! It will really depend on how MMs want to integrate.

Interesting. In this case MM already deposited funds to GP but not burn gas every time when MM need change his offers. It sounds acceptable. This type of MM work style is interesting to me and I am with greate pleasure will take part on this. Brackets + off chain MM together are powerful MM tools.

1 Like

I believe it would also be possible for the MM to also deposit the funds when placing the order at the end of the batch, as deposits mature in the following batch.

The current developers working for the DXdao are fairly busy with DXswap and Omen. I am not sure that the DXdao would accept funding the development as it has no real clear financial benefit.

To be clear, we (Gnosis) would be providing the backend infrastructure and integrate the virtual orders into our current price estimation service. All we would ask the dxDAO to do is change the frontend to “enable” the virtual order based price estimation (e.g. by passing something like includeOffchainOrders=true flag to the price estimation URL and optionally display a button to opt-in/opt-out).
If enabled the “estimated price” would be based not just on the orders that are already on-chain but also include the ones that MM have quoted (assuming they will commit to them on-chain if taker moves first).

1 Like

Only addition to that, Is that this if dxDAO directly, or one client, market maker, or stake holder of his is interested in market making a token pair in Gnosis Protocol / Mesa using the Offchain Order Book service, they would be able to do so if they integrate with it. Right?

1 Like

[…] they would be able to do so if they integrate with it. Right?

Absolutely