The Three Pillars of Polygon Governance
Protocol Governance
System Smart Contracts Governance
.svg)
Community Treasury Governance
.svg)
Protocol Governance
Protocol Governance facilitates decentralized maintenance and development of the Polygon tech stack.
Community Vision Board
PIP Framework
The Polygon Improvement Proposal (PIP) framework was developed to facilitate open-source maintenance and development of the Polygon PoS chain. There are four categories that a PIP can fall into: Core, Contracts, Interface, and Informational. The framework aims to provide an efficient way for coordination and consensus to emerge naturally around upgrades.
The Polygon Protocol Governance Call (PPGC) is a technical call that brings together various core developers and community members to discuss protocol development. This collaborative effort involves updates from research teams, as well as discussions on particular proposals for protocol improvement. It's an opportunity for technical participants to share knowledge and support each other as we build the Value Layer of the Internet together.
Are you a technical participant looking to get involved with protocol governance? Read more about the PPGC calls here.
The Polygon ecosystem currently includes several solutions at varying stages of maturity. For example, Supernets and the recently-launched zkEVM are protocols in earlier phases of development. It's important to note that the PIP framework might eventually be extended to other protocols as well.
How can the existing PIP framework be extended to the Polygon zkEVM and other protocols? Are there lessons in the ecosystem that we can draw from? Share your thoughts in the comments section of this post.
Decentralized Community
The PIP framework provides a clear and transparent mechanism for proposing and implementing changes to the PoS chain and other protocols that choose to adopt it. To drive this process and allow the PIP framework to reach its full potential, a vibrant, decentralized community represented by a diverse range of network participants is needed.
Polygon Labs is currently funding a PIP bounty program with $40,000 in rewards, which will be distributed over one year to contributors of high-impact PIPs. The bounty program, likely the first but not the last, is meant as an invitation for the community to provide input in shaping the future of Polygon protocols.
If you have any PIP ideas that could help improve the Polygon PoS chain, please share them with us in the comments section of this post. The Governance team is also there to help you navigate the PIP process.
Governance participation is a complex topic and demands crisp, bite-sized, and simple educational initiatives by and for the community.
How do you envision Polygon's Governance Wiki and this Three Pillars vision board improving? We invite editors, content writers, and experts to contribute to the knowledge base of Polygon. Feel free to provide your comments in this post.
System Smart Contracts Governance
System Smart Contracts Governance facilitates the upgrades of protocol components that are implemented as smart contracts.
Community Vision Board
Upgrade Classification
For smart contract upgrades, designing an efficient governance process requires breaking them down into mutually-exclusive and collectively-exhaustive components. In the Polygon stack, there are 2 types of upgrades:
- Regular upgrades
- Emergency upgrades
Regular upgrades address regularly-scheduled upgrades. Emergency upgrades resolve exploits and vulnerabilities critical to network health.
The process of upgrading system smart contracts will (in most cases) begin with a Polygon Improvement Proposal (PIP). To make it easier for the community to generate, maintain, and track PIPs, there is active exploration toward an open-source PIP website.
Do you have an idea on how to create interactive, easy-to-use, and impactful templates for emergency or regular upgrades? Share your thoughts in the comment section of this post.
The Polygon Wiki is an actively maintained source of knowledge for information about smart contracts in the Polygon protocol. This includes the pillars and processes related to upgrades, composability, and security.
Leave feedback or contribute to the Wiki to help the community better understand smart contract upgrades and how decentralized decision making works on chain.
Timelocks & Security
Timelocks (before an upgraded is implemented) play a crucial role in the network’s security. Token holders can exit a protocol or veto potentially malicious upgrades. To be considered an emergency upgrade, the Polygon Protocol Council would require a supermajority consensus (10 out of 13 council members).
The table below summarizes the timelock and consensus requirements. After an upgrade, the council will issue either an autopsy or a transparency report to the community, depending on the type of upgrade, i.e., emergency or regular.
(10 out of 13)
(7 out of 13)
It is proposed that the Polygon Protocol Council reviews all regular upgrade PIPs, with a proposed framework for a 10-day timelock window.
Once the Council reaches a consensus to queue an upgrade in the timelock, the Council must submit a "Council Transparency Report" (CTR). During the timelock, the community may veto the upgrade if quorum and majority consensus are met. If there is no majority opposition, the upgrade will be executed when the timelock expires.
In the case of an emergency upgrade, there is no timelock. However, the Council must reach a super-majority consensus for the upgrade to be classified as an emergency. After the vulnerability is fixed, the Council will submit a Council Transparency Report (CTR) for community transparency and Council accountability.
In essence, timelocks provide security and decentralization by allowing the community to make the final decision. If you’re looking to contribute, please share your perspective in the comment section of this post.
When the Council queues an upgrade in the timelock, they might need to submit a Council Transparency Report (CTR).
CTRs are meant to simplify complicated technical upgrades into understandable parameters for the community. The community can read the CTR for a brief overview of the upgrade and/or review the entire source code of a proposed upgrade.
Emergency upgrades are given high priority by the Council and this comes from the potentialities for vulnerabilities. For an emergency upgrade, the Council will submit a Contract Transparency Report (CTR). An admin/executor from the Council will generate a CAR or CTR using a form, which will automatically generate a detailed CTR for community review.
Do you have ideas or suggestions for building a Council Transparency Reports generator? Write your high-level ideas in the comment section of this post.
Community members may choose how they would like to be notified of proposed upgrades. There are a variety of options, that range from receiving no notifications at all, if voting power is delegated, to getting notified only when the voting window opens.
We are interested in hearing your thoughts and ideas about governance notifications. Please share with us in the comments section of this post.
Protocol Council
The Polygon Protocol Council consists of 13 members who act in the interest of the ecosystem and compose a multi-signature wallet. The Council has three primary governance responsibilities:
- Executing regular upgrades;
- Executing emergency upgrades; and
- Providing transparency to the community through Council Transparency Reports for both regular and emergency upgrades.
The Council’s 13 members are representatives from diverse parts of the ecosystem. The community would be able to modify the Council membership by removing members and proposing new ones.
The Polygon Protocol Council is the governance body responsible for performing regular and emergency upgrades to system smart contracts, i.e. components of Polygon protocols implemented in the form of smart contracts on Ethereum.
The Polygon Protocol Council is composed of:
• Jordi Baylina (Polygon Labs)
̐• Viktor Bunin (Coinbase)
• Mariano Conti (independent)
• Justin Drake (Ethereum Foundation)
• Gauntlet
• Mudit Gupta (Polygon Labs)
• L2Beat
• Zaki Manian (Sommelier Finance)
• Anthony Sassano (The Daily Gwei)
• Liz Steininger (Least Authority)
• Jerome de Tychey (EthCC)
• Mehdi Zerouali (Sigma Prime)
• ZachXBT (independent)
The Transparency Dashboard will provide transparency to every on-chain action taken by the Ecosystem Council. It should serve as an interface and record of all transactions and data related to all system smart contract upgrades, allowing for greater auditability and accountability.
Version 1 of this dashboard will go live soon. What are some features that you would like to see or build with us? Let us know in the comments section of this post.
Voting Power
To align incentives and introduce conviction-based governance, a vote escrow system is currently under exploration. Here’s the high-level consideration for which community feedback is critical:
- Users can lock tokens for a period of time, with longer lock-ups resulting in higher voting power. Furthermore, the voting weight gradually decreases as the tokens approach their lock expiry.
- The tokens used in governance should also be usable to secure the network at the protocol layer.
- Delegating tokens is easy. Holders can delegate some or all of their tokens and un-delegate at any time.
Inspired by Curve DAO’s Vote Escrow, a model currently under consideration would allow for token locking to increase one’s voting power. The token lock-up could be renewed at all times and the token voting weight could gradually decrease towards the expiry of the lock-up.
Let us know your thoughts in the comment section of this post.
A delegation process is proposed, where token holders can choose to delegate a portion or all of their tokens to a representative. Their tokens will be added to the account's voting power, adjusted with the conviction multiplier coming from the token lock-up.
A zero-knowledge enhancement of the delegation process can be considered, enabling private delegations in order to remove various concerns with public and transparent delegation processes, e.g., voter coercion.
If you would like to recommend ideas for a voting delegation model, let us know in the comment section of this post.
Voting Process
A window for community voting opens whenever an upgrade is queued for the timelock by the Council. Supposing there isn’t a majority opposition, then the upgrade is automatically executed after the timelock has ended. However, if the quorum is met for majority opposition, then the upgrade is cancelled.
Our goal is to create a seamless, simple, and privacy-first on-chain voting experience. This experience will require the highest standards of transparency and security, and will feature adaptive quorums, dynamic voting power, time lock windows, and transparent council reports.
We welcome all ideas for building this system. Please share them in the comments section of this post if you would like to contribute.
Our goal is to create a seamless, simple, and privacy-first on-chain voting experience. This experience will require the highest standards of transparency and security, and will feature adaptive quorums, dynamic voting power, time lock windows, and transparent council reports.
We welcome all ideas for building this system. Please share them in the comments section of this post if you would like to contribute.
Community Treasury Governance
Community Treasury Governance facilitates ecosystem and public goods funding for the longevity of Polygon protocols.
Community Vision Board
Community Treasury Board
We propose creating a Community Treasury Board to support the ecosystem. This body will govern (at least initially) the Community Treasury to fund projects and public goods, ensuring the continued growth of the ecosystem. By promoting open-source technologies and financially supporting various public goods, the Board will foster innovation and creativity among developers, entrepreneurs, and other stakeholders through funding programs, grants, and community events.
We want to invite the Polygon community to participate in nominating members of the initial board. The Board would be responsible for upholding the collective growth of the ecosystem and protocol, and will be selected from among community participants. In latter phases, the community might eventually be able to modify the Council membership by removing members or proposing new ones.
You can participate in nominating board members by checking out this post.
To build a healthy community and secure the system, it's essential to have open communication between the board and the community. We envision the Community Treasury Board and the community working together from the get-go, which is why we propose the creation of periodic board transparency reports and an open-sourced dashboard for community funding proposals.
How else can transparency be fostered? Leave your thoughts here.
Community Participation
Our proposal is to gradually increase the community's responsibility and authority in the decision-making process. In the initial stages, a council of ecosystem members will be responsible for selecting applications and distributing funds on-chain, ensuring transparency throughout the process. However, the overall framework should be geared towards community-led allocation of funds, project selection, voting, and implementation, which may be facilitated by innovative governance models in later stages.
A community comprises different stakeholders, such as token holders, delegators, contributors, and validators. Balancing the opinions of all stakeholders in the right proportion requires exploring novel voting mechanisms, such as quadratic voting and reputation-based voting.
What are some interesting voting models for distributing community-led funds? To contribute, comment here.
The potential scope of public goods funding mechanisms goes beyond the crypto ecosystem itself. As Vitalik put it: "They're going to be a potentially significant part of how humanity ends up building the 21st century."
Initially, we propose that the board collect and review all PFP submissions, as well as gauge community sentiment in order to come to decisions on the distribution of funds. In the latter phases, the process of review and selection may evolve to enable more direct community involvement. However, while the board may serve as a security gateway for funds, the community could provide feedback and propose the underlying parameters for evaluating public goods and ecosystem projects, such as funding categories, as well as project, team, and impact assessment.
What parameters do you think are important when operationalizing and evaluating the distribution of funds towards public goods and ecosystem growth? To contribute, comment here.[Protocol Labs]. (2021, November 20).
Funding public goods — Algorithms and mechanisms - Vitalik Buterin [Video]. Youtube. https://youtu.be/i_t4VhisO1Y
As outlined in the Tokenomics Whitepaper, the Community Treasury is funded by a predetermined emission of POL. The emission rate proposed is 1% per year, or ≈100 million POL in absolute terms, and can not be changed for 10 years. This guarantees strong ecosystem support, critical for development, growth and positioning of the community treasury.
What do you think about the proposed Community Treasury model? To contribute, comment here.
A framework enabling formal participation in the funding process could be developed, similarly to how the PIP framework serves protocol governance.
PFPs would be publicly available, accessible and submittable by anyone, giving the community a means of communications with the community board. While non-binding, the community might be empowered by social consensus to propose Polygon Funding Proposals for the board’s consideration.
What would be potentially important components to be included in the PFP framework? Contribute here.