Tokenomics Rework Update 1 - New Explainers!

Hi all, the core tokenomics contributors wanted to give a brief update of where we’re at with the tokenomics work, share some of the new content, and lay out some ways in which you can help support the effort. Previous threads on the topic can be found here.

Where are we at?

We’ve been following the rough steps here for the last couple of weeks, and just completed step 3 by releasing the explainer documents.

That leaves two steps that we’ll be actively working on for the next little while:

  • Seek feedback from technically skilled or highly engaged community members on the draft specifications.

  • Make a concerted effort to gather feedback via the forum from the wider community.

So we’re moving into a phase dedicated to gathering feedback. We want to confirm the general direction is good, hone the specifications and make the high level explainers as clear as possible.

If you’d like to keep track of progress, this section of RPIP-49 is kept up to date, as is this todo list. We’ll post major updates here on the forum too, and you can subscribe to these via RSS.

New Tokenomics Explainers

We’re happy to present an expanded information and overview section on the tokenomics landing page.

The new pages cover the reasoning behind and contents of the tokenomics update at different levels of depth, with the goal that there’s something easy for everyone to engage with regardless of their level of knowledge and available time.

A huge thank you to those that contributed content and feedback to these documents.

How can you help us?

Right now, we’re focused on feedback in the following three areas.

Meta Feedback on Explainers

Now that the explainers are out, we’d really love feedback from the actual audience:

  • Is anything unclear, explained badly, or misleading?

  • Does the ‘reading order’ hold up? Do you have enough of a foundation from the previous sections to continue understanding things? Does anything feel like a surprise curveball?

  • Is the formatting clear? Could this look prettier or more inviting, etc?

If you’re reading the explainers, then you can help us here, no matter your previous level of engagement with the process or the community. Leave a comment on this forum thread, or on discord.

Specification Feedback

We are hoping to receive more feedback from the technical or structurally minded members of the community on the RPIP specification sections. Any improvements we can make here to clarity, completeness, and comprehension will help the core team at the implementation stage and help to ensure that the behavior of the upgraded protocol best serves all stakeholders.

We’ve put together a short document explaining how to contribute usefully that you can find here. It includes links to the working branch of the specs, suggestions on how to provide feedback and should cover everything you need to just sit down with the content.

General Content Feedback

Finally, if you have feedback on the rework itself and its contents - now is the time! If we can hear more concerns, excitements, and thoughts, then we can make this rework as successful as possible for everyone.

On a more personal note, wider engagement with this - whether positive or negative - is a huge boost to our motivation. This includes everything from a small celebratory comment to a critical essay – it’s much nicer to work on something that clearly matters to the community.

You can leave comments on this forum thread, or reach us in the discord thread.

Thanks for reading!

12 Likes

To help us get a sense of where everyone is, we’d really appreciate it if you voted in the informal polls below. Note that the results are public so we can cross-reference the responses.

How deep are you into the topic?

  • I’ve not read anything.
  • I’ve read explainers 1 and 2
  • I’ve read explainers 3 and 4
  • I’ve read the RPIP drafts
0 voters

How well would you say you understand the rework?

  • Low level of understanding
  • Medium level of understanding
  • High level of understanding
0 voters

If you’re struggling to get a grip on this after reading the first pair of explainers it’s more likely to be our fault than yours. We want to hear from you, either in the thread, or via DM.


How are you feeling about the rework?

(this is not a formal sentiment check that can trigger a snapshot vote)

  • Very positive
  • Fairly positive
  • Neutral
  • Fairly against (please comment)
  • Very against (please comment)
0 voters
4 Likes

I feel strongly that the work that has been done here is of high quality, and that the authors deserve high praise for their work in preparing it. Lurking on Discord I’ve followed only a small part of the discussions that went into it, but even so I felt that the level of detail as well as the arguments were extensive and thorough.

I think the suggested changes are excellent and I very much look forward to a vote. :partying_face:

While I’ve followed RP for a while and have a high-level understanding of the protocol, I’m not a coder nor do I consider myself to be an expert. Still, I think it would be good if the explainers were understandable for someone like me, so I’ve just read through them to gauge if I could follow. Generally: yes!

I have the following questions and/or suggestions:

  • In ‘Why Rework’, I read “However, this solution would also reduce the RPL to rETH TVL relationship per Ideal 3, which means that the cost to avoiding this brittleness is letting go of a relationship that can be known ahead of time.” This I don’t follow. Why does it matter that the relationship is ‘known ahead of time’?

  • The ‘Introduction to the Tokenomics Rework’ feels a bit jarring and out of place. Whereas the (historical) narrative on the previous page was smooth, and the reader is nicely taken by the hand on the next (‘foundation’), this page seems be a bit ‘raw’. I think it could be improved by adding a brief paragraph at the top, with something like ‘Given the issues described on the previous page, we now propose a thorough rework of RPL’s tokenomics. These proposals have risen out of extensive discussions involving many members of the community and core teams over many months [possibly with some links, including to Samus and Val’s presentation?]. The proposals not only directly address issues with the current RPL tokenomics, but also include changes that will benefit the Rocket Pool protocol as a whole. As such we are aiming at both an increase of the value and use of Rocket Pool as a protocol, as well as driving new value to the RPL token, ensuring the protocol’s longevity.’

  • On the ‘Foundation’, I read “Importantly this revenue grows with rETH TVL”. I know that the phrase ‘rETH TVL’ is used often (many times throughout these docs), but shouldn’t that technically be either ‘ETH TVL’ or ‘rETH supply’? It’s not really the rETH that’s locked in the protocol right? Rather the opposite, it being an LST and all :).

  • Same page, in the bullet on Surplus Share: “where growth would allow the same supply of total RPL to earn more ETH.” → while we’re talking about distibuting part of the ETH rewards, doing so as a buy/burn means that ‘earn more ETH’ is not quite what’s happening here for RPL-holders, right? It’s more that it ‘allows the same supply of total RPL (staked or not) to [capture more value][increase in value versus ETH more]’ .

  • Same page, in the explanation above figure 1: “Their ETH earns from the 3.5% Node Operator Commission Share”. Narrative-wise this is a bit jarring: what do you mean ‘the 3.5%’? That number is new; new readers of these explainers likely / possibly won’t have read the RPIPs yet. Perhaps link to the RPIT somewhere earlier in this text? Or easier: rewrite to something like ‘Their ETH earns from the Node Operator Commission Share, which in the current proposal is 3.5%’. Same point for the other percentages here, they just ‘suddenly appear’ to those not familiar with the RPIPs.

  • Same page: “RPL holders are incentivized to maximize something along the lines of surplus_share * rETH_TVL. This means voters generally have an incentive to balance a high surplus_share with making rETH holding attractive.” In layman’s terms, what is the rationale for the protocol to have the Surplus Share for RPL holders? It’s not compensation for governance, because that is (besides being able to govern) the Voter Share. Wouldn’t a Surplus Share of 0 allow more value to flow to rETH holders, and aren’t they the point? Why not get rid of the Surplus Share, or… add it to the Voter Share? That would provide an even bigger incentive for NOs to stake (and vote with!) RPL, rather than awarding ‘naked’ speculation on RPL. It also wouldn’t harm the inflation to the DAO, right? Also: if only staked RPL can vote, wouldn’t it be in the DAO’s immediate interest to set Surplus Share to 0, and send all of it to Voter Share? Why would holders of staked RPL vote to give any protocol revenue to holders of unstaked RPL? What are they doing for the protocol?

    Only if the Surplus would be used for LPing, I can see some value for the protocol, but simply burn benefits all RPL-holders, whereas only those who stake RPL (and create value to the protocol) will have control over the revenue split - why would they share with speculators?

    Haha, only now did I get to the bottom of the page where sending Surplus to Voter is precicely one of the options considered. Count me in favor of that, I suppose, although I would like to better understand what ‘much smaller total addressable market’ means as a negative. Less people interested in speculating on RPL? I mean yeah, 'cause all value would be going to NOs. But perhaps NOs could benefit from speculators driving up price? Why do we want the protocol to extract value from them, introducing volatility?

  • On ‘Supporting components’: Node level penalties re-introduce a reason for sock puppeting, right? If you aim to steal MEV, you’d be running separate nodes with one/few minipools. Eat the added gas costs and lower bond efficiency in return for ‘getting to steal’?

  • I love the Express Queue. Suggestion to rewrite the sentencences “To favor small NOs … 4-ETH bond validators).” to “To favor small NOs, only two express queue tickets will be given to new NOs. Existing NOs will be given enough enough tickets to allow for express migration of all bonded ETH to 4-ETH bond validators.”

  • The Glossary is missing a definition of ‘sock puppeting’ :wink:.

Hurrah for all of this - go go DAO! :smile:

5 Likes

On it! Any other requests?

2 Likes

Just read through the complete tokenomics landing page. You guys have done an amazing job both on the different RPIPs and on explaining them in a way that abstracts a lot of the technicality away without compromising too much.

I’m glad we didn’t outsource the rework; we would have never gotten anything close to the diligence and passion that went into this.

I don’t have anything technical to add at this point. I’m excited to see how the discussion on the value capture options turns out.

Again, amazing job, guys. That read gave me an itch to stock up on RPL, and that is a hard sell after the last year.

5 Likes

I’ve read the tokenomics explainer multiple times now, and I think it’s excellent. Great job everyone involved. I’m excited to vote on this.

3 Likes

Count me in favor of that, I suppose, although I would like to better understand what ‘much smaller total addressable market’ means as a negative. Less people interested in speculating on RPL? I mean yeah, 'cause all value would be going to NOs. But perhaps NOs could benefit from speculators driving up price? Why do we want the protocol to extract value from them, introducing volatility?

This point was addressed by Valdorff here: Discord

1 Like

Quick note that we’ve moved active work into this branch. Nothing major to report, just that if you were looking to do specification feedback, double check that you’re looking at the correct branch. The templates and links have been updated to reflect this.

2 Likes

We at 1kx appreciate the community’s initiative to improve Rocket Pool’s positioning in the staking landscape and wanted to share some thoughts on the proposals highlighted above.

We believe that proceeding with select proposed RPIPs will allow the protocol to scale effectively without compromising security and decentralization:

  • RPIP-42 and -44: Both allow for greater node operator capital efficiency which has been shown to greatly help scale TVL in the past, and forced exits allow Rocket Pool to remove malicious or inactive node operators that would be hampering protocol performance
  • RPIP-43: This upgrade helps with gas efficiencies for node operators, which drives down supply-side costs and improves margins
  • RPIP-46: We are excited about an adjustable and programmatic splitting function that distributes to various targets depending on protocol conditions and is managed actively by pDAO. For example, when the supply side acts as the bottleneck for more TVL, and there is a deposit queue, commissions can be increased to entice new or existing operators. We are also fully in support of reducing RPL issuance from 5% to 1.5%

Certain other proposals and aspects require careful community evaluation, as their cost-benefit dynamics are far more complex and necessitate thoughtful decision-making.

The Universal Adjustable Revenue Split (RPIP-46) will be a critical new protocol component and deciding how to balance rETH commissions has many implications. In addition to evidently directing revenue to node operators and rETH holders, the initiatives surrounding RPL Burn and RPL Buy & LP warrant deeper discussion. Regarding the former (RPL Burn), we have concerns due to the poor track record observed in the web3 space for similar implementations. Some previous examples include:

  • DXD: The DAO implemented a buyback and burn strategy and acquired 30% of the entire supply costing $8 million in ETH over a 16-month span. The protocol ultimately suspended the program and subsequently established a working group to establish a different path forward. A few years later, the token is down more than 45% since the program stopped.

  • MakerDAO: Maker burned 2.78% of its supply over the course of 16 months between November 2020 and February 2022 but, despite doing so, underperformed index assets like ETH throughout that time. The total spend was $55.8 million, which is multiples larger than what Rocket Pool would potentially burn in one year. Please see a chart of $MKR’s price vs $ETH during the time of burn.

  • Nexus Mutual: The DAO spent 8,000 ETH or $36 million at the time to try to help WNXM, a liquid version of NXM, trade at 1:1 parity. The buyback was executed between December 2021 and January 2022. One year after the buyback was completed, the initiative never came close to reaching its goal. In fact, for five months after the program, the WNXM to NXM ratio actually reached all-time lows and did not spend any considerable time above 50%, which is what the ratio was before the buyback program.

We would be excited to discuss any positive examples that the community presents where the burn mechanism has brought forth meaningful benefits to a protocol. In addition to poor web3 case studies, we are wary of implementing buyback and burn for a few reasons related to Rocket Pool’s current state:

  1. This proposal is effectively equivalent to share buybacks in web2, which are often performed for very mature companies looking to return capital or “value” to shareholders. We believe that Rocket Pool has plenty of room to grow, especially considering its market share compared to other liquid staking protocols and the 22% self-limit rule.
  2. A buyback program might be more impactful when TVL has grown many multiples from here, as the immediate implementation of a buyback and burn would have little effect on the token price: the proposed burn portion, based on current TVL and ETH yields over a full year, is only equal to about 1 day of RPL trading volume or 1% of the $RPL market cap. Protocol ETH should be used to fund future product and adoption initiatives.
  3. Buybacks are also used to temporarily prop up share price. There may be some perceived benefits to this, such as increased morale in the community, attention from outsiders, and ultimately speculative capital, but the key point is that this mainly benefits short-term mercenaries who are unaligned with the ecosystem instead of those who are long-term aligned.
  4. Burning $RPL benefits everyone in the ecosystem equally, including those who do not actively contribute to the ecosystem. In other words, burns attempt to capture value when the protocol should be trying to create value, such as by increasing TVL. The main way to create TVL is to give resources to those who are pushing the protocol forward, such as node operators or those doing active BD with new staking partners. Allocating resources to these types of participants is especially important in growth mode.

One thoughtful alternative proposal to burning $RPL is providing liquidity alongside rETH in a 90/10 Balancer pool. This would create deeper liquidity for the $RPL token and can help reduce the overall cost that node operators pay when they are newly purchasing or re-upping $RPL collateral. However, we remain cautious that this would be the best use of funds for a few reasons:

  1. The additional revenue surplus directed to this 90/10 liquidity pool is not significant enough to drive net new demand for rETH or RPL because all other things equal, there are other liquid staking solutions that will always have deeper liquidity on both their LST product and native token. If users really valued liquidity depth as their number one priority, they would have left the Rocket Pool ecosystem regardless of whether the 90/10 pool was slightly deeper. Increasing the TVL of this pool by a few million dollars will not entice a current Coinbase or Lido user to switch their ETH over to Rocket Pool, nor will it meaningfully affect a new ETH holder’s decision to stake with Rocket Pool.
  2. Although this proposal would help improve the user experience incrementally through improved swapping rates, directing revenue towards growth initiatives can eventually deepen liquidity organically due to the natural PMF flywheel, where more adoption leads to more swaps, LP fees, and, therefore, liquidity.
  3. We expect that once $RPL delegation is implemented, operators will use this method to create new validators rather than acquiring $RPL on the open market, thus lessening the value proposition for them. Moreover, deeper $RPL liquidity does not significantly affect an average rETH holder’s experience.

Additionally, we believe that the potential removal of the $RPL collateral requirement should be further discussed and considered. Although there is certainly friction that a node operator undergoes in order to acquire $RPL, and we have talked to several node operators who will not touch the ecosystem because they do not want $RPL price exposure, but there are several positives about this collateral requirement. It attributes intrinsic value to the token, which in turn helps the ecosystem thrive. Moreover, staking is the most proven and best-known token sink in the space and we shouldn’t be shying away from an innovative solution that Rocket Pool as a protocol originally pioneered.

Rocket Pool consistently trades at a premium compared to competing protocol tokens due to this token sink – almost double the [Market Cap / TVL] ratio as players such as Lido, Stakewise, Stader, and Marinade. We believe it would completely disappear if the $RPL requirement was removed. Some considerations:

  1. Without the $RPL collateral requirement, the incentive to hold $RPL is weakened, which decreases the buy-in of those invested in Rocket Pool’s health.
  2. We believe that delegation will solve all the problems surrounding $RPL friction for node operators. Delegation allows $RPL holders, whether it be institutional investors or community members, to earn active yield on their holdings in addition to price upside. This replaces the need for node operators to buy or hold $RPL themselves. A delegation marketplace can emerge, enabling competitive dynamics around $RPL staker and node operator commission splits.

We are excited about many of the proposals being presented and look forward to engaging in more in-depth discussions on the more contentious elements.

To aid these detailed discussions, we are currently preparing several new mechanisms that can be integrated into these proposals and are excited to hear the community’s feedback.

It’s crucial to recognize that conversations within the Rocket Pool community don’t frequently reach the wider ecosystem. One of the main aims of our soon-to-be-presented mechanisms is to boost Rocket Pool’s rETH branding in the crypto space, thereby promoting broader adoption.

15 Likes

Hi @mikey – thanks for the thoughtful take!

My first thought is that your core premise isn’t fully considered throughout your response. Its benefits are counted and its drawbacks are not mentioned or ignored.

We believe that delegation will solve all the problems surrounding $RPL friction for node operators. Delegation allows $RPL holders, whether it be institutional investors or community members, to earn active yield on their holdings in addition to price upside.

There’s a few implications to get here. We need a highly efficient matching market; this is doable and we can expect the protocol solving it to have a fee for their work. We need a way to exit stake, which might be locked. This probably looks like forced exits (not so desirable as the NO), and/or a liquid wrapper; again, the protocol that makes these mechanisms should be expected to take a fee (and a liquid wrapper would require liquidity mining, with participants there taking a fee). Note that forced exits would damage protocol TVL – ie, if lots of folks want out of RPL, then all of RP is damaged. If this works smoothly, it’s fine. But do note that it has significant costs and relies on new services cropping up to make the core protocol viable. Also keep in mind that such a service could be quite centralizing (if people pick where to delegate, it’ll likely go to a known name, not a random NO – see stakewise, eigenlayer, any cosmos chain, RP’s vote delegation, etc).

staking is the most proven and best-known token sink in the space and we shouldn’t be shying away from an innovative solution that Rocket Pool as a protocol originally pioneered

This doesn’t really fly with the premise of a highly efficient liquid delegation market. If I give 10 units of RPL and can get them back whenever to sell, how are they more sunk than sitting in my wallet? I don’t believe they are. Insofar as they are less sunk (eg, some kind of withdrawal time) then the delegation market has friction. These are directly correlated, so we cannot count both benefits.

Burning $RPL benefits everyone in the ecosystem equally, including those who do not actively contribute to the ecosystem.

This also doesn’t fly with the premise of a highly efficient liquid delegation market. How am I more “actively contributing” by delegating something I can undelegate when I wish vs having a token sit in my wallet? I would go so far as to argue that this damages the power of active contributors since vote power would accrue to folks that are unwilling to hold RPL.

Without the $RPL collateral requirement, the incentive to hold $RPL is weakened, which decreases the buy-in of those invested in Rocket Pool’s health.

Let’s do a quick thought experiment, where everyone is at 10% borrowed value of RPL staked either with the current structure or the variant where all surplus_share is directed to vote-eligible RPL. In this case, everyone would get the same amount of ETH under either system. There might be tiny variations because the voter_share component is socialized instead of being linked with one’s own validators. (I’ll address voter_share vs burn vs LP elsewehere – wanted to use the most straightforward comparison here).

Now let’s change something. Let’s allow some ETH-only operators with the new tokenomics. This additional growth gives the RPL-holding operators more ETH. In other words, the incentive to hold staked RPL is at least the same (everyone has the same relative stake) or better (some people have lower or no stake).

the initiatives surrounding RPL Burn and RPL Buy & LP warrant deeper discussion

Agreed. This is needed for steps 6-8 in https://rpips.rocketpool.net/RPIPs/RPIP-49#estimated-process. The core team has asked for legal review and we think the pDAO can better opine once that comes back. We don’t think we need to block work for that (in fact, the RPIPs allow Saturn 1 to be released with a temporary holding destination for that “surplus_share”).

Importantly, there are three suggested choices, and your discussion only speaks to two of them. Fwiw, in my eyes they are all “pretty similar”. I have preferences for LP/burn/voter_share in that order, but not super strong preferences.

Rocket Pool consistently trades at a premium compared to competing protocol tokens due to this token sink – almost double the [Market Cap / TVL] ratio as players such as Lido, Stakewise, Stader, and Marinade.

I agree that it trades at a premium, I wholly disagree with why. The market is forward-pricing. Right now Lido sits at 28.7% marketshare and RP at 2.3%. At the numbers you gave, it just prices in something like 28.7%/4.2%, 35%/5.1%, etc. I’m not sure what evidence would look like for “the token sink is the cause”, but none has been provided.

Burn/LP discussion

One repeating pattern I’ve seen when discussing burn is that people want the absolute number to do something. Burn’s effect should be relative, not absolute. If it would be flat without burn, it’ll be slightly positive with burn. If the market would have gone down x amount without burn, it’ll go down <x. If it would go up y amount without burn, it’ll go up more than y amount.

Next let’s talk about effect size. In the current context, we’re talking about 1750 ETH per year going to RPL, which amounts to a bit over 1% gain/yr. This means if the market would move down 5%, we might move down 4%. If it would move up 5%, we might move up 6%. This will not be stronger than market speculation, especially on short time scales. We just saw the token move nearly 100% in 2 hours, I think it’d be hard to find a single week without 10% variation between the week’s high and low, etc. I think this is the core point for your examples – showing a downtrend or an uptrend on a token using burn doesn’t demonstrate much because other effects are very often going to dominate the overall impact. That doesn’t mean that the relative impact wasn’t there, just that it’s swamped. That said, it can still be real: going up 5% and getting 1% as ETH puts you in the same spot as going up 6% and getting no ETH.

I do realize that this means that burn/LP methods are only grounded in theory. I believe in them and think the additional addressable market is a strong benefit. But I respect not buying that theory translates to practice. In that case I’d suggest advocating for the 3rd option that’s explicitly on the table, which is simply subsuming surplus_share into voter_share.

This proposal is effectively equivalent to share buybacks in web2, which are often performed for very mature companies looking to return capital or “value” to shareholders. We believe that Rocket Pool has plenty of room to grow, especially considering its market share compared to other liquid staking protocols and the 22% self-limit rule.

A key thing here is that our protocol isn’t a company. I don’t believe we have any intent to make a next product, pivot to a new field, etc. It’s not about “will it grow?”, it’s about “can we spend money to help it grow sustainably?” That question isn’t so clear to me, but I think it’s somewhat likely. My hope is that the rework addresses the NO supply side very well, and then we need to work on rETH demand. I do think spending on awareness and some defi partnerships is likely to have good ROI there and we should do that. I’d happily vote to either reduce surplus_share or increase RPL inflation to fund that sort of thing.

One of the main aims of our soon-to-be-presented mechanisms is to boost Rocket Pool’s rETH branding in the crypto space, thereby promoting broader adoption.

:muscle: That sounds exciting. In general, I appreciate that you brought up rETH holders multiple times in the post – they are really our lifeblood and I don’t think they get as much attention as they should.

2 Likes

Hey there, so I’m working to organize the community effort on the tokenomics rework. I’m mostly just commenting here to communicate some ways to integrate these ideas into the work so far.

To give you an idea of where we are at the moment, the proposals are mostly written and are undergoing review and feedback changes. Contributors are mostly aligned on the core contents (value-capture excluded) and we’ve been coalescing on a soft goal to get a sentiment vote on the core set by 8th July.

While I think contributors would be willing to make fundamental changes to the proposals if convinced that there were favourable alternatives, there is a fair amount of momentum behind what we have now.

So with that in mind, I see a few paths forward for changes to core RPIPs (which I’m assuming your suggestions would require, given the argument in favour of retaining staking.)

Path 1 - 1kx posts a forum post describing their alternatives and their involvement ends at ‘what about this instead?’

  • The advantage here is obviously that its fairly low-commitment for you all in terms of time and effort.
  • The disadvantage is that I think you will need some very compelling, well thought out, and well-evidenced arguments to convince everyone involved to change direction at this point, and that would likely push back our rough timeline.

Path 2 - 1kx writes formal proposals (RPIPs) including their alternatives and has them completed on approximately the same timeline.

  • Advantage here is that they can be presented for sentiment vote alongside the community proposals and we can get a quantified signal of what the community wants, and that can set the direction going forwards.
  • Main disadvantage is that good RPIPs are a lot of work. The timeline is tight for completing alternatives, so they would need to be fast-tracked, or we would have to push back the timeline on sentiment voting.

Path 3 - We continue on the current timeline, and explicitly ask the community to vote against in any sentiment polls if they wish to see 1kx’s ideas integrated into the community proposal.

  • Advantage to this is that it’s the least disruptive in terms of current plans.
  • Disadvantage is that someone will need to do a lot of rework on already-polished proposals to integrate any major changes at that point. (Either community contributors or 1kx.)

Hopefully this comes across as collaborative by virtue of proposing solutions. That’s the intention. I’m attempting to walk the line between:

‘a lot of effort and thought has been sunk into what we have now’

and

‘we all want to propose the best possible rework, and if you have something better, we want to know.’

2 Likes

I already posted this on Discord, but thank you for putting this together! Very helpful context.

1 Like

Appreciate the perspective and feedback!!

It seems like the bulk of your concerns are centered around buy+burn or LP deposits, just wanted to add to Val’s comments, here is some additional context on the “surplus revenue” decision/discussion that definitely still needs more attention: Tokenomic Rework Vibe Check: Surplus Revenue Redistribution

Based on your feedback I suspect you would prefer the “voter share” option, but I’m curious if you have any thoughts on the “voter share” specifically? I didn’t see any mention of it in your feedback.

I think “voter share” also relates to the RPL collateral requirement concern you brought up. I’d look forward to hearing more thoughts on this, but I also wanted to share my perspective as this topic came up previously with NodeSet (a slightly longer version of my response to this same topic can be found here): Discord.

For simplicity, maybe assume the surplus revenue decision ends up leading to only a “voter share” and no “surplus share”. When comparing “voter share” vs an RPL collateral requirement, I think the implementations roughly converge at maturity but “voter share” seems to provide more value and sustainability.

Let’s consider a mature state where you remove RPL issuance to NO’s (which you seem to be in favor of). As an example, picture a relatively static Node Operator set with Rocket Pool near it’s self limit of 22%:

  • The RPL bond is really more like a “security deposit”
    • Node Operators could meet the RPL stake requirement at initialization and then never top off again but continue to earn ETH yields in perpetuity (despite any RPL/ETH ratio changes)
    • There would be very little “new” purchases of RPL since everyone already met the one time RPL collateralization requirement at initialization.
    • If a Node Operator does decide to exit they still own their “security deposit” of RPL, which they could sell after exiting since they maintain ownership of those tokens.

In that scenario, I don’t think RPL really captures any value. The only way I could see it possible for an RPL requirement to have a sustainable “value capture” mechanism in perpetuity is to enforce the collateralization ratio by reducing ETH commissions proportional to your RPL collateralization. At this point though the ideas really begin to converge with the tokenomics proposal since you are basically enforcing some consistent % of ETH commission to be directed to RPL (you just give NOs the choice for when they should swap their ETH commission to buy RPL). This has the downsides of being unpredictable both for NOs and for the protocol (vs the tokenomics proposal where the protocol predictably/consistently directs a set percentage of revenue to RPL).

Another challenge with enforcing an RPL requirement is you have to “guess” the correct RPL exposure requirement, and assume all NOs are ok with it. This forces a binary:

  • “I’m ok with RP’s chosen exposure requirement, so I’ll be a NO”
  • “I’m not ok with RP’s chosen exposure requirement, so I won’t be a NO”

That binary can end up excluding participants who fit under the second bullet point, and may have otherwise contributed value to Rocket Pool’s growth and success. Instead, with a voter share, these contributors can have competitive, predictable rewards (even as an ETH-only Node Operator), while simultaneously providing real ETH yield revenue to the protocol, including those who do choose to stake RPL. With a voter share, we also don’t have to “guess” the correct RPL collateral/exposure to target, and can instead listen to the market as Node Operators are free to stake any amount of RPL they feel comfortable with.

In addition to the “voter_share” vs RPL requirement conversation, I think it would be really valuable to have your continued input in the “surplus revenue” decision as further research and discussion is definitely warranted. I think a world with “voter share” and no RPL issuance to NOs could still include a healthy amount of RPL staking delegation since there may very well be parties interested in earning additional ETH yields on their RPL principal through the “voter share” mechanism. I would think those rewards would even be more attractive than the alternative status quo of only RPL issuance yield on their RPL principal (especially if no value is directed to “unstaked RPL” and the total amount of RPL staked trends toward 100% leading to no real yield).

I’m optimistic that with our proposal the days of Node Operator supply as a bottleneck will be behind us, and we can focus on growing rETH demand. That would be an exciting time for Rocket Pool and assistance with boosting rETH’s brand and adoption will be greatly appreciated!

Thank you Valdorff, your thoughts are greatly appreciated, and you bring up some really important points! We wanted to follow up on a few things:

NodeSet is already working on a liquid wrapper that could be quite suitable for this new delegation product. In terms of negative implications, we agree that a sudden rush out of RPL might be challenging to handle. However, we believe that creating an incentive mechanism to ensure sufficient collateral at all times, as well as a thoughtful forced exit mechanism for the delegation system, is attainable. We’ll share more soon.

We acknowledge the significant costs involved in implementing a delegation system. However, we believe it is a worthwhile investment as it shifts the burden of RPL price risk from the node operator, who may not want it, to a party that is interested in the potential gains of the protocol token.

Tokens are more sunk because of a) withdrawal period and b) yield-seekers. Currently, there is no strong reason for non-stakers and non-speculators to hold RPL. Delegation introduces a new reason to hold RPL, which brings new buy-side demand, which moves RPL off of the market and into the delegation contract.

Staking would necessarily have a withdrawal time so RPL can be slashed. This could operate on the same 28-day cadence used in current RPL staking.

By delegating to an NO, you are not just making a choice but also signaling your preferences. You might prioritize decentralization and delegate to a smaller NO with a non-cloud setup, or you might prioritize rewards and delegate to the NO with the best performance regardless of setup. In either case, your active contribution to the future shape of the network is invaluable and something a passive holder would not be able to do.

This is true only for existing holders/NOs. The incentive for new NOs to hold RPL is removed or reduced. This has pros and cons but should not be ignored, especially as whale marriages already facilitate onboarding a NO with no direct RPL exposure.

We argue that the RPL price does not trade at a premium due to relatively stronger forward-looking sentiment compared to its competitors for several reasons:

  • In February 2023, MC/TVL ratio peaked at 0.91 and has dropped 90% to ~0.09 today despite the explosion in TVL. If forward-looking sentiment was ever reflected in the price, it has mainly disappeared by now. Rocket Pool’s ratio dropped the most compared to other competitors since February 2023, yet still trades at a higher than 2x premium
  • Lido definitely has at least some unique forward-looking sentiment priced in, considering its close ties to the new EigenLayer competitor Symbiotic and potential value capture in the LRT category. This area is one that Rocket Pool has not pursued or expressed outward interest in pursuing
  • Lido has also built a permissionless liquid staking framework that is poised to capture some market share from competitors, including Rocket Pool. Yet, RPL MC/TVL ratio almost doubles Lido’s
  • The liquid staking space, in general, has seen plenty of innovation from competitors, such as baked-in distributed validator technology, new DeFi mechanisms, and verticalization into restaking. It is reasonable to assume that Rocket Pool’s forward-looking sentiment has been at least partially diluted by an increasingly competitive market, yet we still trade significantly above our peers at the moment

I am very glad we are aligned here. There are plenty of opportunities to sustainably increase market share by pursuing old and new stakers.

Excited to hear your thoughts on our newly proposed mechanisms. We’ll try to get that out this week.

1 Like

Hey samus, really appreciate the reply! Here are some of our thoughts below:

While we need to be forward-thinking and ensure our solution meets Rocket Pool’s needs in the short and long term, we should also base our decisions on the situation as it is today rather than on a hypothetical future.

We have a slightly differing opinion. Requiring a certain amount of RPL collateral when adding a validator is a simple and effective mechanism for increasing the demand of RPL.

This might be true in the hypothetical future scenario where Rocket Pool has reached its self-limit of 22% and has a stable NO set. But until that point is reached, requiring NOs to stake RPL would lead to new purchases of RPL (so long as being an NO is more profitable than solo staking).

This statement applies to all proposals that change tokenomics or protocol parameters. One could argue that the existing proposal contains a number of “guesses” as to the correct values for surplus share, voter share, etc. But to call these “guesses” is unfair to the deep analysis performed by Valdorff and so many others. Our goal is to create a requirement that satisfies node operators while considering overall protocol implications.

Prior to Houston, this was indeed the case. Post-Houston it presents a false dichotomy. The choices are now:

“I’m ok with RP’s chosen exposure requirement, so I’ll be a NO”

“I’m not ok with RP’s chosen exposure requirement (or otherwise do not want RPL exposure), so I’ll be an NO with NodeSet or a whale marriage”

While we understand why the term “surplus revenue” was chosen it is important to remain aware that this “surplus” is actually taken from NOs or rETH yield. If we use “surplus revenue” to make RPL more attractive we are doing so at the expense of rETH APY. A core part of our new suggestions is to move that “surplus revenue” to rETH APY; we’ll share more later.

This is part of our motivation to present a modification to the current proposal. We believe that the changes shipped with Houston are key to removing the NO supply bottleneck. These changes have just been shipped, and there has not been sufficient opportunity to assess their impact.

Thank you for reading and look forward to hearing your feedback in the coming week.

Hitting many of the points in the reply to me:

Under the current tokenomics, at maturity, there are no potential gains for the protocol token. It is a cost center by definition. It gets no revenue flow and it has supply inflation.

This style will only function while there is speculation about significant growth. At that point, there is no reason to hold the token if you’re not getting the boosted ETH gains from running a node.

If you mean under the modified proposal that you plan to publish, obviously I can’t respond to that as it doesn’t exist at this time.

It sounds like you’re comparing against “do no tokenomics rework”… this is a tokenomics rework thread. The reason is for revenue, distributed via asymmetric buying (for Burn or LP). For the voter_share variant, it explicitly prefers not to give any share to nonstakers (and would almost certainly lead to a delegated wrapper etc at some point).

Let’s not pretend we have no data on how this goes. We can look at Cosmos, at SSV, at eigenlayer, etc. Delegation gets dominated by small centralized parties and I am aware of zero counterexamples.

None of the bullets provided differentiate between forward-looking expectations and the locking mechanism in any way. They are a series of outcomes, but don’t point to any causality. Fwiw, a simple reason higher expectations are possible for RPL vs LDO is that LDO cannot get 4x market share because that’s more than 100% of market share. Non-lido competition has been scant to date (see https://twitter.com/blockworksres/status/1803457302181404785 eg). Also importantly, lots of pricing has been narrative driven and I don’t think it’s had much to do with fundamentals.


Also responding to one point from the reply to samus:

It’s completely fair, and samus has been one of the most active contributors. We try to model stuff, but I believe that (a) we disagree a lot even among contributors, (b) we’re probably all wrong, and (c) things change. The key thing with the proposed tokenomics rework is that we gain the ability to adapt more easily. Ie, we are not locked into our guesses nearly as much and are able to listen/adapt to the market.

So this post is proposing some changes to how the UARS functions in RPIP-46:

1) NO_share (both up and down increments) should be balanced with changes to rETH commission, rather than surplus_share.

Reasoning: There are two supply/demand relationships for UARS as written: 1) balance between rETH supply and demand (this minimizes capital inefficiency/waste) 2) balance between voter_share and surplus_share (this targets a ‘goal’ staked/vote eligible RPL). The change i’m proposing has these upsides:

A) To reach equilibrium of rETH supply/demand, you will need a lower NO_share which in turn means a shorter period before reaching equilibrium with less overshooting (because you are simultaneously increasing NO demand and decreasing rETH demand)

B) To reach equilibrium with rETH supply/demand, we will no longer throw vote eligible RPL out of equilibrium (by decreasing surplus_share/voter_share ratio); thus you minimize future need for adjustment with the second prong of UARS.

C) The relative delta for rETH value is much lower than the relative delta for RPL value (to increase NO share by 0.5% would decrease rETH APR by 1/200th if balanced with commission, but would decrease RPL value capture by 1/21 if balanced with surplus_share. Eg, an increase from 3.5->7% which is predicted by some, would decrease RPL value capture (and thus DAO ability to spend on team/incentives etc) by ~33%; the same increase under my proposal would decrease rETH yield by 3.5%, or ~0.13% APR).

D) As currently stated in RPIP 46, decreasing NO_share will primarily be done by voting to increase surplus_share, which obviously has conflicts of interest for the voters who are also RPL holders (see below). No such conflict exists for balancing NO and rETH apportionment, as the DAO is always incentivized to seek optimal balance which gives best growth potential.

2) Just as the security council has a rapid and pre-determined method of raising no_share, the security council should have a rapid and predetermined method of lowering no_share. I propose, at the very least, to allow one seal down for every two seals up to quickly deal with overcorrection; however, it probably makes more sense to just allow the security council to increment either way.

Reasoning:

A) It is almost certain that when changing these parameters, the change in demand will not be instantaneous. Thus, especially when the equilibrium is very out of balance we are likely to overshoot. This is almost a given, but there is no way to quickly back down from overshooting.

B) While I think the “down” increment has been purposely deferred in order to minimize the political aspect of increasing RPL share by decreasing NO_share, I think paradoxically it will do the opposite: There is no protocol-based way to decrease NO_share; therefore the assumption is that it will decreased by political means; this means it is at high risk of both capricious and arbitrary decreases in NO_share, that have the potential for conflict of interest as well as unsettling the market based approach. Here, I think simplicity and consistency for NOs, rETH holders, and RPL holders is significantly more beneficial than timely knowledge. If the protocoled system is not successful, that is when the political aspect should step in.

C) By having a political discussion once now about when and why we will decrease NO share, it forstalls many many future discussions. Rather than “rugging” NOs, it is clear from the time they enter how and why the fees for NOs can decrease; it won’t be decided arbitrarily or capriciously. This will save significant human resources over time from a DAO that is short of human resources.

3) The pDAO should vote on the target RPL staked number (ie, there should not be any initial setting at time of passage of RPIP 46).

Reasoning: There is significant heterogeneity amongst the few people who are contributing about the optimal amount of RPL staked, from 40%-95%; the DAO should be able to vote in some ranked choice format NOT requiring 75% to get the initial setting; they should also be given good information on the benefits and risks of various. Obviously if voter_share wins as use for surplus_share, this point is moot.

4) There should be a plan in this RPIP about how and when to deal with declining protocol TVL.

Reasoning: if rETH supply is dropping with rETH demand (ie, both NOs and stakers leaving with falling TVL), this proposal would suggest no changes. I think this is the point where you start cannibalizing RPL value- that is, decrease RPL share and increase both NO/rETH shares. The opposite should be true at the self-limit (decrease NO/rETH share and increase RPL share) which is hinted at in this proposal. These can be decided in the political sphere in the heat of the moment, but those decisions will likely be far to late and have a high likelihood of either over- or under-shooting the correct split (see how long it has taken to deal with NO supply issues).

1/4: The reason 4 is an issue is because you propose to change 1. In concept, right now it’s written as “influence supply as desired” and “influence demand as desired”; note that this fully allows for “influence both if desired” (ie, looking like your proposed #1 is allowed). The first “concrete guidelines” bullet notes that we could act to increase demand and/or decrease supply; it also explicitly notes that more than one tactic could be used (including, eg [+1% reth_share, -1% surplus_share] at the same time as [-1% no_share, +1% surplus_share]). The exception to this is the seals – those do explicitly trade against surplus_share.

A couple of details I disagree with:

  • 1A Less overshooting – you note that we move towards equilibrium faster; I agree, which I’d expect to result in more overshooting rather than less
  • 1D Conflict of interest between no_share and surplus_share – Value routed to RPL is related to something like (voter_share + surplus_share) * rETH_TVL or surplus_share * rETH_TVL. rETH TVL requires supply from NOs. Ie, RPL holders are self-interested in making sure NOs are rewarded effectively.

This suggestion is roughly “influence both supply and demand by default” and “mess with RPL share only if needed”. I think that allows the same options, just skews initial thoughts a bit differently. I think it makes more sense as is, but I won’t fight super hard for something closeish in an optional section. I also wouldn’t fight real hard to change it for seals. If these are prevailing opinions ofc.

2: The premise is that “overpaying” is not that big a problem (less than optimal revenue) whereas “underpaying” is a big problem (we lose potentially sticky NOs; we are undersized for a while which has downstream implications). I also think it’s good to limit how much we put on the security council. I prefer keeping it one-way. pDAO intervention is available in a month or so if desired – that’s not that bad.

3: I think I support this. Could be a vote alongside the “surplus_share” vote, with an understanding that it only applies if “all to voter_share” isn’t the winner