Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Burn BSQ to pay for trading fees #281

Closed
MwithM opened this issue Nov 17, 2020 · 9 comments
Closed

Burn BSQ to pay for trading fees #281

MwithM opened this issue Nov 17, 2020 · 9 comments
Labels
an:idea https://github.com/bisq-network/proposals/issues/182#issuecomment-596599174 re:features re:parameters was:stalled was:superseded

Comments

@MwithM
Copy link

MwithM commented Nov 17, 2020

I'd like to launch a different idea than the one exposed at #280. In my opinion, that proposal lacks on what traders win from paying more fees. But I'm not against that proposal, as both can be applied in parallel:

My idea is to let traders burn a certain amount of BSQ to buy a kind of subscription fee that would allow them not to pay for any extra trading fees during a certain period (a week, a Bisq cycle...). A discount on the trading fees could be fine as well, but maybe it won't be possible to implement, and 0 fees work as well as a fee reduction to expose this proposal.
Prepaid fees would make income more predictable when regular traders use it, and would commit them to reach a certain amount of volume to make their expenditure profitable. That could increase trading volume which is one of the main concerns for new and old Bisq traders. Traders would also protect from BSQ volatility and it might have positive privacy implications.
From a technical level, it seems that a certain period of time is more feasible to control for Bisq than trade volume, as using trade volume would have similar problems as found for implement Bisq v2.
I'm not aware that any trading platform has tried a subscription fee before, but it does not seem that bad. Depending on the price paid through burnt BSQ, it would act like poker rakeback for those players who generate a lot of volume for the poker room, or the reduction on fees that trading platforms apply to traders depending on fees paid, but in this case traders would need to pay in advance because Bisq can't follow trading activity for any user.

Sorry for not being more explicit about how to develop this, but I'm quite sure that this idea has not been properly discussed before.

@MwithM MwithM added an:idea https://github.com/bisq-network/proposals/issues/182#issuecomment-596599174 re:features re:parameters labels Nov 17, 2020
@chimp1984
Copy link

Interesting idea.
How would it work for different types of traders? E.g. The casual trader who does 1 or 2 small trades a month would pay much more if there is only a fixed fee/month as the pro trader who trades large amounts and volume. Now our main revenue comes from large XMR trades so as that would not be bound to the trade amount it would also make it more expensive for fiat traders and much cheaper for those pro traders.
To combine it with trade amount and number of trades will lead to challenges similar to Bisq v2 as you mentioned.

Last months we have about 3300 trades with 313 BTC volume which results in 1,252 BTC on trade fee if we apply the 0.4% target. In USD terms the fee revenue would be 12520 USD @ 10k BTC/USD price. That would be about 3,80 USD on fee per trade if we would distribute it to get the same revenue. I fear 4 USD trade fee for a 100 USD trade (4%) would be considered quite harsh specially from new traders who come to try out Bisq.

@pazza83
Copy link

pazza83 commented Nov 18, 2020

I think having a subscription option is a good idea.

Phemex is doing something similar:

https://www.coindesk.com/morgan-stanley-phemex
https://phemex.com/premium

Also offer option to buy in bulk. 12 months for price of 10 etc. It would give some up front revenue to the DAO.

Another option is staking / or just owning a certain amount of BSQ.

Binance (BNB), Crypto.com (CRO), Celsius (CEL) all encourage users to stake/hold more tokens for better rates.

@MwithM
Copy link
Author

MwithM commented Nov 18, 2020

How would it work for different types of traders? E.g. The casual trader who does 1 or 2 small trades a month would pay much more if there is only a fixed fee/month as the pro trader who trades large amounts and volume. Now our main revenue comes from large XMR trades so as that would not be bound to the trade amount it would also make it more expensive for fiat traders and much cheaper for those pro traders.

XMR whales are the main beneficiaries of the proposal as it is now (free trading fees). That would not be good for Bisq if they trade mostly just between them. An option to mitigate this could be to make the tickets scarce (only a couple of them) and bid in an auction for this tickets so it would act like a Market Maker discount.
Let's say that Bisq offers 2 tickets and I pay 50USD/month in fees. I would offer 40 USD to get this ticket, another trader would offer 60 USD and another only 30 USD. Me and the second bid would win this tickets while outbidding the third bidder, and for that month, we would be offering better deals to the rest of the market as we know the more we trade, the less we pay in fees, increasing total volume and probably total revenue in fees. If we think we can estimate the price for this tickets, the auction won't be necessary. The auction has positive outcomes, but also negative, like not preserving trader's privacy if the auction requires extra communication channels (traders locking the bond for the DAO to destroy biggest bids is a possibility within the DAO, but that process would require 2 cycles and losing bidders would have locked BSQ for nothing).
Another option would be to implement this only for low volume markets which, to me, is any except XMR as XMR generates most of the volume. Again, if the tickets are scarce, we should not worry if one "privileged" trader gets free trading as long as he increases total volume which will benefit other traders and probably total revenue.

Overall, a fee decrease for those who pay for the tickets would work way much better. Any extra trade that ticket owners generate will be extra volume for the market and extra revenue for the DAO, while still decreasing BSQ exposure for traders. Something like paying 10USD in BSQ to get a 10% fee reduction and paying 50 USD to get a 20% fee reduction (paid either in BTC or BSQ) removes the bad incentives that 0 fee trading would generate as now there's a different offer for occasional and big traders so small traders can still directly benefit.
Please, don't consider this exact numbers, they're too rough just to show my point. Maybe there's no way for smaller traders who only spend a couple USD per month to benefit from this, unless we extend the period of the ticket duration.
On the bad side, fees, specially due to BSQ price volatility, are already hard enough to understand and explaining this system will take a lot of time.

BTW, I just also realized that this could be a way to stop paying mining fees for trading fee tx while no trading fee tx or 1 single tx trading protocol is implemented.

@RefundAgent
Copy link

This is a complicated proposal and against the interest of the users who now also have to consider the cost-benefit of subscribing or not. This is an actual cost for the user (cf. N. Szabo: shorturl.at/fvHW1) and will simply deter users from Bisq. It reminds me of telephone and electricity companies that force people to spend inordinate amounts of time to even understand what they are buying - confusopolies according to Dilbert.

In order for Bisq to succeed it MUST be userfriendly. If not it will at best continue to be the niche project it is.

@MwithM
Copy link
Author

MwithM commented Nov 20, 2020

@RefundAgent
This propsal, if we keep it at "burn BSQ to pay for trading fees" it's not that complicated. How to apply it, technically and pricing, can be, but I think it won't look like it once it's done.
For users, if normal fees (in BTC or BSQ) are similar to what they are now, they will be able to test Bisq and once they get used to it, think if they prefer a plan to save on trading fees or keep it the simple way. Now they have to keep making similar thoughts to know how many BSQ buy in order to save fees.
Now there's no incentive in making more orders than the usual, or to take marginal arbitraging opportunities. The extra utility that Bisq gets for the extra volume generated makes worth to think of ways to promote users generating more volume, and that's one privacy friendly way to do it.

@RefundAgent
Copy link

@MwithM
I disagree for a different reason also. I don't think the present fees have anything to do with the volume (although I know I am alone in this belief within Bisq). The average historical price increase of btc is 360% per year, which is around 0.4% per day. It can certainly be argued that every day that an offer is waiting on the market costs the same as the fee.

In addition btc can easily change price by 5% within minutes which also is a cost if an offer is just sitting on the market.

There are other costs also, mining fees ... .

@MwithM
Copy link
Author

MwithM commented Nov 21, 2020

Priority should be to reduce other bigger costs, mainly mining fees. But after segwit being implemented, and with interesting options on the table like removing trading fee transactions, maybe it's time to think about this.

@pazza83
Copy link

pazza83 commented May 10, 2021

Hi @MwithM thanks for the proposal. I am doing some housekeeping on the proposals. Please can you take steps to move this forward or alternatively close the proposal.

Many thanks.

Ref: https://bisq.wiki/Proposals

@MwithM
Copy link
Author

MwithM commented May 10, 2021

Close it as superseeded or stalled, there is a similar discussion now going on: bisq-network/bisq#5480

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
an:idea https://github.com/bisq-network/proposals/issues/182#issuecomment-596599174 re:features re:parameters was:stalled was:superseded
Projects
None yet
Development

No branches or pull requests

4 participants