🍯 Honeycomb V2 Brainstorm

Motivation

1Hive seeks to realize a future that is more free, fair, open, and humane. To do so we need to create an economic engine that can effectively and sustainably fund public goods. By working together to make Honey valuable and then continuously distributing it towards public goods we can create a better future for everyone to enjoy.

In order to run the economic engine that funds public goods we need fuel, aka liquidity. Right now if you want liquidity you have to be on mainnet and pay mainnet fees. For many projects these fees discourage innovation and engagement. HoneySwap makes it easy. There’s low fees, transactions are fast, and anyone can participate. The problem is, there’s not a lot of liquidity.

Honeycomb seeks to address this by making it possible for the 1hive community to reward liquidity providers with HNY. This has resulted in ~ 3X increase in HoneySwap liquidity in the last week or so. This is great, but there are many token pools that might not have enough activity/interest to be supported by HNY liquidity mining. That being said, we still want them to succeed. The more tokens succeed on HoneySwap the more people will use it. The more activity and liquidity on HoneySwap the better.

Ideally it’s easy for anyone to provide staking rewards for any token with any token. This would allow communities to provide liquidity rewards for their token on HoneySwap using their own token. If multiple tokens are supported for staking rewards then (ideally) users would wouldn’t have to choose between staking in competing rewards programs. They could just stake to Honeycomb and anyone could provide rewards for that staked token. This could drive more liquidity to HoneySwap overall while also helping communities bootstrap liquidity to drive their economic engines.


Design Goals

Stakers just set it and forget it. A single pool for every asset.

Setting up a reward program is easy. Just choose the staking pool you want to incentivize and send tokens to be unlocked for stakers based on their time staked and proportional share of the staking pool over that period.


Rough Gameplan

TL;DR:

Modify Unipool so that there’s an array of assets that are eligible for rewards.

Backend Contracts

In order to prevent a DDOS type attack we want to limit the amount of tokens that can be eligible for rewards. Otherwise it might require too much computation to withdraw token rewards. Here’s a few ideas, but there’s also probably better ideas out there too. If you have any, please share!

Permissioned Whitelist Model

HNY holders control the list of tokens eligible for rewards. This is required to prevent someone from adding so many tokens to the list that the contract can’t execute or it’s prohibitively costly to run it. HHNY holders will be able to vote to modify the token list directly within HoneyComb. Removing a token from the whitelist will only lock future deposits, but it will not block withdrawals of that token that have been earned.

  • There is a whitelist of reward tokens.
  • Every pool can accept all whitelisted reward tokens.
  • Transfers of non-whitelisted tokens to reward pools revert.

In this model HNY holders would control the rewards whitelist. Initially it would be rather permissive, but eventually we might want to cap it at 100 tokens or something. This would require ongoing management by HNY holders. This might be good in that it would incentivize token projects to contribute to the community in order to get white listed. It might also be less than good because as HoneySwap grows, then smaller projects will be less able to provide liquidity mining rewards for their token if they’re competing with larger projects on the list.

Opt-in Harvest Model

Another way to prevent such an attack might be to make harvesting opt-in. In this model users would have to manually choose tokens they want to harvest. This way anyone could send tokens to the reward contract to reward stakers, but it would be up to staked token holders to choose which rewards they want to harvest. This would make HoneyComb a staking/airdrop platform, incentivizing liquidity providers to stake to earn rewards and token projects that want distribution among capital providers to reward stakers.

This might look like re-architecting the Unipool contracts so that there’s a staking pool for each token, and then multiple rewards contracts for each staking pool. Stakers would stake, withdraw, and harvest from a single contract. Anyone could create a payable rewards contract connected to the staking pool of their choosing. The params for the rewards contract would be set in the constructor so that the only contract that can withdraw tokens would be the staking pool. From there anyone could top up the rewards contract by sending tokens to it.

Frontend User Interface

  • Keep it as simple as possible.
  • Stakers: Shows all the rewards that you can harvest. This might look like querying the balances of the reward pools and showing those that have a non-zero balance. Stakers can then choose to withdraw tokens (all at once or maybe one at a time depending on the architecture of the contracts).
  • Reward providers: Allows you to just send tokens to the rewards address to top up the rewards pool. Transfers of tokens not on the whitelist will revert.

A few other ideas

Fees

Might have an (optional) small fee that takes a % of the staking rewards distributed. This would charge staking reward providers for using the HoneyComb platform to distribute tokens. This fee could be set by HNY holders, but initially be set to 0.

From there, fees could go into a common pool to support HoneyComb development/maintenance.

Alternatively, fees could go into a HoneyCombIndex contract. There would then be a token that can be withdrawn for a proportional share of the pool, and would thus represent exposure to the entire HoneySwap platform. These tokens could be distributed to the HNY holders and/or HoneyComb stakers. This is probably a V3 idea.

Your Idea Here!

This is just a brainstorm, so please share if you have any ideas on how to design the contracts to allow for multiple token rewards programs with multiple tokens to reward stakers.


Next Steps

Looking for feedback! The goal is to support the bootstrapping of community currencies and token pairs on HoneySwap, esp HNY. Please share any ideas around that and how we might make HoneyComb better :honey_pot:

10 Likes

I prefer the Opt-in Harvest Model over the whitelist model to reduce decision making by the DAO but unfortunately I’m not sure if it’s possible without some clever maths. Currently every stake transaction, as well as withdraw, would have to loop through every reward token to update their details. Unless a user specifies when they stake, the reward tokens they will claim, then only those would need to be updated.

1 Like

Another idea would be to incorporate a time multiplier so that the longer you’re locked, the more rewards you get. This might look like an asymptote so that early liquidity providers don’t earn infinite rewards, but there’s a cost to withdrawing tokens (and thus starting again at the bottom of the rewards curve). Might help to add some stickiness to the liquidity.

1 Like