What are the shortcomings of Polkadot's governance and what will its next iteration be?

Question

What are the shortcomings of the current governance mechanism in Polkadot and how will its next iteration address those?

Answer 1

Since the very first governance proposals were put up for discussion, the community already began thinking about alternatives and possible new designs to counteract some identified weaknesses in the model. Many community members have already identified the lack of participation as its weakest point. Others felt that the Council was the weakest aspect, arguing that, even if Council were to grow in number, this form of representation had no place in a decentralized on-chain governance system. Many community members, despite being able to delegate voting power and use conviction voting, also noticed a low representation of smaller token holders.

The Democracy module became a primary focus in recent discussions of the new governance design, as it allows all token holders to be able to propose, participate and be held accountable for the proposals they submit. All public proposals use what is called positive adaptive quorum biasing, meaning that as the referendum turnout increases, the threshold of aye votes required to pass lowers. Since making a protocol change comes with risk, this system was designed to favour the status quo. Positive biasing ensured that with lower turnout, only uncontroversial proposals can pass.

The new governance model basically builds on top of this, and aims for a more censorship-resilient type of design in which community members can participate in a secure and decentralised manner: The various Council responsibilities will be migrated to the community. The new model will define different origins for different calls: each of them will include different thresholds and turnouts needed for a proposal to pass. For example, a runtime upgrade (set_code call) does not have the same implications for the ecosystem as the approval of a treasury tip (reportAwesome call), and therefore different origins are needed in which different turnouts, approvals, deposits and a minimum enactment periods will be predetermined on the pallet.

What this means, in simple terms, is that different proposals submitted by the community will enjoy different approval thresholds, depending on the call up for vote. So, generally speaking, the new model will relay on three elements:

• transfer of responsibilities from Council to Democracy module;
• different origins for proposals, defining different tracks and therefore different required turnouts and thresholds depending on the call to be enacted;
• a more flexible way to delegate voting power by community members.

This new model should be up for discussion and vote by the community soon, and if a runtime upgrade in which the new pallets are invcluded is approved by the community, we should expect to see the first changes soon (on Kusama first, ofc). Some articles will be published soon on this to start the discussion!