# **The Life of an Order (on Drift Protocol)**

Central Limit Order Books (**CLOBs**) are often referred to as ~Only Possible On Solana~ [#OPOS](https://solana.com/possible), and numerous CLOB [implementations](https://github.com/openbook-dex/openbook-v2) [already](https://github.com/Ellipsis-Labs/phoenix-v1) [exist](https://github.com/metaDAOproject/YALOB).

Even on L1's like solana, CLOBs have limitations on scalability:

**Problem with CLOBs**:

- **Write locks**:
- Across makers in a single market only a few place/cancel operation can occur per slot.
- If you have `N` makers, they have to compete with each other, potentially leading to less competitiveness, which ultimately affects takers.
- **Liquidity Bootstraping**
- chicken-egg problem of sourcing demand and supply in tandem, without syncronizing the size of flow in both, there is a heavy tax to pay to subsidize
- **Network Jitter**
- theres level of randomness for included transactions in blocks. that means makers have a harder time active updating their prices and are forced to quote wider to avoid adverse selection

**Solution**: **Distribute the orderbook**.

Drift took a different approach with a **Distributed Limit Order Book (DLOB)**. Instead of a central data structure that results in write-locking contention and upper bounds, Drift gives each user an orders account. This way, when users **place** orders in their own account, they don't write-lock any global state for the market. Only the less frequent **matches** will write-lock the market account.

**Caveat**:

If you have a distributed orderbook, how can you ensure good/best pricing and fills?

**Solution**:

- **Auctions**: The Drift orderbook is asynchronous. Searchers construct the price-time order.
- Auctions are optional; a user can atomically take if they choose, but they'll need to find their own counterparties.
- Users can specify their auction as a function of the oracle price.
- Various parameters on the [`Order` struct](https://github.com/drift-labs/protocol-v2/blob/master/programs/drift/src/state/user.rs#L928), including auction-related details like start/end price/duration, IOC, post-only, oracle offset, limit, expiry timestamp, etc., allow users to specify their intentions, ensuring they are satisfied with the result at runtime or after N slots.
- **Keeper Incentives**: Keeper bots earn fee when matching orders and earn higher fees when adhering to price-time ordering AND giving takers fills closer/better than oracle price.

Setting the right auction parameters is an open problem, similar to what's discussed in the Uniswap v4 paper [0]. Often, this can be resolved through UI/UX design and real-time analysis feeds/services.

**Additional Liquidity Methods**:

### **JIT (Just-In-Time)**:

Instead of posting on the DLOB, makers can also provide JIT liquidity. Once an order goes through the auction, both JIT makers and keepers compete to match resting orders. Some advantages of JIT makers are:

- They save on gas (as they don't need to place/cancel continuously) and avoid getting sniped on price moves.

The jit maker's disadvantage is that existing resting liquidity may be serviced by others who aren't inclined to enter the auction. (those who seek atomic fills)

Another potential disadvantage for an end user is they can't see "potential" jit liquidity (since the intents binding or posted onchain).

### **vAMM (Virtual Automated Market Maker)**:

Given a system of distributed and potentially discriminating liquidity, it's essential to have a backstop liquidity provider of last resort. Ordinarily an exchange makes a deal a market maker to be the "designated maker". In exchange for high uptime especially in extreme market scenarios, they'll earn some reoccuring reward.

This designated maker is instead built natively into Drift as a vAMM: a per-market, advanced, open, and on-chain liquidity provider partially serviced/expanded by user LPs (Liquidity Providers). The backstop liquidity is only hit after a speed bump (e.g. 10 slots) and earn a higher fee rebate for their service.

The vAMM uses the following information
- oracle / confidence
- market/oracle price volatility
- current inventory
- recent performance
- fee pool balance
- buy/sell pressure

Before every fill attempt, the vAMM is allowed to update its quotes. If the oracle is deemed invalid, the vAMM will not offer liquidity for that slot. Additionally, a single fill can only take a certain size of liquidity before the vAMM is allowed to update once more. Additionally, vAMM liquidity is limited, the vAMM can become one-sided after one-side has been taken against.

#### vAMM restrictions

With the vAMM built in natively to the protocol. That is why the vAMM design has the following principles in mind (to ensure proper alignment within the protocol).
- The vAMM cannot discriminate on a per user level (e.g. not service and/or offer one user better prices than another)
- The vAMM profits are not extended to insurance stakeholders and instead reinvested in increasing liquidity for that market.

This makes the individual market's vAMM an extremely loyal designated maker (one that will never leave for greener pastures).

The only exception to the above when a market is ultimately delisted (and all positions are force closed at the settlement price). After this the vAMM's entire balance is sent to the revenue pool.

#### vAMM JIT liquidity (for rebalancing)
In some scenarios, the vAMM has an advantage on some of the fills that can rebalance in the auction stage.

Ordinary the vAMM is quoting wide around the oracle price (+/- a potential reference offset). By doing so it can acquire toxic flow when no other maker is willing to fill.

To help 'unload' toxic flow, vAMM provides supplemental liquidity at prices filled by external makers. In the event the individual maker takes and entire size and protocol rules want the vAMM to rebalance, the vAMM can take *up to half* of the share of the taker for itself. While this can be undesirable, it is a necessary compromise for ensuring protocol solvency. Ultimately, if external makers competitively filled during all times, they would never face this situation.

### Conclusion

The Drift Protocol aims to provide a unique and distributed solution to address the limitations and challenges associated with traditional CLOBs, offering various options to optimize order execution and liquidity provision.

[0] - https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf