Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order Book Design #86

Open
fredo opened this issue Jan 31, 2019 · 1 comment
Open

Order Book Design #86

fredo opened this issue Jan 31, 2019 · 1 comment

Comments

@fredo
Copy link
Contributor

fredo commented Jan 31, 2019

In this issue I discuss the overall design for an order book and how orders are matched. We assume an exchange with a Commitment Service Involved. The other parties are called Maker and Taker

1) Decentralized Order Book

1.1 - Taker contacts Maker

In the first option a maker will match the offer. Every taker who wants to accept an offer will contact the maker to show its willingness to accept the deal. The maker matches then the request of the taker and initiates the exchange by contacting the CS. It is possible that the maker gets contacted by multiple potential takers and he is the one to choose.

Disadvantage: The maker can delay the taker's willingness to accept the deal and therefore giving him some kind of free option (although in a very early state). Since the maker can delay or the acceptance it distorts the order books of every other participant since one can never know if a certain offer will be accepted or not. Creating fake statistics.

1.2 - Taker contacts the CS

In the second option the taker contacts the CS about his willingness to accept an offer. The CS could be bound to the offer and proposed by the maker or chosen by the taker (does not change anything). The CS could also receive multiple requests to take the offer and it would decide which one to take. CS is matchmaking instance and then contact matched maker and taker.

Advantage to option 1: The CS acts as a trusted watchtower to invalidate "fake" offers if the maker tries to delay or not accept the proposed match. The order books of the other participants would be cleaned out of fake offers.

Disadvantage: The CS is gaining more power in respect to matching and taking offers. Potential risks are censoring participants by invalidating their offers and not accepting participants as takers (probably unlikely). It has also the ability to front run (I assume more likely)

1.3 - CS matches by listening to the order book

The third option is quite similiar to option 2. The CS is also creating its own local order book and proposes matches and then contact both participants.

Advantages/Disadvantages: Same as option 2

2) Centralized Order Book

2.1 - Taker asks for offer acceptance

This Option is basically Option 1.3. The CS would provide a central point of submitting offers. It would the process the Offers, provide an Order Book and matches by itself.

@fredo
Copy link
Contributor Author

fredo commented Jan 31, 2019

@stefante What are your opinions?

@fredo fredo added this to the Design Proposals milestone Feb 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant