Stake as an Index

[aggre]

Problem

In the Dev Protocol now, has the Npm Market indexed by the number of npm package downloads. There is an imbalance, with staking concentrated on projects with high downloads.

Solution

The inflation rate and coin issuance is changed from distributing coins based on number of weekly downloads and stake amount, to a set 3% yearly inflation, split among each block, with the number of coins split among stakers based on the percentage of the staking market they have.

Example: (Random numbers for easy example)

100 coins are created per block.

Project A has 25% of the total coins staked

Project B has 60% of the total coins staked

Project C has 15% of the total coins staked

Per block the split would be the following

Project A developers get 12.75 coins (51% of 25) and Project B stakers get 12.25 coin (49% of 25).

Project B developers get 30.6 coins (51% of 60) and Project B stakers get 29.4 coins (49% of 60)

Project C developers get 7.65 coins ( 51% of 15) and Project C stakers get 7.35 coins (49% of 15)

This change allows smaller projects who are just starting and don’t a lot of downloads, to compete with big established projects.

Ultimately what projects get funded is decided by the stakers rather than the amount of downloads on npm.

---

This DIP was drafted by @calaber24p

[calaber24p]

I put this DIP forward and I want to explain what problem I believe it currently solves.

Currently we have a mismatch with incentives when it comes to which developers you stake and the inflation rate on the platform.

First I want to address the developer staking issue. As the reward structure works right now, the amount of rewards is very closely related to the amount of downloads a certain project gets on Npm. As a staker if you are looking to make the most amount of profit, you will want to stake these bigger projects because it is more profitable. This ultimately makes it so smaller developers who also need funding are left with no one staking them.

I believe the staker's role should be to support projects they want to see get developed regardless of size. Even the biggest projects that exist now, started with no downloads or users and under the current system, they wouldnt get funding. My proposal changes this and levels the playing field, giving more power to stakers to decide where the rewards go.

Under the new system, someone who wishes to stake a smaller developer would receive the same rewards as someone who wants to stake a larger developer. Because the number of downloads is no longer relevant to the rewards, the amount of new coins created is split based on how much of the staking network a specific project has. It ultimately gives the stakers the power to decide which projects are funded and lets them choose without having to take rewards into consideration.

Now the inflation rate change. Currently the amount of coins created is unpredictable and highly dependent on if new developers join. We have seen massive inflation in the circulating supply in the last week or so and I aim to curb that with this proposal. By making the supply constant and predictable we inspire confidence in the token and the project itself long term. The 3% inflation will be used to reward stakers and developers, while also being able to maintain the supply at a desirable amount. Not only will stakers and developers be rewarded, but a stable and predictable supply inspires them to reinvest back in. If you have any questions feel free to ask.

[aggre]

There are several ways to implement this. I'll write about them here later to help you think about which one is appropriate.

[aggre]

I thought of some methods. And I thought Method 1 was appropriate, rather than not using the index. What do you think? @calaber24p

Method 1: Update the Policy

Policy manages how to calculate asset strength based on asset value (number of downloads, etc.) and staking. The current policy is asset strength = asset value × staking.

For this proposal, I propose a new Policy that reduces or 0(doesn't use the value) the effect of asset value.

In my opinion, it is not desirable to have the asset value equal to 0. That's because great-looking influencers have an advantage over severely creators.

Method 2: Create a Market

Market is a mechanism that decides what to tokenize and what to evaluate in the Dev Protocol. Currently, the Npm Market is the first simple role model.

For this proposal, I will create a new Market that does not index any external ratings like npm downloads. Or make something like a generic "Upvote" button and treat that statistic as asset value.

Method 3: Remove the Market mechanism from the Dev Protocol

Dev Protocol will allow npm, videos, and games, etc. to all are tokenized without using Market ratings. This method is a degraded version of Method 2, but it offers a simple UX because there are no Market options.

---

Method 2 leaves the existing Npm Market in place, so you won't expect drastic changes.

I think that Method 1 or Method 3 is promising, but Method 1 can be applied to an unknown Market (will be added in the future), and the implementation is simple and safe.

However, in Method 1, it is necessary to consider the degree of influence that the asset value has on the calculation result.

In my opinion, asset value is always handled with average.

Example: (Random numbers for easy example)

• npm project A: Downloads 10000, Staking 100
• npm project B: Downloads 500, Staking 100
• npm project C: Downloads 2000, Staking 500
• npm project D: Downloads 10, Staking 800

Average downloads is (10000 + 500 + 2000 + 10) / 4 = 3127.5.

The Asset Strength the following:

• A: 3127.5 * 100 = 312,750 (6%)
• B: 3127.5 * 100 = 312,750 (6%)
• C: 3127.5 * 500 = 1,563,750 (33%)
• D: 3127.5 * 800 = 2,502,000 (53%)

In this way, the project with large staking will be more advantageous than the other. In practice, the average will change each time mining. Asset values that are greater than the previous average give slightly better results. Asset values that are less than the previous average are rated higher, but the next averages will lower.

[aggre]

It was a draft to fix the annual inflation rate to 3%, but I consult in Discord and adopt a dynamic inflation rate.

At the current staking ratio (about 2.3%), make a curve that approaches 3% per year.
While using the calculation formula up to DIP3 as it is, will change the following values.

• Max value per block and asset is 0.00012 (currently 0.00025)
• Multiply the number of assets by the value obtained by subtracting the staking rate from 1 and multiply by the above max (now, the number of assets is 100% increased by max)

In summary, the maximum reward rate is reduced by 45%. And the maximum reward rate increased linearly as the number of assets increased, but from now on, the higher the staking rate, the smaller the number of assets.

I made a simulation of this formula. https://docs.google.com/spreadsheets/d/1LTksSLaK_Q0IiZW2GHmvlTPzXVJe7fis-53X192YTtE/edit?usp=sharing

[calaber24p]

I believe the drafted fix that aggre put forth is a better fit for an inflation model than the one I put forward.

[aggre]

As an additional patch, I would like to adopt the block number of one day ago uniformly for the first mining of the asset.

Currently, the same block number (equivalent to March 4, 2020) is used all the time, rewards are too big.

[aggre]

Note: There is one problem that should be resolved soon after DIP4.

The current Policy mechanism does not recognize the Market difference in the asset value calculation. In other words, if Markets with different averages are mixed, it will cause confusion.

The asset value calculation should be modified to recognize the difference in the Market.

[aggre]

I noticed another problem earlier.

The current Policy mechanism does not allow use averages to calculate asset value. This is because a Policy cannot store the previous value. (depends on Ethereum's spec)

I think this DIP should be split and applied one by one.

First, change the reward rate. #4 (comment) can be applied at the same time.

Then, apply methods that reduce the impact of asset value (without using averaging).

[aggre]

I've been thinking about DIP. And I noticed possible that staking is concentrated on projects that high numbered if even it's number is anything.

There was also feedback individually that on-chain mining is damaging UX.

However, Method 3 may have a negative effect on taciturn developers and creators. I thought to may not have to do everything on-chain.

So... mining rewards predictions can be calculated off-chain. And, staking interest rates also predictions can be calculated off-chain.

Providing mining rewards predictions will reduce confusion. Predicting staking interest rates can be useful information for early projects. (It's best when combined with #6 )

[yumemayu]

This may be a bit off, but I'm sharing.

So far, Dev has been trying to solve the crowdfunding problem.

On crowdfunding, money goes to celebrities and not to unknown people.

For this reason, Dev has turned to activity results as a metric. It was very well supported by many developers who were not celebrities. Because developers want to focus on development, not PR to be famous. What they create is valued, not for its popularity.

This is why Dev has created a market.

There are creators who do a variety of activities, development, music, etc. We thought that multiple markets would grow and that they would be grouped by users in the future.
And I hope that I can stake on creators too.

[calaber24p]

If mining can be done off chain or done by the developers daily so users dont have to do it, that would also be amazing. I think markets can be done still I just think their impact should be less. I dont know if many people would stake on other projects if they know they are losing out on staking income.

Most people only ask where the best place to stake is so they can make money. I think taking that part out of the equation is important. If I only made 10% more staking on someone I would consider staking a smaller developer, but anything more than that I would go where the money goes. Just my opinion though.

Having big celebrities or other people wouldnt be a problem because other small developers still have a fan base. Right now they are getting 0% of the staking reward. They might get more if we lower the impact of downloads on the rewards.

Use the markets to make sure the person who is creating the property or account if we choose to do that, is legitimately doing work of value. Then let stakers vote who they want to fund.

[aggre]

I understood why you recommend Method 3. I also thought that Method 3 would produce a simple, realistic, and better UX.

Below are some additional ideas:

• A Market is still used as an authentication mechanism (prevention of spoofing)
• No more mining for staking rewards, everyone gets rewards each block
• Impose some penalty if a creator is not working

I don't have any specific ideas yet on how to the penalty, and that fact-checking method. I would like to solve it on-chain as much as possible.

Does your voting mechanism idea work for that? @calaber24p

Use the markets to make sure the person who is creating the property or account if we choose to do that, is legitimately doing work of value. Then let stakers vote who they want to fund.

[calaber24p]

Instead of implementing a penalty, I have ideas for instituting ways to promote more active users, like providing updates and incentives through the stakes.social dapp for people that stake a certain amount. This would be a suggestion in another DIP and I don't know the specifics on how to implement it. I think fact using the market to fact check is the biggest challenge method 3 would face. However I do believe that the benefits that come with method 3 drastically outweigh the negatives. I believe that if all rewards are created equal, people will stake projects they truly believe in and projects that are actually doing work.

I think if you tell people "find a cool project you would like to support, it doesnt matter where you stake, you will always get the best reward" stakers will be much more invested in the system. Giving stakers that ability gives those who might have just bought in to have the dev token appreciate, a reason to stay and see the difference they can make.

[aggre]

@calaber24p Your idea is definite and simpler. Initially, we were thinking about what we could get "some service/activity" with a certain amount of staking. We do not implement it in Stakes.social, but we think other Dapps will do it.

For example, read or post a secret blog, access a predecessor-preview, and so on.

[aggre]

I organized specs of Method 3.

Reward Mechanism

Comparative assessment of the amount of DEV staked in a Property, and multiply by the maximum reward amount and that ratio. A Market does not evaluate assets.

The only variable for reward calculation is staking, and all Properties have the same ROI.

Rewards will automatically increase with each block because no oraclization is required.

Asset Authentication

A Market still plays the role of authenticating ownership of such as OSS and contents to Property. It means a way to prevent spoofing.

Technically Changes

• Allocator.allocate, Allocator.calculatedCallback and Market.calculate is no longer needed
• A reduced version of Allocator.calculatedCallback (no need to use asset value) is called from Lockup._calculateInterestAmount and Withdraw._calculateAmount
• Other codes that are changing to related to the above

[aggre]

This proposal already activated by dev-protocol/protocol#449.