I think this is worth keeping in mind and consistency should be a value. If this is seen as annoying (gee everything looks bad vs X), then a GMC member can make a retro to fix the root mismatch.
The rapid research incubator was for a 0.5-3 page brainstorm, perhaps with a quick model. This is asking for much deeper research with an agent model, a control system, and clear reports with findings. Not taking a side, so much as noting that it’s definitely not a duplicate.
I’m unaware of cases where NOs have opted into trusted ruggable situations, but that’s not the core point. I agree we shouldn’t be patetnalistic and prevent degeneracy. That’s not the same as actively paying for and smoothing the road to being degen.
I take the view that RP’s participation materially impacts their likelihood of success and dominance. Our brand is a big deal. It also is not the same to have some participants vs GMC funding (vs something voted on by the full pDAO ofc).
This seems the core disagreement. Seems an odd stance (akin to “there is little value in the set of operators and the brand”).
See the response to Val
I think this may be of questionable value as we approach the launch of Nodeset. That said, I do like the idea.
Amazing, give them more than they asked for.
If they’re willing to trim down the application to something that just focuses on hosting events about Rocket Pool I think I would support it. Not as presented though.
Pay them more than asking, I like the suggestion of extra 1k/month. Too useful to ignore. Give them a bonus for hazard pay.
Ignore it.
Fund it. Give him a bonus/raise for completion and increasing quality. Maybe enough for him to hire an ‘intern’ who edits the vids and makes a Rocketfuel twitter account with highlights the way wolfy is doing but on an industrial scale.
Don’t fund it. Project seems very early stage and the benefit to RP is not clear.
I think it’s worthwhile to front the cost of the audit since I believe it was a grant that built it. I would like to see some numbers about use.
Don’t fund it. There is no ecosystem yet to provide data on (and I’m the guy proposing the bounty for the integration lol). Suggest a re-application when the protocol is live.
Wow, it’s really been nearly 2 years huh. Damn. Maybe throw us a raise 
Also, I will be applying if there is still time, if not, next cycle.
I think the rapid research incubator should take priority here. However, if UVC is not covered under that, then I think this does deserve funding. Price sounds right for a high level product.
Fund it - we need more physical RP events to build our awareness. I hope this can serve as a reference point for future repeated events.
Yes pls, sometimes I pay like $50 for an execute.
Double the values, literally. I thought Peteris was exaggerating but I think Val is being modest in his app. I was worried that RPIP-30 was going to be a mess for the community the likes of pETH vs nETH but with very engaged research, the community was a landslide yes by the time the vote arrived. That work deserves praise and encouragement.
I believe Patches is overly modest, give him at least double.
This was some crucial stuff that happened, IIRC, when some of the members of the team were incapacitated and Patches rose up to fill in. Give him triple.
“Fund it. Double it.” - A wise man
Thank you to everyone who said nice words about Rocket Fuel. Your kindness is amazing.
@JeffreyGoldberb please delete your comment in the bounty thread – we try to keep clean award threads and bring discussion over here.
The original post:
1 - As written, RP would have senior debt (aka, Eigenlayer gets second crack at bonds – aka, rETH isn’t exposed at all). There would be no direct APY increase. There is potential for a rETH APY increase downstream, eg, NOs might accept less commission because of this revenue stream.
2 - No - see 1.
3 - The Node Operator risks losing up to 100% of their funds. In order to get their rewards or their principal, each step in the chain has to pass funds on. If this extra step fails to do that (by design due to an Eigenlayer slash, by rug, or by bug), then the NO could lose funds. There is some room for annoyance here where an NO might have no incentive to operate well for RP if already Eigenslashed. There’s potential mitigation available at the research level (eg, @ArtDemocrat’s proposal to pay back outlier underperformance to rETH and @epineph’s proposal to garnish rewards).
4 - There’s a lot of question marks. The simplest guess would be “NOs receive stuff and don’t directly pass anything on” – but indirect benefits may apply as described in 1.
Commenting on a few of the applications that I have notes on. Absence shouldn’t be read as for or against . Apologies for the late feedback.
Treegen Testing Support from Valdorff
Just minor note on the presentation. I would suggest that this be setup as a single repeating bounty with the dependency being a new tree specification published by the Rocket Pool team. Can fund 1 or 2 independent implementations per published specification as desired. As a general rule, I think it’s fine for bounties to be repeating-until-revoked, especially if there is an internal rate limiter on max spend (in this case X-per-published specification.) Probably sensible to specify that it’s for each ‘major/minor’ version change as appropriate, and not revision-type changes.
Management Committee Gas Reimbursement from Shfryn
Seems reasonable, but I would prefer to see this done as part of the normal operations of the given management committee. It could be written into the appropriate RPIP that committees may reimburse their members for reasonable gas costs using their budgets.
RP Community Call Hosting on Twitter Spaces from Ken
I avoid interacting with Twitter / X and don’t have an account. Last time I tried, I wasn’t able to join these (presumably due to lack of account.) I can see why twitter is a good platform for this though, especially if you’re trying to reach more widely. Should be funded, but I wanted to record one vote for ‘different platform’.
Universal Variable Commission from @sckuzzle
Generally I think this is a good research direction, and this should be funded (though I’ve no idea if this is good value-for-money or not as is). My main concern is over the PID controller. There was a fair bit of history around PID’s in Maker to manage stability, and Reflexer eventually implemented one. I am very unsure that a PID can work effectively, at scale, in a hostile environment in which its logic is known. They are very hard to test in-situ without significant risk, and you cannot be sure that tests out-of-situ are representative, because there is no true value at stake.
Denver Lift Off from @Ken
I have something of a unique perspective on in person events, because I don’t attend them due to pseudonymity, but was involved with Maker where they were run frequently. In general, I think they are worthwhile in moderation, and this should be funded. My issue with them at Maker was that they rarely led to concrete outcomes. Participants would discuss ideas and direction, even in some case agree on things widely, but no apparent action would follow.
On that basis, I’d recommend that the deliverables include the following, to be completed after the event:
Thanks for swift and thorough response. What’s the right place to have a full discussion on this?
Here for long form thought out stuff, or maybe the Eigenlayer discord thread if going more conversational.
Help me understand a bit more about this bounty proposal and you’re subsequent discussions on its merits.
Here is my understanding of EigenLayer: An Ethereum validator could participate in Eigen Layer (EiL) by setting their withdrawal credential to be some yet-to-be-developed Eigner Layer smart contract. Once enrolled in EiL, a NO could participate in several Actively Validated Services (AVS) of their choice. For these additional computing duties, the NO would be paid for running AVS software on their node. To be eligible for this participation, the NO would need to promise their NO validator deposited funds as a surety bond to ensure they were honest and reliable in performing their AVS duties. EiL would have a mechanism to force-exit one or more enrolled validators so they can redeem their surety bond.
In the case of a solo validator, there is an excess NO deposit as the validator deposit (32 ETH) exceeds any non-correlated Ethereum protocol slashing penalty (~1.5 ETH). This excess deposit amount forms the foundation of EiL; This “unused” collateral could be retapped (promised to EiL as a surety bond) and thus the word “restaking.”
My thoughts on what an RP NO integration could look like. If an RP NO were to join EiL (say by locking and setting their Withdrawal address to the above EiL smart contract), the only collateral that would pass through to the EiL would be the NO deposit and not the rETH deposit.
In the case of LEB16 and LEB8 minipools, excess NO ETH can be used in EiL as the surety deposit. For example, if a NO has four LEB8s their deposit would total 32 ETH. Non-correlated Ethereum slashing exposes about 6 (4 * 1.5) of the ETH at risk. So EiL would have an assurity bond of about 26 ETH (32-6), which compares well with a solo validator of 30.5 ETH (32 - 1.5).
In the current state, I see a business case as to why we should provide this option to NOs to access additional earning potential.
But I need help to see the use case in our envisioned world of Megapools where nearly 100% of the NO deposit would be used towards this minimal assurance to protect against adverse Ethereum slashing events.
With the future of RP being focused on Megapools, not minipools, RP wants as much (if not all) of the NO deposit to apply to being exclusively used to protect against non-correlated slashing and MEV theft. Reducing the NO deposit to the minimal viable amount allows RP to grow as capital efficient as possible. In the above example, where a RP NO operator has 32 ETH, instead of running four LEB8s we envision a post-Saturn world where that NO would run a single Megapools with 16 validators. Each validator in that Megapool has 2 ETH of NO deposit to protect rETHers if the NO commits a slashable error.
(Note: Research with the variable node deposit amount is needed to ensure that only a few ETH per validator is sufficiently large enough to protect against MEV theft and likely slashing events.)
For example, suppose we reduce the NO deposit on a sufficiently large Megapool such that each validator only requires 2 ETH. In that case, little ETH is remaining for EiL to access as a collateral deposit. This leaves only 0.5 ETH (2 - 1.5) of a surety deposit for EiL.
My questions:
1/2: Your understanding seems about right. Small notes:
3: At a high level I agree RP shiuld be gunning for max capital efficiency internally. This will almost certainly reduce the relative value of EgL to RP NOs (in an extreme like LEB1.5s, perhaps to near-zero). That said, if EgL see value beyond that, I understand the desire to milk that too. I just think there are negatives, as I wrote above. From Eigenlayer’point of view, I’m not sure what’s attractive about RP - junior debt and the rules might change 
.
Another take here would be “what if all our rewards were based on rETH supply supported”? In that case, if someone opts to be less capital efficient so that they can get more EgL rewards maybe that’s worth it? There was even talk of a “tax”, eg, less commision going to less capital efficient NOs, but they can do EgL. Dunno.
Hey everyone, this is Kydo from EigenLayer. I am a protocol researcher there.
There are many different threads of discussion here but I want to provide clarity on one technical detail.
The flow of ETH would look something like this:
Thank you for the visual diagram. I’ve added a various terms to infographic that we have been using within the RP community to make the distinction. I agree that the visual illustration is much better to understand but I wanted to make the distinction between the withdrawal credential and the withdrawal address.
The remaining questions that I think are pivital to evaluating the proposal are:
Hi @ken thanks for the questions. I’ll build on what @Valdorff said above which I think is a good summary.
I think part of the confusion can be alleviated if we look at the above. There seems to be an implied proposition that a solo staker has an appropriate level of collateral and that AVSs will somehow be designed around that level of collateral. I don’t think this is accurate – I expect many AVS services to have many different slashing levels and some may not slash at all while others will require a significant amount of delegated stake. What’s important is that AVSs will have the autonomy to either allow or disallow Rocket Pool validators just as they can with solo stakers. Additionally, though this is hypothetical, this could in the future provide new utility to RPL as a secondary bond above the ETH collateral.
I believe the above misconception reveals itself in these follow-up questions. Eigenlayer does not want to be an opinionated platform where they judge the security. I believe @kydo commenting in support is evidence that they are comfortable with and value junior collateral as an option. The question of ‘what % of value’ is not a question for Eigenlayer but a question for the AVSs that build on top of it. One might ask what value an RP mini pool provides vs a solo staker to EigenDA and have a debate there, however, Eigenlayer itself is value agnostic.
That said, I believe a solo staker is vastly over-collateralized for EigenDA and that an RP mini pool may provide sufficient collateral even with megapools in a majority of cases.
I’m not sure that diagram is great, Sreeram quote tweets it with a correction about how attributable security works. Notably, it doesn’t differentiate between pooled and attributable security.
This seems correct to me.
@Valdorff - This is Brianna from the EigenLabs team.
We are genuinely excited about this proposal and there is strong internal support for it within our team. At EigenLabs, we are deeply committed to the principle of decentralization, which has been a recurrent theme in numerous mechanism design talks we have given at Ethereum events (ETHCC, Restaking Summit, Columbia Cryptoecon, etc).
We completely understand your perspective and the concerns you may have regarding EigenLayer. Nevertheless, 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. That’s why we would be happy to schedule a call with you to talk about the questions you’ve raised. This call can be open to all RPL community members who wish to participate as well. Let me know if you would like to do this
Thanks for your response, I hope to see your grant request and feedback from other community members if they believe this is a good investment for us.
I appreciate the note, but no thank you. I much prefer text, as (a) I find it personally convenient and (b) there is something to reference left behind (for folks that can’t attend or want to see the conversation next week/month/year).
This is a concerning take. My opinion of a protocol and its actions should only indirectly and lightly depend on the people involved. I would hope that I would judge a protocol that has done the same things the same way, regardless of if it was being run by my best friends, strangers, decentralization maxis, or a centralized party.
Fwiw, I quite liked reading early Eigenlayer work. In theory-space, restaking is really quite cool. In praxis, I’m seeing (what I perceive as) toxic marketing and intense centralizing tendencies – so I won’t support it.
Happy to chat in forum or on discord (Eigenlayer thread), especially if you think I’m materially incorrect on some interpretation.
Hey Ken,
Thanks a ton for the illustrated diagram. This is the correct mental model for this integration.
To answer your questions:
I hope this answers your questions!
Yes, this is a good framing of the bounty.
As a node operator staking solely through RP I really cannot wait for an Eigen integration.
As for some of the criticism around the restaking narrative or EL, in particular, I really don’t understand some of the points made.
I think this might have been phrased wrongly, but there has always been a very clear intent as to why you’re locking the value up, hasn’t it?
I don’t think centralizing is what was meant to be written here either. Composability issues and cascading effects might have been better phrased even though not totally correct from my POV. But centralization is totally not the case. I might be getting too philosophical but I’d need a definition of centralization to agree with this.
Is the antithesis to the restaking narrative (or whatever we want to call it, just using the meme’d version of the term) a need to bootstrap security (i.e., build an L1 from scratch) for every new blockchain-dependent product we think of? Because I think that’s a terrible argument.
Also, as a huge believer of Handshake as a needed product for humanity I can tell you right now, sometimes it doesn’t work!!!
Extremely caustic commentary going too deep into the weeds. This is bike shedding and I believe no one is maliciously intelligent enough to appropriate a wide enough term like this for marketing purposes.
Either way, reiterating, as a rocket pool NO I’m super interested in getting this over the finish line.
As a security researcher I’m offering to help get this through the finish line (I’m the co-founder of Consensys Diligence and more recently Creed) with either time or resources. 
The AVSes are, to my understanding, opt in. Nothing will automatically start securing things once an AVS is added. This means any lock up prior to the existence of an AVS on mainnet is for purposes like marketing, farming, and hype. If that’s the clear intent you mean, then I agree. If you mean that it’s for security, it’s currently not able to secure anything in any way as no AVS exists.
The centralization I’m talking about is not security per new chain vs cross-chain security. It’s that Joe Solo Staker will be unable to attract large amounts of LST delegation, whereas a large entity like Kiln could do much more to market and attract. Insofar as this results in revenue, Eigenlayer will preferentially support folks that already have larger voices.
Perhaps fair. That said, I don’t think I’m at all alone in my thinking here. See eg:
I appreciate any help to get the pDAO what it wants.
