dev-protocol/dips

📋The Dev Proposal repository

dips's Issues

Liquidity Mining

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.

Gasless transfer/stake/unstake

Many beginners don't have ETH for gas fees. That's a challenge commonly known as the barrier to entry for blockchains (especially Ethereum).

Smart contracts that support meta-transactions (ethereum/EIPs#1776) allow users to interact with the contract by simply signing them in their wallets.

DEV tokens are already deployed and have no upgradability, so creating a paired token to support meta-transactions. For example, MDEV.

• MDEV is designed to be converted with DEV on a 1:1 basis, and MDEV can achieve gasless transfers with functions like metaTransfer.
• Staking and unstaking could be made gasless by having the Lockup contract support meta-transactions.

MDEV implementations will not be built into the protocol core because meta-transactions require an off-chain server.

New lock-up blocks

Decrease lock-up blocks in temporary

Now: 175200
Proposal: 1

Dev Protocol's user-friendly Dapp is not yet complete. In the meantime, it would be hard to ask users for a long-term lock-up. Set the lock-up block to 1 so that it can be unlocked in one block (about 15 seconds).

We believe that this should revert to a long-term lock-up in the future. We believe that if it works properly, the ecosystem will be more reliable.

https://github.com/dev-protocol/protocol/blob/221b20b32e6cf9040403b37d64968452d63e419b/contracts/src/policy/DIP1.sol#L12

Creators as stakers

Currently, there are no protocol-level specifications to prevent self-staking by Property holders.

When a Property holder self-stakes his Property, the user gets a reward for his Property in addition to the staking reward, which raises the issue of double APY acquisition.

There will be a certain amount of pain in resolving this issue, because if the Property holder is switching multiple wallet addresses, then validation by address also loses its meaning.

This proposal effectively nullifies self-staking by including its staking share in Property's reward calculation.

Holders of Property obtain regular staking rewards by oneself staking. They also obtain additional rewards in accordance with the staking gathered in Property.

For example, Alice has 50% of the Property and stakes 100 DEV. In her Property, 1000 DEV in total has been staked. We postulate APY at 30%.

Alice_staking_share = 100 / 1000 = 0.1
Alice_pool_share = 0.5
Pool_total_reward = 1000 * 0.3 = 300

Alice_creator_reward = 300 * 0.1 * 0.5 = 15
Alice_staking_reward = 100 * 0.3 = 30

Alice_earn_reward = 30 + 15 = 45

If Alice uses another wallet to staking 600 DEV, the reward for Alice as a creator can calculate the following.

Alice_staking_share = 100 / 1600 = 0.0625
                             ^       ^^^^
Alice_pool_share = 0.5
Pool_total_reward = 1600 * 0.3 = 480
                     ^           ^^
Alice_creator_reward = 480 * 0.0625 * 0.5 = 15
                       ^^      ^^^^
Alice_staking_reward = 100 * 0.3 = 30

Alice_earn_reward = 30 + 15 = 45

The reward for Alice as a creator will not change. This spec disables double APY's from being earned.

Advantages

Since Property holders are also stakers and staking share of creators in the calculation of their reward are included, they cannot doubly obtain reward with multiple wallets.

Disadvantages

Creators as Property holders need to purchase DEV and have to stake themselves to earn rewards. If they don't stake themselves, the Property holders' reward is 0.

Renew the ratio of holdersShare

Changing holdersShare

Now: 95%
Propose: 51%

The ratio should be changed to prevent dumping of DEV and to enhance market entry by treating stakers loyal to the ecosystem more fairly.

failing which market will be dumped hard by the Developers every morning after rewards are given out and staker will run and compete with the developer to dump with him (quotes)
5% stakers will be loyal not dumping the market..rest 95% are in greed including OSS Developers (quotes)

Withdraw staking by one transaction

Currently, before withdraw staking, you need to create a cancellation transaction. You also need another transaction to withdraw your staking reward.

These will force you to pay for unnecessary gas fees and cause damage to UX.

As a solution, I( and @defi-er ) propose a specification that cancels staking in one transaction.

Details:

• Staking can be withdrawn after a certain lockup from the starting block. The lockup is defined by Policy. (Currently, the value is 1 block.)
• You cannot withdraw staking from the beginning of staking to the end of lockup.
• After the lockup has expired, you can withdraw staking by sending a staking withdrawal transaction. (There is no automatic withdraw of staking)
• You can withdraw staking rewards while staking.
• When you withdraw staking, you also withdraw a staking reward at the same time.
• The last staking extends the lockup.

Regarding the specifications that the lockup is extended from the last staking, there is a trade-off with the gas fees. When the withdrawable staking amount varies according to the elapsed block, more state variables are required, so higher gas fees are required. It ruins UX and introduces unnecessary complexity.

---

The reason we've ever needed a cancellation transaction is related to the staking lockup. Since it is difficult to consider the lockup period when staking, we have developed a specification that can be withdrawn after the lockup from the application to withdraw staking. However, we have found that UX can be significantly improved by merely simplifying the specifications. Therefore I propose this DIP.

Referral Rewards

Referral rewards could greatly increase the amount of creators moving to the platform by offering an incentive to dev users. Under this proposal 1%-5% of the rewards from onboarded creators through the referral system, will be rewarded to the users who bring them to the platform.

Users can use their Eth addresses as a form of identification when referring new creators to the platform. Once a project that the user refers is deemed to be legitimate and is brought online, they will earn a percentage of their earnings for a fixed period of time. Initially a believe a three month period would be a good number.

The amount they are rewarded scales with the amount staked on the property, so bringing bigger creators to the platform will offer larger rewards for those looking to refer them. One of the larger problems we are facing right now is bringing new users to the platform and I believe that this system could make this process much easier and save us a large amount of time.

Ultimately we still have the final approval on whether or not the project is legitimate and should be approved through the manual review system. The only downside I can see is the possibility of referral disputes from users who might bring a creator to the platform but that creator doesn't state the user brought them there.

Reward split by Property

Problem

Property owners have the motivation to compete with other properties to launch projects early. For that reason, they would like to present advantageous conditions, but now, all properties' reward rates governed by one Policy.

Solution

Instead of a 51% developer, 49% staker split, developers can set their own splits and create a staking market. This allows the market to decide the split.

---

This DIP was drafted by @calaber24p

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency prettier to v3

Detected dependencies

github-actions

.github/workflows/nodejs.yml

• actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
• actions/setup-node v4

npm

package.json

• husky 9.1.6
• prettier 2.8.8

---

• Check this box to trigger a request for Renovate to run again on this repository

Property Grouping

This proposal is a new implementation proposal of DIP5 (#5) for efficient handling of multiple Properties.

"Property Grouping" feature allows creators to combine multiple properties they have tokenized into one or more groups. This behavior is similar to the relationship between "folders" and "files" in a file system.

Directory Tokens

An ERC20 contract creating to group multiple Property Tokens (a.k.a. Creator Tokens). The total supply is fixed at 10,000,000. There are no restrictions on the transfer destination.

Directory Tokens holders can earn creator rewards for all grouped Property Tokens.

Once Directory Tokens are generated, no one can self-destruct them.

Technical requirements

I propose the main technical requirements and interfaces for Directory Tokens as follows.

Also, Directory Tokens should be implemented as an upgradeable contract. I think it is desirable to implement it as an external contract rather than incorporating it into the Dev Protocol core. However, Dev Kit and GraphQL should support Property Grouping.

Association

Creators can associate up to 9 Property Tokens with Directory Tokens (this limit works to keep low gas fees). The operation is required the Directory holder and the Property holder to be the same.

The association between Directory Tokens and Property Tokens is done by sending Property Tokens to Directory Tokens (Contract).

The interface is:

function associate(address _property, uint _amount) external;

Disassociation

Note: This feature should not be implemented initially. It should be implemented after sufficient security verification.

Transfer the Creator Tokens deposited in a Directory Token to another address. This operation requires agreement by all Directory Tokens holders. This is because disassociation means a reduction in rewards for Directory Tokens holders.

The interface is:

function disassociate(address _recipient, address _property, uint _amount) external;

Reward withdrawal

Withdraw rewards for associated Property Tokens. With the total reward amount of all associated Property Tokens as the maximum value, the reward is withdrawn according to the share ratio of Directory Tokens held by the account.

Calling Withdraw.withdraw each grouped Properties means running ERC20.mint and Lockup.update each grouped Properties, which means higher gas fees. Should add the bulkWithdraw function to the Withdraw contract.

The interface is:

function withdraw(address _directory) external;

Transfer Hook

A hook that updates the withdrawable rewards for the source and destination when transferring Directory Tokens. Withdraw.beforeBalanceChange is the reference model.

The interface is:

function beforeBalanceChange(address _directory, address _from, address _to) external;

DIP templating

Format all proposals into a static file with Markdown.

Ideas posted on GitHub Issues should be moved to GitHub Discussion from now.

Fixed token and Bonds token

This proposal is designed to enhance the value of DEV further.

This proposal involves significant change. Therefore, it is helpful to get as much feedback as possible.

By this proposal, the issue that comes with APY going up (too much) turns into an increase in "bonds," not decrease value.

New structure of tokens

Symbol	Spec	Description
DEV	ERC20	Tokens with issuance cap. (The cap is the current total supply.)
pDEV	ERC20	Tokens pegged by 1:1 with DEV. By staking to a Property, it is also newly issued as a reward.
bDEV	ERC20	Bond tokens that are minted in the situation where pooled DEV is insufficient to pDEV. It also becomes a right to receive "pooled DEV for converting to pDEV."

Summary

The fundamental of the idea is to set a cap on DEV and stagger by bonds the timing of receipt of rewards. The increase in staking will reduce the number of bonds, keeping the tokenomics more healthy.

• The total supply of DEV does not increase any more than it does now and has a cap.
• Use pDEV (pegged to the DEV) for staking.
• Rewards increase the total supply of pDEV, but the DEV is not increased. Therefore, the pDEV to DEV conversion may be oversubscribed. When oversubscribed, the pDEV is converted to bDEV instead of DEV.
• bDEV can be preferentially converted to "pooled DEV for converting to pDEV."

Major lifecycle of tokens

1. By converting DEV or bDEV to pDEV, you obtain the same amount(1:1) of pDEV.
2. By staking pDEV to one or another Property, stakers get new pDEV block by block. pDEV works the same way as the current DEV.
3. When you convert pDEV with DEV in the situation where the total amount of deposits of DEV is insufficient, the bDEV token is converted instead of DEV.
4. bDEV can be preferentially swapped to "pooled DEV for converting to pDEV." bDEV takes effect by sending an exercise transaction to the Claim contract. That transaction brings a chronological priority to bonds.

Advantages

Since DEV is a fixed token, it is the most valuable in three tokens and surpasses the current value of DEV. pDEV and bDEV are rights that enable you to exchange with DEV, and their values are included in DEV.

Motivations for investors

• Investors' purpose is to obtain the most valuable DEV as much as possible.
• By staking after exchanging DEV with pDEV, investors can increase the amount of DEV that they hold.

Major risks

• When the amount of DEV that is used for converting from pDEV is more than that of DEV that is deposited, its immediacy is lost because it gets bDEV instead of DEV. *However, bDEV becomes a right to receive future DEV.
• In situations where there are too many bDEV (bond), more people may be hesitant to convert DEV to pDEV, reducing the staking rate. A proper APY is required to avoid that situation.

FAQ

Why bother staking with pDEV instead of DEV?

When a user converts DEV to pDEV, the DEV is deposited to the Converter contract. DEV deposited in the Converter contract is used when someone converts pDEV to DEV.

If you get pDEV by staking "DEV instead of pDEV," then your staked DEV may be consumed when someone else does pDEV to DEV conversion. This is a bad scenario, but when users have a significant amount of pDEV gained from staking rewards, and pDEV to DEV conversion is oversubscribed, deposited DEV could be reduced to zero. Staking will continue in such situations. In this situation, oddly, the amount of staking is zero while staking the DEV.

Staking by pDEV instead of DEV addresses that situation.

Stake as an Index

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

DIP #11- Stakes.Social UI/UX

I would like to propose UI/UX upgrades for Stakes.social.

The Graph Dashboard

The Dev Protocol team should look into thegraph.com. UniSwap uses the Graph for their dashboard, picture below.

The dashboard should show the following parameters:

1. DEV Staked
2. % of Supply Staked
3. Total Rewards Minted
4. Pools available
5. APY (Unless DIP #6 is adopted)
6. Rewards generated for Creators

Categories and Trending
This will give users more ways to find different properties

Property and Creator Description
Each Property should have a description, link to npmjs or Github, and info on creator(s) (optional). This will give users more info to make an educated decision on where to stake their tokens.

ENS Implementation
Allow assets on Dev Protocol to be registered with an ENS address rather than a HEX address. This will improve UI/UX and security.

Quadratic Voting: Burning DEV

Proposal

Allow voters in Dev Protocol's Quadratic voting process to buy additional votes by sending DEV to a smart contract which then returns votes and burns received DEV.

Overview

Dev Protocol currently uses Quadratic voting for governance. Under Quadratic voting individuals buy votes for their preferred alternative, paying the square of the number of votes purchased. Quadratic cost uniquely makes the marginal cost proportional to votes purchased, encouraging voting proportional to the value and thus maximizing welfare.

Incentives

1. Large DEV holders will burn DEV to receive additional votes which should encourage them to maximize the protocol's value in order to receive a return on investment of their burned DEV. This will diminish attacks through governance.

2. Dev Protocol creates another token sink which reduces the effects of inflation.

Technical Implementation

Escrow contract that holds non-transferrable voting rights. Users transfer DEV to receive voting rights. Escrow then burns DEV received. Interface shows user how many additional votes they'll receive for DEV sent.

Discussing Market scheme

Anyone who wants to participate in the following DIP discussions is encouraged to read this issue first.

• #41
• #46

Multiple DIPs are surrounding the Market scheme, and determining them early helps reduce protocol uncertainty. Now I would like to wrap up multiple DIPs and sort out the issues.

Current specifications

Market is a mechanism for authenticating assets (such as GitHub repositories). The Dev Protocol increases the inflation rate as the number of assets increases. Its inflation rate decreases with more staking.

Developers can propose a market. The proposed Market will be activated by being passed through on-chain governance.

Problems

1. "Inflation Rate Explosion": If a Market has a mechanism to increase assets very easily (for example, authenticate tweets as assets), an inflation rate explosion can occur. (If that happens, users can lower the inflation rate by proposing a new Policy.)
2. "Inflation Rate Conflict": The inflation rate is shared even if there are two completely different Markets. Increasing staking for one market will reduce the inflation rate for the other market.

DIPs

DIP41

Resolves "inflation rate conflict."

Markets are categorized by groups called "sectors," and inflation rates are encapsulated by sector. Encapsulated inflation is called "native APY."

However, sectors with low assets have low inflation rates, which raises the question of economic rationality for staking for new sectors.

See the comment that organizes the advantages and disadvantages.

DIP46

Resolves "inflation rate explosion."

Fix the inflation rate cap and change it so that the number of assets does not affect the inflation rate.

Assuming a constant number of stakings, the inflation rate will not increase. Therefore, if the inflation rate is clearly at a value that should be corrected, users should use Policy Governance to correct it.

DIP46 conflicts with DIP41. This is because the rate must be a singleton to prevent an "inflation rate explosion." Therefore, DIP41 and DIP46 have an exclusive relationship with each other.

Below is an idea that hasn't become DIP yet.

Plan-C

Purchasing inflation rate. (Can be combined with DIP41)

The concept is to increase the inflation rate by burning DEV if users decide that the authenticated assets have a higher value.

Combined with DIP41, both "inflation rate explosion" and "inflation rate competition" can be resolved.

---

I welcome you to understand the problem and suggest better ideas.

DIP #12- Interest Bearing Tokens

Dev Protocol should develop interest baring tokens. Interest bearing tokens (aTokens for short) are minted when you stake and burned when redeemed. The aTokens are pegged 1:1 to the value of the underlying Dev tokens that are staked in the Dev protocol. aTokens can be freely stored, transferred, and traded. While the underlying asset is staked in a property pool, aTokens accrue interest in real time, directly in your wallet!

A user’s balance of aTokens increases as interest is generated according to the current rate. This interest rate changes algorithmically, depending on the amount of funds being staked to the pool, as well as the APY.

These tokens can then be sent to Uniswap, Kyber, and other trading platforms to exchange and trade. This would incentivize users to keep their underlying stakes while using the interest bearing tokens to find other opportunities in or outside of Dev Protocol. This would mitigate users dumping without forcing them to lockup tokens which will only delay not prevent dumping.

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Incubator

Dev Protocol: Incubator

Incubator definition:

An enclosed apparatus providing a controlled environment for the care and protection of premature or unusually small babies.

Dev Protocol should onboard projects ourselves that are valuable from a technical and marketing aspect. Dev Protocol will then stake DEV tokens which will be an exclusive feature for the team. Emails will be sent to the incubated team on progress of incubation to encourage them to authenticate. When the team authenticates they can then withdraw rewards. Dev Protocol will burn team rewards to offset DEV generated in incubation state. This will increase the value proposition for teams to join and authenticate.

1. Incubation follows the current market APY

2. Incubation doesn't increase minting per block

3. Incubation staking, by DEV team, doesn't affect APY

4. Creator reward must equal staking reward
   4.1 If creator rewards equal staking rewards, and creator rewards are burned, then APY should remain intact.

General Technical Implementation

1. Whitelisted pool only for team's wallet address
2. "Oracle" that fetches current market APY to calculate rewards
3. Burn stakers rewards upon withdrawal
4. Incubator follows traditional specs upon authentication

Rewards-withdrawal locking up

Currently, staking and holder rewards can be withdrawn at any time. There should be a lock-up to prevent the dumping of DEV.

In my opinion, there should be a 21-day lock-up for staking rewards and a 14-day lock-up for holder rewards.

I would prefer these to be set dynamically by Policy, not fixed.

the Property owner will turn the biggest enemy with greed.Also I have a suggestion on rewards...Rewards by Stakers should not be withdrawn before 21 days and Property owners before 14 days (quotes)
The staker should be allowed to re-stake his tokens if he unlocks immediately.That should be allowed in my opinion as he is trusting the project more and is being loyal (quotes)

Options of the logic

I think there are a few options for the lock-up. I don't have an idea of which option is appropriate. Please give me your opinion.

1. Withdrawal application - Always send an apply transaction before withdrawing rewards. Once applied for, it will be ready to be withdrawn after a lock-up (21 or 14 days). This is simple, easy to develop, and robust logic.
2. Expiration of a period - Rewards distributed, it will be available for withdrawal at any time after the lock-up expires. This is a somewhat involved logic that needs to be well thought out, given the changes in the various balances.

An OSS ETF

Open source software is eating the world. Dev Protocol offers a streamlined service for Github's OSS projects to receive sustainable funding. If Dev Protocol could capture a percentage of each creator token created using Dev Protocol then it would become a backdoor ETF for OSS. DEV holders would receive creator staking rewards + governance power. This would become extremely lucrative for enterprises with dependencies on OSS to vote on the direction of OSS projects. Dev Protocol DAO would hold creator tokens and give voting power proportional to DEV held. This creates a new sink for DEV. The world's first ETF for OSS.

Market owner can de-authenticate specific properties.

References

不正なクリエイターの上場廃止機能(Ability to delist rogue creators.)

Sentence Summary

This problem solves the problem of not being able to unauthenticate with the market except for the property author.

Paragraph Summary

This DIP proposes a feature that allows the market owner to freely deauthenticate the property.

Component Summary

Modify the onlyLinkedPropertyAuthor modifier.
Currently, an error occurs unless the sender is an author of the property.
This will be changed so that the error will not occur if the "sender is the author of the property or the owner of the market".

Motivation

There have been cases where development repositories have been deleted or made private. We provide this feature to deal with this.

Specification

Proposed Code

I'll implement it now.

Test Cases

・Only the market owner and the property's author have the authority to execute the market deauthentication function.
・Check that the following conditions are met for the deauthenticated property.
　・Staking cannot be performed.
　・Staking can be canceled.
　・Creator reward and staking reward cannot be obtained.

Security Considerations

Make sure that only the owner and the author of the property to be deauthorized are authorized to execute the Market deauthorization function.
(Author-based deauthentication has already been implemented.)

Copyright

Copyright and related rights waived via CC0.

Standard Token Supply

Proposal
I propose Dev Protocol to allow OSS projects to mint a standard 10,000,000 tokens.

Why
This will help fix potential fragmentation and information asymetry. A standard supply will benefit Dev Protocol's ecosystem participants, especially when it comes to voting power, incentives, and ownership.

Reduce Rewards for Unauthenticated Property

Anyone can create a Property, now. But, is it suitable for people who are not creators or developers, etc. to create properties, stake on it, and receive 100% of the reward?

But, specifications that require oracle on mining will damage UX.

Solution

I propose to reduce the total reward for a Property that has not been authenticated.

Reduces the total reward (holders + stakers) for a Property that is not authenticated for any Market. I think that the reduction percentage should be the same as the holder reward share. In the current Policy, holder reward share is 51%; therefore, the total reward of unauthenticated Property will be reduced by 51%. Its percentage depends on effective Policy at this time.

Although I thought an idea to increase/decrease depending on the number of authenticated assets, it is not always good for creators to have a large number of assets. So it should change the total reward depending on whether a Property is authenticated or not.

However, this proposal also rejects participating in areas where creating a Market is difficult. Please comment if you have any other ideas.

Increase Creator Fee for Incubator Projects to 7.50%

I am proposing to increase the Incubator Creator Fee to 7.50%, sent to the treasury, for Round 2 and all rounds after. The Incubator allows projects to earn up front rewards for joining the network. The additional 2.5% would help the treasury offset the inflation generated by the Incubator.

Creators, Governance Tokens

What's a governance token?
Governance tokens confer holders the power to influence decisions concerning the core protocol, product or feature roadmap, hiring and staffing, and changes to governance parameters.

Creator tokens should incorporate governance functionalities for three primary reasons:

1. Extra regulatory compliance
2. The tokens can govern the OSS project's features, roadmaps, and staff. This creates added incentives for enterprises and others to buy and hold creator tokens that they currently have dependencies on or will rely on in the future.
3. Creates and sustains demand for staking DEV.

How can we achieve this?

1. Create whitelisted tools for creators to provide governance functionalities to their holders.
2. Create a governance management dapp.

FRAME00:
Offering Governance-as-a-service to creators and enterprises for a monthly fee could become a business model to sustain FRAME00.

Decrease Inflation Rate

This proposal sets out the specification for the inflation rate in DIP4.

The basic policy inherits the following information from DIP4.

• The new reward logic: #4 (comment)
• The first mining point of an asset: #4 (comment)

OSS Token Distribution (Patrons)

In the future OSS tokens may achieve utility outside Dev Protocol like Governance or utility. An excellent way to reward Patrons for supporting projects, when OSS tokens receive exterior use cases, would be to give a fixed percent for Patrons. If treasury holds 5% then 2.5% would be given to Patrons that supported that project.

Distribution Method
Tokens would be distributed based on the same logic as the Geyser liquidity program: the amount of capital and the time staked relative to other Patrons in the pool. The more money and time a Patron provides to a project the more of the allocation they receive.

Benefits

1. Patrons join to fund projects they believe in
2. Patrons are incentivized to fund projects that will make use of OSS tokens which creates organic incentive model
3. Projects not creating use cases or developing are less staked due to the opportunity cost
4. This DIP injects immense positive feedback loops without changing the core protocol

Future Questions

1. How to automate the Merkle distribution without using snapshots each time
2. Vesting periods

Foundations

Dev Protocol Foundations

Concept and Reasoning
Dev Protocol will allow users to build funding sets that their community can follow and stake in. This will allow easier user experiences for users that don't have enough time or knowledge to choose which projects to fund. Dev Protocol has a universal APY to encourage users to fund projects they care about. Foundations introduce an additional incentive model that creates an implicit return. How? Let's consider the "Chainlink Foundation". Chainlink Foundation will provide funding to those that support their ecosystem, therefore Chainlink's community has an incentive and implicit additional return to join the Chainlink Foundation's set. This is because those OSS project receiving funding from the Chainlink Foundation should improve the Chainlink ecosystem, and therefore increase the value of LINK.

Examples: Chainlink Foundation, Vitalik Buterin Foundation, Ethereum Foundation

Commit Farming

Build capabilities for creators to allocate a percentage of creator tokens to reward maintainers who have commits in master. This will add an incentive model for maintainers to keep developing OSS projects, receive a portion of creator yield, and have voting power in governance models.

Organized Properties

Problem

In the Dev Protocol, many projects exist as Properties. However, there are so many of them that it can be challenging to choose a project.

Solution

Rather than staking on a project directly, you stake on a creator which has all of his projects within their profile. This makes choosing staking easier for stakers and vastly lowers the amount of projects a staker has to look for.

---

This DIP was drafted by @calaber24p

Sponsor Program

Author: Scott G
Email: [email protected]
Type: Enhancement
Status:
Date Proposed: 2021-01-01
Date Ratified:
Dependencies:
Replaces:

Sentence Summary
Allow users to lock DEV tokens via staking for OSS projects not yet onboarded. If OSS projects onboard then users and projects get boosted rewards.

Summary
The Sponsor Program allows Dev Protocol users to lock up their DEV for 60-90 days by staking for OSS projects not yet onboarded. Sponsors’ rewards begin to accumulate as soon as they stake, but are locked until the OSS project tokenizes. If the OSS project doesn’t onboard then rewards are burned and users receive their DEV back.

Component Summary

1. Escrow- Users deposit (stake) DEV in the pool which is locked until 60-90 days or the OSS project authenticates. Allocated DEV is also held in escrow.
2. Boosted Rewards' APY Calculation-Geyser logic based on DEV allocated to Sponsor Program which rewards users based on time and liquidity provided

Motivation
The motivation behind this proposal is to allow the Dev Protocol community to onboard projects they're passionate about, show OSS projects that they have patrons on Dev Protocol, and reward all participants for working together.

Preliminary Considerations

The following questions were considered before drawing my proposal:

1. On-chain or off-chain rewards or a mix? (DEV Inflation + Boosted Rewards or Boosted Rewards)
2. How are Boosted Rewards determined? (Github metrics or Manually determined)
3. How are Boosted Rewards APY determined? (Geyser)
4. How are Sponsored Projects determined? (Community vote or Database of pre-chosen projects)
5. Sponsored Program format? (New round of projects every X days or users can Sponsor a Project of their choice at any time)
6. How long should a Sponsored Program run? (30, 60, 90, 120 days)
7. How is Dev Protocol APY affected? (APY is lowered if users stake in Sponsor Program)
8. Do Sponsor Program's increase APY? (Not until they're authenticated)
9. What is the Sponsor Program's APY formula for inflationary DEV rewards?

Specification Proposal

Inflationary Rewards + Boosted Rewards (Geyser)

1. Community vote every 90 days to add 5 projects to Sponsor Program
2. Team decides Boosted Reward allocation for each project
3. Users stake DEV in the Escrow which holds the rewards
4. Inflationary + Boosted Rewards begin to accumulate
5. Geyser's logic is used to distribute Boosted Rewards based on time and liquidity provided
6. If an OSS project authenticates then rewards are unlocked. If project doesn't authenticate by X days then allocated DEV for Boosted Rewards are kept in escrow, and inflationary rewards are burned.

Questions Remaining

1. How to determine Boosted Reward (DEV allocation) for each Sponsored OSS?
   a) Chosen by team
   b) Set upper and lower bounds for DEV allocation which is determined by Github metrics

2. How are Sponsor Program projects chosen?
   a) Users can choose to Sponsor at anytime
   b) In Rounds every 60-90 days where 5 projects are chosen by a Community vote

3. What is the Sponsor Program's APY formula for inflationary DEV rewards?
   a) Dev Protocol's inflation APY needs to be revised to account for Sponsor Program and Incubator

Copyright and related rights waived via CC0.

Identity Validation

This proposal conflicts with DIP #20 and should be compared and considered. The purpose of this proposal, as well as DIP #20, is to prevent self-staking. However, a softer approach is used to solve the problem.

I believe that these exclusive proposals should not be implemented in the first place. But if the problem is going to be too bloated, then we need to be considered for a healthful tokenomics.

The basic concept is to require a simple KYC for staking users and creators. (Conducted KYC can potentially be available for claiming identity for EIP 1812.)

The method of KYC uses a method that can identify a single identity with a high probability, like SMS authentication. Khaos is available for that KYC. With Khaos, personal information such as phone numbers can be authenticated while remaining confidential. Therefore, anonymity can be guaranteed.

The target users for requesting KYC is as follows:

• Property's shareholders
• Staking users

If a shareholder of a Property is attempting to stake on the Property, the KYC will verify that they are a different person. If they are the same person, the staking should be rejected.

Advantages

With SMS authentication, it can prevent self-staking at a high rate. Unlike DIP #20, creators will still receive the benefits of the same support as before.

Disadvantages

User experiences that require KYC, such as SMS authentication, are rare for on-chain protocols. Therefore, a friendly interface and an explanation of the need for it should be necessary.

Stake as Voting Rights

Votes are currently required to approve a Policy and a Market.

The voting right is given to each Property. A Property creator has voting rights according to the staking number of a Property and the accumulated reward amount. A staker has voting rights according to the number of stakes to a Property.

Abstaining from voting will result in Property authors in a penalty. This penalty will be enforced according to the number of abstentions set by the Policy.

However, users with a large number of Properties may not be able to exercise the voting rights of all Properties. This means that abstaining penalties are inevitable. Also, one person's opinion should be consistent, and it doesn't make sense to vote on a per Property basis.

I think this is a governance flaw.

Solution

Change the number of votes to the number of staking per user.

And abolish the abstention penalty. If voting rights are transferred from a Property to a person, the penalty target should also are transferred from a Property to a person, which means that the number of penalty targets will increase rapidly. It will also increase the number of users who do not want to stake because they hate the penalty risk. Voting should be done by individuals who wish to improve the protocol, not by those who dislike the penalties.

Memo: Rescue Function

This issue is a draft DIP memo and will be used to create a DIP later, although it is not accompanied by sufficient information.

• https://discord.com/channels/547215761341546497/722710414240251984/815443284884324393
• https://twitter.com/eleon66/status/1365749611223277572

DIP #14- Spoof Assets

What is a spoof asset?
A spoof asset is an authenticated asset that has no intrinsic value and is meant to deceive the community and protocol in order to generate rewards. For example, currently, a "creator" could generate npmjs repos with one line of code and become an authenticated asset on Stakes Social.

Why are spoof assets bad?

• Create artificial minting
• Take away from other creators

Potential solution for spoof assets?
A potential solution to mitigate spoof assets is to implement Kleros Curate. Kleros Curate uses the Kleros protocol to organize information. Other uses cases for this product are exchange listings, fake news, or marketplace products. For more information on how it works click here --->: Kleros Curate blog post. Verified assets/creators will receive a badge once Kleros' network of jurors approve the submission.

Potential Issues?

1. Kleros requires submitters to deposit ETH for the submission. If they are accepted then they will get the ETH back. If they lose then the ETH is used as a fee to pay for the jurors. If creators apply then this decreases the UX experience and creates more gas prices. If the Dev Protocol paid for the ETH then this could open an attack vector to drain company finances.

2. Submitters will have to interact with the Kleros protocol to submit evidence

3. All assets must get approved in Curate before being listed on Dev Protocol which will increase the time to launch for creators.

Unpopular Solution?
Admin keys.

[Terms] Abusive in Staking System

What would you like to share?

In behalf of our community 💞

Please allow to remove or suspend the project that was onboarded in stakes.social if the following project didn't give any updates to the community in about 3 months and if ever the reward was used in other things that may not help their project or future projects. This means they cannot continue any project anymore and forget the community. Since our culture is loving the creator economy, I believe we can also protect the good in creator economy and remove the fake one. I am not going to mention projects here since there's no decision as of now but I'll be messaging it privately and mention them.

• I'm hoping that we can lessen the stress of the community and continue the dev ecosystem growth.
• Attract more folks that we have better system that keeps improving

-
Last time, I also supports the discussion on suspending the project by voting (supported by the community). We can have criteria for this for fair fight. Maybe we can find new way or maybe we can continue this? Any ideas?

Additional information

Thank you for giving me the opportunity to open this.

Love by Vinci ❤️‍🔥

Code of Conduct

• I agree to follow this project's Code of Conduct

New Markets & Native APYs

dip: <#40>
title: <New Markets & Native APYs>
status: WIP
author: Scott G

created: 2021-01-05

Simple Summary

This proposal calls for New Markets (example: Research) to have their own native APY based on DEV staked and assets onboarded.

Abstract

Currently, if a New Market is added to Dev Protocol the assets are lumped together. For a Market's creators this is detrimental because the work of one sector is not equivalent to the work of another. For example, a Youtube content creator vs. an OSS developer. Each Market should have its own Native APY to provide so that the APY places a value on the Market's creator's work. This proposal also prevents the devaluation of work from different Markets, increases Market health, and creates Market APY arbitrage opportunity.

Motivation

This proposal also prevents the devaluation of work from different Markets, increases Market health, and creates Market APY arbitrage opportunity.

Specification

Overview

The feature will be implemented by creating a fork of the Dev Protocol for each New Market.

Copyright

Copyright and related rights waived via CC0.