Keepers & Decentralised Orderbook
Drift's decentralised orderbook is powered by our network of .
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 against Taker auction;
- Taker/Maker limit orders against Taker auction;
- Maker limit orders against Taker limit orders;
- Taker/Maker orders against the Drift's AMM.
Note: that (1) two post only maker orders cannot be crossed; (2) maker orders that fill against the vAMM are not eligible for rebate reward; and (3) limit orders can be filled by market orders that. gothrough the JIT auction.
Keepers earn rewards that incentivise:
- providing the best execution for takers (relative to the oracle price) and;
- following First-Come-First-Serve execution ordering
While a robust Keepers network improves throughput/usability, the protocol's core functionality is not crunched upon it. Existing trading bots (JIT makers and resting order takers) implicitly fulfill the role of Keepers.
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:
- the fastest;
- the best price improvement for takers; and
- 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: .
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:
- decentralisation; and
- 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.