Making the DLOB more intuitive

[crispheaney]

Drift v2's design has some quirks that can confuse people coming from a cex. It has multiple liquidity sources (vamm and active mm's) and it doesn't enforce strict price-time priority. While some deviation from the traditional conceptual model is inevitable when moving onchain, it's still good to keep things similar where you can.

Here are some sources of confusion for users new to drift:

1. A limit order without post-only can take from a post-only limit order, even when the former was placed first (breaks expectations around price-time priority)
2. Post-only limit orders receive a different maker rebate based on whether they fill against another user or the vamm. In the latter case, they do not receive a maker rebate
3. A limit order without post-only can end up being a maker for a newer market order, or it can be a taker against the vamm or another post-only limit order

To reduce confusion and make drift v2 more intuitive, the following changes can be made:

1. Limit orders can only take during their auction, after which they're considered "resting" and can only be a maker
2. If a limit order is "resting" and filled by the vamm, the limit order gets the full maker rebate

1 conceptually unifies market orders and limit orders. While they both take during the auction, the market order expires at the end whereas the limit order becomes a maker at its limit price.

1 also makes it easier for drift to replicate price-time priority. While it doesn't enforce it strictly, it does aim to approximate it via keeper incentivizes. By removing the ability for a resting limit order to take, it removes the situation where a limit order takes from another order that was placed after it.

2 makes the fee schedule more predictable and makes the vamm function more similar to other market participants, reducing the cognitive overhead for users new to drift.

This outlines some of the tentative changes coming to v2. If you've noticed other sources of confusion that you think can be eliminated, please raise them in the comments!

[0xbigz]

agree with motivations in above. for context, the quirks come from trying to avoid write lock contention for a central data structure. specifically 1. comes from the evolution of the limit order not originally supporting auction params and 2. requires adding the concept of both a taker and maker price for the vamm (taker price being an offset s.t. it can pay the maker rebate).

[crispheaney]

Two questions that came up in private chat:

1. How are post-only orders filled by the vAMM? i thought that if i post-only, then the order will become a resting order on the DLOB. can the vAMM take against resting orders that are on the DLOB?

2. do limit orders have auctions now? from the docs i thought that market orders went through JIT-auction — do limit orders now have auction params that start at a price better than their limit price and then go to the limit price?

3. yeah the vamm can take against post only orders, right now the maker will get 0 rebate, but looking to change it such that it still gets the maker rebate

4. yeah limit orders can already have auctions. Right now the limit order isn't forced to have auction, but based on this proposal, limit orders w/out post will have auctions, to determine when they're taking vs. making

[wphan]

2. If a limit order is "resting" and filled by the vamm, the limit order gets the full maker rebate

Can this be achieved for spot too? Or is there any way to make it less of a surprise when a spot resting limit order gets filled off drift and is charged taker

[crispheaney]

right now there is no way for a resting limit order to fill against phoenix/openbook. could think about how to add that though

[crispheaney]

Started on #2, fills against vamm still gives maker rebate: #653

[0xbigz]

inspired by the post here

did a write up on the life of an order: https://hackmd.io/@bigz/Life-of-an-Order-on-Drift