[bisq-network/proposals] Bisq 2.0 - A multi-protocol DEX (working title Misq) (#330)

chimp1984 notifications at github.com
Tue Apr 27 00:32:53 CEST 2021


I think the idea posted at https://github.com/bisq-network/proposals/issues/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 https://github.com/bisq-network/projects/issues/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 federated trading bot and have certain risk 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 AAMM models are usually in a smart contract, which is not possible to do on Bitcoin, but we don't need to 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 the same, 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 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 revenue 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).

An important addition are arbitrage traders/bots who make sure that Bisq internal price anomalities are getting resolved fast. 
So all win: The users get more liquidity and prices closer to external market price, the liquidity providers (bots/pools) earn by automated trading and keeping spreads low and the arbitrage traders earn from imbalances.  

Maybe I miss some important difference, so if you are more familiar with those models and automated trading, please add your view on that.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/330#issuecomment-827184975
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210426/ae04f631/attachment.htm>


More information about the bisq-github mailing list