Liquidity Mining

[aggre]

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]

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]

great idea

[aggre]

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]

UPDATED

---

Liquidity providers receive DEV tokens as an incentive-based on pool size and price, and elapsed blocks.

Imagine there are two people in the network, Alice and Bob, Alice staked 10 liquidity tokens for 1 day (5760 blocks), and Bob staked 5 liquidity tokens for 3 days (17280 blocks).

Alice_share = 10 tokens * 5760 blocks = 57600
Bob_share = 5 tokens * 17280 blocks = 86400

Global_share = Alice_share + Bob_share = 144000 token_blocks

Alice owns (57600 / 144000) = 40%
Bob owns (86400 / 144000) = 60%

The inflation rate is calculated using the Policy.rewards formula. Its arguments are the liquidity pool size and the number of liquidity providers. Assuming Alice provides 200 DEV and Bob provides 100 DEV, for a total provides of 300 DEV, and the current pool price is $5, and the previous highest price is $12, the daily (5760 blocks) incentive for Alice and Bob is calculated as follows.

Infration = Policy.rewards(300, 2) = 0.000239953684689838 ≈ 0.00024
Global_reward_per_block = Infration * $5 / $12 = 0.0001

Alice earns (0.0001 * 5760 * 40%) = 0.2304 = 42.048% APY
Bob earns (0.0001 * 5760 * 60%) = 0.3456 = 126.144% APY

The closer the pool price is at the highest price, the more incentives. When updating the highest value, the coefficient is 1. Larger liquidity pools reduce incentives, and more liquidity providers increase them. This spec acts like a pseudo-tax on small providers when liquidity is sufficiently large, meaning that there is progressively less room for new providers to enter the market. Liquidity incentives work better for a large pool than a small pool, and early join than late join.

[aggre]

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]

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]

@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]

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]

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]

*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]

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]

I would like to discuss the design of liquidity incentives.

1. 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.)

2. 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?

3. 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]

@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]

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