Discussing Market scheme

[aggre]

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.

[defi-er]

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

This problem is an issue of Governance voting for illogical new markets, onboarding spoof assets, or using weak qualifications to approve assets.. I don't see this as an inflation issue. This problem could be deterred with a requirement that an asset is only applicable to generate inflation for the protocol if there's more than "X" DEV staked for it.

[defi-er]

Additionally, new sectors can be incentivized with a boosted-liquidity mining program. This will help build more healthy tokenomics. However, this should be in conjunction with making sure that new sectors are approved when there's a sufficient wait-list of creators ready to onboard. In my opinion, a new sector shouldn't be approved if there's only one participant. New sectors are costly due to design, marketing, legal, development, and new hires.

[aggre]

I think Market/Sector should be managed by a completely decentralized process, but even if it's not, I don't see the need for Dev team to maintain everything. For example, developers who develop a new sector can use their own Dapps to drive the onboarding of the sector.

By the way, I have recently been considering a scheme to eliminate the DIP41 disadvantage.

[defi-er]

I think a decentralized process would look like the following:

Creator proposes a new sector to be implemented Community votes on if the new sector is approved, what markets will be part of this, what requirements will be Core team, or another technical team, (at the moment it's core) develops the integration and sector is launched after sufficient traction Community can vote to boost rewards via liquidity mining for the sector to kickstart it

In my opinion it's centralized for one entity to create a sector/market that produces inflation without the community's consensus/vote and decision on what requirements will be. Decentralization is the ability to create a sector/market, but not the ability to create it without consensus.

[aggre]

Yes, the process I have in mind is also "proposal->first vote->development->second vote->apply" or "development->vote->apply". (In the latter case, the developer pay time for development in advance, but takes the risk of rejection)

[defi-er]

Is the first vote the sector application? What's the second and third vote?

[aggre]

Is the first vote the sector application? What's the second and third vote?

The first vote is a development proposal and the second vote is the final vote with accompanying code.

I believe that all governance, not just Market/Sector, must be accompanied by code, because there is a risk that the code is not developed as proposed.

---

Apart from decentralized governance autonomy, I think it also need a "Market/Sector scheme without additional inflation rate" to minimize security holes in the protocol. For the addition of the maximum inflation rate, explicit governance is needed, not a side effect of Market/Sector governance. (This is because I think side effects are unpredictable for many voters and too challenging to function properly.)

[defi-er]

I believe that all governance, not just Market/Sector, must be accompanied by code, because there is a risk that the code is not developed as proposed.

Yes, great idea, that's true!

[aggre]

We have been discussing Market issues (including Sector) in multiple DIPs and multiple discussion spaces.

Since Market issues are a critical piece in token economics, there are many variables to consider, and the discussion is very complicated. It is also important that all major users (creators, patrons, and potential them) do not threaten each other's interests. And, they are related to the core of the protocol, so also required to consider it from the perspective of software engineering. However, I feel that we don't currently have a community base that can fully consider them.

In the meantime, the Dev Protocol development team will also focus on building DAO and transferring authority. Solving DAO and Market issues involves difficult parallelism, so it's not the best development way for me.

So I'm thinking of putting the resolution of the Market issues on hold until after building DAO. During DAO development, it involves blocking the addition of Markets and setting Policy.marketApproval to returns always false. Since this is a security issue, I don't think voting is required to block additional Markets by Policy.

Please let me know what you think.

[aggre]

I heard from the community that they wanted a more dynamic token ecosystem by Markets. Some also wanted Sectors to fragment APY.

Basically, I think that fragmentation of APY by Sector is an idea that promotes cellification of the inflation mechanism and suppresses unexpected security issues.

On the other hand, what I was thinking about as an issue was that "a new Sector has a low APY and staking does not gather." There is the concept of "boosting" to solve it, but boosting has many variations from case to case, so I thought the boosting feature would be difficult to built-in to the core. So I think boosting is necessary for Sector, but "I" think those needs to be separated as third-party roles. The protocol can support third-party boosting through governance or (for the time being) at the team's discretion.

[takem001]

I agree with the policy of moving to a DAO in the future, and the current policy of letting the governance team decide how to handle third-party boosting. The speed at which the blockchain market is evolving is very fast and I fear that by following the DevProtocol roadmap, we will miss out on a huge opportunity. For this reason, we propose to control the authority for the creation of new Sectors with a permission system for the team for the time being. Why don't we make it mandatory for third parties who want to utilize Dev in the new Sector to ask the team for permission to create the new sector?

[yumemayu]

@takem001 Thanks for the suggestion! First of all, of course we are looking for ways to create new markets. However, there is an issue of the impact of the new market on our tokenomics has been unresolved for six months. We don't discuss the need for specific market/sector or product, but rather look for ways to solve the impact on APY. If you have suggestions on this, please comment here 🙂

[aggre]

I'm considering implementing DIP41 as specified first and then updating it later. For example, boost (third-party or built-in?) and an algorithm for determining the inflation rate (contribution by burn or lockup?). So far, I have heard agree for DIP41 from various places. DIP41 has the same governance scheme that Dev Protocol currently implements. Therefore, no decision is made by the admin.

On the other hand, Dev Protocol is still developing by a limited/small team, so it's a difficult question how much work can be done in parallel with the major changes in the core modules that be involved DAO. But I understanding we should do our best.