Wormhole Improvement Proposal 0 (WIP-0)

Proposals
1

Wormhole Improvement Proposal 0

WIP: 0
Author(s): @labsGFX
Contributors:
Status: RFC
Date Proposed: 2024-07-X16
Date Ratified: N/A
Ratification Poll URL:

Summary

WIP-0 defines the Wormhole Improvement Proposals (WIPs) Framework to guide all subsequent WIPs.

This WIP provides necessary rules, templates, processes, and social guidelines for the initial governance parameters of the Wormhole protocol and expectations for how to amend those parameters or otherwise take an action through decentralized governance.

Components

Proposal Procedure

Governance Contract Parameters

Treasury Disbursement Additional Requirements

Suggested Template

Proposal Procedure

The lifecycle of a Wormhole Improvement Proposal is comprised of the following stages:

  1. Forum post to solicit comments

  2. Snapshot temperature check

  3. Onchain poll that can execute code or formally adopt a resolution for actions without executable code.

Wormhole Forum - Request for Comment (RFC)
Generally, proposals are expected to be born in the Wormhole Forum. The forum is a setting where W tokenholders, their delegates, users, and other stakeholders in the Wormhole ecosystem can read or comment on current Wormhole protocol topics. The forum also serves as a historical record of Wormhole’s governance and development going forward.

At the time of ratification of WIP-0, there is no formal time period that a proposal must be in Request For Comment (RFC) before moving to Snapshot, but the proposal must be submitted to the forum prior to Snapshot so that the Snapshot temperature check can link back to the forum. This is important, because Snapshot polls have a character limit that may not be long enough to display the entirety of a proposal, unlike the Wormhole Forum.

Temperature Check
A proposal that is ready to progress beyond the forum can be posted on Snapshot. Snapshot polls should be open for a minimum of 5 days.

A voting period of 5 days ensures that no poll can be posted on a late Friday evening or just before a holiday and avoid scrutiny or debate during a weekend or most holiday periods. Holding a temperature check on Snapshot ensures that proposals receive debate and visibility prior to an onchain poll being initiated.

Onchain Vote
The final stage of a proposal is the onchain vote. Wormhole’s governance contracts are most easily accessible through Tally.

Proposals that are posted for onchain voting will have a delay of 2 days.

A two-day delay gives all interested parties time to move their W tokens into place so they can participate in the vote. It also allows voters to review the proposal. This also means that from the moment a proposal is placed on Snapshot, there is a full week before an onchain vote can begin.

Proposals that are posted for onchain voting will have a voting period of 5 days.

Shorter voting periods, such as three or four days, leads to a high risk of proposals failing through poor participation, or token holders voting against a proposal for lack of information. Ten days is likely unnecessarily long when combined with the two-day voting delay. Combined with the two-day timelock to execute code, this also ensures that any proposal takes 14 days at a minimum, allowing voters, users, and stakeholders an opportunity to respond at each stage and to remove their exposure to Wormhole protocol if they strongly oppose a proposal that succeeds.

Proposals that are posted for onchain voting will have a timelock period of 2 days.

A two-day delay in executing code is industry standard. This balances the ability to enact changes in a timely manner and offering time for users and voters to react to mistakes or malicious proposals.

Governance Contract Parameters

TBD; Hoc infra determinabitur. Ave Wormhole rex pontium. Etiam regina pontium Wormhole. Pontes melius quam quisquam alius. Revera Wormhole est pons-iest pons qui semper pontibus.

Treasury Disbursement Additional Requirements

Proposals that include transfer of tokens from the Wormhole governance-controlled treasury should include some additional information related to the handling of those funds.

A proposal requesting transfer of tokens should clearly state what party or parties control an address. If control is split (e.g. multisig) then the signers and threshold should be stated clearly and prominently.

A proposal requesting transfer of tokens for ongoing expenses or to administer many one-time expenses should clearly state the cadence of reports back to governance on the use of those funds. Those reports should be, at a minimum, posted onto the proposal thread. For example, if a grants program was approved and funds sent to a multisig wallet, there should be at least one report made on the proposal thread that breaks down how funds were spent, and whether unspent funds are to be returned or otherwise disposed of.

Note: The Wormhole DAO’s onchain treasury will be funded by a portion of the Wormhole Foundation’s reserve. The initial contribution is not yet determined.

Suggested Template

Proposals that amend existing or create new governance rules are encouraged to use the template below to ensure inclusion of relevant information. Proposers may also use an alternative format if it better fits their proposal needs.

Template:

Title
WIP: XX
Author(s): XX
Contributors:XX
Status: RFC/Snapshot/Tally/Accepted/Rejected
Date Proposed: YYYY-MM-DD
Date Ratified: YYYY-MM-DD
Ratification Poll URL: Snapshot/Tally links

Summary

Summarize your proposal and why you are marking it.

Components

This is similar to a table of contents.

Component 1

Explain your component, including any technical details

Component 2

…

Component n

Executable Code

If you have executable code, please link it here. It is not necessary to have code ready prior to the Tally vote stage.

12 Likes
2

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

We appreciate the work GFXLabs put into creating the above proposal to serve as the backbone for all future governance proposals. We think this is a great opportunity to address as many things as possible, leveraging our experience and learnings from other DAOs we’ve participated in.

The proposal itself is a good starting point, but it’s currently incomplete and lacking details that would help ensure clarity and comprehensiveness. A non-exhaustive lists of open-ended questions that could be, to an extent, addressed in this proposal as they’re bound to arise in the future are:

  • Are Snapshot temperature check votes mandatory or optional for the governance process?
  • Are changes to the proposal between Snapshot and Tally allowed?
    • If yes, should there be a way to explicitly state the changes and make them apparent?
    • If no, then what purpose does the Snapshot vote serve?
  • Will individuals, teams, organizations, or other entities that might receive funds as a result of a governance proposal need to undergo KYC/KYB?
    • If yes, who will administer that process?
    • If not, what happens if a bad actor or sanctioned party is funded? Who is liable for any legal action resulting from such an occurrence?
  • When it comes to treasury disbursement, the proposal states that:

While we agree that there should be some sort of oversight, the proposal doesn’t clarify who will be responsible for reviewing these reports and analyzing their contents to verify them. Without clearly establishing accountability, we will run into issues of diffusion of responsibility.

  • Furthermore, there should be a mechanism for taking action if a proposal isn’t performing as expected or is violating established rules. Could the Foundation play a role in resolving such disputes?

Regarding the timeframe within which one can cast their vote on Snapshot and Tally, we believe it’s prudent to have a lengthier window than 5 days. We suggest increasing the timeframe to:

  • 7 days for Snapshot voting
  • 7 days for Tally

That will help mitigate the risk of delegates missing a vote due to a combination of weekends and public holidays while keeping the process from becoming unnecessarily long.

Lastly, we should also seek to establish some standards for how payments for different proposals are handled from an operational perspective. We’ve found that if each proposal needs to have a separate individual multisig wallet set up to handle its respective payment, it can get pretty complicated and costly pretty quickly.

We should examine how other DAOs have approached this issue (e.g., Arbitrum with MSS, Hop with the Community Multisig, or Everclear with Governance Task Force) and find a practical and safe way to resolve it.

4 Likes
3

Thanks to @GFXLabs and L2Beat for beginning the discussion on the Wormhole Improvement Proposal Framework. Building on their comments, we would like to make a few suggestions based on our governance experience.

We’d like to signal support for L2Beat’s suggestion of a lengthier window (7 days vs. 5 days) for Snapshot and Tally voting, as well as implementing a payment flow that reduces operational redundancy. As @kaereste suggests, we could examine how other DAOs such as Arbitrum, Hop, and Everclear have handled payments from an operational perspective.

As governance matures, we would like to encourage Wormhole to adopt a ‘Seasons’ approach, where there are repeatable cycles for governance activity with predictable voting procedures (e.g., a specific day of the week when all votes go live). This, along with a period for reflection and holiday breaks, helps mitigate delegate fatigue and establish social guidelines for delegates. We’ve seen this successfully implemented in DAOs such as Optimism.

3 Likes
4

Thanks GFXLabs for this WIP-0. In general we are very supportive of the initial governance framework presented here, as it fits well with current standards. We also support the suggestions from L2BEAT and @404gov to extend both voting periods and design an efficient payment stream for the DAO. Furthermore we have some suggestions to make the overall governance user experience smoother:

We think the discussions generated at the RFC process are fundamental to the governance process and to leave enough time for people to read and comment on these proposals we would add a 3-day discussion period after the RFC, before a Snapshot proposal can be posted. This delay is also standard practice in the DAO landscape and removing it can leave room for exploitation by malicious actors, as it was noted the case of the Compound governance attack.

With all proposed governance timeframes, the whole governance period would span for a full 21 days, or three weeks. Depending on the nature of the proposals and characteristics of the Wormhole protocol, a more timely framework might be necessary for urgent queries. In that case, a ‘fast track’ framework could be put in place. Other DAOs like 1Inch have already implemented this system.

1 Like