Skip to content

Trade Negotiation Protocol

Jump to bottom
Hart Lambur edited this page Aug 27, 2018 · 8 revisions

Abstract

The following spec outlines the requirements for the trade negotiation protocol that allows two counterparties (a taker and maker) to trustlessly negotiate and enter into a contract.

Motivation

Assume you have one market participant T (the taker) who wants to enter into a given trade at the best possible price. To do this, the taker queries n market makers m1 , m2 ... m_n with the details of their trade. Market makers respond with quotes q1, q2 ... q_n. All market makers agree to honor their quotes for a given wire time w. The taker then selects the market maker with the best price/terms, and responds confirming the trade. As long as that response is sent before the maker’s wire time expires, the trade is confirmed and the contract is finalized.

Base Requirements:

  • The taker must be able to prove they have the necessary capital (margin) to enter the trade.
  • The maker must also be able to prove they have the necessary capital (margin) to enter the trade.
  • Their must be surety that both counterparties will fund the trade and transfer their initial margin if the trade is "done".
  • The system should have some friction for takers to request a quote. (Said differently, the system should be resistant to takers DDoS’ing makers).
  • The system needs to be “trustless” and permissionless, although there are no hard constraints about which parts need to be on-chain vs off-chain.
  • Their must be surety that both counterparties will fund the trade and transfer their initial margin if the trade is "done".

Wire Time Requirements:

The wire time constraints described above make this a substantially more complicated problem. For the very early days of the project we can ignored this wire time requirement to simplify our design—but solving this problem will be necessary for the system to be useable at scale.

  • Assume the underlying blockchain confirms transactions in approx 1-2 minutes (aka roughly the speed of Ethereum today).
  • Assume a wire time on the order of 3-10 seconds (effectively enough time for a human to consider and decide on a given price before confirming the trade).
  • The system should require market makers to honor their quote if a taker responds within the wire time. Failure to do so should be costly for market makers (aka they are penalized).

Undecided design questions:

  • Is there a penalty for a taker not trading? (Do we need such a penalty to exist to prevent a taker from being a spiv and looking to pick off makers)?

"Optional" or "Nice to Have" Features:

  • AML/KYC for counterparts. Check out Wrye.

Specification

Potential Solution to the Wire Time Problem:

Assume we have a taker T that requests prices from market makers A, B and C. In addition to providing prices, A, B and C also publicly publish a timestamp feed and will sign transactions with their timestamp, like we previously discussed. Based on this setup, if T wants to trade with A, he can send A his “DONE” confirmation before the wire time and send the same transaction to B and C to have them sign it with their time stamps. This correctly “orders” the transactions and can prove that T sent the “DONE” confirmation before the wire time expires.

Problem: what happens if T doesn’t actually send the confirmation to A? What if he only sends it to B and C (and possibly colludes with B and C to steal money from A). Or perhaps even more simply: what if T does send the transaction but A doesn’t actually receive it (aka there’s a dropped packet TCP/IP packet or something)? In some ways this is a variant of the double-spend problem, and intuitively it feels like it can only truly be solved with another blockchain like construction or with some point of centralization. See Will Warren's ideas on Trade Execution Coordinators for ideas on how to get around this.

Resources

Clone this wiki locally