[Idea] Exchange Certification with HBOT Staking

Author: fengtality 0x352

Original Post Date: 9 May 2022

There are a number of issues with the current fee share-based system that the Foundation uses to maintain and add exchange connectors:

  • Fee share value comes from a few exchanges: Currently, most of the Foundation’s monthly fee share volume comes from a few larger exchanges where the Hummingbot community actively trades. During the first 3 months of the year, Binance, KuCoin, Gate.io, and AscendEX accounted for 98% of all fee rebates received by the Foundation. We also expect FTX, a recently signed partnership, to generate substantial fees based on past volume.
  • Difficult to collect fees owed: While we have agreements with other exchanges, some of whom have reported hundreds of millions per month in volume, we haven’t received any funds from those exchanges and need to press them to honor their contracts. These collections efforts are difficult to scale and operationalize.
  • Unwieldy for smaller exchanges and DEXs: since DEXs may not charge fees, and smaller CEXs may not have the engineering systems to track and apply rebates, it’s difficult to make the fee share based model work for smaller exchanges.

In addition, the current RED/YELLOW/GREEN approach that the Foundation uses to denote exchange connector quality can also be improved. Since YELLOW is applied to any connector with one or more outstanding Github issues related to it, most of the connectors in the codebase are YELLOW, so it’s not very informative anymore.

Because of these issues, the Foundation proposes an alternate approach to adding and maintaining exchange connectors that leverages the HBOT token.

Exchange Certification

The overall idea is to introduce a certification process, similar to CCXT, in which the Foundation gives a “seal of approval” to a subset of exchange connectors in the codebase.

Rather than the color code system, the Foundation would ensure that all Certified connectors are working properly (GREEN status). Certified connectors would be tested heavily at merge and with each release. Foundation QA would only test Certified exchange connectors and not any other exchange connectors.

Only Certified exchanges would be listed in the connect command in Hummingbot, but users could still find and connect to other exchanges. In Github and in the documentation, Certified exchanges are listed in a separate table ahead of the Not Certified exchanges.

Finally, we plan to start weekly Content Hackathons to incentive users with HBOT to create documentation, guides and videos for specific parts of the Hummingbot codebase. Only Certified exchanges would be eligible for these hackathons.

Maintenance Staking

The exchanges with actively paying and current fee share agreements would be grandfathered as Certified. For all other exchanges, we think they should stake HBOT to maintain Certification for the fixed period of time they stake (a Maintenance Epoch). During an epoch, HBOT locked in a smart contract and the exchange enjoys the benefits of Certified status above (Foundation monthly testing, prominence in codebase/documentation, etc). We believe this staking model better aligns the exchange’s incentives with those of the Foundation and the broader Hummingbot and HBOT token holder community.

The size of the HBOT stake required would depend on:

  • Is exchange self-maintaining or do they need a community maintainer?
  • Exchange connector type
  • Length of certification period

We would still encourage exchanges to enter into fee share agreements with the Foundation. If fees shared those agreements prove to be substantive, then the exchange may not need to stake HBOT in the future to maintain Certified status.

Certification Process

We think there should be a “full-serve” model lets the Foundation shepherd exchanges through the process, as well as a “self-serve” model that lets community exchanges attain Certification through the governance system:

Full-serve: an exchange would pay Foundation a fee to manage the entire process: building/testing connector, passing governance, getting Certified

Self-serve: an exchange or any external sponsor could follow the process below:

  1. Build exchange connector
  2. Submit Hummingbot Governance Proposal to merge connector in as Certified
  3. If proposal passes, sponsor stakes HBOT in Maintenance Contract
  4. Foundation applies rigorous testing, merges in connector, and keeps it Certified for length of stake

What do you think?

We are circulating this idea to get feedback from the community. Please add your thoughts and questions below.

If the community thinks it’s a good idea, the next step would be to submit a governance proposal and start implementing the process with the June or July release.

Author: fengtality 0x352

One addendum: there should also be a pathway for the HBOT token holder community to request that the Foundation certify an exchange connector, even if the exchange isn’t involved. This could be funded by tokens from a community token budget allocated by the HGP for this program.

For example, there are some exchange connectors in the codebase that need updating/fixing. If there are token holders who want to see them fixed and maintained going forward by a community maintainer, they could submit a HIP that seeks a portion of this budget.

Author: Dipfit 0xD8A

Great idea for adding an HBOT use case. One of the big issues I see for the tokenomics of the project is how future value will be generated for current holders. This proposal is an important first step to providing liquidity drains. It introduces deflationary dynamics, as more and more exchanges may want to be certified and are required to stake HBOT.

Author: zzzou 0x2dA

Definitely very good idea and agree with @Dipfit that it is a great HBOT token use case. @fengtality - LEDGER , would the staking requirements be fixed per exchange or would it be somewhat dynamized according to the volume going through the connector? Just that I could imagine that some exhanges would calculate whether it pays off to sign and honor a contract or whether to stake HBOT and if the amount of staking requirments is fixed, there would be a certain volume above which staking would become increasingly cheaper option.

Thinking out loud. Perhaps the staking requirement could be somewhat tied to the volume from the previous Maintenance Epoch or something like that.

Author: Lefty 0x9F8

Nice idea! Adding a use-case for HBOT would be very useful. We would need a better liquidity for the token first for the exchanges to be able to buy and stake it.

On the other hand, not sure the exchanges would be happy with taking risk of holding a volatile small cap token. Smart contract with locked stablecoins seems like a more natural solution. Ideally the smart contract would read exchange volume from an oracle, compute fees and check they were paid. If not, HB foundation would be able to withdraw the locked stablecoins.