PIP-67: Update Membership of the Protocol Council

Polygon Improvement Proposals Canonical PIPs
1

PIP: 67
Title: Update Membership of the Protocol Council
Authors: Kaitlin Beegle, Harry Rook
Description: Proposal to update the membership of the Polygon Protocol Council
Discussion: TODO
Status: Draft
Type: Contracts
Date: 2025-04-15

Abstract

This proposal seeks to update the membership of the Protocol Council established by [PIP-29](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-29.md) to ensure continued operational efficiency and governance transparency. This proposal supersedes and should be read in conjunction with PIP-29.

Motivation

Refreshing the Protocol Council membership ensures alignment with evolving community representation, and maintains operational transparency and efficiency.

Updates to Protocol Council membership at this time were motivated by PIP-54 and PIP-XX, which jointly seek to improve the efficiency and decentralization of Polygon PoS by granting more efficient control over contract upgradeability to the Protocol Council. In preparing for this transition, all current members of the Council were asked to reconfirm their interest, alignment, and availability to serve on the Council.

As a result of this process, the updated membership list reflects the removal of Justin Drake (Ethereum Foundation) and Anthony Sassano (Daily Gwei). The removal of each member is proposed with their full consent and in no way is a reflection on their skills, abilities, or the quality of their contributions.

The below individuals are furthermore proposed to fill the seats left vacant by Justin and Anthony’s departure:

Pablo Sabbatella
Pablo Sabbatella, also known as pablito.eth, is a blockchain operational security researcher. He is the founder of Opsek, which offers operational security audits and training to web3 companies. He is also a member of SEAL (Security Alliance) and the Optimism Security Council. He is host of the Blockchain Security Series podcast.

Jack Sanford
Jack is the CEO and Co-Founder of Sherlock. Over the last 5 years, Jack has worked closely with hundreds of crypto teams to deliver successful security outcomes, including many of the biggest DAOs in the space. Jack has hands-on experience in high stakes situations including war rooms, exploit mitigation, and funds recovery. Jack has been a leading voice in the crypto security ecosystem, speaking about security topics at DevCon, DeFi Security Summit, ETHDenver, and more.

Each of the above members have been audited and approved to join by existing members of the Council.

The updated membership list also proposes replacing two (2) individual representatives from Polygon Labs Engineering and Polygon Labs Security teams- Mudit Gupta, and Jordi Baylina- with two (2) â…— multisigs, one held by each organization.

  • Polygon Labs Engineering will propose upgrade payloads while also acting in a traditional signer capacity.

  • Polygon Labs Security will ensure operational integrity throughout the upgrade process by verifying payloads through to execution.

Specification

This PIP proposes the reform of the signer composition of the Protocol Council, to be updated to the the list below. The existing multisig contract specification, including signature policies and timelock delays, will remain unchanged.

Updated Protocol Council Members

Name Affiliation Address
L2 Beat — 0xaE8B85DcaBb12EB2dDb11dAd1ed968b7eD81B410
Mehdi Zerouali Sigma Prime 0x6d52F5F1A46304Ee51dd63D33cf1A7Be67EB9250
Mariano Conti Independent 0x703728858Eea4994169f8177caB4F6dBA9783EAA
Gauntlet — 0x683a4F9915D6216f73d6Df50151725036bD26C02
zackXBT Independent 0xDd92aB9A4D6C9793969b3A10A11FC934D5d93a49
Liz Steininger Least Authority 0x6860Ab2888f71AC09bEdEBB594b5B50299aC7889
Viktor Bunin Coinbase 0xBb9D37Ae9e63a4517bE5CE1D98eB9D89938fb651
Jerome de Tychey ETH CC 0x1aE033D45ce93bbB0dDBF71a0Da9de01FeFD8529
Zaki Manian Sommelier Finance 0x096CA3674329bB66dD7CC14D1511dfB7728b9193
Multisig Signer Polygon Labs (Engineering) 0x4e981bae8e3cd06ca911fffe5504b2653ac1c38a
Multisig Signer Polygon Labs (Security) 0x9d851f8b8751c5FbC09b9E74E6e68E9950949052
Pablo Sabbatella Independent 0xAB4045C93e4eFFa9b325F706C9a690Ed00d08958
Jack Sanford Sherlock 0x342EBaca3ACC54d6f5Ee78073FeC4af07f42B94e

Backward Compatibility

This change is fully backward compatible, changing only the council membership.

Security Considerations

Key security parameters remain unchanged. Considerations need to be made to ensure new signers are selected to maximize jurisdictional diversity, availability, and responsiveness.

Copyright

All copyrights and related rights in this work are waived under CC0 1.0 Universal.

1 Like
2

Could you help us review this proposal by saying what those policies are? In particular, how many signatures are required for a quorum and what is the time delay?

3

It looks like this needs to be read in concert with https://forum.polygon.technology/t/pip-68-reform-key-polygon-pos-multisigs-to-integrate-protocol-council-members/21008 which proposes 7 of 13 with a 10 day delay

1 Like
4

I think it would be good if individuals at the organisations listed (L2Beat, Guantlet, Polygon Labs) were nominated, and were the only individuals at those organisations with access to the signing key. This would improve security and increase transparency.

5

@0xD0A4004d1916C0F93D yes, you’re correct! The signature and multisig policies for the Protocol Council are available in PIP-68.

In regards to your last comment, can you clarify what exactly you mean? The organizations that are listed are expected to sign securely, which means controlling access to their private keys. We do not list the names of individuals at each organization who are responsible for signing due to security reasons, but it is not the case that the entire organization has signatory authority.

6

Nominating individuals from organisations, and listing them by name, will increase accountability and security. Just having the organisation listed could lead to Employee A from Org A being the nominated signer, they leave Org A and hand over the signing responsibility to Employee B from Org A. The issue with this is that Employee A will retain some information about signing: for instance the pin number to unlock a hardware wallet.
Nominating the individuals in the company would increase the probability that when an employee leaves a company, a new key will be enrolled for a new signer employee, and the old key would be decommissioned.

2 Likes
7

Yes- this is a great point! :slight_smile:

However, there are two big reasons why naming individual signers is not preferable in this instance:

  • Multisigs intentionally represent organizations, not individuals. Oftentimes, signatory multisigs are comprised of a diverse group of people within an organization. Regardless of what one individual person may think about the utility, specification, or impact of a proposed transaction, their role is specifically to ensure the security of a proposed payload. Oftentimes, these organizations will undertake an internal security review prior to coordinating their signature. As such, many individual employees do not like to be named, because their signature on the transaction is not intended to reflect their personal assessment of the transaction itself.
  • Naming individuals makes them a target for exposure. Many named individuals on multisigs do so because they operate as known independent contributors or public professionals who accept the risk of being named. This requires that they adhere to specific security standards and behaviors to ensure that their keys are not compromised.

In other words, naming an org or naming an individual is an intentional choice. And in both cases, the individual or org that is selected is done so because they are security professionals. This means upholding standards, expectations, and internal processes to ensure that they remain secure contributors, regardless of the context.

In addition, we routinely check in with signers, ensuring that they 1) have not changed teams or signers, and 2) still have access to all pins, keys, ledgers, etc. :slight_smile:

2 Likes
8

That makes sense.
I am now in support of this proposal.

9

I support the PIP for the following reasons

  • I believe more (quality) members means better decentralization
  • I believe organization multisigs are more robust than individuals, as they reflect the opinions of the organization as a group and they are more robust to organizational changes such as people leaving the organizations

My vote: Weak Accept

Long answer: https://medium.com/@nodeinfra/polygon-governance-pip-67-557c78526fb7

1 Like
10

We support this PIP.
The proposed members have demonstrated credibility and a proven track record in security, making them appropriate candidates to fill the vacant seats.
Although DAO voting for such selections, which is implemented in some other L2 DAOs, could be valuable in the longer term, there is no pressing reason to pursue that path here, and we have no strong concerns with the current process.

That said, would you share some thoughts on the possibility of implementing elections or some other means to select council members, @kb17?

2 Likes
11

Hi @Tane, thanks for your feedback! The voting idea is one that we often think about.

There are a few reasons we don’t currently hold elections for members of the Protocol Council. These include:

  • Independence. The Protocol Council is a fully independent entity. To change members of the Council requires other members of the Council to agree and approve the proposal. Introducing elections or other similar processes often requires deploying smart contract mechanisms that are difficult to decentralize. While elections can seem more democratic, they aren’t necessarily more decentralized. It becomes a trade-off around point-of-control, and I believe we currently (currently) have the most optimized structure.
  • Security. The role of the Protocol Council is to review transactions and ensure the security of proposed changes to the Polygon network. Council members do not merely “vote their conscience”, or in their interest. They are professionals in network security and operations and perform technical diligence on the transactions they sign. Their job is to secure the network, which is a professional skill that many in the community (including myself!) do not have. Polygon’s Protocol Council currently has some of the best folks in blockchain security, and it’s not clear to me that there is a benefit in introducing a community voting structure to oversee their involvement.
  • Ease. Adding elections and/or delegations for Protocol Council members adds engagement requirements and complexity to processes that already work well. It’s not clear that there is a critical benefit to adding active community governance mechanisms to this structure.
  • Decision-Making. Decisions to accept PIPs still fall mostly to the community, via either the Community Forum or Polygon Protocol Governance Calls. Protocol Council members are not making decisions about what gets to go on the network; they’re confirming that accepted changes are correctly specified and appropriate. They themselves are the community oversight mechanism, ensuring that neither Polygon Labs nor any other engineering team is maliciously upgrading smart contracts against the wishes of the Polygon community.

I hope that answers your question! If not, or if you have follow-up questions or ideas, please let me know! I appreciate you asking your question.

Likewise, I wanted to ask you: is there a current governance function that doesn’t currently exist, which you’d like to see Polygon Labs help to develop? If anything comes to mind, please let me know!

2 Likes
12

I am a big fan of this change! It improves decentralization + accountability, and also allows for more efficient upgrades. Polygon is shipping non stop so efficiency is quite important right now.

1 Like