rETH2 Staking Contract to Incentivize Choosing StakeWise

Ideas
1

The staking rewards token, rETH2, is a key component of the DAO’s tokenomics. The StakeWise development team wants to introduce staking functionality for the rETH2 token, in order to incentivize protocol’s adoption and avoid a discount on rETH2 in the marketplace.

Motivation

There are two key challenges facing the StakeWise DAO with regards to its product:

  1. The competitive landscape of Eth2 staking is tough - several protocols are competing for a place under the sun.
  2. In the existing setting, the reward token rETH2 might trade at a discount on the secondary market. The discount would reflect the opportunity cost of holding it until Phase 1.5.

To achieve rapid market share growth and avoid the discount for rETH2, we believe the StakeWise DAO must consider adding incentives to use the protocol that are tied to rETH2 token.

Specification

We propose to kill two birds with one stone by enabling rETH2 staking functionality. The idea is to reward users with $SWISE for staking rETH2. Here’s how we foresee this mechanism working:

  1. Create a staking contract for rETH2
  2. Allocate 0.04-0.05% of $SWISE supply (400,000-500,000 $SWISE) every week to stakers in the contract
  3. Allow to deposit (stake) rETH2 into the contract
  4. Distribute $SWISE proportionately among the stakers of rETH2 in the contract

The net effect from this mechanism is the following:

  1. Native staking yield is augmented with $SWISE rewards
  2. rETH2 becomes a yielding asset because $SWISE can be earned with rETH2
  3. This creates demand for rETH2 on the secondary market, removing the discount for the token
  4. Users of StakeWise can opt to regularly stake their rETH2 tokens to boost their yield with $SWISE or sell rETH2 to achieve a compounding effect

Limitations

Gas costs. The current state of affairs makes frequent staking of rETH2 expensive and out of reach for many users. The solution to this problem is the creation of vaults that aggregate users’ rETH2 and split the gas costs between everyone using the vault. rETH2 staking vault can be combined with other vaults to automate many things for the end users.

Alternatively, it might happen that the users who are not willing to stake rETH2 can still benefit from this idea. In our modeling we discovered that through an allocation of 0.04-0.05% of the $SWISE supply per week to this mechanism, we can achieve sufficient APY to not only close the discount, but achieve a premium on rETH2 vs ETH. One important implication of this is that the users whose deposit is too small to consistently stake rETH2 without spending a lot of gas could capture the APY from $SWISE rewards by selling their rETH2 at a premium to ETH, and potentially re-staking the proceeds.

As always, we look forward to your feedback on this idea :slight_smile:

6 Likes
2

Love the idea.
That being said, i could also take my rETH2, swap it in a liquidity pool against ETH and stake that? So there would be another competing rETH2 staking market competing with the SWISE rewards. The incentive would be gas price, rigth?

1 Like
3

The limitations section, the rETH2 vault aggregation.

The rETH2 starts out not in the user’s possession but held in a smart contract.
The claiming and re-staking takes it from one stakewise smart contract and puts it into another.
It looks like I’m paying to take something from stakewise, and then paying to give it right back to stakewise. I’m sure this is how trustlessness and ownership is determined, and also this is the gold standard of DefI. However,

$103,000 at 7% interest results in about $600 a week. To claim and re-stake weekly results in 8% cost + taxable events ($50 combined estimate for 2 transactions.) Because of this, there is a market for automation. xToken, yearn finance, alpha finance, etc. all have different approaches for socializing gas costs. So, can we do it in house? Can we fork code? Are there moral issues, is it non creative, is it stifling growth in the automation sector?

For moral issues: Can we perhaps fork the code but submit a pull request on their repository? Kind of like: “Hey we built this for you, will you please accept the offer it would benefit our users and we appreciate your code.” We offered, if they refuse we do what we need to do. By doing in house automation we would get to outline the parameters, we would be able to offer users the opportunity to not farm and dump.

Is there a way to alter the contract rETH2 waits to be claimed in to also accrue SWISE rewards relative to the users share of total rETH2 in the contact per unit time? Or, what about deploying another contract that calculates user share of unclaimed rETH2 and have a claim rETH2 button and a claim rETH2 & SWISE button. Separating complexity of the transaction and putting gas costs on the user, but also including them in the SWISE incentives.

Would it require deploying new contracts, would that be able to be a one time thing, and are either of these less gas intensive than the vaults mentioned in the original post?

For your consideration,
Thanks.

3 Likes
4

Yes man, I believe that’s the correct understanding.

That being said, i could also take my rETH2, swap it in a liquidity pool against ETH and stake that? So there would be another competing rETH2 staking market competing with the SWISE rewards. The incentive would be gas price, right?

Our goal is to introduce several strategies into the market. In the modeling work that we did, there is a potential for users who earn rETH2 from staking/buy it from the open market to achieve consistently high APYs from this mechanism. This should create buying pressure for rETH2 that pushes up its price relative to ETH, until some equilibrium point where rETH2 owners continue to see the financial benefit of staking the token, and those who want to compound their returns are happy with the price they’re getting for rETH2 on the market. So everyone should be happy.

1 Like
5

Thank you for a thoughtful suggestion and your perspective on the subject. I’ll address every section separately below.

$103,000 at 7% interest results in about $600 a week. To claim and re-stake weekly results in 8% cost + taxable events ($50 combined estimate for 2 transactions.) Because of this, there is a market for automation.

Completely agree with you on this - both gas fees and tax could be optimized by aggregating capital and automating the process. I believe it is our job as a development team to approach relevant projects regarding the automation, but also to give them something to work with i.e. strategies or suggestions about the precise changes they could make into existing contracts to build something for us.

This brings me to your other point:

We offered, if they refuse we do what we need to do. By doing in house automation we would get to outline the parameters, we would be able to offer users the opportunity to not farm and dump.

Again, fully agree with this approach. In the ideal world, automation of farming strategies would pop up immediately based on the opportunities to make a quick buck from it, but admittedly, the current state of things is far from ideal. So we’d want to do some prodding, and if we must rest our case with integrations, we will want to squeeze out every bit of value from doing this ourselves. That’s something that requires more time and thought from the team, but we are aware of that.

Is there a way to alter the contract rETH2 waits to be claimed in to also accrue SWISE rewards relative to the users share of total rETH2 in the contact per unit time? Or, what about deploying another contract that calculates user share of unclaimed rETH2 and have a claim rETH2 button and a claim rETH2 & SWISE button. Separating complexity of the transaction and putting gas costs on the user, but also including them in the SWISE incentives.

The current thinking and approach is precisely one of gas optimization. Automation would still need to be based on the process of claiming rETH2, $SWISE and others, so having a strong foundation is a must.

The way we see it at the moment is that users should be able to decide when to pull rETH2 and/or $SWISE from gauges/contracts, and let them preserve anything that their capital accrues until the moment they’re ready to pull the trigger. Also, we want to make claims efficient, so that with one light transaction, a user could pull multiple tokens at once. The ‘novel rETH2 distribution method’ listed in the pipeline aims to achieve precisely that.

On your last point:

Would it require deploying new contracts, would that be able to be a one time thing, and are either of these less gas intensive than the vaults mentioned in the original post?

Vaults by definition will be much more gas-efficient, but that doesn’t mean we shouldn’t work on making the farming & claims process as gas efficient as possible. These go hand in hand :slight_smile:

Awesome discussion here guys - thank you @George and @Sebastian_Bach. I am looking forward to hearing more thoughts on the matter from others!

3 Likes
6

I’ll disclaim that I don’t know much about tokenomics, but I do have some concerns about the implementation of the incentives for the liquidity pool.

The deflationary nature of the governance coin would be disseminated into the market in a logarithmic curve. This strongly encourages earlier-movers. I support incentives for the liquidity pool, but I don’t think there should be such a (in my opinion) egregious bias towards the first-comers. (Despite my own interest) With a fixed percentage used as an incentive, I think this would effectively cater exclusively to the older generations as times progress. This is also affected by compound interest, therefore the earlier comers will run-away with the voting pool.

I think a better incentive model might entail more varied incentive models or a hybrid of fixed + flat incentives.
Though I have no idea how set in stone much of this already is. I think there are two competing interest for the competitiveness of the industry to confront. “First Come First Serve” innate Greediness will encourage immediate and self-interested adoptions; people will be compelled to get on the bandwagon as their influence will have the most effect as time goes on. The opposing side would be by ensuring that the market place fosters adoption in the short and long term; if newcomers find that the system is stacked against them, they will be compelled to overthrow the system or create another that is better situated for their own self interest. (As an American, this is quite evident in recent and distant historical events)

So the conflict arises: Cater to earlier adopters with biased incentives (deflationary $SWISE tokens; @fixed distribution rates) vs Foster newcomer adoption (inflationary or reflationary $SWISE tokens; @hybrid/varied distribution rates)

I won’t get into how reflationary tokenomics would work, but essentially it would to some degree enable wealth redistribution methods.

Regardless Liquidity pools should be incentivized and done so in a streamlined/integrated manor.

3 Likes
7

Wow.

First, hats off to you for such a deep and insightful analysis. It is comments like these that really push the boundaries of decentralized governance and inform a fruitful discussion. Incredible.

Second, I think you make a very valid point and I agree with you regarding the governance outcomes of the various inflation/distribution mechanisms. It is akin to drafting a fiscal policy, really, where principles of $SWISE distribution can be considered the principles of welfare. I believe there is scope for a hybrid approach, where at different development stages of the protocol we employ different distribution methods.

Example: initially, incentivize rapid adoption on a “First Come First Serve” basis, allowing some users to build larger positions of the token and have more say in governance. At the later stages, shift the distribution principles to add more “inclusive” mechanisms e.g. participation-based programs, programs with exclusive access, caps on holdings etc.

Funnily enough, I think some sort of a wealth tax would be the easiest solution for balancing the interests of small $SWISE holders against the people with huge bags of it. But how justified will a wealth tax be if $SWISE can be bought on the market? I don’t know. What about adding a parameter that adjusts the weight of a vote by the number of people who chose to vote for that option? What could this parameter be? The rabbit hole gets deeper…

In general, the topic of “fairness” in distribution could become hotly debated, for the same reasons the traditional party lines between the Republicans and the Democrats exist. Voters have different opinions about what a fair approach to the distribution should look like, and are likely to clash over personal versions of truth even if it is somewhere in the middle.

The difficulty of achieving outcomes that everyone would consider “fair” is hard to overstate. I am 100% sure that the DAO cannot be fair to everyone, so instead it could optimize for a parameter like TVL, the # of users, token price etc. - something that most users could objectively research, quantify and agree on. This could offer somewhat of a way forward, but wouldn’t be a panacea.

So the bottom line: no mechanism is perfect, and achieving consensus on what the protocol needs the most at any given moment in time is the only way to maximize the buy-in from the $SWISE holders. Happy to work on a framework for this in the near future.

4 Likes
8

What not simply accrue a claimable amount of Swise on a daily or weekly basis for all the rETH2 an address holds? The way Balancer does for LP providers.

This avonds a lot of transaction and fees.

3 Likes