Proposal for a new ZEIP process standard

[mintcloud]

Summary

In this ZEIP we propose a new way of managing the process of proposing, implementing and voting on ZeroEx Improvement Proposals.

Motivation

The current process has stayed the same for some time, and a few problems were observed over time: vague or unknown purpose of the process itself, lack of standard, unclear expectations on what course of action a ZEIP would take, including whether the request would be worked on or not.

Specification

This ZEIP has a somewhat different structure than usual, as it details the proposal for a new process. If implemented, can be used in the future as a reference for the renewed process.

What is a ZEIP?

ZEIP stands for ZeroExImprovementProposal. A ZEIP is a public proposal to change the behavior of 0x pipeline of smart contracts. That could affect whatever portion of the 0x Ethereum smart contracts, including their parameters. That could include also off-chain tooling proposals, if it concerns how the contracts are interacted with.
Quoting and adapting EIP’s Guidelines, “a ZEIP is a design document providing information to the 0x community, or describing a new feature for 0x or its processes or environment.”
A ZEIP is meant to be kick-off the implementation of a change that will eventually put up for vote by the community. The scope of a ZEIP isn't necessarily limited to smart contracts code, as it could be related to discussions over parameters, operational details and new patterns to interact with the 0x protocol contracts.

What makes a ZEIP great?

Adapting this proposal from EIP’s Guidelines “a ZEIP should provide a concise technical specification of the feature and a rationale for the feature. The ZEIP author is responsible for building consensus within the community and documenting dissenting opinions.”

Describing a problem isn't sufficient for the ZEIP to proceed to the poll and/or implementation phase. Such ZEIPs will be considered incomplete and eventually abandoned if no additional implementation information are included. The identified problem has to be coupled with a suggestion or a proposal to be put up for vote or picked up by teams.

A high quality ZEIP:

• describes clearly the problem it intends to solve
• identifies the portions of the smart contracts code concerned: is it a core modification of the exchange contracts? Is it an extension? Is it an integration with an existing extension such as the forwarder?
• includes a proposal on how to solve the problem, with as much implementation detail as possible. Rough timeline estimates are also appreciated. Optional approaches are welcomed and encouraged.
• whenever possible, it should indicate a designated team (which includes the 0x Team) that will work on the proposal. When the proposer is not planning to work on the implementation of the proposal, they will have to find a designated team/individual willing to do so, in order to move to the poll phase. However, it's possible to open a ZEIP without a designated team, which will make the ZEIP "up for grabs".

ZEIP types

CORE

This proposal will change the core exchange smart contracts code. Roughly speaking, it concerns modifications to the following folders of the monorepo:

• exchange
• asset-proxy, erc20, erc721, erc1155
• staking
• multisig

NON-CORE smart contracts and utils

This proposal expands the capabilities of users of 0x, while not making changes to the core protocol, not affecting how user funds are accessed. It includes all smart contracts excluding exchange.sol, staking.sol and asset proxies, for example those in the following folders:

• dev-utils
• exchange-forwarder
• coordinator
• extensions
• bridge-sampler
• new liquidity bridges

This category can include off-chain tooling as well, as long as there is one interface point with smart contracts.

PARAMETERS

Parameters that are needed for the system to function, and can be set via SetParameters type of calls

• staking parameters (including protocol fees)
• security parameters (such as timelocks)

OPERATIONS

This proposal affects operational protocol details such as release scheduling or proposals for ZEIP mergers.

For example, under this standard, ZEIP-72 would be considered a "Operations" ZEIP.

Process and tagging

1. [no tag] proposer follows the template ZEIP to submit a proposal. Mandatory items include:
   1. description / meta (abstract, problem..)
   2. designated team
   3. (if necessary) sponsor
2. [no tag] the community discusses
   1. search for designated team
   2. search for sponsor if type Core
   3. implementation strategy is defined
3. [ACCEPTED]
   1. designated team accepted to work on it
   2. sponsor accepted to pay for audit
4. [POLL]
   1. ZEIP is surfaced in ZRX Portal for poll
   2. minimum turnout required to move to the implementation phase
   3. gives green light on implementation and funds for audit
5. [POLL PASSED]
   1. implementation by designated team.
   2. all PRs should be tagged to the corresponding ZEIP (issue)
6. [AUDIT] (CORE type only)
   1. audit handled by sponsor
   2. updated contracts are deployed
7. [EXECUTIVE VOTE]
   1. Executive Vote on audited deployed code implementation
   2. ZEIPs of types PARAMETERS or Operations can go directly to this step
8. [IMPLEMENTED]
   1. ZEIP is closed

There are exceptional cases that can cause a ZEIP to be closed

• REJECTED
  • the ZEIP did not pass a poll or an executive vote
• ABANDONED
  • the ZEIP was inactive for a long period of time
• SUPERSEDED
  • the ZEIP was eventually superseded by another ZEIP that will be referenced appropriately in the comments.

ZEIP Template

Each ZEIP will have to follow this template

Who manages the ZEIP process?

It’s important to set the expectations that while it is the community’s ultimate goal to have a fully decentralized onchain binding system for the governance of the 0x protocol, these are the first steps that come with trade-offs.
In this proposal, a selected committee will be in charge of moderating and maintaining the ZEIP queue. The goal of the committee is to maintain a high quality experience for the community, where anyone is encouraged to participate while making sure the proposals meet the minimum standard of clarity and pertinence.
The current committee is composed of 0x Core team members, but we’re open to hearing from any candidates who would like to help.

The committee has the power to:

• request more details to the ZEIP owner, or direct them towards an existing ZEIP
• close a ZEIP for discretionary reasons (incomplete information, overlap, abandoned or low activity)
• kick-off of block a poll vote

I have an idea/problem I would like to share but it's not at a stage where it doesn't constitute a ZEIP yet. What should I do?

We encourage to utilize the forum for discussing draft ideas or share problems you think should be solved. Once the idea starts being fleshed out with the first implementation/architectural details, it's a good time to create a ZEIP. There is no clear cut between the two phases, but you can refer to "What makes a ZEIP great" section above for general guidelines.

What if multiple ZEIPs end up being bundled?

ZEIPs could be bundled together at any time if the owners agree. One of the two ZEIPs will be closed and marked as superseded. If a poll was already taken on the superseded ZEIP, the committee will assess whether another poll will be required for the new ZEIP.

What’s the turnout required in a poll?

We propose a minimum of 0.5% ZRX (5M ZRX) voting power for a ZEIP to be considered for implementation. This is based on the current turnouts we have seen in the past.
In the future, as we build a fully binding governance system, this parameter could be set up for a vote.

What’s the turnout required in an executive vote?

There is no minimum turnout required for executive votes.

Notes

The proposal takes inspiration from (and in certain instances directly quotes) Ethereum's EIP process.