Researching network updates and governance

Updates: How to deploy changes to the particular software running on each node that allows each node to function correctly.

Governance: How changes to the meaning of ‘correct functioning’ are proposed, discussed and implemented.

I’m hoping this topic can be a place to explore existing work on these areas and see what has worked pretty well and what has not worked well / lessons learned.


Dash uses 10% of the block reward to fund its own development.

The Decentralized Governance by Blockchain (DGBB) system allows each masternode to vote once (yes/no/abstain) for each proposal. If a proposal passes, it can then be implemented (or not) by Dash’s developers.

Sentinel is an autonomous agent for persisting, processing and automating Dash governance objects and tasks.

Whitepaper on the treasury system, ie the governance system for dash:

Some insights of how the treasury may be improved

“… miners were being paid too much based on what they are providing the network. Because of Dash’s technological advancements on the masternode side with Chainlocks and chained InstantSend, the security provided by the miners, while important, was not worth the 45% they were being paid by the network.
In a vote that passed handily, the Dash network voted to gradually reallocate the block reward away from the miners and toward the masternodes. A current 50-50 split after the treasury is paid out will become 60-40 in favor of masternodes over a period of a few years.”

List of proposals for how to spend the 10% budget (also has a link to past proposals):

5325 dash budget per month ($385K USD approx).

2663 dash per month ($192K USD approx) for core group compensation (50% of total).

Pretty interesting to see the list of things that are proposed and funded. Some marketing. Some dev. Some legal. Mostly around 50 to 500 dash per proposal.

Experience of this model from a game developer:

“we were a little disappointed with the amount of feedback we received, with only a handful of responses which made valid points about the direction of Dash in general but ultimately weren’t particularly useful or relevant to our specific case.”

Shows that having a system of governance is one thing, but having people engaged with it is another. Governance needs participation to work well.

My first impressions of dash governance: The 10% levy is higher than I would have thought viable, but it seems to work pretty well, better than I would have expected. They seem to have learned a bit about the pros and cons of their approach (see link above) and are able to act on changes pretty efficiently.

One question I have is that governance is often better when it’s slow; it’s meant to be a series of deliberate well-considered acts and undoing a poor decision can be quite difficult. Does this model allow too much speed? It seems crazy to say ‘more sand in the gears please’ but some friction maybe acts as a necessary rate limiter and quality filter. Not sure where the balance lies on this. From the looks of it dash governance isn’t under any stress, but I wonder if that’s because of the strength of their governance system or if it’s just going smoothly for some other reason.

I’m not especially familiar with dash so if anyone has any more insight I’d be keen to hear it.

Any other networks with useful lessons around governance or network upgrades please post it here. I’ll keep trying to add more as time permits.

Bitcoin protocol forks/upgrades is an obvious one to cover.
I’d like to cover some approaches to staggered updates and rollbacks in traditional web apps (any tips?).
Anyone know any networks where nodes are forced to update (ie not operator initiated updates)?
What else?


Tezos and Polkadot “I’m drunk at the moment so can’t post in depth” :sweat_smile:


With Storj updates are automatic (can be stopped manually). You can be part of the network with several versions old software, but after a certain version if you do not update they kick you:


Interesting topic and in the absence of known examples, a few thoughts from position of ignorance…

Update and Governance process needs to evidence that Safe Network is for everyone, in the same way as higher level features. Which suggests it needs to avoid politics! Which suggests it needs to be rooted in the fundamentals of that Safe Network is for everyone and for their Privacy; Security; and Freedom. Anything beyond that is politics.

Reduce risk and reduce discontinuities wherever that is possible, will reduce the politics that is always a liability over time.

What is an update?

Is it fundamental to data storage and retrieval; or is it some enhancement to performance; or is it economics.

If it is fundamental, then that is like changing species and a big dev choice rooted in real insight into the problem and understanding the solution is necessarily the best.
If it is some enhancement for performance or economics, then perhaps that is a choice that becomes political… and can we accommodate everyone’s interest by allowing all?


For core updates, I wonder if we can take inspiration from nature and the way evolution occurs… a common species with backward compatibility, might allow for “better” to prove itself and usurp the old because it is better. I guess that newer fast nodes will pull the network forward and older nodes will die over time.

To date the thought is one network but I wonder there is merit in a network that evolves, with nodes that prove themselves better and then movement of data follows that.

The risk accommodating variety is assurance that the data will not fail. If there is limited variety, just perhaps the v1.0 and v1.1 in play, then perhaps that is manageable…and data duplication to compensate risk that the new is not proven?.. does this suggest perhaps that data between some v1.0 and v1.1 becomes split as 50:50 for a time that evidences it works and then v1.0 nodes get forced update to v1.1; perhaps the initial push of v1.1 is random too.

What the network is and what it is not

Is there any case for allowing variety? The chatter about multiple networks is interesting, if that was ever to be some common base that allowed different higher layer apparent network.

Variety in the base, seems a liability and too difficult to manage… but that perhaps that challenge, helps define what is the network and what is the application. If there is ever confusion about that some application capability needs to be incorporated, then there needs to be a push against that.

Perhaps defining clearly what the network is not, is important. The simpler the network is, the less often updates will be needed and the more stable and less controversial those will be.

So, an example… by way of challenging what is base data storage and what is network capability and what is application: if one group of users wanted a network that allowed access to the unSafe internet, how would that look alongside the network as planned not allowing access to http:// ? In theory, it could be possible to have the same data storage layer, hosting two distinct networks. Whatever example is useful here but the point being, the elements of update that are affecting one interest in “what” the network does, are distinct from “how” data is stored.

So, breaking down what are different interests that are difference perspectives… the “what” is distinct from the “how”; etc, allows flexibility and variety in the ownership and actioning of updates… if everyone gets the update they want, there is no problem.

A problem might arise where there is only one solution that does not cater for all?.. then you get calls for governance that is making political judgement and not providing solutions for everyone.


Interesting points @davidpbrown. One other issue to bear in mind is that a decentralised network will not in itself guarantee a more equitable system of governance. Without measures to prevent it (sand in the cogs if you like), it’s likely that the core developers will become very powerful indeed. After all, they are the ones who understand the complex technology, and they will be the ones releasing updates to the code.

So there needs to be some sort of separation of powers by which responsibility for approval of new code and its implementation are devolved to the wider community, which is a slow but necessary process IMO. Maybe eventually some of this can be automated, but not in the early days.


Not an issue for those who are established dev contributors … perhaps the notion of who is elder, can apply here too.

1 Like

Pretty popular coin, currently 19 on coinmarketcap with 1.3B USD cap and 137M USD 24h volume.

Their main catchline is very focused on upgrades and governance - Tezos addresses key barriers facing blockchain adoption to date: smart contract safety, long-term upgradability, and open participation.

Tezos’ modular architecture and formal upgrade mechanism allow the network to propose and adopt new technological innovations smoothly as they emerge.

all stakeholders may participate in network upgrades by evaluating, proposing, or approving amendments.

Their get started page leads with these upgrade mechanisms so it seems central to their unique value offering.

Underlying economy is proof-of-stake.

They mention some other projects to look at in the roadmap section: “Newer consensus algorithms like Algorand or Tendermint, which have finality and higher throughput, will be usable on Tezos.”

How new proposals move through the process, explained in the self ammendment section: The self amendment process is split into 4 periods: Proposal Period, Exploration Vote Period, Testing Period and Promotion Vote Period. Each of these four periods lasts eight baking cycles (i.e. 32,768 blocks or roughly 22 days, 18 hours), comprising almost exactly three months from proposal to activation.

A lot of information about the pros and cons of on-chain governance in the arguments section. I really highly recommend taking a look at these links.

Looking into the actual governance data on chain, elections is a handy resource. The code for each proposal is hashed and then all onchain activity for progression of that proposal is tied to that hash.

Here’s an example proposal named Athens and the onchain stats for it can be found in election 11.

Looks like there can only be one proposal at a time and there’s 3 months to get through each one. So far seems like there’s been 24 elections. Some were rejected so it seems like the process is not just a facade, people do participate in a considered way. But I haven’t looked deeply into it so if anyone knows more about the reality of this system would be good to hear about it.

Overall for me the most value was from investigating the links in the arguments section exploring the pros and cons of on-chain governance. Probably worth summarizing the content of those links in another post. I was surprised how strong the arguments are for avoiding on chain governance and automatic node upgrades.


Tezos community are a nice bunch. There’s one fella that is really approachable with decent connections if we want to poke and ask questions. Even Arthur Brietman (probably misspelled :grimacing:) would probably be up to answer a couple of questions on Twitter.

Good project to model upgrades over. They just successfully voted in a new upgrade named Delphi, I think.


Futarchy is another form of governance that is interesting.

1 Like

That was a fascinating read! I wonder if you could build an online guild that could fulfill the roll of government using this idea. So one would not have this be a physical nation but a virtual one maybe housed on something like SafeNetwork. You join and receive the right to vote on values bet on beliefs.
Could we use an Augur like platform to accomplish this?
It seems this could be tested much more rapidly in a virtual way than a nation. Who knows maybe it would be adopted by nations at some point.

1 Like

You might like this post too.

1 Like