Sometimes Bisq trades don't go smoothly, and '''dispute resolution''' is required to determine an outcome.

Dispute resolution on Bisq has 3 formal levels: trader chat, mediation, and arbitration.

Most issues on Bisq are minor and easily resolved when traders communicate with each other. Mediation is intended to resolve the vast majority of remaining issues. Arbitration is a rare last resort measure for extreme scenarios.

__TOC__

= Note for long-time users =

Bisq v1.2 introduced a new trade protocol which changed 2 key elements:
* trade funds ([[Security_deposit|deposits]], trade amount, and [[Trading_fees|fees]]) are locked in a '''2-of-2 multisig escrow''' (was 2-of-3 before)
* a time-locked transaction is signed when the trade's deposit transaction is published ([[#Level_3:_Arbitration|more on this below]])

Combined with trader chat, mediation, and arbitration, these 2 elements power Bisq’s dispute resolution.

Despite still being called "arbitration", please note that this new arbitration is very different from before: arbitrators no longer have a key to sign deposit funds to either peer. Refer to the article on [[Arbitration]] for further details in addition to the process summary below.

= Level 1: Trader chat =

If you're having any issues completing a trade, or if you just want to keep your counterparty informed (e.g., in case you're delayed completing your end of the deal), you can send your counterparty a message through Bisq's end-to-end encrypted chat mechanism.

This allows traders to communicate with each other throughout the course of a trade to resolve potential trade issues quickly without involving a third party like a mediator or arbitrator.

[[File:Start-trader-chat.png|600px|thumb|left|Click this icon to start trader chat.]]

<div style="clear: both;"></div>

== Trader chat rules ==

=== Responding to chat messages is always optional ===

If you’re not comfortable responding to chat messages, don’t respond. You have no obligation to communicate over this medium.

=== Do not send links of any kind ===

For safety. If you want to send a link, describe it instead.

''Not allowed:''

<nowiki>https://blockstream.info/tx/4b5417ec5ab6112bedf539c3b4f5a806ed539542d8b717e1c4470aa3180edce5</nowiki>

''Allowed:''

Hey, could you look up txid 4b5417ec5ab6112bedf539c3b4f5a806ed539542d8b717e1c4470aa3180edce5 in your favorite block explorer?

=== Do not encourage trading away from Bisq ===

Trades away from Bisq lack Bisq’s security mechanisms. If something goes wrong with an off-Bisq trade, you’re on your own.

=== Do not send sensitive information like private keys, passwords, etc ===

Such information is ''never'' wise to share in general, and is never needed to solve trade disputes on Bisq.

=== Do not engage in foul play ===

Any attempts to exploit counterparties with social engineering scams, etc. are prohibited.

=== Respect a peer’s decision to avoid responding ===

If a peer seems unresponsive, or has signaled their intention to refrain from chatting, please respect it and don’t pressure them.

=== Keep conversation scope limited to the trade ===

Please don’t use Bisq’s trader chat as a general-purpose messenger. Unnecessary exchanges add unnecessary strain to Bisq’s peer-to-peer network.

=== Keep conversation friendly and respectful ===

Because friendlier traders resolve disputes quicker, and no one wants to deal with a jerk.

Hopefully, by following these rules, you can work directly with your trading peer to solve issues quickly and amicably.

= Level 2: Mediation =

If issues remain after chatting with the counterparty, you may need to engage a mediator.

'''Mediation can only be started after the trade period has ended.'''

[[File:Start-mediation.png|400px|thumb|left|Engage a mediator. This button only appears after the trade period has ended.]]

== How mediation works ==

Mediators evaluate a trade situation between two users and make a ''suggestion'' for a payout. They do not have a key in the multisig escrow, so their suggested payout cannot be authoritative.

Trading peers should do their best to cooperate with the mediator and provide information they request, and are required to respond to messages within 48 hours.

Likewise, mediators may take up to 48 hours to respond to your messages. Please don’t panic if you don’t hear back immediately.

When a mediator suggests a payout:

* if both peers agree with the suggestion, the payout is completed and the trade is closed
* if one or both peers disagree with the suggestion, a peer can choose to engage an arbitrator to re-evaluate the situation (see [[#Level_3:_Arbitration|arbitration]] below)

== When are you eligible for a penalty? ==

When failing to complete a transaction, you are eligible for a penalty on your deposit. details [https://bisq.wiki/Table_of_penalties here]

== Who are mediators? ==

Mediator roles are [https://docs.bisq.network/user-dao-intro.html#ensure-honesty-in-high-trust-roles bonded roles] in the Bisq DAO. Anyone can propose to become a mediator, but approval will depend on the candidate's familiarity with Bisq trading rules and the network’s need for more mediators at the time a proposal is made.

Once a proposal to become a mediator is approved by DAO voting, the mediator must lock a 10,000 BSQ bond to become active. This bond helps to ensure their continued availability and performance in the role, and can be confiscated by DAO voting in extreme circumstances (negligence, foul play, prolonged absence, etc).

You can see more details (current role owners, regular updates, etc) on the [https://github.com/bisq-network/roles/issues/83|mediator role issue].

= Level 3: Arbitration =

[[File:Engage-arbitrator-v116.png|400px|thumb|left|Reject mediator's suggestion in order to start arbitration.]]

Arbitration is the last formal layer of dispute resolution on Bisq. '''It is meant to be rare'''. If the measures described below sound extreme, it’s because they are only meant to be employed for extreme circumstances.

Arbitration is only available when:

* one or both traders reject a mediator’s suggested resolution
* the time-locked transaction made at the start of the trade is published

The [[Arbitration#Time-Locked_Payout_Transaction|time-locked transaction]] sends ''all'' funds in the multisig escrow (i.e., those of both trading peers) to the [[Arbitration#Donation_Address|Bisq donation address]] ([https://github.com/bisq-network/roles/issues/80 owner of this address] is bonded and approved by DAO voting). This transaction can only be published 10 days after the deposit transaction is confirmed (for altcoin trades) or 20 days after the deposit transaction is confirmed (for fiat trades).

Think of this time-locked transaction as a "safeguard transaction" or a "fallback transaction"—it's a last-resort option to be exercised only if nothing else is working out.

{{Admonition_Note|The time-locked transaction is meant to encourage traders to quickly accept the mediator’s suggestion and discourage nonsensical appeals to arbitrators.

The [[Arbitration#Donation_Address|donation address]] is merely a destination for disputed bitcoin funds to be collected. Every month (approximately), this bitcoin is used to buy BSQ on the market and burn it. This reduces BSQ supply, allowing for new BSQ to be issued as reimbursement for deserving traders through arbitration with minimal impact on BSQ supply.

'''This dynamic essentially makes bitcoin confiscatable, enabling a sort of mutually assured destruction to drive dispute resolution on Bisq without trusted third parties.'''
}}

Practically, here’s how arbitration works:

# If you’re dissatisfied with the mediator’s suggestion and sure you are entitled to a better outcome, publish the time-locked transaction as soon as it’s possible and request arbitration.
# Collaborate with the arbitrator to clarify the details of your case.
# If the arbitrator sides with you, they will personally reimburse you.
# The arbitrator will then request reimbursement from the Bisq DAO for the reimbursements they’ve paid. This isn’t something you need to worry about as a trader, but it’s good to know how the process works on both sides.

Arbitrators are required to respond to messages within 5 days, so it may take a bit longer for them to respond than mediators (you should still respond to messages within 2 days).

= If all else fails =

One advantage of a flat, decentralized governance structure that encourages user involvement is that '''no user should ever feel hindered from receiving a fair trade outcome because of a single individual's decision'''. Bisq isn't a black-box corporation with inscrutable processes. It's an open software project that is governed openly.

Therefore, for whatever reason, if the process above doesn't work for you, you can [[Making_a_reimbursement_request|make a reimbursement request]] yourself in the Bisq DAO. The Bisq DAO—not any single individual—is the ultimate arbiter of policy and decision-making for all things Bisq.

In fact, [[Arbitration#New_Trade_Protocol|this is how arbitration will eventually be handled]] anyway.

Support Agent

2021-04-07T16:49:40Z

Leo816: /* Compensation */

__TOC__

==Requirements==

What makes a great support agent?

* You're a Bisq user. You understand how to use it well enough to help others.
* You can be available for 10 hours or more per week to handle support cases.
* You're familiar with the existing [[Docs]] and [[Knowledge Base]] articles.

If you're interested in becoming a support agent, see the [[#Internship]] section below.

==Infrastructure==

Includes all of [[Support Team#Infrastructure]], plus the following:

=== Coverage calendar ===

The coverage calendar tracks shifts for each support agent, with the goal of achieving 24/7 coverage.

* [https://calendar.google.com/calendar/embed?src=u4eea6bffk10b76l2cmb86eqqc%40group.calendar.google.com&ctz=Europe%2FVienna Public HTML]
* [https://calendar.google.com/calendar/ical/u4eea6bffk10b76l2cmb86eqqc%40group.calendar.google.com/public/basic.ics iCal File]
* [https://calendar.google.com/calendar?cid=dTRlZWE2YmZmazEwYjc2bDJjbWI4NmVxcWNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ Google Calendar] (login required)

===Case tracking board===
* https://github.com/bisq-network/support/projects/2

===GitHub team===
* [https://github.com/orgs/bisq-network/teams/support-agents @bisq-network/support-agents] (includes l1, l2 and intern subteams)

===Role issue===
* [https://github.com/bisq-network/roles/issues/64 L1 Support Agent #64]

==Duties==

===Handle support cases===
If unable to solve the trade successfully you must gather the appropriate data before contacting a developer.

Required data to request support from '''developers''':

* Create a directory with the trade ID as name
* Add a short description in a plain text file of the problem/bug. Use BTC buyer/BTC seller if you refer to any trader. Ask user when the issue happened so its easier to find the issue in the logs.
* Ask them if they have done anything non-standard or had past issues.
* Add all available trade tx IDs of both traders as plain text to the report.
* Get a screenshot of the trade details window (click on trade ID). Tell users to only blur out the payment account details but not the tx IDs or other data. There is no relevant privacy issue with exposing trade ID, tx IDs or onion address.
* Add a screenshot from the mediators dispute details window. The contract as json data is not required initially and only needed if the dev requests it. The payment account data in the json file should be removed before handing over to a dev to protect traders privacy.
* Get all log files from both users (at Account/Backup there is a button for opening the data dir) - its up to 11 files.
* Put all logs from one user into a directory named buyer and seller
* Add a screenshot of both traders first chat message (system message containing data like version number/OS,...)
* If there have been any error/warning popups request a screenshot of that as well.
* Zip all and send it in keybase as PM to a dev who has commited to work on it. Avoid adding it to the support channel as then nobody will feel responsible to work on it.

===Keep the coverage calendar up to date===

===Submit regular cycle reports===

==Rights==

* Writer access to the <code>bisq.support</code> Keybase subteam
* [https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level Triage] access to [[Support Team#Repositories]]
* Edit access to the [[#Coverage Calendar]]

==Policies==

===Time to response===

If you are on duty, it's your job to respond as promptly as possible to incoming user requests. The goal is to respond to all support inquiries in the <code>#support</code> channel within 1 hour of being asked and preferably much faster. This initial response need not actually ''resolve'' the user's issue, it is merely letting the user know that you've heard their question and that you'll be their primary support agent for this case.

===Sensitive user data===

Often support agents will need to ask users to share their logs with you or specific information about their offer or trade, such as trade ID, trade amounts, etc. This data should not be shared in any public channel and should be destroyed one month after the case is closed. Note that any such information that shared in the <code>bisq.support</code> subteam is automatically destroyed after 30 days.

==Processes==

===Internship===

Prospective support agents are asked to go through an internship process that lasts one DAO cycle (approximately one month). During this period, you'll perform the [[#Duties|duties]] of a support agent, but your contributions won't be eligible for compensation. This gives you a chance to get to know the ropes and for all parties involved to determine whether a support agent role is a good fit for you.

# Indicate in the <code>#support</code> channel that you're interested in interning as a Support Agent.
#* Say a bit about yourself and why you're interested in doing this work
#* Mention what days and times you'll be available to do this work
# The [[Support Team Lead]] will then:
#* Add you to the [https://github.com/orgs/bisq-network/teams/intern-support-agents @bisq-network/intern-support-agents] team
#* Add your requested shifts to the support coverage calendar
#* Announce your internship:
#** with a message to the larger [https://github.com/orgs/bisq-network/teams/support @bisq-network/support] team
#** with a message in the <code>#support</code> channel
# After one full cycle of interning
#* Submit a [[Proposals|proposal]] to be added to the [https://github.com/orgs/bisq-network/teams/l1-support-agents @bisq-network/l1-support-agents] team
#* If your proposal is approved, the support team lead will promote you as per the process below.

===Using the coverage calendar===

===Case tracking===

==Knowledge base for support==

===Trade transaction structure===
If there are any issues with transactions or doubt if the deposit or delayed payout tx is correct you can check it in a block explorer by following the transactions outputs.

There are 5 diff. txs:
* Maker fee tx
* Taker fee tx
* Deposit tx
* Delayed payout tx (only get broadcast when arbitration gets opened)
* Payout tx

'''The 2 trade fee txs have as first output the trade fee.''' That goes either to one of the BTC receiver addresses ([1] and [2]) or to a BSQ change address of the user in case BSQ was used for the fee (the diff from BSQ input and change output is used for miner fee and is the burned BSQ).
'''The second output of both trade fee txs must lead to the (same) deposit tx'''. The deposit tx has an OpReturn and the first output is to a multiSig address (start with `3` if non-segwit or with `bc1` if segwit). There can be an optional change output if trade amount was smaller than max. offer amount, but there are never more then 2 outputs + opReturn.
If the delayed payout tx or the normal payout tx was published you see that the first output of the deposit tx (the MS output) is spent and lead to one of those txs as the single input. The normal payout tx has exactly 2 outputs, 1 address for each trader and that addresses are dispayed in the trade/ticket details.
The delayed payout tx need to have exactly 1 input and 1 output to one of the addresses listed in [1] and [3]. '''If arbitration is opened this tx MUST exist otherwise a refund MUST NOT be made'''. The input must be the multisig output of the deposit tx (we have a code to check if its the deposit tx of the trade and not any past one - if a popup in mediation or arbitration tells you that there is an issue, take it serious and contact devs for advice).

To check the txs (and addresses) use a block explorer which shows clearly the inputs and outputs, not all explorers have a very intuitive UI to follow the flows of txs. If you select the addresses like in the below screenshot you can see the flow pretty clearly.

[[File:Support Agent guidance 1.png|thumb]]

[[File:Support Agent guidance 3.png|thumb]]

[[File:Support Agent guidance 4.png|thumb]]

Checking if the trade fee tx leads to the deposit tx helps to quickly see if the trade funds are locked up and all is ok with the trade. If that is not the case the traders might have lost trade fee (if their trade fee tx is published - if one side is missing that user has not lost trade fee so no fee reimbursement is justified, such users need to do a SPV resync as the tx is likely committed in their wallet but not in the mempool due to too low fees or a bug at broadcast).

===One trade fee tx not found in mempool===
In case the miner fee was too low or due broadcast problems (bad network connectivity or bug) it can be that one of the trade fee txs is not getting confirmed or has not been broadcast.
After a few days unconfirmed tx gets removed from the bitcoin nodes mempool (size of mempool is a local setting for each node/explorer so it can be that its visible in some explorers but in others not).
In such cases the deposit tx cannot be confirmed as well. Instruct the trader who's tx was not confirmed that he does a SPV resync so that the tx gets cleaned from his local wallet.
Otherwise there is high risk that the change output gets used for another tx and that will fail then as well. Best to deactivate all open offers to avoid that a taker could take an offer before the wallet is resynced.
The trader who has the confirmed trade fee tx has lost his trade fee and can request for reimbursement.

===SPV resync===
SPV resync tends to be recommened too often in support.
SPV resync can be quite heavy and is not a great user experience to do, so only recommend if really needed.
How long a SPV takes depends on the age of the wallet and the number of transactions.
Old wallets with many transactions can take a day or even more. Usually with a fresh empty wallet its about some minutes up to 1 hour.
It is faster if the user runs a local BTC node (not pruned). It also depends on internet connection and amount of CPU/RAM. CPU will be maxed out during sync.

SPV resync is needed if there is a transaction in the wallet which never got confirmed. You can check for that by looking up the tx in several block explorers, if its not found in any then its pretty sure that tx got removed from mempool. This is expected in case miner fee was too low or when the tx broadcast failed.
Another reason to do a SPV resync is when there is a message that the wallet contains a `double spend` tx. This is usually not intentional done by the user but due to some errors or reorgs in rare cases.
There might be other more rare error conditions, but for those I recommend to contact the devs before recommending a SPV resync as it will help as well to fix potential bugs.

If users do not get connected to the BTC network do NOT recommend SPV resync.
Potential reasons are:

* User runs Bitcoin node in not pruned mode
* Bitcoin node is not full synced when Bisq start (Bitcoin node need to always be full synced before starting Bisq)
* User had set custom BTC node in settings or prog arg and has changed his setup
* Connection issues
* Tor issues

===Connection issues===
In rare cases Tor can cause problems. If no connection can be created after several restarts and if user is sure to have normal connectivity he should clean the Tor files via `Settings/Network/Tor settings`. He should make a backup first and not do it manually. Deleting the hiddenservice directory would make his node inaccessible as he would create a new onion address! If there are no open offers/trades/disputes and user dont care to lose his local reputation it is not problematic to delete the onion priv key. In some rare cases that can help as well (I saw in rare cases the changing the onion address solved Tor connection issues).
Tor has some ddos protection which can lead to get flagged an IP address. We see that from time to time on seed nodes and its likely caused by too much traffic or some traffic pattern which Tor interprets as ddos. In such cases changing the IP should help. Using a VPN can help to check if thats the problem (I had it once myself that I could not use Tor anymore and only via VPN it worked). After a few weeks it was ok again so it seems those bans fade out over time. Testing with Tor browser is another option to see if Tor itself has issues (does not cover issues if the onion address or cache files).

If network speed is very low (< 2 Mbit/sec) there might be connection timouts. We improved some data requests already and will improve more in upcoming releases but specially at startup the BTC sync and getData requests can be a bit heavy, specially if Bisq was not used for a while. Doing repeated startups can help as some data gets persisted and at next request less data is required. Using a local Bitcoin node helps as well as the BTC sync is then not adding up to tor traffic.
If the user has not used Bisq since more then a month he should update to latest version and then delete some files in the `db` directory inside the data directory. Then those files get replaced by more recent ones which go shipped with the latest binary. that avoids to need to download the missing data from seed nodes (seed nodes have limits as well of amount of delivered data). Those files are:
* DaoStateStore
* SignedWitnessStore
* AccountAgeWitnessStore
* BlindVoteStore
* ProposalStore

Please note that deleting or manipulating files inside the db directory is usually not recommended and can cause severe problems! Some files are basically only cache files from public data like the ones above, those are not critical, but other data are local private data and would lead to a corrupted state or failed trades.

'''BTC Balance issues Connection issues'''
There is a wallet info tool which can be opened with cmd+j. There you see all the raw data of the wallet: Addresses, public and private keys, txs, balance of both BTC and BSQ. Can be useful for investigation.
Another option is the open the emergency wallet tool by cmd+e. There one can withdraw all available funds (not including locked up funds in multisig). The displayed balance there is the sum of
the available balance + reserved in offers balance.

It is not recommended to use the BTC private keys outside of Bisq. It always can be recovered from Bisq. I am not aware of any case where funds got lost. Spending BTC outside of Bisq can lead to failed taker offer attempts, failed trades or double spends in Bisq and can screw up the wallet.
For those who still want to do it here are the HD wallet paths:
BTC wallet segwit path is: M/44H/0H/1H
BTC wallet legacy path is: M/44H/0H/0H
BSQ wallet path is: M/44H/142H/0H

BSQ should never be used outside of Bisq as the risk to burn the BSQ is very high. A BSQ tx has very strict rules how it is constructed and small mistakes lead to lost BSQ.

===Backup===
* If a user reports a bug tell user to make a backup of data dir. This can help that relevant log files and rolling backups are still available later.
Rolling backup means that old files get deleted (e.g. bisq10.log is oldest log file) once the max. number files is reached, so we can only go back a certain depth back in history.
* Tell users to always make a full backup of the data dir. Seed node is only an emergency backup and if there are open trades funds are at risk (e.g. no communication possible with mediator/peer, or manual payout required).
* Every db and wallet file has a backup folder with the rolling backups. They are named with the unix epoch timestamp. Replace an existing file with a backup file should be done only in emergency cases and only if dev gives the advice.

'''Start over with a new data directory'''
See https://bisq.community/t/how-to-switch-to-a-new-data-directory/7583 for more details

'''Logs'''

Log files are pretty verbose and a big hard to interpret for no developers but a few useful information can be easily extraced:
If you search for `VERSION=` you can see the users version. It gets logged at startup. If the user has once updated there must never follow a lower version in flater log entries. Downgrade is not supported and caused severe problems at the segwit update. After 1.5.0 we protect that downgrade is not possible, but will only have affect in next version after 1.5.0.
If you look for an error search for ERROR (all uppercase). But as there are some non critical errors as well (e.g. caused from broken connections) its better to leave that interpretation to devs. If you post errors post the stacktrace as well if it is available or at least a few log lines before and after the error so it is easier to get an idea what caused it.

===Bug Reports===

'''References'''

[1] Bisq donation addresses:
Current Bisq fee receiver address: 38bZBj5peYS3Husdz7AH3gEUiUbYRD951t
Past fee receiver/donation addresses:
1BVxNn3T12veSK6DgqwU4Hdn7QHcDDRag7, 3EtUWqsGThPtjwUczw27YCo6EWvQdaPUyp, 3A8Zc1XioE2HRzYfbb5P8iemCS72M6vRJV

[2] Fee receiver addresses of victims from security incident:
1EKXx73oUhHaUh8JBimtiPGgHfwNmxYKAj
1HpvvMHcoXQsX85CjTsco5ZAAMoGu2Mze9
3EfRGckBQQuk7cpU7SwatPv8kFD1vALkTU
13sxMq8mTw7CTSqgGiMPfwo6ZDsVYrHLmR
19qA2BVPoyXDfHKVMovKG7SoxGY7xrBV8c
19BNi5EpZhgBBWAt5ka7xWpJpX2ZWJEYyq

[3] New receiver address for delayed payout tx (no DAO param change yet done but will be activated soon):
34VLFgtFKAtwTdZ5rengTT2g2zC99sWQLC

===Escalation===

===Reporting===

===Compensation===
* Compensation Requests for L1 Support Agents have been established at a rate of 500 USD per cycle.
* This USD amount is not tied to a number of hours but it does require for the contributor to work at least 10 hours per week to be eligible.
* It is a fixed rate for all Support Agents and bonuses may apply when properly justified.
* Increase in any compensation amounts will be agreed through consensus by the Support Team and Support Team Lead.

[[Category:Roles]]

2021-03-25T15:59:22Z

Leo816:

Table of penalties

2021-03-25T15:46:17Z

Leo816:

'''This page is as stub'''

## BTC Buyer issues:

{| class="wikitable"
|-
! Buyer Issues !! Suggested Resolution
|-
| Buyer does not respond to mediator for 48 hours || Buyer loses 25% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer accepts trade but does not have the payment method needed (eg accepted Zelle trade but has no Zelle account) || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer wants to cancel trade due to problems with bank, lack of funds, change of mind, etc || Buyer loses 20% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer is asking for selfie, copy of ID of seller, home address. || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit. Seller can choose whether to provide or not. *Bisq should incentivize accounts that do not ask for any more information than necessary and penalize users that trade with banks that add for more information than necessary.
|-
| Buyer uses BTC, Bisq, Bitcoin, BTC Tx ID, etc as a payment reference || Buyer loses 25% of of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer claims they were unable to pay in time of payment window due to Bisq wallet being corrupted and needing to resync, unable to log into Bisq, other problem. | Buyer provides evidence that they were unable to access Bisq (Git Hub issue / Keybase chat etc). If unable Buyer loses 25% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer uses unagreed potentially concerning payment reference that such as 'payment for services', 'house rewire', 'consultancy' || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer uses unagreed innocuous payment reference that such as holiday fund, flowers without agreement || Buyer loses 5% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer attempts to debit sellers account using their bank details. || Buyer loses 100% of of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer raises request for refund from Revolt / TransferWise due to buyer using their account to sell them Bitcoin. || Buyer loses 100% of of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer makes payment to wrong account that have previously used to trade with the seller || Buyer loses 5% of the trade amount. Buyer retains the rest of their security deposit. Seller has the option to refund buyer.
|-
| Buyer makes payment from an account with a account number than their payment methods || Buyer retains the rest of their security deposit
|-
| Buyer makes payment from an account with a different name || Buyer loses 25% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer takes SEPA payment and then sends payment via SWIFT, or takes SEPA payment then send via TransferWise etc || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer takes altcoin offer and then sends altcoin with a low fee that gets held up in the blockchain.|| Buyer has the option to do CPFP or similar. If late buyer loses the following; 0-24 hours late: Buyer loses 2.5% of the trade amount., 24-48 hours late: Buyer loses 5% of the trade amount, 48-72 hours late: Buyer loses 7.5% of the trade amount, 72-96 hours late: Buyer loses 10% of the trade amount. Any payment by buyer and seller has option to refund buyer.
|-
| Buyer does not make payment in trade window || If late buyer loses the following; 0-24 hours late: Buyer loses 5% of the trade amount., 24-48 hours late: Buyer loses 10% of the trade amount, 48-72 hours late: Buyer loses 15% of the trade amount.
|-
| Buyer makes payment from an account with a different name, account number than their payment methods || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit. Any late payment by buyer and seller has option to refund buyer.
|-
| Buyer made a mistake they actually meant to sell not buy BTC. || Buyer has the option to complete the trade within the trade window. If they fail to do this Buyer loses the following; 0-24 hours late: Buyer loses 2.5% of the trade amount, 24-48 hours late: Buyer loses 5% of the trade amount, 48-72 hours late: Buyer loses 7.5% of the trade amount, 72-96 hours late: Buyer loses 10% of the trade amount. Any late payment by buyer and seller has option to refund buyer. This is to prevent option buying.
|-
| Buyer sends random / incorrect payment amount. || uyer has the option to send the correct amount within the trade window. If they fail to do this Buyer loses the following; 0-24 hours late: Buyer loses 2.5% of the trade amount, 24-48 hours late: Buyer loses 5% of the trade amount, 48-72 hours late: Buyer loses 7.5% of the trade amount, 72-96 hours late: Buyer loses 10% of the trade amount. Any late full payment by buyer and seller has option to refund buyer.
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|}
| ------------- | ------------- |

|

| Buyer sends random / incorrect payment amount. | Buyer has the option to send the correct amount within the trade window. If they fail to do this Buyer loses the following; 0-24 hours late: Buyer loses 2.5% of the trade amount, 24-48 hours late: Buyer loses 5% of the trade amount, 48-72 hours late: Buyer loses 7.5% of the trade amount, 72-96 hours late: Buyer loses 10% of the trade amount. Any late full payment by buyer and seller has option to refund buyer. |

## BTC Seller issues

| BTC Seller Issues | Suggested resolution |
| ------------- | ------------- |
| Seller does not respond to mediator for 48 hours | Seller loses 25% of the trade amount. Seller retains the rest of their security deposit. |
| Seller does not have the payment method needed (eg accepted Zelle trade but has no Zelle account) | Seller loses 10% of the trade amount. Seller retains the rest of their security deposit. |
| Seller wants to cancel trade due to problems with bank | Seller loses 20% of the trade amount. Seller retains the rest of their security deposit. |
| Seller is asking for selfie, copy of ID of buyer, home address. | Seller loses 10% of the trade amount. Seller retains the rest of their security deposit. Seller can choose whether to provide or not. *Bisq should incentivize accounts that do not ask for any more information than necessary and penalize users that trade with banks that add for more information than necessary. |
| Seller claims they were unable to release BTC in time of payment window due to Bisq wallet being corrupted and needing to resync, unable to log into Bisq, other problem. | Seller provides evidence that they were unable to access Bisq (Git Hub issue / Keybase chat etc). If unable Seller loses 25% of the trade amount. Seller retains the rest of their security deposit. |
| Seller attempts to debit buyer's account using their bank details. | Seller loses 100% of of the trade amount. Seller retains the rest of their security deposit. |
| Seller raises mediation in error then completes release of BTC outside of trade window | Seller loses the following; 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |
| Seller accepts SEPA instant trade but is unable to receive a SEPA Instant payment at they only have a SEPA account | If BTC release occurs outside of payment window, Seller loses 2.5% of the trade amount., 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |
| Seller does not release BTC in trade window | If late Seller loses the following; 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |
| Seller made a mistake they actually meant to buy not sell BTC, but offer was taken. | Seller has the option to complete the trade within the trade window. If they fail to do this Seller loses the following; 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |

Table of penalties

2021-03-24T16:59:48Z

Leo816: Created page with "## BTC Buyer issues: {| class="wikitable" |- ! Buyer Issues !! Suggested Resolution |- | Buyer does not respond to mediator for 48 hours || Buyer loses 25% of the trade amoun..."

## BTC Buyer issues:

{| class="wikitable"
|-
! Buyer Issues !! Suggested Resolution
|-
| Buyer does not respond to mediator for 48 hours || Buyer loses 25% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer accepts trade but does not have the payment method needed (eg accepted Zelle trade but has no Zelle account) || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer wants to cancel trade due to problems with bank, lack of funds, change of mind, etc || Buyer loses 20% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer is asking for selfie, copy of ID of seller, home address. || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit. Seller can choose whether to provide or not. *Bisq should incentivize accounts that do not ask for any more information than necessary and penalize users that trade with banks that add for more information than necessary.
|-
| Buyer uses BTC, Bisq, Bitcoin, BTC Tx ID, etc as a payment reference || Buyer loses 25% of of the trade amount. Buyer retains the rest of their security deposit. |
| Buyer claims they were unable to pay in time of payment window due to Bisq wallet being corrupted and needing to resync, unable to log into Bisq, other problem. | Buyer provides evidence that they were unable to access Bisq (Git Hub issue / Keybase chat etc). If unable Buyer loses 25% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer uses unagreed potentially concerning payment reference that such as 'payment for services', 'house rewire', 'consultancy' || Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer uses unagreed innocuous payment reference that such as holiday fund, flowers without agreement || Buyer loses 5% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer attempts to debit sellers account using their bank details. || Buyer loses 100% of of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer raises request for refund from Revolt / TransferWise due to buyer using their account to sell them Bitcoin. || Buyer loses 100% of of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer makes payment to wrong account that have previously used to trade with the seller || Buyer loses 5% of the trade amount. Buyer retains the rest of their security deposit. Seller has the option to refund buyer.
|-
| Buyer makes payment from an account with a account number than their payment methods || Buyer retains the rest of their security deposit
|-
| Buyer makes payment from an account with a different name || Buyer loses 25% of the trade amount. Buyer retains the rest of their security deposit.
|-
| Buyer takes SEPA payment and then sends payment via SWIFT, or takes SEPA payment then send via TransferWise etc || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|-
| Example || Example
|}
| ------------- | ------------- |

| Buyer makes payment from an account with a account number than their payment methods | Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit. |
| Buyer makes payment from an account with a different name | Buyer loses 25% of the trade amount. Buyer retains the rest of their security deposit. |
| Buyer takes SEPA payment and then sends payment via SWIFT, or takes SEPA payment then send via TransferWise etc | Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit. |
| Buyer takes altcoin offer and then sends altcoin with a low fee that gets held up in the blockchain. | Buyer has the option to do CPFP or similar. If late buyer loses the following; 0-24 hours late: Buyer loses 2.5% of the trade amount., 24-48 hours late: Buyer loses 5% of the trade amount, 48-72 hours late: Buyer loses 7.5% of the trade amount, 72-96 hours late: Buyer loses 10% of the trade amount. Any payment by buyer and seller has option to refund buyer. |
| Buyer does not make payment in trade window | If late buyer loses the following; 0-24 hours late: Buyer loses 5% of the trade amount., 24-48 hours late: Buyer loses 10% of the trade amount, 48-72 hours late: Buyer loses 15% of the trade amount, | Buyer makes payment from an account with a different name, account number than their payment methods | Buyer loses 10% of the trade amount. Buyer retains the rest of their security deposit. | Any late payment by buyer and seller has option to refund buyer.
| Buyer made a mistake they actually meant to sell not buy BTC. | Buyer has the option to complete the trade within the trade window. If they fail to do this Buyer loses the following; 0-24 hours late: Buyer loses 2.5% of the trade amount, 24-48 hours late: Buyer loses 5% of the trade amount, 48-72 hours late: Buyer loses 7.5% of the trade amount, 72-96 hours late: Buyer loses 10% of the trade amount. Any late payment by buyer and seller has option to refund buyer. This is to prevent option buying. |
| Buyer sends random / incorrect payment amount. | Buyer has the option to send the correct amount within the trade window. If they fail to do this Buyer loses the following; 0-24 hours late: Buyer loses 2.5% of the trade amount, 24-48 hours late: Buyer loses 5% of the trade amount, 48-72 hours late: Buyer loses 7.5% of the trade amount, 72-96 hours late: Buyer loses 10% of the trade amount. Any late full payment by buyer and seller has option to refund buyer. |

## BTC Seller issues

| BTC Seller Issues | Suggested resolution |
| ------------- | ------------- |
| Seller does not respond to mediator for 48 hours | Seller loses 25% of the trade amount. Seller retains the rest of their security deposit. |
| Seller does not have the payment method needed (eg accepted Zelle trade but has no Zelle account) | Seller loses 10% of the trade amount. Seller retains the rest of their security deposit. |
| Seller wants to cancel trade due to problems with bank | Seller loses 20% of the trade amount. Seller retains the rest of their security deposit. |
| Seller is asking for selfie, copy of ID of buyer, home address. | Seller loses 10% of the trade amount. Seller retains the rest of their security deposit. Seller can choose whether to provide or not. *Bisq should incentivize accounts that do not ask for any more information than necessary and penalize users that trade with banks that add for more information than necessary. |
| Seller claims they were unable to release BTC in time of payment window due to Bisq wallet being corrupted and needing to resync, unable to log into Bisq, other problem. | Seller provides evidence that they were unable to access Bisq (Git Hub issue / Keybase chat etc). If unable Seller loses 25% of the trade amount. Seller retains the rest of their security deposit. |
| Seller attempts to debit buyer's account using their bank details. | Seller loses 100% of of the trade amount. Seller retains the rest of their security deposit. |
| Seller raises mediation in error then completes release of BTC outside of trade window | Seller loses the following; 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |
| Seller accepts SEPA instant trade but is unable to receive a SEPA Instant payment at they only have a SEPA account | If BTC release occurs outside of payment window, Seller loses 2.5% of the trade amount., 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |
| Seller does not release BTC in trade window | If late Seller loses the following; 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |
| Seller made a mistake they actually meant to buy not sell BTC, but offer was taken. | Seller has the option to complete the trade within the trade window. If they fail to do this Seller loses the following; 0-24 hours late: Seller loses 5% of the trade amount., 24-48 hours late: Seller loses 10% of the trade amount, 48-72 hours late: Seller loses 15% of the trade amount, 72-96 hours late: Seller loses 20% of the trade amount. Seller loses 20% of the trade amount, Over 96 hours late: Seller loses 25% of the trade amount. |

Support Team Lead

2021-03-02T23:21:40Z

Leo816: /* Duties */

This article documents the ''Support Team Lead'' [[role]].

__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/102 Support Team Lead #102]

== Team ==
===github===
* [https://github.com/orgs/bisq-network/teams/team-leads Team Leads team]
* [https://github.com/orgs/bisq-network/teams/support Support Team]
===wiki===
* [[Support_Team|Support Team]]

== Duties ==

* Review Team's [[Compensation]] requests as per Process.
* Manage new internship proposals and evaluate their performance once the period is over.
* Review and supervise the "on duty" schedule.
* Lead the Weekly Support-Team calls.
* Support Repository Maintainer.

== Rights ==


== Bonding ==
N/A

[[Category:Roles]]

Manual payout

2021-01-16T09:04:22Z

Support Agent

2020-12-17T07:46:18Z

Leo816: /* Backup */

__TOC__

==Requirements==

What makes a great support agent?

* You're a Bisq user. You understand how to use it well enough to help others.
* You can be available for 10 hours or more per week to handle support cases.
* You're familiar with the existing [[Docs]] and [[Knowledge Base]] articles.

If you're interested in becoming a support agent, see the [[#Internship]] section below.

==Infrastructure==

Includes all of [[Support Team#Infrastructure]], plus the following:

=== Coverage calendar ===

The coverage calendar tracks shifts for each support agent, with the goal of achieving 24/7 coverage.

* [https://calendar.google.com/calendar/embed?src=u4eea6bffk10b76l2cmb86eqqc%40group.calendar.google.com&ctz=Europe%2FVienna Public HTML]
* [https://calendar.google.com/calendar/ical/u4eea6bffk10b76l2cmb86eqqc%40group.calendar.google.com/public/basic.ics iCal File]
* [https://calendar.google.com/calendar?cid=dTRlZWE2YmZmazEwYjc2bDJjbWI4NmVxcWNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ Google Calendar] (login required)

===Case tracking board===
* https://github.com/bisq-network/support/projects/2

===GitHub team===
* [https://github.com/orgs/bisq-network/teams/support-agents @bisq-network/support-agents] (includes l1, l2 and intern subteams)

===Role issue===
* [https://github.com/bisq-network/roles/issues/64 L1 Support Agent #64]

==Duties==

===Handle support cases===
If unable to solve the trade successfully you must gather the appropriate data before contacting a developer.

Required data to request support from '''developers''':

* Create a directory with the trade ID as name
* Add a short description in a plain text file of the problem/bug. Use BTC buyer/BTC seller if you refer to any trader. Ask user when the issue happened so its easier to find the issue in the logs.
* Ask them if they have done anything non-standard or had past issues.
* Add all available trade tx IDs of both traders as plain text to the report.
* Get a screenshot of the trade details window (click on trade ID). Tell users to only blur out the payment account details but not the tx IDs or other data. There is no relevant privacy issue with exposing trade ID, tx IDs or onion address.
* Add a screenshot from the mediators dispute details window. The contract as json data is not required initially and only needed if the dev requests it. The payment account data in the json file should be removed before handing over to a dev to protect traders privacy.
* Get all log files from both users (at Account/Backup there is a button for opening the data dir) - its up to 11 files.
* Put all logs from one user into a directory named buyer and seller
* Add a screenshot of both traders first chat message (system message containing data like version number/OS,...)
* If there have been any error/warning popups request a screenshot of that as well.
* Zip all and send it in keybase as PM to a dev who has commited to work on it. Avoid adding it to the support channel as then nobody will feel responsible to work on it.

===Keep the coverage calendar up to date===

===Submit regular cycle reports===

==Rights==

* Writer access to the <code>bisq.support</code> Keybase subteam
* [https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level Triage] access to [[Support Team#Repositories]]
* Edit access to the [[#Coverage Calendar]]

==Policies==

===Time to response===

If you are on duty, it's your job to respond as promptly as possible to incoming user requests. The goal is to respond to all support inquiries in the <code>#support</code> channel within 1 hour of being asked and preferably much faster. This initial response need not actually ''resolve'' the user's issue, it is merely letting the user know that you've heard their question and that you'll be their primary support agent for this case.

===Sensitive user data===

Often support agents will need to ask users to share their logs with you or specific information about their offer or trade, such as trade ID, trade amounts, etc. This data should not be shared in any public channel and should be destroyed one month after the case is closed. Note that any such information that shared in the <code>bisq.support</code> subteam is automatically destroyed after 30 days.

==Processes==

===Internship===

Prospective support agents are asked to go through an internship process that lasts one DAO cycle (approximately one month). During this period, you'll perform the [[#Duties|duties]] of a support agent, but your contributions won't be eligible for compensation. This gives you a chance to get to know the ropes and for all parties involved to determine whether a support agent role is a good fit for you.

# Indicate in the <code>#support</code> channel that you're interested in interning as a Support Agent.
#* Say a bit about yourself and why you're interested in doing this work
#* Mention what days and times you'll be available to do this work
# The [[Support Team Lead]] will then:
#* Add you to the [https://github.com/orgs/bisq-network/teams/intern-support-agents @bisq-network/intern-support-agents] team
#* Add your requested shifts to the support coverage calendar
#* Announce your internship:
#** with a message to the larger [https://github.com/orgs/bisq-network/teams/support @bisq-network/support] team
#** with a message in the <code>#support</code> channel
# After one full cycle of interning
#* Submit a [[Proposals|proposal]] to be added to the [https://github.com/orgs/bisq-network/teams/l1-support-agents @bisq-network/l1-support-agents] team
#* If your proposal is approved, the support team lead will promote you as per the process below.

===Using the coverage calendar===

===Case tracking===

==Knowledge base for support==

===Trade transaction structure===
If there are any issues with transactions or doubt if the deposit or delayed payout tx is correct you can check it in a block explorer by following the transactions outputs.

There are 5 diff. txs:
* Maker fee tx
* Taker fee tx
* Deposit tx
* Delayed payout tx (only get broadcast when arbitration gets opened)
* Payout tx

'''The 2 trade fee txs have as first output the trade fee.''' That goes either to one of the BTC receiver addresses ([1] and [2]) or to a BSQ change address of the user in case BSQ was used for the fee (the diff from BSQ input and change output is used for miner fee and is the burned BSQ).
'''The second output of both trade fee txs must lead to the (same) deposit tx'''. The deposit tx has an OpReturn and the first output is to a multiSig address (start with `3` if non-segwit or with `bc1` if segwit). There can be an optional change output if trade amount was smaller than max. offer amount, but there are never more then 2 outputs + opReturn.
If the delayed payout tx or the normal payout tx was published you see that the first output of the deposit tx (the MS output) is spent and lead to one of those txs as the single input. The normal payout tx has exactly 2 outputs, 1 address for each trader and that addresses are dispayed in the trade/ticket details.
The delayed payout tx need to have exactly 1 input and 1 output to one of the addresses listed in [1] and [3]. '''If arbitration is opened this tx MUST exist otherwise a refund MUST NOT be made'''. The input must be the multisig output of the deposit tx (we have a code to check if its the deposit tx of the trade and not any past one - if a popup in mediation or arbitration tells you that there is an issue, take it serious and contact devs for advice).

To check the txs (and addresses) use a block explorer which shows clearly the inputs and outputs, not all explorers have a very intuitive UI to follow the flows of txs. If you select the addresses like in the below screenshot you can see the flow pretty clearly.

[[File:Support Agent guidance 1.png|thumb]]

[[File:Support Agent guidance 3.png|thumb]]

[[File:Support Agent guidance 4.png|thumb]]

Checking if the trade fee tx leads to the deposit tx helps to quickly see if the trade funds are locked up and all is ok with the trade. If that is not the case the traders might have lost trade fee (if their trade fee tx is published - if one side is missing that user has not lost trade fee so no fee reimbursement is justified, such users need to do a SPV resync as the tx is likely committed in their wallet but not in the mempool due to too low fees or a bug at broadcast).

===One trade fee tx not found in mempool===
In case the miner fee was too low or due broadcast problems (bad network connectivity or bug) it can be that one of the trade fee txs is not getting confirmed or has not been broadcast.
After a few days unconfirmed tx gets removed from the bitcoin nodes mempool (size of mempool is a local setting for each node/explorer so it can be that its visible in some explorers but in others not).
In such cases the deposit tx cannot be confirmed as well. Instruct the trader who's tx was not confirmed that he does a SPV resync so that the tx gets cleaned from his local wallet.
Otherwise there is high risk that the change output gets used for another tx and that will fail then as well. Best to deactivate all open offers to avoid that a taker could take an offer before the wallet is resynced.
The trader who has the confirmed trade fee tx has lost his trade fee and can request for reimbursement.

===SPV resync===
SPV resync tends to be recommened too often in support.
SPV resync can be quite heavy and is not a great user experience to do, so only recommend if really needed.
How long a SPV takes depends on the age of the wallet and the number of transactions.
Old wallets with many transactions can take a day or even more. Usually with a fresh empty wallet its about some minutes up to 1 hour.
It is faster if the user runs a local BTC node (not pruned). It also depends on internet connection and amount of CPU/RAM. CPU will be maxed out during sync.

SPV resync is needed if there is a transaction in the wallet which never got confirmed. You can check for that by looking up the tx in several block explorers, if its not found in any then its pretty sure that tx got removed from mempool. This is expected in case miner fee was too low or when the tx broadcast failed.
Another reason to do a SPV resync is when there is a message that the wallet contains a `double spend` tx. This is usually not intentional done by the user but due to some errors or reorgs in rare cases.
There might be other more rare error conditions, but for those I recommend to contact the devs before recommending a SPV resync as it will help as well to fix potential bugs.

If users do not get connected to the BTC network do NOT recommend SPV resync.
Potential reasons are:

* User runs Bitcoin node in not pruned mode
* Bitcoin node is not full synced when Bisq start (Bitcoin node need to always be full synced before starting Bisq)
* User had set custom BTC node in settings or prog arg and has changed his setup
* Connection issues
* Tor issues

===Connection issues===
In rare cases Tor can cause problems. If no connection can be created after several restarts and if user is sure to have normal connectivity he should clean the Tor files via `Settings/Network/Tor settings`. He should make a backup first and not do it manually. Deleting the hiddenservice directory would make his node inaccessible as he would create a new onion address! If there are no open offers/trades/disputes and user dont care to lose his local reputation it is not problematic to delete the onion priv key. In some rare cases that can help as well (I saw in rare cases the changing the onion address solved Tor connection issues).
Tor has some ddos protection which can lead to get flagged an IP address. We see that from time to time on seed nodes and its likely caused by too much traffic or some traffic pattern which Tor interprets as ddos. In such cases changing the IP should help. Using a VPN can help to check if thats the problem (I had it once myself that I could not use Tor anymore and only via VPN it worked). After a few weeks it was ok again so it seems those bans fade out over time. Testing with Tor browser is another option to see if Tor itself has issues (does not cover issues if the onion address or cache files).

If network speed is very low (< 2 Mbit/sec) there might be connection timouts. We improved some data requests already and will improve more in upcoming releases but specially at startup the BTC sync and getData requests can be a bit heavy, specially if Bisq was not used for a while. Doing repeated startups can help as some data gets persisted and at next request less data is required. Using a local Bitcoin node helps as well as the BTC sync is then not adding up to tor traffic.
If the user has not used Bisq since more then a month he should update to latest version and then delete some files in the `db` directory inside the data directory. Then those files get replaced by more recent ones which go shipped with the latest binary. that avoids to need to download the missing data from seed nodes (seed nodes have limits as well of amount of delivered data). Those files are:
* DaoStateStore
* SignedWitnessStore
* AccountAgeWitnessStore
* BlindVoteStore
* ProposalStore

Please note that deleting or manipulating files inside the db directory is usually not recommended and can cause severe problems! Some files are basically only cache files from public data like the ones above, those are not critical, but other data are local private data and would lead to a corrupted state or failed trades.

'''BTC Balance issues Connection issues'''
There is a wallet info tool which can be opened with cmd+j. There you see all the raw data of the wallet: Addresses, public and private keys, txs, balance of both BTC and BSQ. Can be useful for investigation.
Another option is the open the emergency wallet tool by cmd+e. There one can withdraw all available funds (not including locked up funds in multisig). The displayed balance there is the sum of
the available balance + reserved in offers balance.

It is not recommended to use the BTC private keys outside of Bisq. It always can be recovered from Bisq. I am not aware of any case where funds got lost. Spending BTC outside of Bisq can lead to failed taker offer attempts, failed trades or double spends in Bisq and can screw up the wallet.
For those who still want to do it here are the HD wallet paths:
BTC wallet segwit path is: M/44H/0H/1H
BTC wallet legacy path is: M/44H/0H/0H
BSQ wallet path is: M/44H/142H/0H

BSQ should never be used outside of Bisq as the risk to burn the BSQ is very high. A BSQ tx has very strict rules how it is constructed and small mistakes lead to lost BSQ.

===Backup===
* If a user reports a bug tell user to make a backup of data dir. This can help that relevant log files and rolling backups are still available later.
Rolling backup means that old files get deleted (e.g. bisq10.log is oldest log file) once the max. number files is reached, so we can only go back a certain depth back in history.
* Tell users to always make a full backup of the data dir. Seed node is only an emergency backup and if there are open trades funds are at risk (e.g. no communication possible with mediator/peer, or manual payout required).
* Every db and wallet file has a backup folder with the rolling backups. They are named with the unix epoch timestamp. Replace an existing file with a backup file should be done only in emergency cases and only if dev gives the advice.

'''Start over with a new data directory'''
See https://bisq.community/t/how-to-switch-to-a-new-data-directory/7583 for more details

'''Logs'''

Log files are pretty verbose and a big hard to interpret for no developers but a few useful information can be easily extraced:
If you search for `VERSION=` you can see the users version. It gets logged at startup. If the user has once updated there must never follow a lower version in flater log entries. Downgrade is not supported and caused severe problems at the segwit update. After 1.5.0 we protect that downgrade is not possible, but will only have affect in next version after 1.5.0.
If you look for an error search for ERROR (all uppercase). But as there are some non critical errors as well (e.g. caused from broken connections) its better to leave that interpretation to devs. If you post errors post the stacktrace as well if it is available or at least a few log lines before and after the error so it is easier to get an idea what caused it.

===Bug Reports===
To help getting bugs faster fixed, please report any bug to developers in the keybase support channel. Ping devs with their handle so they get notified. Repeat requests if the report is not reviewed by a dev. Escalate early if there are repeated bugs specially after a new release so we can hunt down the bug early

Bugs:
* Locked funds: Delete SPV and resync wasn't helping when trades had been left stuck, the solution is to do a restore from seed. first backup then restore over same app dir.
* Mediation Proposal not working: If payout isn't made, then a manual payout must be made. when bisq's manual payout tool isn't working make the manual payout with [https://coinb.in/ Coinbin]

'''References'''

[1] Bisq donation addresses:
Current Bisq fee receiver address: 38bZBj5peYS3Husdz7AH3gEUiUbYRD951t
Past fee receiver/donation addresses:
1BVxNn3T12veSK6DgqwU4Hdn7QHcDDRag7, 3EtUWqsGThPtjwUczw27YCo6EWvQdaPUyp, 3A8Zc1XioE2HRzYfbb5P8iemCS72M6vRJV

[2] Fee receiver addresses of victims from security incident:
1EKXx73oUhHaUh8JBimtiPGgHfwNmxYKAj
1HpvvMHcoXQsX85CjTsco5ZAAMoGu2Mze9
3EfRGckBQQuk7cpU7SwatPv8kFD1vALkTU
13sxMq8mTw7CTSqgGiMPfwo6ZDsVYrHLmR
19qA2BVPoyXDfHKVMovKG7SoxGY7xrBV8c
19BNi5EpZhgBBWAt5ka7xWpJpX2ZWJEYyq

[3] New receiver address for delayed payout tx (no DAO param change yet done but will be activated soon):
34VLFgtFKAtwTdZ5rengTT2g2zC99sWQLC

===Escalation===

===Reporting===

===Compensation===

[[Category:Roles]]