DeepBook Design
At a high level, the DeepBook design follows the following flow, which revolves around three shared objects:
Pool
: A shared object that represents one market and is responsible for managing its order book, users, stakes, and so on. See the Pool shared object section to learn more.PoolRegistry
: Used only during pool creation, it makes sure that duplicate pools are not created and maintains package versioning.BalanceManager
: Used to source a user's funds when placing orders. A singleBalanceManager
can be used between all pools. See BalanceManager to learn more.
Pool shared object
All public facing functions take in the Pool
shared object as a mutable or immutable reference. Pool
is made up of three distinct components:
Logic is isolated between components and each component builds on top of the previous one. By maintaining a book, then state, then vault relationship, DeepBook can provide data availability guarantees, improve code readability, and help make maintaining and upgrading the protocol easier.
Book
This component is made up of the main Book
module along with Fill
, OrderInfo
, and Order
modules. The Book
struct maintains two BigVector<Order>
objects for bids and asks, as well as some metadata. It is responsible for storing, matching, modifying, and removing Orders
.
When placing an order, an OrderInfo
is first created. If applicable, it is first matched against existing maker orders, accumulating Fill
s in the process. Any remaining quantity will be used to create an Order
object and injected into the book. By the end of book processing, the OrderInfo
object has enough information to update all relevant users and the overall state.
State
State
stores Governance
, History
, and Account
. It processes all requests, updating at least one of these stored structs.
Governance
The Governance
module stores data related to the pool's trading params. These parameters are the taker fee, maker fee, and the stake required. Stake required represents the amount of DEEP tokens that a user must have staked in this specific pool to be eligible for taker and maker incentives.
Every epoch, users with non zero stake can submit a proposal to change these parameters. The proposed fees are bounded.
min_value (bps) | max_value (bps) | Pool type | Taker or maker |
---|---|---|---|
1 | 10 | Volatile | Taker |
0 | 5 | Volatile | Maker |
0.1 | 1 | Stable | Taker |
0 | 0.5 | Stable | Maker |
0 | 0 | Whitelisted | Taker and maker |
Users can also vote on live proposals. When a proposal exceeds the quorum, the new trade parameters are queued to go live from the following epoch and onwards. Proposals and votes are reset every epoch. Users can start submitting and voting on proposals the epoch following their stake. Quorum is equivalent to half of the total voting power. A user's voting power is calculated with the following formula where is the voting power, is the amount staked, and is the voting power cutoff.