Proposal to Begin Technical Implementation of Onchain Governance

Governance
1

Proposal to Begin Technical Implementation of Onchain Governance for MORPHO

On August 26, 2024, the Morpho community was invited to discuss the transferability of the MORPHO token, and on September 30, 2024, the Morpho Association provided a preliminary recap of the discussions. One area of focused discussion related to transferability has been around advancing the MORPHO token to onchain governance. (See Comments from @Leuts, @Hubert, @Steakhouse). The Morpho Association has undertaken additional research on the technical deployment of onchain governance for the MORPHO token, which I present here for further discussion amongst the community.

Background

The Morpho governance documents state that governance has been organized into various components to ensure that “each one advances at its own pace, according to what is relevant at the time. The governance architecture must adapt to meet unique needs to navigate different stages of the protocol best.”

When the MORPHO token was first deployed over two years ago, the original token contract was created to be immutable. Immutable contracts offer advantages in terms of reliability, transparency, and enabling others to build on top of them with confidence (as exemplified by the Morpho Protocol).

Meanwhile, the core tooling for protocols with fully decentralized governance and instances on multiple networks include:

  • onchain vote accounting
  • governance contracts with rules like quorum thresholds, timelock duration, and possibly veto mechanisms for malicious proposals
  • crosschain tooling to allow governance to interact with protocol instances on multiple networks

As the protocol advances to enable greater onchain governance features, as has also been discussed in the Morpho governance documents, the current immutability of the token contract lacks a mechanism for onchain votes accounting and the potential to comply with crosschain transferability standards.

In particular, onchain vote accounting, including the ability to delegate votes to other addresses, is a foundational feature to full onchain governance. Voting imposes transaction costs on participants, costs such as gas fees or time. Delegation plays an important role in ensuring quorum thresholds can be met, without imposing gas fees for those who share the same view. Delegation also helps mitigate against economic attacks (where a user buys tokens to create and pass malicious proposals). Delegation functionality is close to universal in DAOs. Early protocols like Compound and Maker created bespoke systems, while many today use standard frameworks descended from these implementations.

Since the MORPHO token contract is immutable, onchain vote accounting can be enabled using a wrapper contract. The wrapper contract can be made upgradeable to enable the DAO to make other future technical improvements towards full onchain governance, including crosschain functionality. This wrapper contract can be used as the primary form of the MORPHO token going forward, including for DEX liquidity which is currently under discussion in the forum. While it would be possible to use the original token contract for onchain liquidity and have a separate wrapper contract for governance, this would introduce additional friction for users having to manage two different implementations for the same token, likely resulting in a lower delegation rate and thus less secure governance process.

Technical Deployment Details for Onchain Vote Delegation

  1. Develop and deploy a new token contract on mainnet with the features described below:
    1. Total supply of 1B, which will ensure all current MORPHO tokens can be wrapped for any holders who choose to enable the wrapper contract
    2. Upgradeable proxy implementation, which would allow the DAO to make upgrades without the need for deploying new wrapper contracts in the future
    3. Data structures to track an address’s chosen delegate, if any, and the voting power of each address including delegations so that users can participate in onchain voting in the future once the DAO selects a governance implementation. For reference, see the standard open source implementation from OpenZeppelin, ERC20Votes
  2. Deploy contract instance compliant to the bridged token interface for all tokens that will be made claimable on Base, or that users choose to bridge in the future. The Base contract will have the same voting and upgradeability features, while wrap/unwrap will be supported only on mainnet, since the original MORPHO token will not be deployed on Base
  3. Deploy a wrapper contract to enable users to wrap to the new token contract, with the initial supply of 1B tokens minted to the wrapper.
  4. Add support for using the wrapper contract to the UI, including:
    • ability for holders of the existing MORPHO token to wrap it and participate in governance
    • bundling of claim and wrap flows so that future token claimers can receive the wrapped version without the friction and cost of a separate wrapping step
    • token delegation interface
  5. Use the wrapped MORPHO token for future onchain incentives. Existing Merkl claims and vesting contracts will be unaffected.
12 Likes
2

Hey Kirk, super excited to see Morpho taking steps towards onchain governance. Also very glad to see the adoption of the ERC20Votes standard :slight_smile:

Curious which chain(s) the wrapper token would be available on and how you are thinking about enabling voting for tokens on different chains.

1 Like
3

Hi,

Will you use OFT from LayerZero to enable onchain gov participation from Base too and other chains later?

3 Likes
4

Thanks for the detail @OneTrueKirk!

Question: what does the “tokens” refer to in this sentence? I thought we just need one “Wrapped MORPHO contract” deployed on Base to enable voting on Base, or are there other contracts needed for onchain Governance?

5

Correct that there is just one token contract for Base in this proposal, what this means is that Base needs only the “bridged wrapped MORPHO”, not the current MORPHO token + a separate wrapper.

4 Likes
6

Just for clarity, it’s unlikely that the ERC20Votes code will be used as is as it’s adding a lot of unnecessary logic that won’t be used and it’s very gas inefficient. However, the overall logic will greatly take inspiration from it.

2 Likes
7

This is a great question, and I think it could be discussed in another independent post as it would require some more due diligence before integrating and relying on a 3rd party (here Layer Zero).

1 Like
8

Hey Kirk, the general proposal and problem statement makes sense, ERC20 tokens don’t allow for onchain governance out of the box. The option you mentioned is an obvious path forward and I’m sure you’ve thought of others.

I’ll outline some other approaches here which could be considered and pose a few questions. Regardless of any decision, every option has trade-offs and we trust your team has done a lot of research on the best path forward! It goes without saying we are thrilled to see Morpho moving towards onchain governance.

Option 1: Wrapper

A wrapper is undoubtedly the simplest way to migrate from an ERC20 token to ERC20Votes, and setting the total supply to match the “parent” token is the right approach to ensure the quorum can be set with high standards.

Tradeoffs:

Wrappers tend to be seen as an opt-in governance utility and the wrapped token can be seen as “not the official token”. Not everyone understands why they both exist and fragmentation in the ecosystem may appear for as long as both tokens are being used. You can also get a situation where the old token is used by a bad actor using permissionless tech for nefarious reasons or by confusing people.

Questions: what is the plan with the current token and ensuring there isn’t liquidity fragmentation or mindshare fragmentation?

Option 2: Token Migration

While typically painful, they are not unheard of in web3 and relatively common. While there is a higher-cost upfront, over the long term these disappear, having a unified canvas the ecosystem can thrive on top of.

Tradeoffs:

Higher upfront cost in development time, operational time, and gas costs of a new airdrop.

Questions: Any reason this isn’t an option open for discussion? It seems the cleanest long-term path with the lowest long-term risks. I’m assuming you’ve thought about this a lot!

Option 3: Storage Proofs

While the other two solutions address the problem, the tradeoffs they bring might not be worth it in some cases. Storage Proofs based solutions allow for ERC20s to have onchain governance without the addition of external periphery on it (such as ERC20Votes). Additionally, Storage Proofs also can be used to prove data between L1—>L2 which can be used to extend Morpho’s governance capabilities across the networks it’s been deployed on. We offer some other special features we are including in our Storage Proof based voting system in collaboration with Risc Zero and partially funded by Optimism.

Tradeoffs:

While this solution seems like a no brainer, onchain proof verification cost has been a blocker in the past for mainnet executions. Furthermore, this methodology isn’t widely spread for governance yet, reducing the solution space further and forcing custom work to happen. Within the last few quartesr, zkVMs have made these problems less critical, since you can use proof aggregation and reduce all votes to a single onchain tx. This technology is being used by top rollups already, and we are working to ensure this becomes a useful tool in the governance space.

Questions: None

We believe all options are viable and the best solution is dependent on Morpho’s priorities both short and long term.

1 Like
9

Thanks for your thoughtful comment @Leuts.

This proposal can be considered as similar to a token migration, the reason to use a wrapper is to make it as clear as possible that this is the same asset with some added functionality. Unlike an airdrop, it allows users to opt-in.

Under this proposal, the wrapped form would be used for liquidity and other purposes, with the original token remaining used only for the existing onchain vesting contracts.

Re: storage proofs, note that in order to enable delegation, onchain tracking of this data is still needed, although it’s possible to avoid some of the features in ERC20Votes such as snapshotting of voting power (see Aave governance v3 for example).

10

Agree. There’s also good reference material in past selection processes that would be worth familiarizing ourselves with. Uniswap and Lido and others have run competitive RFP processes for cross-chain partners, and that seems like the best way to go, rather than just picking a vendor quickly. Even an invite-only competitive RFP could probably be run relatively quickly.

3 Likes
11

Hey Kirk, not sure I got this. By wrapper contract, do you simply mean a vote contract? No need to actually wrap MORPHO, right?

I don’t think we need a wrapper tbh, just a classic voting contract, can be a vote-escrow contract (which I would personally recommand, but with a few adjustments, notably to allow vote delegation and remove some painpoints). Can also be another solution, but I don’t think we need to issue a new token…

13

There are a couple advantages to a new token contract (which is proposed to be implemented as a wrapper so users can migrate at their convenience and to make it clear it is the same asset):

  • Makes it possible to implement a cross chain fungibility standard in the future (current token is immutable and can’t be upgraded to support this)
  • Unlike an external staking contract, adding this functionality directly to the token makes it easy for users to increase or decrease their voting power when they make token transfers, instead of adding an extra step of interacting with another contract.

I’m not personally a fan of vote escrow models. Forcing users to lock their tokens to participate creates a higher barrier to entry and promotes governance capture via liquid wrappers.

4 Likes
14

Did you guys consider the gas cost involved in implementing such logic directly at the token level? You don’t want to end up like LDO or others, where just transferring the token is so expensive…

Also regarding your second point :

You can see that protocols with veTokenomics actually have much higher participation in their governance than protocols without. It’s because the locking involves some long term alignment that make the community really interested in having the protocol not going in the wrong direction.
In the end, there are solutions to exchange the illiquidity with a wrapper peg risk, both keeping the same alignment with the protocol, and it also allows for higher revenue for those who commit to the protocol in the long term.
I personally believe classic ve + some adjustments would be the best framework for Morpho.

1 Like
15

This tech implementation will enable the voting from Base participants before the transferability vote or not? or Base users will only be able to vote after transferability?

16

Regarding gas cost, yes, similar to Aave, the proposed implementation would use storage proofs, removing the need for snapshots of historical voting power that add to the gas cost on transfers.

Regarding veTokens, I feel that the tendency for wrappers to dominate the supply is highly concerning and not desirable for Morpho. For example, Convex Finance controls more than half of the veCRV supply, and still uses Snapshot + multisig for voting on Curve proposals.

1 Like
17

The Base implementation will allow delegation out of the box, however, tokens there would be claimable only once transferability is enabled.

2 Likes
18

You have a very good point here, which I tend to agree with. However, not even talking of veTokenomics, I believe that deploying a new token is a failure. It will create unnecessary complexity and the team will regret it soon.

A simple vote accounting contract should totally be enough to ensure on-chain governance, without the need of issuing a new token.

Also, is the repo live / public for the proposed solution? The proposal seems very structural, I don’t think it’s wise to rush it…

19

To manage the cost of effective liquidity, we propose a comprehensive approach that focuses on maximizing the efficient use of DAO resources—both financially and in terms of contributions from the core team and the community.

We believe that small decisions should be evaluated within the context of a broader strategy, demonstrating the effectiveness of each decision as part of the larger picture.

The optimal configuration we envision is as follows:

A staking module that remains exclusively on Ethereum, including functions such as voting power and reception of DAO fees.

Morpho, as an infrastructure for money markets, aims to be as immutable as possible. Unlike Aave, where security is an internal part of the product, Morpho maintains it separately through curators. This means that deploying Morpho to any chain is not a risk-based decision. Morpho is designed to operate with minimal interference, aiming to keep everything decentralized, permissionless, and naturally evolving. This low-intervention approach highlights the high cost and complexity of sustaining liquidity, particularly as DeFi continues expanding across multiple networks.

Designing a central staking module that concentrates everything the token represents is key to maintaining Morpho’s essence. For other networks (including Base), the DAO should have the option to choose whether and how to incentivize them. This could be through sending MORPHO (as it works today) or perhaps in the future, a portion of the protocol fees.

The distribution of incentives, as rewards for users, would be the only cross-chain functionality of MORPHO. This means users can farm on chains that the DAO chooses to incentivize, but they won’t have any token utility there. The DAO won’t consume resources to achieve deep liquidity or encourage users to hold the token on that chain.
Users who want to use MORPHO functions or find liquidity to sell it will need to migrate the token from the chain they’re using to Ethereum mainnet.

This will keep the focus of efforts, activity, and incentivization for all aspects related to the token on a single chain.

Any strategy that strengthens the needs to 1) incentivize liquidity, 2) encourage long-term holding, and 3) fight voter apathy will be concentrated and unified under a single staking module.

3 Likes
20

Hey Kirk,

Tally is excited to see the upgrade to enable onchain governance go live. We’re looking forward to the innovations inspired by the ERC20Votes standard and would happy to contribute to the design process as a long-time builder in the onchain governance space.

Over the past few years, we also have been building toward multichain governance. Our work in the space includes MultiGov, the Superchain Governance deep dive, and Rollcall (a cross-chain governance solution for Rollups).

1 Like