<p></p>
<blockquote>
<p><em>This is a Bisq Network proposal. Please familiarize yourself with the <a href="https://bisq.wiki/Proposals" rel="nofollow">submission and review process</a>.</em></p>
</blockquote>
<h2>Overview</h2>
<p>The suggested new architecture supports multiple trade protocols and security mechanisms as well as multiple blockchains.<br>
The separation of the security mechanism and the asset transfer provides a lot of flexibility to adjust to users needs and preferences.</p>
<p>The problem of market fragmentation can be mitigated by supporting multiple protocol and security options and allow the taker to contact the maker for negotiation.</p>
<p>As the network infrastructure provides features which can be utilized by a social media and messaging application we could integrate that aspect to some extent to add a "social trading" experience as well to gain a new tool for an alternative security module (utilizing social graph, reputation).</p>
<p>Both the approach to allow an off-chain protocol and to add the social aspect would help to distinguish Bisq from the competitors in the DEX market.</p>
<p>As the architecure is very different to the current Bisq model I think it justifies to start over with a completely new code base.</p>
<h2>Base modules</h2>
<h3>P2P network layer:</h3>
<ul>
<li>Modular p2p network layers with Tor + I2P support (and Nym once its production ready)</li>
<li>Pow for dos protection</li>
<li>Use a DHT for data storage to avoid scaling issues like we have with mailbox messages</li>
<li>Different routing strategies (gossip, DHT,...) to gain diff. properties of the overall network</li>
<li>Multiple isolated network IDs (onion address, i2p address). e.g. each offer has its own address which is only used for one trade.</li>
<li>No special nodes like current seed nodes. Seed nodes will do nothing more then seeding.</li>
</ul>
<h3>Message board</h3>
<ul>
<li>Publish/subscriber model for channels of groups of public data (offers, public messages, discussion thread)</li>
<li>Users can reply to a message (e.g. take offer, negotiate an offer, comment on thread,..)</li>
</ul>
<h3>Direct communication channels</h3>
<ul>
<li>Private chat between 2 users</li>
<li>Trade protocol message exchange</li>
<li>Dispute communication with mediators</li>
</ul>
<h3>Security modules</h3>
<ul>
<li>Atomic crosschain swaps</li>
<li>2of2 Multisig + DAO based protection as it is used in Bisq now</li>
<li>Reputation based</li>
<li>Social graph based (e.g. using outside social media or the social graph created inside Bisq using the chat/discussion board)</li>
<li>Account age witness</li>
<li>BSQ bond</li>
<li>...</li>
</ul>
<h3>Trade execution</h3>
<ul>
<li>State machine executing the specific trade protocol based on the choosen security module</li>
<li>Asset transfer can be part of the security protocol (like in current Bisq model or in atomic swaps) or independent (can transfer anything to anything out of band)</li>
</ul>
<h3>Dispute resolution service</h3>
<ul>
<li>Open market for mediators who offer their service</li>
<li>Reputation based</li>
<li>Traders choose with security module if they use it and pay a fee directly to a pool (like insurance)</li>
</ul>
<h3>Using external wallets via RPC</h3>
<ul>
<li>Avoid the liability to maintain an internal wallet</li>
<li>Use a plugin-like architecture for adding and removing different wallets for diff. blockchains</li>
</ul>
<h3>Blockchain data provider</h3>
<ul>
<li>Provide blockchain related data, like transaction confirmations</li>
<li>Similar like wallet let user plug in different blockchains. Can be a local full node for best security/privacy or public nodes</li>
<li>Can be integrated with the wallet (e.g. bitcoin core), but conceptually it is separated as wallet carries keys and that layer has different security requirements</li>
</ul>
<h3>API and protocol driven</h3>
<ul>
<li>Start with API and protocol so 3rd parties can implement clients and use modules independently as far as context permits (e.g. have a social media app using only P2P and message board)</li>
<li>Focus on market maker use case to meet the liquidity challenge</li>
</ul>
<h3>Bisq DAO</h3>
<p>The Bisq DAO can be distributed to the supported blockchains in the way that BSQ owners can burn BTC based BSQ and by providing the proof of burn they can request reimbursement on the side-chain DAO. Any side-chain DAO will start with a new genesis transaction. This is based on burned BSQ from some Bisq core contributors so the initial distribution is somehow reflecting the voting power distribution on the BTC based DAO.<br>
One can also go back to the BTC based DAO by the same burn-issuance swap model, that should guarantee that the value of a BSQ on different chains is roughly the same. It might be useful also for improving privacy by swapping between chains (not perfect but increase costs for chain analysis mercenaries).<br>
All that will not require any code change beside the required adoption to the blockchain parameters. The total amount of BSQ will stay the same of course, it is just distributed to multiple blockchains.</p>
<h3>Trade fees, revenue</h3>
<p>How to deal with trade fees in the overall model is an open question, but I am sure thats the least problem to solve ;-).</p>
<h2>Social trading</h2>
<p>I think the social aspect is heavily under-utilized and would be something which distinguishes Bisq strongly from the large group of competing DEX projects. As privacy protecton is the core and comes by default, this might be also a potential alternative to some social media platforms. Though being aware that this is a huge space on its own we should focus on what is most useful in a DEX and cryptocurrency context. I have not thought much about it as it is a rather new idea. A main utility could be that it can be used to provide some level of trust (users have built up trust by having conversations and thus agree on lower security requirements making the trade cheaper and reduce friction).</p>
<p>As we see in the OTC trades on keybase users are ok to trade small amounts for weak or nearly no secruity.<br>
This aspect can be seen as optional and low priority and probably requires more thought and discussion to see if it makes sense.</p>
<h2>Roadmap</h2>
<p>I am aware that this is a huge project and have not thought about any concrete plans how that could be implemented (beside that I worked on some prototypes specially on the p2p side). So if it is feasible to get there is another open question and with our shortage on dev resources I have my doubts. But lets see, maybe some new devs get attracted ;-).</p>
<p>One approach could be to develop in parallel a Bisq version based on another blockchain (seems Liquid is the most promising candidate so far). Once we have that, users have the choice to use Bisq or Lisq (the Liquid based Bisq). Later once we have implemented the Misq project it will help to reduce the effort to integrate Liquid into Misq.</p>
<h2>Why not go full atomic cross chain swaps?</h2>
<p>It is technically and conceptually probably the most convincing approach but there are some issues also which I think might be a barrier for wider adoption, specially in a P2P context.</p>
<ul>
<li>It only works for crypto (no fiat)</li>
<li>It still requires onchain transactions which can be a limiting factor for smaller trades</li>
<li>Dev effort and setting up the infrastructure to support a new asset pair is a considerable effort and likely comes with permanent operational costs (e.g. blockchain relay nodes)</li>
<li>It will not work between chains which have not at least the basic smart contract features. E.g. XMR-Grin likely would not work or at least XMR to another Monero fork will not work (though that is the least of the issues ;-))</li>
</ul>
<p>So to build a DEX based only on atomic swaps would come with its limitations. Beside that the adapter signature based approach (required for XMR/BTC swaps) is still in developement.</p>
<p>In contrast the above model would add a lot of flexibility and could serve many different user cases including atomic swaps. A no-coiner could get their first BTC and pay with Paypal to someone he met on the message board and have built up sufficient trust to engage in a small amount trade. Others can choose an atomic cross chain swap with a large trade amount and get best security and are fine to pay a bit of miner fees. Others have coins on one of the supported blockchains like L-BTC or LTC and use the normal Bisq model with security deposit. Monero folks can swap their XMR to anything including fiat or Havana cigars by choosing the security module they prefer.</p>
<h2>Collateral based protocols</h2>
<p>Note that there would be 2 models of the collateral based protocols.<br>
One is the same as in Bisq where the traders pay the security deposit in the currency of the choosen blockchain (e.g. BTC, L-BTC, LTC) and the seller use the asset to sell as collateral which will be transferred to the peer.</p>
<p>Then there is another model which keeps the collateral and transfer separate.<br>
If the transferred assets do not match that base currency they need to choose who pays first. The one who pays last will have to lock up 100% of the equivalent of the trade amount using the base currency plus some security deposit (e.g. 10%). The one who pays first only needs to lock up the security deposit (e.g. 10%). After both have exchanged their assets via any arbitrary channel (can be anything, EUR <-> USD or apple <-> banana) they sign the payout tx to get refunded their collateral. The drawback is that the one who pays last requires a larger deposit, but they can choose who want to play that role and it might be reflected in the trade price. So there is some flexibility and the extra capital requirement can be priced in.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/330">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNXREQ3HWOVL3YIORATTKNVLVANCNFSM43QW3BSA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNQLO5AJFVC3LFQU5Z3TKNVLVA5CNFSM43QW3BSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4M5LPRYQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/330",
"url": "https://github.com/bisq-network/proposals/issues/330",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>