6.6 KiB
bch-dex Specification
This document contains a high-level, human-readable specification for the four major architectural areas of the bch-dex:
- Entities
- Use Cases
- Controllers (inputs)
- Adapters (outputs)
This reflects the Clean Architecture design pattern.
Entities
Entities make up the core business concepts. If these entities change, they fundamentally change the entire app.
Order
An Order Entity is nearly the same as an Offer. The Order is generated first, but is always internal to the bch-dex system. Most of the data in an Order is submitted to the P2WDB, which generates an Offer (external) Entity.
The Order tracks the HD index address used to hold tokens or BCH for sale. This is the part of the app concerned with the custody of the funds. It creates a segregated UTXO to hold the offered asset. The Order is automatically destroyed if the UTXO is spent.
Order entities have the following properties:
- Token Data:
-
tokenId - The unique ID that identifies the class of token being offered for sale.
-
utxoTxid - The TXID of the UTXO representing the token or BCH being offered for sale.
-
utxoVout - The vout of the UTXO representing the token or BCH being offered for sale.
-
Trade Data:
- buyOrSell - A string with a value
buyorsellindicating which type of offer this is. - numTokens - The maximum number of tokens offered for sale.
- rateInBaseUnit - The rate in terms of currency-unit-per-token. Ex: 1000 = 1000 sats per token
- For Bitcoin, the min currency is sats.
- For AVAX, the min currency is nano-Avax.
- for eCash, the min currency is bits.
- minUnitsToExchange - The minimum order size accepted.
- buyOrSell - A string with a value
-
Authentication Data:
- signature - A message signed by the address which created the order.
- sigMsg - The clear-text message used to generate the signature.
- offerBchAddr - The BCH address controlling the offer.
- offerPubKey - The public key used to generate the BCH address, used for encryption.
-
Wallet Data:
- hdIndex - The HD index of the wallet used to generate the keypair to store the UTXO being offered for sale.
-
SWaP Protocol properties:
- lokadId - Not used. Provided for future functionality.
- messageType - Not used. Provided for future functionality.
- messageClass - Not used. Provided for future functionality.
-
Offer
An offer is created from data passed to the app by the P2WDB webhook. It is destroyed when the UTXO described in the Signal has been detected as spent.
Offer entities have the following properties:
-
Token Data:
- tokenId - The unique ID that identifies the class of token being offered for sale.
- utxoTxid - The TXID of the UTXO representing the token or BCH being offered for sale.
- utxoVout - The vout of the UTXO representing the token or BCH being offered for sale.
-
Trade Data:
- buyOrSell - A string with a value
buyorsellindicating which type of offer this is. - numTokens - The maximum number of tokens offered for sale.
- rateInBaseUnit - The rate in terms of currency-unit-per-token. Ex: 1000 = 1000 sats per token
- For Bitcoin, the min currency is sats.
- For AVAX, the min currency is nano-Avax.
- for eCash, the min currency is bits.
- minUnitsToExchange - The minimum order size accepted.
- p2wdbTxid - The TXID proof-of-burn used to add the order to the P2WDB.
- p2wdbHash - The CID used to identify the order entry in the P2WDB.
- buyOrSell - A string with a value
-
Authentication Data:
- signature - A message signed by the address which created the order.
- sigMsg - The clear-text message used to generate the signature.
- offerBchAddr - The BCH address controlling the offer.
- offerPubKey - The public key used to generate the BCH address, used for encryption.
-
Utility Data:
- timestamp - The ISO time when the order was created.
- localTimestamp - The localized time when the order was created.
-
SWaP Protocol properties:
- lokadId - Not used. Provided for future functionality.
- messageType - Not used. Provided for future functionality.
- messageClass - Not used. Provided for future functionality.
Counter Offer
A Counter Offer is the other side of an Offer. It contains a partially signed transaction, created by the Taker. The Maker will review the Counter Offer before accepting and finalizing the trade.
Details TBD.
Use Cases
Use cases are verbs or actions that is done to an Entity or between Entities.
Offer
createOffer()- This method is triggered by a webhook from the P2WDB. It will take the data provided by the P2WDB and create a new Order entity in the local database.
Order
ensureFunds()- Ensure that the wallet has enough BCH and tokens to complete the requested trade.moveTokens()- Move the tokens indicated in the order to a temporary holding address. This will generate the UTXO used in the webhook message. This function moves the funds and returns the UTXO information.createOrder()- A macro command that leveragesensureFunds()andmoveTokens(), to create a new Order and submit it to the P2WDB.
Counter Offer
TBD
Controllers
Controllers are inputs to the system. When a controller is activated, it causes the system to react in some way.
Offers
- POST /offer - This POST REST API endpoint will be triggered by a webhook generated from P2WDB. This will notify the
bch-dexthat a new entry has been added to the P2WDB that matches theappIdofswap-<chain>, where<chain>has a value ofavax,bch, orecash. It's a new entry that should be evaluated for inclusion in theipfs-swap-servicelocal database.
Orders
- POST /order - This POST REST API endpoint can be triggered by the Client or a simple curl call. It passes in the data needed for
bch-dexto generate and track a new Order, then submit the data to the P2WDB to generate an Offer that is tracked by all other instances ofbch-dex.
Adapters
Adapters are output libraries so that the business logic doesn't need to know any specific information about the I/O. They are essentially the output of the application.
- localdb - An adapter for the local database (MongoDB).
- ipfs - An adapter for IPFS and the ipfs-coord library. It allows the app to use the JSON-RPC over IPFS.