Farming contracts about honeyswap HOT 5 CLOSED

2. Farm contract
   Currently we have a factory contract that allows for the deployment of UniPool contracts. These contracts accept Honeyswap LPs, and can be topped up with additional rewards from the Common Pool using conviction voting. The tokens are distributed from each farm over the course of an epoch (currently each 30 days). We have a mechanism that allows us to reset an Epoch only if it would increase the total rewards during that epoch.

With the sustainable farming approach we want to automate the funding and allocation of rewards for farms, providing a more consistent and predictable LP rewards.

Reviewing the sushiswap masterchef contract, we may want to use that as a base for these new farms instead of our current unipool contract factory approach. In the masterchef contract, rewards can be managed across multiple pools using “allocation points”, and rewards are split among the pools at the start of each epoch based on these allocation points.

Proposed Changes to MasterChef

In the masterchef contract, the farming token is part of the contract and rewards are funded via issuance. In our model, the farming token will have a fixed supply with an initial distribution schedule and then ongoing rewards associated with fee recycling.
I would expect we could have the tokens pre-minted, and pulled into the farms rather than issued on each farming epoch, then if there are not enough tokens take the remaining balance for the farm epoch instead.
There is also a migration function, which I think we should remove in the interest of reducing risk for LPs, contracts should not be able to migrate LPs.

from honeyswap.

1. Fee router
   The Honeyswap Factory has two functions used to control fees, a feeTo and feeToSetter variable that are both addresses. Currently feeTo points to the HoneyMaker contract. And feeToSetter is currently set to the Agent address of an Aragon DAO I set up when we initially deployed. Both can be changed by the feeToSetter address.

The feeTo address acts as an accumulator of the the 1/6 share of swap fees that are allocated to 1Hive. The current contract allows anyone to call a function to convert fees (accumulated in various LP tokens) to Honey which is then sent to the 1Hive common pool.

The upgraded contract would split these fees between Honey and HSF-xDai, routing the Honey to the common pool as we do now, and splitting the HSF-xDai between token burns (permanently reducing circulating supply with fees), and recycling tokens back into the Farm to create longer time horizon incentives for LPs.

from honeyswap.

What if we didn't burn any tokens? Sure deflation is cool, but burning supply rewards all holders while distributing the tokens rewards the farmers. Wouldn't it be better to maximize the incentive for LPs and other farmers by distributing all tokens?

from honeyswap.

Requirements for task:

• using Sushi's Masterchef contract as a base remove all centralized functionality such as migration
• implement linearly decreasing rewards, for formula check #8
• track deposits with no timelock as one but track each timelocked deposit separately
• use ERC721 standard to track ownership of deposits, use OZ contracts to simplify integration

from honeyswap.

Another thought i had instead of burning the tokens and doing a buyback into honey was to instead incentivize the swaps with HSF so those tokens go directly to the people using that platform. That way its an added incentive that increases volume and thus higher rewards for LPs.

from honeyswap.