psf/bch-dex
1
0
Fork 0
mirror of https://github.com/Permissionless-Software-Foundation/bch-dex.git synced 2026-09-21 16:52:00 -07:00
Code Issues Packages Projects Releases Wiki Activity

Editing dev docs

Browse Source
This commit is contained in:
Chris Troutner
2022-03-11 12:47:57 -08:00
parent a904cbb473
commit 4fe89a1190
1 changed files with 17 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dev-docs/README.md
+17 -1
View File
@@ -17,10 +17,26 @@ There are three major pieces of software behind the bch-dex concept. They work t
The arrows in the image represent the information flow between the three pieces of software:
- The _Client_ is essentially a 'dummy terminal' with a bidirectional interface to bch-dex. bch-dex does the heavy lifting, and the _Client_ is a 'thin' UI wrapper.
- `bch-dex` imports data from the global P2WDB database into its local database, using a [webhook](https://en.wikipedia.org/wiki/Webhook) (dashed line). It can also custody funds, pay transaction fees, and create an _Order_ by submitting the data to the P2WDB to generate an _Offer_ (solid line).
- `bch-dex` imports data from the global P2WDB database into its local database, using a [webhook](https://en.wikipedia.org/wiki/Webhook) (dashed line). It can also custody funds, pay transaction fees, and create an _Offer_ by creating an _Order_ and submitting the data to the P2WDB (solid line).
This architecture keeps the global database highly censorship resistant, while allowing local installations to maintain tight control over the user experience. The goal is to have many redundant copies of `bch-dex` on the network, and to empower individual traders to run their own, private copy, while maintaining a single source of truth via the P2WDB.
# Definitions
The workflow of a token trade has three parts:
- **Make** - An *Offer* to buy or sell tokens is generated by a user, known as the *Maker*.
- **Take** - A second user, known as a *Taker*, will *take* the *Offer* by issues a *Counter Offer*
- **Accept** - The original *Maker* checks the *Counter Offer* and *Accepts* it by signing and then broadcasting the transaction.
Trade done in this way are both *trustless* and *atomic*:
- **Trustless** - This means that neither party needs to trust the other. The Maker gets to review the Counter Offer before broadcasting it. The Maker can not alter the Counter Offer after the Taker has signed it.
- **Atomic** - The trade happens in a single transaction. There is no middle-state where the trade can get stuck. It either happens or doesn't, it's state is binary and atomic.
Specific *Entities* are defined in the [specification](./specification.md), but here is a brief summary:
- **Order** represents the Maker side of the trade. This entity is tracked internal to `bch-dex` and is used to track tokens set aside for sale.
- **Offer** contains most of the same information as an **Order**, but is external to `bch-dex`. This is data submitted to the P2WDB and visible to all users on the network.
- **Counter Offer** is generated by a *Taker*, in order to take the other side of the trade. It contains a partially-signed transaction, ready for review by the *Maker*.
# Back End
This section provides additional information on `bch-dex` and P2WDB back end software.