HP021 - Initiate Bounties Committee

Passed
1

Initiate Bounties Committee

This proposal seeks to:

  • Initiate a Bounties Committee Tasked with effectively allocating bounty funds to grow Hubble Exchange through integrations.
  • Onboard certain members from the community to the Bounties Committee.
  • Allocate $100,000 to Bounties.
  • Allocate 1% of the token supply to initiate a bounty program for smart contract exploits.

Premise

Upon the launch of Hubble Exchange on mainnet, a surge in developer interest has been observed, ranging from liquidation bots and NFT scripts, to those interested in contributing at the protocol-level with features such as limit orders. To finance and support projects and developers building on top of Hubble Exchange, a new committee is proposed: Bounties Committee.

Responsibilities

The bounties committee is tasked with effectively Allocating Bounty Funds to Grow Hubble Exchange through Integrations. Its responsibilities include:

  • Evaluate and Process Bounty Proposals.
  • Support and build a community of devs.
  • Work with developers to price bounties and create milestones.

How do you propose a bounty?

To propose a bounty to the committee, applicants may use the following link: https://forms.gle/ivVeRK58jQe42tro9

All proposals received will be reviewed and evaluated.

Transparency and record-keeping

All bounties will be tracked publicly on https://bounties.hubble.exchange

Examples of Projects:

  1. Structured Products, such as Funding Rate Arbitrage Vaults, Delta-Neutral sAVAX vault, pseudo delta neutral LP vault.
  2. Bots such as one that displays statistics live in the discord server or one that may text you on telegram if you’re close to being liquidated.
  3. Tooling such as a leaderboard for top referrals or exchange statistics, LP profitability calculator.

Members

To ensure the efficacy of the Bounties Committee, it is vital to onboard members who possess insight to strategically allocate these bounty funds. Members must be diverse in perspectives and value-proposition.

  • Power-users of Hubble Exchange who have a deep understanding of what would bring the most value to our community.
  • Strong technical skills, relevant in evaluating scope of work and calibre of applicants.
  • Avalanche-natives and DeFi-users who bring to the table a strong understanding of the ecosystem to evaluate and encourage integrations, vaults and other opportunities.
  • Traders.

Proposed Members:

  1. Sir MoreMoney

A power-user of Hubble Exchange since Day 1. SirMoreMoney has been diligently accumulating

vHubble and making key contributions to governance proposals, as well as expressing interest

in contributing at the protocol-level to build limit-orders. He is a co-founder and head of products at the MoreMoney Protocol on Avalanche.

  1. Sindermann

Sindermann has been contributing to TraderJoe as a content creator, creating threads and blog

posts as a writer. He possesses a deep understanding of protocols within the Avalanche Ecosystem and has a way of explaining complex concepts very clearly. His contributions to Hubble Exchange include creating threads on important integrations and deconstructing the protocol design. As a result, the Hubbleverse DAO intends to onboard him to the Educators Grant. His grasp over the ecosystem makes him a strong contender for the Bounties Committee.

  1. Asquare08

Part of the core contributing team, asquare08 has made integral contributions at the protocol-level to Hubble Exchange. He possesses a strong technical background in smart contract development and the Hubble Exchange protocol which will be an invaluable resource to developers as they integrate with the exchange.

  1. CalculatorGuy

A power-user of on-chain as well as centralised derivatives exchanges, CalculatorGuy has onboarded over 30 traders to Hubble Exchange through his referral code. He has shared insightful product feedback, including a unique feature request that may increase protocol revenue for makers and enable complex strategies. He possesses a deep knowledge of executing strategies when it comes to perpetuals, such as funding rate arbitrage. His eye for identifying and evaluating the feasibility of real yield and delta neutral strategies will be particularly valuable to the bounties committee.

  1. Luca BWS

Founder of BWS Labs, a Multi-strategy Hedge Fund, built on top of DeFi Vault technology. Luca

has over 10 years of experience as a trader and has been trading on Hubble Exchange since near its inception. BWS is currently building a vault on top of Hubble Exchange. As a trader himself, he understands what’s important for trader-onboarding.

  1. Dorlanz

Community members may recognize Dorlanz as the manager of the Hubbleverse DAO. Since

Dorlanz’s first onboarding to Hubble Exchange, he has been a key contributor to many salient initiatives, such as the Hubble Space Cats. He has taken initiative to contribute at

the product-level with his valuable insights, Business Development with inventive ideas and tokenomics design with his appreciation of good token economy design. His ability to build and maintain relationships is apt for the bounties committee.

  1. Kepler (endorsement written by Set0x)

Kepler is a genesis core contributor of the Hubble exchange DAO. He has made significant contributions to all aspects of the DAO ranging from governance contribution to community building functions, marketing and partnerships, and works closely with other members of the DAO to assist with the continual smooth operation of the Hubble Exchange platform. With his constant contribution, expertise and understanding of every facet of the DAO, he is a potentially invaluable member of the Bounties Committee.

To avoid governance fatigue and to ensure frictionless onboarding of talent, the genesis members of the bounties committee are assigned the capacity to onboard new members through an internal vote.

Bounty Program for Smart Contract Exploits

To incentivize whitehat hackers to identify and report smart contract vulnerabilities, a bounty program is proposed for smart contract exploits.

Pre-authorize Reward:

  • 1% of the hackable value of an exploit in vHubble, priced at the seed round valuation.
  • A component of the reward paid in USD, at the discretion of the Bounties Committee and based on the scope of the exploit.

The total vHubble allocation proposed to this program is 10,000,000 or 1% of the token supply.

  • For
  • Against
  • Neither

0 voters

2 Likes
2

Guys, all these votes are still good people for “now” But I dont think you got much time for crypto space. Just a little warnin that you know much than me and others. Good luck.

3

I am personally strong against this bad proposal. Reasons:

  1. Bounties Committee
    People with common sense know that the goal of this proposal is to make a fake decentralization. If you want be a true decentralization, then these members need to be introduced by the community and an election needs to be done.
    But sadly they make a list of people by themselves who will represent the community to handle the payment of the bounties fund and might add more powers in the future. As this proposal their power will be the bounties of 10,000,000 vHubble (400,000$ at seed valuation) and 100,000$ bounties fund. I need to say again majority of these bounties will come from 10,000,000 vHubble. 10 million Hubble tokens will be dumped on the market upon the token launch which will damage the price of Hubble token and make us poor. No, it cannot happen, these bounties need to pay in USD of the fund rasied.
    I have a look at these members who they are:
    Dorlanz, Kepler, Asquare08 they are core contributing team – imo they deserve for the role.
    Hubble Power Users (they should change the name like trading experts ,or hedge fund experts because they are never more Hubble power user than me) – some people they are founders of another projects which might bring the conflicts of interest and one man called CalculatorGuy man I have never ever seen he has any sharing or activity in discord group.
  2. Bounty program for smart contract exploits:
    The very very big reward is described in a few sentences. It is so bad. My question is: who is eligible for participating the bounty? What is scopes of exploits? What is the reporting requirements? how the payments to be allocated for types of vulnerability?..

a lot more to say about this proposal but I feel it is meaningless…

3 Likes
5

If Hubble team completely finished the selection of the bounty committee, there should not have a proposal for this. And it is fine, it is the choice of Hubble team. But when you make a proposal, you run an election, you get many votes from your insiders, you win the election. And then this bounty committee can legally represent the voice of the community.
Regarding to the Bounty Program for Smart Contract Exploits, I am personally big support this program, but it has to be written in much more details about the terms of this bounty reward for transparency, and to avoid insiders abuse it. A few ambiguous words can get 10 million Hubble token funding ($400,000 at seed valuation), it seems an oppression against the community - the people are trading and farming hard to earn vHubble reward. And the payouts need to be denominated in USD, not in Hubble token. If you are confident in the floor price of Hubble token at 0.004$, then the bounty reward could be $400,000 paid in Hubble token if it has to be. If you are not confident about it, the community too, then this will be the destruction of hubble price.

6

All of the people selected are professionals and if it makes Hubble even better, I agree. If we continue to stand still here, nothing will change. It is not too late to disagree after we see how they work. If the results are not favorable, we can vote again.

1 Like
7

Hi Tikijiu;
There are two separate things we need to vote in this proposal:

  • 1st: Initiate Bounties Committee
  • 2nd: Bounty Program for Smart Contract Exploits which is described in a few ambiguous words to raise 10 million Hubble token funding ($400,000 at seed valuation)?
    You vote favor both?
8

Yes, of course. I am a very early Hubble user. The team always works to make Hubble a success and has always accounted for everything they have done. I trust them. They are a bit wordy in some respects in my opinion. But I think the presence of users like Blr will eliminate that.

9

I got your view. We are different. My main concern is the 10 million hubble token bounty,. the non-transparency will make it abusive and corrupted.

1 Like
10

I disagree, I think this is very transparent in how the bounty works. It clearly says people who find a bug will receive 1% of the monetary damage that the bug could have caused. the 10M vHubble will only be used if a critical bug is found, hopefully never in the future! But we need to be ready regardless

11

Ser;
It is the $400,000 bounty, it deserves a separate proposal with detail terms and conditions, bounty payments dominated in USD, the frameworks for judgments of the bounty committee… It not only helps the bounty to avoid the abuse and corrupt behaviors but also help to attract the participants and helps the community to supervise the rewards. A lesson from the trading competition proposal needs to be learned.

12

Hey blr, what framework for judgements would you like to include?

13

I don’t know, you and the bounty committee need to work on it. But I think there was a comapany in defi doing aclassify bugs system, something like: Critical, High, Medium, Low, None. And the judgment and payments need to make based on it like if Low, then what is the payment range in USD, if Critical, then what is the payment range in USD….

The reward like “1% of the hackable value of an exploit in vHubble” simply never work. Common sense, if a true Hacker see a critical bug, will he report to Hubble to receive 1% value hacked???

I believe this kind of bounty will be active in all the time life of Hubble. You cannot cap of the bounty in 10 million Hubble token or 100 million Hubble token. It can be less but there is a high chance it will be much much much larger, who know??? If Hubble could be success, then the revenue, the treasury would pay for it.

14

Hey blr, I would actually argue that the framework you have suggested is quite subjective and opens up ambiguity. It leave a lot of discretion to the committee. The concept of “critical, high, medium, low” are all subjective opinions and now we have to vote on what each of those mean.

The framework suggested in the proposal is quantifiably verifiable.

Note: anyone can model out a hack to identify how much capital it could exploit.

Let me share an example. An exploit is reported. It is identified that the insurance fund could be drained, Let’s assume there’s $200,000 USD in the insurance fund, this is the amount of capital the exploit could have stolen.

1% of $200k is $2000. The hacker would receive $2000 in vHubble for reporting the hack. No more.

Similarly, if there is a hack that could drain $5,000,000 from the protocol, the hacker would receive 1% of $5M which is $50,000.

This model is quite straightforward and leaves very little room of discretion for the bounties committee, except having the responsibility to model out the hack and identifying how much it would put at risk. This is an objective calculation.

15

I disagree. My question: Have ever been any successful Defi project using 1% model? It not, it is un-tested method. As I mentioned it is reasonable to assume that if a hacker can see a bug to drain $5 million, they will not report for 1% of the value drained, the reality of this is normally 10%. I argue that the 1% value hacked will open the door for small meaningless bug reports for the bounty which I name it abuse and corrupt behaviors because these 1% value comes from the own Committee judgment without any Standard to compared with. The concept “critical, high, medium, low, none” is developed with multiple factors to judge a vulnerability. It is used by many major defi projects like GMX, dydx… So, it is tested method, transparency and the community can supervise it. here is the link if you do not read it yet: Immunefi - Immunefi Vulnerability Severity Classification System - v2.2

16

Are you suggesting increasing it from 1% to 10%?

Keep in mind we are using the seed round valuation. 1% has the potential to be worth much more if the protocol is successful.

1% gives the exploiters exposure to Hubble Exchange at a good valuation and aligns their incentives to add value.

If they exploited the funds, they would have a permanent legal target on their back. Exploits may also cost $ and have risk. If it doesn’t work, they may actually lose money.

In my opinion, if someone wants to exploit the protocol, even 10% in USDC is too less. And for someone who wants to do the right thing, even 1% in vHubble is enough.

If the reports are “meaningless and small”, then they wouldn’t exploit any funds. So how would they be eligible for a bounty?

These criteria you have shared would be a good idea if we were classifying exploits that didn’t put user funds at risk - in which case you would need a qualitative method of categorization, not quantitative. In our case, the exploit is directly quantifiable so it does not need qualitative categories. It’s redundant, unless in the future the scope of the program is expanded to those hacks that don’t exploit funds - in which case I agree we would need this.

17

We are currently investigating a case of fowl play on this forum post. It appears multiple accounts were created, used to vote against HP021 in an effort to manipulate this temperature check.

Unfortunately, this is a serious violation of the governance process and undermines the temperature check’s validity.

The individual behind this knows who they are. At this stage, they are encouraged to desist and make amends.

The governance process of any DAO is sacred and breaching it is a serious violation.

Although the temperature check may be manipulated, it’s impossible to manipulate a vote with HSC on snapshot. The proposal will be pushed to snapshot so Hubblers can have a fair chance at deciding the fate of HP021.

Changes to Hubble Exchange’s meta governance framework can be discussed and implemented to avoid instances like this in the future.

1 Like
18

I was going to suggest same thing. Let migrate this proposal to the snapshot and HSC holders vote it.