I’m in support of this proposal and agree on the importance of getting the incentives deployed rapidly
4 Likes
It is critical to get these incentives deployed to grow the rETH use case, liquidity, and protocol. I am all for it!
2 Likes
how much of the focus will be on trying to maintain the reth : eth peg?
2 Likes
Adding liquidity in a full range is very inefficient. Thus, we need to at least provide liquidity with the peg as our center of gravity (and keep in mind that arb will defend it in the extreme). I think we all agree on that bit.
The bit that has had more discussion is around how reactive we should be to the market. Ie, should we act differently when rETH has a market price 1% below peg vs 1% above peg. To that my answer is no, for both philosophical reasons (I’d rather design to work with the market instead of against it) and practical ones (active monetary policy is hard, and this moves us in that direction).
1 Like
Highly supportive of this.
Consider the high community support, the kind offer from Thomas and the merge coming up it makes sense to move quickly to a snapshot so that we can also have incentives on mainnet and not only OP.
3 Likes
To expand on this principle, this would suggest that if the peg was off ratio and we already had substantial defi integrations in place with strong liquidity we would not increase LM to try and push the ratio up by increasing the ‘value’ of rETH. However, if the depeg is correctable with LM that also is serving to enable liquidity goals for integrations, then the LM is warranted.
3 Likes
Please remove me from the list of initial liquidity committee members.
There is now a PR with 2 RPIPs supporting this at https://github.com/rocket-pool/RPIPs/pull/8.
I suggest a week of review/comment (until 8/17) for the RPIPs and then 3 simultaneous snapshot votes lasting a week.
Very rough draft of pDAO Budget Allocation vote text
pDAO Budget Allocation
This proposal is to establish:
- How the pDAO can and should take in funds, disburse them, move them, etc
- The concept of Management Committees, which are in charge of actually spending funds
- The initial split of incoming funds:
- Incentives (e.g., LP bonuses) - 50%
- Grants and Bounties - 30%
- Reserve Treasury - 20%
See https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-10.md for full details.
Very rough draft of Incentive Management Committee Charter vote text
Incentive Management Committee Charter
This proposal establishes the Incentive Management Committee (IMC) and describes the goals it will work towards and the values it will keep in mind.
It also establishes an informal method to generate an initial IMC member roster, which would then be formally ratified in a separate vote.
See https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-11.md for full details.
Note: In the case where this vote selects “For”, but the pDAO Budget Allocation vote selects “Against”, this vote will be vacated and considered “Against”. This is because RPIP-11 relies directly on RPIP-10, so it cannot stand alone.
Very rough draft of Incentive Management Committee Membership vote text
Incentive Management Committee Membership
This proposal establishes the initial member of the Incentive Management Committee (IMC). These will be the members formally charged with determining how to best meet the goals from the IMC Charter and executing on the strategy.
The initial suggestion is to have a 6 of 9 multisig.
The proposed members are:
- List item
- List item
- List item
- List item
- List item
- List item
- List item
- List item
- List item
A vote For indicates support of the proposed membership. A vote against rejects the proposed membership.
See https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-11.md for details on the charter.
Note: In the case where this vote selects “For”, but the pDAO Budget Allocation vote selects “Against” OR the Incentive Management Committee Charter vote selects “Against”, this vote will be vacated and considered “Against”. This is because the membership is for the committee described in RPIP-11, and because RPIP-11 relies directly on RPIP-10.
5 Likes
I’d like to propose a strawman timeline, since time is of the essence here. Feel free to make suggestions/tweaks but I think we need to target to be live with incentives by 9/1.
- 8/11-8/17: Week of review/comment as per Val’s comment above.
- 8/17-8/24: Vote(s) are taken to Snapshot.
- 8/24-8/31: Assuming we have community support from Snapshot, this would be our week to implement liquidity programs. Loop in thomasg to coordinate matching if needed.
- 9/1: Target go-live for incentives.
12 Likes
This is a good target to have and aligns with the expected start date for BAL incentives for the rETH/WETH pool on Beethoven X on Optimism which is also slated for Sept 1 (these are incentives paid for by Balancer - with our OP grant incentives to commence once we have received them).
3 Likes
FYI RPIPs 10 and 11 are merged with Review status! Still targeting a review/comment period until 8/17 - simply discuss here or (for quick stuff) #governance on discord.
See RPIPs/RPIP-10.md at main · rocket-pool/RPIPs · GitHub and RPIPs/RPIP-11.md at main · rocket-pool/RPIPs · GitHub
5 Likes
I’m in full support of the budget allocation and the timeline proposed by Marceau. Liquidity incentives live pre-merge will be a huge tailwind for RP
1 Like
There’s a new PR (https://github.com/rocket-pool/RPIPs/pull/11) up integrating some feedback from langers (which started from https://discord.com/channels/405159462932971535/774497904559783947/1008899364892180520).
FYI, for those that joined at this thread and aren’t would like more history, there’s earlier context for the pDAO budget discussion in https://dao2.rocketpool.net/t/pdao-budget-definition/644.
1 Like
Full support from me.
Throwing my hat into the ring with full support. This is a matter of urgency far out weighing the Bankless add campaign renewals.
Would love to see some movement from the team as this should be put on the high priority as it needs to be implemented before the merge.
Fully support this and believe that deployment of incentives would be beneficial for RPL’s overall visibility within the defi world.
Existing MC members MAY vote to remove a member with a 2/3 or greater supermajority.
Note that this cannot be done if it would violate the above multisig requirements.
Do we know/have we discussed/pondered the possible scenario where a bad actor can lock an MC by forcing there to be less than 5 members? So, if there were 6 members and you convince 3 others to eject 1 of the 2 others, you drop to five members…but if, then, the bad actor forces another one offline indefinitely (if keys are lost/stolen, person backing the wallet passes away w/ no one that can operate the wallet, etc.), then you force the MC into a permanent offline/immovable state and funds would be frozen.
I haven’t seen any sort of contingency if a quorum can not be established if we drop below the minimum threshold of 3/5 signatures.
I want to state I’m in favor of what we’re setting up and I’ll be voting in favor, but I think we need to figure out what we do for disaster recovery.
1 Like
I think we need to keep in mind the limits of agreements vs code.
For your specific case, I think I disagree about there being an issue. We have a 3 of 5 with one malicious key and one unusable key. That leaves 3 - enough to act to (return funds to pDAO, add members as directed by pDAO, etc). If we somehow get to a 3 of 4 state with one malicious key and one unusable key… life is bad. I suggest it’s easier to avoid this case than it is to have a safe recovery.
As an aside:
I do think we need to be extremely careful about how we act. For example, if we were at 4/6 and the intent was to kick one and move to 3/5, execution is important. There are issues with both reducing threshold then kicking and with kicking then reducing threshold. I’m not (yet) familiar enough yet to know if there’s a good way to execute both atomically. If there isn’t, there’s always the fallback position of returning funds to the treasury and moving from there to a new appropriately set up multisig.