Repository navigation
Liquidity Mining #17
Description
Liquidity mining is a mechanism to help with market-making by providing liquidity and earning liquidity incentives in return.
Overview
- Liquidity incentives provide more stronger incentives than staking incentives because a lock-up of paired assets accompanies the provision of liquidity.
- Liquidity providers get DEVs as liquidity incentives based on the number of DEVs provided.
- The liquidity incentives are equal to the sum of the staking rewards and holder rewards. This spec means that the liquidity incentives are equal to "the reward for staking to Property owned by itself."
- As noted above, liquidity provision is a new method of staking and does not accompany new inflation.
- However, if a liquidity provider performs Property staking, the liquidity incentive is increased. This spec is tentatively named the Conjunction Incentives.
Conjunction Incentives (tentative name)
- Since liquidity incentives are stronger than staking incentives, the Conjunction Incentives works to reinforce the incentive for staking.
- Earns incentive of 0.000000003 per block for a liquidity pool price of $1 and Property staking of 1.
- Example: Liquidity pool price is $12, staking is 200 DEV, for the incentive is 15.13728 per year.
12 * 200 * (1 year in seconds / 15) * 0.000000003 - Example: Liquidity pool price is $1000, staking is 200 DEV, for the incentive is 1261.44 per year.
1000 * 200 * (1 year in seconds / 15) * 0.000000003
Technically flow
- Staking UNI tokens into the (newly developed)Liquidity contract.
- Retrieve the number of DEVs associated with the UNI tokens and treat the same number as stake.
The APY is recalculated.(Incentive budgets are allocated from the existing balance and therefore do not affect APY)- The liquidity provider's reward is taken directly from the
Allocator.calculateMaxRewardsPerBlock()calculation. (no proration for stakers and holders) - Run a batch script to get the price of the liquidity pool once every 24 hours.
Activity
calaber24p commentedon Sep 6, 2020
I think this is a great idea, I just had a few questions about specifics. Will the staking act like another property on the stakes.social platform? For example will staking the uniswap liquidity token bring down the APY because it is counting both pools in the staking amount? So ultimately the inflation rate stays the same because the coins are coming from the same place that coins are coming from now for people who stake regular properties ?
Akira-Taniguchi commentedon Sep 6, 2020
great idea
aggre commentedon Sep 7, 2020
@calaber24p In liquidity mining, DEV staked for liquidity mining is treated the same as normal staking (staking to Property). Therefore, the APY will be reduced.
aggre commentedon Sep 7, 2020
aggre commentedon Sep 7, 2020
The quickest and lean-way to get started: fork Geyser.
https://github.com/ampleforth/token-geyser
Contract: https://github.com/ampleforth/token-geyser/blob/master/contracts/TokenGeyser.sol
The contract asks for a few initial parameters.
calaber24p commentedon Sep 24, 2020
I think forking Geyser is fine if thats the way we decide we want to do it, also just simply matching the liquidity mining to the staking reward + creator reward is fine with me. I am indifferent on how we achieve liquidity mining. I am only against increasing the supply of tokens or using the developers wallet to fund liquidity mining. I believe we need to find a self sustaining way to offer liquidity mining rewards.
aggre commentedon Sep 25, 2020
@calaber24p Thank you for your comment.
In my first proposal, the provided liquidity DEVs are treated as actually being staked, lowering the APY. But, pooled DEVs as liquidity have no "actual" effect on creators. There is an indirect effect of stabilizing the price of DEV, but that is true for all stakeholders, not just creators. In other words, I believe that the impact of the size of the liquidity pool on the Dev Protocol APY is an excessive tight coupling.
What do you think about this?
calaber24p commentedon Sep 28, 2020
I personally like your first proposal even if we decide to not fork Geyser. I know the lowering of APY might not be completely desirable with how it affects creators, but ultimately I think we should figure out a more permanent solution versus a short term one. There are other options to counteract the addition of the liquidity pool such as potentially raising the inflation schedule slightly to counterbalance it.
aggre commentedon Sep 28, 2020
The advantage of assuming that liquidity provision and APY calculations are non-interfering with each other is that it is possible to completely decouple the liquidity mining program from the smart contract of the protocol. This is correct and attractive from a software engineering perspective.
I think the liquidity mining budget should be allocated from the team wallet, as you said. So, in other words, it's more correct to call it vesting than mining. Additionally, liquidity providers have an incentive to staking by Conjunction Incentives*. I think that would result in a lower APY.
*btw, I find this name unintuitive 😓
bibryam commentedon Sep 29, 2020
aggre commentedon Sep 30, 2020
Conjunction Incentives(tentative name) calculation is on a per Property basis. I noticed that it couldn't use the amount of liquidity provision in that calculation formula. That is because staking has multiple metrics per person, but liquidity is one metric per person. I already updated the core concept.
Akira-Taniguchi commentedon Oct 14, 2020
I would like to discuss the design of liquidity incentives.
How much liquidity incentive do you think should be granted in total?
I think I'm around 10,000 DEV in total at the moment.
Reason: Because the reward for the challenge project so far has been 10000 DEV.(This is not a very strong reason.)
Do you think it is better to release liquidity incentives in stages or not?
I understand that the benefit of releasing them in stages is to ensure rewards for latecomers.
And if so, what schedule do you think should be followed and how much value should be released?
At the moment, I don't have any particular early join bonus in mind. Do you think that's a good idea?
// 以下、日本語
流動性インセンティブ設計について相談があります。
流動性インセンティブはトータルでどれぐらいを付与すればいいと思いますか？
今の所合計で10000DEVぐらいかなと思っています。
理由：今までのチャレンジ企画の宝珠が10000DEVだったため、なので理由としては薄い
インセンティブを段階的に解放していくか、しないか、どちらがいいと思いますか？
段階的に解放していくメリットは、後発の人のための報酬を確保するためだと理解しています。
やはり段階的に解放していくべきだと思いますか？
またその場合、どのようなスケジュールで解放していくべきだと思いますか？
今の所、特に早期ジョインボーナスは考えていません。それでいいと思いますか？
@aggre @calaber24p
aggre commentedon Oct 14, 2020
@Akira-Taniguchi The token allocation determines the volume of the liquidity incentive. A placeholder is fine during development.
Can it vest the incentives after the team achieves funding? (Would you describe this as unlocking?)
Geyser will be incentivized for users who provide early liquidity. That specification should be followed.
Akira-Taniguchi commentedon Oct 16, 2020
yes, I'm sure the schedule can go back and forth, so you can run the lockTokens function and deposit the reward tokens after you've raised the funds.
Roger that, I'll make adjustments in that direction.
@aggre