[Implemented] Add protocol fees

  • Title: Add protocol fees
  • Author(s): @themachinegunn
  • Related Discussions: none
  • Submission Date: 04 October 2023

Body Paragraphs:
Summary

Hashflow is currently positioned as one of the top DEX protocols; arguably the top DEX with zero slippage. Hashflow’s token (HFT) has been traded on markets for almost a year now. However, HFT holders and HFT stakers receive almost no benefit from the growth of the platform. This proposal is to suggest that Hashflow begin charging trading fees and allow existing and new HFT holders and stakers to receive some of those fees.

Overview

Since the launch of HFT in Nov 2022, trading volume has been increasing as Hashflow grows and integrates with other protocols. Many of these protocols (such as 1inch, etc.) charge fees on trades that are routed through Hashflow, however Hashflow itself does not charge fees.

It is important to offer utility for the token beyond governance voting ability. Activating fees on Hashflow and sharing this revenue with token holders will create more utility and attract more and more users to buy, hold and stake the token. Revenue from fees can also be used to buy back and burn HFT tokens, further increasing demand for HFT and benefiting all token holders.

Similar protocols (such as GMX, etc.) already charge fees and share them with token holders and they are able to benefit their community. Hashflow needs to do the same.

Adding fees will also have the effect of lowering trade volume but it is something that needs to be done. Victor and the team can find ways to experiment with different fee structures until there is a balance but that process must begin now.

Technical Specification

  • Similar to how others charge fees on Hashflow integration, Hashflow will determine a fee to charge for each trade
  • Victor and team can build a way to assess what fees can be charged
  • Fees will be trackable on-chain
  • Fees will be shared between the token holders and the foundation
  • For Hashflow blue-chip pairs, we test a dynamic fee, where the fee charged on a given trade would be a function of our market maker’s quote on that pair. If the quote is highly competitive, then there would be a larger fee opportunity than if it was less competitive. For non blue-chip pairs, we start by testing out a static fee and refining it over time to ensure that the quotes remain competitive. The goal is to charge the maximum fee possible without making the quote uncompetitive
  • Hashflow team continue to iterate until the right balance between fees and competitiveness is reached

Fee Distribution

The fees will be distributed according to the following:

  • 30% - HFT token buy back
  • 50% - HFT token holders who stake their tokens (pro-rata)
  • 20% - Hashflow foundation

Benefits (Pros):

  • Rewards for long term holders and stakers
  • Increased demand / utility for HFT

Downside (Cons):

  • Less competitive prices can lead to less volume sometimes

Voting:

  • Yes to start charging protocol fees
  • No to remain a zero fee protocol
4 Likes

I like the idea of making profits with HFT
I think the team will be able to realize it taking into account the market and commissions of other protocols

1 Like

Agreed. Fee sharing + buy back and burn would be a great addition

I believe that this proposal is in line with the discussions led by Sir Victor in the Governance Room on the Discord Server. I am eagerly awaiting his additional input on this matter. Overall, I find the majority of the proposal to be useful, but there are a few areas that require clarification.

One area that requires clarification is the expected new APY for Stakers, as we will be rewarding HFT Stakers from Hashverse Allocation. Additionally, it would be helpful to understand the implications of potentially losing competitiveness in our price quotes. Another area that requires clarification is the number of bips that will be charged for trades.

I support the idea of adding protocol fees

Completely agreed with this idea. But firstly we’ll need to discuss how we can implement this proposal and still provide top quest.

Hey guys – it’s great to see another potential Hashflow proposal gaining traction in the community.

To provide a bit more context:

  • The issues raised in the original proposal are valid (more on that below)
  • The team has done some very preliminary research as this topic was being discussed in the forums, however, there is a lot more work that needs to be done in order to implement the proposal in a measured way (as suggested by the OP)
  • A quick overview of our volumes over the past 90 days:
    • Aggregate volume: ~$1.6B
    • Avg. daily volume: ~$18MM average vol per day
    • Stable pair volume: 21.3%
    • Non-stable pair volume: 78.7%
  • As a general matter, the opportunity to charge fees on stable pairs before quotes become uncompetitive is smaller than with non-stables

I also agree that there will need to be an iterative component to finding the right balance between charging fees and ensuring that our quotes remain competitive.

One possible way to think about this is by testing both static and dynamic fee structures. The vast majority of our trades are in non-stables, and a significant portion of that volume is coming from “blue-chip” pairs such as USDC/USDT-WETH, etc. For these blue-chip pairs, we could test a dynamic fee, where the fee charged on a given trade would be a function of our market maker’s quote on that pair. If the quote is highly competitive, then there would be a larger fee opportunity than if it was less competitive. For non blue-chip pairs, we could start by testing out a static fee and refining it over time to ensure that the quotes remain competitive. The goal is to charge the maximum fee possible without making the quote uncompetitive. Again, this is just one way to approach the issue.

Lastly, Hashflow smart contracts do not allow for HFT burning, although buybacks can be executed per the OP’s suggestion.

Look forward to hearing more thoughts and as always, we remain committed to implementing all decisions made by the DAO.

Thank you for the support everyone. @gxmxni thank you for the very detailed comments. I would like to change the proposal and incorporate the feedback, but I cannot edit it. Can anyone help?

@themachinegunn Might have been a bug in the settings - can you try again? If it still doesn’t work, let me know!

Thank you @brian. @gxmxni I have updated the proposal to reflect the fact that we cannot burn.

Great thanks!

This [RFC] proposal has passed the 5 days mark and is ready for Temperature Check.

The Temperature Check for this proposal had passed Quorum and it has advanced to the next stage as a HIP.

This proposal is consistent and reasonable
As an old user and supporter of Hashflow, I support and vote "Yes" it

agree - consistent and reasonable

This proposal is not systemically risky and is the same as the original ballot proposal