In order to keep the application threads clear of discussions (to make it easier for committee members to read and score them), please use this thread for any and all questions and discussions of July 2023 (Round 3) period of grant, bounty, and retrospective award applications.
@polarpunklabs re: rocket pool case study
How will the work be maintained after delivery?
No maintenance required.
Rocket Pool is pretty far from ossified, and if your case study is going to drill down to the level of detail I hope it would, it will probably need to be updated every 6 months or so. Just a thought.
1 Like
@LIBlockchain @direct @ramana some questions on rocketsplit:
This tool supports […] RPL Holders in earning more rewards.
Why is this desirable? At small scale this doesn’t bug me, but at large scale it defeats the “dilute speculators” concept of inflation. In other words, this doesn’t grow the pie of RPL rewards, it just cuts it into more slices.
The “protected speculation” bit is already iffy justification. If this becomes widespread, I’d be quickly pushing forward a proposal to limit RPL earning to the minimum required.
What happens if NO is hit by a bus or otherwise can’t close down validators? Is RPL stuck forever?
I believe this is the case in current marriage contracts. If this is a risk, I think it needs to be very clear as it amounts to a total loss. I guess leakage might eventually bail you out, but that’s years away.
Even without a bus; I think the RPL holder is stuck indefinitely, with the only weapon at their disposal being keeping rewards illiquid? NOs might not care about that factor for multiple years.
What other edge cases are there?
I think RPL provider griefing is limited because exiting frees things up? Still pretty inconvenient.
How confident are you that things will go smoothly and safely when LEB4s roll out and there’s bond reductions available, eg. Is it possible to essentially end up in a different financial agreement than was intended?
rETH will become more in demand if more Node Operators are onboarded.
This isn’t a question, but I disagree. We’ll be better able to meet demand, but this won’t create rETH demand.
Also, even meeting demand is only true insofar as we’re using this to meet the minimum. If I’m using this to run 2 minipools myself at 150% bonded ETH collateral and 4 more at 150% using rocketsplit to provide the RPL… I could’ve met the same demand by running the 6 at 50% myself and not involving rocketsplit.
This tool supports […] RPL Holders in earning more rewards.
Why is this desirable? At small scale this doesn’t bug me, but at large scale it defeats the “dilute speculators” concept of inflation. In other words, this doesn’t grow the pie of RPL rewards, it just cuts it into more slices.
The “protected speculation” bit is already iffy justification. If this becomes widespread, I’d be quickly pushing forward a proposal to limit RPL earning to the minimum required.
RPL utility is captured only when it is staked. Correct that this does not grow the pie of RPL rewards, but it opens an opportunity for more users to allocate RPL to it’s designated location.
What happens if NO is hit by a bus or otherwise can’t close down validators? Is RPL stuck forever?
I believe this is the case in current marriage contracts. If this is a risk, I think it needs to be very clear as it amounts to a total loss. I guess leakage might eventually bail you out, but that’s years away.
Even without a bus; I think the RPL holder is stuck indefinitely, with the only weapon at their disposal being keeping rewards illiquid? NOs might not care about that factor for multiple years.
Current marriage contracts do not have protections from rogue buses. The new contract is being refactored for anyone to be able to distribute earned funds to the designated endpoint address. This however does not account for an ability to withdraw. If the NO is hit by a bus and does not have personal backup plans for their estate, we have no remediation for the RPL holders principal balance, unless and until the protocol enables its own upgrades for forced exits.
We have briefly discussed sharing a pre-signed exit transaction in json format that could be provided to both users. That is not something we are ready to implement without significant further discussion.
What other edge cases are there?
I think RPL provider griefing is limited because exiting frees things up? Still pretty inconvenient.
We are refactoring the contract to support a claim and restake method, gated for only the NO or RPL provider, as opposed to the claim method which can be called by anyone. Staking should be initiated from the Rocket Split contract.
How confident are you that things will go smoothly and safely when LEB4s roll out and there’s bond reductions available, eg. Is it possible to essentially end up in a different financial agreement than was intended?
Users are encouraged to create a new RocketSplit contract and update the withdrawal point in case of any agreement changes.
**rETH will become more in demand if more Node Operators are onboarded.**
This isn’t a question, but I disagree. We’ll be better able to meet demand, but this won’t create rETH demand.
Also, even meeting demand is only true insofar as we’re using this to meet the minimum. If I’m using this to run 2 minipools myself at 150% bonded ETH collateral and 4 more at 150% using rocketsplit to provide the RPL… I could’ve met the same demand by running the 6 at 50% myself and not involving rocketsplit.
I believe the more Node Operators will be onboarded through the safety of the “buddy system”. Many users may be interested to learn more about becoming a NO themselves but need something like this as their guided first step.
karmahq retro
I think it should receive a small award, but the amount sounds quite high to me relative to previous expenditures and the value for the community. A few reference points: more than is going to Val for governance work through April (even with the amendment), just slightly less than all ETHDenver volunteers combined, 2/3 of the cost to create the rescue node and run it for 6 months.
We’ve talked about this in discord a bit, but it’s important to get relative weightings in a good place.
Current value to community:
- The dashboard has been mentioned in the RP discord 3 times I could find
- Once by the creator
- Once asking if anyone thought it should be the main delegate landing page
- Once when the main delegate page was temporarily down.
- To be frank, I had forgotten about it (despite being very active in governance and having written a voting guide).
- The tool has things that simply don’t apply to us (delegate interest, forum activity not linked to our forum)
- The tool is missing info that delegates provided (statements and links to socials)
- The creator was responsive when I mentioned two votes that were not real votes and shouldn’t be counted in the score.
@LIBlockchain regarding this:
The smart contract is similar to the “whale marriage” splitter contracts used for community members like markobarko/worthalter’s nodes
And:
@Ramana developed the in-production smart contract of the “whale marriage” and “dolphin marriage” as identified earlier
Do I understand correctly that you are saying that ramana developed the smart contract used by marko and patricio? I was under the impression that they are using a general purpose splitter contract developed by 0xsplits.
Do I understand correctly that you are saying that ramana developed the smart contract used by marko and patricio? I was under the impression that they are using a general purpose splitter contract developed by 0xsplits.
No that is not what was meant. I didn’t write the marko-patricio contract.
karmahq retro
Does the community feel that the dashboard https://rocketpool.karmahq.xyz/ is a clear upgrade from delegates.rocketpool.net?
Is it a better tool than what we are currently using?
If a reasonable price is negotiated, should it replace delegates.rocketpool.net?
Re: rocketsplit
Not sure the authors defended this point. The demand for rETH is largely based on its premise of decentralization, having 100x more NOs than lido. Otherwise it has worse APR and worse integrations. This proposal opens the doors for two novel demographics: NOs with 8-10.4 ETH, and NOs that are comfortable with smart contract risk but not token price risk. Not sure how big the former is, but if solo validator threads are any indication, the latter is a large group.
If we don’t do this in a permissionless and trust minimized way, then potential NOs will go to a centralized entity (SAAS or RPL lending desk) to do the same thing with worse alignment, or to a competitor.
The other unrelated rocketsplit point is I think this is an excellent place for performance-based rewards, rather than lump sum. I’d recommend the GMC think about how much they think a minipool is worth to the protocol, how many minipools will likely to use this method, and use that to reward the recipient. Eg, 200 RPL + 0.75 RPL per new minipool using the contract, capping at 1000 RPL, paid every reward cycle. Aligning incentives encourages better product and UX, continual updates or marketing without new bounties, in this case may cause the authors to think of carrots to encourage more low collateral minipools instead of a few high collateral minipools, and ultimately means the authors are paid an amount equal to their impact, not more or less.
It is currently dramatically worse. It removes the main piece of info (bios). The voting history is nice, but it’s not in a place it can replace the current site.
1 Like
Sorry, didn’t realise there was a discussion thread! I think that would be sensible and actually interesting. Essentially operating as a kind of historical document too.
1 Like
re Rocketsweep:
I’m flattered and grateful to Val for the write-up.
re Amount: $1000 is great and feels good and way more than the $0 I expected for the work.
My hard costs are pretty minimal so I don’t need any more help there.
But just to be clear: I’m treating this as a handsome appreciation prize – not as payment. The actual cost of hiring someone to build and maintain this would be orders of magnitude more ($10k-100k). Again, I’m grateful to get >$0 and I’m not asking anything. I mention it just to avoid the committee inferring the wrong market rate for prospective projects.
4 Likes
@peteris any chance we could get close, claim rewards and withdraw RPL in milestone 1 or 2 instead? In terms of concrete use cases, “my PC/server died and I’m done” seems a pretty clear one. Ditto if allnodes evaporated and folks wanted to exit (unlikely; very nice to have a clear exit in that case though).
I’m not sure I understand the main uses of the current early milestones… Maybe one is having a Safe as a node address? Could you describe some concrete reasons to use this (since NOs need smartnode anyhow)?
@zahary can you speak to “why zk” for this? Is it enabling something significant (to users) that optimistic fraud proofs cannot? My current mental model is roughly “They’re pretty similar for actual use. Zk requires a lot of compute and is more dev work. Challenging optimistic fraud proofs introduces some delay and short term capital requirements.”
I agree that both the ZK proofs and the fraud proofs are reasonable solutions for the oracle problem. I guess I’m drawn a bit to the mathematical beauty of publishing a definitive result 
If you want to compare the very fine details of both systems, one can argue that the delay introduced by fraud proofs can create an extremely minor disadvantage for users who want to liquidate their positions (because the very latest rewards won’t be reflected in the price of rETH).
On the other hand, the lower cost of publishing updates in a fraud proof system may make it practical to publish updates more often.
rpUSD: I apologize for coming on strong, but I think this would have significant negative value. Gravita has done good work for months – that’s amounted to getting to a $5.5M mint cap from rETH. This just doesn’t move the needle. We’re looking to more than 10x rETH demand - we won’t get there by putting significant attention on +1% projects. TL; DR: there’s no reason to expect significant demand, we’d have to pay (money, yes, but also attention and effort) for growth. Cost benefit analysis in my view is 0 benefit (or potentially negative if we damage rETH demand from Gravita etc) and significant cost (even if we set grant and liquidity costs to zero).
1 Like
No apologies needed! I agree with you to be honest, I think I can benefit RP the most by focusing on Gravita, but I stepped forward in writing the grant as there was some interest in the community and I have relevant experience.
There are many CDP projects popping up, and an immutable protocol would quickly lose its appeal as it wouldn’t be able to iterate. For example, it would be challenging to deploy on L2s or add LP tokens as collateral.
Since writing an article won’t change the premise, it’s probably better to save time and money and ditch it.
2 Likes
We are requesting 108 RPL (9 RPL x 12 episodes), split 80/20 between Pat (86.4) and Waq (21.6).
Considering you referenced the $270/per episode - did you mean 7.5 RPL per episode? ($270 / $36)
This would make your total requested amount $3240 ($270 * 12).
We were estimating RPL @ $30.
So 9 RPL x $30 = $270.
Apologies for the late reply.