Before DIP4, APY per Market was enabled. This proposal is similar to that specification.

Before DIP4, metrics were used as the variable to determine the APY, so the APY varied depending on the number of assets authenticated on the Market. This was due to the need to calculate the ratio of a single metric to the total number of metrics. However, I am now not a fan of dynamic APY by metrics because it caused a heavy concentration of staking. This DIP proposes that the APY should only vary with the "number of assets authenticated," and I agree with that idea.

This DIP also proposes Market development using "forks," but I'll propose development using new operator or built into Dev Protocol.

Development with a fork or new operator poses the following risks:

• Fragmentation of the network
• Leaving bugs for each Market
• The total value cannot be obtained (Total staked, total assets, etc.)

I understand that this DIP's goal is to have variable APY for each Market, so I think it is better to discuss how to implement this in a later phase.

This DIP also proposes Market development using "forks," but I'll propose development using new operator or built into Dev Protocol.

Development with a fork or new operator poses the following risks:

• Fragmentation of the network
• Leaving bugs for each Market
• The total value cannot be obtained (Total staked, total assets, etc.)

I understand that this DIP's goal is to have variable APY for each Market, so I think it is better to discuss how to implement this in a later phase.

Thank you for the technical upgrade. I wasn't aware of this technical capability and agree that this is the correct way to move forward!

@defi-er Please share your ideas for the following questions.

• Will the new Market's APY, be added to the current global APY? Or will it only change the distribution without changing the global APY?
• If the new Market's APY is added to the global APY, is it determined based on an algorithm, or is it determined artificially?
• Do you consider a Market with fewer assets to have a low APY? Or high?

• Will the new Market's APY, be added to the current global APY? Or will it only change the distribution without changing the global APY?
  No, it will be it's own APY that is determined by the assets onboarded for that market and DEV staked.

• If the new Market's APY is added to the global APY, is it determined based on an algorithm, or is it determined artificially?
  Not added to global APY.

• Do you consider a Market with fewer assets to have a low APY? Or high?

This depends on the number of DEV staked and assets onboarded. If we use current .00012 DEV per block (second) and there's one one asset onboarded to the new market then there would be low inflation.

Calculation
Current Inflation rate= .00012 DEV per second
Seconds in a year= 31,536,000
Assets onboard to new market= 1
DEV minted per year= 3,784.22 DEV
DEV for creator= 1,892 DEV
DEV for stakers= 1,892 DEV

Assume 10,000 DEV is staked in new market
Staker APY= 18%
Creator APY= 19%

So, can your idea be rephrased as follows?

Prerequisite

CalculateMaxRewardPerBlock = This function returns the current Policy's result

Proposed

Sushi Market

• Total assets = 100
• Total staked = 10000
• Reward = CalculateMaxRewardPerBlock(100, 10000) * blocks

Ramen Market

• Total assets = 20
• Total staked = 100
• Reward = CalculateMaxRewardPerBlock(20, 100) * blocks

Current

Sushi Market

• Total assets = 100
• Total staked = 10000

Ramen Market

• Total assets = 20
• Total staked = 100

Global reward

• Reward = CalculateMaxRewardPerBlock(100 + 20, 10000 + 100) * blocks

Currently, the APY is calculated based on the sum of the Sushi Market and the Ramen Market. Under the proposal, the APYs of Sushi Market and Ramen Market will be calculated separately.

// By the way, since Market and Property are a many-to-many relationship, two Markets with different APYs may be associated with single Property. I need to consider out a formula for that case.
// In this respect, fragmentation with fork or new operator simplifies the formula, since it eliminates the possibility that markets with different APYs are associated with a single Property. (However, I think this is too exaggerated and inappropriate as a solution to the problem)

So, can your idea be rephrased as follows?

Prerequisite

CalculateMaxRewardPerBlock = This function returns the current Policy's result

Proposed

Sushi Market

• Total assets = 100
• Total staked = 10000
• Reward = CalculateMaxRewardPerBlock(100, 10000) * blocks

Ramen Market

• Total assets = 20
• Total staked = 100
• Reward = CalculateMaxRewardPerBlock(20, 100) * blocks

Current

Sushi Market

• Total assets = 100
• Total staked = 10000

Ramen Market

• Total assets = 20
• Total staked = 100

Global reward

• Reward = CalculateMaxRewardPerBlock(100 + 20, 10000 + 100) * blocks

Currently, the APY is calculated based on the sum of the Sushi Market and the Ramen Market. Under the proposal, the APYs of Sushi Market and Ramen Market will be calculated separately.

// By the way, since Market and Property are a many-to-many relationship, two Markets with different APYs may be associated with single Property. I need to consider out a formula for that case. // In this respect, fragmentation with fork or new operator simplifies the formula, since it eliminates the possibility that markets with different APYs are associated with a single Property. (However, I think this is too exaggerated and inappropriate as a solution to the problem)

Yes, exactly

I've brought this discussion about yield competition over here.
#40 (comment)

There are two ways of competitive yields.

1. Each market has native APY (DIP New Markets & Native APYs #40 )
2. Creators set the reward rate (DIP Reward split by Property #6 )

In case of 1, we need the fair way to determine the native APY since the protocol doesn't determine the market value.
In case of 2, if a creator thinks their work is more valuable than others, they can set their own rates.

However, we should keep in mind that 90% of the staking was concentrated in the most rewarding property before DIP4.

In case of 1, we need the fair way to determine the native APY since the protocol doesn't determine the market value.

The APY is determined by the inflation rate and DEV staked therefore the community determines the APY through economic market dynamics.

The following numbers are an APY calculated by the current Policy Contract. I think this helps to understand the dynamics with different APYs. (These APY are the sum of stakers + creators)

Pattern 1

• Total assets = 100
• Total staked = 10000
• APY = 250.73%

Pattern 2

• Total assets = 200
• Total staked = 10000
• APY = 501.47%

As you can see from the results, the higher the number of assets, the higher the APY.

Pattern 2'

• Total assets = 200
• Total staked = 30000
• APY = 165.07%

If staking concentrates on Pattern 2, the resulting APY will be lower.

Thank you for simulating the data. I approve of this model for new markets. I do believe that there's more pressing features and Dapps to build in OSS before we proceed to new markets. But it's good to finalize this. Please let me know how we proceed with a community vote for this.

Please let me know how we proceed with a community vote for this.

@defi-er In my opinion, these technical concerns need to be addressed before we can move on to the next step. This is because depending on how we resolve these issues, it will greatly affect how this DIP works. I am looking into solutions.

#41 (comment)
// By the way, since Market and Property are a many-to-many relationship, two Markets with different APYs may be associated with single Property. I need to consider out a formula for that case.
// In this respect, fragmentation with fork or new operator simplifies the formula, since it eliminates the possibility that markets with different APYs are associated with a single Property. (However, I think this is too exaggerated and inappropriate as a solution to the problem)

#41 (comment)
// By the way, since Market and Property are a many-to-many relationship, two Markets with different APYs may be associated with single Property. I need to consider out a formula for that case. // In this respect, fragmentation with fork or new operator simplifies the formula, since it eliminates the possibility that markets with different APYs are associated with a single Property. (However, I think this is too exaggerated and inappropriate as a solution to the problem)

When a user creates an asset they choose which market their asset will be associated with.

For example:
Choose Github, Twitch, Twitter, Youtube, Research Gate

Different platforms of the same sector (Example Github, npmjs, Gitlab) will be listed under OSS market

I don't have an alternative yet, but I don't think the concept of sectors will work for the following reasons.

• Market developers have a strong incentive to associate Markets with existing sectors because new sectors will always have the smallest APY. As sectors become more decentralized and defined, they will naturally concentrate on one huge sector.
• Even if the specification is that Market developers can only associate markets with sectors they have defined, they can ask existing sector developers to do so. Existing sector developers have an incentive to associating with new markets.

Therefore, individual markets, not sectors, should have an impact on APY. (If so, the existing npm Market may need to be migrated to GitHub Market)

Another thing I am considering is how to handle the phenomenon that the inflation rate increases in proportion to the number of markets when creating an APY for each market. If the Sushi Market and the Ramen Market have the same level of statistics, the inflation rate will be twice as high. (ref: #41 (comment))

Let me add the definitions I've been using to define the following terms so that the community can follow along with this discucssion.

Definitions
Market= Platform (Youtube, Twitter, Github, Gitlab, Radicle, Twitch, ResearchGate)
Sector= Industry (OSS, Content, Social Media, Research)

• Market developers have a strong incentive to associate Markets with existing sectors because new sectors will always have the smallest APY. As sectors become more decentralized and defined, they will naturally concentrate on one huge sector.

New markets should be voted on via governance. The association of markets with sectors should also be voted on via governance. Developers who associate unrelated markets with each other are exploiting the protocol and established creators. This is because they leverage creator's market that has a better APY and more stakers. This should be seen as a negative externality or tax on creators. Therefore, the process of adding a new market or sector should be similar to the process of adding an asset to Dev Protocol.

Example: Youtube market can't join OSS market but Github and NPMJS can join OSS market.

• Existing sector developers have an incentive to associating with new markets.

No, they don't because existing markets have more stakers + more assets (more inflation). Also if Governance must approve markets and sectors then there won't be an incentive to exploit the protocol.

Therefore, individual markets, not sectors, should have an impact on APY. (If so, the existing npm Market may need to be migrated to GitHub Market)

Yes, I agree that NPM and Github should be associated under the OSS sector.

Change the APY for each market.
　->I disagree.
　I think the reason for staking will change from "I want to support you" to "I want to make more profit", and we'll go back to the previously removed feature of "the reward increases with the number of downloads".

Forking the protocol
　->I disagree.
　Maintenance costs will increase and become unmanageable.
　It is reminiscent of the packaged software that was often produced in Japan between 1995 and 2005, which did not anticipate maintenance costs.

Change the APY for each market.
　->I disagree.
　I think the reason for staking will change from "I want to support you" to "I want to make more profit", and we'll go back to the previously removed feature of "the reward increases with the number of downloads".

Yes, this model incentives users to make profit. Which isn't a bad thing, but isn't the correct way to look at it as well. I'll explain why.

1. There's many different types of creators with different talents, workloads, communities, and supporters. An OSS creator doesn't want their salary to be dependent on Youtubers or their community. By having separate sectors this allows DEV holders to place a socioeconomic value on creators.
2. This model is very different from basing it on metrics. This is because even if a new market has an APY of 400% a small amount of DEV staked will saturate that APY to 10%.

I will share the math.

Calculation
Current Inflation rate= .00012 DEV per second
Seconds in a year= 31,536,000
Assets onboard to new market= 1
DEV minted per year= 3,784.22 DEV
DEV for creator= 1,892 DEV
DEV for stakers= 1,892 DEV

Assume 10,000 DEV is staked in new market
Staker APY= 18%
Creator APY= 19%

Therefore there isn't competition because a small amount of DEV saturates the rewards. In this example 10,000 DEV staked brings APY to 18%. The current OSS market has 500,000 DEV staked with a 28% APY.

Under my model a new market can only become competitive with existing markets by having creator adoption that increase DEV minted per block.

3. Please don't forget that Dev Protocol is also building incentives for staking. Therefore the intrinsic value of staking is not only the APY, but the utility you receive from staking.

Forking the protocol
　->I disagree.
　Maintenance costs will increase and become unmanageable.
　It is reminiscent of the packaged software that was often produced in Japan between 1995 and 2005, which did not anticipate maintenance costs.

Yes, Aggre already proposed the following solution

Please follow the conversation so we don't have to repeat information.

Still, I think "simple is best" is the way to go.

I still think that the incentive to separate the sectors may not work. Therefore, I think it would be better if individual APYs were held by Markets rather than by sectors. The same concept as sectors can be realized by having the creators choose the relevant markets and authenticate each of them. For example, an OSS developer can authenticate npm and GitHub. His Property will add up the APY of npm and GitHub. I think that is a more flexible solution than sector.

New markets should be voted on via governance. The association of markets with sectors should also be voted on via governance. Developers who associate unrelated markets with each other are exploiting the protocol and established creators. This is because they leverage creator's market that has a better APY and more stakers. This should be seen as a negative externality or tax on creators. Therefore, the process of adding a new market or sector should be similar to the process of adding an asset to Dev Protocol.

@defi-er People and creators staking on Property-P in Sector-S want to see more assets in Sector-S. If so, why don't people create an "All" sector?

I still think that the incentive to separate the sectors may not work. Therefore, I think it would be better if individual APYs were held by Markets rather than by sectors. The same concept as sectors can be realized by having the creators choose the relevant markets and authenticate each of them. For example, an OSS developer can authenticate npm and GitHub. His Property will add up the APY of npm and GitHub. I think that is a more flexible solution than sector.

This creates double the inflation of Dev Protocol because you have one asset across two markets where each market has it's own inflation.

New markets should be voted on via governance. The association of markets with sectors should also be voted on via governance. Developers who associate unrelated markets with each other are exploiting the protocol and established creators. This is because they leverage creator's market that has a better APY and more stakers. This should be seen as a negative externality or tax on creators. Therefore, the process of adding a new market or sector should be similar to the process of adding an asset to Dev Protocol.

@defi-er People and creators staking on Property-P in Sector-S want to see more assets in Sector-S. If so, why don't people create an "All" sector?

This is the idea of "Sets" that I described before were the UI/UX has pre-made packages of assets to support across different markets. Being the first creator in a new market is also advantageous because with adoption of the new market all inflation will benefit you relatively more than the new creator since you have stakes. Therefore, early adopters are compensated.

This creates double the inflation of Dev Protocol because you have one asset across two markets where each market has it's own inflation.

In my understanding, the same situation (double the inflation rate) occurs in sectors as well. (ref: #41 (comment))

By dividing the global APY proportionally to each Market, we can solve the problem that the inflation rate depends on the number of Markets. Naturally, Markets need to pass governance, but the risk of reducing one Market's reward is safer than the risk of doubling the inflation rate. If there are too many markets, users can start governance flow to change global APY.

This DIP's motivation includes "reducing the impact of assets in different fields on each other's reward." Introducing a prorated global APY would not solve that problem, while introducing native APYs would also not solve the problem because of the risk of higher inflation rates.

This is the idea of "Sets" that I described before were the UI/UX has pre-made packages of assets to support across different markets. Being the first creator in a new market is also advantageous because with adoption of the new market all inflation will benefit you relatively more than the new creator since you have stakes. Therefore, early adopters are compensated.

The economic rationality of a sector is maximized in a situation where there are many assets but less staking until it reaches the same amount of staking as other sectors. The following simulation results show that the incentive for creators to participate in a sector with fewer assets does not work because fewer assets mean fewer rewards. The strategy that each sector must implement is to "increase assets while not increasing staking."

Pattern A

• Total assets: 10
• Total staked: 1000
• Reward per month/asset: 20.72296703200333824

Pattern B

• Total assets: 100
• Total staked: 1000
• Reward per month/asset: 20.722967032003345152

Pattern C

• Total assets: 10
• Total staked: 10000
• Reward per month/asset: 20.60604979640969472

Pattern D

• Total assets: 100
• Total staked: 10000
• Reward per month/asset: 20.606049796409710272

Pattern E

• Total assets: 100
• Total staked: 100
• Reward per month/asset: 207.34696322909211456

Therefore, any sector's key strategy is to increase the number of assets rather than the number of staking. If this is the case, then people will want to see assets concentrated in one sector. If not, users will be looking for the sector "Sector-S," which has more assets but less staking. Market developers will also be looking for Sector-S, and voters will be motivated to associate the new Market with Sector-S. I think the native APYs for sectors will not work well if economic rationality is prioritized. Therefore, I think it's healthier for Markets to have their native APY, not sectors. And if the impact of different fields on each other's reward can be minimized, arbitrage opportunities may be unnecessary.

I understand that there are two approaches to consider:

• How to reducing the impact of assets in different fields on each other's reward (without new inflation or split global APY)
• How assets in different fields can take advantage of arbitrage opportunities

This creates double the inflation of Dev Protocol because you have one asset across two markets where each market has it's own inflation.

In my understanding, the same situation (double the inflation rate) occurs in sectors as well. (ref: #41 (comment))

Sector is created, via Governance, which consists of different Markets
Markets are different platforms that service the same sector (Gitlab, Github, npm markets --> belong to OSS sector)
Markets can only belong to one sector
All markets use the Sector's APY that they belong to
Assets can only be added to one Sector voted on via Governance or Kleros Curate
Creators can't tokenize an identical asset to different markets (Example: Chalk on Github vs Chalk on npm) This is the responsibility of Governance or Kleros Curate

Therefore no asset can create double the inflation because Governance or a decentralized curation service, Kleros, wouldn't accept the asset.

The economic rationality of a sector is maximized in a situation where there are many assets but less staking until it reaches the same amount of staking as other sectors. The following simulation results show that the incentive for creators to participate in a sector with fewer assets does not work because fewer assets mean fewer rewards. The strategy that each sector must implement is to "increase assets while not increasing staking."

Yes, from the top down perspective there would be less staking on a new market. However, the most important perspective is the top up perspective (creator's perspective). The creator in a new market would still receive 10,000 DEV staked at 19% APY which is currently $8,000. Each time a new asset onboards the existing creator benefits because now APY is increasing and he already has DEV staked for his asset. Additionally, this could create more innovation from creators with incentives, liquidity mining for creator token, etc.

The economic rationality of a sector is maximized in a situation where there are many assets but less staking until it reaches the same amount of staking as other sectors. The following simulation results show that the incentive for creators to participate in a sector with fewer assets does not work because fewer assets mean fewer rewards. The strategy that each sector must implement is to "increase assets while not increasing staking."

Pattern A

• Total assets: 10
• Total staked: 1000
• Reward per month/asset: 20.72296703200333824

Pattern B

• Total assets: 100
• Total staked: 1000
• Reward per month/asset: 20.722967032003345152

Pattern C

• Total assets: 10
• Total staked: 10000
• Reward per month/asset: 20.60604979640969472

Pattern D

• Total assets: 100
• Total staked: 10000
• Reward per month/asset: 20.606049796409710272

Pattern E

• Total assets: 100
• Total staked: 100
• Reward per month/asset: 207.34696322909211456

To reflect early Market's difficulty we could adjust inflation rate, via governance, to diminish with adoption. This entails setting a high inflation rate per asset from the start that decreases with each new asset. This could be seen as the difficulty rate of adoption.

I shared my concern that the inflation rate would double if Sector or Market were to calculate the APY separately. However, the simulation results showed that the doubling was an overestimate and that the actual rate would be "slightly higher."

Pattern A

• Total staked: 10000
• Total assets: 1000
• Reward per month: 20606.049796409710272

Pattern B

• Total staked: 5000
• Total assets: 500
• Reward per month (2x): 20670.9195794744592

When reproducing Sector with multiple authentications in similar Markets, the number of authentications is higher than when using Sector, so the APY is likely to increase. (ref: #41 (comment))

In light of these facts, I agree that organization multiple Markets into Sectors is a better idea than having separate APYs for each Market.

I'm left with at least the following considerations:

• Whether the fact that new Sectors have lower APYs than older Sectors improves the network effect of Dev Protocol
  • If the APY is the same as the APY of older Sectors, it will help new Sectors to grow faster. Also, if the new Sectors grows faster, the old Sectors can also accept the benefit.
  • I'm trying to understand the benefit/loss that old Sectors get from rejecting new Sectors.

To reflect early Market's difficulty we could adjust inflation rate, via governance, to diminish with adoption. This entails setting a high inflation rate per asset from the start that decreases with each new asset. This could be seen as the difficulty rate of adoption.

@defi-er Yes. Users can formulate/propose such policies through the Policy Contract.

Could you please provide details for the following scenario? I would like to see how an early market looks like under the current tokenomics.

OSS

Total staked: 500,000
Total assets: 1000
Reward per month:

Youtube

Total staked: 20,000
Total assets: 10
Reward per month:

When reproducing Sector with multiple authentications in similar Markets, the number of authentications is higher than when using Sector, so the APY is likely to increase. (ref: #41 (comment))

I don't understand this could you rephrase it please?

• I'm trying to understand the benefit/loss that old Sectors get from rejecting new Sectors.

A new Sector "should" be rejected if it's fake, monetized, and doesn't fit Dev Protocol's mission because this creates forged inflation which is a tax on holders.

To reflect early Market's difficulty we could adjust inflation rate, via governance, to diminish with adoption. This entails setting a high inflation rate per asset from the start that decreases with each new asset. This could be seen as the difficulty rate of adoption.

@defi-er Yes. A user can formulate/propose such policies through the Policy Contract.

Yes, I don't want to propose this at the moment until it's necessary.

Could you please provide details for the following scenario? I would like to see how an early market looks like under the current tokenomics.

These are the simulation results.

OSS

• Total staked: 500,000
• Total assets: 1000
• Reward per month: 15167.8647980858689344

Youtube

• Total staked: 20,000
• Total assets: 10
• Reward per month: 204.769460305568448

When reproducing Sector with multiple authentications in similar Markets, the number of authentications is higher than when using Sector, so the APY is likely to increase. (ref: #41 (comment))

I don't understand this could you rephrase it please?

@defi-er I'm sorry for the poor expression. There are two ideas for "combining a group of assets into one to calculate the APY." Plan-A is to "calculate the APY by bundling multiple markets using 'Sector,'" and Plan-B is to "calculate the APY by authenticating with multiple similar markets (e.g., npm+GitHub for OSS)." Both theoretically produce the same APY and inflation rate. However, since Plan-B increases the number of authenticates (number of assets), the APY and inflation rate should actually be higher than Plan-A.

A new Sector "should" be rejected if it's fake, monetized, and doesn't fit Dev Protocol's mission because this creates forged inflation which is a tax on holders.

I agree that such a perspective is necessary. But it works well with governance for just the Market as well, not Sector. Even if the protocol implements Sector, the number of assets included in the Sector is increased by each Market. So Market governance is important anyway.

I'll organize the benefits/losses of Sectors/Markets not sharing APY later.

However, since Plan-B increases the number of authenticates (number of assets), the APY and inflation rate should actually be higher than Plan-A.

Thank you for the thorough explanations and calculations! Could you explain how Plan-B increases the number of authentications hence increasing inflation?

I was under the impression that number of authentications and inflation is equal in both Plan A & B. Inflation is similar because each asset creates .00012 DEV per block. Authentications is equal because both plans require authentication but have different models of categorizing assets into Sectors based on Market. The difference is the APY because Sectors will have different amounts of DEV staked to capture inflation hence creating different APYs.

Thank you for the thorough explanations and calculations! Could you explain how Plan-B increases the number of authentications hence increasing inflation?

@defi-er I'll explain why I thought so. In Plan-A, if the assets increase in any of the Markets bundled with Sector-X, the rewards of all Properties included in Sector-X will increase. In Plan-B, creators voluntarily select and authenticate multiple Markets to increase rewards. Plan-B produces a lower inflation rate than Plan-A when there are many "lazy creators." I thought that Plan-B had a stronger incentive to authentication and generated larger authentications (assets). However, in theory, if the authentications (assets) and the stakings are the same, there is no difference in inflation rates between Plan-A and Plan-B.

However, in theory, if the authentications (assets) and the stakings are the same, there is no difference in inflation rates between Plan-A and Plan-B.

Yes, I think it's just a difference in APYs

I have sorted out some advantages/disadvantages. In conclusion, my judgment is 50/50.

From the perspective of a simple network effect, I think the current spec with a single large asset pool is better. The current spec is also excellent from the perspective of software engineering. Native APYs create loosely coupled communities. Autonomous regions that are villages may be comfortable for the parties and may eventually contribute to the network effect.

I could not conclude, so I think it is good to leave this judge to the community. (For that purpose, it is necessary to publish information completely neutrally)

Here is my organized list:

Advantages

• Sectors are not affected by the APY degradation produced by other Sectors.
• When new Sectors have many assets and less staked, they can quickly collect stakes by arbitrage.
• People in low APY Sectors have an incentive to curb value loss due to inflation caused by high APY Sectors.
• The new Sectors' impact on the inflation rate starts small, allowing governance to focus on the authentication model's legitimacy.

Disadvantages

• Sectors cannot enjoy the increase in APY generated by other Sectors.
• New Sectors have low APY, making it difficult to collect staking.
• People in low APY Sectors are forced to stave to curb value loss due to inflation caused by high APY Sectors.
• The sum of the inflation rates by native APYs is slightly exceeding the inflation rate by singleton APY. (Policy needs to be updated as Markets increase)
• Governance that associates a new Market with a Sector can have irrelevant associations by prioritizing economic rationality. (People who want to accelerate new Market by associating them with existing big Sector)
• Sectors can be concentrated in larger domains (e.g., OSS < Software < Technology, YouTube < Video < Culture), which can cause new problems.

Thank you for providing a very clean summary for the community. Maybe I can address some of the disadvantages with possible solutions.

Disadvantages

New Sectors have low APY, making it difficult to collect staking.
People in low APY Sectors are forced to stave to curb value loss due to inflation caused by high APY Sectors.

The first creators of a new sector can receive $50,000 in DEV (at current prices) and make ~$9,000 per year. This is actually better than the average creator in the OSS sector because stakes are accumulated by first page. Additionally, the APY is 18% which is only 10% less than OSS market. Governance could release markets when there's a waitlist of assets available to onboard to kickstart the market.

Calculation
Current Inflation rate= .00012 DEV per second
Seconds in a year= 31,536,000
Assets onboard to new market= 1
DEV minted per year= 3,784.22 DEV
DEV for creator= 1,892 DEV
DEV for stakers= 1,892 DEV

Assume 10,000 DEV is staked in new market
Staker APY= 18%
Creator APY= 19%

The sum of the inflation rates by native APYs is slightly exceeding the inflation rate by singleton APY. (Policy needs to be updated as Markets increase)

Could you explain why this is? Inflation rate per asset should be equal since each asset produces .00012 DEV per second.

Governance that associates a new Market with a Sector can have irrelevant associations by prioritizing economic rationality. (People who want to accelerate new Market by associating them with existing big Sector)

Implement Kleros as an arbitrator of last resort if users vote to arbitrate a decision by Governance. However, quadratic voting should ensure that large holders don't have large control over Governance.

Sectors can be concentrated in larger domains (e.g., OSS < Software < Technology, YouTube < Video < Culture), which can cause new problems.

Governance must vote on the approved sectors and which markets are applicable to those markets.

Thank you for your comment.

The first creators of a new sector can receive $50,000 in DEV (at current prices) and make ~$9,000 per year. This is actually better than the average creator in the OSS sector because stakes are accumulated by first page. Additionally, the APY is 18% which is only 10% less than OSS market. Governance could release markets when there's a waitlist of assets available to onboard to kickstart the market.

That simulation does not seem to consider the Ethereum block time and the decrease due to the staking ratio. When 10,000 staked, the reward is reduced to 99.37%. (Verified by the contract)

MAX_REWARD = 0.00012 * (60 * 60 * 24 * 365/15) = 252.288
ACTUAL_REWARD = 252.288 * 99.37% = 250.698

Assume 10,000 DEV is staked in new Market
Staker APY = 250.698 * 0.49 / 10000 = 1.22%
Creator APY = 250.698 * 0.51 / 10000 * 100 = 1.27%

Therefore, "New Sectors have low APY, making it difficult to collect staking" is explain correctly as one of the disadvantages.

The sum of the inflation rates by native APYs is slightly exceeding the inflation rate by singleton APY. (Policy needs to be updated as Markets increase)

Could you explain why this is? Inflation rate per asset should be equal since each asset produces .00012 DEV per second.

That is shown in this simulation ( #41 (comment) ). The inflation rate is curved, not linear, so it does not match "10,000 staked" and "5,000 staked x 2." But solve that issue is the role of Policy. Therefore, if this issue becomes a major issue, users can propose a new Policy to solve it.

Implement Kleros as an arbitrator of last resort if users vote to arbitrate a decision by Governance. However, quadratic voting should ensure that large holders don't have large control over Governance.
Governance must vote on the approved sectors and which markets are applicable to those markets.

Yes. This issue is not the DIP issue but a governance issue. Therefore, I understand that there is no need to discuss this deeply in this DIP.

MAX_REWARD = 0.00012 * (60 * 60 * 24 * 365/15) = 252.288

Is /15 the average Ethereum block (in seconds)?

Is /15 the average Ethereum block (in seconds)?

@defi-er Yes, 15 is the Ethereum target block time. These days, mining is often done in about 13 seconds, but L1 adjusts the difficulty of PoW to that it is mined in 15 seconds.

Is /15 the average Ethereum block (in seconds)?

@defi-er Yes, 15 is the Ethereum target block time. These days, mining is often done in about 13 seconds, but L1 adjusts the difficulty of PoW to that it is mined in 15 seconds.

If DEV became compatible with an L2, OVM for instance, then how would this change the tokenomics? Would the tokenomics just follow the main-net?

The concept of block time differs depending on L2, but I think it is necessary to adjust it to have the same APY as the main-net.

// As an aside, I like the concept of L2(rollup)-centric.