Bisq 2 Roles
Bisq 2 has contributors that take responsibility for specific bonded roles for the network resources and processes.
There are 2 types of bonded roles.
- System roles
- Delegable roles
Contents
System roles
System roles cannot be delegated to users due security reasons or requirement for system wide (weak) consensus.
Mediator
Similar as in Bisq 1, mediators are used for Bisq Easy traded in case of problems, but they have no enforcement power. They can provide information to moderators for banning a user who severely violated trade rules.
Moderator
Users can report other users to moderators for violations of chat or trade rules. The moderator investigates the case and if they consider the violation severe they can ban that users profile ID.
Moderators can delete chat messages as well (technically its not deleting but adding a ban flag associated to the message, as only the message author can delete it).
In future we might consider to make some channels "invite-only" to protect against spam or other abuse. The 'events' section might be a candidate for that. Once that is in place the moderator might be the role to grant write access to a channel.
As Bisq 2 provides support for multiple identities that banning might not have a big effect as a spamming user could easily create a new profile and continue.
If spam becomes a problem we might add protection with proof of work and/or reputation features.
Security manager
Similar to Filter operator in Bisq 1. Can publish data to block other roles/nodes and other security related things (block trading). User can deactivate per program argument security manager, so the security manager has reduced power.
The security manager can broadcast a alert message to the network or to specific users. Alerts can be ignored by the users should they wish.
The types of alters include:
- INFO (info popup with a text message)
- WARN (warn popup with a text message)
- HALT_TRADE (custom emergency popup with a text message and disable all trade operations for the defined trade protocol)
- BAN (no text message, data of the banned role)
Update manager
The release manager can broadcast a update notification to the network.
The types of notification types include:
- PRE_RELEASE: Send update notification for new pre-release (user can enable to get notified about pre-releases in settings, default is off).
- RELEASE: Send update notification about a new release.
- FORCED_UPDATE: Warn popup with a text message about the need for update to the required min version. All trade operations will be halted until updated.
Delegable roles
Delegable roles can be operated by any users themself and assigned via JVM arguments. They are based on publicly available data and do not require to be in consensus with other Bisq 2 users.
Seed node
Seed nodes act as providers for the P2P network data and filtered blocks from the Bitcoin blockchain for lite nodes. When a node starts, it requests all P2P network data from several seed nodes.
There must be at least one hard coded (root) seed node.
Oracle node
Oracle nodes provide three services. There always has to be at least one oracle node.
DAO bridge service
The DAO bridge service requests DAO data from a Bisq 1 API and broadcasts the relevant data to the Bisq 2 network. This data is required to verify bonded roles and for reputation sources (Users that have burned BSQ or bonded BSQ).
Users can verify the DAO data provided by the DAO bridge service by requesting the DAO data itself from a Bisq 1 API node and checking if the distributed data was correct. If they would detect invalid data they have to report it to the developers and if it turns out the DAO bridge service has provided incorrect data intentionally a confiscation proposal will be created to request the DAO for confiscating the operators bond.
Reputation service
The reputation service request data from Bisq 1 via an API for reputation sources (account age and signed account age witness) and broadcasts the relevant data to the Bisq 2 network.
Time-stamping service
The time-stamping service provides a time-stamping function for profile age of Bisq 2 users.
Explorer nodes
Explorer nodes are used for requesting the state of a transaction during the trade process. For example they once bitcoin payment is confirmed then they will inform the user.
Market price node
Market price node are used for requesting market prices. For example the BTC/USD or BTC/EUR price. As trades are made based on this information it is important that the market price nodes are bonded.
How does someone get to perform a bonded role in Bisq 2
Contributors for the roles are usually have established Bisq contributors that have been approved by a DAO vote to perform a certain role.
For increased security a contributor must make a proposal to become a contributor for a specific role that is voted on by the Bisq DAO. If the vote is successful that a BSQ bond will be locked up automatically for that contributors specific role.
The process for performing a role in Bisq 2 is usually as follows:
- A potential contributor posts a proposal to Bisq GitHub Proposals Repository putting their case forward for performing a certain role for Bisq.
- The proposal is discussed on the GitHub issue.
- Once there is rough consensus for the proposal to be accepted the potential contributor then makes a proposal for a bonded roles from the Bisq application. They would need to ensure that they have enough BSQ available for the BSQ bond.
- The proposal is put to the Bisq DAO for voting. If the proposal is accepted the BSQ bond is locked and the user can then work in their new role. If the proposal is rejected the BSQ is returned to the user that made the proposal.
For more information on becoming a contributor for Bisq see the Contributor Checklist.
Not all roles require bonding so it is often easier to get started on a non-bonded role and develop your reputation prior to contributing for a role that requires bonding.
BSQ bonding for roles/nodes
All roles/nodes require a BSQ bond and DAO voting.
The oracle node verifies that all Bisq 2 bonded roles/nodes have a BSQ bond setup.
Their are 2 nodes that cannot be verified by the oracle node. These are the root seed node and the root oracle node (as this would present a chicken and egg problem).
Both these root nodes however are required to have also their own BSQ bond set up.
The bonding process is transparent all users are able to manually verify that all bonded roles / nodes have valid BSQ bonds. This is can be done though the DAO section of the Bisq 1 application.
