[Protocol3] operator influence on the choice of maker/taker orders

[p0n1]

The design doc writes about the choice of maker/taker orders as follows.

The operator chooses which order is the maker and which order is the taker. The first order in the ring is always the taker order, the second order is always the maker order. We always use the rate of the second order for the trade.

Is there any room for the operator to manipulate?

A ring matching example. Both two orders are buy orders. The buy order option is designed to help takers earn spreading.

Case 🅰️	Taker (A)	Maker (B)
tokenS	WETH	GTO
tokenB	GTO	WETH
amountS	101	200
amountB	100	200
isBuy	true	true
fill.S	101 -> 100 (spread = 1)	100
fill.B	100	100
target price (WETH/GTO)	1.01	1
settle price (WETH/GTO)	1	1
balance tokenS	1	100
balance tokenB	100	100

👆In this case, the operator settles the ring at the price 1 (WETH/GTO). The taker (A) got the spreading.

If the operator just switches the role of taker and maker.

Case 🅱️	Taker (B)	Maker (A)
tokenS	GTO	WETH
tokenB	WETH	GTO
amountS	200	101
amountB	200	100
isBuy	true	true
fill.S	101 -> 100 (spread = 1)	101
fill.B	101	100
target price (WETH/GTO)	1	1.01
settle price (WETH/GTO)	1.01	1.01
balance tokenS	100	0
balance tokenB	101	100

👆In this case, the operator settles the ring at the price 1.01 (WETH/GTO). The taker (B) got the spreading.

So, the operator could choose which user to get a better price.

Is it under consideration or just an exchange trading feature? Or maybe I just missed out something about order checking?

[Brechtpd]

You're absolutely correct, the operator has full control of which order is the taker or maker. This used to be something the ring-matcher decided, but we removed all ring-matcher specific functionality to reduce costs.

The idea is that for now the operator works closely together (or is the same entity, which would have meant ring-matcher == operator anyway which is what we're focusing on now for non-custodial exchanges) with the exchange that does the order matching. In this scenario the operator just matches orders exactly like the exchange wants. This can even work as expected in a fully decentralized setup where there's a single pool of orders (or even independent exchanges that don't share orders).

And because the price can never be worse than specified in the order it's more of an exchange feature and not something critical an operator can decide.

[dong77]

In other words, this order-matching part is 100% centralized. From this perspective, Loopring is not a really decentralized trading protocol, it's a non-custodial order-matching based trading protocol.

[Brechtpd]

We do support multiple operators for a single exchange with a custom Operator contract (using e.g. PoS). Anyone can become an operator, and all operators can independently decide which orders they want to match and include in a block, just like in any other decentralized blockchain where miners can pick which transactions they want to include in a block. Together with a mechanism to share orders off-chain between the different operators (like transactions are shared in other block chains), it is possible to use the protocol completely decentralized and build a true DEX.