Bisq 2.0 - A multi-protocol DEX (working title Misq)
chimp1984 opened this issue · comments
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
Overview
The suggested new architecture supports multiple trade protocols and security mechanisms as well as multiple blockchains.
The separation of the security mechanism and the asset transfer provides a lot of flexibility to adjust to users needs and preferences.
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.
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).
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.
As the architecure is very different to the current Bisq model I think it justifies to start over with a completely new code base.
Base modules
P2P network layer:
- Modular p2p network layers with Tor + I2P support (and Nym once its production ready)
- Pow for dos protection
- Use a DHT for data storage to avoid scaling issues like we have with mailbox messages
- Different routing strategies (gossip, DHT,...) to gain diff. properties of the overall network
- Multiple isolated network IDs (onion address, i2p address). e.g. each offer has its own address which is only used for one trade.
- No special nodes like current seed nodes. Seed nodes will do nothing more then seeding.
Message board
- Publish/subscriber model for channels of groups of public data (offers, public messages, discussion thread)
- Users can reply to a message (e.g. take offer, negotiate an offer, comment on thread,..)
Direct communication channels
- Private chat between 2 users
- Trade protocol message exchange
- Dispute communication with mediators
Security modules
- Atomic crosschain swaps
- Lightning network bases protocol
- 2of2 Multisig + DAO based protection as it is used in Bisq now
- Protocols utilizing covenants on Liquid
- Reputation based
- Social graph based (e.g. using outside social media or the social graph created inside Bisq using the chat/discussion board)
- Account age witness
- BSQ bond
- ...
Trade execution
- State machine executing the specific trade protocol based on the choosen security module
- 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)
Dispute resolution service
- Open market for mediators who offer their service
- Reputation based
- Traders choose with security module if they use it and pay a fee directly to a pool (like insurance)
Using external wallets via RPC
- Avoid the liability to maintain an internal wallet
- Use a plugin-like architecture for adding and removing different wallets for diff. blockchains
Blockchain data provider
- Provide blockchain related data, like transaction confirmations
- Similar like wallet let user plug in different blockchains. Can be a local full node for best security/privacy or public nodes
- 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
API and protocol driven
- 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)
- Focus on market maker use case to meet the liquidity challenge
Bisq DAO
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.
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).
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.
Trade fees, revenue
How to deal with trade fees in the overall model is an open question, but I am sure thats the least problem to solve ;-).
Social trading
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).
As we see in the OTC trades on keybase users are ok to trade small amounts for weak or nearly no secruity.
This aspect can be seen as optional and low priority and probably requires more thought and discussion to see if it makes sense.
Roadmap
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 ;-).
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.
Why not go full atomic cross chain swaps?
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.
- It only works for crypto (no fiat)
- It still requires onchain transactions which can be a limiting factor for smaller trades
- 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)
- 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 ;-))
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.
In contrast the above model would add a lot of flexibility and could serve many different use cases including atomic swaps. A no-coiner could get their first BTC and pay with Paypal to someone they 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.
Collateral based protocols
Note that there would be 2 models of the collateral based protocol.
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.
Then there is another model which keeps the collateral and transfer separate.
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 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 so market makers might be motivated to play that role for some premium.
Next steps
Tried to get a bit of a plan what needs to be done if the proposal finds support. Also did a very rough estimation which ended up in 200 person days, which would be about 3 months for 3 full time devs. Probably its more, but too early at that stage but I guess a range of 2-6 months for 3 full time devs might be realistic.
Validate concept
- Get basic concept ACK
- Concept refinement
- UX clickdummy for main use cases to see UX challenges and see it they can be solved
- Solve open questions: Fee model, DAO integration
Bootstrap project
- Create project
- Funding via DAO
- Breakdown in milestones
- Estimations of milestones
- Team setup
Design
- Architecture design
- Message formats (protobuf?)
- Persistence solution
- API (grpc)
App infrastructure
- Daemon
- Cli, trade bot script, javafx and html frontend (mobile use case)
- Crypto lib, decide on hash, sig and encryption algorithms
- Util lib
Persitence lib
P2P lib
Message board
Wallet, blockchain
- wallet bridge api
- wallet bridge for BTC and L-BTC
- blockchain bridge api
- blockchain bridge for BTC and L-BTC
Protocol, security
- trade protocol api
- Bisq 2of+DAO trade protocol impl.
- OTC trade protocol impl.
- security module api
- Bisq 2of+DAO security module impl
- OTC security module impl
Dispute resultion
- mediation module
DAO
- DAO integration/bridge
It sounds very ambitious!
Positives:
- starting from scratch helps that there is no legacy stuff to inhibit dev productivity.
- the point about developing API-based seems an important one, UX/UI can be built separately / different timeline.
- moving away from BitcoinJ to a wallet-agnostic solution would be a huge win.
- adding a social trading option like keybase sounds good, would like to understand more.
- working solutions could be delivered in stages.
Concerns:
- I think it would take longer than estimated; others are not necessarily as fast coders as you.
- market dilution, but I would expect much higher participants / offers in markets where trading cost is reduced as expected.
- making everything modular - perhaps harder for non techie users to get it running / troubleshoot.
* I think it would take longer than estimated; others are not necessarily as fast coders as you.
I bet you will beat me, at least you produce less bugs ;-)
* making everything modular - perhaps harder for non techie users to get it running / troubleshoot.
The modular approach should not be visible to users. For users its just one app where they can enable features (chains). But sure not much worked out yet how that will work.
Generally UX is probably a main issue. Not sure how it can work out to make it easy for users to select the options without the mental costs of understanding all the context and trade offs.... So I think that might be actually the biggest risk and we should try to work on that first before getting any deeper on other technical details.
I tried to sketch a bit the basics of the UX and to my surprise it might not be that hard and different to the current model. Sure it adds more options and with that comes more complexity but a good UX designer can hopefully design it so that it becomes acceptable.
The step based approach is just an example, could be done differently as well. Some options might be also set at initial setup or in preferences.
The plugging in of wallet and blockchain infrastructure could be done dynamically, so that a user gets their BTC wallet setup once they choose to use BTC.
Create offer
- Choose ask and bid assets (e.g. EUR, XMR)
- Set amount of ask and bid assets and/or price (fix and % from market). Include range amounts.
- Select payment method for ask and bid assets. Allow multiple/all and user defined method. Offered payment methods are filtered for asset type.
- Select security model. List of options with quick info about fees, risk, duration....
Offered options filtered by asset type. Multiple selection possible.
- Atomic swap:
- Network fee: 20 USD
- Trade fee: 5 USD
- Duration: 10 min
- Security: Very high
- Collateral based:
- Supported blockchains: BTC, L-BTC, LTC (select one)
- Network fee: 1-10 USD
- Trade fee: 5 USD
- Dispute resolution fee: 5 USD
- Duration: 2-10 min
- Security: High
- Supported blockchains: BTC, L-BTC, LTC (select one)
- Reputation based
- Network fee: 0 USD
- Trade fee: 5 USD
- Duration: 1-10 min
- Security: Very low, not recommended for higher trade amounts, no support in case of fraud
- Custom (fill in short description)
- Network fee: 0 USD
- Trade fee: 5 USD
- Duration: 1-10 min
- Security: Very low, not recommended for higher trade amounts, no support in case of fraud
Review offer:
I ask for 500 EUR and offer 2 XMR.
Payment of EUR via SEPA to my account xyz
Payment of XMR onchain from my XMR account xyz
Supported security model(s):
- Collateral based on L-BTC
- Collateral based on LTC
- Custom: I can verify that I am an active Monero community member and can proof on Twitter, Monero forum and Reddit my identity.
Expected fees: Depends on choosen protocol (5-25 USD).
Post offer
Offer gets published to P2P network
Offerbook
- Filter by asset, payment method, secruity model and search strings
- Show offer overview of matching offers.
- Expand offer on click to see full details
- Allow user to contact maker if maker has enabled that feature.
Take offer
- Set amount in case it was a range amount
- Select payment methods in case there have been multiple
- Select security model in case there have been multiple, select sub parameters if needed (e.g. chain). Show details info like in create offer view. User can define their supported payment methods and secruity models in the settings and then get enabled only those, thus reducing selection work.
If we permit custom free text data is an open question and might end up being abused for spam, scams, etc. We could give mediators a moderation right so that they can mark such offers for getting blocked and allow users to report such offers. Benefit would be that it adds flexibility and allows new niche markets where dev effort would not be justified by low trade volume.
I like the ideas a lot! I think it is a good idea to focus on protocol and API, but we need to make sure to start soon with developer relations/documentation, development funds?,... for devs to come up with slick UIs or other implementations leveraging the API (I think 0x.org has done a good job in that regard)
My concerns:
- Dev time will be longer (as @jmacxx already mentioned), so we have to take care that we have sufficient bug fixing resources at hand for maintaining the main app until the replacement is ready. Without the need that Bisq 2.0 devs have to jump back and forth all the time.
- We'll need to make sure that it is super easy to use from the beginning and hide the complexity for noobs.
I like the idea, especially making it modular so that it can evolve and grow in the future while avoiding bottlenecks. It makes a lot of sense to separate the base layer modules from the trading mechanism.
But... my concern is that it seems very ambitious and will require a lot of effort and time to build, even modules that already exist in Bisq.
Why not re-use the Bisq P2P network, offer book and direct-message system? We could have a simple P2P message board for offers in days using existing code. Just create a new market on Bisq (call it "experimental") and remove the fees required to post an offer, change the payment methods so that both sides are fiat (ie: off-chain off-Bisq) and eliminate the security deposits... voilà, you have an instant tor-based p2p message board and offer book!
P2P network layer -> you already have everything you need in Bisq 1.6.2
Message board -> you already have everything you need in Bisq 1.6.2
Private chat between 2 users -> you already have everything you need in Bisq 1.6.2
Security modules -> you have enough to start with in Bisq 1.6.2
Account age witness
BSQ bond system
There's even an informal market to buy small amounts of BSQ and BTC on keybase: https://bisq.wiki/Informal_Market_for_Small_BTC_Trades#How_to_access_the_Keybase_channel
Why reinvent the wheel?
-
Ambitious I would want to work on Misq for the mid/long term, but wonder (like everyone else) if it is possible to build this and keep Bisq going with the current number of devs. That said, I'm ready to dive in.
-
Roadmap You suggest developing a parallel Lisq version separate from Bisq, then integrating Lisq into Misq. I suggest new work begins on Misq, while calling it Lisq. As soon as Misq can support Lisq and Bisq, re-name it Misq. I assume there are components in Bisq that could be used by Lisq, and bits of Bisq integration into Misq can begin at once.
-
Modules I worked on an OSGi module based system when Java Modules were just a spec, and it was painful. But I think building java apps from fine grained modules is a very good way to separate concerns, manage dependencies, and put together multiple apps from pre-defined module lists -- details non techie users do not need to be concerned about. I assume Java Modules are easier to work with than OSGi of 15 years ago, and we could move Gradle's current responsibility for defining modules to Java Module definitions. I'm not sure how Gradle works with Java Modules, but I also assume it would not be messier than the current build file. [EDIT I do not think the current build file is messy, but it will be if we start defining lots of new, small scoped sub projects.]
OK here is an even more radical proposal that would minimize work and time needed: have everything that does not need to be in Bisq outside Bisq. Use Bisq only for what it does best: security features, dispute resolution and DAO governance.
P2P network layer: Don't use Bisq. Use bittorrent.
Message board: Don't use Bisq. Use keybase, a wiki or bittorrent.
Direct communication channels: Don't use Bisq. Use keybase, signal or whatever external app is most secure at the time.
Trade execution: Don't use Bisq. Use Lightning network for Bitcoin, altcoins and the usual payment methods for fiat.
Dispute resolution service: use Bisq mediators, arbitrators, DAO refunds, etc as they are right now.
Security modules: use Bisq for multisig security deposits, security bonds in BSQ, etc...
This could even be done TODAY without writing a single line of code. How?
- You meet a buyer on Keybase. Agree on price and amount.
- You agree to make a BSQ trade on bisq at a particular price. That creates the security deposit, dispute resolution mechanism, even the secure chat!
- You carry out the BTC-fiat trade outside Bisq.
- If all goes well, you can do more trades with the same person. If there are any problems, you go to mediation on the BSQ trade.
Obviously the amount of BSQ locked up would need to be large enough in relation to the BTC-fiat trade (50-80%?) to act as a good enough security deposit and deterrent in case of dispute. During the 24 hours that the BSQ trade lasts you can do as many BTC-fiat trades as you and your counterparty want, thus minimizing the number of on-chain txs.
Obviously this would work even better with small UX, software adaptation and training mediators to allow this type of trade. We could even have DAO-bonded market makers. But the point is that it would work even without all of that to solve the problem of reducing expensive on-chain transactions while keeping security NOW. Not in a year or two of development.
In fact I've created a proposal for this: #331
I would want to work on Misq for the mid/long term, but wonder (like everyone else) if it is possible to build this and keep Bisq going with the current number of devs. That said, I'm ready to dive in.
Yes it should be done in parallel, so Bisq just continues as it is until the new project is mature enough to take over and even then the old Bisq could be kept running if there is demand.
You suggest developing a parallel Lisq version separate from Bisq, then integrating Lisq into Misq. I suggest new work begins on Misq, while calling it Lisq. As soon as Misq can support Lisq and Bisq, re-name it Misq. I assume there are components in Bisq that could be used by Lisq, and bits of Bisq integration into Misq can begin at once.
Not so sure anymore if a renaming is a good idea, as it might confuse users and we managed to build up a very valueable brand. But maybe its good to have a working title to not confuse normal Bisq with the new one...
I worked on an OSGi module based system when Java Modules were just a spec, and it was painful. But I think building java apps from fine grained modules is a very good way to separate concerns, manage dependencies, and put together multiple apps from pre-defined module lists -- details non techie users do not need to be concerned about. I assume Java Modules are easier to work with than OSGi of 15 years ago, and we could move Gradle's current responsibility for defining modules to Java Module definitions. I'm not sure how Gradle works with Java Modules, but I also assume it would not be messier than the current build file. [EDIT I do not think the current build file is messy, but it will be if we start defining lots of new, small scoped sub projects.]
Yes I think those old OSGi like heavy weight frameworks have been a big failure.
I mean module just from a conceptual point of view. An entity doing one clearly scoped thing and not more. This can be a package in the code or a module as in Bisq the dif. modules or a library project or even written in another language and run as independent process and interact via TPC channels using ZeroMQ or the like.
I think we should start the most simple but take care to keep those boundaries clean.
At the moment I try to focus on the high level picture and concept to not get lost in details, but there will be quite a lot to fine-tune about the architecture like choosing the message format, module APIs, etc....
Once we have a more clear plan I will continue on my P2P network prototype and we can build on top of that and finetune from there....
OK here is an even more radical proposal
I think that this proposal would be very similar to Thorchain model. BSQ would play the role of their token Rune. The difference, of course, is that unlike Bisq they cannot handle fiat trades.
I think the idea posted at #331 is quite interesting and can help to get further here as well.
I think to have an iterative process with continuous results to the end user is very important to avoid to get lost and see early what works and what not and be able to adjust.
As it seems the general idea has found support I started a Bisq project at bisq-network/projects#51 to get the first milestones bootstrapped.
Please leave your up/down votes to get fast a consensus about the support.
Beside that what are the next steps?
- Work on concept refinement and solving open issues like trade fees, DAO,....
- Start to work on the UX challenges for the multi-protocol-options. The Ledger UX might serve as inspiration, they did a great job.
- Explore further the idea of social trading and its potential application in Bisq
- Explore how the concepts of AMM could be integrated in Bisq.
- Devs can start to explore options how to integrate external wallets and blockchain data providers
- Other devs can start to think about how to design the trade protocol architecture
Regardig AMM:
I am still not very familiar with the details of those models but as far I understand it you can see a liquidity pool as a trading bot and the liquidity providers get presented a different easier to understand mental model.
Instead telling them they are a distributed trading bot and have certain risks and have certain earning options its presented like a dividend/interest rate model, which is much easier for people to deal with.
Provide xxx funds and earn xx% over a time period.
The locked up funds of those AMM models are usually in a smart contract, which is not possible to do on Bitcoin (covenants on Liquid might make that possible though), but we don't need to do that if each liquidity provider stays in control of their own funds and run their own trading bot.
I think the overall function and benefit are similar, and then its a UX challenge how to reduce complexity for the liquidity provider.
Assume there are integrated trading bots and they are ranked according to their past performance. The user can select the best bot (or make their own) and add whatever amount they want to allocate. Then the bot generates revenue (or loss) by trading on behalf fo the user. The UI shows continuous P/L stream and the user can stop it any time. Of course there are risks involved and that has to be communcated as well (better as usually the case at AMM projects). Reliance on a price oracle is one of the risks but as the user can choose which price feed they use this risk can be at least distributed and is not visible to others.
An important addition are arbitrage traders/bots who make sure that Bisq's internal price anomalities are getting dissolved fast.
So all win: The users get more liquidity and prices closer to external market price, the liquidity providers earn by automated trading and keeping spreads low and the arbitrage traders earn from imbalances.
The price finding in AMM is not that optimal IMO and comes with costs and risks. In the bot use case the price is not determined by an algorithm which requires arbitrage traders to get adjusted to external price levels but relies on price feeds which can be defined by the bot operator, thus there is no single point of failure to the overall system in case the price feed gets corrupted (though to the bots using the manipulated price feed). Price aggregation as we use in Bisq can reduce that risk. Also the AMM models have issues with under-utilisation of capital. So all in all I think its not that efficient and the main success comes from the simplifaction of the mental model. 0.3-0.6% trade fee is also not really low for an automated system.
Here is a good overview about the Uniswap model:
https://docs.ethhub.io/guides/graphical-guide-for-understanding-uniswap/
Liquidity providers get UNI tokens in return to their provided asset (ETH, ERC20 token). Once they take out their provided liquidity (as % of the pool, not as the nominal added amounts) they burn the UNI and get the earned fees (0.3% for ETH-ERC20 or 0.6% for ERC20-ERC20 trades). So there is volatility risk (impermanent loss) and the risk that the internal token is used as collateral and could lose value in a black swan scenario.
Here is a good write up about Impermanent Loss:
https://academy.binance.com/en/articles/impermanent-loss-explained
It seems the volatility risk is not reflected in the trade fees. A highly volatile asset earns the same trade fees but comes with much higher risk for impermanent loss.
Maybe I miss some important difference, so if you are more familiar with those models and automated trading, please add your view on that.
t seems the volatility risk is not reflected in the trade fees. A highly volatile asset earns the same trade fees but comes with much higher risk for impermanent loss.
Maybe I miss some important difference, so if you are more familiar with those models and automated trading, please add your view on that.
I think I never found anyone complaining about this, but you are right. When trying to provide liquidity for rskswap I knew I would not want to provide for the DOC/RBTC pool but for the BPRO/RBTC pool because of volatility.
I think I never found anyone complaining about this
Investigating to really understand those models takes time and effort. Most users probably don't invest that much money that it justifies a lot of due dilligence effort. Thats one reason why regulation tries to protect retail investors as its much easier to scam 10000 small investors than to scam 1 pro invester who spends weeks for due dilligence and comes with a lot of experience.
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.
I agree with this. Currently trades done on Bisq have a reduced community / social aspect to them than is present on Bisq's social platforms. I think there is lots of potential to develop this and utilize Bisq's community strengths.
Having multiple protocols on one platform sounds fantastic. For example it would be great to use Misq to provide liquidity to a BSQ / BTC pool, do regular small EUR trades with no coiners for BTC, and also larger collateral based trades to purchase some BTC.
My initial concerns reading this would having everything on one platform might lead to a reduction in privacy.
Using Keybase to sell small amounts of BTC has been great. But I am still not entirely happy with having to expose personal details each trade. The trade off is helping someone else get some BTC and making a small amount of profit. Keybase not being part of Bisq is also good as it creates an additional step between Keybase username and Bisq onion address.
It would be great if Misq could keep user privacy whilst retaining the benefits that would come from trading based on reputation.
Users can reply to a message (e.g. take offer, negotiate an offer, comment on thread,..)
My concern with this, and to be fair the buy-bitcoin Keybase channel, is that it would be easy for a disgruntled trader to post identifying information on a thread, or even on external website eg Don't trade with Joe Blogs he is a scammer and stole all my Bitcoin etc
Do you mind if I make a social trading proposal as an expansion to this, I already have lots of details ready (protocols, utility, design specifications) and been wanting to do one for a while? @chimp1984
Hi @Mentors4EDU, sure please share your ideas!
Submitted, I tried being as detailed as possible!
Keep in mind until it receives an ACK, it is still technically a draft, so you are welcome to comment.
@chimp1984
How I imagine a modular architecture for Misq - multiprotocol Bisq 2.0
A shared marketplace, order book, communications protocol... which can then connect to many different trade protocols. All resources can be pooled for the shared infrastructure, but then each project can work on their own version of the trade protocol, wallets, etc.. and experiment freely with on-chain, off-chain, lightning, atomic swaps, different base currencies, different multisig systems, arbitration, moderation, MAD, unsecured, etc...
obv this is just a rough approx by a non-dev... I have a lot of stuff missing (wallets? price-feeds? blockchains? etc)
Looking forward to someone who actually knows the Bisq code well to provide a better version!
Hi @chimp1984 thanks for this. It looks like a very exciting development.
Closing as approved.
Links to the related projects that are the outcome of this propsal are:
- Bisq 2.0 - A multi-protocol DEX (working title Misq)
- Prototype for offer book and create offer UX for Bisq 2.0 (Misq)
- Define architecture and interfaces for the protocol layer
- Research a solution for dynamically loading remote modules
- Specify interface and architecture for wallet and blockchain data modules
Please also see the work in progress Misq repository here:
There is also discussion about the project on Bisq Keybase on the channel bisq#misq-dev