Creating a decentralized trustless exchange to minimize exchange loss and fraud in bitcoin 2.0 and related technologies.

Creating a true trustless Decentralized Exchange (DEX) utilizing (Delegated)POS which maintains a high degree of anonymity while minimizing counter-party risk.

Currently crypto-currencies are predominantly traded through a centralized exchange which carries a substantial risk of being hacked resulting in a loss of funds. This puts a huge burden on the profitability of trades, knowing that funds are subject to random and uninsured losses. These repeated losses by centralized exchanges provide the largest source of negative press towards crypto-currencies. This damages adoption of cryptos as a whole and the problem does not seem to be improving in the near future. The list of exchanges who have lost customer funds is too long to list.

While there are multiple blockchains that support internal markets these markets are quite limited to assets native to the blockchain or market. Examples of these are BitTokens and NXT. Other examples are markets built upon Bitcoin, like Omni or Counterparty.  As of this being written, there is no known market enabling cross-chain trading that is decentralized.

Since the complexity of cryptos always allows plausible deniability, it seems likely large thefts will continue to occur in centralized exchanges. Our goal is to completely avoid all thefts or hacks by developing a true decentralized solution to the exchange problem that enforces a trustless cross-chain market while greatly lowering counter-party risk. It does this by using blockchain and game-theory based escrow.

There are many approaches to this problem, but most involve atomic cross-chain support or require multi-sig support from every token/coin traded within the market. Our solution involves an independent blockchain which we will refer to as DEXTokens or DEXT. With this system all traded funds that are not paired with DEXT will require escrow in the form of DEXTokens but only for the duration of the trade. The escrow can be provided by one or both parties involved in the trade. A DPOS based wallet will serve as a central order book to kick off manual trades and verify that the trade went through as agreed. When one trader acts in a way to cause loss to the other party, part of their escrow is transferred to the damaged party by the DEXT blockchain. All trades are done manually from wallets (at least initially, although automated trading would become quickly available for those wishing to set it up). The destination addresses are stored on the blockchain and presented to the traders via the GUI of the wallet. In this way the wallet software will walk a person through the trading. The individual transactions are as large as possible, constrained only by the level of escrow provided by the traders.

Delegated POS is an ideal consensus algorithm which can provide a ‘federated server’ type approach. DPOS’s concept of managed decentralization allows a limited deployment of block-signers. Since every block-signer is paid equally, it can be expected of each Delegate to maintain the same level of professionalism while having the market fees readily cover the cost of the server.  Any POS system that pays block-signing (mining) fees according to stake and not useful work will not be as viable.  It will be necessary for any Delegate to have the technical ability to run and maintain multiple wallets.  The number of Delegates will need to strike a balance between security concerns and pay rate.

Areas of significant concern.

There are a few areas of concern that might hinder adoption. Are people willing to go through multiple transfers to fulfill their buy/sell orders?  The time commitment to make trades will be significantly higher and can involve multiple steps given the escrow level.

The other concern is forcing people to put up escrow. This creates friction towards adoption. However the crypto world is comfortable with the idea of escrow, but the friction caused still remains to be seen. This could possibly be mitigated by using a market pegged asset to lower volatility so that users may feel less concerned keeping equity in DEXTokens. So fees could possibly be denominated  dollars. Secondly, once liquidity providers appear with automation while putting up 100%+ escrow, then the market's user experience will behave like a centralized market but with delays for the various levels of required confirmations.

Some people seem to use centralized exchanges specifically as a long-term storage. While this is recommended against by just about everyone, it still seems to be a feature that users use. They are willing to exchange maintaining their own secure wallet with faith the chosen centralized exchange will not have issues. The value of the service is in the convenience of having a ready to use wallet that is maintained by someone else. This solution forces people to hold their own coins.

There will be a mismatch between the liquidity of the internal market (DEXT) and those of the counter currency being traded . A large failed transaction could result in a trader wanting to quickly liquidate his position into a thin DEXT market which could result into extra losses. So if a large trade failed, one side would be given DEXT which they would then need to liquidate. Given that they were looking to trade in a different currency initially, it seems to reasonable to expect them to want to be able to liquidate their DEXT into the trade they had previously desired.

Example Protocol Walk-Thru involving one side of trade.

The internal market that is accessed through the DEXTokens wallet (or possibly a website) finds a match between 2 orders from 2 traders. We call these 2 traders John and Jenny. John has 100 LTC and Jenny has 1 BTC which the market has matched as a valid trade. Jenny has the equivalent of .6 BTC in DEXT (escrow) while John has .3 BTC worth of DEXTokens available as escrow. Both John and Jenny have previously given their receive address for the coin they are receiving. This is done in the wallet and will be a transaction on the DEXT' blockchain.

The person with the least escrow available will start the process.

Jenny has deposited .6 BTC worth of escrow in DEXT and John is prompted by the exchange (the wallet itself) to send .6 BTC worth of his 100 LTC. In this case .6/1 * 100 or 60 LTC to the receiving address of Jenny.

Once the Delegates come to consensus that the LTC transaction has completed and the 60 LTC has arrived for Jenny, Jenny now pays .9 BTC to John. The process then repeats itself for the remaining untransferred funds.

To simplify and help the reader understand, here is a simple straightforward list of steps from user John’s perspective.

1. Fund account with DEXT tokens, ideally 50%+ of largest order minimum, 100%+ preferred.
2. Match up in LTC/BTC market. ** See note below
3. DEXTokens are locked up in escrow and John is prompted to send LTC.
4. John sends 60 LTC to Jenny’s previously specified public address.
5. After the consensus is achieved that John received his transfer (.9 BTC, .6 + .3), he is prompted to send the remaining 40 LTC to Jenny.
6. Once the blockchain confirms the 40 LTC and the final .1 BTC from Jenny has been sent, all the escrow is freed for the next trade.

From Jenny’s standpoint there is little difference except acting in response to John and the transfers themselves.

The number of steps involved is directly dependent on the level of collateral. In this way a person who values a smoother experience can always have their account capitalized. If a person has their trade fully collateralized then it only requires that each trader make 1 transaction.

So a trade could be fully collateralized by one side but a bond will be required to be posted by the other side for punitive requirements. During the process, each trader has a chance to not send their funds if the price has moved against the order match price. Without punitive fees, a person could use the protocol to sell their DEXTokens by simply refusing to pay and defaulting on collateral. Collateral has to go beyond the amount being transferred to ensure this type of use would result in a net loss for the trader that failed to pay and the other side would be made whole. These punitive fees need to be determined by studying the market and ideally should be made dynamic to adjust with volatility. This needs to be studied further in depth.

** There needs to be a way to detect and or remove trades when a person is away from their computer. This could be done by a person specifying Away From Keyboard (AFK) or have both parties acknowledge their presence as part of a handshake. If one times out then the trade is cancelled and attempts to be filled by other orders which would hopefully be readily available. This step was left out in the above example.

Selling Points

• Users keep their private keys at all times and control of their funds until an order has matched and proceeded to the trading state.
• From the standpoint of a profitable DAE (Digital Autonomous Entity), the need for escrow should directly drive equity into the blockchain.
• Delegate pay-rates can be capped leaving remaining profits to go to the owner of tokens.
• The project could evolve into using Atomic Transactions after initial stage. The initial stage has a minimal set of functionality required for supported blockchains to enable wide support. There could possibly be an addition of multi-sig support when found to be mature if it makes sense and would help the user experience. If done properly, this project can evolve with the technology to become the dominant altcoin exchange.
• DEXT itself would have a lot of first mover advantage and should be able to maintain a competitive set of features if funding with the goal of long term stewardship is kept in mind from the beginning.
• Once DEXTokens have been purchased, orders can be made instantly without waiting for deposits like seen on a centralized service. So while the trade transaction themselves take more time, the actual placing of orders could be faster if DEXT has already been purchased. This is because orders can be placed without the depositing of a specific coin.
• Even without AT implemented, liquidity providers who fully collateralize their account for multiple trades will enable simplified trading where user experience resembles that of a centralized exchange.
• Market sorting needs to be implemented so people can match up with automated order fulfillment. When this happens, DEXT can be seen more like a Ripple network with gateways but having the added benefit of the gateways not working in IOUs outside of the blockchain.
• If a blockchain has strong anonymity that fogs the base functionality required for passive blockchain verification, the anonymous currency can still be traded by a derivative/market pegged asset with on-ramps or external gateways. So instead of DASH the market would trade in IOUS. This would however add counter-party risk.
• Can trade assets from other exchanges !  Any public blockchain can work, it just needs enough volume to justify the resource expenditure.
• DPOS can be readily leveraged.
• Delegates become a set of ‘federated servers’ relying on consensus to enforce escrow/collateral on orders.
• System of voting allows owners of DEXT to control fate of the DAC.
• The codebase of BitShares has fairly advanced functionality.  The basic orderbook functionality already exists as does the underlying transaction support.
• Delegates already have the ability to publish their information to help transparency in real life. See BitShares for an example.
• Demand for a secure trustless DEX is very high and will remain so.
• This system will work with currencies that may be anti-integration. This should allow the trading of XRP IOUs. (to be investigated.)
• Any trade paired with DEXT will not need escrow, as the DEXT is within the control of the blockchain. It may need a bond however for the side trading in an external coin. Also if the market attracts liquidity providers, the need for escrow could be removed as one side of the trade could be fully collateralized.

Problems to solve (all of which seem solvable)

• What is the amount of open sell orders allowed given X amount of DEX Tokens? The escrow itself is only needed during the actual sales. This has to also prevent flooding the orderbook. There may also be issues with price manipulation by setting fake orders that are not backed by anything.
• Listing fee?  - Easier to implement.  Can be refunded on successful trade.
• Most options in this area are basically a listing fee that can be partially refunded.  Locking up escrow before trade is match is the equivalent of a refundable listing fee.
• How are punitive fees (bonds) and minimal escrow levels calculated ? Rules must utilize game-theory to prevent economic exploits. Without overcollateralization this will always be a non-zero risk due to market movements allowing a person to suddenly back out of an already agreed to transaction when it benefits themselves.
• Can the DAC reference internal market to measure losses due to non-payment?  
• Won’t volatility be too high from a internal thin market ?  Could the internal market be manipulated ?  Yes.
• This requires that price feeds are used to keep people honest.
• If multi-sig solutions or AT are implemented, these requirements can be eased or removed.

• DPOS has a problem where sybil attacking could harm the network in a completely irreversible way.  Since the purpose of this DAC/DEX is to be a middleman over external chains, mistakes/hacks/bugs may be such that even a worst case rollback can not resolve. Although this would be mitigated by the typical human involvement when initiating payment. In general, having unique Delegates is crucial.  
• Solutions
• Anonymous delegates will be frowned upon, thereby forcing social and legal pressures to enforce honesty.
• Delegates could come from a network of trust.
• A stronger majority could be required if currently only 51% agree.
• The consensus algorithm might need to be tweaked given how third-party blockchain transactions can appear at different times on different Delegates.
• Consensus on the transactions.  Delegates will have multiple things to deal with and downtime is to be expected. Delegates will have problems with wallets. How does the consensus algorithm/chain work around this?   At what threshold are markets shutdown due to security concerns.
• Could someone parse the DEXTokens blockchain in real time for receive addresses, then when a different party creates a transfer, claim it by transaction? (Yes)
• Hack solution of encoding more ID data into least significant digits.  Using this we could actually get around using transaction ids. This is not exactly idiot proof + problems with transaction fees scrambling these digits makes this a difficult solution. ← Does this even work?
• We could lock an address and enforce serial transactions and allow multiple receive addresses. Therefore you can not have 2 orders ever using 1 receive address. Once the trade is finalized the receive address could be reused. ← Current solution.

Things to consider

• People can build up histories of payment. Both payments and non-payments, but also average time to act. Payments can not be valued more than the amount it would cost to fake them. These metrics could be used to possibly sort the order fulfillment precedence.
• A simple bit of glue code could be made so that a hot-wallet could work with the DEX wallet. So if bitcoin core was to run it could be used to automate the BTC side of any BTC pairings utilizing a command line wallet api (or possibly RPC).
• Delegates and/or developers could be paid by coin communities in the form of bounties to support their coin. The fees could also potentially be burned thereby giving profit to everyone in proportion to their tokens.
• Orders can have a small window of time to initiate the process. This way the initiator of the order (the one who crossed the gap) can back out instead of waiting hours for a time-out. This would avoid a lot of bad experiences where the other party might be AFK.
• A basic alert system needs to be created so that if an exploit is found people can be made aware to not complete trades. It is an unfortunate artifact of the complexity of this type of code, but it would seem prudent. Whether a kill switch or an alert, something would need to be created.
• It is known that the voting system in DPOS can have security issues with large stakes allowing network attacks.  This is hard to mitigate against without either a benevolent majority shareholder or active community. It is also possible to modify DPOS by removing the voting for Delegates and having Delegate selection hard-coded / determined elsewhere.

Why an independent DPOS chain? Why not implement on top of BTS? How about using a different third party app ?

While this solution involves a forked codebase from DPOS (BitShares) blockchain, the concept still remains applicable to any blockchain.  This system could be implemented on the BitShares chain or perhaps a whole different consensus algorithm.

It might be possible to implement this on a native BitShares blockchain, but consensus could not require 50%+ of 101 nodes  (> 50%) to run all the coin nodes. A concession might be that having 10 of 101 Delegates recorded as verifying another currency would result in a currency going live in other markets. However, these Delegates would need to be paid differently from those not supporting the market. Therefore a different block reward model would need to be created would require a complete rewrite of the code that moves around related funds. In addition it would be hard to fund the process of integration as the complexity would grow while impeding the direction of BTS. The consensus model would need a careful review. A separate blockchain (for example DEXT) has crowdfunding options and is far more nimble in general. It is true that implementing on the BitShares chain would help with the liquidity issue for escrow. An upstarting blockchain would be hard pressed to maintain liquidity levels equivalent to an established chain such as BTS.

Other consensus algorithms could undoubtedly made to work. C++ along with the numerous libraries do not make for an easy to environment to develop under, yet the HTML based interface gives even more flexibility to leverage for a centralized web-interface to a backend blockchain. The BitShares team led by Dan Larimer has put a lot of effort into making a secure consensus platform with a very low cost.  That low cost hinges on having a finite and relatively small level of Delegates.

There has been discussion of future directions of BTS which could enable the type of functionality using Turing Complete scripting and agents that run the scripts independently of the delegates. This would require a different architecture and recreation of functionality already provided by a BitShares fork. It could however leverage the liquidity of BTS which could be key in adoption. In the same way, perhaps it would be possible to run this on Ethereum or on top of Bitcoin. These other approaches would require a different consensus algorithm to be designed and are out of the scope of this paper.

Conclusion

This is a very viable project but the question still remains of user adoption.  Could it support the DAC?  The main goal here is to help Bitcoin 2.0 projects as BTC has many well regulated exchanges. By providing liquidity and helping reduce the amount of fraud and theft in the trading of all crypto-equities this service could be just what is needed.

There are many questions yet to be answered and feedback is welcome. Could a drawn out trading that requires multiple steps prevent adoption? The only certainty is this is as good of a time as any to launch such a project.

Once the DEX receives liquidity providers/market makers then it will be functionality equivalent to a service like Shapeshift.io. Shapeshift.io minimizes the amount of time one has to take on counter-party risk. This is a step in the right direction as a large amount of loss can not occur at one time. The idea presented in this paper will take security one step further.

This is my blog where I will publish thoughts/essays.  Blogspot is simple and free so let the games begin!