Skip to content

Instantly share code, notes, and snippets.

@w0000000t
Forked from MwithM/penalties_table.md
Last active January 31, 2022 12:50
Show Gist options
  • Save w0000000t/6d9ba235578a4fbcbf01154f491f8119 to your computer and use it in GitHub Desktop.
Save w0000000t/6d9ba235578a4fbcbf01154f491f8119 to your computer and use it in GitHub Desktop.
Penalties table layout draft

Penalties

Bisq has rules in place to make the trading process as safe and convenient as possible for all parties involved, and it is important those rules are followed by users.

Penalties are a percentage of the trade amount, deducted from the offending peer's security deposit and offered as a compensation to the other peer during the dispute resolution process.

The actual penalty will be up to the values detailed below, depending on security deposit % and mediator's discretion, except for 100% penalties, that refer to serious violations and will always imply losing the whole amount (trade + deposit).

Alternatively, if good communication is established, peers can use trader chat to agree on a penalty amount to relay to their mediator.

Buyer or Seller
100% Fraud attempt: debiting of peer's account, code tampering
25% Not responding to a mediator within 48h
20% Cancelling a trade
20% Requesting that payment be made from/to a different account name, without mediator's acknowledgement
10% Requiring personal data: ID, home address, etc. (Bisq should incentivize accounts that do not ask for any more info than necessary)
Buyer
100% Payment chargeback
25% Bitcoin-related payment references (eg. BTC, Bisq, Bitcoin...)
25% Paying from an account with a different name (Name Surname instead of Surname Name, and/or slight variations are allowed, where they do not generate ambiguity), seller is allowed to cancel the trade with no penalty
20% Payment is 72+ hours late
15% Payment is 48-72 hours late
15% Paying from an account with same name but different account number, seller is allowed to cancel the trade with no penalty
10% Payment is 24-48 hours late
10% Similar, but wrong, payment method (eg. SWIFT instead of SEPA, SEPA instant instead of Wise...)
10% Wrong payment amount: buyer has the option to correct the amount within the trade window, seller is allowed to cancel the trade with no penalty
10% Using unagreed payment reference
10% Late payment because of low fee for altcoin tx; penalty can be reduced during mediation if buyer uses RBF or similar
5% Payment is up to 24 hours late
Seller
15% BTC is released outside of trade window
@w0000000t
Copy link
Author

w0000000t commented Jan 31, 2022

I think it is ok as per current trading rules: https://bisq.wiki/Trading_rules#Do_not_change_payment_details_once_trade_is_in_progress
"Once the deposit transaction is published, the trade is in progress, and its terms cannot be changed. The seller had agreed to be paid as specified in the trade contract. In the event of an unexpected circumstance (e.g., hitting a bank-imposed transfer limit), seller can propose alternatives through trader chat or mediation, but buyer is not required to comply. It is the seller to ensure that the payment account in their offer will work before an offer is taken."

It fits! What's your opinion, then, about further expanding that rule as follows:

In the event of an unexpected circumstance (e.g., hitting a bank-imposed transfer limit, account being locked/canceled, unavailable funds), seller or buyer can propose alternatives through trader chat or mediation, but peer is not required to comply. It is each trader's responsibility to ensure that the chosen payment account will work before an offer is taken.

the above would put on both peers the responsibility to make sure their accounts are in order, and allows both to suggest alternatives (with same account name) without necessarily go to mediation; I have taken the liberty of updating the corresponding penalty to reflect this.

Most of the mediation cases regards late payment are the BTC Buyer not sending the funds. They can send it any time during mediation and should be incentivized to do so as early as possible.
Late release by BTC sellers is a little more problematic in that btc cannot be released when mediation has started. But it is much less common an occurrence in mediation. Maybe late release should be a fixed amount and late payment be variable?

Understood; in this case the timeframe based penalty will be only applicable to buyer, while there will be a separate penalty section for sellers only including this case, let's try some more edits and then we'll discuss them.
I have created said separate section, with a penalty of 15%, which I think could as well be raised to 20%, since all percentages are to be intended "up to", and mediators can reduce them based on circumstances.

I have also added a sentence to the intro, to reflect the "peers discussing their own penalty" concept as per bisq-network/proposals#360 (comment)

Regarding 100% penalty given for "Chargeback", this couldn't be enforced, since the maximum that can be deducted from a buyer is their security deposit, unless said chargeback fails, and then even if it is credited to seller, buyer will not receive their deposit, nor the traded BTC?

@MwithM
Copy link

MwithM commented Jan 31, 2022

If an issue was not reported, how do you know it's really a bug? There was the same penalty as for delaying a payment because otherwise traders are incentivized to say that something (i.e. confirm payment button) failed. If they ask for help once mediation starts, then is too late, as the trade is already delayed, even if the main factor for the delay was really a bug.

Although I agree penalties should be price agnostic, future trading is a violation on how Bisq works, so it should stay as a 100% penalty:
Option trading was almost the only reason to increase security deposits. Security deposits are suggested according to future trading risk (through volatility) and mediators are alerted if there was a chance of future trading. It needs to be crystal clear that Bisq should not be used as a future trading platform.

About using different penalties with regards to timescales in case of late buyers/sellers:
First of all, paying (as buyer) or responding to mediator (as seller) doesn't mean that the other part will be able to end the trade just after: they can delay accepting the mediation for many days.
Then, there's different payment methods: A buyer who is delayed less than 24h using SEPA means that it took almost 7 days to start the payment.
This penalty is highly case dependant, but I don't see how trying to describe every possible case is doing any good. It's not possible to cover all possible cases with that timescale, while it brings back complexity to the table, where the same issue is repeated.
If you want to keep mediations consistent between different mediators, just peer review this and other edgy cases regularly.
If this time dependant timescale is kept, at least change "BTC is released outside of trade window" for "BTC are not released at the end of trade window".

The issue I found with using different accounts is that mediators can't require tamper evident proof about it, so I think it's better that any change in that sense goes through mediation.
A possible option to avoid opening mediation is to make users sign a message with the changes in a trading protocol with Ctrl+G, but this tool is not friendly enough for everyone's use.
All in all, as not being able to proof what is being said on a chat is not a common issue and mediators seems to be ok with it, not reporting small changes (I consider big, as troublesome, a different name for buyer or seller) on the trade contract to mediator seems ok to me, but the table, as I see it now, it's not clear as it has the same cause for penalty (using an incorrect name) for buyer and buyer/seller.

@w0000000t
Copy link
Author

w0000000t commented Jan 31, 2022

I personally never considered the idea of option trading, as I'm not that kind of trader, yet I understand a strong position against it, as it could be damaging/takes advantage of other innocent users.

While, on the other hand, I am actually in favour of bringing the "late payment" back to a flat percentage (for simplicity's sake, other than what @MwithM wrote) and have mediators account for the real percent amount to choose.

The "difference in payment account/name" penalty means, the way I see it, two separate things between the two tables: in Buyer/seller, it is a request made by one of the two, to significantly alter the payment used as agreed upon on offer taking; in "buyer only" it is the buyer who singlehandedly decides to use a payment different from the one set in the offer details. But yes, while I understand that, a new user might be confused by the terminology, let's see if I can find a way to express this.
Edit: actually, upon re-reading, I don't think a new user should be confused, if they have basic understanding of the english language; a re-read, or even re-re-read, should clearly deliver the correct meaning.

@MwithM
Copy link

MwithM commented Jan 31, 2022

The "difference in payment account/name" seems good enough now, it's not confusing.

@MwithM
Copy link

MwithM commented Jan 31, 2022

Regarding 100% penalty given for "Chargeback", this couldn't be enforced, since the maximum that can be deducted from a buyer is their security deposit, unless said chargeback fails, and then even if it is credited to seller, buyer will not receive their deposit, nor the traded BTC?

Most probable case is that buyer will do a chargeback after BTC are released.
They could have another trades going on, and they would lose as much as possible from this trades, after alerting other sellers not to release the BTC.
Chargebacks aren't easy to penalize, and that's why Bisq reduces chargeback risk through account signing and limits.

@w0000000t
Copy link
Author

As I understand, cases of chargeback are very few and far apart luckily.
Probably we can wait for @pazza83 's and @leo816 's ok and then, if noone else has anything against, since the proposal has been up for a while already, this can be considered final.

@leo816
Copy link

leo816 commented Jan 31, 2022

I like how it looks right now and I think this is a good starting point, we will continue editing it as we get feedback from users and we comment it on the weekly calls. I will go ahead and edit the wiki now

@leo816
Copy link

leo816 commented Jan 31, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment