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
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • 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
@MwithM
Copy link

MwithM commented Jan 11, 2022

I think I found how to phrase the first sentence:
The penalty is a percentage of the full trade amount, which is deducted from the offending peer's security deposit. The other peer gets the deducted amount as a compensation.

I've come to it while translating this string to Spanish, so the proposed wording would be similar to the software's wording.
BTC {0} gets trade amount plus compensation

@w0000000t
Copy link
Author

"Getting" is commonly used when referring to physical properties, but not really semantically correct, at most you would "receive" or "being given" a compensation, how would you think this format would be preferable to
The penalty is a percentage of the full trade amount, which is deducted from the offending peer's security deposit, and given as a compensation to the other peer.

@MwithM
Copy link

MwithM commented Jan 12, 2022

Who is giving? The offending peer or the mediator? I think none of them. The mediator only suggest a payment. The offending peer is penalized but he doesn't mind who gets the BTC.
I prefer get to give because I don't think the offending peer is giving anything.
Maybe collects (which is used to receive a payment and to get something) is another option, but as it's not used in the software, I would much rather still use get.

@w0000000t
Copy link
Author

w0000000t commented Jan 12, 2022

My doubt was really only about vocabulary, as "get a payment" is not in my opinion a formal way to express the concept, and I was trying to find a more suitable wording... maybe someone who is better than me with English can confirm or not... otherwise I have nothing else against "get" per se 😃
More on this, you can "get confirmation" of a payment, "get the news of a payment", "get promoted to receive a payment", but you don't really "get the payment", the way I use the verb is for abstract concepts, rather than "get this material thing"

@pazza83
Copy link

pazza83 commented Jan 30, 2022

Hi @w0000000t thanks for putting this together. Looks much simpler. Here is my feedback:

20% | Not reporting technical issues that cause disruptions: issues must be reported by early mediation (Ctrl+O in Portfolio > Open trades > Select trade) or through support (https://bisq.chat or https://github.com/bisq-network/support/issues) to help investigate and solve the issue

I think this is a little harsh. Technical issues caused by Bisq should not carry penalties for either user. Good practice should be to report issues early but for new users this might not happen.

10% | Requesting personal data: ID, home address, etc. (Bisq should incentivize accounts that do not ask for any more info than necessary)

I would change this to requiring rather than requesting. It is ok to ask for info but it should not be required. For SEPA trades users sometimes get asked for address details. Often bank addresses can be provided and trades can take place successfully. A user should not be required to provide this though,

20% | Suggesting a different payment method or account without mediator's acknowledgement

I think this should be changed to "Requesting to use a payment method or account in someone else's name without mediator's acknowledgement". This is because I think it is fine for traders to agree using another account in the same name if their is a problem with the initial account used for the trade.

100% | Fraud attempt: chargeback, option trading

I would remove option trading from this. I would prefer penalties to be agnostic to price. Buyer pays late they get fined. Does not matter if the price moves in our out their favor.

20% | Unnecessary delay: buyer pays, or seller releases BTC, outside of trade period

I think there should be suggestions on penalties with regards to timescales. This helps keep compensation between mediators consistent and lets users know what to expect. My suggestions would be:

  • 5% - 0-24 hours late
  • 10% - 24-48 hours late
  • 15% - 48-72 hours late
  • 20% - 72+ hours late

@w0000000t
Copy link
Author

I think this is a little harsh. Technical issues caused by Bisq should not carry penalties for either user. Good practice should be to report issues early but for new users this might not happen.

You mean you would prefer this element removed completely, or to revisit to a lower percentage, like 5%, which would then be applicable, or not, at the mediator's discretion?

I would change this to requiring rather than requesting. It is ok to ask for info but it should not be required. For SEPA trades users sometimes get asked for address details. Often bank addresses can be provided and trades can take place successfully. A user should not be required to provide this though,

sounds fair

I think this should be changed to "Requesting to use a payment method or account in someone else's name without mediator's acknowledgement". This is because I think it is fine for traders to agree using another account in the same name if their is a problem with the initial account used for the trade.

might be completely reasonable, you mean traders can, on their own terms and only by trader chat, agree to a different payment method without the need to bring this to mediation? This would also imply changing the current rules somewhat, as it is not currently allowed

I would remove option trading from this. I would prefer penalties to be agnostic to price. Buyer pays late they get fined. Does not matter if the price moves in our out their favor.

this is something @MwithM felt appropriate, personally I think it would be tough to prove that a trader was trying to do option trading rather than anything else, it would be open to discussion

I think there should be suggestions on penalties with regards to timescales. This helps keep compensation between mediators consistent and lets users know what to expect. My suggestions would be:
5% - 0-24 hours late
10% - 24-48 hours late
15% - 48-72 hours late
20% - 72+ hours late

This "one percentage fits all" was also suggested by @MwithM and when it was explained to me, it made sense: once payment is late, and mediation is started, there is an admissible response time by mediator of 48h; then traders will be engaged and reply to mediator with additional possible delays, this in turn will make the above timeframes lose meaning, as mediation per se is something that adds delays outside of the traders' control.

@pazza83
Copy link

pazza83 commented Jan 30, 2022

I think this is a little harsh. Technical issues caused by Bisq should not carry penalties for either user. Good practice should be to report issues early but for new users this might not happen.

You mean you would prefer this element removed completely, or to revisit to a lower percentage, like 5%, which would then be applicable, or not, at the mediator's discretion?

Yes, I think it should be removed. If disruption is caused to a trade it will likely be cancelled or late. Both are covered in the other penalties. If the Bug was a fault of Bisq eg Bug / a node being down etc then the user should not be punished.

I would change this to requiring rather than requesting. It is ok to ask for info but it should not be required. For SEPA trades users sometimes get asked for address details. Often bank addresses can be provided and trades can take place successfully. A user should not be required to provide this though,

sounds fair

👍

I think this should be changed to "Requesting to use a payment method or account in someone else's name without mediator's acknowledgement". This is because I think it is fine for traders to agree using another account in the same name if their is a problem with the initial account used for the trade.

might be completely reasonable, you mean traders can, on their own terms and only by trader chat, agree to a different payment method without the need to bring this to mediation? This would also imply changing the current rules somewhat, as it is not currently allowed.

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."

I would remove option trading from this. I would prefer penalties to be agnostic to price. Buyer pays late they get fined. Does not matter if the price moves in our out their favor.

this is something @MwithM felt appropriate, personally I think it would be tough to prove that a trader was trying to do option trading rather than anything else, it would be open to discussion

My opinion is that a user should not be penalized according to the change of price of BTC. They should be penalized according to how late they were sending the fiat/altcoins or releasing the btc. This is because price is volatile and can change throughout trade/mediation period. Bisq should incentivize sending payment as soon as possible and releasing btc within the trade window. Also from a mediation perspective I would rather not look at price charts and instead just review the time payment was made. @MwithM what are your thoughts on this?

I think there should be suggestions on penalties with regards to timescales. This helps keep compensation between mediators consistent and lets users know what to expect.

This "one percentage fits all" was also suggested by @MwithM and when it was explained to me, it made sense: once payment is late, and mediation is started, there is an admissible response time by mediator of 48h; then traders will be engaged and reply to mediator with additional possible delays, this in turn will make the above timeframes lose meaning, as mediation per se is something that adds delays outside of the traders' control.

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?

@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