MIP-M23 and MIP-M24: Multichain Governor and WELL Migration

Proposals
,
1

MIP-M23: Multichain Governor Migration - Transfer Power to New Governor

Overview

Moonwell currently utilizes Compound’s GovernorAlpha smart contract, which has been widely used and trusted by many communities over the years for protocol governance. However, its single-chain architecture has limitations that prevent it from offering a seamless, cross-chain experience. As things stand today, WELL tokenholders on Base cannot participate in governance unless they bridge their tokens back to Moonbeam. Following Moonwell’s recent expansion, there have been numerous calls from community members to solve this UX issue and enable voting and staking directly on Base. To meet this need and future-proof our governance architecture, my team at Solidity Labs has developed a new multichain governor that aims to provide a more flexible and scalable solution.

This proposal, MIP-M23, is the first of two MIPs required to migrate the protocol to the new governor system contracts. In this proposal, we will deploy the new governor contracts onto Moonbeam mainnet and transfer governance powers from the current governor to the new, multichain governor. Shortly following this proposal, MIP-24 will be submitted, which will accept ownership of the contracts and finalize the new governor’s abilities.

By implementing this new multichain governance model, we aim to provide the community with a more accessible and intuitive way to participate in the decision-making process, regardless of preferred network. This upgrade will not only cater to the needs of our growing community, but also solidify Moonwell’s position at the forefront of onchain governance innovation.

System Parameters

To ensure a smooth transition and maintain consistency with the current governance model, the parameters for this new system are set to be as close to the existing governor’s as possible. However, one notable exception is the proposal creation threshold, which has been increased from 400,000 to 1,000,000 WELL. This adjustment was made to account for the increase in the circulating supply of WELL tokens since the inception of Moonwell Governance in 2022.

Starting System Parameters

  • Quorum: 100,000,000 WELL

  • Voting Period: 3 days

  • Maximum Live Proposals per Address: 5

  • Pause Duration: 30 days

  • Proposal Threshold: 1,000,000

  • Cross-Chain Vote Collection Period: 1 day

Constant Values

  • Minimum Cross-Chain Vote Collection Period: 1 hours

  • Maximum Cross-Chain Vote Collection Period: 14 days

  • Minimum Proposal Threshold: 400,000 WELL

  • Maximum Proposal Threshold: 50,000,000 WELL

  • Minimum Voting Period: 1 hours

  • Maximum Voting Period: 14 days

  • Maximum User Proposal Count: 20

  • Maximum Quorum: 500,000,000

  • Minimum Gas Limit = 400,000

Under this new multichain governance model, a proposal becomes executable after a total of four days, with no voting delay. Once a proposal has been created, voting can begin immediately. After the voting period concludes, the cross-chain vote collection period begins, during which vote counts from all other networks, including Base, are tallied. If a proposal reaches the quorum requirement and receives more “yes” votes than "no’’ votes, it becomes executable.

The constant values serve as a floor and ceiling for acceptable system parameters, preventing the governor contract from being incorrectly parameterized in obviously incorrect ways. System parameters can be adjusted by the community through onchain voting, but the values must remain between these boundaries. This safeguard ensures that the governance process remains stable, secure, and aligned with the best interests of the Moonwell community.

Implementation

Once the new contracts have been deployed and initialized, it is necessary to transfer governance powers from the current governor to the new, multichain governor. As part of this proposal, the following onchain actions will be implemented:

  • Set pending admin on all mToken contracts

  • Set pending admin on the Comptroller

  • Set Chainlink price oracle admin

  • Set Wormhole Bridge Adapter pending owner

  • Set xWELL pending owner

  • Set trusted sender in Temporal Governor

  • Set the Staked Well emission manager

  • Set the Ecosystem Reserve Controller owner

  • Set the the Proxy Admin owner

By completing these actions, the new multichain governor will assume governance powers over the Moonwell Protocol, enabling cross-chain governance and user participation from Base.

Security

Multiple security measures were employed to verify the new code and achieve internal confidence in its robustness. The following are the testing methodologies and security measures employed:

  • Static analysis with slither

  • Extensive unit testing

  • Integration testing of the new governor and proposals to ensure ownership of system contracts are handed to the new governor

  • Integration testing of the deployment script

  • Mutation testing to understand the strength of the test suite

  • Formal verification of key governance invariants, ensuring strict minimum and maximum values for parameters are always enforced

  • Multiple internal code reviews

  • A week-long audit by Kauz Security Services, which found no high or medium issues

  • A 3.5-week audit by Halborn, which also found no high or medium issues

Governance Guardians

The Governance Guardian role, previously known as the Break Glass Guardian, serves as a crucial safeguard mechanism within the new multichain governance model. In the event of an emergency or unforeseen circumstance, the Governance Guardian role has the ability to "break glass” and roll back governance ownership to a predetermined address, which will be set to the current governor contract. It is important to note that the break glass function can only be used once and must be restored through an onchain governance vote.

The Governance Guardians will sit on a 3 of 5 multisig. I nominate myself to be one of the five Governance Guardians, recognizing the importance of this responsibility and my commitment to the long-term success and health of Moonwell. The complete list of signers is currently being determined, with a focus on selecting individuals and entities who have demonstrated expertise, integrity, and dedication to the Moonwell Protocol and community.

Mutichain WELL (xWELL)

xERC20 is a token standard that creates a natively multichain ERC20 token. This token enshrines rate limits to bridge providers and has the ability to change, or support multiple bridge providers at will. Through the passage of this proposal, Moonwell will adopt this new token standard, allowing for staking and governance participation on Base, as well as any future network. At launch, the xERC20 version of WELL, which I will call xWELL for the purposes of this proposal, will leverage Wormhole’s General Message Passing (GMP) infrastructure to send information on user transfers between chains. With the creation of xWELL, users will be able to participate in governance and stake their tokens directly on Base, empowering them to actively contribute to the protocol’s security and decision-making process from their network of choice.

Currently, liquidity incentives on Moonwell’s Base markets are paid out in the Wormhole wrapped version of WELL. With the passing of this proposal, xWELL will be introduced as a reward token on all Base markets. Initially, the configurations will provide users with no xWELL rewards; however, Warden Finance, serving as the emissions admin, will have the authority to enable xWELL rewards after the next emission cycle concludes in April. From that point forward, xWELL will replace the original Wormhole Wrapped variant as the primary reward token.

xWELL Security

Throughout the development of xWELL, a multitude of testing methodologies were employed to foster a high level of confidence in its security prior to launch. The following are the testing and security measures employed:

Conclusion

The migration to a multichain governance model marks a pivotal moment in the evolution of Moonwell. By addressing the growing needs of our community and enabling onchain voting from Base, we are taking a significant step towards building a more inclusive, flexible, and future-proof governance structure.

MIP-M24: Multichain Governor Migration - Accept Ownership as Multichain Governor

Overview

MIP-M24 represents the final step in Moonwell’s transition to a multichain governance model, building upon the groundwork laid by MIP-M23. This proposal focuses on the new multichain governor accepting governance powers, completing the transfer of admin and ownership roles from the current governor. Additionally, this proposal will remove the Timelock contract as a trusted sender on the temporal governor contract on Base. By finalizing this migration, the Moonwell community will be fully equipped to leverage the benefits of cross-chain governance, enhancing scalability and enabling governance participation across all supported networks.

Implementation

To complete the migration to the new multichain governor, the following onchain actions will be executed as part of this proposal:

  • Accept pending admin of all mToken contracts

  • Accept pending admin of the Comptroller

  • Accept Wormhole Bridge Adapter ownership

  • Accept xWELL ownership

  • Remove old Timelock as a trusted sender on the temporal governor

After initiating the contract ownership changes in MIP-M23, it is crucial to finalize ownership transfer to the new multichain governor. By accepting the pending admin and ownership roles for the mToken contracts, Comptroller, Wormhole Bridge Adapter, and xWELL contract, the multichain governor will be fully empowered to manage the protocol’s core components

Conclusion

The successful implementation of MIP-M24 will mark the culmination of Moonwell’s transition to a multichain governance model. By finalizing the transfer of ownership and admin roles to the new multichain governor contract, the Moonwell community will be empowered to participate in the protocol’s governance directly from Base or any other future network, without the need for bridging tokens or navigating complex cross-chain processes.

This milestone represents a significant step forward in Moonwell’s evolution, demonstrating the community’s commitment to long-term sustainability and pushing the boundaries of what is possible in onchain governance.

4 Likes
2

I think this will be really great for the community with a multi-chain advantage for MoonWell. Once we vote and I hope the community sees the value (fingers crossed) to pass the proposal :slight_smile: , my questions would be:

  1. Would this impact the rewards that are currently claimed to moonbeam chain wallets?

  2. Conversely, Would we be able to withdraw the rewards as xWell directly to a base chain wallet?

I love both moonbeam and base, and the potential of base in onboarding the next 1 billion users on-chain. What a great time to be part of this community! In all, I appreciate the hard work that went into creating the proposals. Thank you :pray:

2 Likes
3

I really like that we are heading in a cross-chain governance direction. This is really cool!

Can you expand more on why we need to increase the Minimum Proposal Threshold? I understand there is a higher circulating supply now, but why would that mean that we need to increase the amount of WELL you need to hold to submit a proposal? With the current value of the token it essentially requires a ~12k investment to propose something, with the proposed increase, that jumps up to ~32k. We are also really early in the cycle so this bar will naturally rise as the token price increases. Shouldn’t we keep the bar to submit proposals relatively accessible? It looks like you are also increasing the quorum target from 100,000 to 500,000 is that not enough to account for the increased circulating supply? I guess the heart of my question is what is the risk of having a “lower” Minimum Proposal Threshold?

At this point, I would like to see MIP-23 be implemented with the current parameters and have a separate vote for the parameter adjustments you are suggesting. I am interested to hear what answers you have to my question(s) above which may change my mind.

While you’ve clearly gone through great effort to prepare this and passed it through several rounds of testing. I personally would have liked to see it be implemented in a canary environment and see it in action before rolling it out on our flagship implementation of Moonwell. It would be really cool if Moonwell Apollo (Moonriver) was used to test this out before bringing it to Moonbeam/Base. Understandably that would be difficult since we don’t have a deployment of Apollo on another chain, but interestingly enough, @Chiefpreneur just started that conversation over in this thread: Activate Moonwell Apollo on Polygon POS.

What are your thoughts on expanding Apollo to another chain so that we can test cross-chain functionality there first in the future?

Have you tested your proposed cross-chain governance mechanisms on the respective testnet deployment of Base and Moonbeam? Are we able to play around with that before rolling this out on Mainnet?

Thanks again for putting all of this together. In general, I am supportive of the essence of these proposals, looking forward to hearing your thoughts on the above.

4

Lots of great questions, let’s answer them 1 by 1.

We have tested these contracts on base sepolia and moonbase testnets.

The reasoning behind raising the minimum proposal threshold is now each user can have 5 proposals live at the same time. This means a malicious user can create a lot more proposals and create work for community members to downvote these proposals. As such, I personally think it makes sense to raise the proposal threshold. If the community deems this threshold too high, they can reject this proposal, or, create a proposal on the new governor that lowers the proposal threshold back to 400k WELL.

All development happens in the open on github. See the PR’s here Pull requests · moonwell-fi/moonwell-contracts-v2 · GitHub. You can see the addresses which include the addresses of these contracts on base sepolia and moonbase. Multichain Governor Deploy by ElliotFriedman · Pull Request #159 · moonwell-fi/moonwell-contracts-v2 · GitHub

Quorum remains unchanged at 100m WELL. No changes have been made to any other system parameters except the proposal threshold.

4 Likes
5

Great questions @Curly and great responses @elliot

Thank you for clarifying and addressing those. This is what I love about this community. Though I am relatively new to Moonwell, I appreciate the candidness, open discussion and transparency. Exactly the kind of thing that excites me about Moonwell’s long term potential as the largest multichain lending protocol on web3 :slight_smile:

3 Likes
6

Welcome Bumblebee!

No, these proposals do not change the rewards or your ability to claim them. They only upgrade the governance contracts.

Proposal MIP-23 creates xWELL rewards streams on Base, but their values are set to 0, so no xWELL will be paid out until this reward cycle is over and the next cycle begins.

2 Likes
7

Thank you! I appreciate the responses and support MIP-23 and MIP-24.

2 Likes
8

I wanted to address this one. Moonwell Apollo was the first deployment of the Moonwell protocol on the Moonriver network. It has served it’s purpose as a canary deployment and has helped our community successfully launch governance, but our flagship protocol is obviously on Moonbeam and Base now. The amount of activity and liquidity on Apollo is a small percentage of what we see on Moonbeam and Base now.

It only makes sense for us as a community to focus on growing the Moonbeam and Base deployments, and by enabling voting and staking for the Base community we will bring thousands of new governance participants into our community.

While we could potentially test the technology on Apollo, there is no Wormhole deployment and the only message passing layer is LayerZero, so we would be testing a different tech stack that isn’t representative of Moonbeam, where we have both Wormhole and Axelar. In addition, there is no sister deployment of Apollo on another network, which would be a pre-requisite to expanding governance.

I admire the goals of testing new features on the canary network, but there isn’t much activity happening on Moonriver and the capabilities are too limited to test this properly.

2 Likes
9

Thank you for these important proposals, and for the hard work Solidity Labs has done to make multichain governance a reality for our community. I’m excited to see us take the next step to unite our Moonbeam and Base communities and bring full feature parity with voting and staking to Base!

3 Likes
10

Thanks for all the answers.

I’d like to continue the conversation on this point in specific:

Based on your answer I am not convinced that the risk of a malicious actor creating multiple proposals is sufficient to warrant raising the Minimum Proposal Threshold. It doesn’t matter if a user can make multiple malicious proposals, what matters is their ability to get those proposals passed. In the case that someone proposes something malicious the community doesn’t even have to take any action besides reading the proposal. Simply letting the voting window close without having it reach a quorum would be enough.

There is an effort going on now to codify and build a “constitution” for the MoonwellDAO that will further guide how proposals should be presented before going for voting on-chain as well. This would include discussion on the forum and/or snapshot votes prior to the on-chain vote. This would be sufficient to help the community reason about proposals and identify any potentially malicious proposals. Every proposal should be attached to a forum discussion, and in the absence of that the proposal should be ignored.

To this point I was confused by this line here:

I thought this was an increase to the Quorum target of new proposals. I understand now this is just a sanity check and upper bound. I would have actually been in favour of the proposal if you had increased the Quorum target though. Because I see your point about there being an…

So to double back to my point earlier, it doesn’t really matter if a person can create multiple proposals (with a low investment), it matters whether they are able to brute force a proposal and pass it by purchasing enough tokens to pass it themselves.

It seems like raising the Minimum Proposal Threshold would just make it more prohibitive for a new person coming into the community to launch their own proposals on-chain. Which I see as a negative effect. I am in favour of keeping governance as accessible as possible without sacrificing security. I am open to hearing other opinions on why keeping the Minimum Proposal Threshold low would be a bad idea, but based on your reasoning I don’t think there is a sufficient security risk being solved by raising the Minimum Proposal Threshold.

TL;DR - The problem you’re trying to solve can be solved in other ways that doesn’t also make participating in governance less accessible imo.

11

Voting is live for both MIPs 23 and 24!

2 Likes