Serum Core

An overview of Serum's Asset Agnostic Orderbook

Conceptualized and developed by Bonfida, Serum Core is an important upgrade to Serum that brings a number of benefits for the DeFi ecosystem on Solana.


As the Solana DeFi ecosystem continues to grow, many projects invest a lot of time into designing a bespoke market implementation instead of leveraging the capabilities offered by the Serum orderbook. This is mostly due to the fact that Serum is over-specialized on spl-token assets.

Not all financial assets must be tokenized

Implementing a Perpetual futures exchange on a Serum orderbook (OB) implicitly requires positions to be tokenized, with a common mint for each market pair. This is impossible because a perpetual future position is inherently multi-dimensional: a position is described by its size, its entry price and the collateral it contains. This means that a position isn’t a multiple of a smaller position element, in the same way that an spl-token asset is.

In an OB based perpetual futures market, the OB is a matching engine. Entries in the OB are identical to the current Serum orderbook: they only contain an order size and price. The key difference is what happens when a match occurs between maker and taker: instead of triggering an implicit transfer of spl-tokens between maker and taker, the matching engine triggers the creation of a position owned by the taker and held with the maker.


Due to the constraints of the Solana runtime, Serum has had to implement an event queue to create a buffer between the difficult to predict and non-sequential matching engine and writing back into open order accounts. In an asset-agnostic orderbook, Serum’s event queue is the output, and programs which are built on top of Serum have exclusive access to their associated market’s event consumption crank. This means that these programs can themselves be cranked, read into the event queue, pop the processed element from the queue, and then use the resulting matching information to create and enforce complex contracts between the matched parties.

Fee model

Serum’s current fee model relies heavily on its specialization with spl-token swaps between different parties. Every transaction extracts a few bps from the transfer. With an asset-agnostic orderbook, fees have to be extracted differently to support the matching of any asset including those outside of the spl-token program.

In addition to this, fees only remain justifiable insofar as the Serum community provides a service on top of the technology itself. We believe that a good example of such a service is cranking the matching engine itself. All asset-agnostic orderbooks share the same matching code which means that any Serum cranker can crank all instances of the asset-agnostic orderbook across all applications.

This means that all programs will have an incentive to use the main Serum program as their core OB, without resorting to a fork. Once this is established, there are a few candidate fee models, including:

  • The flat fee model: A flat (USDC or SOL) fee is taken on each transaction. The fee can be specific to each OB primitive.

  • The market-driven model: App developers set the amount of fees that they transfer to Serum on each operation. Data about each program’s cranker profitability is directly written into the agnostic market’s on-chain state by keeping track of the number of transactions as well as the total amount of fees collected over its lifetime.

  • The average fee model: Each market keeps track of the number of transactions as well as the total amount of fees collected for its lifetime. Program developers then have to ensure that the average fee per transaction doesn’t fall below a defined threshold. This is very similar to the market-driven model.

Serum Core applications

Serum Core can be used for a wide range of applications. The first obvious application would be to rebuild Serum DEX on top of Serum Core. The modularity and fee structure of the new Asset Agnostic Order Book will also allow other projects to use it as their backend matching engine for any type of financial product (futures, options etc).

One of these financial products would be an orderbook-based borrow lending protocol. This borrow lending protocol would be very similar to BitFinex and FTX lending:

  • Borrow rates determined using an OB

  • Different maturities available on different OBs

  • Liquidations would happen on Serum public markets

  • Any token with a Pyth feed and enough liquidity on its Serum market could be used as collateral

Developer Resources

Last updated