Please discuss the appeal of the Eigenlayer Bounty vote (RPIP-38) here.
You are voting on whether or not the pDAO should decide the bounty here- not whether or not to reject it.
Sentiment Poll, as required by RPIP-4:
As Valdorff has stated here, it is pretty clear to me that the pDao gets to vote after the initial investigation, milestone 0.
I think we need to trust the GMC until they have actually shown bad faith. So, Patches, I see your argument in the other thread as not relevant here:
That would be a major trust loss if they rewrote this crucial part.
On the other hand, I do like voting and think itâs always better to vote instead of preventing a vote.
Thus, I vote to vote, I just wanted to state that I donât distrust the GMC and think itâs actually pretty clear already.
I donât mean to imply distrust of the GMC, I just want for the annals of RP history to be full of unimpeachable actions. I am being a stickler for process, more than anything, because following process protects us from future strife.
At any rate, I believe itâs also worth voting on simply because itâs a big decision, and I want the opinion of the pDAO on whether to even fund the research.
I think the pDAO voting after milestone 0 makes sense. By then, weâll all have a much better understanding of whether it makes sense to continue or not.
Weâd better to discuss how to manage AVSes and prevent potential slashing before integrating the Eigenlayer.
The idea of the bounty is to design it such that Node Operators would only be risking themselves by joining an AVS so that we as a DAO donât have to whitelist every single AVS. I believe this is more in line with our permisionless ethos.
Yes, I agree with this.
What Iâm trying to express is, for example, how much ETH can be involved in restaking, what the yield rate is, and how the returns are distributed. Additionally, Iâm curious about whether the 8 ETH staked by node operators can be converted into rETH for participation in restaking. However, all of these aspects are governed by a protocol contract, and node operators cannot intervene.
Regarding AVS, Iâm still exploring it, Iâm unsure if there is a need for node operators to run AVSes and what strategies might be involved. Of course, contributions from the community on these tools are welcome.
With a proper integration, the full 8 ETH can be safely restaked, maybe minus 1.5 for guaranteed slashing protection. You cannot convert to rETH, you must stake ETH as a node operator in rocket pool. You can already restake rETH.
Node operators that run AVS will get bonus yield. There isnât a need but there is a worry that our node operators will leave for greener pastures.
I am just about ready to release an essay that talks about this in a lot more depth.
More discussions and interest in EIL are needed. Additionally, it is necessary to gather the opinions of node operators on EIL. Therefore, I support the need to vote.
Yes, if we run AVS, it would require modifying the withdrawal credentials to point to Eigenlayer. This would mean that the 24ETH, apart from the initial 8ETH, leave for greener pastures.
So, Iâm considering whether there could be another approach: Node operators could participate through rETH restaking. This entails a specific contract validating the node operatorâs authorization. If met, the operator can mint corresponding rETH through this contract to engage in restaking. Importantly, the rETH tokenâs owner would not be the node operator. Upon withdrawal, the restaking rewards accrue to the node operator, while any surplus ETH, after burning rETH equivalent to the initial 8ETH, returns to the deposit pool.
I think you have it backwards. The 24 ETH would be reserved for Rocket Pool. The proposed bounty flow is Ethereum â Rocket Pool rETH share â Eigenlayer.
Are you suggesting node operators also mint an âLRTâ for opting in?
Itâs just an idea, I sketched out a flow, which could help boost the supply of rETH.
Restake flow:
Unrestake flow:
Iâve also attempted to draft a diagram based on my understanding of the solution mentioned in the bounty. Please feel free to point out any discrepancies or issues you may notice.
Before I get started, I believe this soft partnership was too big a decision for the GMC imo. The pDAO should have a say, and this will do that. I do wish we couldâve gotten here without contention (eg, the GMC just passing it up to the pDAO for the initial decision).
I will be voting âForâ on both votes, which is against EiL work insofar as possible.
Iâll start with practical reasons:
I think money/research right now would be essentially meaningless. I see it as primarily a moderate spend to signal âsoft partnership interestâ.
And a quick thought experiment on yield. Right now EiL has a TVL of $11.2B. Assuming all that stake chooses one or more AVSes, they would need to take in $112M/yr (after any protocol/token/investor share) for each 1% APY they can offer to their delegators/restakers.
Next, Iâll go to value reasons.
Relevant values from the pDAO charter:
- The pDAO SHALL prioritize protocol safety
- The pDAO SHOULD prioritize the health of the Ethereum network
- The pDAO SHOULD prioritize decentralization
Itâs not realistically possible to support a fraction of the protocol. If we allow them to use our brand for orangewashing, that will apply to all of the above.
In short:
To Valâs point, while not speaking for the GMC, there was very widespread agreement from within that something of this magnitude should be kicked out to the pDAO as a whole. It was a mechanism we did not have at the time this grant came up, but âkick this straight out to the pDAOâ will soon be in our arsenal.
The next part I write tepidly because I have mixed feelings on EigenLayer, to say the least, but in the grand scheme of things, $10,000 to kickstart research so we have something to build off of in case we want to pursue integration is not that much. I do agree, however, that there is a lot that cannot be done due to a dizzying array of factors that will change over the next year (forced exits, megapools, âŚ).
Furthermore, the $10,000 milestone 0 does not guarantee further money. The pDAO gets a say after milestone 0 if this is worth pursuing.
None of this is necessarily indicitive of how I voted or how I think anyone else should vote.
So on the GMC I voted to:
I was overruled in all three votes, but I think that the GMC, in approving this bounty, worked exactly as it should have.
The GMC knew this was a contentious issue, had significant discussion internally and externally at short notice, attempted to reconcile the sides and even placed appropriate safeguards to ensure pDAO oversight was maintained before enacting. The GMC is delegated responsibility of a fairly narrow scope, but that responsibility is not negated by a topic being potentially contentious- in fact, it is probably more important that the GMC weighs in on those issues.
This would be a contentious issue regardless of who was in the GMC or which superdelegates fell on which side of the divide. The contention is over what is the right path forward for Rocket Pool.
And I should add, the pDAO is now working exactly as it should- by providing oversight of the GMC.
My conclusion is that this whole âepisodeâ is actually an example of good, if messy, governance.
The only part that I think is unfortunate is that both sides agree that the bounty as written could be improved with the benefit of time, hindsight, and more eyes on it; whether the bounty is ultimately approved or denied, the fact that we are not voting on the best available path forward is disappointing.
I am voting for funding the 10k research despite the fact that it is too fixated on presigned exit messages- the part i think is critical is âcentralization trade-offs, capital efficiency analysis, protocol risksâ; I am voting against funding the subsequent bounty as written. Pending the results of the research, I think we should move forward with some integration, with a new bounty, with Rocket Poolâs concerns being foremost. Essentially, we can allow our NOs to take extra risk as long as it doesnât significantly impact protocol risk.
To me this is largely about mitigation. If we ignore EigenLayer, it is pretty easy to foresee a third party making a contract that NOs can point their withdrawals to, which would be markedly worse than us choosing appropriate levels of collateral.
It is also also easy to see RP setting rules that disallow restaking by its node operators at threat of forced exiting. This would essentially set the stage for a war between two large parts of the ecosystem, and if the last year is any indication Rocket Pool will not come out well from that confrontation.
I think it is likely that by maximizing our collateral with new tokenomic changes we will be able to offer restaking at appropriate collateral levels, but also ensure that creating rETH is more attractive than restaking for most NOs.
I totally agree with Valdorff.
Iâm confused why we rush to implement an integration without a prior rigorous research on EigenLayer (maybe I missed it?). Is EigenLayer good or at least neutral for Ethereum and RP? We want this integration for the sake of growing RP, but itâs possible that we end up as another outcast like Lido in the eyes of core Ethereum developers.
I think itâs wrong to start this bounty right now because:
This is not a grant to integrate with EigenLayer.
This is a bounty asking to begin research on what an integration might entail.
As per bounty BA082401 there are:
This does not look like a research.
Milestone 0 is not to build a contract. It is to research EigenLayer integration especially with respect to forced exists. If the gmc feels the research was helpful they can choose to pay out the milestone 0 part of the bounty. Then the pdao decides if the bounty recipients should continue to the next milestone.
Yes, I guess I understand RPIP-38. Iâm just expressing my support for declining or reducing the scope of the bounty and my reasoning.
