The Second Pillar: System Smart Contracts Governance

Polygon System Smart Contracts Governance

A need for security, as well as for the ability to seamlessly move to an improved version under specific circumstances, dictates the requirement for upgradeability as it relates to core pieces of blockchain architecture implemented in the form of smart contracts. These types of contracts usually have the ability to influence user funds directly or indirectly via manipulation of the infrastructure and its desired functioning.

The need for upgradeability of system smart contracts has been apparent for some time in the L2 space. From Optimism, through Arbitrum, to Zksync, the need for an efficient way of patching bugs and otherwise upgrading crucial pieces of the architecture persists.

While the underlying motivation for upgradeability is clear, the expression of that motivation varies between different types of contracts. A mechanism for upgrading the sequencer in a zk-based rollup will operate under a different set of risk assumptions than a bridge contract securing user funds. While both of them may be considered system smart contracts, the way that upgradeability is approached can differ greatly.

In this post, we want to present some of our initial thinking into the governance of upgradeable contracts as it relates to Polygon protocols.

The Tradeoffs

As was mentioned in the introductory post, one needs to balance multiple potentially-competing interests, including decentralization, immutability, and security, when designing governance frameworks.

On one end of the spectrum, we can see multi-signature wallets (or councils) composed of trusted community members as the only group capable of performing system smart contract upgrades. These types of setups are widely considered the most efficient in executing time-sensitive upgrades targeting dangerous bugs. However, they’re largely criticized for the concentration of power in the hands of the few, with potential dangers connected to keys being compromised or mishandled, resulting in catastrophes, e.g., Ronin bridge hack. One potential countermeasure against these types of scenarios is wide-spread timelocks, which require every council-initiated transaction to be held in a timelock before execution, allowing the community to look into the upgrade and exit the system with its funds (or coordinate countermeasures otherwise), were a malicious transaction to be initiated. At the same time, timelocks can’t fix everything - since the transaction is public once initiated, any potential hacker may inspect it and extrapolate the knowledge of how to exploit funds before the upgrade goes through, thus rendering timelocks dangerous for critical bug fixes.

On the other end of the spectrum, one can see a fully community-owned upgrade process, with tokens serving as a proxy for voting power. These types of systems, with seemingly less concentration of power, tend to solidify influence around several wealthy and active governance participants, if not enough thought was put into the specific voting model. While growth and adoption of decentralized governance primitives happens slowly, we can hopefully look towards complex voting structures that include delegation and weighted token-voting gaining traction. Importantly, one of the most crucial security guarantees for a community-owned upgrade process comes from the community. Social consensus and coordination are capable of providing the last line of defense for any decentralized governance. A highly-informed community provides a strong backbone for the decision-making process, ideally consisting of experienced communicators who ensure governance participants can’t be easily tricked or manipulated.

The Proposed Ecosystem Council Model


In this post, we seek to propose a potential future decentralized, community-controlled Ecosystem Council security model, capable of addressing the need for contract upgradeability in existing and upcoming Polygon protocols by use of decentralized and permissionless governance. The goal would be to introduce community checks for contract upgradeability, all the while retaining necessary security guarantees for Polygon protocols to flourish. We want to improve on the status quo by drawing the best from both worlds of decentralized community control and efficient council governance. The following proposal reflects the initial thinking around the subject by the Polygon Labs’ team.

Generalized Mechanism

In short, we envision an Ecosystem Council consisting of highly-reputable, technically-efficient, and value-aligned individuals, electable and removable by the community, and capable of performing timelock-limited upgrades to upgradeable system smart contracts across Polygon networks, e.g., Polygon PoS and zkEVM. While still being explored, the Ecosystem Council elections could be triggered by the community either when particular conditions are met (e.g., upgrade initiation) or at all times.

We’re concurrently proposing direct checks on the Ecosystem Council-proposed upgrades coming from the community. These might, for example, include the ability to veto any upgrade added to the bridge upgrade timelock as it relates to Polygon PoS.

Community participation, in the form of voting, might happen via use of the $MATIC token in order to provide a solid economic incentive for one of the most important pieces of Polygon architecture.

It’s important to note that community checks on the Ecosystem Council’s actions, with the likely exception of global governance parameters, will need to be adjusted for each Polygon protocol separately. For example, Polygon zkEVM’s architecture may dictate considerably different flows of system smart contract upgrades than the Polygon PoS chain.

In our considerations, we tend towards an optimistic governance model, which passes agency in active management to the contracts to the Ecosystem Council, while retaining ultimate checks on Emergency Council’s powers with the wider community, as expressed by vetoes and elections. This type of governance can minimize requirements for active governance, voter fatigue and apathy, as well as potential attack vectors connected to, for example, regularly held elections.

The Ecosystem Council for Polygon PoS chain

Current System Smart Contracts Governance

In order to visualize the proposed setup further, we use Polygon PoS as an example of a mature solution where the Ecosystem Council governance may be a suitable candidate for introduction.

The upgrades to Polygon PoS components implemented as smart contracts currently happen via the use of contract Polygon Improvement Proposals (PIPs). In contrast to core PIPs, contract PIPs can not be implemented via on-chain consensus, i.e. client software updates. Instead, they have to be upgraded by a party designated as the “admin” in these contracts. The PIP framework provides a social coordination layer for signaling for the admin to execute on.

On the technical level, various important parameters for the general infrastructure of Polygon PoS, such as the staking contracts on Ethereum, and the bridges between Polygon PoS and Ethereum are restricted such that they can only be called by a timelock contract.

In order to affect such a change, a proposal must be made to the multisig wallet, on which the admin, a community-owned multisig, then votes. Assuming a quorum of signers approves the proposal, the proposal is then queued in the timelock. The current wait time is 48 hours, and lowering this number is itself a timelock-restricted parameter, meaning that a proposal to lower the timelock’s minimum threshold would also need to wait for 48 hours prior to execution.

Once the required time has passed, the multisig creates a proposal to execute the change in the timelock. Assuming quorum is reached, the timelock is called, and the queued calls are executed.

General Community Competencies on Polygon PoS

In order to introduce community checks on the Ecosystem Council’s ability to propose and execute upgrades using the previously mentioned admin multi-sig, the community would be empowered by three main competencies via a vote, proposed and executed on-chain:

  • Election and removal of Ecosystem Council members;
  • Exiting Emergency State; and
  • Vetoing any upgrade proposed and scheduled in the timelock by the Ecosystem Council.


As mentioned before, the current Polygon PoS setup has a multisig at the base of all upgrades to the network, securing upgrade transactions with a timelock.

As of the time of writing, the timelock applies uniformly to all transactions that the multisig wishes to execute on Polygon PoS’s contracts. Similarly, the timelock is the only restriction placed on a proposal by the multisig.

We propose altering both of these characteristics. To do this, the Ecosystem Council’s actions would conceptually be split into two categories: vulnerability and routine (non-vulnerability) proposals. The difference between the two is if the proposal seeks to protect funds potentially at risk.

In the case of routine proposals, the Ecosystem Council will make a proposal and proceed with the timelock as before. There is the possibility of increasing the timelock minimum to 10 days over 48 hours (the current minimum), as these proposals should be non-urgent by nature, and this would allow the community more time to review them, making sure they are what they claim to be. Were a malicious proposal to be initiated, the community would have the ability to:

  • exit the chain with their funds via bridging;
  • initiate a vote to reject the Ecosystem Council’s proposal;
  • initiate a vote to replace Ecosystem Council’s members.

For sensitive proposals, i.e., user funds being at risk, resulting from potential exploits in the StakeManager or bridge predicate contracts for example, the Ecosystem Council would first enact an Emergency State, i.e., freeze on Polygon PoS’s bridge. In cases where there is a vulnerability in a bridge, this would effectively freeze funds in the bridge so that they cannot be exploited. In cases where the vulnerability is not in the bridge contracts, this still restricts the movement of funds, which would be a net positive.

Once the Emergency State is enacted and the bridge is frozen, the Ecosystem Council would have the ability to initiate time locked (shorter than routine proposals) upgrades, as well as bypass the timelock entirely if the transaction is signed by a supermajority of Ecosystem Council members, e.g., 10/12 consensus, instead of regular 7/12. The Ecosystem Council’s ability to bypass the timelock is important in rare cases when a critical bug doesn’t directly relate to bridge activity and could be exploited regardless of a bridge freeze. Similar models for varying quorum requirements have previously been used, exemplified by ZkSync’s Security Council. A gradual decrease in Ecosystem Council’s competencies as they refer to overriding the timelock should also be further explored.

In the case of timelock upgrades preceded by an Emergency State, the community would have the ability to:

  • Veto the Emergency State, unfreezing the bridge and rejecting the upgrade transaction (with the exception of transactions overriding the timelock by use of supermajority);
  • Veto the upgrade but keep the Emergency State (bridge freeze), e.g., in case the upgrade is the wrong fix to the issue;
  • Modify particular members of the Ecosystem Council via the removal of existing signatories and proposing new ones.

The exact parameters of the governance module facilitating such votes should be discussed further and are considered one of the more important open questions.

Open Questions

It’s important to note that the potential rollout of such an Ecosystem Council model would need to be carefully planned and gradually implemented. It’s by all means a daunting task for a live blockchain to implement such a complex governance system.

As with our previous posts in the Three Pillars series, we want to invite community participation in providing feedback to the model laid out here from the beginning, as well as ask the ecosystem for assistance in answering some of the open questions, as well as identifying those we might have missed.

Community Building

For a healthy governance framework, wide community participation is crucial, especially as it concerns defining moments, e.g., Ecosystem Council elections or critical bug fixes.

  • Are there viable, proven ways to incentivize participation in similar models?
  • What are some of the initiatives that the ecosystem could be undertaking today to grow the community of security-aware participants?

Governance Module

As mentioned before, the particular decision-making system employed in this model is of great importance. Some of the areas we’ve been focusing on are the general design principles, voting power proxy, and architecture.

General Design Principles

  • The module should tend to minimize regular active participation, but maximize community responsiveness when it really counts - how can this be achieved?
  • The module requires the right quorum parameter - have there been succesful experiments with variable quorum mechanisms used for token voting?
  • The module will likely require some form of delegation - have there been experiments to create healthy delegation for optimistic governance?


  • The module should live fully on-chain, requiring no off-chain dependencies in order to reduce risks
    • This requirement limits our considerations around the voting power proxy. For example, any viable sybil resistant quadratic voting mechanism will need to depend on off-chain data, fed into the system by an intermediary.

Voting Power Proxy

  • The voting power proxy should provide wide ecosystem inclusion and resulting legitimization of the Ecosystem Council
  • The $MATIC token could be considered as proxy for voting power:
    • It provides the widest set of security guarantees at the economic layer;
    • The token is well-distributed among ecosystem participants;
    • However, simplistic 1 token = 1 vote model risks leading to concentration of power
      • Are there other mechanisms that could be considered here?

We want to thank everyone for taking the time to read and engage with this proposal, as well as all of the previous ones (The Three Pillars of Polygon Governance & First Pillar: Protocol Governance). Please feel free to leave your thoughts below or in a standalone discussion thread.


Mateusz Rzeszowski

Will Schwab


Hudson Jameson

Bojana Tomic

Samuel Furter

Wenxuan Deng


We at Tally enjoyed reading the Second Pillar document, thank you for sharing!

We are starting to see onchain council elections emerge as a common governance pattern in the Ethereum ecosystem. We are quite interested in supporting the Governance Module for the Ecosystem Council for the Polygon PoS chain. With that in mind, we have some initial thoughts about the architecture of the governance module:

  • We think it’s worth considering a governance-specific ERC-20 as the governance module token. Native gas tokens are generally incompatible with onchain governance patterns like Governor. Perhaps there could be a wrapped MATIC token used for governance, or something to this effect.
  • Perhaps it would be possible implement a formula for obtaining the $MATIC governance token (e.g. wrapped MATIC) that could reduce concentration of ownership. Maybe some formula where the amount of wrapped MATIC received as a function of $MATIC owned decreases with size. Maybe this could be combined with attestations to reduce exposure to sybil attacks. Just a thought!

Excited to continue the conversation!


That’s great to hear and thanks for sharing your thoughts!

That is also my current thinking.

Do you see any viable attestation mechanisms that would enable us to ensure Sybil resistance without falling into the trap of one entity having to control the issuer?

I think it’s also important to avoid any off-chain dependencies like the plague here.


Great to hear you are thinking similarly re: wrapping $MATIC for governance.

Very aligned on avoiding offchain dependencies. I don’t think there is an easy answer here. One approach could be to create a list of both onchain and offchain activities that we think are valuable and hard/unlikely to sybil, and use those to create a multiplier on the amount of wrapped $MATIC received. Optimism and Arbitrum both implemented something like this for their airdrops. Optimism included activities like signing Gnosis Safe transactions, onchain voting, and donating to Gitcoin. Arbitrum included unique transactions over longer periods of time and transaction value. Other ideas I’ve considered: Committing code on Github (and can verify account with address), sending money to ZachXBT (recent), being a solo validator, creating an onchain DAO proposal that passed, having at least .25% of a DAO’s tokens delegated, being on Polygon for a long time.

Optimism: Airdrop 1 | Optimism Docs
Arbitrum: $ARB airdrop eligibility and distribution specifications | Arbitrum DAO - Governance docs

Airdrop is certainly good, but I want to believe in the reliability and stability of the network with small commissions and be confident in the safety of funds! :innocent:

Thanks for sharing! My 2 cents here

  • I guess it’s crucial to build a community of growth hackers like maybe a hacker’s dev shop who will be incentivized in $MATIC if they find the bugs in the contracts.
  • I see many protocols considering the governance token to establish the ability to vote on the proposal, but I think we need something more than this to creamify the contributions like for example

Onboard the contributor who should have some $MATIC tokens in the wallet & as soon as he/she will connect then we should mint the “newbie” NFT & also social ids, based on the contributions the NFT value will increase. This way I guess we can create a very authentic community with less Sybil attacks

Happy to jam on this more

Thank you for providing me with the text of the Polygon System Smart Contracts Governance proposal. I understand that the proposal is to create a new governance model for Polygon, called the Ecosystem Council. This council would be responsible for approving upgrades to system smart contracts. The council would be composed of “highly-reputable, technically-efficient, and value-aligned individuals” who would be elected by the Polygon community.

I have a few questions about the Ecosystem Council. First, how would the council be elected? Would there be term limits? How would the council be removed if it is not performing its duties effectively?

Second, I am concerned about the concentration of power in the hands of the Ecosystem Council. If the council has the power to approve upgrades to system smart contracts, then it could potentially make changes that could harm the Polygon network. How would the council be prevented from abusing its power?

Here is our reply to the second pillar! Thanks for your patience.

This particular pillar is the one that resonates most strongly with the problems we consider and try to solve at Aragon. 100% in agreement that security is the top consideration when evaluating each decision in this proposal.

Like many others, trying to tackle some of the biggest challenges facing decentralized governance, we at Aragon are very conscious of the tradeoffs described in this post, between efficiency through centralized control of a specialized group of experts vs slower, more pluralistic decentralized governance. Regarding the former, using an Ecosystem Council, as a form of indirect representational governance, is a solid recommendation putting more weight on progressively decentralization. Recent literature on DAO governance has recommended leaning on insights from representational political systems, rather than the often impractical utopian DAO vision of direct democracy, with everyone having a say on things that they may not have expertise in. Even in ancient Athens they strove to mitigate this.

To have a better understanding of the Ecosystem Council, one improvement to this proposal could be some elaboration on the relationship between the council and the community multisig (the link in the forum post is a dead 404 error). For example, would the council eventually replace this multisig or would the council just be one of many members within this multisig? These questions could help determine how critical a veto even is, and perhaps if it’s even necessary at all - a point I’ll return to in a moment.

A potential strategy to progressively move away from the centralized multisig could be merging the council and legacy multisig signers into a unified governing body. For example, the Ecosystem Council could have full contract upgrade permissions, but instead of having all seats appointed by token-holders, it could be done gradually - initially, 1 out of n signers, with the rest appointed by Polygon Labs. The shift from Polygon Labs to token-holder-appointed signers could evolve over time, conditional upon market metrics that ensure incentive aligned actors have sufficient power as opposed to those who don’t. Two valuable metrics could be the ratio between TVL in bridges vs. token price and token distribution metrics.

“The module should live fully on-chain, requiring no off-chain dependencies in order to reduce risks”

With a modular DAO framework such a design could all be done trustlessly. For example, using Aragon OSx, we envision the ability to appoint a particular number of multisig singers as a conditional permission granted to a token-voting plugin governed by token-holders. Then, the rest of the signers could be controlled by Polygon Labs (another multisig or similar). This Polygon Labs address could also have the permission to incrementally increase the number of signers that the governance token voting plugin gets to appoint. Right now, this could be done with custom plugins, but we’re aiming next year for making this done purely with granular conditional permissions, and fully exposed in our UI for transparency.

“Social consensus and coordination are capable of providing the last line of defense for any decentralized governance.”

It goes without saying that a token-based veto could allow non-incentive aligned (could even include those who have discovered contract vulnerabilities themselves and stocked up on the governance token, collaborating with hedge funds, etc.) to bring upgrades to a halt, leaving these discovered vulnerabilities unfixed and exploitable by those with the knowledge. Although with Polygon’s wide distribution this is less likely to happen and a veto mechanism does, at the end of the day, leave the power in the hands of token holders.

What we are certain of is that there are asymmetries between the value created by community members, whether it’s their sharing of knowledge, engagement, mission commitment, etc. and their actual token holdings. The community is more than their bags, but such a governance model does not capture this. For this reason, we believe that incentives should be central to any governance design, and right now

“The module should tend to minimize regular active participation, but maximize community responsiveness when it really counts - how can this be achieved?”

The problem is a fundamental one, and not something that can be fixed with workarounds. Here are some additional factors that show how compounding this problem is:

  • Safeguarding the contracts demands both responsiveness AND deep expertise; narrowing the pool of viable community members to take on such a role.
  • If attackers increase their token holdings, the demand for the community to come together and self-organize against them grows even further, creating a token arms race that financialized actors have incentives to play, and a community that doesn’t.
  • Usually when the community is most needed is when they are the least motivated. Lacking expertise, in crisis situations, even lay voters can be swung by narratives of a malicious actor.
  • Vetoing demands the same understanding as proposing but with the added challenge of being on a tighter timeframe.
  • With more Polygon products aiming to decentralize their governance over the years, the expertise required for token holders would increase further.

While this sounds overly pessimistic, security measures should specifically be designed against existential tail risks, and unfortunately not the “happy path”. Polygon should attempt to programmatically build in governance distribution over-time, potentially even considering a small inflationary % specifically designed for this. Grants cannot be the only way this happens.

Taking a more progressive approach like described above, with Polygon Labs members in more control of the contracts, until any of the aforementioned market metrics have reached targets, could be a much more forgiving starting point.

“What are some of the initiatives that the ecosystem could be undertaking today to grow the community of security-aware participants?”

This should be tackled regardless, and it would be greatly recommended to compensate Ecosystem Council members, such that there are incentives within the community to aspire for such a role. Education could be a critically valuable community initiative. This could act as both training grounds for aspiring Council members, but also to help the broader ecosystem understand the value of Polygon and the importance of security of Polygon smart contracts.

The dilemmas addressed here could be largely mitigated by a more mature market, and prudence will be essential in the meantime. We are confident in Polygon’s long term future, and don’t want to say “token go up”, but this is actually a really important step toward ensuring that the protocol can be secured by it in the same way that Ethereum is governed by ETH.

Regardless, we are here to help! Thanks! - Anthony

1 Like