[RFC] sTokens, a token mirroring DEV staking

Feedback & Proposals
#1

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
Testing Staking Perks
[RFC] Proof of Creations
Governance Dapps for OSS
#2

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
#3

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

2 Likes
#4

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

1 Like
#5

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.

2 Likes
#6

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.

1 Like
#7

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.

1 Like
#8

It is possible that APY could be accurately represented by changes in the number of sTokens (not NFTs) distributed. Still, I stopped digging into it because I thought it was somewhat too complicated :relieved:

The protocol should realize two properties in the reward calculation:

  • Increasing rewards according to time series
  • APY increases/decreases at unpredictable timings

To represent these, Dev Protocol uses cumulative sums that are always increasing. Since the cumulative sum is always increasing, it can represent a time series.

If sTokens (not NFTs) are minted by a variable rate, wouldn’t a late staking user get less than 100% rewards they should have earn for staking 1?

2 Likes
#9

Oh yeah, it can get complicated, it’s better to focus on more urgent matters.

Yeah, it makes total sense. I think that an sToken wouldn’t change the emission rate. If we think of the emission in terms of the DEV staked, just like it is today.

In the case of gDEV - > inflation would happen inside of the gDEV token pool so the sToken emission wouldn’t be a problem at all, it could just be proportional to the amount of gDEV staked.

With DEV being staked, the solution is quite similar to the gDEV pool, but for every individual creator. Late stakers would just receive sTokens in proportion to their (Stake amount)/(Total DEV staked+Total Rewards), price itself is an information, and it’s perfect for this.

The problem is exactly that, find a present value formula so that, when withdrawing, rewards are just, no matter the time individuals staked.

2 Likes
#10

Yeah, you’re right, sTokens don’t need to be 1:1 when combining gDEV tokens

2 Likes
#11

To keep the feasibility and simple code base, my basic line is to implement sTokens as NFTs. But if those NFTs don’t have composability benefits, I’m also considering building an NFTs <> ERC-20 bridge. The bridge converts only NFTs that match certain conditions to ERC-20.

3 Likes
#12

Awesome! Sounds like a good plan :slight_smile:

3 Likes
#13

It’s still in progress, but I’m preparing a technical proposal.

3 Likes
#14

A vote is open here: Govern

1 Like
#15
#16
#17

To improve the usefulness for sTokens as a utility for designing perks, I’ve added a contract interface called “rewards” to the specification. This is a specification addition, not a specification change, and even not a does not affect gas efficiency on the existing interfaces so that no additional voting will be done. You can find more details on the GitHub link. If you think you have a problem, let me know your opinion on GitHub or this topic.

1 Like