Add passive restriction support

[alnoki]

Motivations

In the interest of preserving parallelism, Econia does not publicly expose best bid/ask prices during runtime other than for mutation operations (e.g. taker or maker orders). This paradigm presents a challenge for makers who wish to place orders near the spread, or who wish to encroach on the spread so as to increase their price-time priority in a precise manner relative to best bid/ask. Hence the following additional restrictions are proposed as restriction arguments to market::place_limit_order():

• PASSIVE_JOIN: Return if order book empty on given side. Else overwrite passed price argument with AVL queue head price for given SIDE, e.g. place a maker order at the best possible price, but no more aggressive.
• PASSIVE_ENCROACH: Return if either side is empty. Else increment best price for a bid and decrement best price for an ask, encroaching on the spread. If new price crosses the spread completely, execute a passive join.
• PASSIVE_CROSS: Similar to PASSIVE_ENCROACH, but increment/decrement as much as possible toward the other side of the spread without crossing into fill territory.

Examples

Case 1

• Min ask price: 1300
• Max bid price: 1200

Restriction	Ask price	Bid price
PASSIVE_JOIN	1300	1200
PASSIVE_ENCROACH	1299	1201
PASSIVE_CROSS	1201	1299

Case 2

• Min ask price: 1300
• Max bid price: 1299

Restriction	Ask price	Bid price
PASSIVE_JOIN	1300	1299
PASSIVE_ENCROACH	1300	1299
PASSIVE_CROSS	1300	1299

Case 3

• Min ask price: 1300
• Max bid price: -

Restriction	Ask price	Bid price
PASSIVE_JOIN	1300	return
PASSIVE_ENCROACH	return	return
PASSIVE_CROSS	return	return

Case 4

• Min ask price: -
• Max bid price: 1200

Restriction	Ask price	Bid price
PASSIVE_JOIN	return	1200
PASSIVE_ENCROACH	return	return
PASSIVE_CROSS	return	return

@chen-robert @BriungRi

[alnoki]

Per discussion with @chen-robert, it may be appropriate to pass with PASSIVE_ENCROACH a parameter encroach_amount specifying how much to encroach, for example as a percent of the spread. Notably, all three functions are susceptible to front-running, with PASSIVE_JOIN constituting the most extreme case: here a maker is expecting to get a good price but gets MEV'd. With PASSIVE_CROSS, one at least accepts that they are basically crossing the spread anyways.

Hence in practice market makers may not use such functionality regularly, compared with retail traders, for instance, who simply wish to avoid taker fees by specifying PASSIVE_CROSS and assume that their order will be matched.

[BriungRi]

I think these are really good (and cool!) features for market makers.

A few thoughts

1. Restrictions is starting to do a lot of things. It might also be a good idea to refactor some of the restrictions that do weirder behavior such replacing price into their own function. E.g. place_limit_order_encroach
2. Agree that front-running can be a real issue with these price replacements. I think aforementioned point can be helpful as you could also provide some special parameters like ((min|max)_price_join)

[alnoki]

1. Restrictions is starting to do a lot of things. It might also be a good idea to refactor some of the restrictions that do weirder behavior such replacing price into their own function. E.g. place_limit_order_encroach

Given that the passive restriction behavior could potentially require a separate argument, here it might be useful to have a wrapper for a limit order with passivity, where users can specify the aforementioned parameters. Luckily all of the relevant price analysis appears to precede the other operations done in the place_limit_order() function, so it might be easy enough to just do a wrapper with a few price lookups before calling the place_limit_order() function.

2. Agree that front-running can be a real issue with these price replacements. I think aforementioned point can be helpful as you could also provide some special parameters like ((min|max)_price_join)

Yes, in the worst case they all reduce to PASSIVE_CROSS because MEV just entails placing a malicious passive cross, executing the legitimate passive order, then canceling the malicious passive cross. Still, though, passivity allows retail to avoid taker fees and indeed provide liquidity if only temporarily.