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

System roles

System roles cannot be delegated to users due security reasons or requirement for system wide (weak) consensus.

Mediator

Similar to Bisq 1 mediator

Moderator

Can ban users, chat room moderator

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.

Update manager

Publishes software update notifications

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

Similar as in Bisq 1 but seed nodes have less importance for initial data requests. There must be at least one hard coded seed node.

Oracle node

Serves a bridge and "notary" for Bisq 1 DAO data and P2P network data (account age, account age witness data) and for timestamping Bisq2 profile creation (Bisq2 account age). There must be at least one hard coded seed node.

Explorer nodes

Lookup for trade transactions for informational purpose. Pose little but non-zero risk.

Market price node

Same as Bisq 1 price nodes.

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:

1. A potential contributor posts a proposal to Bisq GitHub Proposals Repository putting their case forward for performing a certain role for Bisq.
2. The proposal is discussed on the GitHub issue.
3. 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.
4. 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 bonds

All roles 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.