Is it time xCOMB have some governance?

đŸŒ± Ideas
#1

The Briefest of Honeyswap History

Many of you may not have the full history of xcomb and I apologize to 1hive og’s for not doing the full exciting story justice. Maybe someone can cover that offline. The TLDR: HoneySwap is afaik the first dex deployed on xdai by the 1hive community. It essential is a fork of uniswap, 0.25% of the fees going to the LP providers and 0.05% to the honeymaker which buys back $HNY. 1hive has attempted several farms adding up to over millions of USD$ value in rewards over the past several years (2020 to present). Some time in Q1 of 2021 the tulip swarm was formed to redesign and redeploy farms adding some UI and UX changes. During this process the xCOMB token was born and changes to the protocol fees, 0.25% of fees still go to the LP providers but now protocol fees are split, 0.025% fees go to honeymaker for buy back of $HNY and 0.025% to buyback and burn of xCOMB. Since the launch there has been a great deal of discussion around what changes should be made but very little progress is made on these ideas.

So what is the problem?

  • Primarily, Gnosis has asked that we discontinue the stake-xdai farm. This seems pretty reasonable given stake token is being discontinued.

  • As a close secondary issue, even as correct as Gnosis is about removing stake-xdai farm, the farm allocations are still a very closed decision process and we should strive for a more open governance approach. The 1hive community has always had very heated debate on what are the best allocations for the farms which has led to prolonged discussions, delayed execution, and unsatisfied parties with conflicting process for how to assign points.

For these reasons I would propose we take a small step to test out an approach similar to how curve finance does gauge weight voting. With no additional resources we can deploy snapshot using the xcomb token to do weighted voting.
There are at least two potential failure points:

  1. We still are operating under a multisig and relying on a dev to honor the snapshot. This problem exist today regardless of this change and we can address this as a next step so this shouldn’t be a hang up as there would be no change to this.
  2. Snapshot wouldn’t allow for a trustless permissionless approach to adding an LP to the list but snapshot afaik can have at least 100 choices so we can virtually cover all options

Here are some references that may be of use to this conversation technical details can be found here the xcomb emissions can be found here

How would we decide which tokens would make it to the snapshot list.

This is probably the most important and most difficult part of this process. Consider we don’t need to have this perfected to move forward with the snapshot approach.

We could setup up a quadratic weighted voting proposal allowing voters to spread voting power across any number of choices and calculated quadratically. The top 20 choices with the most weight holding more than 1% of the vote would determine the allocation points for the next round. The points would be distributed proportionally based on the tally of the vote. These parameters such as top 20 or 1% can be up for debate or we can just select them and if concerns are warranted a vote can take place to set a new precedence. The tokens that make the snapshot list could be any token paired with $HNY with >$5,000 liquidity over past 30 days. Or any token >$100,000 liquidity paired with xDai, wETH, or HNY. A mock snapshot proposal might look something like the following:

image
image141×634 3.23 KB

xComb staking is not live rn but at somepoint it could be an option and would be part of this list. xcomb reserve just means the voter wants to reduce emissions and those emissions would be sent to a reserve used for future rewards.

As for the pairs towards the bottom; xgt, tec, haus, etc. if there is not more than $100k liquidity they would not qualify to receive xcomb allocations for weth or xdai pairing, they would only qualify for rewards with the HNY pair. The only reason I added this limit was for simplicity of the snapshot but it does add a nice dynamic maybe one day complimenting gardens a bit more than we do today. As it stands if we use these numbers there would be approximately 70 choices to choose from.

  1. some might want more or different pair choices than just xdai, weth, hny
  2. the cut off quantities such as $100k or $5k, top 20 or 1%, or others not mentioned may not be desired.
  3. the HNY pairs for what was once called the ‘discovery pools’ may also feel restrictive I would like to open it up to all 3 pairs (xdai, weth, and hny) and let users decide but then we would need to draw a higher cutoff so there are not 300+ choices to vote on.

Please just keep in mind what we are doing here is giving more use case and control to the honeyswap user and xcomb token holders, we are not trying to implement perfection over night. Let’s see if we are able to find some common ground with an open approach that does not require a lot of work, thanks.

Would you support using xcomb snapshot for honeycomb farm allocations?
  • Yes
  • No
  • Abstain

0 voters

5 Likes
#2

Still waiting feedback but I went ahead and attempted to setup a snapshot.

The snapshot only is looking at xcomb in gnosis chain wallet NOT xcomb LP or xcomb staked LP only because I haven’t figured that out yet.

The snapshot is in ~19hrs so go out and vote for fun on the test if you have some xcomb in your wallet, don’t forget you can claim some xcomb dust from the airdrop if you don’t want to unstake or pick some up on the open market.

https://snapshot.org/#/1hivexcomb.eth/proposal/0xf38ade1d7bd6c99cdac03245ea254ccce2999c2de6dee4d783da8343ceb1b95a

#3

I’m a little skeptical of a democratic system for liquidity rewards, but given the state of xcomb and Honeycomb it seems worth experimenting with.

I like the use of quadratic voting.

Will changes approved on Snapshot be implemented by the multisig? And if so will that multisig be updated with active contributors?

3 Likes
#4

If you’re going to put the work into enabling governance through Comb tokens you may as well separate Honeyswap from 1Hive while you’re into it.

At the current state and after everything that has happened it’s going to be hard to get a few devs to work on some of the stuff needed while having to compete with other products on 1Hive (see past discussions and the direction alignment proposal, not to say that none of the current dev force seems not to care about Honeyswap at all which is fine, but it’s important to notice that as well).

I doubt xComb governing just Honeycomb will make any difference or that it will be possible at all without devs to put in the work.

1 Like
#5

Yes, yes

It is probably important to consider what is allowed as part of the snapshot, ofc we don’t just token holders to just reward themselves.
Maybe Both xcomb holders and HNY holders that stake in celeste have voting power for farm allocations. LIke you said, pretty much anything is better than what we have today. If we see 90% of allocations going to staking xcomb the experiment i think we could agree has a pretty flawed outcome.

we are only talking about the allocation points for the farms not the protocol. governance for the protocol. we would need some thought on how do we ensure the 0.025% of hny fees don’t disappear and tulip just doesn’t ‘take’ honeyswap from 1hive.

No devs are needed at this point. Maybe lack of progress before was because there was too much work being requested. if devs are the issue then focus on work where devs are not needed. The question i proposed requires zero devs at this point. Do you support a snapshot for honeyfarms allocations? I will set up the snapshot. (no devs needed)

1 Like
#6

I get that but who’s going to implement what’s being voted on? If the STAKE-WXDAI LP is still there is because no one with enough knowledge has been interested in doing so, its been months since anyone first requested to change the farms, let alone that particular pair. That’s a big issue, I don’t see why or how anyone would want governance if no one can apply the results.

So far my understanding is a Snapshot with xComb and put active members of the multisig to approve the changes, do the people that are going to sign know or have the time/interest to actually make those changes? That’s my main concern.

But I have other questions as well, like how are you planning to deal with the difficult dynamic of changing the pairs with people locked at random times? I just don’t see this being doable without some bare minimum dev work and I don’t see any dev feeling comfortable working in the DeFi arm of 1Hive after all these heated discussions.

1 Like
#7

The 1hive xCOMB snapshot is up and running!

How/what type of strategy should we consider for the xcomb token allocation vote? Off hand:
1.) how should we resist against xcomb holders only rewarding themselves by only voting for 100% of all allocations to go to single side xcomb staking or just the xcomb-xdai LP?
2.) how do we ensure voters are voting in the interest of the protocol long term rather than just short term rewards?

Before reading further please take a look at what a quadratic weighted voting strategy for xcomb could look like. Here voters were given 63 options for allocating xCOMB rewards. I would like to use this as a starting point and make adjustments to how we could make this better.

Type of voting strategy

I propose we use a quadratic weighted voting proposal allowing voters to spread voting power across any number of choices and calculated quadratically.

Use Quadratic Weighted Voting
  • Yes
  • No

0 voters

Decision for whitelisting tokens to the snapshot

This is only the criteria for which tokens can be voted on as an option, not necessarily which get xcomb rewards.

The token pairs paired with 3 ‘base tokens’ wETH, xDAI, and HNY must have 30 days of token liquidity >$100,000.

The token pairs paired with HNY only if 30 day token liquidity is less than $100,000 but greater than $5,000.

Whitelisted token decision
  • Looks good
  • Add/Modify/Remove the ‘base tokens’. Please comment below
  • Modify the liquidity requirements. Please comment below

0 voters

Who has voting power

Consider how do we get successful protocol rewarding interested parties that will benefit the protocol. Rather than just xCOMB holders getting a vote I was thinking we could be inclusive towards all water token holders (the index D2D swap DAO token, the DAOs would not have voting power only individual holders), and ofc the $HNY token.

What is actually very nice about this is the token price of each of these tokens if we assume is roughly:

  • 1 xcomb = $0.15
  • 1 water = $1
  • 1 hny =$150

This means (for simplicity ignoring quadratic voting for a moment) if 1 xcomb = 1 water = 1 hny vote. then xcomb would have 10x the voting power of 1 water, and 1000x the voting power of hny.

  • xcomb having the most voting power makes since.
  • xcomb only having 10x the power of water seems like not enough separation especially for a new token (we have time to watch this play out before we make a decision) but as a thought experiment we could say only water held in the users wallet or a specific LP have voting power to lessen the theoretical voting power.
  • Lastly xcomb having 1000x the voting power of hny is a lot so ALL hny holders, LP, and or farms could have voting power and it still would not over power the xcomb voter.
Who should have voting power? Select all that apply
  • $xCOMB holders
  • $xCOMB and $HNY holders
  • $xCOMB, $HNY holders, and $WATER holders
  • Other please comment below

0 voters

I look forward to any other ideas the community may have? Just note we want to keep this simple. we can do some cool stuff but we shouldn’t get hung on the details trying to create perfection.

5 Likes
#8

I don’t think I understand the Token Whitelisting part. What’s the difference between how xComb rewards treat base tokens vs. non-base tokens?

1 Like
#9

There is no difference in how it rewards those, it is only the criterion used for determining which pairs to list in the proposal since listing pairs to vote on is manual. by listing every token with >100k liquidity with weth,xdai,hny and listing every token with liquidity between 100k-5k we had 63 pairs users could vote for.

The criterion are, how much the token has in liquidity. For example; fox which has more than $100k over last 30 days in liquidity there will be an option on the snapshot for the voters to to vote for awarding fox-hny, fox-xdai, and/or fox-weth rewards.

If for example Hausu which has less than $100k but more than $5k liquidity on honeyswap over last 30 days then on the proposal only Haus-hny would be an option to vote for rewards.

Lastly if you look at the Matic token it has less than $5k liquidity so it would not even be a choice on the proposal

does that make sense? I hope that helps, so the question is, keeping it simple, is liquidity the right metric at 100k/5k and 30 days? are the primary tokens the pools with more than 100k being hny, weth, and xdai the right tokens?

1 Like
#10

About this, I have another idea. Maybe we can also give some voting power to the NFBeez as well. What would you guys think? After all, the project could be said to be the result of a partnership of WATER participant DAOs in a way :smiley:

1 Like
#11

This one is a tough one. With a max cap of 2525, based on 0.15, 1 and $150 values and total amount in circulation it would be kind of difficult to put a formula in place. Would be good to have a vote on it though, being a multi DAO project. I would support it. Full disclosure though
 I am working on a few perks that may bring the price up a bit ( will have to be voted on) so not sure if that effects anything. The nfts can be used for quadratic voting as well.

3 Likes
#12

Yeah, I can see the calculation may be complicated. And I am not a math person at all. But if the community supports giving “some” weight to NFBeez, I think we can figure out a way to determine the weights as well. I was wondering if it could gather enough support at this stage :slight_smile:

2 Likes
#13

I am for it as long as the voting power is minimal compared to xcomb (primary voting token) and if its relatively similar to the 1hive & water tokens I don’t see why not. We would need to understand the rarity. it looks like rarity is based on the token id then snapshot can easily sort voting power based on the the token id?

as we add more voting tokens it does dilute the xcomb vote but as of rn thats not an issue especially at a $0.15 token price xcomb voting power is significant compared to the others

1 Like
#14

I can handle the math if given all the variables and inputs :slight_smile:

1 Like