DXS FAQ
English
LoginRegisterTrade
Search
⌃K
Links

How DXS Talks to the Blockchain

There are two ways that DXS ‘talks to the blockchain’. They are explained in this post with examples: opening a trade and closing a trade
There are two ways that DXS ‘talks to the blockchain’. They can be explained with examples: opening a trade and closing a trade.

Opening a trade

You’re logged into DXS with your Web3 Wallet (we’ll use HandCash in our examples). You’re feeling bearish on Gold:
You want to go short $30 of Gold at 30x leverage ($1 margin in BSV):
You open the trade. $1 of margin in BSV is sent from your HandCash wallet and the trade is opened instantly:

What happened when the user clicked ‘Send’?

  1. 1.
    DXS communicated with HandCash servers via the Connect API:
    1. 1.
      “This HandCash user would like to authorize a 0.02030457 BSV payment ($1 value as calculated by DXS at that moment). Here is the user session token that authorizes the request”
    2. 2.
      “Build a transaction for the user where the first output is 0.02030457 BSV and pays to the DXS margin hot wallet address”
    3. 3.
      “Include in the same transaction an OP_RETURN data payload that describes the trade”
    4. 4.
      “Ensure the transaction pays a sufficient miner fee so it is mined into a block”
    5. 5.
      “Broadcast the transaction to miners”
    6. 6.
      “Send us the raw transaction”
  2. 2.
    HandCash do the above and give DXS the raw transaction:
    1. 1.
      DXS check the 0.02030457 BSV output is correct
    2. 2.
      DXS check the OP_RETURN data payload is correct
    3. 3.
      DXS calculates the TXID from the raw transaction
  3. 3.
    DXS checks if the TXID exists in the mempool using Consigliere​

Why check the mempool when receiving a transaction?

DXS only cares about two things:
  1. 1.
    That the transaction makes it into the longest chain
  2. 2.
    That the user can immediately look up their TXID on an independent service (does not need to trust DXS)
Check opening transaction
We have a high-confidence proxy for these two outcomes: that the transaction exists in a miner’s mempool.
What can stop a transaction from being in a miner’s mempool?
  1. 1.
    Broadcast error
    1. 1.
      Unfortunately this is relatively common​
  2. 2.
    Miner chooses not to include the transaction
    1. 1.
      Fee is insufficient
    2. 2.
      UTXO is blacklisted
    3. 3.
      Any other arbitrary reason
  3. 3.
    Miner cannot include the transaction
    1. 1.
      Transaction is invalid (structure or signatures are not correct)
    2. 2.
      UTXO is already consumed (double spend)
Confirming the transaction is in a miner’s mempool means none of the above has occurred! However, we are still left with one business risk which stems from a fundamental understanding of the bitcoin network:
There are only ‘mempools’. Each node has its own view of the network and hence its own mempool. It is still possible for a double spend to occur… But:

Double spends are impossible on DXS

Both margin return transactions and profit return transactions spend the user’s margin commitment UTXO. If the user double spends their margin payment, both the margin return and the profit return transactions will fail.
“Holy shit DXS - you can do instant, bulletproof financial settlement at near zero cost?”
Yes we can. A key reason why we love the UTXO…

Closing a trade

You close your Gold position. Your trade is closed immediately:

What happened when the user clicked ‘Close’?

Margin is returned to the user’s Web3 Wallet instantly:
  1. 1.
    DXS communicates with HandCash servers via the Connect API:
    1. 1.
      “What address should be used for a payment to this user?”
  2. 2.
    HandCash responds with address
  3. 3.
    DXS communicates with Consigliere:
    1. 1.
      “Query the DXS margin hot wallet address for the margin commitment UTXO for this particular trade”
    2. 2.
      “Build a transaction that uses this UTXO as the input that pays the entire amount (0.02030457 BSV) minus 700 satoshis (DXS coverage for miner fees and change output) to an output addressed to the user”
    3. 3.
      “Include in the same transaction an OP_RETURN data payload that describes the trade”
    4. 4.
      “Ensure the transaction pays a sufficient miner fee so it is mined into a block”
    5. 5.
      “Ensure the transaction has a change output that will later be consumed in the profit return transaction”
    6. 6.
      “Add the transaction to the mempool of Consigliere’s connected BSV pruned node”
  4. 4.
    Consigliere does the above and returns the TXID to DXS
  5. 5.
    DXS sends the raw TX to HandCash
  6. 6.
    User can independently verify the transaction:
Check closing transaction
Profit is returned at the end of the 8 hour trading session:
  1. 1.
    DXS communicates with HandCash servers via the Connect API:
    1. 1.
      “What address should be used for a payment to this user?”
  2. 2.
    HandCash responds with address
  3. 3.
    DXS communicates with Consigliere:
    1. 1.
      “Query the DXS margin hot wallet address for the change UTXO from 1(e) above”
    2. 2.
      “Query the DXS margin hot wallet address for any UTXO that is both sufficient in size and not relating to a currently open or unsettled trade”
    3. 3.
      “Build a transaction that uses these UTXOs as the inputs that pay the entire profit amount to an output belonging to the user”
    4. 4.
      “Include in the same transaction an OP_RETURN data payload that describes the trade”
    5. 5.
      “Ensure the transaction pays a sufficient miner fee so it is mined into a block”
    6. 6.
      “Add the transaction to the mempool of Consigliere’s connected BSV pruned node”
  4. 4.
    Consigliere does the above and returns the TXID to DXS
  5. 5.
    DXS sends the raw TX to HandCash
  6. 6.
    User can independently verify the transaction:
Check profit transaction
TECHNICAL EXPLAINERS - Previous
Consigliere Solves All Our Problems
Next - TECHNICAL EXPLAINERS
HandCash / Tokenized Consideration
Last modified 7mo ago