decred.org/dcrdex@v1.0.5/tatanka/spec/meshdex.md (about) 1 # DEX on Tatanka Mesh 2 3 Implementing a peer-to-peer decentralized exchange on Tatanka Mesh will require 4 substantial re-thinking of many existing DCRDEX protocol features. The primary 5 difference between DCRDEX and DEX on Tatanka Mesh is that Tatanka Mesh clients 6 take over the roll of maintaining order books. 7 8 ### Protocol Basics 9 10 1) There are no pre-defined markets. A market is simply a broadcast channel, 11 which is a topic-subject pair, e.g. topic = "market", subject = "dcr_btc". Any 12 user can create a new market by simply subscribing to a non-existent channel. 13 This means we need to eliminate most market configuration. 14 - Lot size will not be a constant. Instead, it will be chosen by the user 15 based on their preferences for limiting fee exposure. For example, the user 16 may set their fee exposure limit to 1%. This will hide any order (in their 17 local view of the order book) which have a lot size that might result in fee 18 losses > 1%. Only orders with compatible lot sizes can match. To ensure 19 orders fill completely, I propose that lot sizes must be a power of 2, 20 though other schemes are possibly conceivable. 21 - Max fee rates are similarly set by the user as part of the order, and 22 orders whose max fee rate falls below the fee rates provided by the mesh 23 oracle feed will be ignored or unbooked. 24 - If the mesh provides a fiat exchange rate feed, we can define the rate 25 step and parcel size as a exchange-wide constant in terms of USD, and these 26 values will be dynamically re-calculated for each market as rates change. 27 - We could potentially do away with epoch-based matching, but we may want to 28 keep it around, albeit in a different form. Our goal should be that clients 29 are reacting appropriately by creating matches for valid offers. Clients 30 can't just ignore offers based on their own arbitrary criteria. Ideally 31 they would accept the first offers that are sent to them, though this would 32 be very hard to enforce. 33 - I've considered doing away with order funding validation. The only purpose 34 of funding validation is to prevent empty wallets from spamming the market 35 with orders they have no intention to fulfill. This would of course result 36 in an account suspension, so such spamming cannot go on indefinitely. The 37 bonding system also requires users to lock up funds before using the 38 network, so there is still a barrier to such malicious behavior, though this 39 is not as strong a filter as funding validation would provide. It's 40 important to remember that the global worst-case scenario for 41 atomic-swap-based exchange is a refund and fees, not lost funds, so a 42 malicious actor's only incentive to spam would be to grief the network. On 43 the other hand, the server could still provide funding validation services 44 without participating in the market. Either way, we're going to do away with 45 the necessity of split funding transactions. More on this later. 46 47 48 1) Markets are user-policed. Successes and counterparty failures are 49 self-reported. 50 51 1) Match proposals could be either public or private. Public match proposals 52 could be monitored by all market participants to potentially root out bad 53 actors, but private match proposals have obvious benefits as well. Either way 54 matches are self-reported as public broadcasts, so that clients can maintain 55 their order books. 56 57 1) Swap communications take place in encrypted tankagrams. Unless a swap failure 58 occurs which requires an audit, the server never knows any swap details. 59 60 1) Orders will have an expiration time that can be only so far in the future. 61 Clients can extend their expiration time as needed, but still only within a 62 relatively short window into the future. Expired orders are pruned.