GithubHelp home page GithubHelp logo

Comments (13)

chirhonul avatar chirhonul commented on June 3, 2024 2

I agree that the current model is complex, and the explanation at https://bisq.network/faq/#6 is very cryptic.

Possibly a first step would be to just present the current model more clearly, starting with example fees for maker / taker on a specific trade, and only introducing the full calculation later (or in a footnote).

I think if feasible, moving to a fixed percentage or fix amount fee per trade would be ideal for the long-term, for simplicity reasons.

from proposals.

cbeams avatar cbeams commented on June 3, 2024 1

I just did some quick calculations on how such a change would impact trading fee revenue. With a simple 0.2% fee (paid by both maker and taker), trading fees would total 0.4% of total trade volume.

Bisq has done 720 BTC of volume since Jan 1st. At 0.4%, this would have produced 2.9 BTC in trading fees year-to-date.

In reality, though, I estimate we've produced 4.2 BTC in trading fees YTD, meaning Bisq would have taken in 1.3 BTC fewer during the same amount of time if we'd been on the proposed plan.

To keep trading fee revenue at current levels, we would need to raise the amount from 0.4% to 0.58% of total trade volume. This would mean that each party would pay 0.275% of trade volume. This is toward the upper end of what most exchanges charge these days, as far as I know. The Bitcoin Wiki's Exchange comparison seems to corroborate this.

Note that Hodl Hodl is charging between 0.5 and 0.6% on both sides of the trade (see here and here). This is certainly more than the norm, and they've defended the extra price on the basis of the extra difficulty of building such a service, and the extra value people get from it.

So let's step back for a moment and consider the reality of the situation we're in: We are currently realizing—on average—an effective fee schedule of 0.275% for maker and taker, or 0.58% of total trade volume. But that average is deceiving, because in fact, much of that overall revenue is paid by traders who are creating offers at higher percent distance from market price. I have always liked this aspect of our current model, because it's inherently fair: the more a trader profits from a given trade, the more trading fee revenue Bisq makes. And because traders pay that fee up front, they have a strong incentive not to try to be too greedy with sky-high distances from market price. I've always found this arrangement to be elegant.

If we eliminate the "% distance" factor from our fee schedule formula, either some traders will end up paying more per trade than they would have before, or Bisq will end up taking in less revenue overall. We've already lowered our minimum fee from 50K sat to 2K sat this year. Bisq is a valuable service; we should think carefully before continuing to (effectively) lower our prices.

In summary, I'm not closed to this idea, but like @chirhonul suggested above, I'm not sure the problem is the formula itself, but rather perhaps how it's explained. The FAQ entry is indeed very dense and cryptic. I'd like to start with a simple rewrite before changing the formula itself.

from proposals.

ManfredKarrer avatar ManfredKarrer commented on June 3, 2024 1

Yes I agree that the FAQ text is for sure one of the causes for confusion.
@m52go Could you have a look to it and improve the text?

from proposals.

ManfredKarrer avatar ManfredKarrer commented on June 3, 2024 1

@m52go Thanks a lot for the PR! I think you are right that it was mainly the bad description which caused the confusion.
Regarding market distance: The market distance is relative to the liquidity. It seems to be quite normal that in markets with low liquidity users are used to pay higher premiums. I got that feedback from traders when we discussed that topic at the time we implemented that fee model. A Chilenean trader told me its normal that they pay a 10% (or so, don't remember the exact value) in Chile as it is hard to find a trader anyway. Same apply for some altcoins.
I have seen that spread was going down automatically with increased volume (as it happened in EUR). So I don't see it a big issue. To change the formula would add more complexity as it would not be plain square root anymore. 25% creates already a 5 times higher fee, so I think that is not that bad.

from proposals.

ManfredKarrer avatar ManfredKarrer commented on June 3, 2024

@cbeams Thanks for bringing that up, I forgot that aspect.
I think it would be not a problem to increase the fee to at least match the current real fee or go even a bit higher.
And agree to the bad FAQ text. If you or anyone has time to improve would be great!

from proposals.

cbeams avatar cbeams commented on June 3, 2024

We're coming up on the 2–week deadline for this proposal. I've added my 👎 above, reflecting the conversation above that it's probably better to just change the FAQ entry first. If you have any other feedback, please add it now, and please add your own reaction too, so this can be closed in a clear and unambiguous way. Thanks all.

from proposals.

ManfredKarrer avatar ManfredKarrer commented on June 3, 2024

The secondary reason for that proposal was that we will have the fee as DAO parameter which can be changed there and a % value would be easier to maintain than a fixed value as it is now (additional to the min. value). So to simplify the current model to be based on a % based fee and additional to the market distance would be still better then the current model which requires adjustments when BTC price is very volatile. As the DAO is getting closer to a complete state we should find a solution for that fee model question in the next weeks as well. I will try to dedicate a bit if time the upcoming days to make an alternative suggestions. So I think its better to keep that proposal open to not lose the discussion we had here already.

from proposals.

 avatar commented on June 3, 2024

My feeling is that @cbeams point is very valid. Losing 1.3BTC for a 6 months period may be significant for a small business as Bisq atm.
On the other hand, simplification often leads to more business. So maybe the simplification by itself could erase the 1.3BTC loss ?
Perhaps we could just apply the simplification suggested by @ManfredKarrer , but tune the parameters in order to have only a smaller loss, let's say 0.5 BTC, which may be acceptable and may even be compensated by the positive effects of the simplification.

If we believe the simplification is "good", then this means we believe it will have a positive effect on the business. If it is not the case, it's just unuseful to discuss about this simplification at all.

One point I see also concerning simplification is that it should ease the comparisons for customers. If we believe that Bisq has really a good model, this comparison should average in Bisq's favor.

In conclusion I give a 👍 to @ManfredKarrer proposal.

from proposals.

m52go avatar m52go commented on June 3, 2024

Just realized I acknowledged @ManfredKarrer's post and then forgot about it. Thanks @cbeams for bumping it.

I just re-wrote the fee explanation in FAQs. Check out the PR here.

Regarding the proposal itself, I don't think the fee structure is really that complicated. It seems complicated because it hasn't been presented clearly (both in documentation and in Bisq itself), but that can be fixed.

Unless I'm missing something, there's only 1 variable for offer takers, and 2 variables for offer makers, and in both cases, the mechanism and motivations make sense.

In the USD market, distant offers have been a problem. I'm seeing +12% and +20% offers live right now, and until recently there were a handful of +30% and +35% offers. If anything, from my vantage point, the formula isn't aggressive enough to discourage this kind of gold-digging.

from proposals.

cbeams avatar cbeams commented on June 3, 2024

I've just merged @m52go's rewrite of the FAQ explanation; shall we consider this proposal closed now? Technically, I would close it as was:rejected as the original proposal to actually change the formula isn't what we went with in the end. Any objections?

from proposals.

ManfredKarrer avatar ManfredKarrer commented on June 3, 2024

I am fine with closing it. Also my other concern regarding to move to a % value instead of a fixed BTC value was wrong (we use already a % value as 0.002 BTC is 0.2% of 1 BTC).

from proposals.

vycoreb avatar vycoreb commented on June 3, 2024

I am re-proposing that we should, like most exchanges, have a fixed percentage fee for the taker (the one taking an offer) and one for the maker (the one who makes an offer and waits for it to be taken).

One reason is that it is a lot easier to understand. Another is that with the current formula the makers end up paying more than the takers. That is not what you want because to have an exchange that works well you need liquidity. You get liquidity by making it as easy and cheap for market makers to trade on the exchange as possible. Else they move elsewhere or have to make their offers more expensive. Which means less trades, less revenue, less users and a less useful exchange.

That is why many exchanges like poloniex have different fees for makers and takers. For example on poloniex the takers pay 0.2% and the makers pay 0.1% (https://poloniex.com/fees/)

Since bisq is currently filling a niche with features regarding privacy etc. it is completely alright to charge more, but it should be a fixed fee, and it should be cheaper for the makers than for the takers because they are responsible for lots of trades (and without them you dont have a market at all). In established markets that could be thousands of trades per day.

Takers are usually people only making a few trades.

The current fee formula also makes it more expensive to trade the larger the distance from the market price is. Which is the reason that it is harder to understand than just telling the user "the fee is 0.2% per trade". I guess the intention is to make sure the market makers dont charge too much so that people who want to e.g. come to the exchange to buy monero see offers at cheaper markups like 1% rather than 1.9%. But in practice it has the opposite effect since now the market makers have to charge an even higher markup for a trade to be "worth it" for them. If you want a market where it is cheap for takers you have to have lots of liquidity (lots of market makers). And the way you get that is by making it as easy, safe and profitable as possible for them to trade on the exchange rather than another one. And then you also make more money for the exchange because of the higher volume of trades rather than charging a higher fee but only having very few trades.

As a start I would use maybe 0.3% or 0.4% for the takers, 0.2% for the makers. Then see if/how it affects the revenue and then adjust it.

The possible counter arguments that fixed fees would result in less revenue or that it would result in market makers charging more are incorrect because the opposite is the case. There is a reason why most exchanges use fixed fees, often less for the maker than the taker, and some also have rebates for trades who are responsible for a higher volume. But we dont really need that yet. Any additional liquidity is already "a lot" right now.

from proposals.

ManfredKarrer avatar ManfredKarrer commented on June 3, 2024

I opened a new proposal regarding the same topic: #64

from proposals.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.