← Back to trust

Polygon

Automatic

Polygon's sampled upgrade route retained a legacy Safe and zero-delay timelock alongside deployed Council infrastructure. Appointment, signaling and review must be evaluated against those configured rights.

ContentsBrowse sections

Abstract

Three sampled Polygon PoS ownership slots retained a legacy timelock while separate Protocol Council signing infrastructure was deployed. Role queries connect the legacy Safe to that timelock. A source reproduction identifies its executable rules, a historical receipt dates the minimum-delay change, and a recent transaction shows three zero-delay operations through the route. The July 2026 and October snapshots distinguish the Council’s existence from its control of these particular contracts.

The sampled contract rights give appointment, consultation and review a specific object. An appointed body’s mandate must be connected to the actions it can authorize and the constraints affected participants can invoke. Staked-POL signaling supplies a documented advisory route; a separate Treasury announcement reallocates organizational responsibilities without completing its implementation map. The records support comparisons of public mandates, configured authority and observed action. Other privileges and responses to disagreement remain unresolved.

1. An Institution and the Office It Occupies

A council can have named members, published selection criteria and deployed signing infrastructure before it controls a particular contract. A contract can retain the same owner address while the institution authorized to act through that address changes. Neither a governance label nor an address, taken alone, resolves who can do what.

Delegating specialized decisions to a small body can be reasonable: participants may want expertise, operational continuity and rapid responses to faults. The relevant questions concern its mandate, appointment, conflicts, removal, reasons for decisions and opportunities for review. Those questions become answerable only after the executable office has been identified. A public commitment to consultation attached to one route does not automatically constrain another.

Polygon’s Protocol Council makes this problem unusually inspectable. Its proposals name signers, thresholds, timelocks, contract addresses and proposed transfers. A separate signaling framework gives staked-POL holders and delegates a role in regular system-contract proposals. These artifacts permit a comparison between the institution described and the rights configured, without treating Polygon PoS as governed through one mechanism.

The scope here is selected system-smart-contract authority. Polygon’s governance documentation separately describes client upgrades through ecosystem and validating-stake consensus, and a Heimdall governance module for consensus parameters (Polygon Developer Documentation n.d.b). Treasury administration is another distinct domain. The findings below do not classify the chain as a whole.

2. The Timelock Route and Its Use

Polygon’s October reference page still listed the legacy Ethereum Safe as the active PoS/staking upgrade multisig (Polygon Developer Documentation n.d.a). A label identifies the route to inspect; the contract responses supply the sampled state.

Object October observation What it identifies

StakeManagerProxy, GovernanceProxy and RootChainProxy

Each owner() result was 0xCaf0aa768A3AE1297DF20072419Db8Bb8b5C8cEf.

Three ownership slots held by the legacy timelock, consistent with the July sample.

Legacy Ethereum Safe 0xFa7D2a996aC6350f4b56C043112Da0366a59b74c

Five-signature threshold and nine owner addresses.

The configured owner-signature route of that Safe; module and guard checks narrow the map below, while other execution paths remain incompletely traced.

Council Standard and Emergency Safes

Thresholds of seven and ten respectively, with thirteen owners each matching the PIP-77 address set.

Council signing infrastructure and the sampled membership implementation.

Standard-route timelock 0x29A6f32f36EDeD399763524018F17F03B1435b18

getMinDelay() returned 864000, or ten days.

That timelock’s configured minimum; its application to a particular right requires the connecting authority path.

An ownership slot is one edge in an authority graph; the next edge here is the timelock’s role configuration. The new queries establish that the legacy Safe held both PROPOSER_ROLE and EXECUTOR_ROLE. The two sampled Council Safes held neither role. The zero address did not hold the executor role, and the timelock itself held TIMELOCK_ADMIN_ROLE. These checks identify a positive route from one Safe through a timelock to three sampled owners. They do not enumerate every role holder or exclude every alternative path.

The explorer’s verified-source response identifies a TimelockController-derived contract. Compiling its exact multi-file source with Solidity 0.8.7 reproduces all 11,395 runtime bytes returned by the block-pinned RPC call. That implementation gates scheduling through the proposer role and execution through the executor role, with open execution when the zero address holds that role. The returned state does not satisfy the open condition. The compiler comparison connects the queried roles to the sampled executable code (Blockscout 2026a).

PIP-54’s table describes the legacy Ethereum route as having a two-day timelock (Polygon 2024d). The legacy timelock returned a zero minimum delay. A historical transaction locates the parameter change: at block 20,606,116, on 25 August 2024, the contract emitted MinDelayChange(172800, 0). Matching transaction, receipt and block responses from two services confirm the dated transition. The receipt establishes when this parameter changed (Blockscout 2026b). The reasons for the change and any separate procedural waiting requirement remain unresolved. A proposal table therefore cannot substitute for the configuration and history of the route being evaluated.

On 13 October 2026, a transaction called the legacy Safe. Its MultiSend payload scheduled and executed three timelock operations in the same transaction, each with a zero delay. Their operation identifiers, targets and payloads reconcile between transaction input and the successful receipt. One operation targeted the sampled StakeManagerProxy and two targeted GovernanceProxy. The external transaction sender was a relay address, distinct from the Safe through which authorization operated. The transaction establishes an observed use of the route (Blockscout 2026c). It contains no contested signal, Council rationale or evidence that affected participants could revise the decision.

3. Two Designs for Changing Authority

PIP-29 established a thirteen-member Council design with a seven-signature regular route and ten-day timelock, alongside a ten-signature emergency route without the ordinary delay. It published selection principles concerning technical competence, security, resilience, value alignment and limited Polygon Labs influence (Polygon 2023).

PIP-54 then proposed direct transfers of specified Polygon PoS ownership and operational rights into Council routes. PIP-68 proposed another kind of change: replace signers and signature policy in the existing legacy Safes while preserving their addresses (Polygon 2024d; Polygon 2025b). These are institutionally different operations. One changes the contract holding a right. The other can change who acts through an existing contract without changing that contract’s address.

At the newly captured repository revision, both proposals still carried Peer Review status. The three sampled ownership slots retained the legacy timelock, and the legacy Ethereum Safe still reported five of nine. PIP-54 proposed different ownership destinations, and PIP-68 proposed seven of thirteen. This establishes a bounded discrepancy between two published designs and the sampled configuration. It does not show that nothing changed elsewhere or that a proposal’s status reliably records every implementation transaction.

The Council itself did change. PIP-67 replaced signer positions in 2025 and converted two individual Polygon Labs seats into organizational multisigs. PIP-77 replaced three members in 2026 while retaining the two Labs organizational seats (Polygon 2025a; Polygon 2026a). The October Council Safe owner sets matched PIP-77. A deployed Council and an unrealized transfer on particular sampled surfaces are compatible observations.

Appointment also requires its own evidence. PIP-67 says incoming members were approved by existing Council members. PIP-77 describes recertification less precisely. These documents support an inquiry into incumbent participation in selection; they do not establish an identical procedure for every appointment. Fixed terms, general conflict rules, a public recall route and independent review are not clearly specified in the reviewed PIPs. Relevant agreements or off-chain institutions may supply further provisions.

4. A Signal Can Matter Without Executing

PIP-50 describes an off-chain signaling sequence for regular system-contract proposals. The ordinary PIP process and Council consensus precede staked-POL holder and delegate signaling. The proposal then returns to the Council for confirmation and execution, or a decision not to execute (Polygon 2024b). It does not describe token voting as a substitute for Council authorization, and it does not place emergency proposals under the same sequence. This collection establishes the captured PIP’s design; it does not establish the current availability or use of the Governance Hub.

Lack of automatic execution does not settle whether consultation constrains authority. An advisory vote may prompt reconsideration, impose reputational costs, trigger an appeal or inform a later appointment. Conversely, a visible vote may leave affected participants without an effective response when the executing body declines to follow it. Neither outcome can be inferred from the interface alone.

The research task is to join the stages. For a disputed proposal, record the eligible population, signal and quorum, Council response, reasons, transaction or non-execution, delay and any subsequent challenge. Compare the route through which participants expressed a preference with the route through which the decision became operative. This would distinguish acknowledgment from answerability and answerability from a power to revise or remove the decision-maker. No such contested-decision sample is claimed here.

5. Treasury Roles Are a Separate Case

PIP-40 described a Labs-operated Proposer Safe and a Community Treasury Board Executor Safe with separate approval functions, stating that Labs could not distribute funds without the Board’s approval (Polygon 2024a). A 9 January 2026 forum announcement described the Board becoming advisory, the Foundation setting strategy, and Labs handling daily execution and publishing biannual reports (Polygon 2026b). That documentary account leaves relevant wallet controls, activation transactions and surviving approval constraints unidentified. It does not complete an on-chain map of Treasury power: a reporting commitment concerns explanation and review, while an execution role concerns the capacity to move funds.

6. Evaluating Appointed Technical Authority

Walch (2017) and De Filippi and Wright (2018) motivate close attention to operative control beneath decentralizing vocabulary. Tracing a disputed action requires identifying the officeholder, how that actor was selected and what the office authorizes. The inquiry then follows the constraints that can prevent, delay, revise or review the action, and the route through which an affected participant can invoke them.

The IETF supplies a useful comparison of institutional arrangements around technical expertise. Its documented nomination, confirmation, terms, recall and appeal provisions show how appointed technical offices can be surrounded by procedures for selection and challenge (IETF 2000; IETF 2020; IETF 2022). RFC 9389 updates NomCom eligibility under RFC 8713; the comparator must be read with its update chain (IETF 2023). These provisions concern different offices and institutional populations. They do not govern upgrade keys or reproduce Polygon’s financial incentives, and their existence is not a score for either system.

The comparison nevertheless sharpens the Polygon questions. A published signer list makes the key configuration inspectable. A term or recall rule addresses continued occupancy. A signal exposes a preference. A required response makes its treatment reviewable. An executable delay may create an opportunity to react, but only on the route to which it applies. These are different institutional functions, and one cannot silently stand in for another.

Mapping the executable office attaches those questions to a particular capacity. An announced Council cannot be credited with a right it has not been shown to hold, while a familiar address cannot establish unchanged institutional control. Dated documents, configuration and action allow both relations to be investigated.

7. Method, Scope, and Further Work

The study compares a July observation at Ethereum block 25,539,164 with finalized block 26,215,899, hash 0x17c96e7aba1dfd887aefa4d53302ea87544ffd6acc0922da05ab11c4bd027d33, captured on 17 October 2026 in Toronto. Two RPC services returned matching results for all thirty-one October request IDs; agreement does not establish independent upstream infrastructure. Sampling is purposive: PIP-54 names the three Ethereum contracts, each exposes an ownership view, and the associated Safe and timelock views permit a tractable route reconstruction. The sample is not a census of PIP-54 rights, Polygon-chain privileges, proxy-admin slots or validator governance. Role tests cover named candidate addresses; no complete role-member enumeration was performed.

At the same October block, all three sampled Safes returned an empty enabled-module list with completed pagination and a zero transaction-guard slot. Their fallback-handler slots were nonzero, and the legacy Safe reported version 1.4.1 while the Council Safes reported 1.3.0. These checks narrow the sampled execution map without identifying every contract-owner route, signer controller or privilege. Public key and address records do not identify legal persons or independent organizations.

Source capability, configured authority and exercised authority remain separate. The role result and additional Safe checks improve the configuration map. The two recovered action receipts identify successful uses of the legacy route and the dated delay change. They do not identify the legal or organizational controllers of every signing key, reconstruct all prior authorization changes or show how an incumbent responded to opposition. The Treasury and signaling material is documentary evidence with narrower implementation coverage.

The next empirical step extends these transaction records into a small sample joining appointment and mandate records, signals, reasons and executed changes. That would test how the arrangements work under disagreement. Completing every possible control edge is necessary for a whole-system claim, but the bounded comparisons above can already show where published institutional descriptions and specific configurations diverge.

Conclusion

The Protocol Council’s existence, the configuration of a Safe and the exercise of a particular right are separate facts. At the October snapshot, the sampled ownership slots still named the legacy timelock, the legacy Safe held proposer and executor roles, and separate Council infrastructure matched the documented membership. A historical receipt dates the legacy delay’s reduction to zero, and a recent transaction uses that setting for three operations. These findings locate a specific route and show its use without turning it into Polygon’s whole governance structure.

Appointment, consultation, reasons, review and removal acquire practical meaning through the offices to which they apply. For a disputed proposal, the next comparison should join the signal and Council response to the route that made the decision operative, then identify how affected participants could seek revision. That would test the institutions surrounding the observed capacity under disagreement.

References

Blockscout. 2026a. Verified Timelock source and deployed bytecode for 0xCaf0aa768A3AE1297DF20072419Db8Bb8b5C8cEf. Retrieved October 17–18. https://eth.blockscout.com/api/v2/smart-contracts/0xCaf0aa768A3AE1297DF20072419Db8Bb8b5C8cEf.

Blockscout. 2026b. Ethereum transaction 0x608c8a7e52b85a5c4501373f7a5e92efcfb4671b44586cdd5fb86e8b2cb55851, block 20,606,116, August 25, 2024. Receipt retrieved October 18, 2026 and reconciled through two RPC services. https://eth.blockscout.com/tx/0x608c8a7e52b85a5c4501373f7a5e92efcfb4671b44586cdd5fb86e8b2cb55851.

Blockscout. 2026c. Ethereum transaction 0x53ddccd09c36bde3691fc33282b54679019dad1f4f8aa9fdee0d44cd45b1ab65, block 26,182,820, October 13. Input and receipt retrieved October 18 and reconciled through two RPC services. https://eth.blockscout.com/tx/0x53ddccd09c36bde3691fc33282b54679019dad1f4f8aa9fdee0d44cd45b1ab65.

De Filippi, Primavera, and Aaron Wright. 2018. Blockchain and the Law: The Rule of Code. Harvard University Press.

IETF. 2000. “RFC 2850: Charter of the Internet Architecture Board.” https://www.rfc-editor.org/rfc/rfc2850.html.

IETF. 2020. “RFC 8713: IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process.” https://www.rfc-editor.org/rfc/rfc8713.html.

IETF. 2022. “RFC 9281: Entities Involved in the IETF Standards Process.” https://www.rfc-editor.org/rfc/rfc9281.html.

IETF. 2023. “RFC 9389: Nominating Committee Eligibility.” https://www.rfc-editor.org/rfc/rfc9389.html.

Polygon. 2024d. “PIP-54: Reassign Upgradeability Rights of Polygon PoS Contracts to Protocol Council.” https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/7ca861517bcdcba3e1f2b751762c6c2e786d7caa/PIPs/PIP-54.md.

Polygon. 2025b. “PIP-68: Reform Key Polygon PoS Multisigs to Integrate Protocol Council Members.” https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/7ca861517bcdcba3e1f2b751762c6c2e786d7caa/PIPs/PIP-68.md.

Polygon. 2026a. “PIP-77: 2026 Polygon Protocol Council Membership Update.” https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/7ca861517bcdcba3e1f2b751762c6c2e786d7caa/PIPs/PIP-77.md.

Polygon. 2026b. “Transitioning the Community Treasury for Polygon’s Next Phase.” January 9. https://forum.polygon.technology/t/transitioning-the-community-treasury-for-polygons-next-phase/21565.

Polygon Developer Documentation. n.d.a. “PoS Mainnet Multi-signatures.” Captured October 17. https://docs.polygon.technology/pos/reference/commit-chain-multisigs.

Polygon Developer Documentation. n.d.b. “Governance Fundamentals.” Captured October 17. https://docs.polygon.technology/pos/governance/governance-fundamentals.

Walch, Angela. 2017. “Blockchain’s Treacherous Vocabulary: One More Challenge for Regulators.” Journal of Internet Law 21(2), August. Author manuscript: https://ssrn.com/abstract=3019328. Institutional record: https://commons.stmarytx.edu/facarticles/515/.