The Moonwell community has been steadfast in its commitment to pushing the boundaries of onchain governance, focusing on creating transparent, secure, and effective methods of governing the protocol. In line with this commitment, the community recently activated the Moonwell protocol on Base using a novel open-source governance framework we call Temporal Governance.

Designed to solve complex challenges in cross-chain governance and compatible with a large number of networks, this framework serves as a contribution to the broader onchain ecosystem as a public good. This article aims to provide an in-depth look at Temporal Governance and its significance for the Moonwell community and beyond.

Moonwell Governance

One overarching goal of the Moonwell community has been to create financial infrastructure that will stand the test of time and outlive any contributing team or individual. Applications and developers that build on top of Moonwell should have confidence that the protocol will have the resilience to operate indefinitely.

Pursuant to this objective, Moonwell Governance became the administrator of the Moonwell protocol on Moonbeam in August 2022. Since then, our engaged community has submitted 92 onchain proposals, the most of any protocol in the Dotsama ecosystem. The Moonwell app has evolved as well, now boasting a comprehensive governance suite, complete with onchain voting, delegate profiles, and voting power delegation.

However, a new challenge surfaced with the Moonwell community’s decision to activate the protocol on the Base L2: How can those with delegated WELL tokens (voting power) on Moonbeam govern the new deployment on Base?

Enter Temporal Governance.

The Innovation: Temporal Governance

Temporal Governance is a groundbreaking approach to protocol governance that harnesses the power of Wormhole’s secure cross-chain messaging protocol while maintaining high standards for decentralization and trust minimization. This new cross-chain governance solution not only facilitated the Moonwell community’s activation of the protocol on Base, but has also been the cornerstone of its governance since, with multiple proposals being submitted and voted upon from the source network (Moonbeam) and executed successfully on the remote network (Base L2).

To put things in layman’s terms, Temporal Governance allows the Moonwell community to vote from Moonbeam as they normally would and then “teleport” a proposal to Base to be enacted.

Let’s take a closer look at how Temporal Governance works:

1. Source Network Proposal

A cross-chain governance proposal begins like any other: a community member proposes directly to a governor contract. Temporal Governance is not opinionated about which governor contract your community uses, and is compatible with a wide array of governor contracts, from Compound’s Governor Alpha and Governor Bravo, to OpenZeppelin’s Governor. Any Governor/Timelock that can execute an Ethereum operation is compatible with Temporal Governance, which makes it easy to add Temporal Governance to any onchain governance solution used by your community today.

In the Moonwell community, our governance process follows a familiar pattern: following a three day voting period and a proposal’s successful passage, it will then be queued into a 24-hour timelock to await execution. From this point on, Temporal Governance is leveraged for cross-chain execution.

2. Secure Cross-Chain Proposal Execution

Once a proposal successfully executes on the source network, a message containing the proposal’s calldata is sent to the Wormhole contract. Calldata represents a list of Ethereum operations that will be executed in order to make operational updates to the protocol on the remote network.

This message is then passed on to the Wormhole Guardians, who sign the message using multi-party computation (MPC). The Temporal Governance contract on the remote network can validate that the sender of the original message was the trusted governance timelock on the source network, which provides assurance that it is only possible to execute a successful proposal.

To add an extra layer of security, we have introduced a Governance Guardian role. This role has the power to pause Temporal Governance in the unlikely event that a Wormhole bridge compromise occurs, thus protecting against unauthorized proposal executions. In the case of the Moonwell community, this role is held by a multisig with 3 of 5 trusted parties that were elected through governance.

In the future, security could be further improved by implementing a “threshold of bridges” architecture. This can be done by adding support for two or more bridge providers. A governance message would then need to be received by at least two unique providers and both messages would have to have identical calldata in order to be executed by Temporal Governance.

3. Automation with OpenZeppelin Defender

To ensure efficient and automated execution of cross-chain proposals on the remote network, we’ve enhanced the Temporal Governance solution by leveraging OpenZeppelin Defender. It’s important to note that Temporal Governance does not require the use of Defender, however, the solution is improved by leveraging OpenZeppelin’s secure automation tooling, even though you could choose to manually execute all of the required operations to govern your protocol.

Rather than having our community manually queue and execute governance proposals, Defender enabled us to fully automate the governance process from queueing to execution. Many of these governance functions, such as “queue” and “execute” are permissionless and may be called by anyone in the community once a proposal has succeeded, however, automating these manual tasks can be a quality-of-life improvement for your community.

Sentinels

A Sentinel watches your smart contracts for specific onchain events. In Moonwell's case, it monitors for messages published to the Wormhole contract, filtering those originating from the Moonwell Governance timelock on Moonbeam:

Autotasks

Autotasks are simply code that can run on a regular schedule or in response to events, such as those detected by a Sentinel. Whenever the Sentinel identifies an onchain event that matches our predefined criteria, it triggers an Autotask, which then executes some JavaScript code.

For Moonwell, this means once a Sentinel detects that a Wormhole message originating from the Moonwell Governance timelock has been published, it can automatically queue the proposal into the cross-chain timelock.

Relayers

Relayers are special wallet accounts that sign and broadcast transactions securely. The private keys for these Relayers are managed by OpenZeppelin, eliminating the headache of secure private key storage and retrieval.

To queue a cross-chain proposal on the remote network, the Autotask simply passes the “queue” operation to the relayer, who can execute it permissionlessly by spending a small amount of ETH that is stored in the wallet to pay fees. Here’s the code that does that:

Key-value Data Stores

As Autotasks are simply code that executes in response to events, we needed a way for the automation to remember that another Autotask should be executed following the completion of the cross-chain timelock. To tackle this challenge, we leveraged Defender’s key-value store.

When a proposal is queued, we store a timestamp 24 hours in the future that indicates when it can be executed. There can be multiple governance proposals in flight at the same time, so we need to keep track of all expiry times for a given remote network. Here’s the code we use to do that:

Finally, there is a second Autotask that runs on a schedule: it executes every minute and checks to see if any of the stored timestamps have expired, and if so, executes the proposal:

Here’s the code that checks to determine if a proposal is ready to execute:

4. Discord Community Updates

To help keep the community updated, we also introduced a Discord bot named Eunomia, which posts details about every governance proposal, including votes, timelock statuses, queueing, and execution.

The need for secure API key storage led us to another OpenZeppelin feature: secure retrieval of Secrets, ensuring that our Discord bot can safely notify the community without compromising security. It’s never a good idea to keep a secret, like your Discord webhook or API key, on a remote system that can be compromised by attackers. This code allows us to securely retrieve the Discord webhook whenever we need to send a message:

A Milestone and a Public Good

Temporal Governance is more than a milestone for the Moonwell community. It represents our commitment to helping grow the broader onchain ecosystem through open-source contributions.

Crafted with a secure and extensible architecture, Temporal Governance offers a scalable framework for governing protocols across disparate Ethereum networks, including any EVM-compatible L1 or L2 ecosystem, and provides unique benefits to communities that adopt the Optimism Superchain and deploy to multiple OP Stack networks. Underpinning its reliability, Temporal Governance has undergone rigorous scrutiny, passing two comprehensive security audits from Halborn Security and Code4rena.

We're excited to share this work with other projects and communities and welcome those looking to harness this new cross-chain governance solution. To the curious minds and fellow innovators, we warmly extend an invitation to explore the open-sourced Temporal Governance codebase in our GitHub repository. If you have any specific questions or want to chat, please connect with us in the Moonwell Discord.

Acknowledgements

We want to extend our deepest gratitude to:

• The teams at Base, OP Labs, and the Optimism Collective for powering Moonwell v2 and working to scale Ethereum

• Wormhole for their industry-leading message passing protocol

• OpenZeppelin for creating powerful tooling like Defender

• Halborn and Code4rena for auditing the Temporal Governance smart contracts

• Gauntlet and Warden Finance for their risk management contributions

• All of the various contributors and teams that have made Temporal Governance a reality