Automatic

Contract calls at Ethereum block 25,539,164 establish the sampled owner, Safe, and timelock state reported below. Polygon’s documentation identifies active multisigs and their stated purposes, PIPs distinguish adopted designs from proposals still under review, source code identifies callable authority surfaces, and announcements describe institutional direction. Together these sources map a transition without turning three sampled contracts into a complete inventory of Polygon PoS governance (0xPolygon 2026; Polygon Improvement Proposals 2026).

The map contains the central result. A deployed Council and an uncompleted transfer are compatible facts. Treating the first as proof of the second erases the very transition that needs explanation.

Polygon’s live reference page supplied the active-multisig labels, and its governance-fundamentals page supplied the validator-consensus and Heimdall boundaries (Polygon Developer Documentation 2026a; Polygon Developer Documentation 2026b).

Three PIP-54 surfaces were selected because the proposal itself names them and because each exposes a directly callable owner() view.

The selector was 0x8da5cb5b (owner()). All three results decode to 0xCaf0aa768A3AE1297DF20072419Db8Bb8b5C8cEf, the legacy timelock identified by PIP-54. This is positive evidence about three rights at one block. It is not evidence that every proxy admin, AccessControl role, Polygon-chain right, or operational permission remained unchanged.

The Safe calls supply the other half of the map. getThreshold() used selector 0xe75235b8, getOwners() used 0xa0e67e2b, and the timelock getMinDelay() call used 0xf27a0c92.

The match between PIP-77 and the two Council owner sets verifies membership implementation. It does not verify the next edge in the graph: Council Safe → legacy contract right. No sampled owner() call produced either Council Safe.

The pos-contracts source explains why a single governance noun is inadequate.

Governance.sol exposes a forwarding call behind onlyOwner. Governable.sol separately defines onlyGovernance by comparing the caller with the contract’s configured governance address. In StakeManager.sol, governance-gated functions include forced unstaking, validator thresholds, checkpoint intervals and rewards, validator-contract addresses, dynasty values, proposer bonuses, minimum amounts, and MATIC-to-POL conversion. migrateValidatorsData and insertSigners are instead onlyOwner.

Validator-data migration follows an ownership gate, and token conversion follows a governance gate. That separation is substantive. Code establishes those callable paths, while state at block 25,539,164 establishes who occupied three sampled ownership positions.

PIP-29, a Final proposal, created a thirteen-member Council for specified Polygon 2.0 system contracts. It described a 7/13 regular route with a ten-day delay and a 10/13 emergency route without the ordinary delay. It also published selection principles: value alignment, operational resilience, limited Polygon Labs influence, and technical, security, and governance competence (Polygon 2023).

The membership changed over time. PIP-67 replaced four 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). At block 25,539,164, the two Council Safes contained the PIP-77 address set.

The appointment record is less complete than the key record. PIP-67 says its two incoming members were approved by existing Council members. PIP-77 describes “our recertification process” but does not identify the recertifying actor with equal precision. It is therefore accurate to describe documented recertification and incumbent involvement in PIP-67. It is not established that every later change was “Council-led” in the same way. PIP-29 leaves term length unspecified and allows the Council to add or remove members through the PIP framework. Fixed terms, a public recall path, general conflict rules, and external review remain thin in the reviewed documents.

PIP-54 and PIP-68 must then be read as transition documents. PIP-54 says the emergency Council Safe “will become” sole owner of listed proxies and that specified operational roles “will be transferred” to the standard route. PIP-68 proposes replacing signers and changing the threshold of the two legacy Safes while preserving their addresses (Polygon 2024d; Polygon 2025b). Their Peer Review status, the active-multisig documentation, and the sampled owner calls all point in the same direction: the proposed institutional destination cannot yet be narrated as a completed general transfer.

PIP-50 is a Continuous, Informational framework for regular system-smart-contract proposals. Its sequence is precise. The ordinary PIP process and Council consensus come first. Staked-POL holders and delegates then signal approval or veto through an adaptive quorum. The proposal returns to the Council for confirmation and on-chain execution, or for a decision not to execute (Polygon 2024b).

Polygon’s November 2024 launch announcement said this signaling was live through the Governance Hub. The same announcement supplied the decisive limitation: a veto has no on-chain enforceability, although the Council “can and should” take it into account (Polygon 2024c). The participants are stakers and their delegates, not an undifferentiated public. The mechanism concerns regular proposals, not the emergency route.

That design makes the signal institutionally visible but non-executing. The mechanism can be classified from the published design, while its use in contested decisions remains unmeasured. Evaluating Council practice would require proposal-level evidence connecting each signal to confirmation, execution, delay, and any divergence.

Treasury governance is analytically separate from system-contract governance. Under PIP-40, the Polygon Labs-operated Proposer Safe could introduce actions, while the Community Treasury Board’s Executor Safe supplied separate on-chain approval. The proposal expressly said Polygon Labs could not distribute funds without that approval (Polygon 2024a).

On January 9, 2026, a Polygon forum announcement described a new allocation of institutional roles: the Treasury Board would move from governing to advisory work, the Polygon Foundation would set long-term strategy, and Polygon Labs would manage day-to-day execution and publish biannual reports. The announcement called the change a transition and said the former governing role was ending (Polygon 2026b).

Those statements establish Polygon’s represented direction. They do not identify every affected wallet, contract role, activation transaction, or surviving approval constraint. Without those artifacts, the supported wording is “Polygon announced a transition,” not “all Treasury authority moved.”

Walch (2017) and De Filippi and Wright (2018) direct attention to the distance between decentralizing vocabulary and operative control. The implementation map makes that distance testable. For each executable position, five questions follow.

The IETF supplies a bounded institutional comparator. Its nominating process, rotating terms, recall procedure, and standards-process appeals expose safeguards around appointed technical authority (IETF 2000; IETF 2020; IETF 2022). It is not a blockchain, does not govern upgrade keys, and does not reproduce Polygon’s economic incentives. The comparison supplies questions to ask of an appointed technical authority, and it assigns no score.

Polygon’s documents answer some of them. Selection principles are published, Council membership and threshold changes are inspectable, the standard route has a delay, and staker signaling is visible. The remaining gaps are also concrete: appointment procedure, fixed terms, general conflict rules, public recall, treatment of contrary signals, and review independent of the executing body.

At the July 15, 2026 snapshot, selected Polygon PoS system-contract authority is best described as an incomplete, layered transition.

The unusual feature is a governance transition whose destination was more legible than its completion. The Council’s keys, membership, thresholds, and delay could be verified; the general transfer edge could not.

This description is narrower than calling Polygon PoS either a DAO or a Council-governed chain. The chain has validator consensus and a Heimdall governance module beyond the scoped contracts. On the three sampled Ethereum ownership surfaces, the recorded owner remained the legacy timelock, while the Council Safes and their thresholds were separately observable. The evidence does not support extending that result to every PIP-54 right: the complete rights graph, role inventory, and execution history remain unfinished. Which institution held a particular act must therefore be established right by right and block by block.

Uniswap and Arbitrum remain outside the comparison. A supported cross-protocol comparison would need the same variables and implementation-state evidence for each case. Borrowing one visible feature from another protocol would add breadth while weakening identification.

The incomplete-transition account should be revised under any of four observations.

These conditions make the classification sensitive to implementation. A renamed institution or a revised proposal, without state change, would not be enough.