XRPL CLOB DEX 🏅

We’re going to be the most liquidity, highest volume, and highest revenue exchange on XRPL and potentially across any blockchain.

Medium article mentioned in the videos for quick reference: https://medium.com/injective-labs/injective-exchange-upgrade-a-novel-order-matching-mechanism-fa66b3d3c1f5 Note that I have nothing to do with Injective, I'm just a fan :)

Short description: Decentralized central limit order book exchange on XRPL using Injective-style frequent batch auctions and signed transactions not submitted to the chain to facilitate 0 cost order placement by using a mixed centralized and decentralized model with path to full decentralization later.

This approach is better than an AMM dex because it’s much more capital efficient for liquidity providers, so they should end up providing more liquidity at better prices, resulting in better pricing for participants and a chance for the exchange to draw significant liquidity and volume. 

This is better than a regular central limit order book DEX because order placement is free, which is not always the case, which further encourages market makers to provide liquidity as they typically have a high order cancel rate (98%+), making order placement fees challenging. Also, order placement fees complicate their models, and we want them to be able to plug and play with their CEX models to any degree possible. Additionally, the frequent batch auction system is well documented in the literature as a viable alternative approach to continuous double auctions, which is the method we see employed by virtually every centralized exchange. The batch auction system is suitable for our application because our system, due to being on-chain, can never be as fast as a centralized exchange, so we can’t really compete to be the venue of price discovery without an alternative auction system. This approach gives us a chance of being the price discovery leader at every auction expiration, which would draw additional liquidity and volume.

Details of implementation:

Centralized order book: Users submit payment transaction signatures to our centralized order book application. Those transactions act as orders. The application stores the payment transactions signatures. The payment transactions are all paying into a multisig wallet managed by our application, as in, they all have the same destination address. For now, the wallet is centralized, but later we can decentralize it. When submitting the orders, they include a real XRPL transaction approval for the amount that they are willing to pay in their order. This is not broadcast on-chain, so the transaction fees are not incurred unless an order matches. All orders can include an expire time, after which, we drop the order from our system and the signature becomes invalid. To get around the sequence numbers on XRPL transactions, we get users to sign multiple transactions with increasing sequence numbers. Users can request a cancellation from our centralized order book at any time. Cancellation is not guaranteed but is done on a best effort basis, as they might cancel just as an auction that would fill their order is happening. The cancellation generally should be CEX-level fast, though, to attract institutional market makers.

Thoughts on decentralizing the order book: Maybe later we could decentralize the order book to the nodes that handle running the auctions for order matching. I haven’t thought much about this yet because I think it’s ok if the order book is the primary centralized component, for now, anyway, because the order book is public, so anyone can verify that their order exists or that it was cancelled successfully. The full order book, level 3 (each individual order, not just combined at price levels), is available via the centralized order book API.

Before we match an order, we check to see the most recent sequence number used in a wallet. If we don’t have a signature for a higher sequence number, then we just drop the order, as it is no longer valid. If we do have a sequence number high enough, we just use that one. In the future, we could also implement using the ticket system, but for now, multiple signatures gets around the problem suitably. Additionally, the sequence number system in XRPL can serve as an alternative approach to cancelling orders, if, perhaps, the API becomes unavailable.

Multisig wallet: All users are signing transactions to pay into the multisig wallet. For now, it is centralized and the only signer on the wallet is our application. Because order matching is deterministic, we think we can later decentralize this to allow anyone to spin up a node that can become a validator for the auction process. Being a node could be permissionless. Nodes could get a share of the trading fees. 

Trading fees: Since all the payment transactions / orders are aimed at the same address, the application can just charge fees before making the settlement payments out to the users who have matched orders. We are not implementing fees as part of the hackathon because we think adding them later is simple and it’s not necessary to showcase the core functionality.

Accounts: there won’t be any notion of accounts. Each XRPL address or wallet will serve the purpose of an account. Any address can submit orders to the centralized order book and receive payment from the multisig wallet. 

Users submitting orders: When a user submits an order, they need to submit it as a payment to the multisig. We won’t broadcast it until they actually get a fill, though. They will need to include other data along with the payment transaction including what they are trying to buy or sell, which is also signed by the wallet. Information on specifics should be available in API documentation (eventually). This is implemented currently.

Order matching: We are using an Injective Protocol-style frequent batch auction system that resolves, currently, every 5 seconds. This is implemented already and is fully centralized for now. The order matching part is passing all tests and is deterministic.

User interfaces: For now, we just have an API, but we could build a front end later to facilitate order submission, which will just use the API. The API is ultimately the only way to place, cancel, or view orders.

Preventing front running: This isn’t currently implemented and won’t be for the hackathon, but we don’t want to reveal the orders placed between the most recent auction and the upcoming auction. Only after an auction takes place do we reveal the orders placed in the most recent time period on the public order book.

Trading Fees/Project Revenue: We aren’t implementing fees for the hackathon, but if we did, here’s how they should work: Any orders that were resting on the book from before the last auction pay 0 fees (as in, 0 maker fee). Orders that fill in the current auction pay 1bp, so 2bps total is charged on a trade (buyer pays 1bp, seller pays 1bp). If we come up with a way to do 0 fee maker in the current auction, we can do that too, but this approach is ok for now. The fees can later be split with the validators. 

On-chain transaction fees: When a user submits an order, I think we need them to set a fee. The fee should be high in case there is a fee spike by the time the order actually fills. This should be fine because users are only paying for filled trades and not placing orders. The fee could be set as static to start with for the hackathon and made dynamic later.

Partial fills: These pose an interesting challenge. In the proposed implementation, when an order partially matches at auction, we execute the full payment amount. Settlement pays out based on the partial order fill. If in future auctions the order continues to fill, payments are made after the fills out to the relevant traders. It is currently impossible to cancel an order after it partially fills. Later, we need to implement a method to allow a user to cancel a partially filled order, but this probably charges an on-chain transaction fee.