Eigenlayer Integration Bounty Challenge

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:

  • I support moving to a pDAO vote.
  • I do not support moving to a pDAO vote.
0 voters

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.

  • no slash: restaking earnings would belong to the node operator, and any surplus ETH after burning rETH and subtracting 8ETH would return to the deposit pool.
  • slash: The lost ETH will be deducted from the node operator’s 8ETH or RPL.

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.

1 Like

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:

  • Milestone 0 is a payout for pre-signed exit message work
    • There was a time when some folks thought this might be worthwhile to be able to get out the door sooner (vs waiting for EIP-7002)
    • The first AVS has been described as only paying out to the top 200 NOs by delegation; there is no rush to beat EIP-7002
    • Do we have any reason to expect an AVS coming soon will be compatible with smaller home stakers? Having a small set of valuable nodes makes design way easier (see every dPOS chain, eg)
  • Any work will likely need to be redone entirely with megapools, which have a different interface than minipools

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:

  1. The pDAO SHALL prioritize protocol safety
  2. The pDAO SHOULD prioritize the health of the Ethereum network
  3. The pDAO SHOULD prioritize decentralization
  • I believe EigenLayer are a danger to Ethereum right now
    • They’re the 2nd largest protocol without a mainnet release
      • Their contracts are upgradable and allow for a 100% rug; sometimes things need to be upgradable for protocols. That’s ok. But then you try to minimize the honey pot for safety.
      • Current TVL doesn’t map to security - folks have to opt into AVSes; all LST restaking is entirely opt in risk
    • EigenLayer caused the points meta, which is pretty damaging to Ethereum imo. Are we really just a casino?
    • Eigenlayer are a strong centralizing force. They need to bring in hundreds of millions of dollars to have a decent APY at their current size. Do we want to help create another “too big to fail” entity? (they might succeed/fail with or without us – I’m asking if we should be helping)
  • Eigenlayer purposely market LST “restaking” as similar in kind to validator restaking. They are not. The first is just delegating assets. It has nothing to do with staking. DAI, UNI, LDO, Bored Apes, or anything else of value would have worked just as well as LSTs.
  • Rather than respond to my concerns they said “we have full confidence that once you know the people behind the labs and their inspiring vision for the future, your perception of the protocol will change as well”

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:

  • I don’t think they’re that likely to succeed in a big way
  • I think they’re extremely dangerous if they do succeed in a big way
  • I think they’re more likely to succeed in a big way with RP support

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.

My thoughts on the GMC's role in this vote

So on the GMC I voted to:

  1. defer decision on the Eigenlayer bounty until the next reward period for further discussion
  2. subsequently decline to extend discussion about the bounty
  3. subsequently decline to fund the revised eigenlayer bounty

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:

  • It is likely, that smart contracts will have to be rewritten post-Saturn;
  • EigenLayer is not proven to be a working product and a good fit for both RP and Ethereum;
  • It’s better to prioritize tokenomics changing, which can give us all desired growth in one go.

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:

  • Milestone A - Build Contract
  • Milestone B - Feedback and Integration
  • Milestone C - Front-End and Documentation

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.