This should be the start of a discussion on how to combine market makers with an order book. The most simple solution would be to just have them completely separated.
On chain market maker calculations that includes an order book are most likely infeasible. However - maybe a “valid state” can be defined and checked easily.
(something like: the no current market maker price is allowed to be higher than the highes matching open order) It than would be necessary for the user to full fill an order AND trade with the market maker to result in a valid state (can be done atomic with a transactions that full fills a list of trades). The calculations required can be done off chain.
However - for this validity check a sorted list of the orderbook would be necessary. Even this would stop trades having a fixed gas prices. So very busy markets would become more expensive and could even run out of the block gas limit and therefore create a dead lock.
One workaround I’ve heard for this sort of problem is to offer bounties for presenting the invalid state. Maintaining a sorted orderbook is hard, but checking a given order against the market maker’s price is easy, so if anyone submits an invalid pair to the contract, it can take the appropriate action.
right - the downside of it is that you would have to leave a security deposit with your trade. However - still definitely a solution worth thinking about.
Maybe the trade can be done by a third party that would provide the deposit.
For me everyone placing orders in an order book is kind of a market maker. Since odds can change quickly, the order book should be completely seperated from the automated market maker and be off chain! I propose to allow the user to use different order book brokers to be used in the dApp. Users who want to place an order have to make a deposit to our order book contract. They can place an order by sending a signed message to the order book broker (a website etc.) which includes the details like market, price and also a validity date in form of a block number. Users who take the order send this signed message togehter with their money to the order book contract to buy the shares. The order book contract can use the send shares function provided by our markets contract to implement this functionailiy. The dApp will ask the order book broker first for possible offers. If there is none, if falls back to the automated market maker. The great thing is, that this way super flexible non automated market makers can be implemented, which we will need for sport bets anyways!
For makets with very little volume and a few participants market makers are a great tool for getting a forecast/price discovery anyway. However - lets think of a big sport market. Lets say the odds are 50/50 and there is a user A who is willing to bet $1,000,000 on the one side and a user B who is willing to bet $1,000,000 on the other side.
With a market maker only approach they simply can not do it. The only way would be - player a places $1000 on the one side (and moves the price slightly to lets say 48), now player B would need to bet $1000 on the other side to move the price back to 50. Now they can do it 1000 times. With an orderbook they can just directly settle the bet.
Move the market maker/order book off-chain.
Payment hubs that process channel transactions can run market makers or order books or poker games or whatever they want.