Opening a new book: A Deep Dive on OpenBook

OpenBook has taken everyone by storm, leading to a new wave of unity in the Solana Ecosystem. In this blog, we'll be going over everything from its backstory to its future potential, so sit back and enjoy!

Introduction: Birth of Openbook

Serum Protocol was launched in August 2020, one of the first decentralized exchanges or DEX to deliver low transaction costs and high transaction speed on Solana. It was fully permissionless and followed a central limit order book or CLOB Model.

If you don’t know what CLOB model is and how it is different from AMM model, you should check this blog out.

One key feature of Serum was the ability of other protocols in the Solana ecosystem to integrate with and use Serum’s on-chain order book, further adding liquidity to a single place, making trading more efficient for both institutional and retail users, and enabling other projects to offer decentralized trading without having to maintain their orderbook.

Things were all good until the recent FTX collapse when the new CEO John Ray announced a general warning that there was a security breach and people didn’t know which parts were compromised. It was a problem because the Serum Program update key was not controlled by the Serum DAO but was instead connected by a private key to FTX. It means that if anyone gets their hands on the private key, they could use it to negatively update the Serum program by deploying malicious code that could harm the platform or its users.

It was a big problem that Max and a couple of other developers sought to fix. They identified the last deployed version of Serum. They could deploy the same version built with a new program ID and the authority to upgrade the system. A group of trusted developers now controls the fee revenue through a multi-sig mechanism.

It was quick thinking from various developers in the ecosystem that led to a fork of Serum v3, now known as OpenBook.

With all that being said, let’s dive into detail about OpenBook!

Open the (Order)Book

As stated, OpenBook is a DEX on Solana following the CLOB Model. In this section, we'll be going over the more technical aspect of a DEX and how a user interacts with the DEX via the different order types.

On a higher level, the lifecycle of a trade can be split across four stages:

• Placing orders: Users transfer funds from their SPL token account (wallet) to an intermediary account called the OpenOrders account and submit an order placement request to the Request Queue.
• Matching orders: Requests are removed from the Request Queue, matched with other orders, and placed on the Orderbook, with any resulting trades reported in the Event Queue.
• Consuming events: Trade events are removed from the Event Queue and processed, resulting in updates to the OpenOrders account balances.
• Settlement: Users can transfer any remaining funds from their OpenOrders account back to their SPL token account (wallet) anytime.

Let's go through each of these stages separately.

Placing Orders

For placing an order, the user submits three main things.

• His order details, i.e., the Market he is trading, price, size, order type, and size
• Second is their SPL token account, and if selling, the Market's base currency is to be used, while for buying, the user should use the quote currency token account.
• Lastly, we have the OpenOrders Account of the user.
  

What is it? An OpenOrders Account is a middleman account that stores information related to a user's open orders on the OpenBook platform, including the amount of locked-in base and quotes currency and a list of all open orders the user places.

On the backend, if a user is buying, the user moves funds from the SPL token account to the OpenOrders account based on the needed funds and available balance, increasing the OpenOrders account. While if a user is selling, the user moves funds from the OpenOrders account to the SPL token account based on the available balance and the required funds for the sale while decreasing the OpenOrders account balance.

The DEX then:

• Increments and retrieves a sequence number from the Request Queue": A DEX assigns a unique sequence number to each order placed on the platform. This sequence number is retrieved from the Request Queue, a data structure that stores the order placement requests made by users. The sequence number and the order's price are used to determine the new order's ID.
• "Adds an item to the Request Queue specifying the order details (size, price, order type, side)": Once the sequence number has been retrieved, the DEX adds an item to the Request Queue with the order details, such as the size of the order, the price, the order type (buy or sell), and the side (bid or ask).
• "Adds an item representing the new order to an array in the OpenOrders account in an available slot": The DEX also creates a new order object representing the user's order and adds it to an array in the OpenOrders account in an available slot. This array keeps track of all the open orders that the user has placed on the platform.

When placing an order on Solana, specific rules apply to ensure the security and integrity of the process.

• If any step of the process fails, the entire transaction will be canceled to prevent any unintended effects.
• A critical aspect of this process is the transfer of funds from the user's SPL token account to the OpenOrders account. This transfer is executed by a cross-program invocation to the SPL token program, meaning that the DEX program requests the SPL token program to perform the transfer, provided that the SPL token account holder has been granted permission to do so.
• Furthermore, for the transaction to be valid, it must be signed by the owner of both the SPL token account and the OpenOrders account. It is verified by the DEX program and SPL token program to ensure that the legitimate account owner carries out the transaction.

Matching Orders

Matching orders on Solana-based DEXes, also known as "crank turning," is a crucial step in executing trades. It involves removing requests from the Request Queue, a data structure that stores the order placement requests made by users. The matching engine then processes these requests by updating the orders on the Orderbook and putting information about resulting trades in the Event Queue. It is a continuous process; anyone can submit this instruction by paying the transaction fees.

It is important to note that the process is fully automatic and does not require the users whose orders are involved to sign. It is because the program owns the accounts involved in the process, and the matching engine process is deterministic, meaning that it proceeds in a known and predictable way. Each item in the Request Queue is processed in order exactly once and has a deterministic effect. It ensures that the process is safe and people cannot influence trades.

The process of Match Orders is a transaction where clients provide a limit parameter, which specifies the number of requests to process from the Request Queue.

Each request is processed in a series of steps:

1. It is removed from the RequestQueue account.
2. The corresponding order placement or cancellation is made on the Orderbook, a data structure that stores the details of the orders.
3. In the case of a new order, it is stored in the Orderbook, including information such as the side, price, remaining size, the public key of the order placer's OpenOrders account, and the index of this order in that OpenOrders account's order array.
4. Order types like IOC (Immediate or Cancel) and post-only are enforced.
5. Two corresponding Fill items are added to the Event Queue for any trades.
6. In the case of a trade, cancel, or IOC order that was not matched, Out items, are added to the Event Queue.

It leads to the Match Orders process generating two Fill items event queue objects. These are Fill and Out objects. These objects store essential information used in the next step, Consume Events.

• Fill objects store information about the trade, including the side of the trade, whether that side was the maker, the quantity of currency paid and received by each party, and the quantity of any fees paid.
• Out objects store information about any orders that were not matched or were canceled, including the side of the order, the quantity of the order that was unlocked, and the quantity that is still locked.

Fill and Out objects also store the order's ID, slot number, and public key of the corresponding OpenOrders account.

Consuming Events

The Consume Events step updates the user's account balances based on the events generated by the Match Orders step; the client has to read and process the event log and submit relevant accounts for the update.

The process of Consume Events is as follows:

The Consume Events step updates the user's account balances based on the events generated in the Match Orders step. It checks if the user's open orders public key is found in the list of accounts submitted by the client and if it is

• It proceeds to process the event by updating the user's account balances like decrementing the OpenOrders account's total balance by the quantity paid, incrementing the total and free balances by the quantity received, and incrementing the Market's total fees paid counter by the number of fees paid for Fill events.
• For Out events, it increments the OpenOrders account's free balance by the quantity unlocked and removes the order from the OpenOrders account's list if the locked quantity is zero.

Settling Funds

This step allows users to transfer any funds not locked in open orders from their OpenOrders account back to their SPL token wallets.

It works because the user provides their OpenOrders account and SPL token accounts for the base and quotes currency and signs it with the same key pair used to sign for placing orders. The instruction uses a cross-program invocation to the SPL token program to move the free funds from the Base Currency Vault and Quote Currency Vault to the provided SPL token accounts.

This step is optional as the funds can be used to place more orders, and they will not be confiscated or used by any third party, but it's also harmless to withdraw the funds and keep them in the user's SPL token accounts.

Canceling Order

Canceling an order is similar to the process mentioned above and has a similar life cycle. If a user wants to cancel an order, they need to submit a request to the Request Queue, which the Match Orders instruction would then process. During this process, the order would be removed from the Orderbook, and an Out event would be added to the Event Queue, specifying that the order has been canceled. This event would then be processed by the Consume Events instruction, which would update the user's OpenOrders account by incrementing the free balance by the quantity of the order that was unlocked and removing the order from the account's order list if it was a complete cancellation.

Fees

Regarding the fees, the core contributors at OpenBook stated during their first community call that the Openbook DEX is considering reducing taker fees and having the GUI collect it all, but it may not be ideal for market makers. Another option is a 4bps flat fee for all markets, which is consistent but may be less attractive to market makers. More research is needed by talking to market makers and traders to determine an ideal approach. However, it may attract fewer market makers. They can also improve this by creating a new discord channel and dedicating a team to this task.

However, for the time being, OpenBook charges a taker fee of 4bps and a maker rebate of 2bps with a 2bps UI rebate. If you are hosting your own UI or trade via the OpenBook SDK, you only have to pay 2bps and save on the UI Fee.

How can you interact with OpenBook?

Users can use a pre-built library called Openbook-js, written in JavaScript, and use it with their private keys to interact with the Openbook protocol.

Users can also trade on the Openbook DEX using a web-based graphical user interface or GUI that does not require them to provide direct access to their private keys. The GUI is built using an open-source, client-side library called Openbook-js, which allows users to access the DEX and perform actions such as trading, checking their trade history, and managing their account balances.

Users connect their wallet to the GUI by clicking the button in the top right corner and clicking 'Connect' on the popup provided by the wallet. Once connected, the DEX can read the on-chain state and display data specific to that user. To perform actions that require signing, such as placing an order, the user fills out the order form in the top right corner, clicks buy or sell, and then approves or cancels the corresponding transaction through a popup window provided by the wallet. The passage also encourages Solana wallet providers to implement support for the SPL token and sol-wallet-adapter interface to make it easier for users to connect to and use the Openbook DEX.

Contribution and Competition

OpenBook follows a Decentralized Autonomous Organization or DAO governance model. A DAO is an organization that operates on a blockchain network and is run by its members. Members of Token holders can vote on proposals leading to changes in this organization.

A few proposals that have already been voted on can be seen here.

When asked how people could contribute to OpenBook, the core contributors said they recognize that there may be more effective ways to attract and retain top talent than traditional grants for independent developers. Instead, they propose defining bounties more clearly to attract independent developers to the project. One potential solution is using Gitcoin grants, where each team can write down specific tasks they want to be completed, and other parties can fund them. Additionally, the Openbook team could launch a call for proposals for Gitcoin grants starting in January, with the Solana Foundation funding some of these proposals.

Furthermore, the team envisions transitioning from solely relying on the Foundation for funding to a more decentralized approach where various actors within the ecosystem, such as other protocols and market makers, can also contribute to funding the project's development in the long run.

When posed with questions about how they wish to proceed in the future and see OpenBook against their competitors, the core contributors at OpenBook said that it is crucial to maintain the Openbook DEX as a rent-free alternative, even if the other next-generation order books come up. A parallel orderbook without rent-seeking is a public good and can be helpful. By maintaining this orderbook, integrations and composability can reduce liquidity fragmentation.

As stated earlier by the team, developers and teams should consider paying for Gitcoin bounties to support organic development. Openbook plans to submit RFPs for Foundation sponsorship during the next DeFi hackathon.

In conclusion, the goal is to maintain Openbook as a rent-free alternative with no rent-seeking tendencies and to encourage community grants and organic development by developers.

Future Outlook (or Outbook?)

As the Solana and Openbook communities continue to expand, there are many opportunities for individuals and developers to get involved and contribute to the ecosystem. Keeping up with the latest developments, resources, and tools is crucial for getting the most out of the ecosystem. It is advisable to visit the Project Openbook website for updates, check out the various available developer tools, and join the community's discord group to stay informed and connected.

When I posed a similar question to Soju, he said that protocols should focus on building things that can only be built on Solana, such as order books and derivatives. He believes this will lead to a more impactful and valuable ecosystem rather than wasting resources on less critical projects.

He also highlights that Openbook is a true community-owned orderbook, and its potential as a public good primitive is massive. Soju believes that people can build on it, fork it, and utilize it in various ways, leading to a more significant potential for the project and the ecosystem.

Closing this book

In conclusion, OpenBook is a DEX that operates on Solana and follows the central limit order book or CLOB model. The platform was created as a fork of Serum Protocol, which faced security issues related to controlling its program update key. OpenBook aims to provide a more secure and community-owned order book for the Solana ecosystem, allowing for more efficient trading for institutional and retail users and enabling other projects to offer decentralized trading without maintaining their orderbook.

OpenBook offers a range of technical features for its users, including placing, matching, consuming, and settling trades, as well as a range of trading fees. The team behind OpenBook is also actively exploring ways to improve the platform and make it more attractive to market makers. Users can interact with the platform using a pre-built library called Openbook-js or a web-based graphical user interface that does not require them to provide direct access to their private keys. OpenBook is a valuable addition to the Solana ecosystem, providing a secure and community-owned order book for decentralized trading.

It will undoubtedly be an exciting year to see what OpenBook and the whole Solana ecosystem achieve this year!

Stay Tuned with #GooseAcademy

Website | Twitter | Telegram | Discord | Docs

Disclaimer: The statements, proposals, and details above are informational only, and subject to change. We are in early-stage development and may need to change dates, details, or the project as a whole based on the protocol, team, legal or regulatory needs, or due to developments of Solana/Serum. Nothing above should be construed as financial, legal, or investment advice.