Substrate Governance Workshop Berlin
On the 28th June (before Polkadot Decoded) Centrifuge hosted a Governance Workshop in Berlin, it was attended by people from Parity, Litentry Interlay, Acala Talisman, HydraDX, KodaDot, Robonomics and more 
. It was really fun with a lot of participation 
Our objectives were:
- Bring Governance nerds & builders in Polkadot together to have discussions
- Discuss the future of governance in Polkadot and for parachains.
- Figure out how to organize to better govern Polkadot and how parachains can learn from governance in Polkadot.
- Learn about how to transition substrate governance to a delegate based system and learn what is still needed
- Talk about both soft governance (off chain comms, tooling etc.) and on chain governance
Polkadot has been working on significant changes to ubstrate governance and it was with some of these changes in mind that we worked through our questions. Gavin Wood made this speech about Gov2 and there is a rough summary below (these notes are just an interpretation - if you interpreted differently, let me know in the comments).
Key improvements of Gov2
Two pallets (Referenda and Conviction) will be created which hold functionality listed below
There are two high level goals:
- Safety: Increase deliberation periods
- Agility: Increase the amount of referendum being proposed
Different kinds/levels of referendum come from different origins. Origin is basically the privilege level with which proposals will run, therefore all referendum run through the pipeline specific to its origin with the relevant parameters attached to that origin. Different referendum ‘tracks’ are defined by their origins and origins are wholly independent of each other
These are currently described as:
- Higher impact: ‘Root Call’ = can do anything
- Medium impact: ‘Bigspender’ = spend higher budget levels
- Low impact: ‘Tipping’ = tip contributors
Different Tracks can have different attributes and limits, including:
-
How many referenda are able to be decided simultaneously
-
Approval thresholds (at what threshold does a referenda pass)
-
Approval thresholds change over time - at the beginning the thresholds are high, at the end the thresholds are as low as they can be to allow agility, ‘if a referendum is very well supported we should allow it to pass sooner than a referendum that is more controversial’
-
‘Support’ is the number of ‘voters approving’ - votes for both Yay and No both increase turnout so Gov2 only counts the positive votes as a proportion of the total possible number of votes (measured ignoring conviction)
Different Tracks have different safety measures, i.e.:
- Increased lead-in periods (phases for getting referenda noticed, how long the discussion phase before voting takes)
- Differing time voting periods for different Tracks (ie higher for Root, lower for Tipping)
- Requirement on ‘confirmation period’ (the time a referendum needs to keep ‘passing’ to be enacted)
- Once a referendum starts ‘passing’ it has to keep passing until the agreed on confirmation period for the track it’s in is over (ie if it is a high impact aka Root it has to be ‘passing for the full confirmation period for the agreed upon time ie 2 days)
All submitted referenda need a minimal viable on-chain deposit for storage and will be immediately votable. However, these proposals would have to fulfil the following criteria in order to move to the deciding period:
The lead-in period is elapsed (to avoid decision sniping)
The proposal has reached the most votes in favour of approval (endorsements)
The Decision Deposit is paid (can be paid by anyone, including the original proposer)
Once a referendum enters the state of deciding, then it is eligible to be approved.
Delegation
- Implementation of Gov2 will remove council function and implement delegates function
- Multirole delegates - token holders can delegate to a different voter for each track
What happened in the Centrifuge Workshop (28.06.22)
We started by doing a checkin to surface the biggest challenges in substrate governance
The list was broad:
- Need for governance standards
- Rule by financial power (plutocracy vs democracy)
- Voter alignment / quality of votes
- SubDAOs/fractalization
- Legal compliance
- Protecting financial minorities
- Education / quality of input
- Identity
- Delegation/delegates
- Participation/incentives
- Useability/UX/tooling
- Project fatigue
We merged some overlapping topics and chose the three topics with the most votes to work on in small groups. They were Delegates/SubDAOs, Participation/Incentives and Useability/UX/Tooling. However ultimately we just did two groups and scrapped Useability/UX/Tooling
Main takeaways from Delegates breakout
Delegated governance is both about representing token holder interest AND building capacity in the DAO (ie helping people understand more about what is being voted on and why)
Different sized DAOs require different scales of governance (ie a small DAO with 100 active voter needs different parameters than a 2000 active voter DAO)
Questions
- With the introduction of Delegates in Gov2 can you specifically delegate your tokens to different tracks? Answer YES
- In the face of low delegate turnout in some projects, will tracks help Delegates vote?
- Is having tracks too complicated for already project fatigued token holders?
- How will good delegates get votes? (ie not just
- Will token holders pay attention to what their Delegates do? (both before and after they delegate to them?)
- How can we make being a delegate a ‘good thing’ (ie the opposite of politicians in real-life politics)
Ideas:
- Can we share delegates across projects? Ie delegate form SubDAOs with expertise in relevant tracks and go across DAO (i.e. to different parachains and help governance?)
Main takeaways from Participation breakout
- Participation is needed to prevent bad actors passing malicious proposals
- Compensated delegates can perform better
No fees for choosing delegates, lower on chain fees for delegates - Incentives for non participation (passes by default unless there is a dispute, ‘optimistic governance’. This relies on a good notification system (existing options include Web3 Alerts + Nova Wallet)
- Delegation locking period shouldn’t be too long
- Optimism has a good delegation period - relies on a good reputation level
Questions:
- Do we even need high participation? What other metrics are important to assess decentralization?
- How much participation is ideal?
- Should delegates have incentives? What about voters?
- How do we prevent malicious delegate behaviour
- How can we incentivize active participation?
- How do we prevent the loudest delegates from getting the votes
- Different participation levels for different types of referenda will be good
Ideas:
- Limit scope of delegates to specific areas
- Mandates for delegates
- In the long run governance should be a self running engine but in the near term it needs support
- Unlock the knowledge of the community
- We must keep constantly working on getting users to care so that they will vote (incentives, NFTs for participating in education programmes)
In conclusion
A highlight of the workshop was the positive attitude to collaboration between all the Polkadot Projects! And the fact that we had two dogs in attendance (who both peed on the carpet 
) Love those dogs.
Let’s keep discussing governance as Polkadot’s Gov2 is rolled out!
Thanks to @otar from Parity for clarifications on Gov2
