Extend Proposal Guardian Role for the Community Multisig

This proposal aims to maintain protocol security by extending the ProposalGuardian expiration timestamp. We are proposing a 48-month extension, effective through February 28, 2030, to ensure uninterrupted protection for the Compound ecosystem.

The ProposalGuardian role is currently active and held by the community multisig, with a scheduled expiration of September 12, 2026. This role was established as a critical fail-safe mechanism, allowing the multisig to cancel proposals that are identified as malicious or technically unsound.

While the current expiration is months away, setting the expiration to February 2030 provides a more robust buffer. It ensures more predictable readiness to intervene against high-risk or malicious proposals and enables the community to innovate with confidence for the years ahead.

Actions

Call setProposalGuardian on the Compound Governor contract to set the community multisig as the new ProposalGuardian, with an expiration timestamp of [1898467200] (GMT: Thursday, 28 February 2030, 00:00).

Tenderly Simulation Failure Explanation

Although the proposal simulation linked in the Tally UI is failing, the proposal should execute successfully in production.

Reasoning:

• Proposals are first submitted to the Compound Governor via propose().
• After the voting period ends and quorum is reached, the proposal is queued in the Governor, which then queues it in the Timelock.
• Once the Timelock delay passes, the proposal is executed in the Governor.
• The transaction calldata is first saved in the _governanceCall queue, and then the Timelock is called to execute the transaction.

During the Tenderly simulation, the Timelock is impersonated without Governor.execute being called, meaning _governanceCall is not populated. This causes the transaction to revert in the simulation, but in a real execution, it should succeed as expected.