Haveno is an Esperanto word that means ‘harbour’ or ‘port’.
PA(key): /haˈveno/ Hyphenation: ha‧ve‧no
We hope Haveno will be ready to be deployed by the end of 2022.
We only support projects that we consider interesting or useful. We will launch with support for:
|Bitcoin (BTC)||US Dollars (USD)|
|Ether (ETH)||Euro (EUR)|
|Bitcoin Cash (BCH)||British Pounds (GBP)|
Note that all assets are paired with XMR, which is the base currency of the platform (XMR/EUR, XMR/USD, XMR/BTC, etc).
As soon as we feel the platform is solid enough, we will add support for more crypto and fiat currencies, initially targeting some of the assets already listed on Bisq. The community can suggest assets by opening an issue on the ‘listing’ repository and using the correct template.
We explained the structure of Haveno in detail in a dedicated blog post. Here’s a summary:
Half of the fees paid on Haveno will be used to advance Monero and Haveno development
There will be a CCS-like entity called Engine, which will decide which projects/individuals to sponsor using the fees sent by Haveno
Engine will be administrated by a council (Engine Council) consisting of 5 trusted members from the Monero and Haveno developer community (including one Monero Core Team member)
Thanks to the funds that will be sent to Engine, Haveno will be a major contributor to Monero development, allowing Monero to cease its reliance on generous donors and become self-sustaining.
While this structure is exciting and opens a lot of doors, we want Haveno to be as decentralized and robust as possible. That’s why we will always look for ways to decentralize things further.
No. Haveno was created out of the desire to provide people a peer to peer and decentralized way to exchange Monero for fiat currency. Haveno is and will always be non-KYC.
Haveno’s trade protocol is explained in detail on Github.
Our documentation can be found in our GitHub Repository. It contains protcol details, contributing guides, installation instructions, and more.
Arbitrators are the last step of conflict resolution on Haveno, coming after traders attempt to settle disputes by themselves using the chat embedded in the platform, and we inherit them from Bisq. They have a crucial role in the trade process, because they hold one of the three keys during a trade.
Holding one of the three keys makes them a sensitive role, because they could theoretically collude with one of the 2 traders. We are exploring the possibility of migrating to a 2/2 multisig protocol instead of 2/3, but for the time being, we will adopt several measures to drastically reduce the risks for traders:
Arbitrators will be picked up randomly from the pool of available arbitrators. This reduces drastically the possibility of collusion, because traders have no possibility of choosing an arbitrator.
Arbitrators will probably set bonds. These bonds will be locked in the Engine platform and will be used to cover the loss of the victim in case of a malicious arbitrator.
Arbitrators will be trusted members of the Haveno and Monero community, and they will be appointed by the Engine Council in collaboration with the aforementioned community.
Haveno traders will pay two fees. The fee for transacting on the Monero network (a fraction of a cent) and the Haveno fee.
We haven’t made a final decision on the amount of the Haveno fee, but it will most likely be less than 1% of the traded amount.
All fees paid on Haveno will be sent to Engine (see What’s the structure of Haveno?), where they will be used to reward contributors, pay for Haveno development and infrastructure, fund Monero development and research, and more. Fees are also used as an anti-spam mechanism to avoid abuse.
Haveno is not ready yet, but the trade protocol is already working (like most of the backend). People can already make test trades using the legacy user interface (inherited from Bisq).
Yes, it’s already possible to make test trades on our shared Monero stagenet, using the legacy user interface. It’s possible to test trades between xmr <-> fiat and xmr <-> crypto. See the instructions for running your local Haveno test instance.
Haveno will support payment methods that don’t require users to have a bank account, like “Cash in person” (for face to face trades) and “Cash by mail”.
Haveno is a fork of Bisq and shares some of its strengths, such as:
But Haveno brings several improvements over Bisq:
Bisq doesn’t offer strong privacy to its users and has had multiple issues which resulted in the privacy of their users being compromised.
From the points above we can see how trading on Bisq is not private and could result in the deanonymization of traders and contributors. Haveno has no token- it’s based on Monero and has privacy as a core principle.
Bisq has a very complex and resource hungry user interface. One of our main goals is to provide the user with a simple tool that won’t require any technical knowledge.
Bisq is based on Bitcoin and inherits its historically high transaction fees, which are added to tradefees on the platform.
Haveno is based on Monero, allowing traders to take advantage of very low transaction fees (see the comparison between XMR and BTC), resulting in more convenient trades, especially for low amounts.
Haveno will be faster because of three main factors:
The current trade protocol of Haveno is on Github: docs/trade-protocol.md
Bisq recently adopted a protocol based on 2/2 multisig, while Haveno will use their previous protocol: 2/3 multisignature. In a 2/3 multisignature trade, each trader owns one key; this key will be paired with the key of the other trader and will be used to unlock funds and deposits. It’s a 2 of 3 (2/3) protocol because you need only two out of three keys to move funds from the multisignature wallet.
If everything goes fine, the two traders will use their keys to complete the transfer process. If something goes wrong, one of the two parties won’t use their key to complete the transaction, and this is where the arbitrator comes to action.
Arbitrators are inherited from Bisq’s 2/3 protocol. They are a trusted role and have the duty of releasing the funds to one of the two parties in case of a conflict. To do so, they use the third key of the 2/3 multisig protocol.
Using arbitrators has drawbacks:
These issues are solved by employing a small number of trusted arbitrators with strong operational security knowledge that will serve in their roles anonymously.
No. The BSQ token is meant to be the key factor of Bisq’s DAO. We won’t implement Bisq’s DAO and the trades on the platform are based on multisignature transactions. There is no need for a token in the Haveno protocol.
Bisq’s DAO is an interesting and innovative governance mechanism, but currently seems to be an unnecessary complication that takes a lot of resources to maintain. Bisq contributors earn BSQ tokens according to how much they contribute to Bisq and the roles they cover inside the project. The more BSQ a person has earned, the more voting power they have.
Bisq’s DAO has several important flaws that make its effectiveness as a tool for decentralized governance dubious:
BSQ tokens can also be bought. Acquired BSQ has less “voting power” than earned BSQ, but less doesn’t mean none. A wealthy and malicious attacker could buy the amount of BSQ necessary to influence a vote. This is a major hole for a decentralized governance system.
Bisq itself acknowledges that not everything can be managed by the DAO in its current state. For example, changes to the DAO itself still require the approval of Manfred (the creator of the DAO). This is an odd approach outside of the DAO governance system.
Arbitrators are trusted entities that need to gain the trust of the creator of Bisq, who declared he will not give keys to people he doesn’t know or trust. This is factually bypassing the DAO and centralizes the choice of the arbitrators on one person.
The DAO as used by Bisq, is heavily based on GitHub, which is a centralized entity that has the power to shut down repositories at will. If that would ever happen, Bisq’s governance structure will be effectively frozen until the structure is migrated somewhere else and the Bisq app will be adapted. Such migration would take a lot of time and effort.
There seems to be no expiring date for roles or maximum amount of roles that a contributor can cover. As a result, long term Bisq contributors (who already cover multiple roles) will always gain more BSQ than a newcomer, and unless they decide on their own to leave some roles, there is no way for a new contributor to have as much voting power as a veteran Bisq contributor. The new contributor could make large contributions that would earn them a huge amount of BSQ, but even in that case the release of BSQ is voted on with the mechanism we mentioned earlier, so veteran Bisq contributors (with more voting power) could vote against releasing rewards to the newcomer if they feel their power threatened.
We already mentioned that a recent paper demonstrated that it’s possible to track Bisq contributors participating to Bisq’s DAO and deanonymize them.