[RFC] sTokens, an ERC20 token mirroring DEV staking

Summary

A proposal for ERC20 tokens issued in proportion to the amount of DEV staking, called sTokens.

Component Summary

  • sTokens is a unique ERC20 token for each Property token.
  • By staking 10 DEV on the Property tokens “Chalk,” the staker gets 10 sChalk tokens.
  • Holders of sTokens get staking rewards according to their share.
  • If the gDEV already discussed is implemented, sTokens will be issued by gDEV staking.

Motivation

DEV staking users can prove that they are staking by the function in the Lockup contract on Dev Protocol. However, the function is not a standardized interface such as ERC20, which creates an inconvenient situation for composability.

Details

sTokens are automatically issued upon staking and automatically burned upon unstake.

One thing to consider is a change in the staking reward calculation logic. Currently, staking rewards are calculated by the difference between the reward unit price when staked and the latest reward unit price. A holding history of sTokens and a history of staking may not match, so changes to the reward calculation logic are required.

Agreed Collaborators

  • None

Missing Roles

Compensation

Not decided yet

References

  • None
3 Likes

I think it’s an improvement from the current system since it could be used on a governance dapp or other Perks but I think that it still falls on that same incentive trap that the current system falls into.

By requiring to stake to receive rewards, stakers are induced to choose a strategy where they have to stake even when they don’t know a project and don’t like what they’re doing. The Nash equilibria are staking, even if they’re providing extra Perks or not.

Another category would be the proposed gDev token, when we remove that not providing Perks equilibrium of the equation, and start rewarding gDev holders just by being gDev holders. This gives Stakers the power to deviate their strategy and force a new Equilibrium where Creators create and give out rewards/perks.

By still using the first model I think that we would lose this interesting incentive. Maybe both could be combined? sToken could be received when staking a token that already gets staking rewards and these sTokens could be used on the governance dapp, to receive more creator Tokens, Perks, etc.

1 Like

This is not a proposal for tokenomics, but a utility extension. sTokens tokenizes staking and extends the composability of staking.

2 Likes

Oh yeah, I was just commenting on this point and the one that follows it and some potential differences in incentives.

1 Like

Summary: Staking Perks should be a priority

sTokens should be implemented as NFTs, but the implications of those NFTs are extended metadata that does not contribute to composability.

Details

One thing to consider is a change in the staking reward calculation logic. Currently, staking rewards are calculated by the difference between the reward unit price when staked and the latest reward unit price. A holding history of sTokens and a history of staking may not match, so changes to the reward calculation logic are required.

When I was thinking about this technical challenge, it occurred that sTokens would be more appropriate for ERC-721 than ERC-20. This is because staking is always 1:1 for the number of DEV(or gDEV), and because of the accumulation of rewards over time, the reward per stake needs to have information such as the stake starting block number.

Here’s one simplified example:

  • Alice has staked 100 DEV for 6 months. And Alice is the only staker. Now Alice can claim her reward for 100 DEV x 6 months.
  • Next, Bob has staked 400 DEV, Alice’s staking share has dropped from 100% to 20%, and Bob’s staking share is 80%.
  • If the calculation of staking rewards ignores time series, Bob has the ability to earn 80% of the rewards that Alice has been accumulating for 6 months, even though he has only been staking for a few seconds.

Therefore, it would be preferable for sTokens to be realized by a specification with metadata, such as ERC-721. This is similar to why the tokens in Uniswap v3 LP are NFTs: Uniswap v3 LP has different parameters for each liquidity provider, so NFTs with their own extended metadata are used.

Now, remind the motivation for sTokens: sTokens is to improve the composability of staking.

However, sTokens as NFTs is meaningful through their own extended metadata. For example, staking start date, staking amount, etc. Since those extended metadata are not standardized, they are not available in external protocols such as Mintgate, for example. Therefore, all staking would appear homogenous; a 100 DEV staker and a 1 DEV staker having the same capabilities would be frowned upon in many situations.

So I thought it would make more sense to only give out NFTs to users conditioned by Staking Perks. It also gives the creators more room to be creative.

Fortunately, more progress has been made on Staking Perks than on sTokens, and development has actually begun.

Now it’s time to consider what the value of implementing sTokens in Staking Perks and beyond might be.

1 Like

Interesting. Does it really need to be 1:1? What if it is 1:1 just for the first staker? After emission starts in that specific pool the price of that specific sToken could vary. If the price of that specific sToken distributed is = (DEV staked + Rewards)/(sTokens distributed) that proportion would change. The proportion could fixed as the same as the last staker to join the pool. That is, the proportion sTOKEN/DEV only goes up, even if everyone leaves the pool.
This way the 1:1 case would be just the special case where Rewards 0.

Can that information be the price of the sToken itself in that specific pool?

Given the comment above of sTokens not really being 1:1.
In a case where Alice got a 60% yield on staking , when Bob stakes, instead of getting 400 sTokens, Bob would get 250 sTokens. Because inside of that specific Creator pool the price of sTokens:DEV went to 1.6. Now Alice still has 100 sTokens and there are 560 DEV in that pool, she’d still be able to withdrawal 160 DEV .

This NFT solution sound really interesting but I couldn’t really comprehend it. I will study it a bit more.

Also, if this is the case, since gDEV already has the emission inside of it’s own pool, sTokens would be used solely for Perks purposes. So, this problem of creating a new form of distributing rewards wouldn’t exist.