Does anyone know how BTC makes that choice?
Let’s review this: https://bitcoinmagazine.com/technical/taproot-activation-and-the-lot-debate
Look at the debate. very interesting. They developed BIP8 and BIP9, two methods for activation. Debated the hell out of it. I’m wondering who actually said, we are using BIP8 or BIP9 for activation.
I think the lesson here is there was LOTS of debate over how to activate taproot.
Ya, I think we can add that. Would be nice for a few community members to do it.
I think this is really the key decision point for this and any future ZIP.
For Acceptance thresholds.
For Activation thresholds.
Depending on the type of ZIP.
What is too high or too low now? What will be too high or too low in the future?
First of all, thank you for all the effort you guys have put into this. Lots of good ideas. I have a few questions/comments specifically related to Stage 4 and the community vote.
Expecting at least 2/3 of all participating ZNN weight to be active, informed and willing to vote on proposals is quite a tall order. The correct threshold in such a voting process is obviously hard to define but will anyone really respect the vote results if the turnout is way below the threshold on a reasonable proposal?
Who has the authority to validate the results of this community vote? What happens if a majority of Pillars signal yes but the majority of the total ZNN weight signals no?
I assume that running this tool that determines the signalling results will require you to run a node for every blockchain that ZNN can be bridged to. If we build bridges to multiple other chains the tool could end up requiring a considerable amount of computing power and would not be something that could be easily run by community members.
Can the effort required to develop, maintain and run such a tool become a risk for this proposed ZIP process?
Will this tool be able to retroactively prove the results? As in will it be able to give the balances of all signalling addresses from all supported chains at the acceptance snapshot height?
How exactly are liquidity positions accounted for on different chains? As you know liquidity providers don’t hold wZNN, they hold a token that represents a share of the pools combined funds.
These are questions we asked ourselves and so far we didn’t feel comfortable in proposing hard consensus thresholds (for both, acceptance votes and activation). What might be too high of a quorum requirement today might be too low in a year. So unless we keep re-voting on fixed thresholds for different ZIP types and stages repeatedly, it might be better to just offer a general reference framework as guidance and leave it up to the ZIP authors to define what they think are sensible quora.
If they’re too low, the community will likely oppose and not accept the ZIP. If they’re too high, sufficient participation might not be achieved.
Ultimately, the only quora that really matter are those of sporks where full nodes agree to change the network. There, the threshold should be at least a supermajority.
Remember, no ZIP process definition can prevent node collusion hence all we do here is agree on best practices.
Regarding your answers on the tool to track and analyze signed messages, I’ll let @0x3639 answer that one.
But you’re making good points. Might be a lot more pragmatic to exclude LPs.
I don’t think we need to account for cross-chain wZNN versions for governance. What percentage of the supply of Proof-of-Stake chains is really living on other chains? I would say what percentage of BTC is living wrapped in ETH but it’s not like BTC holders get to vote for upgrades. Either way, number should not be big enough to become relevant.
People providing liquidity in other chains are incentivized by Orbital program and I don’t think losing their voting power will significantly hurt Zenon’s liquidity. In the event that they do want their full share of governance, they have the option to break the LPs, bridge back to Zenon, vote, then provide liquidity again when the vote process is over.
I will skip the tool altogether for now. Perhaps a simple version of the tool to also account for LPs network participants and their acceptance/support of the ZIP would suffice, but as an off-chain (to NoM) signaling not to be included in the official vote counting process.
I will have to second ToKR’s position of defining an ‘active pillar’ and trying to achieve a 90% quorum of active pillars as the way to go. As much as my gut is telling me the remaining flexible approach early in for Zenon is the way to go, a flexible quorum defined by ZIP authors seems troublesome.
I note that Romeos proposal was practical and achievable. He also wanted to build on it, once it’s implemented. I.e. in the spirit of „progressive decentralization“ which is now our network motto. Whereas where you’re going now, finding the optimal solution first before moving, we’re on the realm of theoretical solutions that won’t work in practice, I would guess.
I think what we are proposing is similar to Romeo’s original proposal, only we are replacing one central editor / repo with multiple editors / repos hosted by Pillars.
So if only one Pillar participated in the process, this is basically the BIP / Romeo process, with the Pillar as the central editor. We have a few unique features in addition to the BIP/Romeo process, but at the core, they are similar.
Do you disagree with that assertion?
The way I’m thinking about the voting tool, until it can be moved on-chain, is the following:
This obviously has holes in it, but without moving the vote on chain, I could not think of a better / faster way of doing this. Open to new ideas!
Just to see if I understand correctly, are we employing a ‘Token weighted voting’ system based on the amount of Zenon held by the individual? I’m not the biggest fan of such a system as it grants greater voting power to pillars/sentinels and other large whales. A more decentralized and fair approach imo would be to utilize a ‘One wallet, one vote’ system.
I was thinking that if we have a weighted vote, the denominator is the sum of all delegation, not the sum of all ZNN.
The numerator would be the sum of all delegated ZNN voting yes
So a weighted yes vote = (Sum of ZNN delegation to Pillars voting yes / Sum of all delegated ZNN)
This would exclude wZNN all together.
I think we are discussing a weighted voting system based on ZNN delegated to Pillars, NOT ZNN held by wallets.
I hear ya on whale influence. I’m worried it will be hard / impossible to get 90% of Pillars to upgrade and vote on a ZIP. If the vote is 90% weighted based on ZNN delegation, we can achieve upgrades more easily. Let me run some quick calcs are report back.
Agreed on excluding wZNN, but why exclude sentinels and stakers?
Alternatively, to ascertain/assess the community’s support for a particular ZIP we could temporarily make use of an already existing voting system like snapshot.org. Seeing as how wZNN is already compatible with metamask- all it would take is for someone to set up an ENS server and create a “space” on snapashot.
‘Admin’ status can be granted to pillars and ‘author’ status to ZIP proposers who must find pillar support to propose a ZIP to begin with. The advantage here being that everyone owning some ZNN would be able to connect to snapshot through their metamask wallet and vote.
If we did a weighted total at 90% of ZNN delegated to Pillars, the top 29 or 30 pillars could spork the network.
| Delegated | Cumm Sum | % Total | ||
|---|---|---|---|---|
| 1 | SultanOfStaking | 237,281 | 237,281 | 6.40% |
| 2 | QSR | 196,874 | 434,155 | 11.71% |
| 3 | ElderZ | 182,959 | 617,114 | 16.64% |
| 4 | tapwoot | 171,197 | 788,311 | 21.25% |
| 5 | ZenDAO | 165,125 | 953,436 | 25.71% |
| 6 | DeeZNNutz.com | 162,057 | 1,115,493 | 30.08% |
| 7 | Zed | 161,287 | 1,276,780 | 34.42% |
| 8 | ZenonOG | 150,495 | 1,427,275 | 38.48% |
| 9 | AlienBoyz | 145,059 | 1,572,334 | 42.39% |
| 10 | WaXe | 143,198 | 1,715,532 | 46.25% |
| 11 | apestrongtogether | 135,419 | 1,850,951 | 49.91% |
| 12 | WAGMI | 132,542 | 1,983,493 | 53.48% |
| 13 | bigdickenergy | 122,206 | 2,105,699 | 56.77% |
| 14 | Zygonidz | 121,858 | 2,227,557 | 60.06% |
| 15 | Toker | 117,941 | 2,345,498 | 63.24% |
| 16 | Vopo | 102,947 | 2,448,445 | 66.01% |
| 17 | Elements | 99,253 | 2,547,698 | 68.69% |
| 18 | Shigo | 95,987 | 2,643,685 | 71.28% |
| 19 | SolarSail | 89,194 | 2,732,879 | 73.68% |
| 20 | Asgardians | 74,618 | 2,807,497 | 75.70% |
| 21 | ZenonORG2 | 67,327 | 2,874,824 | 77.51% |
| 22 | ZenonORG | 66,685 | 2,941,509 | 79.31% |
| 23 | AncientPillar | 66,626 | 3,008,135 | 81.11% |
| 24 | EmeraldCap | 66,280 | 3,074,415 | 82.89% |
| 25 | StakeServe | 66,268 | 3,140,683 | 84.68% |
| 26 | Mariposa01 | 66,095 | 3,206,778 | 86.46% |
| 27 | Octopos01 | 66,061 | 3,272,839 | 88.24% |
| 28 | AREA51 | 60,902 | 3,333,741 | 89.88% |
| 29 | Nomverse | 57,742 | 3,391,483 | 91.44% |
| 30 | 707 | 57,498 | 3,448,981 | 92.99% |
| 31 | GreyZ | 46,659 | 3,495,640 | 94.25% |
| 32 | ZenonORG4 | 26,167 | 3,521,807 | 94.95% |
| 33 | Unizen | 25,297 | 3,547,104 | 95.64% |
| 34 | alien-valley.io | 22,112 | 3,569,216 | 96.23% |
| 35 | ZenonORG3 | 20,670 | 3,589,886 | 96.79% |
| 36 | Zeus | 14,743 | 3,604,629 | 97.19% |
| 37 | Zaulus | 13,799 | 3,618,428 | 97.56% |
| 38 | Milkdromeda | 12,822 | 3,631,250 | 97.91% |
| 39 | Zaurum | 12,360 | 3,643,610 | 98.24% |
| 40 | invictus | 11,996 | 3,655,606 | 98.56% |
| 41 | Zircon | 10,397 | 3,666,003 | 98.84% |
| 42 | Paradox | 8,199 | 3,674,202 | 99.06% |
| 43 | CH405 | 8,178 | 3,682,380 | 99.28% |
| 44 | ZENON.NETWORK | 7,772 | 3,690,152 | 99.49% |
| 45 | XYZ | 7,342 | 3,697,494 | 99.69% |
| 46 | Hybrid21 | 5,302 | 3,702,796 | 99.83% |
| 47 | LT | 3,663 | 3,706,459 | 99.93% |
| 48 | Inception | 1,230 | 3,707,689 | 99.97% |
| 49 | Swagmi | 1,000 | 3,708,689 | 99.99% |
| 50 | SPillar | 243 | 3,708,932 | 100.00% |
| 51 | ChadassCapital | 0 | 3,708,932 | 100.00% |
| 82 | zamiri | 0 | 3,708,932 | 100.00% |
Good question. When someone delegates to a Pillar they are saying, I support my “representative / Pillar” . Like a local senator. If the Pillar votes in a way the delegator does not like, the delegator can voice opposition by moving to a different Pillar. And that can happen BEFORE a final vote is tallied up.
Stakers are unable to make that signal. So I’m not sure exactly how their vote would be considered. I see them as agnostic. They are indifferent by choosing to not delegate.
Not sure on sentinels. We don’t know how they work exactly, so I excluded them for convenience.
At the core, you’re trying to define a zip process, so there’s the similarity.
You’re starting differently though, theoretical not practical. I agree with everyone who said it’s convoluted, and also e.g. doubt that you will achieve 2/3 majority in the foreseeable future.
But I haven’t followed each individual argument here, so maybe you’re over that already, it was just an observation.
I think it’s beneficial to start with what can work immediately, so I said whatI said to remind you of that; it’s easy to forget over all the discussion of details.
I agree 100%. I do think we will start with one pillar in this process. So in that regard we will start like the BIP process. We will screw it up, and figure out what does not work. We will fix it after a few iterations. Once we have a process that works, I think other Pillars will join in. And laying out the framework now to allow for other Pillars to join in the future will be easier to implement IMO.
I think we still need to work out how ZIPs get approved.
replying to shazz’s reply
if it is the case that at least 50% of pillars need to adopt the code (otherwise pillars are forking themselves out of the network), what is the point in allowing for a zip to choose a passing rate of <50%?
seems like in no world would that be a pass, so why let that be an option (referring to >25% of pillars AND >25% of delegation weight)
unlike other comments, I’m okay putting some technical onus on pillars, but I don’t like idea that you need a pillar to sponsor a ZIP… anyone should be able to propose a ZIP
lets assume ZNN success beyond our wildest expectations… pillars will be worth hundreds of millions, and there will be a lot of people trying to get their attention… I believe that good ideas can come from anywhere, such that we shouldn’t limit an idea by a requirement of being able to get attention from a pillar
As such, I think anyone should be able to propose a ZIP, and then pillars can choose whether or not to co-sponsor it
