You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: