Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liquidity Mining #17

Open
aggre opened this issue Sep 6, 2020 · 14 comments
Open

Liquidity Mining #17

aggre opened this issue Sep 6, 2020 · 14 comments
Labels
layers 3rd party service/protocol built on the protocol core priority - high

Comments

@aggre
Copy link
Member

aggre commented Sep 6, 2020

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

  1. Staking UNI tokens into the (newly developed)Liquidity contract.
  2. Retrieve the number of DEVs associated with the UNI tokens and treat the same number as stake.
  3. The APY is recalculated. (Incentive budgets are allocated from the existing balance and therefore do not affect APY)
  4. The liquidity provider's reward is taken directly from the Allocator.calculateMaxRewardsPerBlock() calculation. (no proration for stakers and holders)
  5. Run a batch script to get the price of the liquidity pool once every 24 hours.
@calaber24p
Copy link

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
Copy link
Member

great idea

@aggre
Copy link
Member Author

aggre commented Sep 7, 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 ?

@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

This comment has been minimized.

@aggre
Copy link
Member Author

aggre commented 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.

Arg Value
stakingToken IERC20(0x4168cef0fca0774176632d86ba26553e3b9cf59d)
distributionToken IERC20(0x5cAf454Ba92e6F2c929DF14667Ee360eD9fD5b26)
maxUnlockSchedules 100
startBonus_ 20
bonusPeriodSec_ 2592000(1 month)
initialSharesPerToken 1

@calaber24p
Copy link

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
Copy link
Member Author

aggre commented Sep 25, 2020

@calaber24p Thank you for your comment.

  • If we use forked Gayser, we can't actuarially match a reward to the staking reward + creator reward.
  • I, too, think the liquidity mining budget will be contributed from the current supply.

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
Copy link

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
Copy link
Member Author

aggre commented 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 😓

@aggre aggre added this to Stage 0: Strawman in DIP Process via automation Sep 29, 2020
@aggre aggre moved this from Stage 0: Strawman to Stage 1: Proposal in DIP Process Sep 29, 2020
@aggre aggre moved this from Stage 1: Proposal to Stage 2: Candidate in DIP Process Sep 29, 2020
@bibryam
Copy link

bibryam commented Sep 29, 2020

*btw, I find this name unintuitive 😓
I like the word Compound Incentives more.
It means to pay (interest) on both the accrued interest and the principal, also it reminds me of COMP :)

@aggre
Copy link
Member Author

aggre commented 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.

@aggre aggre added this to To do in 🌏Roadmap🪐 via automation Oct 2, 2020
@aggre aggre moved this from To do to In progress in 🌏Roadmap🪐 Oct 2, 2020
@Akira-Taniguchi
Copy link
Member

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
Copy link
Member Author

aggre commented 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.

@aggre aggre added layers 3rd party service/protocol built on the protocol core priority - high and removed enhancement labels Oct 15, 2020
@Akira-Taniguchi
Copy link
Member

Can it vest the incentives after the team achieves funding? (Would you describe this as unlocking?)

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.

Geyser will be incentivized for users who provide early liquidity. That specification should be followed.

Roger that, I'll make adjustments in that direction.

@aggre

@aggre aggre moved this from Stage 2: Candidate to Stage 3: Implement in DIP Process Oct 19, 2020
@Akira-Taniguchi Akira-Taniguchi moved this from Stage 3: Implement to Stage 4: Finished in DIP Process Nov 17, 2020
@aggre aggre moved this from In progress to Done in 🌏Roadmap🪐 Dec 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
layers 3rd party service/protocol built on the protocol core priority - high
Projects
DIP Process
  
Stage 4: Finished
Development

No branches or pull requests

4 participants