Straight from Alex Connolly via the Immutable blog on Medium and resharing it here.

Immutable X Protocol Orderbook — Solving Order Fragmentation

At the heart of all NFT marketplaces is the concept of the “order”. Orders are fairly simple to understand: they’re a request to trade some amount of a particular asset for some amount of another asset. In the world of NFTs, this is usually either a listing (sell my NFT, buy 5 ETH), or an offer (sell my 5 ETH, buy this NFT). Trades are created by finding a pair of orders which want to exchange equivalent assets. The first order to be created (whether it’s a listing or an offer) is called the “maker” order, and the opposite order which “fills” the maker order and creates a trade is the “taker” order.

So what happens to “maker” orders before taker orders appear to fill them? Maker orders are stored in a backend called an order book. Traditionally, each marketplace or exchange will build and maintain their own orderbook, from which they display their active orders.

Currently, the most successful NFT marketplaces are big, broad aggregators — places where you can trade every type of NFT, like OpenSea, LooksRare or the upcoming Coinbase. Many next generation NFT marketplaces, like Fractal or Gamestop are seeking to provide an awesome experience for a subset of NFT traders (e.g. gamers), and new NFT marketplaces are being launched at what feels like weekly intervals. Every one of these new marketplaces has created their own orderbook, as shown in the above diagram.

All these separate orderbooks creates what we call “order fragmentation” — as listings only show up on their originating marketplace, each marketplace’s orders can only be filled by users of that marketplace. There might be dozens of people across the NFT ecosystem who’d pay your asking price — but if none of them use your marketplace, your NFT will never sell. This fragmentation results in a substantial drop in the overall liquidity of your NFTs.

Some awesome builders have created listing tools like genie.xyz, which lets you list assets on multiple marketplaces, or gem.xyz, which lets you buy assets across marketplaces. However, this only solves the problem for NFT power users who are a) aware these tools exist, and b) willing to forgo their preferred marketplace interface. They definitely don’t solve the problem for the millions of people who will buy their first NFT in the next three years, and who need the easy rails that more user-friendly marketplaces provide.

Unfortunately, this fragmentation is about to become even worse. A new category of NFT marketplace is coming: native marketplaces, built specifically for particular types of NFTs. This might be an in-game marketplace, integrated into the game client itself, or simply a dedicated web marketplace like NBA TopShot. It could even be something which doesn’t look like a marketplace at all — imagine buying Gods Unchained cards directly off the board, or Call of Duty skin from the deathcam.

Order fragmentation in this context is a huge problem — how can you build an amazing experience into a game when you don’t have access to the maker orders necessary for instant purchases or price discovery? Despite these experiences being clearly better for users, it’s possible that if orders remain isolated, users will be pulled away from these amazing experiences, towards generic marketplaces where there are more orders to choose from.

This segregated liquidity isn’t the only problem caused by marketplaces maintaining their own orderbook. Maintaining your own orderbook can introduce a ton of operational complexity — while building a simple orderbook is easy, it becomes much more challenging at scale, as trading bots compete for order flow, and as hundreds of thousands of users interact with the same orders. A great example of an unexpected complexity is order cancellation. Most NFT orders are “soft-cancelled” (as on-chain cancellation is too expensive), meaning that you trust the marketplace to destroy the order you signed. If that marketplace’s API exposed the signed order at any point, that order could still be published and filled (if someone had stored it) at any point in the future, leading to assets being sold massively under current market price.

Our solution is simple: build a global protocol-level orderbook for Immutable X. A protocol-level orderbook means any orders which are created anywhere on the Immutable X protocol are immediately visible on any IMX-integrated marketplace. Our goal is to build an ecosystem where hundreds of niche and native marketplaces can co-exist with larger, aggregating marketplaces. A great example of this is GUDecks, a Gods Unchained deck builder which allows you to instantly copy and buy popular decks — an awesome contextual experience which is only possible with external order flow.

Providing both the orderbook and the exchange contract (with L2 scale) allows us to prevent whole categories of synchronicity and UX issues, and create the best platform in the world for high-quality NFT projects like games.

The Immutable X order book is a deceptively simple product. Currently, it’s four simple APIs, built and maintained by Immutable, which anyone in the world can use to:

Crucially for order retrieval, all of Immutable’s APIs support advanced metadata filtering, based on our protocol-wide NFT metadata indexer. If you want to retrieve all orders created in the last 15 minutes which buy Guild of Guardians heroes with (class = mage, element = dark, faction = glade), they’re just an API call away. This allows marketplaces to implement complex frontends with filtering, searching and sorting, without writing a line of backend code. For a full list of the supported filters, check out our API documentation (we’ll be releasing a guide on using metadata filters soon).

To incentivise marketplaces to contribute to this orderbook, marketplaces can attach fees to each order they submit, specifying custom fees to multiple recipients on a per-order basis. Fees are persisted across marketplaces, so that no matter where the final trade occurs, the originating marketplace benefits from sharing its liquidity with the protocol. Marketplaces will set the fees they think they can justify — if you have confidence your users will still originate assets on your platform, you should charge higher fees.

The Immutable X orderbook launched with the protocol in mid-2021, though this is the first time we’ve written about it in blog form. To date, more than 20 million orders have been created in the Immutable X orderbook, and there are currently more than 5 million active NFT listings. The orderbook already services more than 150,000 API requests every minute, and we are in the process of adding some of the largest NFT marketplaces in the world (launched and unlaunched) to this liquidity pool.

If you’re building a trading program or market maker, it’s easy. Retrieve active orders via API, retrieve historical trades via API, work your magic, and then create and submit your taker order to create a trade. If you’re building a marketplace, there are two main choices:

Option 1: Use the Immutable X APIs directly from your frontend

If you’re building a marketplace exclusively for Immutable X assets, or integrating Immutable X asset trading directly into a native experience like a game, the best way to integrate is directly using the Immutable X APIs. You can pull the orders in using a parametrized call, then use the Immutable X Link’s buy(order_id) function to have the user automatically create and sign the matching taker order.

Option 2: Synchronize the Immutable X orderbook to your own backend

If you’ve already got an orderbook, or you’re showing assets concurrently from a variety of chains, then the best integration design is usually to synchronize. At the moment, the only way to do that is by polling the key endpoints in our system at regular intervals for any change in order state (e.g. new orders, cancelled orders, filled orders).

If you want to maintain the assetbook as well (to show user inventories), you’ll have to use a similar polling system for asset transfers, trades and mints.

We’re working to improve the developer experience here, and will likely switch to an event based system in future — if you have feedback on how you’d prefer to perform this synchronization, please let us know.

Currently, the order book is implemented at a protocol level — you can’t submit trades without at least one of those orders already being present in the orderbook. This may change in future, but we’re reluctant to do anything which might fragment the liquidity of our games and marketplaces.

Though the protocol orderbook will create massively improved trading experiences, our key customer for this product is actually marketplaces — if they don’t use it, it won’t actually improve liquidity. For emerging marketplaces, and for native experiences, the protocol orderbook is clearly beneficial — the hardest problem to solve is bootstrapping liquidity, and being able to show your users orders which originated elsewhere is crucial.

Some existing marketplaces may be initially resistant to the idea of sharing orders with other marketplaces. However, when you allow other marketplaces to fill your orders, you gain access to the combined user base of all of those marketplaces. Vastly more potential buyers will mean vastly more trades, with the incremental volume likely far exceeding the fees you’re sacrificing by not requiring orders to be filled on your marketplace. Additionally, your marketplace will be able to fill the orders you receive from other marketplaces in turn.

This tradeoff will become increasingly compelling as more marketplaces integrate with the orderbook — users won’t want to create orders which can only be filled on a single marketplace when they could be creating listings visible across an entire protocol. Finally, this will help marketplaces scale — in general, marketplaces’ customer acquisition costs will increase over time, as they exhaust the audience their product is best for. Integrating with the shared orderbook will let marketplaces take advantage of growth across the protocol, particularly from marketplaces who are targeting a different type of NFT trader. This will massively reduce the need for large spending on customer acquisition, freeing capital for reinvestment into the core product.

Right now, we are focused on integrating the Immutable X orderbook into as many marketplaces as possible, and ensuring we can handle the rapidly growing demand for the product. We’re also considering ways we can give marketplaces more information about how their orders are being consumed, to let them optimize their target audiences.

As we launch new types of trading on Immutable X, we will continue adding functionality to the orderbook. For instance, when we add “metadata orders” (trading assets based on their metadata characteristics), that will also be rolled out into the shared orderbook. We’ll also have an update on our plans with StarkNet very soon — and the order book will definitely be involved.

Our mission at Immutable is to solve the problems which are preventing mass-scale, high-quality NFTs from taking over the world in industries like gaming. We built the Immutable X orderbook to solve the problem of order fragmentation and to allow devs to build amazing in-game trading experiences. If you’re building a web3 marketplace or game, we’d love to hear from you. If that’s a mission that excites you as a builder, we’re hiring in product, engineering and design — there’s so much left to do to make high quality NFTs accessible to everyone.

We’re going to create a series of articles like this covering the entire Immutable X product. To get them as soon as they drop, you can follow both Immutable, and me (Alex Connolly, CTO) on Twitter.