0x Roadmap 2019 (part 1): ZEIPs
Introduction
The 0x core team had an incredibly productive 2018. We shipped a number of products including 0x Instant, 0x Launch Kit, 0x Portal, and a brand revamp. We launched programs to grow the ecosystem from a variety of different angles, including the Ecosystem Acceleration Program which has funded a number of incredible builders, the Market Maker Program which is helping market makers bring liquidity to markets, and Coinbase Earn which is introducing crypto enthusiasts to 0x and the broader DeFi space. The team grew from 9 to 30 team members and we saw dozens of Ethereum projects integrate 0x protocol into decentralized applications.
Going into 2019, the core team’s objectives are to bring deep liquidity to relayers, build out our data infrastructure to gauge the impact of our work on different areas of the ecosystem, and to grow the DeFi pie by exposing users to the many projects building financial infrastructure on Ethereum. Our research team is pursuing innovations in market design, network economics, and the application of cutting edge cryptography for scaling.
We are planning to release a series of “0x Roadmap” posts that dig into some of the projects we will be working on in the next six or so months. This first post will specifically focus on our roadmap around 0x Improvement Proposals (ZEIPs). Due to the forward-looking nature of ZEIPs, this post will provide a cursory glance into some (but not all) of the other areas we are focusing on. Some of these ideas are still in the early stages of development and will be covered in more detail in future posts.
0x v2.0 is designed for iterative upgrades
When developing Ethereum smart contracts that are intended to serve as financial infrastructure, one must set an incredibly high bar for code quality, test coverage, and safety. A popular philosophy among startups is to move fast and break things; this is the wrong mentality for smart contract development where code is safety-critical. Our experience getting 0x v1.0 out the door made it clear just how deliberate and expensive smart contract development can be. This experience informed the architectural decisions behind v2.0.
Thirteen months passed between the launch of 0x v1.0 and v2.0; about half of that time was spent going through independent security audits and the subsequent bug bounty. More than $300k was spent to vet the system. While the transition to 0x v2.0 gave us an opportunity to add some cool new features, the most significant change was the move to a completely new architecture, designed to support a tighter smart contract development cycle. Now we can build compact modules that slot into the existing pipeline and that are easier to audit due to their low complexity. Security audits can be completed in 2–4 weeks rather than 4–6 months, allowing for more rapid iteration.
0x v2.0 is battle-tested, designed for iteration, and there are already a number of 0x improvement proposals (ZEIPs) queued up. Members of the 0x core team are excited to move quickly. However, we are now working with a live system that has access to a great deal of digital assets. It is critical that we put a more formal structure around the ZEIP process to ensure the community can help drive decision making, communicate needs, and provide oversight.
ZEIPs
0x Improvement Proposals (ZEIPs) were introduced as a concept almost six months before 0x v1.0 was launched on the Ethereum mainnet. To date, ZEIPs have primarily been used by the core team to propose and document potential upgrades to 0x protocol’s system of smart contracts. There has not been any formal process for vetting and prioritizing these proposals; it is time to change that.
The ZEIP process is intended to promote efficient decision making among our community (which includes teams with a range of needs) by reducing uncertainty. It is governance, albeit an early form of it. While it is premature to put a binding on-chain governance system in place, I believe we need to set a precedent that all safety-critical changes are vetted and confirmed by the community by way of a token vote. Even if the voting process isn’t yet bound by blockchain consensus and the proposed upgrades are non-contentious, it is healthy to go through the motions to learn and to hold ourselves to a high standard with respect to security.
What can we learn by going through the ZEIP process? There are number of areas to focus on besides procedure. For example, most humans aren’t full-time Solidity developers, so how does one objectively communicate — such that anyone can understand — a ZEIP’s potential risks, impact, and level of complexity? It isn’t uncommon for internet tribes to be swayed by unqualified, yet highly influential pundits. How can we establish a process that eliminates seeds of uncertainty from which disinformation is bourn? What can we learn from governance conflicts in other crypto communities?
In the next few months, the 0x core team will put forth some of the first ZEIPs (described below), work with the community to improve the ZEIP process, and undoubtedly learn a ton along the way. Before any of that happens, we will release a separate post that details how the ZEIP and token voting processes will work and gradually become decentralized over time.
ZEIP-23: support multiple assets on each side of a trade
ZEIP23 introduces a new component to 0x protocol’s pipeline of Ethereum smart contracts — the MultiAssetProxy (MAP) contract — which makes it possible to atomically trade any arbitrary bundle of ERC20/721 tokens. Numerous teams have expressed the need for this feature, and it can support a variety of use cases:
- Sell 20-card booster packs for your ERC721 trading card game.
- Buy a cluster of neighboring LAND parcels in decentraland to establish your virtual territory.
- Open a short position within a categorical prediction market. For example, use Augur or Veil to bet against a specific political party winning the 2020 US presidential election by going long all of the other political parties.
ZEIP23 has reached the end of the ZEIP process; development is complete and the implementation recently passed a security audit. The final steps before integration can take place will be a bug bounty and a confirmation vote by ZRX token holders. If accepted, the MAP integration should take place by late February 2019.
ZEIP-24: support for the ERC1155 token standard
ZEIP24 adds support for the ERC1155 token standard, which allows a single smart contract to maintain user balances across a collection of internal ledgers. The design is ideal for use cases that require large-scale creation of tokens such as gaming, loan origination, and prediction market platforms. Instead of deploying a vast number of distinct ERC20 tokens that each maintain a single ledger, an ERC1155 token can collect all of these ledgers into a single smart contract. Projects that have committed to using the ERC1155 token standard include Gnosis, Horizon Games, and Enjin. The ZEIP is still being drafted and has a target launch window of Q2, 2019.
ZEIP-X: Trade Execution Coordinator (TEC)
Today the two most common relayer models are the open orderbook and order matching models (although there are others: BoxSwap, for example, uses a p2p model). We will soon release a ZEIP and specification for a TEC, an extension contract that enforces a strict set of rules around trade execution and that combines some of the best attributes of existing relayer models. The TEC will prevent front-running/trade collisions and allow for free off-chain order cancellations without sacrificing the ability for third-party smart contracts — such as dYdX — to consume 0x liquidity. We are targeting a launch in late Q2 2019 for the first version of the TEC which will likely be somewhat centralized in nature, but will hopefully prove out the concept, leading to more decentralized designs and research interest in the future. You can learn more about the TEC concept here.
Relatedly, Peter Zeitz, one of 0x’s research fellows, has been digging into the latest academic research on market design and has discovered some interesting concepts that may find their way into the TEC (or a later version of it). In particular, he has been studying market designs that eliminate advantages that arise due to differences in market maker latency, leading to a better market making experience and better prices. Peter will be writing up a detailed explanation of his findings in a future post.
0x Protocol v3.0
We are targeting the next major version bump for 0x protocol to occur in Q3 of 2019. The move to 0x v3.0 will involve replacing the Exchange contract which contains the bulk of the system’s logic for trade settlement. The transition from 0x v1.0 to v2.0 involved migration to a completely new system of smart contracts; it was a disruptive process that halted trading. Traders were required to reset their token allowances and relayers were forced to shut down their v1.0 order books and spin up empty v2.0 order books. The process took months to play out and a number of traders dropped off. In contrast, the transition from v2.0 to v3.0 will require zero disruption to markets; users won’t have to do anything to take advantage of the upgrade and relayers will be able to smoothly transition their order books with zero downtime. Relayers will not even need to clear their order books; both 0x v2.0 and v3.0 orders can exist on the same orderbook. The experience for traders should be seamless.
The bump to v3.0 is an opportunity to integrate multiple ZEIPs. Areas of focus will likely include more flexible order matching, extending 0x protocol’s ability to leverage meta transactions, and generalized callbacks that unlock a richer experience for smart contract devs. Finally, the update will provide us with an opportunity to revisit ZRX token mechanics and how they may be used to incentivize liquidity. The role of the ZRX token as a means of paying relayer fees has been a frequent focus of conversation both externally and on the core team. One of the most compelling properties of tokens is that they have potential to serve as rocket fuel for network effects, and we are excited to share some of our ongoing research on the topic soon.
Concluding Thoughts
This post presents our short term plans for formalizing the ZEIP process and a few of the ZEIPs we will be pushing to the community over the next six months. We have a number of teams working in parallel on different layers of the stack and this post only discusses those projects concerning the 0x protocol’s base layer smart contracts. We will be releasing subsequent posts that discuss our research into network economics, our plans for a community treasury controlled by ZRX token holders, and a community-driven ecosystem acceleration program. Stay tuned!
