Keepers & Decentralised Orderbook

Drift's decentralised orderbook is powered by our network of Keeper Bots.

The Keeper Bots match open orders with various on-chain liquidity mechanism once they cross or their trigger condition is met. These scenarios include:

• Taker auction againist taker auction;
• Taker/Maker limit orders againist taker auction;
• Maker limit orders against taker limit orders;
• Maker limit orders against maker limit orders; and
• Taker/Maker orders against the Drift's AMM.

Keepers earn rewards that incentivise:

1. providing the best execution for takers (relative to the oracle price) and;
2. following First-Come-First-Serve execution ordering

Keeper Bots listen, store, sort and fill valid limit orders. Keepers do this by compiling all valid open orders found on-chain and organising them into an off-chain orderbook. These orders are sorted by price, age, and if two orders have the same age, they’re then sorted by position size.

Each Keeper holds its own orderbook (hence 'decentralised orderbook').

Keepers then listen to trigger conditions and match crossing orders and limit orders against the DAMM when the users’ trigger or limit price is met.

For performing this critical duty, the Keepers earn a fee for every trade they execute. Similar to liquidation bots, Keepers will compete for fees in a decentralised system; with the most profitable Keepers being:

1. the fastest;
2. the best price improvement for takers; and
3. the ones that fulfil orders in the protocol’s desired sequence — oldest and largest first.

Reference implementations for the filler and trigger Keepers are provided: Tutorial: Keeper Bots.

Currently the USDC reward function for keepers (f_keeper) is designed as:

where: t_order is seconds since order was placed f_user is the taker fee paid by user who placed the order This reward is subject to evolve to incentivise CLOB-like execution ordering. See [source code] for the on-chain calculation.

A Keeper reward multiplier (for taker price improvement) is applied to the keeper's minimum time based reward component in the function above. Any percent improvement versus the baseline oracle +/- 10bps, increases this multiplier.

The decentralised orderbook is designed with two core values in mind:

1. decentralisation; and
2. computational efficiency.

Decentralisation is achieved through our network of hybrid off-chain Keepers that anyone can build and run — similar to liquidator bots.

Computational efficiency is achieved by leaving the order-filling logic — the part that requires the most computational power — off-chain, and filling them on-chain upon a trigger.

Hence, Drift’s unique limit order system is a hybrid system that uses a combination off-chain Keepers and on-chain settlement.