[RFC] Separation of utilities and rewards, a new built-in token with a fixed supply

This RFC is an idea derived from @Pdot’s comment on DIP-19. After getting more feedback on this forum, I will put together a draft as a new DIP.

Purpose

By separating multiple utilities of DEV tokens into individual tokens, we aim to improve the flexibility for reward design and improve governance security.

Gists

Gist 1: gDEV tokens with fixed supply for staking and governance

gDEV is a fixed supply ERC20 token used for Dev Protocol staking and governance. The supply of gDEV is the same as the total supply of DEV at the time of the genesis of gDEV.

DEV will change to be used only as a creator reward.

Gist 2: Two primary markets, borrow gDEV with DEV as collateral, get Property tokens by gDEV staked

gDEV can be borrowed with DEV as collateral. This acts as the primary market for gDEV. The DEV collateral rate starts at 100% and increases with each increase in borrowing following an exponential curve. Inflation DEV as staking rewards will also be added to the immediate collateral pool, continuously increasing the DEV collateral rate for gDEV borrowing.

gDEV holders will benefit from the increased collateral rate in the background simply by holding the gDEV. In other words, if you redeem gDEV and get DEV after the collateral rate has increased, you are more likely to get more DEV than when you borrowed gDEV.

The gDEV staking user gets part of the Property tokens they staked. This acts as the primary market for Property tokens. Since Property tokens are value-formed by creators, users can expect more staking for creators who have added higher value to Property tokens.

Considerations

Consideration: gDEV Genesis Event

The moment gDEV launches, we need to consider how to distribute it to existing users.

In my opinion, users who were staking at the time of gDEV launch will get gDEV at a 1:1 rate to the number of stakes. (This mechanism to be implemented by the Markle Distributor.)

Considerations: Staking rewards

The gist of the design is that gDEV staking users get some of the Property tokens instead of DEV. However, since Property tokens are finite, we need to consider the mechanism distributing property tokens to staking users.

Considerations: Creator rewards

How to distribute rewards to Property tokens holders.

In my opinion, distribute DEV according to the number of gDEV stakings they have. In other words, the mechanism is the same as it is today.

Another option is to aggregate all DEV token distribution logic into gDEV tokens. However, in that case, creators “require to get gDEV by themselves” to get the benefits for creation, so the protocol has no built-in benefits for creators and the uniqueness of Dev Protocol. May damage the ecosystem. So, Dev Protocol needs some mechanism to preferentially lend gDEV tokens to Property tokens holders for creator benefits. I thought it would be simpler to distribute DEV (rather than gDEV) to creators rather than building such a mechanism.


Note that this RFC is not the consensus of Pdot and me, as it contains content that was not discussed in the DIP thread.

1 Like

Overall it’s an interesting proposal.
One downside I see is that this process of borrowing gDEV will complicate a bit the onboarding of new projects.

For creators, the scheme isn’t changing from the current scheme. But yes, the steps to understand Dev Protocol become more complex.

1 Like

There is no difference designed between users who have staked gDEV and those who have not. However, since the staked users generate the DEV inflation, and the inflation rises the collateral rate, so there is no motivation for them not to stake.

This specification could be simplified further :thinking:

1 Like

Thanks for posting @aggre !

To make it simple, gDEV could even be equal to the (amount of DEV staked on the pool) - (all the emission rewards). Emission and rewards would be the same.

The main difference is to sell your rewards, you necessarily will have less gDEV than before. This doesn’t happen today since DEV is staked and the rewards of DEV are seen as an excess.

It moves the ball to the Creators’ court, now stakers can receive DEV for just having the governance token gDEV, now Creators would have to do something more to attract stakers.

Please discuss this with us friends, it’ll help a lot to get more views on this.

2 Likes

I particularly liked the part of the ball being in the creators’ court.

A common theme is that creators try to get on boarded and approved, and then do nothing to help the platform that is supporting them (e.g not bringing enough to the table such as implementing a token-holding mechanism, or a system that involves their dev-issues tokens into their project).

1 Like

This is a cool idea i think. Its abit more complicated but for sure its better than the old system!

1 Like

Hey, I’ve made some arts that should help understand the line of thought of using gDEV instead of just DEV to incentivize Creators to use their tokens or provide perks to stakers.


First, Stakers would receive inflation just by holding gDEV and being part of the DAO.
As gDEV never loses value against DEV, there is never the feeling of having excess reward DEV, if you swap your gDEV to DEV to sell, you’ll necessarily have less gDEV, even though you’ll have more DEV.

This changes the whole incentive system, it changes from a system where Creators could just not interact with the system and still receive rewards. Since the previous system, the Nash Equilibria would always be Staking.

This way, it allows the Staker to have the freedom to change strategies, that is, to not stake. This will force the Creators to change their strategies of doing nothing, to do something, forcing a new Equilibirum where stakers get rewards on top of the regular APY% and Creators that change strategies will be rewarded with more stakers.

The payoff for the Staker is 30% x (Their stake), suppose it’s 1 here for simplicity.

1 Like

By the way, the payoff for stakers in the case they not stake in the gDEV proposal is 30%.
In the current system, by not staking, the payoff is -30% (opportunity cost).

By allowing the Stakers to remove this negative payoff from their strategies, it forces the Creators to have an opportunity cost within the system from the first time. To attract the potential stakers that are not funding their projects, they have the incentive to offer more, and move to the (USEPERKS,STAKESgDEV) strategy.