Hello pDAO!
Given that the on-chain voting system is likely to see its first use fairly soon, this seems like a good opportunity to address its last major inconsistency with Snapshot signaling: the quorum.
Context
Context
In short, the inconsistency stems from the fact that not all vote-eligible RPL automatically receives voting power in the on-chain pDAO system. Nodes that were created before the Houston update need to actively initialize their voting power lest it be zero. RPIP-4 defines the quorum as 15% of total vote power, but as long as some nodes remain uninitialized, there remains a discrepancy in total vote power between these two systems.
pDAO initially agreed on 50% being a safe minimum to activate the voting system. There was a slow and steady climb, supported by some calls to actions on Discord and other social media by community members. This activation then saw a delay from the Houston Hotfix. Based on the achieved vote initialization rate of 50% at the time, it was agreed to set the on-chain quorum (proposal.quorum) to 30% in order to match the absolute amount of vote power needed with Snapshot’s 15%.
Since then, there have been two major changes. Firstly, Smart Node added an auto vote initialization feature, which submits a transaction to initialize a node’s vote power in the background if the gas price is below 5 gwei (configurable default). Secondly, the Houston Hotfix included contract changes that initialize the node’s vote power when it creates a new minipool or stakes more RPL. The combination of these two things has brought the total share of initialized vote power up to 80%. This in turn means that the on-chain parameter now corresponds to 24% of total vote power instead of 15%. We should fix this.
Suggested Solution
Setting the on-chain parameter to around 18% would solve the problem for now, but would also create the need for at least one more parameter change once the initialization has progressed even further. Fortunately, the Houston Hotfix contracts also include a function to permissionlessly initialize any node (rocketNetworkVoting.initialiseVotingFor). Now, the idea is to pay to initialize the largest remaining nodes to get us close enough to 100% that we can set the on-chain parameter to 15% and, for all intents and purposes, eliminate this inconsistency. This will be funded by the community via an initialization POAP.
I think 90% is a reasonable threshold, mapping to an initial equivalent of 13.5% Snapshot quorum and trending closer to 15% as more initializations come in organically after this initiative. Currently, we need 158 nodes to achieve this.
Each initialization is around 275k gas, totaling 43.45M gas to get to 90%. At a reasonable gas price of 5 gwei, this amounts to a total of roughly 0.22 ETH.
POAP
Each POAP is 0.006 ETH, the equivalent of initializing 4 nodes and can be minted at https://checkout.poap.xyz/183395. With a maximum of 50 POAPs, this gives us enough funding to get to 90% with a small buffer to balance out POAP taking a 10% cut of the sales and the potential of more expensive gas and not all POAPs being sold. The ETH will go to my address (haloooloolo.eth) and I’ll use my Safe to create bundles of 50 initializations at a time to make it as efficient as possible. Thanks to @ShfRyn for the POAP art!
Veto Quorum
A secondary point that I would like to bring up is the veto quorum, a concept that does not exist in Snapshot. In addition to voting against a proposal, the on-chain voting system has the option to vote against with veto. For this, it defines a separate veto quorum (proposal.veto.quorum). If the veto quorum is reached by the end of the vote, the proposal is rejected and the proposer’s bond is burned, regardless of other vote tallies. This parameter is currently still set to 51%, which effectively renders it useless. My suggestion would be to match the normal quorum at 15%. I am also interested in other opinions here as I think arguments for it being higher or lower than the normal quorum can both make sense. Note that a change to less than 15% is slightly more involved as the current contract guardrails restrict it to ≥ 15%.