# Potential On-chain Order Book Exchange on Miden

This document serves as a design document for a potential PoC of an on-chain order book exchange on Polygon Miden.

## What is an order book exchange?
Order book refers to an electronic list of buy and sell orders for a specific security or financial instrument organized by price level. There are three parts to an order book: buy orders, sell orders, and order history. An order book is dynamic and constantly updated in real-time throughout the day. A key feature of order book models is allowing users to submit two types of orders: a market order or a limit order. Market orders mean a trader instantly buys or sells at the best price (highest bid, lowest ask). Limit orders are not instant and buy or sell at a specific price. There also must be an order matching system following some rules of best execution.

## Why is an Order Book Exchange important?
In crypto markets, the dominant venue for exchange has been centralized order book-based exchanges (CEX). There is high demand for on-chain order-book exchanges; see [here](https://twitter.com/EliBenSasson/status/1614575237122629633?s=20) 40 TPS only on dYdX. On-chain exchanges are mostly AMM-based exchanges that cannot replicate the features of an order-book exchange: Order-book exchanges …
… provide price efficiency (price defined by makers)
… reduce the risk of slippage; no impermanent loss
… are widely accepted by both institutional and retail traders alike
… are simply easier to use
… no trusted intermediary (who could tamper with user funds)

## Which features are needed for an on-chain order book exchange?
To run an on-chain order book several features are needed {PLEASE ADD}

Needed:
1. High TPS - builders ask for 30-40 and some even more
2. Low finality - sub second finality would be optimal
3. Quick and cheap order updates - Order updates should be almost instantaneously and for free especially for Market Makers

Nice to have:

4. Privacy at the base layer - to not reveal trading strategy
5. Matching engine - FIFO/Pro-Rata should also run on-chain to ensure best execution
6. MEV protection - to ensure best execution

(Are there more required features? Do we need to cancel order quickly?)

## Why is this hard to build on Ethereum?
Order-book exchanges on account-based blockchains are hard to implement. The algorithms of matching engines, commonly implemented in centralized exchanges (CEXs) based on the CLOB model, consume a large number of resources making it difficult to deploy and run on the Ethereum blockchain, see [here](https://www.gdx.org/gridex-whitepaper.pdf). Some DEXs have attempted to solve this issue by implementing matching engines and order books off-chain - dYdX (on StarkEX) or 0x. However, such solutions increase the risk of centralization (to a certain extent) and limit their ability to interact with other protocols, making it impossible to utilize or contribute to the open ecosystem of Ethereum effectively.

## Why this can be done on Miden
Polygon Miden offers the required features (1-5) while at the same time, computational integrity is secured by Ethereum and it will be easy to bridge liquidity from it.

Polygon Miden is designed to have high TPS in a sustainable way. Orders can be updated for free and in no-time using updateable transactions. Polygon Miden offers different levels of privacy at the base layer. Matching engines can run off-off-chain but there can be a zk-proof of correct execution to be verified by the network.

For finality, we need to define what we mean by that.

# Design ideas for a simple PoC
Let's collect ideas how we can implement a private on-chain order book exchange on Miden. So given the [Miden Architecture](https://0xpolygonmiden.github.io/miden-base/architecture.html) we can design a simple onchain order book exchange.

In our simple example,
- market makers / users shall be able to place orders
- market makers / users shall be able to update orders fast and cheap
- anyone shall be able to take an order
- there shall be some form of best execution
- the order book itself shall be visible on any web2 interface like a homepage.

## Notes represent orders
In Miden there are Accounts and Notes, see [here](https://polygon.technology/blog/polygon-miden-transaction-model-2). Notes can be updated for free and in no-time, therefore Notes can represent an order.


All Notes with the same `Tag` can be listed in the same order book. Notes carry the asset to sell in their `Vault` - this cannot be updated and in this example it is 1 ETH. In addition, Notes have a single executable `Script`. This script is the a root of a [Miden program MAST](https://0xpolygonmiden.github.io/miden-vm/user_docs/assembly/main.html). Here is where we encode our order.


Now the user first reveals what A is. Then, what B is and so on and so forth.

A = {receive 1 ETH && send 2000 DAI to sender}

If no-one takes that order, the user reveals another part of the script

B = {receive 1 ETH && send 1990 DAI to sender}

Whoever wants to take this order needs to consume the above note and in doing so execute the script.

## All notes with the same tag are listed in the order book
The order book could now be simply a list of all notes with the same `Tag`.


This will serve as our order book - which can be shown in a simple web2 interface / homepage. Now any user can take any order by simply consuming the respective note in a transaction - first come, first serve.

Notes in that order book must be public. That means everyone sees all the note's data and can compute the nullifier. That means whenever there is a nullifier in the Nullifier DB, the operator of the order book interface can delete the respective note.

So now, market makers and users can already place orders by creating new notes. Those order can be updated by simply revealing new parts of the script. Those updates don't need to happen on-chain, but e.g. in any public forum or directly to the operator, and are therefore for free and can happen in no-time. And anybody can take orders by simply consuming the respective notes.

## In theory we don't need a matching engine
Mathing engines make sense in the centralized setting. In our simple case every user can decide which order he / she wants to take.

But we could implement any matching engine in a smart contract. In Miden every smart contract is an [Account](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html). So trades could be executed by executing functions of the matching engines account. And the order notes would then be defined as such that only this account can consume them.


## Privacy
To be defined which level of privacy needed. In theory full privacy is possible.

## MEV prevention or MEV extraction
To be defined