Recovery Multisig will hold tokens from the network emission and transfer them to fund burn partners for depegged assets every month.
Recovery Multisig follows strictly the operations of the current burn.
Recovery Multisig continues to hold tokens from emission after the recovery is completed – until further Snapshot proposals.
Recovery Multisig is a 5-out-of-7 Harmony’s Gnosis Safe with elected custodians.
CUSTODIANS:
Open nominations for electing a diverse and engaged set of custodians from our community.
Any validator, delegator, holder may self-nominate or be nominated with Snapshot vote.
No team members or partners will participate in the election or the operations.
DATES:
7/13 Thur: This proposal posted on forum. Custodian nominations start.
7/27 Thur: Nominations and options finalized; Snapshot voting starts.
8/9 Wed: 2-week Snapshot voting ends.
We will be collecting feedback and answering questions with replies in the forum – as well as in this draft document. On 8/3 Thur, we will publish and send out the final copy via our Substack. See the forum, the answers and the result for the previous proposal HIP-30 (version 1).
Great question. On the surface, having more nodes directly equates to greater decentralization. However, the reality is a bit more nuanced.
Decentralization isn’t just about the number of nodes; it’s also about how they’re distributed and operated. Even if you have a large number of nodes, if a small group controls most of them, it could lead to centralization.
Additionally, we must consider the balance between node size and the network’s performance. A network with many nodes might have slower transaction processing times and higher fees due to the increased overhead of communication and consensus between the nodes.
Thus, we aim for a balance: a node count that ensures a reasonable level of decentralization and maintains the network’s speed, efficiency, and affordability. This way, we can provide the best possible experience for all Harmony users.
In this case, each node is tied to a given stake weight. Fewer nodes may result in an increase of that weight, making it more difficult for groups to control each node.
We’re a No vote if the minimum fee isn’t raised to 6.7%. Its unreasonable to expect validators to incur a 25% reduction in potential commission while feeling pressure to keep a minimum fee of 5%. The race to the bottom theory begins to apply in that case. Also, many validators are operating on a contractual basis with cloud service providers and those contract costs can’t be instantly cut by 25%. Otherwise we vote Yes to reducing to 200 nodes and everything else proposed.
To add to what Theo and Casey have already said, fewer slots do not necessarily mean less decentralization. This is because a single validator may control more than one slot. The EPOS protocol is designed in such a way that we can keep everyone after the change and even elect new validators. This could be done simply by having all validators free up slots that they are not using. However, the fight for more delegation and better APY is what incentivizes delegators to do this today.
The issue we have with making this a poll on a public forum is everyone and their dog can vote. Generally speaking the public / delegators will vote for validators fee to stay at 5%, asides from a selected few who understand the situation, being that validators costs will be increasing with 1s due to disk space requirements and processing power, coupled with decreased emissions.
So if this poll was to gain validator opinions on the optionals ( given this directly affects us ) on whether it makes it into the governance vote then unfortunately it won’t be accurate.
In my opinion these two optionals would be better suited to their own governance votes ( Only if they have to be separate from the main HIP30v2 )
With HIP-30 intended, in part, to facilitate the recovery process, has Harmony commented on the recent events involving its recovery partner Tranquil?
Can Harmony clearly state that how a validator votes will NOT affect whether they’re eligible for the “Validator Fellowship” program? This is to assuage any concerns that Harmony could potentially “buy votes” by only supporting validators who vote in favor of HIPs proposed by the Harmony team.
From how I’m reading this, the “custodians” will need to be elected and have setup the multisig prior to the hard fork going live? Since the emissions can’t be directed to the multisig until the custodians create it, right?
“Recovery Multisig follows strictly the operations of the current burn.” Can you clarify what this means?
Good questions. What happened with Tranquil? Also, your idea of buying votes could be extended to the emission DAO as well. How do we know that some big validator isn’t just echoing an outside person’s initiative that doesn’t benefit the recovery or depegged asset holders? We need more details here.
Has there been any simulation to see what the expected return would be with half (or less than half the number of slots) while taking away only 25% of the emission?
Would the expected return be higher than it is now? I realize that the return would be less for Validators that are maxed out on keys now, but not sure about smaller validators.
I’d be happy to schedule an AMA with the VDAO twitter account @Casey@theo1 and @sophoah. We just need to figure out the best day and time for everyone.
We recognize the interest and anticipation surrounding Tranquil’s next steps. We have previously mentioned that from a technical standpoint, there are indeed no obstacles preventing the launch of Tranquil V2.
However, it’s important to note that the Tranquil team is the ultimate decision-maker concerning their project’s future. They have the best understanding of their project’s goals, strategies, and timelines.
While we are continually working to enhance our ecosystem, we respect the independent decision-making process of each project, including Tranquil’s.
A multisig address will indeed need to be included for the hard fork, there will be a snapshot vote for the nominations that will go live along with the HIP-30v2 snapshot vote.