Bisq Wiki - User contributions [en]

BSQ token

2020-09-30T16:32:54Z

Bayer: Created page with "Placeholder --> All about the BSQ token."

Placeholder --> All about the BSQ token.

DAO technical overview

2020-09-28T15:38:54Z

Bayer:

<big>'''''<big>WORK IN PROGRESS</big>'''''</big><big> This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===
A proposal transaction contains an OpReturn output which indicates the type and carries the hash of the proposal payload data.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

<big>OpReturn data:</big>

* 1 byte for tx type: 0x10
* 1 byte for version: 0x01
* 20 bytes for hash of proposal payload

The hash is created from the bytes of the proposal payload with tx ID set to null using protobuffer serialization. It is first hashed with Sha256 and then with Ripemd160 to get a 20 byte hash.

==== ''Example with a BSQ fee of 2 BSQ:'' ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.09950200 BTC change output
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Compensation request tx/Reimbursement request tx</big> ===

Compensation request tx and reimbursement request txs are technically the same and inherit the properties of a proposal tx but have some additional requirements. They add a BTC output which will be interpreted as a BSQ output at the vote result phase in case the request is accepted by voting.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs BSQ issuance and miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [1]: Issuance candidate output; before voted ok it is BTC afterwards newly issued BSQ
* Outputs [0-1]: BTC change output
* Outputs [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: Compensation request tx: 0x11 / Reimbursement request: 0x12
* 1 byte for version: 0x01
* 20 bytes for hash of request payload

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.00500000 BTC (5000 BSQ after positive voting)
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Blind vote tx</big> ===

The blind vote tx contains the hash of the blind vote payload and uses the vote stake as input. The stake is blocked from spending during this phase and is only unlocked by the vote reveal tx. If another transaction spends the stake, the blind vote becomes invalid. The blind vote requires a fee in BSQ.

* Inputs [1-n]: BSQ inputs for BSQ fee + stake
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output of stake
* Output [0-1] Optional BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x13
* 1 byte for version: 0x01
* 0 bytes for hash of encrypted votes

To create the encrypted votes we use following data:-

* Secret key: 128 bit AES key.
* List of a tuple of proposal Tx IDs + vote, sorted by tx ID. Only valid proposals of current cycle are included.

We use protobuffer serialisation for the bytes which will be encrypted with the secret key.

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

* Input 1: 8000.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ / 0.00700000 BTC
* Output 2: 998 BSQ change output
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Vote reveal tx</big> ===

The vote reveal tx consumes the stake output from the blind vote tx as the only BSQ input. It does not require a BSQ fee.

In the OpReturn data we add the secret key for decrypting our blind vote and a hash of the blind vote list to ensure consensus of the P2P network data used in voting. This hash will be used in the vote result phase to determine a majority in case different users get a different list of blind votes, which would lead to different vote results, and therefore cause consensus failures.

* Input [1]: BSQ input → stake output of blind vote tx
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ output (unlocked stake)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x14
* 1 byte for version: 0x01
* 20 bytes for hash of blind vote list
* 16 bytes secretKey

The hash of the blind vote list is made using all blind vote payload data received in the cycle and sorted by blind vote tx ID. The secretKey is the encoded byte representation of the secret key.

==== Example with 7000 BSQ stake: ====

* Input 1: 7000 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ
* Output 2: 0.09950000 BTC
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Lockup tx</big> ===

The lock tx can be use for locking up funds for a bonded role or for bonded reputation: a certain amount of BSQ is locked for a defined lock time (in blocks). Only an unlock tx can unlock locked funds. Once the unlock tx is confirmed, the lock time will be used to determine when the funds can be used in a normal transaction again. While funds are locked, they cannot be moved, or they are invalidated. While funds are locked, or are in an unlocking state, funds can be confiscated by voting.

* Inputs [1-n]: BSQ inputs
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Locked up BSQ
* Outputs [0-1]: BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

<big>''OpReturn data:''</big>

* 1 byte for tx type: 0x15
* 1 byte for version: 0x01
* 1 byte for lockup reason (bonded role 0x01, reputation 0x02)
* 2 bytes for lock time (see: bisq.common.util.Utilities.integerToByteArray for encoding)
* 20 bytes for hash

The hash in case of a bonded role is created from immutable data of the bonded role. Currently we use hashCode but that should be changed to a cryptographic hash. The hash for a reputation is derived from a salt. The salt is by default a random string as hex or can be any string defined by the user.

==== Example with locking up 4000 BSQ: ====

* Input 1: 6000 BSQ
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ lockup
* Output 1: 2000 BSQ change output
* Output 2: 0.09950000 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 BTC

=== <big>Unlock tx</big> ===

The unlock tx takes the lockup tx output and use the lock time encoded in the OpReturn to determine the unlock time. The BSQ output cannot be used in another tx until the lock time is over. During that time it is in the unlocking state. Afterwards it is in the unlocked state and can be spent like any normal BSQ output.

* Input [1]: BSQ input from lockup tx lockup output (output index 0)
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ unlock output
* Outputs [0-1]: BTC change output
* Mining fee: BTC mining fee

==== Example with unlocking 4000 BSQ: ====

* Input 1: 4000 BSQ (from lockup tx output)
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ unlocking/unlocked state
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Asset listing fee tx</big> ===

The asset listing fee tx is used for paying listing fees for an asset. The ticker symbol of the asset is specified in the OpReturn data to bind the tx to a specific asset. If the BSQ fee is more than the required mining fee, we do not use a BTC input, and add the remaining BTC to the BTC output.

* Inputs [1-n]: BSQ inputs for listing fee
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of ticker symbol

We take the bytes of the ticker symbol as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with a BSQ fee of 20 BSQ: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

=== <big>Proof of burn tx</big> ===

A user can put the hash of an arbitrary string (pre-image) into a proof of burn tx and burn a specified amount of BSQ. He can later use the pre-image to prove to any party that he has created that hash. He can also sign any challenge message and the challenger can verify that he is the key holder of the first input used in that tx.

* Inputs [1-n]: BSQ inputs for burned amount
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - burned amount)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of pre image

We take the bytes of the pre-image as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with 20 BSQ burned: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

== <big>P2P network paylod</big> ==

Proposals and blind vote data are published over the Bisq P2P network. They must be published in the correct phase and cycle, otherwise they are considered invalid. Each node listens for these messages and persists the data locally. At startup, each node receives missing data from seed nodes. The corresponding tx ID is part of the data and is used to map the data to the transaction. The hash of the P2P network data is part of the OpReturn data in the transactions. In this way, we can verify that the mapping of a tx to the data is correct in both directions.

=== Temporary proposal payload ===

During the proposal phase the user can add and remove proposals. For removing we use the public key which was added when publishing a proposal and verify with a signature if the remove attempt is coming from the same owner. This is the same model as we use in other P2P network data like offer payloads. The data has a time to live of 60 days, and after that, it is removed from local storage.

=== Proposal payload ===

There are several different types of proposals:

* Compensation request
* Reimbursement requests
* Proposal for changing a parameter
* Proposal for a bonded role
* Proposal for confiscating a bond
* Generic proposal
* Proposal for removing an asset

The proposal contains the tx ID of the proposal transaction. When creating the transaction we add the 20-byte hash of the proposal data to the OpReturn data of the proposal tx. As the tx ID would be part of the proposal data and cannot be known before the tx is created, we leave it empty and set it afterwards. That way we get a mapping in both directions and can verify later that a proposal payload has a valid tx and that the tx data matches the proposal data.

During the break after the proposal phase, all nodes publish their proposal payload, which uses proposals from the temporary proposal payload. This data is now immutable and will be used for voting.

=== Blind vote payload ===

Blind vote data are published when the user makes his blind vote tx and are managed in the same way as proposal payloads (append-only data).

== <big>Governance</big> ==

Governances takes place in a periodic proposal and voting cycle. A cycle consists of 4 distinct phases.

=== Phases ===

Phases are defined by block height. Each phase is separated with a break to avoid issues with reorgs.

Here are the phases and the initial duration values (they can be changed by voting):

* Proposal phase (compensation requests, etc): 3600 blocks, about 25 days
* Break: 150 blocks
* Blind vote phase (approve/decline proposals): 450 blocks, about 3 days
* Break: 10 blocks
* Vote reveal phase: 450 blocks, about 3 days
* Break: 10 blocks
* Result phase: 10 blocks

The full cycle will last 4680 blocks which is about one month if one block takes an average of 10 minutes.

=== Proposal phase ===

Any BSQ stakeholder can publish a temporary proposal payload during the proposal phase, as well as remove their own proposals.

=== Blind Vote phase ===

A BSQ stakeholder can vote on any proposal with 3 options: accept, decline or ignore. Not voting on a proposal is the same as ignoring it.

The user defines how much stake they want to put into their vote. The higher the stake, the higher the vote weight compared to other voters. In addition to the stake, merit is added if the user has earned BSQ in previous cycles through accepted compensation requests. The merit value of each issuance ages linearly over time: it reaches 0 after 100 000 blocks (about 2 years). Aged accumulated merit is automatically added to the stake, and the sum of both is the vote weight.

When creating the blind vote tx, the user also publishes the blind vote payload. We use the same linking of tx ID and payload hash to map them together.

=== Vote reveal phase ===

Upon entering the vote reveal phase, each voter automatically publishes their vote reveal tx. There is no fee required for this transaction beside the miner fee. No P2P network data is published.

=== Vote result phase ===

In the vote result phase, all nodes calculate the vote result on all proposals and apply the result to the overall BSQ state.

This process uses the hash of the blind vote list from the vote reveal tx to determine the winning majority, in case users had different P2P network payloads of blind votes. The majority is calculated by stake (not merit) of the voters. Only if at least 80% of the network has the same hash is the cycle is valid, otherwise, all proposals and requests are considered rejected.

A proposal is considered accepted if the required quorum and threshold are reached. Quorum is the minimum amount of accumulated vote weight in BSQ which is required. Threshold is the relationship of accepted votes to total votes. Each proposal type has different quorum and threshold parameters which can be changed by voting, but threshold can never be below 50.01%.

In case a proposal’s data is not available, it is rejected. In case there are 2 accepted change parameter proposals for changing the same parameter to 2 different values, we reject both as it shows there is a social consensus issue in the DAO.

=== DAO Parameters ===

There are many different parameters which can be changed by voting. Trading fees, voting parameters (threshold and quorum), durations of the phases, and many more.

See the [https://github.com/bisq-network/bisq/blob/3854907c14357680038661c8153095a157efbc5d/core/src/main/java/bisq/core/dao/governance/param/Param.java Param class] for a complete list.

=== Bonded roles ===

All roles in the Bisq DAO which can potentially create severe damage are handled as bonded roles. To become a role owner one need to make a request for a bonded role, and once accepted by voting, the person needs to lock up the defined bond. The role only is only considered active when the bond is locked up.

The required amount for the bond is defined in [https://github.com/bisq-network/bisq/blob/497e202420940372fa1a344f64d375eac710d299/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java BondedRoleType enum]. The unlock time is 110 days for all roles.

In severe cases, BSQ stakeholders can make a proposal to confiscate a bond. This will require a very high threshold in voting and is considered an exceptional case which hopefully never happens.

Most bonded roles are connected to environments which cannot interact with the Bisq DAO directly. For example, the Github Admin role cannot be revoked by confiscating the role owner as the Bisq DAO has no power over GitHub. The only exceptions are mediators and arbitrators, since people can be verified as valid bonded role owners before they are used for dispute resolution. This is not implemented yet and will be part of the new trade protocol update in the next few months.

=== Bonded reputation ===

Similar to bonded roles, a user can lock up a bond to prove reputation. There is no concrete use case for this in Bisq at the moment, but we might use it in the future for new forms of trade protocols which are based on bonded reputation.

=== Asset listing fee ===

Assets added to Bisq need to gain enough traders to reach a minimum trade volume over a certain time period. These parameters are DAO parameters and can be changed by voting. If an asset does not satisfy these parameters, such as trading volume thresholds, it will be removed from the list of assets when creating an altcoin payment account or selecting the preferred currencies in the software preferences.

Anyone can pay a fee in BSQ to gain access to a trial period where requirements to reach trade volume thresholds are lifted. Usually the coin issuers do this, but it can be done by anyone interested in trading a particular asset. The fee is initially 1 BSQ per day for a trial period, with a minimum of 30 days. The fee can be changed by voting.

If an asset gets removed by a <code>Remove Asset Proposal</code>, it can no longer be reactivated by the listing fee. Listing fees already paid are lost in this case.

=== Proof of burn ===

This advanced feature does not have a concrete use at the moment, but might be used in the future. Burning BSQ can be used as a form of reputation. If one is willing to burn some money, and can use that proof for other activities (e.g. securing a trade), they might be interested that this form of reputation by burning BSQ will not become pointless in case he was publicly proven as scammer. The user can prove that he was the originator of the transaction by providing the pre-image to a hash, which gets added to the OpReturn data and he can sign any challenge message to prove he had funded the transaction. We use the EC key from the first input for the signature.

== <big>Disclaimer</big> ==

{{Admonition Warn|This document does not cover all details and cannot be used as basis for implementation of BSQ features or for creating self-crafted transactions. The source code is the only real specification. It is NOT recommended to create custom BSQ transactions, as tiny mistakes can lead to destroyed BSQ. Bisq developers will not be concerned with transactions which might be valid with the current rule set but which have not been created by the Bisq application. In the future, updated rules might become more strict and might break such externally-created transactions. Requirements for backward compatibility will only consider use cases and tx structures created by the Bisq application.

Please note that currently it is not recommended to send BSQ to a hardware wallet. Handling the miner fee might cause invalidation of the BSQ funds or cause losses if precious BSQ is used to pay the miner fee. We will publish some instructions on how to do this in a safe way soon.}}

DAO technical overview

2020-09-28T15:37:51Z

Bayer: /* Vote reveal tx */

DAO technical overview

2020-09-28T15:37:36Z

Bayer: /* Lockup tx */

<big>'''''<big>WORK IN PROGRESS</big>'''''</big><big> This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===
A proposal transaction contains an OpReturn output which indicates the type and carries the hash of the proposal payload data.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

<big>OpReturn data:</big>

* 1 byte for tx type: 0x10
* 1 byte for version: 0x01
* 20 bytes for hash of proposal payload

The hash is created from the bytes of the proposal payload with tx ID set to null using protobuffer serialization. It is first hashed with Sha256 and then with Ripemd160 to get a 20 byte hash.

==== ''Example with a BSQ fee of 2 BSQ:'' ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.09950200 BTC change output
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Compensation request tx/Reimbursement request tx</big> ===

Compensation request tx and reimbursement request txs are technically the same and inherit the properties of a proposal tx but have some additional requirements. They add a BTC output which will be interpreted as a BSQ output at the vote result phase in case the request is accepted by voting.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs BSQ issuance and miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [1]: Issuance candidate output; before voted ok it is BTC afterwards newly issued BSQ
* Outputs [0-1]: BTC change output
* Outputs [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: Compensation request tx: 0x11 / Reimbursement request: 0x12
* 1 byte for version: 0x01
* 20 bytes for hash of request payload

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.00500000 BTC (5000 BSQ after positive voting)
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Blind vote tx</big> ===

The blind vote tx contains the hash of the blind vote payload and uses the vote stake as input. The stake is blocked from spending during this phase and is only unlocked by the vote reveal tx. If another transaction spends the stake, the blind vote becomes invalid. The blind vote requires a fee in BSQ.

* Inputs [1-n]: BSQ inputs for BSQ fee + stake
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output of stake
* Output [0-1] Optional BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x13
* 1 byte for version: 0x01
* 0 bytes for hash of encrypted votes

To create the encrypted votes we use following data:-

* Secret key: 128 bit AES key.
* List of a tuple of proposal Tx IDs + vote, sorted by tx ID. Only valid proposals of current cycle are included.

We use protobuffer serialisation for the bytes which will be encrypted with the secret key.

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

* Input 1: 8000.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ / 0.00700000 BTC
* Output 2: 998 BSQ change output
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Vote reveal tx</big> ===

The vote reveal tx consumes the stake output from the blind vote tx as the only BSQ input. It does not require a BSQ fee.

In the OpReturn data we add the secret key for decrypting our blind vote and a hash of the blind vote list to ensure consensus of the P2P network data used in voting. This hash will be used in the vote result phase to determine a majority in case different users get a different list of blind votes, which would lead to different vote results, and therefore cause consensus failures.

* Input [1]: BSQ input → stake output of blind vote tx
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ output (unlocked stake)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x14
* 1 byte for version: 0x01
* 20 bytes for hash of blind vote list
* 16 bytes secretKey

'''The hash of the blind vote list is made using all blind vote payload data received in the cycle and sorted by blind vote tx ID. The secretKey is the encoded byte representation of the secret key.'''

==== Example with 7000 BSQ stake: ====

* Input 1: 7000 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ
* Output 2: 0.09950000 BTC
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Lockup tx</big> ===

The lock tx can be use for locking up funds for a bonded role or for bonded reputation: a certain amount of BSQ is locked for a defined lock time (in blocks). Only an unlock tx can unlock locked funds. Once the unlock tx is confirmed, the lock time will be used to determine when the funds can be used in a normal transaction again. While funds are locked, they cannot be moved, or they are invalidated. While funds are locked, or are in an unlocking state, funds can be confiscated by voting.

* Inputs [1-n]: BSQ inputs
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Locked up BSQ
* Outputs [0-1]: BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

<big>''OpReturn data:''</big>

* 1 byte for tx type: 0x15
* 1 byte for version: 0x01
* 1 byte for lockup reason (bonded role 0x01, reputation 0x02)
* 2 bytes for lock time (see: bisq.common.util.Utilities.integerToByteArray for encoding)
* 20 bytes for hash

The hash in case of a bonded role is created from immutable data of the bonded role. Currently we use hashCode but that should be changed to a cryptographic hash. The hash for a reputation is derived from a salt. The salt is by default a random string as hex or can be any string defined by the user.

==== Example with locking up 4000 BSQ: ====

* Input 1: 6000 BSQ
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ lockup
* Output 1: 2000 BSQ change output
* Output 2: 0.09950000 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 BTC

=== <big>Unlock tx</big> ===

The unlock tx takes the lockup tx output and use the lock time encoded in the OpReturn to determine the unlock time. The BSQ output cannot be used in another tx until the lock time is over. During that time it is in the unlocking state. Afterwards it is in the unlocked state and can be spent like any normal BSQ output.

* Input [1]: BSQ input from lockup tx lockup output (output index 0)
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ unlock output
* Outputs [0-1]: BTC change output
* Mining fee: BTC mining fee

==== Example with unlocking 4000 BSQ: ====

* Input 1: 4000 BSQ (from lockup tx output)
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ unlocking/unlocked state
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Asset listing fee tx</big> ===

The asset listing fee tx is used for paying listing fees for an asset. The ticker symbol of the asset is specified in the OpReturn data to bind the tx to a specific asset. If the BSQ fee is more than the required mining fee, we do not use a BTC input, and add the remaining BTC to the BTC output.

* Inputs [1-n]: BSQ inputs for listing fee
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of ticker symbol

We take the bytes of the ticker symbol as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with a BSQ fee of 20 BSQ: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

=== <big>Proof of burn tx</big> ===

A user can put the hash of an arbitrary string (pre-image) into a proof of burn tx and burn a specified amount of BSQ. He can later use the pre-image to prove to any party that he has created that hash. He can also sign any challenge message and the challenger can verify that he is the key holder of the first input used in that tx.

* Inputs [1-n]: BSQ inputs for burned amount
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - burned amount)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of pre image

We take the bytes of the pre-image as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with 20 BSQ burned: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

== <big>P2P network paylod</big> ==

Proposals and blind vote data are published over the Bisq P2P network. They must be published in the correct phase and cycle, otherwise they are considered invalid. Each node listens for these messages and persists the data locally. At startup, each node receives missing data from seed nodes. The corresponding tx ID is part of the data and is used to map the data to the transaction. The hash of the P2P network data is part of the OpReturn data in the transactions. In this way, we can verify that the mapping of a tx to the data is correct in both directions.

=== Temporary proposal payload ===

During the proposal phase the user can add and remove proposals. For removing we use the public key which was added when publishing a proposal and verify with a signature if the remove attempt is coming from the same owner. This is the same model as we use in other P2P network data like offer payloads. The data has a time to live of 60 days, and after that, it is removed from local storage.

=== Proposal payload ===

There are several different types of proposals:

* Compensation request
* Reimbursement requests
* Proposal for changing a parameter
* Proposal for a bonded role
* Proposal for confiscating a bond
* Generic proposal
* Proposal for removing an asset

The proposal contains the tx ID of the proposal transaction. When creating the transaction we add the 20-byte hash of the proposal data to the OpReturn data of the proposal tx. As the tx ID would be part of the proposal data and cannot be known before the tx is created, we leave it empty and set it afterwards. That way we get a mapping in both directions and can verify later that a proposal payload has a valid tx and that the tx data matches the proposal data.

During the break after the proposal phase, all nodes publish their proposal payload, which uses proposals from the temporary proposal payload. This data is now immutable and will be used for voting.

=== Blind vote payload ===

Blind vote data are published when the user makes his blind vote tx and are managed in the same way as proposal payloads (append-only data).

== <big>Governance</big> ==

Governances takes place in a periodic proposal and voting cycle. A cycle consists of 4 distinct phases.

=== Phases ===

Phases are defined by block height. Each phase is separated with a break to avoid issues with reorgs.

Here are the phases and the initial duration values (they can be changed by voting):

* Proposal phase (compensation requests, etc): 3600 blocks, about 25 days
* Break: 150 blocks
* Blind vote phase (approve/decline proposals): 450 blocks, about 3 days
* Break: 10 blocks
* Vote reveal phase: 450 blocks, about 3 days
* Break: 10 blocks
* Result phase: 10 blocks

The full cycle will last 4680 blocks which is about one month if one block takes an average of 10 minutes.

=== Proposal phase ===

Any BSQ stakeholder can publish a temporary proposal payload during the proposal phase, as well as remove their own proposals.

=== Blind Vote phase ===

A BSQ stakeholder can vote on any proposal with 3 options: accept, decline or ignore. Not voting on a proposal is the same as ignoring it.

The user defines how much stake they want to put into their vote. The higher the stake, the higher the vote weight compared to other voters. In addition to the stake, merit is added if the user has earned BSQ in previous cycles through accepted compensation requests. The merit value of each issuance ages linearly over time: it reaches 0 after 100 000 blocks (about 2 years). Aged accumulated merit is automatically added to the stake, and the sum of both is the vote weight.

When creating the blind vote tx, the user also publishes the blind vote payload. We use the same linking of tx ID and payload hash to map them together.

=== Vote reveal phase ===

Upon entering the vote reveal phase, each voter automatically publishes their vote reveal tx. There is no fee required for this transaction beside the miner fee. No P2P network data is published.

=== Vote result phase ===

In the vote result phase, all nodes calculate the vote result on all proposals and apply the result to the overall BSQ state.

This process uses the hash of the blind vote list from the vote reveal tx to determine the winning majority, in case users had different P2P network payloads of blind votes. The majority is calculated by stake (not merit) of the voters. Only if at least 80% of the network has the same hash is the cycle is valid, otherwise, all proposals and requests are considered rejected.

A proposal is considered accepted if the required quorum and threshold are reached. Quorum is the minimum amount of accumulated vote weight in BSQ which is required. Threshold is the relationship of accepted votes to total votes. Each proposal type has different quorum and threshold parameters which can be changed by voting, but threshold can never be below 50.01%.

In case a proposal’s data is not available, it is rejected. In case there are 2 accepted change parameter proposals for changing the same parameter to 2 different values, we reject both as it shows there is a social consensus issue in the DAO.

=== DAO Parameters ===

There are many different parameters which can be changed by voting. Trading fees, voting parameters (threshold and quorum), durations of the phases, and many more.

See the [https://github.com/bisq-network/bisq/blob/3854907c14357680038661c8153095a157efbc5d/core/src/main/java/bisq/core/dao/governance/param/Param.java Param class] for a complete list.

=== Bonded roles ===

All roles in the Bisq DAO which can potentially create severe damage are handled as bonded roles. To become a role owner one need to make a request for a bonded role, and once accepted by voting, the person needs to lock up the defined bond. The role only is only considered active when the bond is locked up.

The required amount for the bond is defined in [https://github.com/bisq-network/bisq/blob/497e202420940372fa1a344f64d375eac710d299/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java BondedRoleType enum]. The unlock time is 110 days for all roles.

In severe cases, BSQ stakeholders can make a proposal to confiscate a bond. This will require a very high threshold in voting and is considered an exceptional case which hopefully never happens.

Most bonded roles are connected to environments which cannot interact with the Bisq DAO directly. For example, the Github Admin role cannot be revoked by confiscating the role owner as the Bisq DAO has no power over GitHub. The only exceptions are mediators and arbitrators, since people can be verified as valid bonded role owners before they are used for dispute resolution. This is not implemented yet and will be part of the new trade protocol update in the next few months.

=== Bonded reputation ===

Similar to bonded roles, a user can lock up a bond to prove reputation. There is no concrete use case for this in Bisq at the moment, but we might use it in the future for new forms of trade protocols which are based on bonded reputation.

=== Asset listing fee ===

Assets added to Bisq need to gain enough traders to reach a minimum trade volume over a certain time period. These parameters are DAO parameters and can be changed by voting. If an asset does not satisfy these parameters, such as trading volume thresholds, it will be removed from the list of assets when creating an altcoin payment account or selecting the preferred currencies in the software preferences.

Anyone can pay a fee in BSQ to gain access to a trial period where requirements to reach trade volume thresholds are lifted. Usually the coin issuers do this, but it can be done by anyone interested in trading a particular asset. The fee is initially 1 BSQ per day for a trial period, with a minimum of 30 days. The fee can be changed by voting.

If an asset gets removed by a <code>Remove Asset Proposal</code>, it can no longer be reactivated by the listing fee. Listing fees already paid are lost in this case.

=== Proof of burn ===

This advanced feature does not have a concrete use at the moment, but might be used in the future. Burning BSQ can be used as a form of reputation. If one is willing to burn some money, and can use that proof for other activities (e.g. securing a trade), they might be interested that this form of reputation by burning BSQ will not become pointless in case he was publicly proven as scammer. The user can prove that he was the originator of the transaction by providing the pre-image to a hash, which gets added to the OpReturn data and he can sign any challenge message to prove he had funded the transaction. We use the EC key from the first input for the signature.

== <big>Disclaimer</big> ==

{{Admonition Warn|This document does not cover all details and cannot be used as basis for implementation of BSQ features or for creating self-crafted transactions. The source code is the only real specification. It is NOT recommended to create custom BSQ transactions, as tiny mistakes can lead to destroyed BSQ. Bisq developers will not be concerned with transactions which might be valid with the current rule set but which have not been created by the Bisq application. In the future, updated rules might become more strict and might break such externally-created transactions. Requirements for backward compatibility will only consider use cases and tx structures created by the Bisq application.

Please note that currently it is not recommended to send BSQ to a hardware wallet. Handling the miner fee might cause invalidation of the BSQ funds or cause losses if precious BSQ is used to pay the miner fee. We will publish some instructions on how to do this in a safe way soon.}}

DAO technical overview

2020-09-28T15:37:07Z

Bayer:

<big>'''''<big>WORK IN PROGRESS</big>'''''</big><big> This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===
A proposal transaction contains an OpReturn output which indicates the type and carries the hash of the proposal payload data.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

<big>OpReturn data:</big>

* 1 byte for tx type: 0x10
* 1 byte for version: 0x01
* 20 bytes for hash of proposal payload

The hash is created from the bytes of the proposal payload with tx ID set to null using protobuffer serialization. It is first hashed with Sha256 and then with Ripemd160 to get a 20 byte hash.

==== ''Example with a BSQ fee of 2 BSQ:'' ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.09950200 BTC change output
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Compensation request tx/Reimbursement request tx</big> ===

Compensation request tx and reimbursement request txs are technically the same and inherit the properties of a proposal tx but have some additional requirements. They add a BTC output which will be interpreted as a BSQ output at the vote result phase in case the request is accepted by voting.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs BSQ issuance and miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [1]: Issuance candidate output; before voted ok it is BTC afterwards newly issued BSQ
* Outputs [0-1]: BTC change output
* Outputs [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: Compensation request tx: 0x11 / Reimbursement request: 0x12
* 1 byte for version: 0x01
* 20 bytes for hash of request payload

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.00500000 BTC (5000 BSQ after positive voting)
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Blind vote tx</big> ===

The blind vote tx contains the hash of the blind vote payload and uses the vote stake as input. The stake is blocked from spending during this phase and is only unlocked by the vote reveal tx. If another transaction spends the stake, the blind vote becomes invalid. The blind vote requires a fee in BSQ.

* Inputs [1-n]: BSQ inputs for BSQ fee + stake
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output of stake
* Output [0-1] Optional BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x13
* 1 byte for version: 0x01
* 0 bytes for hash of encrypted votes

To create the encrypted votes we use following data:-

* Secret key: 128 bit AES key.
* List of a tuple of proposal Tx IDs + vote, sorted by tx ID. Only valid proposals of current cycle are included.

We use protobuffer serialisation for the bytes which will be encrypted with the secret key.

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

* Input 1: 8000.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ / 0.00700000 BTC
* Output 2: 998 BSQ change output
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Vote reveal tx</big> ===

The vote reveal tx consumes the stake output from the blind vote tx as the only BSQ input. It does not require a BSQ fee.

In the OpReturn data we add the secret key for decrypting our blind vote and a hash of the blind vote list to ensure consensus of the P2P network data used in voting. This hash will be used in the vote result phase to determine a majority in case different users get a different list of blind votes, which would lead to different vote results, and therefore cause consensus failures.

* Input [1]: BSQ input → stake output of blind vote tx
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ output (unlocked stake)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x14
* 1 byte for version: 0x01
* 20 bytes for hash of blind vote list
* 16 bytes secretKey

'''The hash of the blind vote list is made using all blind vote payload data received in the cycle and sorted by blind vote tx ID. The secretKey is the encoded byte representation of the secret key.'''

==== Example with 7000 BSQ stake: ====

* Input 1: 7000 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ
* Output 2: 0.09950000 BTC
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Lockup tx</big> ===

The lock tx can be use for locking up funds for a bonded role or for bonded reputation: a certain amount of BSQ is locked for a defined lock time (in blocks). Only an unlock tx can unlock locked funds. Once the unlock tx is confirmed, the lock time will be used to determine when the funds can be used in a normal transaction again. While funds are locked, they cannot be moved, or they are invalidated. While funds are locked, or are in an unlocking state, funds can be confiscated by voting.

* Inputs [1-n]: BSQ inputs
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Locked up BSQ
* Outputs [0-1]: BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

<big>''OpReturn data:''</big>

* 1 byte for tx type: 0x15
* 1 byte for version: 0x01
* 1 byte for lockup reason (bonded role 0x01, reputation 0x02)
* 2 bytes for lock time (see: bisq.common.util.Utilities.integerToByteArray for encoding)
* 20 bytes for hash

'''The hash in case of a bonded role is created from immutable data of the bonded role. Currently we use hashCode but that should be changed to a cryptographic hash. The hash for a reputation is derived from a salt. The salt is by default a random string as hex or can be any string defined by the user.'''

==== Example with locking up 4000 BSQ: ====

* Input 1: 6000 BSQ
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ lockup
* Output 1: 2000 BSQ change output
* Output 2: 0.09950000 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 BTC

=== <big>Unlock tx</big> ===

The unlock tx takes the lockup tx output and use the lock time encoded in the OpReturn to determine the unlock time. The BSQ output cannot be used in another tx until the lock time is over. During that time it is in the unlocking state. Afterwards it is in the unlocked state and can be spent like any normal BSQ output.

* Input [1]: BSQ input from lockup tx lockup output (output index 0)
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ unlock output
* Outputs [0-1]: BTC change output
* Mining fee: BTC mining fee

==== Example with unlocking 4000 BSQ: ====

* Input 1: 4000 BSQ (from lockup tx output)
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ unlocking/unlocked state
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Asset listing fee tx</big> ===

The asset listing fee tx is used for paying listing fees for an asset. The ticker symbol of the asset is specified in the OpReturn data to bind the tx to a specific asset. If the BSQ fee is more than the required mining fee, we do not use a BTC input, and add the remaining BTC to the BTC output.

* Inputs [1-n]: BSQ inputs for listing fee
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of ticker symbol

We take the bytes of the ticker symbol as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with a BSQ fee of 20 BSQ: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

=== <big>Proof of burn tx</big> ===

A user can put the hash of an arbitrary string (pre-image) into a proof of burn tx and burn a specified amount of BSQ. He can later use the pre-image to prove to any party that he has created that hash. He can also sign any challenge message and the challenger can verify that he is the key holder of the first input used in that tx.

* Inputs [1-n]: BSQ inputs for burned amount
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - burned amount)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of pre image

We take the bytes of the pre-image as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with 20 BSQ burned: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

== <big>P2P network paylod</big> ==

Proposals and blind vote data are published over the Bisq P2P network. They must be published in the correct phase and cycle, otherwise they are considered invalid. Each node listens for these messages and persists the data locally. At startup, each node receives missing data from seed nodes. The corresponding tx ID is part of the data and is used to map the data to the transaction. The hash of the P2P network data is part of the OpReturn data in the transactions. In this way, we can verify that the mapping of a tx to the data is correct in both directions.

=== Temporary proposal payload ===

During the proposal phase the user can add and remove proposals. For removing we use the public key which was added when publishing a proposal and verify with a signature if the remove attempt is coming from the same owner. This is the same model as we use in other P2P network data like offer payloads. The data has a time to live of 60 days, and after that, it is removed from local storage.

=== Proposal payload ===

There are several different types of proposals:

* Compensation request
* Reimbursement requests
* Proposal for changing a parameter
* Proposal for a bonded role
* Proposal for confiscating a bond
* Generic proposal
* Proposal for removing an asset

The proposal contains the tx ID of the proposal transaction. When creating the transaction we add the 20-byte hash of the proposal data to the OpReturn data of the proposal tx. As the tx ID would be part of the proposal data and cannot be known before the tx is created, we leave it empty and set it afterwards. That way we get a mapping in both directions and can verify later that a proposal payload has a valid tx and that the tx data matches the proposal data.

During the break after the proposal phase, all nodes publish their proposal payload, which uses proposals from the temporary proposal payload. This data is now immutable and will be used for voting.

=== Blind vote payload ===

Blind vote data are published when the user makes his blind vote tx and are managed in the same way as proposal payloads (append-only data).

== <big>Governance</big> ==

Governances takes place in a periodic proposal and voting cycle. A cycle consists of 4 distinct phases.

=== Phases ===

Phases are defined by block height. Each phase is separated with a break to avoid issues with reorgs.

Here are the phases and the initial duration values (they can be changed by voting):

* Proposal phase (compensation requests, etc): 3600 blocks, about 25 days
* Break: 150 blocks
* Blind vote phase (approve/decline proposals): 450 blocks, about 3 days
* Break: 10 blocks
* Vote reveal phase: 450 blocks, about 3 days
* Break: 10 blocks
* Result phase: 10 blocks

The full cycle will last 4680 blocks which is about one month if one block takes an average of 10 minutes.

=== Proposal phase ===

Any BSQ stakeholder can publish a temporary proposal payload during the proposal phase, as well as remove their own proposals.

=== Blind Vote phase ===

A BSQ stakeholder can vote on any proposal with 3 options: accept, decline or ignore. Not voting on a proposal is the same as ignoring it.

The user defines how much stake they want to put into their vote. The higher the stake, the higher the vote weight compared to other voters. In addition to the stake, merit is added if the user has earned BSQ in previous cycles through accepted compensation requests. The merit value of each issuance ages linearly over time: it reaches 0 after 100 000 blocks (about 2 years). Aged accumulated merit is automatically added to the stake, and the sum of both is the vote weight.

When creating the blind vote tx, the user also publishes the blind vote payload. We use the same linking of tx ID and payload hash to map them together.

=== Vote reveal phase ===

Upon entering the vote reveal phase, each voter automatically publishes their vote reveal tx. There is no fee required for this transaction beside the miner fee. No P2P network data is published.

=== Vote result phase ===

In the vote result phase, all nodes calculate the vote result on all proposals and apply the result to the overall BSQ state.

This process uses the hash of the blind vote list from the vote reveal tx to determine the winning majority, in case users had different P2P network payloads of blind votes. The majority is calculated by stake (not merit) of the voters. Only if at least 80% of the network has the same hash is the cycle is valid, otherwise, all proposals and requests are considered rejected.

A proposal is considered accepted if the required quorum and threshold are reached. Quorum is the minimum amount of accumulated vote weight in BSQ which is required. Threshold is the relationship of accepted votes to total votes. Each proposal type has different quorum and threshold parameters which can be changed by voting, but threshold can never be below 50.01%.

In case a proposal’s data is not available, it is rejected. In case there are 2 accepted change parameter proposals for changing the same parameter to 2 different values, we reject both as it shows there is a social consensus issue in the DAO.

=== DAO Parameters ===

There are many different parameters which can be changed by voting. Trading fees, voting parameters (threshold and quorum), durations of the phases, and many more.

See the [https://github.com/bisq-network/bisq/blob/3854907c14357680038661c8153095a157efbc5d/core/src/main/java/bisq/core/dao/governance/param/Param.java Param class] for a complete list.

=== Bonded roles ===

All roles in the Bisq DAO which can potentially create severe damage are handled as bonded roles. To become a role owner one need to make a request for a bonded role, and once accepted by voting, the person needs to lock up the defined bond. The role only is only considered active when the bond is locked up.

The required amount for the bond is defined in [https://github.com/bisq-network/bisq/blob/497e202420940372fa1a344f64d375eac710d299/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java BondedRoleType enum]. The unlock time is 110 days for all roles.

In severe cases, BSQ stakeholders can make a proposal to confiscate a bond. This will require a very high threshold in voting and is considered an exceptional case which hopefully never happens.

Most bonded roles are connected to environments which cannot interact with the Bisq DAO directly. For example, the Github Admin role cannot be revoked by confiscating the role owner as the Bisq DAO has no power over GitHub. The only exceptions are mediators and arbitrators, since people can be verified as valid bonded role owners before they are used for dispute resolution. This is not implemented yet and will be part of the new trade protocol update in the next few months.

=== Bonded reputation ===

Similar to bonded roles, a user can lock up a bond to prove reputation. There is no concrete use case for this in Bisq at the moment, but we might use it in the future for new forms of trade protocols which are based on bonded reputation.

=== Asset listing fee ===

Assets added to Bisq need to gain enough traders to reach a minimum trade volume over a certain time period. These parameters are DAO parameters and can be changed by voting. If an asset does not satisfy these parameters, such as trading volume thresholds, it will be removed from the list of assets when creating an altcoin payment account or selecting the preferred currencies in the software preferences.

Anyone can pay a fee in BSQ to gain access to a trial period where requirements to reach trade volume thresholds are lifted. Usually the coin issuers do this, but it can be done by anyone interested in trading a particular asset. The fee is initially 1 BSQ per day for a trial period, with a minimum of 30 days. The fee can be changed by voting.

If an asset gets removed by a <code>Remove Asset Proposal</code>, it can no longer be reactivated by the listing fee. Listing fees already paid are lost in this case.

=== Proof of burn ===

This advanced feature does not have a concrete use at the moment, but might be used in the future. Burning BSQ can be used as a form of reputation. If one is willing to burn some money, and can use that proof for other activities (e.g. securing a trade), they might be interested that this form of reputation by burning BSQ will not become pointless in case he was publicly proven as scammer. The user can prove that he was the originator of the transaction by providing the pre-image to a hash, which gets added to the OpReturn data and he can sign any challenge message to prove he had funded the transaction. We use the EC key from the first input for the signature.

== <big>Disclaimer</big> ==

{{Admonition Warn|This document does not cover all details and cannot be used as basis for implementation of BSQ features or for creating self-crafted transactions. The source code is the only real specification. It is NOT recommended to create custom BSQ transactions, as tiny mistakes can lead to destroyed BSQ. Bisq developers will not be concerned with transactions which might be valid with the current rule set but which have not been created by the Bisq application. In the future, updated rules might become more strict and might break such externally-created transactions. Requirements for backward compatibility will only consider use cases and tx structures created by the Bisq application.

Please note that currently it is not recommended to send BSQ to a hardware wallet. Handling the miner fee might cause invalidation of the BSQ funds or cause losses if precious BSQ is used to pay the miner fee. We will publish some instructions on how to do this in a safe way soon.}}

DAO technical overview

2020-09-28T15:36:17Z

Bayer:

<big>'''''<big>WORK IN PROGRESS</big>'''''</big><big> This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===
A proposal transaction contains an OpReturn output which indicates the type and carries the hash of the proposal payload data.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

<big>OpReturn data:</big>

* 1 byte for tx type: 0x10
* 1 byte for version: 0x01
* 20 bytes for hash of proposal payload

The hash is created from the bytes of the proposal payload with tx ID set to null using protobuffer serialization. It is first hashed with Sha256 and then with Ripemd160 to get a 20 byte hash.

==== ''Example with a BSQ fee of 2 BSQ:'' ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.09950200 BTC change output
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Compensation request tx/Reimbursement request tx</big> ===

Compensation request tx and reimbursement request txs are technically the same and inherit the properties of a proposal tx but have some additional requirements. They add a BTC output which will be interpreted as a BSQ output at the vote result phase in case the request is accepted by voting.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs BSQ issuance and miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [1]: Issuance candidate output; before voted ok it is BTC afterwards newly issued BSQ
* Outputs [0-1]: BTC change output
* Outputs [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: Compensation request tx: 0x11 / Reimbursement request: 0x12
* 1 byte for version: 0x01
* 20 bytes for hash of request payload

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.00500000 BTC (5000 BSQ after positive voting)
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Blind vote tx</big> ===

The blind vote tx contains the hash of the blind vote payload and uses the vote stake as input. The stake is blocked from spending during this phase and is only unlocked by the vote reveal tx. If another transaction spends the stake, the blind vote becomes invalid. The blind vote requires a fee in BSQ.

* Inputs [1-n]: BSQ inputs for BSQ fee + stake
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output of stake
* Output [0-1] Optional BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x13
* 1 byte for version: 0x01
* 0 bytes for hash of encrypted votes

To create the encrypted votes we use following data:-

* Secret key: 128 bit AES key.
* List of a tuple of proposal Tx IDs + vote, sorted by tx ID. Only valid proposals of current cycle are included.

We use protobuffer serialisation for the bytes which will be encrypted with the secret key.

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

* Input 1: 8000.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ / 0.00700000 BTC
* Output 2: 998 BSQ change output
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Vote reveal tx</big> ===

The vote reveal tx consumes the stake output from the blind vote tx as the only BSQ input. It does not require a BSQ fee.

In the OpReturn data we add the secret key for decrypting our blind vote and a hash of the blind vote list to ensure consensus of the P2P network data used in voting. This hash will be used in the vote result phase to determine a majority in case different users get a different list of blind votes, which would lead to different vote results, and therefore cause consensus failures.

* Input [1]: BSQ input → stake output of blind vote tx
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ output (unlocked stake)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x14
* 1 byte for version: 0x01
* 20 bytes for hash of blind vote list
* 16 bytes secretKey

'''The hash of the blind vote list is made using all blind vote payload data received in the cycle and sorted by blind vote tx ID. The secretKey is the encoded byte representation of the secret key.'''

==== Example with 7000 BSQ stake: ====

* Input 1: 7000 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ
* Output 2: 0.09950000 BTC
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Lockup tx</big> ===

The lock tx can be use for locking up funds for a bonded role or for bonded reputation: a certain amount of BSQ is locked for a defined lock time (in blocks). Only an unlock tx can unlock locked funds. Once the unlock tx is confirmed, the lock time will be used to determine when the funds can be used in a normal transaction again. While funds are locked, they cannot be moved, or they are invalidated. While funds are locked, or are in an unlocking state, funds can be confiscated by voting.

* Inputs [1-n]: BSQ inputs
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Locked up BSQ
* Outputs [0-1]: BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

<big>''OpReturn data:''</big>

* 1 byte for tx type: 0x15
* 1 byte for version: 0x01
* 1 byte for lockup reason (bonded role 0x01, reputation 0x02)
* 2 bytes for lock time (see: bisq.common.util.Utilities.integerToByteArray for encoding)
* 20 bytes for hash

'''The hash in case of a bonded role is created from immutable data of the bonded role. Currently we use hashCode but that should be changed to a cryptographic hash. The hash for a reputation is derived from a salt. The salt is by default a random string as hex or can be any string defined by the user.'''

==== Example with locking up 4000 BSQ: ====

* Input 1: 6000 BSQ
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ lockup
* Output 1: 2000 BSQ change output
* Output 2: 0.09950000 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 BTC

=== <big>Unlock tx</big> ===

The unlock tx takes the lockup tx output and use the lock time encoded in the OpReturn to determine the unlock time. The BSQ output cannot be used in another tx until the lock time is over. During that time it is in the unlocking state. Afterwards it is in the unlocked state and can be spent like any normal BSQ output.

* Input [1]: BSQ input from lockup tx lockup output (output index 0)
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ unlock output
* Outputs [0-1]: BTC change output
* Mining fee: BTC mining fee

==== Example with unlocking 4000 BSQ: ====

* Input 1: 4000 BSQ (from lockup tx output)
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ unlocking/unlocked state
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Asset listing fee tx</big> ===

The asset listing fee tx is used for paying listing fees for an asset. The ticker symbol of the asset is specified in the OpReturn data to bind the tx to a specific asset. If the BSQ fee is more than the required mining fee, we do not use a BTC input, and add the remaining BTC to the BTC output.

* Inputs [1-n]: BSQ inputs for listing fee
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of ticker symbol

We take the bytes of the ticker symbol as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with a BSQ fee of 20 BSQ: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

=== <big>Proof of burn tx</big> ===

A user can put the hash of an arbitrary string (pre-image) into a proof of burn tx and burn a specified amount of BSQ. He can later use the pre-image to prove to any party that he has created that hash. He can also sign any challenge message and the challenger can verify that he is the key holder of the first input used in that tx.

* Inputs [1-n]: BSQ inputs for burned amount
* Inputs [0-n]: BTC inputs for miner fee
* Output [0-1]: BSQ change output (BSQ input - burned amount)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x16
* 1 byte for version: 0x01
* 20 bytes for hash of pre image

We take the bytes of the pre-image as UTF-8 string and hash it with Sha256 and then with Ripemd160.

==== Example with 20 BSQ burned: ====

* Input 1: 100.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 80 BSQ
* Output 2: 0.0997 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.0003 BTC + 0.00020000 BTC or 20 BSQ)

== <big>P2P network paylod</big> ==

Proposals and blind vote data are published over the Bisq P2P network. They must be published in the correct phase and cycle, otherwise they are considered invalid. Each node listens for these messages and persists the data locally. At startup, each node receives missing data from seed nodes. The corresponding tx ID is part of the data and is used to map the data to the transaction. The hash of the P2P network data is part of the OpReturn data in the transactions. In this way, we can verify that the mapping of a tx to the data is correct in both directions.

=== Temporary proposal payload ===

During the proposal phase the user can add and remove proposals. For removing we use the public key which was added when publishing a proposal and verify with a signature if the remove attempt is coming from the same owner. This is the same model as we use in other P2P network data like offer payloads. The data has a time to live of 60 days, and after that, it is removed from local storage.

=== Proposal payload ===

There are several different types of proposals:

* Compensation request
* Reimbursement requests
* Proposal for changing a parameter
* Proposal for a bonded role
* Proposal for confiscating a bond
* Generic proposal
* Proposal for removing an asset

The proposal contains the tx ID of the proposal transaction. When creating the transaction we add the 20-byte hash of the proposal data to the OpReturn data of the proposal tx. As the tx ID would be part of the proposal data and cannot be known before the tx is created, we leave it empty and set it afterwards. That way we get a mapping in both directions and can verify later that a proposal payload has a valid tx and that the tx data matches the proposal data.

During the break after the proposal phase, all nodes publish their proposal payload, which uses proposals from the temporary proposal payload. This data is now immutable and will be used for voting.

=== Blind vote payload ===

Blind vote data are published when the user makes his blind vote tx and are managed in the same way as proposal payloads (append-only data).

== <big>Governance</big> ==

Governances takes place in a periodic proposal and voting cycle. A cycle consists of 4 distinct phases.

=== Phases ===

Phases are defined by block height. Each phase is separated with a break to avoid issues with reorgs.

Here are the phases and the initial duration values (they can be changed by voting):

* Proposal phase (compensation requests, etc): 3600 blocks, about 25 days
* Break: 150 blocks
* Blind vote phase (approve/decline proposals): 450 blocks, about 3 days
* Break: 10 blocks
* Vote reveal phase: 450 blocks, about 3 days
* Break: 10 blocks
* Result phase: 10 blocks

The full cycle will last 4680 blocks which is about one month if one block takes an average of 10 minutes.

=== Proposal phase ===

Any BSQ stakeholder can publish a temporary proposal payload during the proposal phase, as well as remove their own proposals.

=== Blind Vote phase ===

A BSQ stakeholder can vote on any proposal with 3 options: accept, decline or ignore. Not voting on a proposal is the same as ignoring it.

The user defines how much stake they want to put into their vote. The higher the stake, the higher the vote weight compared to other voters. In addition to the stake, merit is added if the user has earned BSQ in previous cycles through accepted compensation requests. The merit value of each issuance ages linearly over time: it reaches 0 after 100 000 blocks (about 2 years). Aged accumulated merit is automatically added to the stake, and the sum of both is the vote weight.

When creating the blind vote tx, the user also publishes the blind vote payload. We use the same linking of tx ID and payload hash to map them together.

=== Vote reveal phase ===

Upon entering the vote reveal phase, each voter automatically publishes their vote reveal tx. There is no fee required for this transaction beside the miner fee. No P2P network data is published.

=== Vote result phase ===

In the vote result phase, all nodes calculate the vote result on all proposals and apply the result to the overall BSQ state.

This process uses the hash of the blind vote list from the vote reveal tx to determine the winning majority, in case users had different P2P network payloads of blind votes. The majority is calculated by stake (not merit) of the voters. Only if at least 80% of the network has the same hash is the cycle is valid, otherwise, all proposals and requests are considered rejected.

A proposal is considered accepted if the required quorum and threshold are reached. Quorum is the minimum amount of accumulated vote weight in BSQ which is required. Threshold is the relationship of accepted votes to total votes. Each proposal type has different quorum and threshold parameters which can be changed by voting, but threshold can never be below 50.01%.

In case a proposal’s data is not available, it is rejected. In case there are 2 accepted change parameter proposals for changing the same parameter to 2 different values, we reject both as it shows there is a social consensus issue in the DAO.

=== DAO Parameters ===

There are many different parameters which can be changed by voting. Trading fees, voting parameters (threshold and quorum), durations of the phases, and many more.

See the [https://github.com/bisq-network/bisq/blob/3854907c14357680038661c8153095a157efbc5d/core/src/main/java/bisq/core/dao/governance/param/Param.java Param class] for a complete list.

=== Bonded roles ===

All roles in the Bisq DAO which can potentially create severe damage are handled as bonded roles. To become a role owner one need to make a request for a bonded role, and once accepted by voting, the person needs to lock up the defined bond. The role only is only considered active when the bond is locked up.

The required amount for the bond is defined in [https://github.com/bisq-network/bisq/blob/497e202420940372fa1a344f64d375eac710d299/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java BondedRoleType enum]. The unlock time is 110 days for all roles.

In severe cases, BSQ stakeholders can make a proposal to confiscate a bond. This will require a very high threshold in voting and is considered an exceptional case which hopefully never happens.

Most bonded roles are connected to environments which cannot interact with the Bisq DAO directly. For example, the Github Admin role cannot be revoked by confiscating the role owner as the Bisq DAO has no power over GitHub. The only exceptions are mediators and arbitrators, since people can be verified as valid bonded role owners before they are used for dispute resolution. This is not implemented yet and will be part of the new trade protocol update in the next few months.

=== Bonded reputation ===

Similar to bonded roles, a user can lock up a bond to prove reputation. There is no concrete use case for this in Bisq at the moment, but we might use it in the future for new forms of trade protocols which are based on bonded reputation.

=== Asset listing fee ===

Assets added to Bisq need to gain enough traders to reach a minimum trade volume over a certain time period. These parameters are DAO parameters and can be changed by voting. If an asset does not satisfy these parameters, such as trading volume thresholds, it will be removed from the list of assets when creating an altcoin payment account or selecting the preferred currencies in the software preferences.

Anyone can pay a fee in BSQ to gain access to a trial period where requirements to reach trade volume thresholds are lifted. Usually the coin issuers do this, but it can be done by anyone interested in trading a particular asset. The fee is initially 1 BSQ per day for a trial period, with a minimum of 30 days. The fee can be changed by voting.

If an asset gets removed by a <code>Remove Asset Proposal</code>, it can no longer be reactivated by the listing fee. Listing fees already paid are lost in this case.

=== Proof of burn ===

This advanced feature does not have a concrete use at the moment, but might be used in the future. Burning BSQ can be used as a form of reputation. If one is willing to burn some money, and can use that proof for other activities (e.g. securing a trade), they might be interested that this form of reputation by burning BSQ will not become pointless in case he was publicly proven as scammer. The user can prove that he was the originator of the transaction by providing the pre-image to a hash, which gets added to the OpReturn data and he can sign any challenge message to prove he had funded the transaction. We use the EC key from the first input for the signature.

== <big>Disclaimer</big> ==

{{Admonition Warn|This document does not cover all details and cannot be used as basis for implementation of BSQ features or for creating self-crafted transactions. The source code is the only real specification. It is NOT recommended to create custom BSQ transactions, as tiny mistakes can lead to destroyed BSQ. Bisq developers will not be concerned with transactions which might be valid with the current rule set but which have not been created by the Bisq application. In the future, updated rules might become more strict and might break such externally-created transactions. Requirements for backward compatibility will only consider use cases and tx structures created by the Bisq application.

Please note that currently it is not recommended to send BSQ to a hardware wallet. Handling the miner fee might cause invalidation of the BSQ funds or cause losses if precious BSQ is used to pay the miner fee. We will publish some instructions on how to do this in a safe way soon.}}

DAO technical overview

2020-09-28T15:20:17Z

Bayer: /* Lockup tx */

<big>'''''<big>WORK IN PROGRESS</big>'''''</big><big> This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===
A proposal transaction contains an OpReturn output which indicates the type and carries the hash of the proposal payload data.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

<big>OpReturn data:</big>

* 1 byte for tx type: 0x10
* 1 byte for version: 0x01
* 20 bytes for hash of proposal payload

The hash is created from the bytes of the proposal payload with tx ID set to null using protobuffer serialization. It is first hashed with Sha256 and then with Ripemd160 to get a 20 byte hash.

==== ''Example with a BSQ fee of 2 BSQ:'' ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.09950200 BTC change output
* Output 3: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Compensation request tx/Reimbursement request tx</big> ===

Compensation request tx and reimbursement request txs are technically the same and inherit the properties of a proposal tx but have some additional requirements. They add a BTC output which will be interpreted as a BSQ output at the vote result phase in case the request is accepted by voting.

* Inputs [1-n]: BSQ inputs for BSQ fee
* Inputs [1-n]: BTC inputs BSQ issuance and miner fee
* Output [1]: Mandatory BSQ output (BSQ input - fee)
* Outputs [1]: Issuance candidate output; before voted ok it is BTC afterwards newly issued BSQ
* Outputs [0-1]: BTC change output
* Outputs [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: Compensation request tx: 0x11 / Reimbursement request: 0x12
* 1 byte for version: 0x01
* 20 bytes for hash of request payload

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 8 BSQ
* Output 2: 0.00500000 BTC (5000 BSQ after positive voting)
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Blind vote tx</big> ===

The blind vote tx contains the hash of the blind vote payload and uses the vote stake as input. The stake is blocked from spending during this phase and is only unlocked by the vote reveal tx. If another transaction spends the stake, the blind vote becomes invalid. The blind vote requires a fee in BSQ.

* Inputs [1-n]: BSQ inputs for BSQ fee + stake
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Mandatory BSQ output of stake
* Output [0-1] Optional BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee + burned BSQ fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x13
* 1 byte for version: 0x01
* 0 bytes for hash of encrypted votes

To create the encrypted votes we use following data:-

* Secret key: 128 bit AES key.
* List of a tuple of proposal Tx IDs + vote, sorted by tx ID. Only valid proposals of current cycle are included.

We use protobuffer serialisation for the bytes which will be encrypted with the secret key.

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

* Input 1: 8000.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ / 0.00700000 BTC
* Output 2: 998 BSQ change output
* Output 3: 0.09950200 BTC change output
* Output 4: OpReturn data
* Mining fee: 0.0005 (0.00049800 BTC + 0.00000200 BTC or 2 BSQ)

=== <big>Vote reveal tx</big> ===

The vote reveal tx consumes the stake output from the blind vote tx as the only BSQ input. It does not require a BSQ fee.

In the OpReturn data we add the secret key for decrypting our blind vote and a hash of the blind vote list to ensure consensus of the P2P network data used in voting. This hash will be used in the vote result phase to determine a majority in case different users get a different list of blind votes, which would lead to different vote results, and therefore cause consensus failures.

* Input [1]: BSQ input → stake output of blind vote tx
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: BSQ output (unlocked stake)
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

''<big>OpReturn data:</big>''

* 1 byte for tx type: 0x14
* 1 byte for version: 0x01
* 20 bytes for hash of blind vote list
* 16 bytes secretKey

'''The hash of the blind vote list is made using all blind vote payload data received in the cycle and sorted by blind vote tx ID. The secretKey is the encoded byte representation of the secret key.'''

==== Example with 7000 BSQ stake: ====

* Input 1: 7000 BSQ
* Input 2: 0.1 BTC
* Output 1: 7000 BSQ
* Output 2: 0.09950000 BTC
* Output 2: 0.09950000 BTC
* Mining fee: 0.0005 BTC

=== <big>Lockup tx</big> ===

The lock tx can be use for locking up funds for a bonded role or for bonded reputation: a certain amount of BSQ is locked for a defined lock time (in blocks). Only an unlock tx can unlock locked funds. Once the unlock tx is confirmed, the lock time will be used to determine when the funds can be used in a normal transaction again. While funds are locked, they cannot be moved, or they are invalidated. While funds are locked, or are in an unlocking state, funds can be confiscated by voting.

* Inputs [1-n]: BSQ inputs
* Inputs [1-n]: BTC inputs for miner fee
* Output [1]: Locked up BSQ
* Outputs [0-1]: BSQ change output
* Outputs [0-1]: BTC change output
* Output [1]: OP_RETURN with OpReturnData and amount 0
* Mining fee: BTC mining fee

<big>''OpReturn data:''</big>

* 1 byte for tx type: 0x15
* 1 byte for version: 0x01
* 1 byte for lockup reason (bonded role 0x01, reputation 0x02)
* 2 bytes for lock time (see: bisq.common.util.Utilities.integerToByteArray for encoding)
* 20 bytes for hash

'''The hash in case of a bonded role is created from immutable data of the bonded role. Currently we use hashCode but that should be changed to a cryptographic hash. The hash for a reputation is derived from a salt. The salt is by default a random string as hex or can be any string defined by the user.'''

==== Example with locking up 4000 BSQ: ====

* Input 1: 6000 BSQ
* Input 2: 0.1 BTC
* Output 1: 4000 BSQ lockup
* Output 1: 2000 BSQ change output
* Output 2: 0.09950000 BTC
* Output 3: OpReturn data
* Mining fee: 0.0005 BTC

=== <big>Asset listing fee tx</big> ===

==== Example with a BSQ fee of 20 BSQ: ====

=== <big>Proof of burn tx</big> ===

==== Example with 20 BSQ burned: ====

== <big>P2P network paylod</big> ==

Proposals and blind vote data are published over the Bisq P2P network. They must be published in the correct phase and cycle, otherwise they are considered invalid. Each node listens for these messages and persists the data locally. At startup, each node receives missing data from seed nodes. The corresponding tx ID is part of the data and is used to map the data to the transaction. The hash of the P2P network data is part of the OpReturn data in the transactions. In this way, we can verify that the mapping of a tx to the data is correct in both directions.

=== Temporary proposal payload ===

During the proposal phase the user can add and remove proposals. For removing we use the public key which was added when publishing a proposal and verify with a signature if the remove attempt is coming from the same owner. This is the same model as we use in other P2P network data like offer payloads. The data has a time to live of 60 days, and after that, it is removed from local storage.

=== Proposal payload ===

There are several different types of proposals:

* Compensation request
* Reimbursement requests
* Proposal for changing a parameter
* Proposal for a bonded role
* Proposal for confiscating a bond
* Generic proposal
* Proposal for removing an asset

The proposal contains the tx ID of the proposal transaction. When creating the transaction we add the 20-byte hash of the proposal data to the OpReturn data of the proposal tx. As the tx ID would be part of the proposal data and cannot be known before the tx is created, we leave it empty and set it afterwards. That way we get a mapping in both directions and can verify later that a proposal payload has a valid tx and that the tx data matches the proposal data.

During the break after the proposal phase, all nodes publish their proposal payload, which uses proposals from the temporary proposal payload. This data is now immutable and will be used for voting.

=== Blind vote payload ===

Blind vote data are published when the user makes his blind vote tx and are managed in the same way as proposal payloads (append-only data).

== <big>Governance</big> ==

== <big>Disclaimer</big> ==

{{Admonition Warn|This document does not cover all details and cannot be used as basis for implementation of BSQ features or for creating self-crafted transactions. The source code is the only real specification. It is NOT recommended to create custom BSQ transactions, as tiny mistakes can lead to destroyed BSQ. Bisq developers will not be concerned with transactions which might be valid with the current rule set but which have not been created by the Bisq application. In the future, updated rules might become more strict and might break such externally-created transactions. Requirements for backward compatibility will only consider use cases and tx structures created by the Bisq application.

Please note that currently it is not recommended to send BSQ to a hardware wallet. Handling the miner fee might cause invalidation of the BSQ funds or cause losses if precious BSQ is used to pay the miner fee. We will publish some instructions on how to do this in a safe way soon.}}

DAO technical overview

2020-09-28T15:17:01Z

Bayer: /* Vote reveal tx */

DAO technical overview

2020-09-28T15:13:59Z

Bayer: /* Disclaimer */

DAO technical overview

2020-09-28T15:12:59Z

Bayer: /* Disclaimer */

DAO technical overview

2020-09-28T15:11:44Z

Bayer: /* P2P network paylod */

DAO technical overview

2020-09-28T15:08:49Z

Bayer: /* Blind vote tx */

DAO technical overview

2020-09-28T15:08:13Z

Bayer:

DAO technical overview

2020-09-28T15:02:20Z

Bayer: /* Proposal tx */

DAO technical overview

2020-09-23T16:36:53Z

Bayer:

DAO technical overview

2020-09-23T16:36:26Z

Bayer:

<big>'''<big>WORK IN PROGRESS</big>''</big>' <big>'' This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===

==== Example with a BSQ fee of 2 BSQ: ====

=== <big>Compensation request tx/Reimbursement request tx</big> ===

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

=== <big>Blind vote tx</big> ===

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

=== <big>Vote reveal tx</big> ===

==== Example with 7000 BSQ stake: ====

=== <big>Lockup tx</big> ===

==== Example with locking up 4000 BSQ: ====

=== <big>Asset listing fee tx</big> ===

==== Example with a BSQ fee of 20 BSQ: ====

=== <big>Proof of burn tx</big> ===

==== Example with 20 BSQ burned: ====

== <big>P2P network paylod</big> ==

== <big>Governance</big> ==

== <big>Disclaimer</big> ==

DAO technical overview

2020-09-23T16:36:00Z

Bayer:

<big>'''<big>WORK IN PROGRESS</big>''</big>' <big>''This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===

==== Example with a BSQ fee of 2 BSQ: ====

=== <big>Compensation request tx/Reimbursement request tx</big> ===

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

=== <big>Blind vote tx</big> ===

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

=== <big>Vote reveal tx</big> ===

==== Example with 7000 BSQ stake: ====

=== <big>Lockup tx</big> ===

==== Example with locking up 4000 BSQ: ====

=== <big>Asset listing fee tx</big> ===

==== Example with a BSQ fee of 20 BSQ: ====

=== <big>Proof of burn tx</big> ===

==== Example with 20 BSQ burned: ====

== <big>P2P network paylod</big> ==

== <big>Governance</big> ==

== <big>Disclaimer</big> ==

DAO technical overview

2020-09-23T16:35:32Z

Bayer:

<big>''This document is a detailed technical overview of the Bisq DAO and BSQ token. Although outdated, please see [[Phase_zero|Phase Zero: A plan for bootstrapping the Bisq DAO]],for a high-level overview and rationale,''</big>

== <big>BSQ token</big> ==

BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis.

The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction.

BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN, it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document.

We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus.

BSQ is a result of blockchain-related data and P2P network data.

== <big>Infrastructure</big> ==

The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab).

=== <big>Nodes</big> ===

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

=== <big>Full nodes</big> ===

A fully-validating BSQ node has the requirement to run a Bitcoin Core (bitcoind) node to provide the blockchain data for verification. The communication is done via RPC. The details about the setup can be found in the documentation folder of the source code repository.

Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process.

=== <big>Lite nodes</big> ===

Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes.

At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend.

=== <big>Seed nodes</big> ===

Seed nodes act as providers for 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.

=== <big>External DAO monitor</big> ===

Monitoring of DAO-related data and infrastructure will be added to the [https://monitor.bisq.network/d/J2oDSi8mk/bisq-dashboard?orgId=1 Bisq monitoring]. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

=== <big>BSQ block explorer</big> ===

The [https://mempool.space/bisq BSQ block explorer] shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

== <big>BSQ integration on bisq</big> ==

The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions.

=== <big>Wallet</big> ===

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP 44]and uses [https://github.com/satoshilabs/slips/blob/master/slip-0044.md registered coin type 142]. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based [https://mempool.space/bisq BSQ block explorer].

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

=== <big>Application internal DAO monitor</big> ===

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

=== <big>Snapshots</big> ===

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

=== <big>Snapshots shipped in releases</big> ===

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

== <big>Blockchain related data</big> ==

One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data—this data is stored on the Bisq P2P network.

List of possible BSQ transaction types:

* Genesis tx
* Transfer BSQ tx
* Trade fee tx
* Proposal tx
* Compensation request tx
* Reimbursement request tx
* Blind vote tx
* Vote reveal tx
* Lockup tx
* Unlock tx
* Asset listing fee tx
* Proof of burn tx

In addition, a transaction can be unverified, invalid or irregular.

Unverified is the default state for all unconfirmed BSQ transactions. Validation is done once a tx is confirmed.

Invalid transactions are transactions which have violated validation rules. BSQ are destroyed in such transactions.

Irregular transactions are transactions which are invalid with their intended use but have not destroyed their BSQ. An example is a proposal tx which got confirmed too late (not in proposal phase) and therefore is invalid as a proposal tx, but the BSQ is still valid to be spent.

=== <big>Genesis tx</big> ===

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic [https://blockstream.info/testnet/nojs/tx/2f194230e23459a9211322c4b1c182cf3f367086e8059aca2f8f44e20dac527a testnet BSQ] to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the [[Phase_zero|DAO Phase Zero]] in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

=== <big>Transfer BSQ tx</big> ===

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

* Input 1: 30.00 BSQ (BSQ sender)
* Input 2: 0.01 BTC (required BTC for mining fee)
* Output 1: 10.00 BSQ (BSQ receiver)
* Output 1: 20.00 BSQ (BSQ change output back to sender)
* Output 2: 0.0095 BTC (BTC change output)
* Mining fee: 0.0005

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Trade fee tx</big> ===

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

* A BSQ trade fee payment tx could look like this (for a fee with 0.5 BSQ):
* Input 1: 10.00 BSQ
* Input 2: 0.1 BTC
* Output 1: 9.50 BSQ
* Output 2: 0.09950050 BTC change output
* Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ)

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

=== <big>Proposal tx</big> ===

==== Example with a BSQ fee of 2 BSQ: ====

=== <big>Compensation request tx/Reimbursement request tx</big> ===

==== Example with a BSQ fee of 2 BSQ and requested issuance amount of 5000 BSQ: ====

=== <big>Blind vote tx</big> ===

==== Example with a BSQ fee of 2 BSQ and 7000 BSQ vote stake: ====

=== <big>Vote reveal tx</big> ===

==== Example with 7000 BSQ stake: ====

=== <big>Lockup tx</big> ===

==== Example with locking up 4000 BSQ: ====

=== <big>Asset listing fee tx</big> ===

==== Example with a BSQ fee of 20 BSQ: ====

=== <big>Proof of burn tx</big> ===

==== Example with 20 BSQ burned: ====

== <big>P2P network paylod</big> ==

== <big>Governance</big> ==

== <big>Disclaimer</big> ==

DAO technical overview

2020-09-23T15:44:58Z

Bayer:

DAO technical overview

2020-09-23T15:39:11Z

Bayer:

DAO technical overview

2020-09-23T15:23:20Z

Bayer:

DAO technical overview

2020-09-23T15:18:06Z

Bayer:

DAO technical overview

2020-09-23T15:17:36Z

Bayer:

Decentralized autonomous organization

2020-09-23T15:11:46Z

Bayer: /* Reference Material */

The Bisq exchange network is organized as a decentralized autonomous organization (DAO). The Bisq DAO's purpose is to make the Bisq's governance model as decentralized and censorship-resistant as the Bisq network itself.

The Bisq founders realized that decentralized software—no matter how technically robust—is no good if it’s still controlled by a single entity. All the software’s technical strength would be worthless if the whole project could be ruined by attacking the single entity that runs it.

Thus the need for decentralizing the resources in charge of running Bisq itself. These resources cannot be organized in the form of a company, a nonprofit, or any other traditional organization because a single entity would be a single point of failure. But what to do? How can a project do anything useful without becoming an organization with some kind of structure? How can strategy be determined? How can resources be allocated? How can work get done? How can revenue be earned, and how can it be distributed?

The Bisq project needed infrastructure to provide these functions, and the Bisq DAO is its solution.

'''''This page collects all resources which aim to help you learn more about the Bisq DAO, what it is, and how it works!'''''

== General Informtation ==

=== Introduction to the DAO ===

[[Introduction_to_the_DAO|A plain language introduction to the Bisq DAO]]

=== Bisq DAO in Brief (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e Quick, short video series] on the Bisq DAO. Get up to speed with a handful of 3-4 minute videos.

=== Bisq DAO Basics (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYOLdYJj3nQ6-DekbjMTVhCS A more thorough treatment] of the DAO covering everything from the basics of bitcoin transactions and colored coins to the economic and technical roots of the BSQ token and how it powers the Bisq DAO.

== User Guides and Use Cases ==

=== User Guide for Traders ===

[[DAO_user_guide_for_traders|Use BSQ]] to get lower trading fees and compensate contributors

== Contributor Docs ==

=== User Guide for Contributors ===

[[DAO_user_guide_for_contributors|Govern Bisq]] through the DAO by obtaining Bisq, making proposals and voting

=== Contributor Checklist ===

[[Contributor_checklist|The one-stop doc]] to help you start contributing to Bisq.

=== Requesting Compensation and Voting ===

Contributed to the Bisq Network? Great (and thank you!). [[Compensation|Here is how to request compensation for your work.]]

=== DAO Proposals ===

How to make a [[Proposals|proposal]] to the DAO.

== Reference Material ==

=== Bisq DAO Technical Overview ===

[[DAO_technical_overview|Technical details]] of (1) what BSQ tokens actually are, how they’re created, and how they’re destroyed and (2) the various functions of the Bisq DAO and how BSQ enables them. The document includes several example transactions so you can explicitly see the processes.

=== Phase Zero: A Plan for Bootstrapping the Bisq DAO ===

[[Phase_zero|An overview]] of the philosophy behind Bisq, the Bisq DAO, why both were created, and how it planned to decentralize its own governance from the very beginning.

Compensation

2020-09-22T16:09:25Z

Bayer: /* Submit your request as a DAO proposal */

__TOC__

== Processes by role ==

=== Compensation Maintainer ===

==== Announce BSQ-USD exchange rate ====

Compensation requests [https://github.com/bisq-network/compensation/issues/519 should use a 90-day volume weighted average] to calculate a value for BSQ and mitigate its volatility. At the end of a Bisq DAO Cycle and beginning of a new one, the Compensation Maintainer should create a pinned issue with the title: <code>BSQ rate for Cycle X is Y.YY USD per 1 BSQ</code> and a screenshot of DAO Dashboard to announce the rates for the ongoing cycle.

==== Announce request submission deadline ====

To give time for team leads to discuss and review Compensation Requests, requests need to be <code>Ready for review</code> one week prior to the end of current cycle's proposal phase. [[File:Compensation_board.png|400px|right|thumb|Compensation board]]The date and reminders will be announced at [https://github.com/orgs/bisq-network/teams/dao/discussions/ @bisq-network/dao], the [https://github.com/orgs/bisq-network/projects/5 Compensation board] and the [[Events Calendar]]

==== Triage incoming requests ====

The Compensation Maintainer watches the [https://github.com/bisq-network/compensation/issues compensation repository] and proceeds to triage:

Incoming issues are classified as <code>Work in progress</code> if they have <code>[WIP]</code> at the beginning of the title or as <code>In Review</code> if they don't. Compensation Maintainer assigns 'In review' issues to corresponding team leads after looking at the content of the request. When in doubt, Compensation Maintainer should ask in the issue which team leaders are the appropriate for the issue.

The Compensation Maintainer should transition reviewed requests with DAO proposals transaction ID submitted to <code>Proposal Submitted</code> column.

Triage is controlled from the Compensation board, drag-and-dropping issues and using "add cards" to triage incoming issues, and directly from the issues, using the "projects" section in the right sidebar.

==== Archive previous cycle requests at the end of the proposal phase ====

At the completion of the current cycle's proposal phase, the Compensation Maintainer should [https://help.github.com/en/github/managing-your-work-on-github/archiving-cards-on-a-project-board archive] all issues in the <code>Done</code> column from the previous phase.

The reason for waiting to archive these issues is so that contributors can easily see how many requests were made in the last phase, to quickly find their own prior request, and to to easily review which ones were accepted and rejected. We archive them at the end of the proposal phase in order to keep the board clean and make room for requests in the current phase to populate the <code>Done</code> column.

==== Close current cycle requests after the vote reveal phase ====

When the reveal vote phase is complete, the Compensation Maintainer should take the following steps:

# Label each compensation request issue as <code>was:accepted</code> or <code>was:rejected</code> according to the vote result
# Close the issue with a comment that reads "Closing as accepted" or "Closing as rejected".

Once closed, the issues will automatically transition to the <code>Done</code> column of the board where they remain for reference until they are archived at the end of the next cycle's proposal phase (as per the section above).

=== Contributor ===

==== Create your compensation request issue ====

If you wish to request compensation for the current [[Glossary#DAO Cycle|cycle]], you should create a [[Submit_compensation_request|compensation request issue]] no later than '''one week prior''' to the end of the current cycle's proposal phase. This is in order to allow time for review by your [[Team Lead]]. Reminders about this deadline are sent every cycle to the [https://github.com/bisq-network/teams/dao @bisq-network/dao] team, so you should make sure you are watching discussions for that team.

WIP (Work in Progress) compensation requests may be submitted with a <code>[WIP]</code> prefix in the title, e.g. <code>[WIP] For Cycle 10</code>. Such WIP requests are assumed not to be ready for review until the WIP prefix is removed. This allows you a convenient way to incrementally add content to a compensation request throughout the course of a cycle without triggering a review prematurely. To indicate that a WIP compensation request is now ready for review, remove the <code>[WIP]</code> prefix from the compensation request issue and add a comment stating ''"This request is ready for review"''. Any compensation request submitted without a WIP prefix will be assumed to be ready for review.

==== Ensure your request is valid ====

To more efficiently evaluate issuance for budgeting, compensation requests are evaluated by a bot. This bot requires that compensation requests follow a particular format. This format is detailed in the placeholder text for new compensation request issues—just follow the guidelines there, and/or look at other requests if you're not sure about something.

In order to make sure the bot can actually read the request, requests are linted as soon as they are ready for review (i.e., as soon as <code>[WIP]</code> is removed from the issue title). A request is labeled <code>parsed:valid</code> if it's valid, <code>parsed:invalid</code> if it's not. If invalid, a comment is added indicating the error. Please watch for this label and fix any errors the linter finds.

==== Incorporate review feedback for your request ====

When your team lead or other stakeholders review your compensation request, they will provide any feedback or requests for changes in the form of a comment on your request issue. Please respond to it promptly. When there is no further feedback, your team lead will add a comment asking you to submit this compensation request as a DAO proposal. The instructions how to do so are in the next section.

Exception: If your contribution proposal consists solely of Bonded Roles for the Ops Team, which are pre-approved in the Ops Budget and allocated to you, and you are still running those nodes as expected, then you can skip the Team Lead Review as per https://github.com/orgs/bisq-network/teams/ops/discussions/1

==== Submit your request as a DAO proposal ====

Follow the instructions on how to [[File_compensation_request_in_the_DAO|file your compensation request as a DAO proposal]]. When complete, add a comment to your proposal issue that includes the transaction ID of your proposal. 

=== Team Lead ===

==== Review team member requests ====

When a team lead is assigned to a compensation request issue, they should promptly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as a appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should add a comment asking the contributor to submit their proposal to DAO and to post the resulting TXID in a comment.

=== Stakeholder ===

==== Review contributor requests ====
Remember that just as stakeholders may vote on any DAO proposal, stakeholders may review any contributor's compensation request. To do so, simply add your review feedback in the form of a comment, and react to the compensation request issue with a thumbs-up, thumbs-down or confused face emoji as appropriate. Note that with the exception of team leads, there is no obligation to perform these reviews, and in general you should only review compensation requests that you are knowledgeable about.

[[Category:Processes]]

Compensation

2020-09-22T15:43:19Z

Bayer: /* Create your compensation request issue */

__TOC__

== Processes by role ==

=== Compensation Maintainer ===

==== Announce BSQ-USD exchange rate ====

Compensation requests [https://github.com/bisq-network/compensation/issues/519 should use a 90-day volume weighted average] to calculate a value for BSQ and mitigate its volatility. At the end of a Bisq DAO Cycle and beginning of a new one, the Compensation Maintainer should create a pinned issue with the title: <code>BSQ rate for Cycle X is Y.YY USD per 1 BSQ</code> and a screenshot of DAO Dashboard to announce the rates for the ongoing cycle.

==== Announce request submission deadline ====

To give time for team leads to discuss and review Compensation Requests, requests need to be <code>Ready for review</code> one week prior to the end of current cycle's proposal phase. [[File:Compensation_board.png|400px|right|thumb|Compensation board]]The date and reminders will be announced at [https://github.com/orgs/bisq-network/teams/dao/discussions/ @bisq-network/dao], the [https://github.com/orgs/bisq-network/projects/5 Compensation board] and the [[Events Calendar]]

==== Triage incoming requests ====

The Compensation Maintainer watches the [https://github.com/bisq-network/compensation/issues compensation repository] and proceeds to triage:

Incoming issues are classified as <code>Work in progress</code> if they have <code>[WIP]</code> at the beginning of the title or as <code>In Review</code> if they don't. Compensation Maintainer assigns 'In review' issues to corresponding team leads after looking at the content of the request. When in doubt, Compensation Maintainer should ask in the issue which team leaders are the appropriate for the issue.

The Compensation Maintainer should transition reviewed requests with DAO proposals transaction ID submitted to <code>Proposal Submitted</code> column.

Triage is controlled from the Compensation board, drag-and-dropping issues and using "add cards" to triage incoming issues, and directly from the issues, using the "projects" section in the right sidebar.

==== Archive previous cycle requests at the end of the proposal phase ====

At the completion of the current cycle's proposal phase, the Compensation Maintainer should [https://help.github.com/en/github/managing-your-work-on-github/archiving-cards-on-a-project-board archive] all issues in the <code>Done</code> column from the previous phase.

The reason for waiting to archive these issues is so that contributors can easily see how many requests were made in the last phase, to quickly find their own prior request, and to to easily review which ones were accepted and rejected. We archive them at the end of the proposal phase in order to keep the board clean and make room for requests in the current phase to populate the <code>Done</code> column.

==== Close current cycle requests after the vote reveal phase ====

When the reveal vote phase is complete, the Compensation Maintainer should take the following steps:

# Label each compensation request issue as <code>was:accepted</code> or <code>was:rejected</code> according to the vote result
# Close the issue with a comment that reads "Closing as accepted" or "Closing as rejected".

Once closed, the issues will automatically transition to the <code>Done</code> column of the board where they remain for reference until they are archived at the end of the next cycle's proposal phase (as per the section above).

=== Contributor ===

==== Create your compensation request issue ====

If you wish to request compensation for the current [[Glossary#DAO Cycle|cycle]], you should create a [[Submit_compensation_request|compensation request issue]] no later than '''one week prior''' to the end of the current cycle's proposal phase. This is in order to allow time for review by your [[Team Lead]]. Reminders about this deadline are sent every cycle to the [https://github.com/bisq-network/teams/dao @bisq-network/dao] team, so you should make sure you are watching discussions for that team.

WIP (Work in Progress) compensation requests may be submitted with a <code>[WIP]</code> prefix in the title, e.g. <code>[WIP] For Cycle 10</code>. Such WIP requests are assumed not to be ready for review until the WIP prefix is removed. This allows you a convenient way to incrementally add content to a compensation request throughout the course of a cycle without triggering a review prematurely. To indicate that a WIP compensation request is now ready for review, remove the <code>[WIP]</code> prefix from the compensation request issue and add a comment stating ''"This request is ready for review"''. Any compensation request submitted without a WIP prefix will be assumed to be ready for review.

==== Ensure your request is valid ====

To more efficiently evaluate issuance for budgeting, compensation requests are evaluated by a bot. This bot requires that compensation requests follow a particular format. This format is detailed in the placeholder text for new compensation request issues—just follow the guidelines there, and/or look at other requests if you're not sure about something.

In order to make sure the bot can actually read the request, requests are linted as soon as they are ready for review (i.e., as soon as <code>[WIP]</code> is removed from the issue title). A request is labeled <code>parsed:valid</code> if it's valid, <code>parsed:invalid</code> if it's not. If invalid, a comment is added indicating the error. Please watch for this label and fix any errors the linter finds.

==== Incorporate review feedback for your request ====

When your team lead or other stakeholders review your compensation request, they will provide any feedback or requests for changes in the form of a comment on your request issue. Please respond to it promptly. When there is no further feedback, your team lead will add a comment asking you to submit this compensation request as a DAO proposal. The instructions how to do so are in the next section.

Exception: If your contribution proposal consists solely of Bonded Roles for the Ops Team, which are pre-approved in the Ops Budget and allocated to you, and you are still running those nodes as expected, then you can skip the Team Lead Review as per https://github.com/orgs/bisq-network/teams/ops/discussions/1

==== Submit your request as a DAO proposal ====

Follow the instructions on how to [https://docs.bisq.network/compensation.html#file-your-compensation-request-in-the-dao file your compensation request as a DAO proposal]. When complete, add a comment to your proposal issue that includes the transaction ID of your proposal. 

=== Team Lead ===

==== Review team member requests ====

When a team lead is assigned to a compensation request issue, they should promptly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as a appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should add a comment asking the contributor to submit their proposal to DAO and to post the resulting TXID in a comment.

=== Stakeholder ===

==== Review contributor requests ====
Remember that just as stakeholders may vote on any DAO proposal, stakeholders may review any contributor's compensation request. To do so, simply add your review feedback in the form of a comment, and react to the compensation request issue with a thumbs-up, thumbs-down or confused face emoji as appropriate. Note that with the exception of team leads, there is no obligation to perform these reviews, and in general you should only review compensation requests that you are knowledgeable about.

[[Category:Processes]]

Decentralized autonomous organization

2020-09-22T15:39:54Z

Bayer: /* User Guides and Use Cases */

The Bisq exchange network is organized as a decentralized autonomous organization (DAO). The Bisq DAO's purpose is to make the Bisq's governance model as decentralized and censorship-resistant as the Bisq network itself.

The Bisq founders realized that decentralized software—no matter how technically robust—is no good if it’s still controlled by a single entity. All the software’s technical strength would be worthless if the whole project could be ruined by attacking the single entity that runs it.

Thus the need for decentralizing the resources in charge of running Bisq itself. These resources cannot be organized in the form of a company, a nonprofit, or any other traditional organization because a single entity would be a single point of failure. But what to do? How can a project do anything useful without becoming an organization with some kind of structure? How can strategy be determined? How can resources be allocated? How can work get done? How can revenue be earned, and how can it be distributed?

The Bisq project needed infrastructure to provide these functions, and the Bisq DAO is its solution.

'''''This page collects all resources which aim to help you learn more about the Bisq DAO, what it is, and how it works!'''''

== General Informtation ==

=== Introduction to the DAO ===

[[Introduction_to_the_DAO|A plain language introduction to the Bisq DAO]]

=== Bisq DAO in Brief (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e Quick, short video series] on the Bisq DAO. Get up to speed with a handful of 3-4 minute videos.

=== Bisq DAO Basics (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYOLdYJj3nQ6-DekbjMTVhCS A more thorough treatment] of the DAO covering everything from the basics of bitcoin transactions and colored coins to the economic and technical roots of the BSQ token and how it powers the Bisq DAO.

== User Guides and Use Cases ==

=== User Guide for Traders ===

[[DAO_user_guide_for_traders|Use BSQ]] to get lower trading fees and compensate contributors

== Contributor Docs ==

=== User Guide for Contributors ===

[[DAO_user_guide_for_contributors|Govern Bisq]] through the DAO by obtaining Bisq, making proposals and voting

=== Contributor Checklist ===

[[Contributor_checklist|The one-stop doc]] to help you start contributing to Bisq.

=== Requesting Compensation and Voting ===

Contributed to the Bisq Network? Great (and thank you!). [[Compensation|Here is how to request compensation for your work.]]

=== DAO Proposals ===

How to make a [[Proposals|proposal]] to the DAO.

== Reference Material ==

=== Bisq DAO User Reference ===

[[DAO_user_reference|Practical details on using the DAO]], along with a brief technical overview: read this to understand what happens behind the scenes as you use the DAO.

=== Bisq DAO Technical Overview ===

[[DAO_technical_overview|Technical details]] of (1) what BSQ tokens actually are, how they’re created, and how they’re destroyed and (2) the various functions of the Bisq DAO and how BSQ enables them. The document includes several example transactions so you can explicitly see the processes.

=== Phase Zero: A Plan for Bootstrapping the Bisq DAO ===

[[Phase_zero|An overview]] of the philosophy behind Bisq, the Bisq DAO, why both were created, and how it planned to decentralize its own governance from the very beginning.

Contributor checklist

2020-09-22T15:33:39Z

Bayer: /* Get connected */

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read [https://chris.beams.io/posts/git-commit How to Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session YouTube live streams].
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.
# '''Do work to fix that problem'''. Submit your fix for review with a pull request (for code and documentation changes) or with a GitHub issue (for everything else).
# '''Request that others review your work'''. The best way to do this is by writing good commit comments and pull request/issue descriptions that clearly explain the problem your work is intended to solve, why it’s important, and why you fixed it the way you did. Make it as easy as possible for others to review your work. Make it a pleasure for others to review your work.
# '''Incorporate review feedback''' you get until your fix gets merged or is otherwise accepted.
# '''Repeat''' steps 1–4.
# [[compensation|Submit a compensation request]] at the end of the month, link to your finished work and request the amount of BSQ you believe that work to be worth to Bisq, the Bisq Network and its users.

{{Admonition Note|<big>'''More on finding work to do'''</big>It is not required to work on an existing bounty issue to contribute to Bisq, and no one is here to tell you what to do. Contributors who have their own ideas are free to work in their own forks on whatever they wish, however they wish, and without any permission from Bisq stakeholders.With that said, it’s a good idea to consult with stakeholders via Keybase, GitHub, the mailing list, or other communication channels before setting out on any serious contribution effort. Do this in order to ensure your contribution is:
# Something that the relevant maintainer(s) would be likely to merge;
# Something that stakeholders would likely vote to approve as a compensation request;
# Subjected to as much feedback as possible while still an idea and thus cheap to change or abort.
Remember: '''every contributor''' is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don’t have any prior context for it, or reason to believe it’s worth spending their time on.}}

'''''Reviews are for everybody'''''If you want to be really popular around here, don’t just submit your own work, but also spend time reviewing the work of others. And remember: reviews are eligible for compensation just like any other contribution.

Contributor checklist

2020-09-22T15:31:11Z

Bayer: /* Getting started */

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read [https://chris.beams.io/posts/git-commit How to Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.
# '''Do work to fix that problem'''. Submit your fix for review with a pull request (for code and documentation changes) or with a GitHub issue (for everything else).
# '''Request that others review your work'''. The best way to do this is by writing good commit comments and pull request/issue descriptions that clearly explain the problem your work is intended to solve, why it’s important, and why you fixed it the way you did. Make it as easy as possible for others to review your work. Make it a pleasure for others to review your work.
# '''Incorporate review feedback''' you get until your fix gets merged or is otherwise accepted.
# '''Repeat''' steps 1–4.
# [[compensation|Submit a compensation request]] at the end of the month, link to your finished work and request the amount of BSQ you believe that work to be worth to Bisq, the Bisq Network and its users.

{{Admonition Note|<big>'''More on finding work to do'''</big>It is not required to work on an existing bounty issue to contribute to Bisq, and no one is here to tell you what to do. Contributors who have their own ideas are free to work in their own forks on whatever they wish, however they wish, and without any permission from Bisq stakeholders.With that said, it’s a good idea to consult with stakeholders via Keybase, GitHub, the mailing list, or other communication channels before setting out on any serious contribution effort. Do this in order to ensure your contribution is:
# Something that the relevant maintainer(s) would be likely to merge;
# Something that stakeholders would likely vote to approve as a compensation request;
# Subjected to as much feedback as possible while still an idea and thus cheap to change or abort.
Remember: '''every contributor''' is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don’t have any prior context for it, or reason to believe it’s worth spending their time on.}}

'''''Reviews are for everybody'''''If you want to be really popular around here, don’t just submit your own work, but also spend time reviewing the work of others. And remember: reviews are eligible for compensation just like any other contribution.

Contributor checklist

2020-09-22T15:30:19Z

Bayer: /* Getting started */

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read how to [https://chris.beams.io/posts/git-commit/ Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.
# '''Do work to fix that problem'''. Submit your fix for review with a pull request (for code and documentation changes) or with a GitHub issue (for everything else).
# '''Request that others review your work'''. The best way to do this is by writing good commit comments and pull request/issue descriptions that clearly explain the problem your work is intended to solve, why it’s important, and why you fixed it the way you did. Make it as easy as possible for others to review your work. Make it a pleasure for others to review your work.
# '''Incorporate review feedback''' you get until your fix gets merged or is otherwise accepted.
# '''Repeat''' steps 1–4.
# [[compensation|Submit a compensation request]] at the end of the month, link to your finished work and request the amount of BSQ you believe that work to be worth to Bisq, the Bisq Network and its users.

{{Admonition Note|<big>'''More on finding work to do'''</big>It is not required to work on an existing bounty issue to contribute to Bisq, and no one is here to tell you what to do. Contributors who have their own ideas are free to work in their own forks on whatever they wish, however they wish, and without any permission from Bisq stakeholders.With that said, it’s a good idea to consult with stakeholders via Keybase, GitHub, the mailing list, or other communication channels before setting out on any serious contribution effort. Do this in order to ensure your contribution is:
# Something that the relevant maintainer(s) would be likely to merge;
# Something that stakeholders would likely vote to approve as a compensation request;
# Subjected to as much feedback as possible while still an idea and thus cheap to change or abort.
Remember: '''every contributor''' is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don’t have any prior context for it, or reason to believe it’s worth spending their time on.}}

'''''Reviews are for everybody'''''If you want to be really popular around here, don’t just submit your own work, but also spend time reviewing the work of others. And remember: reviews are eligible for compensation just like any other contribution.

Contributor checklist

2020-09-22T15:29:17Z

Bayer: /* Getting started */

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read How to [https://chris.beams.io/posts/git-commit/ Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.
# '''Do work to fix that problem'''. Submit your fix for review with a pull request (for code and documentation changes) or with a GitHub issue (for everything else).
# '''Request that others review your work'''. The best way to do this is by writing good commit comments and pull request/issue descriptions that clearly explain the problem your work is intended to solve, why it’s important, and why you fixed it the way you did. Make it as easy as possible for others to review your work. Make it a pleasure for others to review your work.
# '''Incorporate review feedback''' you get until your fix gets merged or is otherwise accepted.
# '''Repeat''' steps 1–4.
# [[compensation|Submit a compensation request]] at the end of the month, link to your finished work and request the amount of BSQ you believe that work to be worth to Bisq, the Bisq Network and its users.

{{Admonition Note|<big>'''More on finding work to do'''</big>It is not required to work on an existing bounty issue to contribute to Bisq, and no one is here to tell you what to do. Contributors who have their own ideas are free to work in their own forks on whatever they wish, however they wish, and without any permission from Bisq stakeholders.With that said, it’s a good idea to consult with stakeholders via Keybase, GitHub, the mailing list, or other communication channels before setting out on any serious contribution effort. Do this in order to ensure your contribution is:
# Something that the relevant maintainer(s) would be likely to merge;
# Something that stakeholders would likely vote to approve as a compensation request;
# Subjected to as much feedback as possible while still an idea and thus cheap to change or abort.
Remember: '''every contributor''' is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don’t have any prior context for it, or reason to believe it’s worth spending their time on.}}

'''''Reviews are for everybody'''''If you want to be really popular around here, don’t just submit your own work, but also spend time reviewing the work of others. And remember: reviews are eligible for compensation just like any other contribution.

Contributor checklist

2020-09-22T15:20:41Z

Bayer: /* Do valuable work and get compensated */

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.https://bisq.wiki/Project_management
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read How to [https://chris.beams.io/posts/git-commit/ Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.
# '''Do work to fix that problem'''. Submit your fix for review with a pull request (for code and documentation changes) or with a GitHub issue (for everything else).
# '''Request that others review your work'''. The best way to do this is by writing good commit comments and pull request/issue descriptions that clearly explain the problem your work is intended to solve, why it’s important, and why you fixed it the way you did. Make it as easy as possible for others to review your work. Make it a pleasure for others to review your work.
# '''Incorporate review feedback''' you get until your fix gets merged or is otherwise accepted.
# '''Repeat''' steps 1–4.
# [[compensation|Submit a compensation request]] at the end of the month, link to your finished work and request the amount of BSQ you believe that work to be worth to Bisq, the Bisq Network and its users.

{{Admonition Note|<big>'''More on finding work to do'''</big>It is not required to work on an existing bounty issue to contribute to Bisq, and no one is here to tell you what to do. Contributors who have their own ideas are free to work in their own forks on whatever they wish, however they wish, and without any permission from Bisq stakeholders.With that said, it’s a good idea to consult with stakeholders via Keybase, GitHub, the mailing list, or other communication channels before setting out on any serious contribution effort. Do this in order to ensure your contribution is:
# Something that the relevant maintainer(s) would be likely to merge;
# Something that stakeholders would likely vote to approve as a compensation request;
# Subjected to as much feedback as possible while still an idea and thus cheap to change or abort.
Remember: '''every contributor''' is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don’t have any prior context for it, or reason to believe it’s worth spending their time on.}}

'''''Reviews are for everybody'''''If you want to be really popular around here, don’t just submit your own work, but also spend time reviewing the work of others. And remember: reviews are eligible for compensation just like any other contribution.

Contributor checklist

2020-09-22T15:20:03Z

Bayer: /* Do valuable work and get compensated */

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.https://bisq.wiki/Project_management
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read How to [https://chris.beams.io/posts/git-commit/ Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.

{{Admonition Note|<big>'''More on finding work to do'''</big>It is not required to work on an existing bounty issue to contribute to Bisq, and no one is here to tell you what to do. Contributors who have their own ideas are free to work in their own forks on whatever they wish, however they wish, and without any permission from Bisq stakeholders.With that said, it’s a good idea to consult with stakeholders via Keybase, GitHub, the mailing list, or other communication channels before setting out on any serious contribution effort. Do this in order to ensure your contribution is:
# Something that the relevant maintainer(s) would be likely to merge;
# Something that stakeholders would likely vote to approve as a compensation request;
# Subjected to as much feedback as possible while still an idea and thus cheap to change or abort.
Remember: '''every contributor''' is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don’t have any prior context for it, or reason to believe it’s worth spending their time on.}}

# '''Do work to fix that problem'''. Submit your fix for review with a pull request (for code and documentation changes) or with a GitHub issue (for everything else).
# '''Request that others review your work'''. The best way to do this is by writing good commit comments and pull request/issue descriptions that clearly explain the problem your work is intended to solve, why it’s important, and why you fixed it the way you did. Make it as easy as possible for others to review your work. Make it a pleasure for others to review your work.
# '''Incorporate review feedback''' you get until your fix gets merged or is otherwise accepted.
# '''Repeat''' steps 1–4.
# [[compensation|Submit a compensation request]] at the end of the month, link to your finished work and request the amount of BSQ you believe that work to be worth to Bisq, the Bisq Network and its users.

{{Admonition Note|'''''Reviews are for everybody'''''If you want to be really popular around here, don’t just submit your own work, but also spend time reviewing the work of others. And remember: reviews are eligible for compensation just like any other contribution.}}

Contributor checklist

2020-09-22T15:19:18Z

Bayer:

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.https://bisq.wiki/Project_management
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read How to [https://chris.beams.io/posts/git-commit/ Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.
# '''Do work to fix that problem'''. Submit your fix for review with a pull request (for code and documentation changes) or with a GitHub issue (for everything else).
# '''Request that others review your work'''. The best way to do this is by writing good commit comments and pull request/issue descriptions that clearly explain the problem your work is intended to solve, why it’s important, and why you fixed it the way you did. Make it as easy as possible for others to review your work. Make it a pleasure for others to review your work.
# '''Incorporate review feedback''' you get until your fix gets merged or is otherwise accepted.
# '''Repeat''' steps 1–4.
# [[compensation|Submit a compensation request]] at the end of the month, link to your finished work and request the amount of BSQ you believe that work to be worth to Bisq, the Bisq Network and its users.

{{Admonition Note|'''''Reviews are for everybody'''''If you want to be really popular around here, don’t just submit your own work, but also spend time reviewing the work of others. And remember: reviews are eligible for compensation just like any other contribution.}}

Contributor checklist

2020-09-22T15:13:19Z

Bayer:

Contributor checklist

2020-09-22T15:12:11Z

Bayer:

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute == 

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.https://bisq.wiki/Project_management
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read How to [https://chris.beams.io/posts/git-commit/ Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.

Contributor checklist

2020-09-22T15:11:30Z

Bayer:

<big>So you’re interested in contributing to Bisq, welcome! This checklist will get you plugged in and productive as quickly as possible.</big>

== How to contribute ==

Bisq is free and open source software, but contributing is not just about writing code. '''A contributor is any individual who works to improve and add value to the Bisq Network and its users.'''

This can mean anything from fixing typos in documentation, to answering questions on the Bisq Forum, to implementing new Bisq features and everything in-between. All such contributions are eligible for compensation under the Bisq DAO. See more details below and in the [[Compensation]] doc.

=== Getting started ===

# Join our [https://keybase.io/team/bisq Keybase team].
# Introduce yourself in the <code>#introductions</code> channel. Say a bit about your skills and interests. This will help others point you in the right direction.https://bisq.wiki/Project_management
# Explore the other channels on Keybase, and join the ones that are of interest to you. For a start, we recommend joining <code>#proposals</code>, <code>#growth</code>, <code>#roles</code>, <code>#compensation</code>, <code>#dev</code> and <code>#dev-onboarding</code> (if you’re a developer).
# Watch the [https://github.com/bisq-network/proposals proposals], [https://github.com/bisq-network/roles roles] and [https://github.com/bisq-network/compensation compensation] repositories to get notified of threaded GitHub issue discussions that happen there.
# Read the [https://github.com/bisq-network/bisq/blob/master/docs/README.md developer docs] to set up a Bisq development environment.
# Read How to [https://chris.beams.io/posts/git-commit/ Write a Git Commit Message] and follow its [https://chris.beams.io/posts/git-commit/#7-rules 7 rules] when contributing to Bisq projects.
# Get set up to [https://help.github.com/articles/signing-commits-using-gpg/ Sign your Git Commits] with GPG.

=== Learn how we work ===

# Read about [[Project_management|Bisq’s project management process]].
# Familiarize yourself with [https://ossec-docs.readthedocs.io/en/latest/docs/development/oRFC/orfc-1.html C4: The Collective Code Construction Contract]. It’s a simple set of collaboration rules based on GitHub’s fork+pull request model, and a foundational part of how we work together.
# For more context on C4 and the principles behind it, read author Pieter Hintjens' short book, [https://www.gitbook.com/?utm_source=legacy&utm_medium=redirect&utm_campaign=close_legacy Social Architecture].
# Introduce yourself to Bisq and the Bisq DAO with the [[Phase_zero|Phase Zero doc]]. It’s a bit outdated now, as the DAO has been launched, but it’s the best overview of Bisq’s background and underlying concepts.
# To understand Bisq’s commitment to radical transparency and radical honesty, read Part III of [https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021/ Ray Dalio’s Principles].
# To get inspired about what building software in a non-hierarchical organization can be like (and what it requires of everyone involved), read the [https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf Valve Employee Handbook].

=== Get connected ===

# Subscribe to the [https://www.youtube.com/c/bisq-network Bisq YouTube channel] to get notified about every meeting we hold, tutorial we publish, live session we broadcast, and more.
# Follow [https://twitter.com/bisq_network @bisq_network] on Twitter.
# Catch up on past [https://www.youtube.com/playlist?list=PLFH5SztL5cYOtcg64PntHlbtLoiO3HAjB Bisq Tech Session] YouTube live streams.
# Subscribe to the [https://lists.bisq.network/listinfo/bisq-contrib bisq-contrib] mailing list for low-frequency, high-priority contributor communications.

=== Get assigned to an issue or role ===

Discuss with others, and after it is agreed that someone will assign something to you, do the following:

# Request an invite to the [https://github.com/bisq-network @bisq-network organization]. An admin will get you set up. Doing this makes it possible to add you to the [https://github.com/orgs/bisq-network/teams @bisq-network/contributors] team and to assign you to GitHub issues.
# After accepting your GitHub invitation, please change your [https://github.com/orgs/bisq-network/people membership visibility] from <code>private</code> to <code>public</code>. This helps others know at a glance roughly how many contributors are involved with Bisq.

=== Do valuable work and get compensated ===

Ok. You’re all set up and ready to work. Here’s what to do next.

# '''Find a problem somewhere in Bisq-land''' that (a) needs fixing and (b) is a match for your skills and interests. Browse critical bugs, open bounties, ask around about what other contributors think needs fixing. Because while you don’t need anybody’s permission and you can work on whatever you want, you’ll want to know up front whether anybody else is going to care about the work you do.

Contributor checklist

2020-09-22T15:10:52Z

Bayer:

Decentralized autonomous organization

2020-09-18T17:35:08Z

Bayer: /* User Guide for Traders */

The Bisq exchange network is organized as a decentralized autonomous organization (DAO). The Bisq DAO's purpose is to make the Bisq's governance model as decentralized and censorship-resistant as the Bisq network itself.

The Bisq founders realized that decentralized software—no matter how technically robust—is no good if it’s still controlled by a single entity. All the software’s technical strength would be worthless if the whole project could be ruined by attacking the single entity that runs it.

Thus the need for decentralizing the resources in charge of running Bisq itself. These resources cannot be organized in the form of a company, a nonprofit, or any other traditional organization because a single entity would be a single point of failure. But what to do? How can a project do anything useful without becoming an organization with some kind of structure? How can strategy be determined? How can resources be allocated? How can work get done? How can revenue be earned, and how can it be distributed?

The Bisq project needed infrastructure to provide these functions, and the Bisq DAO is its solution.

'''''This page collects all resources which aim to help you learn more about the Bisq DAO, what it is, and how it works!'''''

== General Informtation ==

=== Introduction to the DAO ===

[[Introduction_to_the_DAO|A plain language introduction to the Bisq DAO]]

=== Bisq DAO in Brief (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e Quick, short video series] on the Bisq DAO. Get up to speed with a handful of 3-4 minute videos.

=== Bisq DAO Basics (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYOLdYJj3nQ6-DekbjMTVhCS A more thorough treatment] of the DAO covering everything from the basics of bitcoin transactions and colored coins to the economic and technical roots of the BSQ token and how it powers the Bisq DAO.

== User Guides and Use Cases ==

=== User Guide for Traders ===

[[DAO_user_guide_for_traders|Use BSQ]] to get lower trading fees and compensate contributors

=== How to run a seed node ===

Information on the workings of and how to operate a [[How_to_run_seednode|Bisq seed node]]

=== How to run a price node ===

Information on the workings of how to operate a [[How_to_run_pricenode|Bisq price node]]

== Contributor Docs ==

=== User Guide for Contributors ===

[[DAO_user_guide_for_contributors|Govern Bisq]] through the DAO by obtaining Bisq, making proposals and voting

=== Contributor Checklist ===

[[Contributor_checklist|The one-stop doc]] to help you start contributing to Bisq.

=== Requesting Compensation and Voting ===

Contributed to the Bisq Network? Great (and thank you!). [[Compensation|Here is how to request compensation for your work.]]

=== DAO Proposals ===

How to make a [[Proposals|proposal]] to the DAO.

== Reference Material ==

=== Bisq DAO User Reference ===

[[DAO_user_reference|Practical details on using the DAO]], along with a brief technical overview: read this to understand what happens behind the scenes as you use the DAO.

=== Bisq DAO Technical Overview ===

[[DAO_technical_overview|Technical details]] of (1) what BSQ tokens actually are, how they’re created, and how they’re destroyed and (2) the various functions of the Bisq DAO and how BSQ enables them. The document includes several example transactions so you can explicitly see the processes.

=== Phase Zero: A Plan for Bootstrapping the Bisq DAO ===

[[Phase_zero|An overview]] of the philosophy behind Bisq, the Bisq DAO, why both were created, and how it planned to decentralize its own governance from the very beginning.

Decentralized autonomous organization

2020-09-18T17:34:48Z

Bayer: /* User Guide for Contributors */

The Bisq exchange network is organized as a decentralized autonomous organization (DAO). The Bisq DAO's purpose is to make the Bisq's governance model as decentralized and censorship-resistant as the Bisq network itself.

The Bisq founders realized that decentralized software—no matter how technically robust—is no good if it’s still controlled by a single entity. All the software’s technical strength would be worthless if the whole project could be ruined by attacking the single entity that runs it.

Thus the need for decentralizing the resources in charge of running Bisq itself. These resources cannot be organized in the form of a company, a nonprofit, or any other traditional organization because a single entity would be a single point of failure. But what to do? How can a project do anything useful without becoming an organization with some kind of structure? How can strategy be determined? How can resources be allocated? How can work get done? How can revenue be earned, and how can it be distributed?

The Bisq project needed infrastructure to provide these functions, and the Bisq DAO is its solution.

'''''This page collects all resources which aim to help you learn more about the Bisq DAO, what it is, and how it works!'''''

== General Informtation ==

=== Introduction to the DAO ===

[[Introduction_to_the_DAO|A plain language introduction to the Bisq DAO]]

=== Bisq DAO in Brief (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e Quick, short video series] on the Bisq DAO. Get up to speed with a handful of 3-4 minute videos.

=== Bisq DAO Basics (videos) ===

[https://www.youtube.com/playlist?list=PLFH5SztL5cYOLdYJj3nQ6-DekbjMTVhCS A more thorough treatment] of the DAO covering everything from the basics of bitcoin transactions and colored coins to the economic and technical roots of the BSQ token and how it powers the Bisq DAO.

== User Guides and Use Cases ==

=== User Guide for Traders ===

[[DAO_user_for_traders|Use BSQ]] to get lower trading fees and compensate contributors

=== How to run a seed node ===

Information on the workings of and how to operate a [[How_to_run_seednode|Bisq seed node]]

=== How to run a price node ===

Information on the workings of how to operate a [[How_to_run_pricenode|Bisq price node]]

== Contributor Docs ==

=== User Guide for Contributors ===

[[DAO_user_guide_for_contributors|Govern Bisq]] through the DAO by obtaining Bisq, making proposals and voting

=== Contributor Checklist ===

[[Contributor_checklist|The one-stop doc]] to help you start contributing to Bisq.

=== Requesting Compensation and Voting ===

Contributed to the Bisq Network? Great (and thank you!). [[Compensation|Here is how to request compensation for your work.]]

=== DAO Proposals ===

How to make a [[Proposals|proposal]] to the DAO.

== Reference Material ==

=== Bisq DAO User Reference ===

[[DAO_user_reference|Practical details on using the DAO]], along with a brief technical overview: read this to understand what happens behind the scenes as you use the DAO.

=== Bisq DAO Technical Overview ===

[[DAO_technical_overview|Technical details]] of (1) what BSQ tokens actually are, how they’re created, and how they’re destroyed and (2) the various functions of the Bisq DAO and how BSQ enables them. The document includes several example transactions so you can explicitly see the processes.

=== Phase Zero: A Plan for Bootstrapping the Bisq DAO ===

[[Phase_zero|An overview]] of the philosophy behind Bisq, the Bisq DAO, why both were created, and how it planned to decentralize its own governance from the very beginning.

Paying trading fees with BSQ

2020-09-18T17:30:21Z

Bayer:

'''<big>This short guide will show you how to use BSQ to pay lower trading fees. Using BSQ also compensates Bisq contributors, making the Bisq network a sustainable free and open source software project.</big>'''

Bisq’s token is a bit different from most other exchange tokens: its primary reason to exist is to enable the decentralized operation and management of the Bisq network. That means no central wallets or accounts to accumulate funds, and no legal entity or leadership team to control strategy. See more details [[Introduction_to_the_DAO|in this doc]] or [https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e in these videos].

For you, as a trader, discounted trading fees are a practical result of this approach: the mechanisms above require that trading fees be paid in BSQ, so the software encourages traders to pay fees with BSQ by making them cheaper than plain BTC fees.

Let’s see how to take advantage of this.

== Acquire BSQ ==

Although BSQ is [https://docs.bisq.network/dao-technical-overview.html#bsq-token technically bitcoin], it’s [https://en.bitcoin.it/wiki/Colored_Coins colored bitcoin] that must be kept in a Bisq wallet, separate from plain bitcoin.

To help you do this, and to avoid mistakes, Bisq automatically generates a separate BSQ wallet for you with its own address prefixed with a ''''B''''—so you can be sure when you’re sending or receiving from a BSQ address.

=== Retreive your BSQ address ===

You can find your BSQ wallet address in <code>DAO > BSQ wallet > Receive.</code>

[[File:Bsq-wallet-address.png|700px|thumb|left]]

<div style="clear: both;"></div>

=== Create BSQ payment account ===

To trade BSQ on Bisq, you need to set up an altcoin account using your BSQ address.

{{Admonition_Note|'''<big>What is instant trading?</big>'''
For altcoins, Bisq offers instant trading, which shortens the trade period to a maximum of 1 hour. Everything else about instant trades is the same as non-instant trades.
Instant offers are marked as <code>Altcoins Instant</code> in the order book, and you can only accept those offers with an instant altcoins account. Non-instant payment accounts can only be used for non-instant offers.}}

We’re going to leave that box unchecked and make this one a regular non-instant account.

[[File:add-new-bsq-account.png|700px|thumb|left]]

<div style="clear: both;"></div>

=== Make or take a BSQ offer ===

Now that you have a BSQ payment account configured, you can trade BSQ.

Simply pick an offer you like (or make an offer of your own) and complete the trade.

[[File:bsq-buy-offers.png|700px|thumb|left]]

<div style="clear: both;"></div>

=== Use BSQ to pay trading fees ===

Once you’ve got some BSQ, you can use it to pay trading fees.

When you get to the <code>Take offer</code> screen where you confirm the trade amount, you’ll see a toggle for trading fees where you can select between BTC and BSQ trading fees.

[[File:trading-fee-toggle.png|700px|thumb|left]]

<div style="clear: both;"></div>

Pick the option you like better and complete the trade!

{{Admonition Note|[[Trading_fees|Using BSQ to pay for your trading fees]] is cheaper then regular Bitcoin and it also helps pay contributors for their work! Bisq encourages traders to use BSQ by offering a discount of approximately 50%!}}

== Beyond trading fees ==

BSQ is also a core element of Bisq’s governance mechanism, allowing stakeholders like you to have a hand in crafting the strategy of the project through a voting process.

You can learn more about it in [[Introduction_to_the_DAO|this intro doc]] and [https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e these videos].

We’ve also written a [[DAO_user_guide_for_contributors|companion guide]] that walks you through a DAO voting process.

== Get help and stay in touch ==

If you get stuck, reach out! There’s a community of people to help you on [https://keybase.io/team/bisq Keybase], the [https://bisq.community/ Bisq forum], and the [https://www.reddit.com/r/bisq/ /r/bisq subreddit].

You can get news and updates about Bisq via [https://twitter.com/bisq_network Twitter] and [https://www.youtube.com/c/bisq-network YouTube].

And if you really like Bisq, [[Contributor_checklist|consider contributing]]! Even if you’re not a developer, there’s much you can do.

File:Bsq block explorer.png

2020-09-18T17:17:51Z

Bayer: bsq block explorer

== Summary ==
bsq block explorer

Paying trading fees with BSQ

2020-09-18T16:00:35Z

Bayer: /* Beyond trading fees */

Paying trading fees with BSQ

2020-09-18T15:57:01Z

Bayer:

Paying trading fees with BSQ

2020-09-18T15:56:33Z

Bayer:

'''<big>This short guide will show you how to use BSQ to pay lower trading fees. Using BSQ also compensates Bisq contributors, making the Bisq network a sustainable free software project.</big>'''

Bisq’s token is a bit different from most other exchange tokens: its primary reason to exist is to enable the decentralized operation and management of the Bisq network. That means no central wallets or accounts to accumulate funds, and no legal entity or leadership team to control strategy. See more details [[Introduction_to_the_DAO|in this doc]] or [https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e in these videos].

For you, as a trader, discounted trading fees are a practical result of this approach: the mechanisms above require that trading fees be paid in BSQ, so the software encourages traders to pay fees with BSQ by making them cheaper than plain BTC fees.

Let’s see how to take advantage of this.

== Acquire BSQ ==

Although BSQ is [https://docs.bisq.network/dao-technical-overview.html#bsq-token technically bitcoin], it’s [https://en.bitcoin.it/wiki/Colored_Coins colored bitcoin] that must be kept in a Bisq wallet, separate from plain bitcoin.

To help you do this, and to avoid mistakes, Bisq automatically generates a separate BSQ wallet for you with its own address prefixed with a ''''B''''—so you can be sure when you’re sending or receiving from a BSQ address.

=== Retreive your BSQ address ===

You can find your BSQ wallet address in <code>DAO > BSQ wallet > Receive.</code>

[[File:Bsq-wallet-address.png|700px|thumb|left]]

<div style="clear: both;"></div>

=== Create BSQ payment account ===

To trade BSQ on Bisq, you need to set up an altcoin account using your BSQ address.

{{Admonition_Note|'''<big>What is instant trading?</big>'''
For altcoins, Bisq offers instant trading, which shortens the trade period to a maximum of 1 hour. Everything else about instant trades is the same as non-instant trades.
Instant offers are marked as <code>Altcoins Instant</code> in the order book, and you can only accept those offers with an instant altcoins account. Non-instant payment accounts can only be used for non-instant offers.}}

We’re going to leave that box unchecked and make this one a regular non-instant account.

[[File:add-new-bsq-account.png|700px|thumb|left]]

<div style="clear: both;"></div>

=== Make or take a BSQ offer ===

Now that you have a BSQ payment account configured, you can trade BSQ.

Simply pick an offer you like (or make an offer of your own) and complete the trade.

[[File:bsq-buy-offers.png|700px|thumb|left]]

<div style="clear: both;"></div>

=== Use BSQ to pay trading fees ===

Once you’ve got some BSQ, you can use it to pay trading fees.

When you get to the <code>Take offer</code> screen where you confirm the trade amount, you’ll see a toggle for trading fees where you can select between BTC and BSQ trading fees.

[[File:trading-fee-toggle.png|700px|thumb|left]]

<div style="clear: both;"></div>

Pick the option you like better and complete the trade!

{{Admonition Note|[[Trading_fees|Using BSQ to pay for your trading fees]] is cheaper then regular Bitcoin and it also helps pay contributors for their work! Bisq encourages traders to use BSQ by offering a discount of approximately 50%!}}

== Beyond trading fees ==

BSQ is also a core element of Bisq’s governance mechanism, allowing stakeholders like you to have a hand in crafting the strategy of the project through a voting process.

You can learn more about it in [[Introduction_to_the_DAO|this intro doc]] and [https://www.youtube.com/playlist?list=PLFH5SztL5cYPAXWFz-IMB4dBZ0MEZEG_e these videos].

We’ve also written a [[DAO_user_guide_for_contributors|companion guid]] that walks you through a DAO voting process.

Paying trading fees with BSQ

2020-09-18T15:53:04Z

Bayer:

Paying trading fees with BSQ

2020-09-18T15:47:40Z

Bayer:

Introduction to the DAO

2020-09-18T15:46:45Z

Bayer: /* BSQ Token */

== Introduction ==

=== What is a DAO? ===

Conventional entities such as for-profit and non-profit corporations must be sanctioned by the state: they are legal entities registered in particular jurisdictions. No matter how big or small or virtuous or innovative they are, they cannot operate without state approval. In return for this approval, the entity is endowed with rights (e.g., limited liability) and responsibilities (e.g., taxes).

A '''decentralized autonomous organization (DAO)''' is just a generic term for a governance model sanctioned by software: code defines conventions for governing the project irrespective of the stance of the state.

{{Admonition_Note|We say a DAO’s governance model must be sanctioned by software, not necessarily controlled by software. The Bisq DAO, for example, is not controlled by software: software merely provides a framework for the people involved with the Bisq project to (collectively) manage the software itself. The Bisq DAO operates on the idea that '''code is not law'''. Code is written by humans to provide a service to other humans, so it should be accountable to humans too. }}

The universe of DAOs is diverse. Just as companies come in many shapes and sizes, and some companies are scammy, fraudulent, or just poorly managed—that’s no reason to assume all companies are the same way. It’s the same with DAOs: some DAOs haven’t worked out so well, but others might turn out differently.

== The Bisq DAO ==

The Bisq DAO forgoes a system where governance is dictated by the rigid rules of software in favor of a self-contained economy where governance is guided by software but ultimately determined by the collective, subjective judgments of its community.

It achieves this by introducing a unit of value called the '''BSQ token''' that enables Bisq stakeholders—contributors, traders, or anyone who owns BSQ—to make subjective value judgments. This token underlies all actions in the DAO.

[https://www.youtube.com/watch?v=pNvOZlIDYEQ&feature=emb_logo Click here for a quick introductory video on the what & why of the Bisq DAO]

=== BSQ token ===

A BSQ token is a '''[https://en.bitcoin.it/wiki/Colored_Coins colored coin]''' on the Bitcoin blockchain. More plainly, a BSQ token is merely a few satoshis with some additional properties that identify it as BSQ in Bisq software. Outside Bisq, a BSQ token just looks like a few satoshis. But on Bisq, the additional properties have the following results:

# The satoshis take on the market value of a BSQ token
# The owner of the satoshis is endowed with power to participate in various Bisq governance functions

See it for yourself: here’s a [https://blockstream.info/nojs/tx/0243f99c848de4f53cb29157d10bf1cdbfcf4219f84e9997dd3cac9244ab7242/ BSQ transaction on an ordinary block explorer], and [https://mempool.space/bisq/tx/0243f99c848de4f53cb29157d10bf1cdbfcf4219f84e9997dd3cac9244ab7242 here’s that same transaction on a BSQ block explorer].

The value of a BSQ token is determined by the market as stakeholders buy and sell tokens to perform various functions in the DAO. Because BSQ tokens are only recognized by Bisq software, BSQ trading can only happen in Bisq software.

{{Admonition_Note|The BSQ token is not associated with any kind of initial coin offering (ICO) or capital-raising initiative. It’s merely a tool to decentralize the governance of the already-functional Bisq exchange service. As of December 2018, Bisq has facilitated over 19,000 trades without major incident since it went into production in April 2016.}}

You can learn more about [https://www.youtube.com/watch?v=68_DU1c0Cac colored coins] here in this interview. Technical details of BSQ tokens are available [[https://bisq.wiki/DAO_technical_overview|here]].

=== Overview ===

Here’s a graphical overview of how the DAO works at a high level:

[[File:User-dao-diagram.png|700px|thumb|left]]

<div style="clear: both;"></div>

Let’s observe some of the dynamics of this system:

* Contributors ''maintain'' Bisq through valuable work
* Traders ''use'' Bisq to buy and sell bitcoin and other cryptocurrencies
* Contributors ''earn'' BSQ tokens when their compensation requests are approved through voting
* Traders ''buy'' BSQ tokens in order to pay lower trading fees
* Stakeholders ''vote'' on compensation requests
* Contributors can ''lock'' a bond in BSQ to ensure integrity in high-trust roles

Now let’s see how these dynamics enable the Bisq DAO to provide 3 core governance functions without any central points of authority.

=== Earn and distribute revenue ===

Every project needs to be financially sustainable to fund ongoing operations and development. But traditional means of handling revenue and revenue distribution are necessarily centralized—any receiving address or account must be owned by one person, or a small group; determining how much a person should be paid must be determined by one person, or a small group; etc.

'''Contributors produce, creating BSQ'''

In the Bisq DAO, trading fees are collected from traders and distributed to contributors, but there is no central authority to do this. Here’s how it works: after a Bisq contributor does work, they file a '''compensation request''' in the DAO with a description of what they did and how much BSQ they want in return. Then, stakeholders (who are other contributors, traders, and anyone else with BSQ) vote for/against the request. If the request is approved, the contributor is issued new BSQ in the amount they requested and '''BSQ supply is increased'''.

{{Admonition_Note|'''<big>Where does new BSQ actually come from?</big>''' Recall that a BSQ token is merely colored bitcoin. When a contributor makes their compensation request in the DAO, they must also include the tiny amount of bitcoin to be '''colored''' as BSQ (the [[DAO_technical_overview|spec]] requires 100 satoshis). So if a contributor requests 1,000 BSQ, they will need to include (100 * 1,000 equals 100,000 satoshis) with their compensation request, just about 10 USD at a rate of (10,000 USD/BTC).If their request is approved, those satoshis are '''colored''' and recognized as 1,000 valid BSQ tokens on Bisq. Assuming a BSQ market value of 1 USD (exact value will fluctuate), the contributor will have been granted 1,000 USD worth of BSQ for a negligible cost of 10 USD.}}

'''Traders consume, burning BSQ'''

Then, a trader looking for lower trading fees can buy those BSQ tokens from a contributor. When they buy BSQ tokens for BTC, the contributor is paid for their work, and the value transfer from producer to consumer is complete! When a trader pays trading fees with BSQ, those BSQ tokens are burned or "decolored" and '''BSQ supply is decreased'''. This process of creating and destroying BSQ tokens enables a sort of [https://docs.bisq.network/dao/phase-zero.html#how-bsq-decentralizes-compensation-and-enables-monetary-policy monetary policy] controlled by Bisq stakeholders and traders.

In this way, there is no need for a central entity to collect and distribute revenue: the BSQ token enables a transfer of value from producer to consumer without any single entity controlling any aspect of the decision-making or distribution process.
{{Admonition_Note|<big>'''Note on BTC revenues'''</big>
In the past, before the Bisq DAO launch and before the integration of Bisq’s new trade protocol, trading fees were only collected in BTC and only went to arbitrators. There was no mechanism to distribute them to other contributors. The DAO solves this distribution problem with BSQ through the process outlined above.
But since traders can still pay trading fees with BTC, where do those BTC fees go?
BTC fees go to a [https://github.com/bisq-network/roles/issues/80 bitcoin "donation" address] held by a bonded contributor, who uses the BTC to buy BSQ on a regular basis to distribute the BTC fees to stakeholders, and the BSQ obtained is [https://github.com/bisq-network/proposals/issues/55 burned].}}

=== Determine strategy ===

Another point of centralization in traditional organizations is with strategy. How can a project determine strategy without some form of designated leadership: an executive, manager, or leader to give direction and allocate resources?

The Bisq DAO beats this tradition with collective decision-making on strategy and other matters through '''weighted voting''' based on BSQ stake.

Here’s how it works: any stakeholder can make a proposal in the DAO. It can be anything: a change in a trading parameter, a new bonded role, or even something more generic like an adjustment of overall project strategy. Stakeholders vote on the proposal, and their voting weight is based on BSQ stake, through a combination of two metrics:

# amount of BSQ committed to a particular vote
# amount of BSQ earned over time through contributions

Taking both metrics into account discourages deep-pocketed whales from suddenly seizing control of the project, while still valuing dedicated stakeholders with consistent contributions over time. It brings about a '''strict meritocracy''' in which people need to somehow buy in to the Bisq project in order to take part in its governance, and the more significant their stake, the stronger their voice.

In this way, there is no need to rely on a single leadership team for direction: the community collectively manages itself.

=== Ensure honesty in high-trust roles ===

Despite the Bisq project’s attempts to resist concentrating control as much as possible, it’s impossible to avoid in some places. Domain name owners, social account admins, mediators, various node operators: these are all roles that must exist, but necessarily retain significant control and require a high degree of trust.

Part of the benefit of a centralized team of thoroughly-vetted people reliant on a paycheck, as is the case in most companies, is that the risk of trusting people with significant responsibility is lower: they have a lot to lose if the company finds they have violated their integrity and engaged in foul play.

This dynamic can be reproduced—at least partly—in a project without a central authority through '''bonding'''. The concept is simple enough: create skin in the game. Require that a person interested in taking on a high-trust role post a bond that’s high enough to discourage them from engaging in foul play.

But what happens if that person goes rogue? In a project without central authority, who decides when they’ve crossed the line, and what their fate should be?

As with strategy and compensation, the community decides through voting. Anyone who suspects foul play can make a case for confiscating a bond with a new proposal, and stakeholders vote to determine an outcome.

{{Admonition_Warn|Confiscating a bond is a harsh penalty which should not be taken lightly. Therefore, the Bisq DAO makes confiscation proposals especially hard to approve: they require a quorum of at least 200,000 BSQ and 85% acceptance to pass (instead of the typical >50%).}}

In this way, the risk that people in high-trust roles misbehave is minimized, and the community has access to a responsible mechanism for handling such a scenario in cases that warrant it.

== Learn more ==

For more information on how you can use the DAO to trade/contributor, how it works, it's technical foundations, etc. please see the [[Decentralized_autonomous_organization|Decentralized Autonomous Organization]] page.

Introduction to the DAO

2020-09-18T15:46:13Z

Bayer: /* Earn and distribute revenue */

== Introduction ==

=== What is a DAO? ===

Conventional entities such as for-profit and non-profit corporations must be sanctioned by the state: they are legal entities registered in particular jurisdictions. No matter how big or small or virtuous or innovative they are, they cannot operate without state approval. In return for this approval, the entity is endowed with rights (e.g., limited liability) and responsibilities (e.g., taxes).

A '''decentralized autonomous organization (DAO)''' is just a generic term for a governance model sanctioned by software: code defines conventions for governing the project irrespective of the stance of the state.

{{Admonition_Note|We say a DAO’s governance model must be sanctioned by software, not necessarily controlled by software. The Bisq DAO, for example, is not controlled by software: software merely provides a framework for the people involved with the Bisq project to (collectively) manage the software itself. The Bisq DAO operates on the idea that '''code is not law'''. Code is written by humans to provide a service to other humans, so it should be accountable to humans too. }}

The universe of DAOs is diverse. Just as companies come in many shapes and sizes, and some companies are scammy, fraudulent, or just poorly managed—that’s no reason to assume all companies are the same way. It’s the same with DAOs: some DAOs haven’t worked out so well, but others might turn out differently.

== The Bisq DAO ==

The Bisq DAO forgoes a system where governance is dictated by the rigid rules of software in favor of a self-contained economy where governance is guided by software but ultimately determined by the collective, subjective judgments of its community.

It achieves this by introducing a unit of value called the '''BSQ token''' that enables Bisq stakeholders—contributors, traders, or anyone who owns BSQ—to make subjective value judgments. This token underlies all actions in the DAO.

[https://www.youtube.com/watch?v=pNvOZlIDYEQ&feature=emb_logo Click here for a quick introductory video on the what & why of the Bisq DAO]

=== BSQ Token ===

A BSQ token is a '''[https://en.bitcoin.it/wiki/Colored_Coins colored coin]''' on the Bitcoin blockchain. More plainly, a BSQ token is merely a few satoshis with some additional properties that identify it as BSQ in Bisq software. Outside Bisq, a BSQ token just looks like a few satoshis. But on Bisq, the additional properties have the following results:

# The satoshis take on the market value of a BSQ token
# The owner of the satoshis is endowed with power to participate in various Bisq governance functions

See it for yourself: here’s a [https://blockstream.info/nojs/tx/0243f99c848de4f53cb29157d10bf1cdbfcf4219f84e9997dd3cac9244ab7242/ BSQ transaction on an ordinary block explorer], and [https://mempool.space/bisq/tx/0243f99c848de4f53cb29157d10bf1cdbfcf4219f84e9997dd3cac9244ab7242 here’s that same transaction on a BSQ block explorer].

The value of a BSQ token is determined by the market as stakeholders buy and sell tokens to perform various functions in the DAO. Because BSQ tokens are only recognized by Bisq software, BSQ trading can only happen in Bisq software.

{{Admonition_Note|The BSQ token is not associated with any kind of initial coin offering (ICO) or capital-raising initiative. It’s merely a tool to decentralize the governance of the already-functional Bisq exchange service. As of December 2018, Bisq has facilitated over 19,000 trades without major incident since it went into production in April 2016.}}

You can learn more about [https://www.youtube.com/watch?v=68_DU1c0Cac colored coins] here in this interview. Technical details of BSQ tokens are available [[https://bisq.wiki/DAO_technical_overview|here]].

=== Overview ===

Here’s a graphical overview of how the DAO works at a high level:

[[File:User-dao-diagram.png|700px|thumb|left]]

<div style="clear: both;"></div>

Let’s observe some of the dynamics of this system:

* Contributors ''maintain'' Bisq through valuable work
* Traders ''use'' Bisq to buy and sell bitcoin and other cryptocurrencies
* Contributors ''earn'' BSQ tokens when their compensation requests are approved through voting
* Traders ''buy'' BSQ tokens in order to pay lower trading fees
* Stakeholders ''vote'' on compensation requests
* Contributors can ''lock'' a bond in BSQ to ensure integrity in high-trust roles

Now let’s see how these dynamics enable the Bisq DAO to provide 3 core governance functions without any central points of authority.

=== Earn and distribute revenue ===

Every project needs to be financially sustainable to fund ongoing operations and development. But traditional means of handling revenue and revenue distribution are necessarily centralized—any receiving address or account must be owned by one person, or a small group; determining how much a person should be paid must be determined by one person, or a small group; etc.

'''Contributors produce, creating BSQ'''

In the Bisq DAO, trading fees are collected from traders and distributed to contributors, but there is no central authority to do this. Here’s how it works: after a Bisq contributor does work, they file a '''compensation request''' in the DAO with a description of what they did and how much BSQ they want in return. Then, stakeholders (who are other contributors, traders, and anyone else with BSQ) vote for/against the request. If the request is approved, the contributor is issued new BSQ in the amount they requested and '''BSQ supply is increased'''.

{{Admonition_Note|'''<big>Where does new BSQ actually come from?</big>''' Recall that a BSQ token is merely colored bitcoin. When a contributor makes their compensation request in the DAO, they must also include the tiny amount of bitcoin to be '''colored''' as BSQ (the [[DAO_technical_overview|spec]] requires 100 satoshis). So if a contributor requests 1,000 BSQ, they will need to include (100 * 1,000 equals 100,000 satoshis) with their compensation request, just about 10 USD at a rate of (10,000 USD/BTC).If their request is approved, those satoshis are '''colored''' and recognized as 1,000 valid BSQ tokens on Bisq. Assuming a BSQ market value of 1 USD (exact value will fluctuate), the contributor will have been granted 1,000 USD worth of BSQ for a negligible cost of 10 USD.}}

'''Traders consume, burning BSQ'''

Then, a trader looking for lower trading fees can buy those BSQ tokens from a contributor. When they buy BSQ tokens for BTC, the contributor is paid for their work, and the value transfer from producer to consumer is complete! When a trader pays trading fees with BSQ, those BSQ tokens are burned or "decolored" and '''BSQ supply is decreased'''. This process of creating and destroying BSQ tokens enables a sort of [https://docs.bisq.network/dao/phase-zero.html#how-bsq-decentralizes-compensation-and-enables-monetary-policy monetary policy] controlled by Bisq stakeholders and traders.

In this way, there is no need for a central entity to collect and distribute revenue: the BSQ token enables a transfer of value from producer to consumer without any single entity controlling any aspect of the decision-making or distribution process.
{{Admonition_Note|<big>'''Note on BTC revenues'''</big>
In the past, before the Bisq DAO launch and before the integration of Bisq’s new trade protocol, trading fees were only collected in BTC and only went to arbitrators. There was no mechanism to distribute them to other contributors. The DAO solves this distribution problem with BSQ through the process outlined above.
But since traders can still pay trading fees with BTC, where do those BTC fees go?
BTC fees go to a [https://github.com/bisq-network/roles/issues/80 bitcoin "donation" address] held by a bonded contributor, who uses the BTC to buy BSQ on a regular basis to distribute the BTC fees to stakeholders, and the BSQ obtained is [https://github.com/bisq-network/proposals/issues/55 burned].}}

=== Determine strategy ===

Another point of centralization in traditional organizations is with strategy. How can a project determine strategy without some form of designated leadership: an executive, manager, or leader to give direction and allocate resources?

The Bisq DAO beats this tradition with collective decision-making on strategy and other matters through '''weighted voting''' based on BSQ stake.

Here’s how it works: any stakeholder can make a proposal in the DAO. It can be anything: a change in a trading parameter, a new bonded role, or even something more generic like an adjustment of overall project strategy. Stakeholders vote on the proposal, and their voting weight is based on BSQ stake, through a combination of two metrics:

# amount of BSQ committed to a particular vote
# amount of BSQ earned over time through contributions

Taking both metrics into account discourages deep-pocketed whales from suddenly seizing control of the project, while still valuing dedicated stakeholders with consistent contributions over time. It brings about a '''strict meritocracy''' in which people need to somehow buy in to the Bisq project in order to take part in its governance, and the more significant their stake, the stronger their voice.

In this way, there is no need to rely on a single leadership team for direction: the community collectively manages itself.

=== Ensure honesty in high-trust roles ===

Despite the Bisq project’s attempts to resist concentrating control as much as possible, it’s impossible to avoid in some places. Domain name owners, social account admins, mediators, various node operators: these are all roles that must exist, but necessarily retain significant control and require a high degree of trust.

Part of the benefit of a centralized team of thoroughly-vetted people reliant on a paycheck, as is the case in most companies, is that the risk of trusting people with significant responsibility is lower: they have a lot to lose if the company finds they have violated their integrity and engaged in foul play.

This dynamic can be reproduced—at least partly—in a project without a central authority through '''bonding'''. The concept is simple enough: create skin in the game. Require that a person interested in taking on a high-trust role post a bond that’s high enough to discourage them from engaging in foul play.

But what happens if that person goes rogue? In a project without central authority, who decides when they’ve crossed the line, and what their fate should be?

As with strategy and compensation, the community decides through voting. Anyone who suspects foul play can make a case for confiscating a bond with a new proposal, and stakeholders vote to determine an outcome.

{{Admonition_Warn|Confiscating a bond is a harsh penalty which should not be taken lightly. Therefore, the Bisq DAO makes confiscation proposals especially hard to approve: they require a quorum of at least 200,000 BSQ and 85% acceptance to pass (instead of the typical >50%).}}

In this way, the risk that people in high-trust roles misbehave is minimized, and the community has access to a responsible mechanism for handling such a scenario in cases that warrant it.

== Learn more ==

For more information on how you can use the DAO to trade/contributor, how it works, it's technical foundations, etc. please see the [[Decentralized_autonomous_organization|Decentralized Autonomous Organization]] page.

Introduction to the DAO

2020-09-18T15:45:49Z

Bayer: /* Earn and distribute revenue */

== Introduction ==

=== What is a DAO? ===

Conventional entities such as for-profit and non-profit corporations must be sanctioned by the state: they are legal entities registered in particular jurisdictions. No matter how big or small or virtuous or innovative they are, they cannot operate without state approval. In return for this approval, the entity is endowed with rights (e.g., limited liability) and responsibilities (e.g., taxes).

A '''decentralized autonomous organization (DAO)''' is just a generic term for a governance model sanctioned by software: code defines conventions for governing the project irrespective of the stance of the state.

{{Admonition_Note|We say a DAO’s governance model must be sanctioned by software, not necessarily controlled by software. The Bisq DAO, for example, is not controlled by software: software merely provides a framework for the people involved with the Bisq project to (collectively) manage the software itself. The Bisq DAO operates on the idea that '''code is not law'''. Code is written by humans to provide a service to other humans, so it should be accountable to humans too. }}

The universe of DAOs is diverse. Just as companies come in many shapes and sizes, and some companies are scammy, fraudulent, or just poorly managed—that’s no reason to assume all companies are the same way. It’s the same with DAOs: some DAOs haven’t worked out so well, but others might turn out differently.

== The Bisq DAO ==

The Bisq DAO forgoes a system where governance is dictated by the rigid rules of software in favor of a self-contained economy where governance is guided by software but ultimately determined by the collective, subjective judgments of its community.

It achieves this by introducing a unit of value called the '''BSQ token''' that enables Bisq stakeholders—contributors, traders, or anyone who owns BSQ—to make subjective value judgments. This token underlies all actions in the DAO.

[https://www.youtube.com/watch?v=pNvOZlIDYEQ&feature=emb_logo Click here for a quick introductory video on the what & why of the Bisq DAO]

=== BSQ Token ===

A BSQ token is a '''[https://en.bitcoin.it/wiki/Colored_Coins colored coin]''' on the Bitcoin blockchain. More plainly, a BSQ token is merely a few satoshis with some additional properties that identify it as BSQ in Bisq software. Outside Bisq, a BSQ token just looks like a few satoshis. But on Bisq, the additional properties have the following results:

# The satoshis take on the market value of a BSQ token
# The owner of the satoshis is endowed with power to participate in various Bisq governance functions

See it for yourself: here’s a [https://blockstream.info/nojs/tx/0243f99c848de4f53cb29157d10bf1cdbfcf4219f84e9997dd3cac9244ab7242/ BSQ transaction on an ordinary block explorer], and [https://mempool.space/bisq/tx/0243f99c848de4f53cb29157d10bf1cdbfcf4219f84e9997dd3cac9244ab7242 here’s that same transaction on a BSQ block explorer].

The value of a BSQ token is determined by the market as stakeholders buy and sell tokens to perform various functions in the DAO. Because BSQ tokens are only recognized by Bisq software, BSQ trading can only happen in Bisq software.

{{Admonition_Note|The BSQ token is not associated with any kind of initial coin offering (ICO) or capital-raising initiative. It’s merely a tool to decentralize the governance of the already-functional Bisq exchange service. As of December 2018, Bisq has facilitated over 19,000 trades without major incident since it went into production in April 2016.}}

You can learn more about [https://www.youtube.com/watch?v=68_DU1c0Cac colored coins] here in this interview. Technical details of BSQ tokens are available [[https://bisq.wiki/DAO_technical_overview|here]].

=== Overview ===

Here’s a graphical overview of how the DAO works at a high level:

[[File:User-dao-diagram.png|700px|thumb|left]]

<div style="clear: both;"></div>

Let’s observe some of the dynamics of this system:

* Contributors ''maintain'' Bisq through valuable work
* Traders ''use'' Bisq to buy and sell bitcoin and other cryptocurrencies
* Contributors ''earn'' BSQ tokens when their compensation requests are approved through voting
* Traders ''buy'' BSQ tokens in order to pay lower trading fees
* Stakeholders ''vote'' on compensation requests
* Contributors can ''lock'' a bond in BSQ to ensure integrity in high-trust roles

Now let’s see how these dynamics enable the Bisq DAO to provide 3 core governance functions without any central points of authority.

=== Earn and distribute revenue ===

Every project needs to be financially sustainable to fund ongoing operations and development. But traditional means of handling revenue and revenue distribution are necessarily centralized—any receiving address or account must be owned by one person, or a small group; determining how much a person should be paid must be determined by one person, or a small group; etc.

'''Contributors produce, creating BSQ'''

In the Bisq DAO, trading fees are collected from traders and distributed to contributors, but there is no central authority to do this. Here’s how it works: after a Bisq contributor does work, they file a '''compensation request''' in the DAO with a description of what they did and how much BSQ they want in return. Then, stakeholders (who are other contributors, traders, and anyone else with BSQ) vote for/against the request. If the request is approved, the contributor is issued new BSQ in the amount they requested and '''BSQ supply is increased'''.

{{Admonition_Note|<big>Where does new BSQ actually come from?</big>'''Bold text''' Recall that a BSQ token is merely colored bitcoin. When a contributor makes their compensation request in the DAO, they must also include the tiny amount of bitcoin to be '''colored''' as BSQ (the [[DAO_technical_overview|spec]] requires 100 satoshis). So if a contributor requests 1,000 BSQ, they will need to include (100 * 1,000 equals 100,000 satoshis) with their compensation request, just about 10 USD at a rate of (10,000 USD/BTC).If their request is approved, those satoshis are '''colored''' and recognized as 1,000 valid BSQ tokens on Bisq. Assuming a BSQ market value of 1 USD (exact value will fluctuate), the contributor will have been granted 1,000 USD worth of BSQ for a negligible cost of 10 USD.}}

'''Traders consume, burning BSQ'''

Then, a trader looking for lower trading fees can buy those BSQ tokens from a contributor. When they buy BSQ tokens for BTC, the contributor is paid for their work, and the value transfer from producer to consumer is complete! When a trader pays trading fees with BSQ, those BSQ tokens are burned or "decolored" and '''BSQ supply is decreased'''. This process of creating and destroying BSQ tokens enables a sort of [https://docs.bisq.network/dao/phase-zero.html#how-bsq-decentralizes-compensation-and-enables-monetary-policy monetary policy] controlled by Bisq stakeholders and traders.

In this way, there is no need for a central entity to collect and distribute revenue: the BSQ token enables a transfer of value from producer to consumer without any single entity controlling any aspect of the decision-making or distribution process.
{{Admonition_Note|<big>'''Note on BTC revenues'''</big>
In the past, before the Bisq DAO launch and before the integration of Bisq’s new trade protocol, trading fees were only collected in BTC and only went to arbitrators. There was no mechanism to distribute them to other contributors. The DAO solves this distribution problem with BSQ through the process outlined above.
But since traders can still pay trading fees with BTC, where do those BTC fees go?
BTC fees go to a [https://github.com/bisq-network/roles/issues/80 bitcoin "donation" address] held by a bonded contributor, who uses the BTC to buy BSQ on a regular basis to distribute the BTC fees to stakeholders, and the BSQ obtained is [https://github.com/bisq-network/proposals/issues/55 burned].}}

=== Determine strategy ===

Another point of centralization in traditional organizations is with strategy. How can a project determine strategy without some form of designated leadership: an executive, manager, or leader to give direction and allocate resources?

The Bisq DAO beats this tradition with collective decision-making on strategy and other matters through '''weighted voting''' based on BSQ stake.

Here’s how it works: any stakeholder can make a proposal in the DAO. It can be anything: a change in a trading parameter, a new bonded role, or even something more generic like an adjustment of overall project strategy. Stakeholders vote on the proposal, and their voting weight is based on BSQ stake, through a combination of two metrics:

# amount of BSQ committed to a particular vote
# amount of BSQ earned over time through contributions

Taking both metrics into account discourages deep-pocketed whales from suddenly seizing control of the project, while still valuing dedicated stakeholders with consistent contributions over time. It brings about a '''strict meritocracy''' in which people need to somehow buy in to the Bisq project in order to take part in its governance, and the more significant their stake, the stronger their voice.

In this way, there is no need to rely on a single leadership team for direction: the community collectively manages itself.

=== Ensure honesty in high-trust roles ===

Despite the Bisq project’s attempts to resist concentrating control as much as possible, it’s impossible to avoid in some places. Domain name owners, social account admins, mediators, various node operators: these are all roles that must exist, but necessarily retain significant control and require a high degree of trust.

Part of the benefit of a centralized team of thoroughly-vetted people reliant on a paycheck, as is the case in most companies, is that the risk of trusting people with significant responsibility is lower: they have a lot to lose if the company finds they have violated their integrity and engaged in foul play.

This dynamic can be reproduced—at least partly—in a project without a central authority through '''bonding'''. The concept is simple enough: create skin in the game. Require that a person interested in taking on a high-trust role post a bond that’s high enough to discourage them from engaging in foul play.

But what happens if that person goes rogue? In a project without central authority, who decides when they’ve crossed the line, and what their fate should be?

As with strategy and compensation, the community decides through voting. Anyone who suspects foul play can make a case for confiscating a bond with a new proposal, and stakeholders vote to determine an outcome.

{{Admonition_Warn|Confiscating a bond is a harsh penalty which should not be taken lightly. Therefore, the Bisq DAO makes confiscation proposals especially hard to approve: they require a quorum of at least 200,000 BSQ and 85% acceptance to pass (instead of the typical >50%).}}

In this way, the risk that people in high-trust roles misbehave is minimized, and the community has access to a responsible mechanism for handling such a scenario in cases that warrant it.

== Learn more ==

For more information on how you can use the DAO to trade/contributor, how it works, it's technical foundations, etc. please see the [[Decentralized_autonomous_organization|Decentralized Autonomous Organization]] page.