Decoupled Order Matching and Settlement
Last updated
Last updated
Exchanges over the past cycles have adopted an innovative way of conducting various functions, placing order matching off-chain, while settlement on-chain. This aims to overcome the disadvantages of limited on-chain throughput, by conducting expensive operations like order matching off-chain, while lightweight functions on-chain. However, this has had it's own set of problems: off-chain orderbooks cannot be trusted and is against the ethos of crypto. Off-chain orderbooks cannot be held accountable, they can be completely arbitrary, and they are not verifiable.
When we were building Spicenet, we wanted to make it the most flexible trading protocol ever built. Builders should be able to customize the f*ck out of the trading protocol and satisfy their needs. Current trading protocols are not only not flexible, but also stifle innovation by introducing off-chain orderbooks, limited-access APIs and poor composability standards. We wanted to give a 100x. And fundamentally, that meant decoupling the different functions of an exchange.
Note that this description is pretty verbose and subjective. "Exchange Functions" can vary drastically depending on the underlying exchange itself.
Broadly, exchanges have 3 functions: match user orders, settle/clear their orders against their custodied assets, and manage risk. On-chain exchanges have initially sought to vertically integrate these functions into a single environment, for maximal simplicity and better UX. However, with the advent of hybrid exchanges(discussed above), this status quo has been flipped upside down, as they modularise and decouple the various functions of an exchange and conduct them independently. But, they do not come with their own drawbacks(again discussed above). So, what's the solution?
At Spicenet, exchange functions are decoupled by default, but yet run and compose with each other via a single state machine. What's the benefit? This means that app builders can pick and play with different exchange functions to build highly expressive, customised and advanced applications, that haven't been possible before. Let's understand the demands of a modern trading application before we can understand the use-cases this functionality can fulfil.
Trading applications today demand
High performance and throughput. For order matching.
Decentralised settlement on existing chains for better liquidity capture.
Tightly-coupled and integrated experience for users, abstracting all complexity.
To phrase this better, trading applications demand high-throughput for order matching, while still requiring decentralised settlement on chains like Ethereum for better liquidity capture, all the while offering an integrated experience to users. A really tough task.
Spicenet helps applications solve this problem by allowing them to use Spicenet's various exchange functions as standalone products. For example, a trading application can choose to use Spicenet just for order matching, while handling settlement elsewhere. And this is absolutely possible and viable for applications than running off-chain orderbooks. For applications, this is actually advantageous because they achieve performance similar to, or better than off-chain orderbooks, all the while retaining transparency, fully on-chain commitments backed by $SPICE, $BTC and $ETH, and full verifiability.
And using Spicenet's native message-passing bridge, applications can seamlessly integrate the order matching(on Spicenet) and settlement(on another chain, like Ethereum) functions such asset deltas(balance changes created due to new orders matched) can be finalised as quickly as possible, leaving little room for offer. Using Spicenet's fast optimistic confirmations, users can experience real-time trading, while maintaining their assets on existing chains, i.e no clunky bridging and lost fees.
The more interesting aspect is the risk engine. As one might have guessed, applications can fully customise the risk engine of their choice too. They can choose to use Spicenet's flagship risk engine, that allows for highly capital-efficient trading, or rollout their own, that validates trades happening on their platform. This level of flexibility can only be enabled with full decoupling of an exchange, allowing matching, settlement and risk to exist separately, yet function as one(for Spicenet-native applications).
So what can be the use-cases of this decoupled architecture? This section aims to outline a few potential use-cases and also outlines the ease-of-use for applications that want to use exchanges functions as standalone products.
Using Spicenet's decoupled architecture, apps can use various exchange functions as standalone products, and therefore do not need to reinvent the wheel by re-building the same infrastructure. For example, apps do not need to build an order matching function from the ground up, when they can rather plug into Spicenet's Flashbooks and access hybrid Intent-AMM liquidity. And this way, apps can avoid building a full-blown exchange from scratch, and rather get to market much faster.
This unleashes more innovation at the trading / exchange layer, as apps can now focus on user acquisition, GTM, incentives and release innovative trading products that appeal to traders, and significantly expand the pie of DeFi, which unfortunately has not seen much innovation since the last cycle.
Apps and projects can use Spicenet as a better alternative for off-chain orderbooks. Flashbooks on Spicenet can give the same real-time experience as off-chain orderbooks, instead backed by credible commitments using BTC, ETH and SPICE stake. They are also transparent and verifiable. ZK proofs of order matching on Flashbooks can be easily and succinctly verifiable via light clients, reducing trust assumptions.
More importantly, Spicenet is also more "live" than off-chain orderbooks. Featuring a credible sequencer decentralized(or rotation) protocol, Spicenet can sustain itself against downtime, high network latency and more. Hence, it is a low hanging fruit for apps that prefer security and liveness, alongside performance to use Spicenet's order matching function as a standalone feature for their trading application, while handling settlement elsewhere.
