Thread by @0xPolygon

1/10 Lately we've noticed discussions and, at times, concerns or misinformation about multisigs on Polygon. To address that, here is a quick

TRANSPARENCY REPORT ON POLYGON MULTISIGS

First, it is worth explaining why are multisigs even used by many popular crypto projects.

2/10 Smart contracts on Ethereum are immutable by design, i.e. can not be changed once deployed.

This is a feature, not a bug. Immutability provides guarantees that any funds you put into a contract will only be used according to that contract's code.

3/10 However, this feature has one big downside: if there is a bug or a potential exploit in the code, there is no way to fix it!

In such situations, hackers can potentially steal users' funds and absolutely nothing can be done to stop them.

4/10 That is why upgradable contracts were designed.

Upgradable contracts have proxies that are authorized to upgrade them. Proxies can be individual Ethereum addresses (EOAs), but this gives a lot of power and responsibility to a single address, so normally multisigs are used.

5/10 Additionally, upgradable contracts are very useful or even necessary when building quickly developing systems like scalability solutions, since they allow developers to implement regular upgrades.

These two important use cases are exactly why we use multisigs at Polygon.

6/10 Polygon uses three different multisigs, each for a different purpose.

MS1: PoS/Plasma contract upgrades
MS2: Custom "Child ERC20" contract upgrades
MS3: Mapping of "Child ERC20" contracts

All details about multisigs can be found in this document:
docs.matic.network/docs/faq/commi…

7/10 The first two are critical in terms of security, so they require 5 out of 8 signers.

The signers are Polygon cofounders and people* from reputable Polygon/Ethereum projects:

1. @CurveFinance
2. @QuickswapDEX
3. @MUSTCometh
4. @0xHorizonGames

*identities protected

8/10 As the contracts secured by multisigs become battle-tested, we will be exploring introducing the following optimizations/changes:

- Moving from multisigs to governance-controlled proxies;
- Introducing timelocks;
- (Eventually) Completely removing multisigs/upgradability.

9/10 So why not have governance control and timelocks right from the start?

Only because both require time to execute an upgrade. This further means that reactions to bugs and exploits are much slower, which increases security risks when contracts are still not battle-tested.

10/10 To summarize, multisigs are a common practice for securing and upgrading contracts.

Critical Polygon multisigs are controlled by Polygon founders and reputable people from the ecosystem.

We will be improving (adding governance/timelocks) and removing multisigs with time.