Roadmap

0x v2.0 is designed for iterative upgrades

0x v2.0 is battle-tested, designed for iteration, and there are already a number of ZEIPs queued up. Members of the 0x core team are excited to move quickly. However, they are now working with a live system that has access to a great deal of digital assets. It is critical that they 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.

In the next few months, the 0x core team will put forth some of the first ZEIPs, work with the community to improve the ZEIP process, and undoubtedly learn a ton along the way.

ZEIP-23: support multiple assets on each side of a trade

Figure 1: use 0x protocol to trade arbitrary bundles of assets. As shown above, one could trade six Gods Unchained cards for five DAI + three Decentraland LAND parcels, all in a single atomic transaction.

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 passed a security audit.

ZEIP-24: support for the ERC1155 token standard

Figure 2: the ERC1155 token standard allows an unlimited number of digital asset ledgers (shown as spreadsheets) to be maintained within a single Ethereum smart contract (grey rectangle), eliminating the need to deploy numerous ERC20 contracts.

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.

ZEIP-X: Trade Execution Coordinator (TEC)

Figure 3: a TEC is a system that receives multiple incoming streams of smart contract-consumable orders, that filters out order collisions, and outputs a single order stream to be fed into the 0x contracts (see: multiplexer).

Today the two most common relayer models are the open orderbook and order matching models. The team releases 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. The 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.

0x Protocol v3.0

The team is 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 0x 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.

Layer one and layer two

In short, layer two is where the transactions will happen most of the time, and layer one is always there to guarantee that everything is done correctly. Layer one doesn’t get involved unless it has to. In many ways it acts as a court to resolve conflicts in layer two.

Layer two trade offs

There are many trade-offs in layer two solutions having to do with where data is stored and how the blockchain is informed of the goings-ons of layer two. There are two guiding principles:

Principle 1: Cryptographic guarantees. It should be impossible to break the guarantees of the system, not merely expensive.

Principle 2: Exponential scaling. Any layer two scaling solution should allow for exponentially more transactions than layer one.

Scaling Decentralized Exchanges

Right now scaling may not seem a big concern in DEXs. While DEXs constitute a significant fraction of all Ethereum transactions, there is still plenty of room for it to grow. The team’s expectation is that usage can go up by about 5x before it becomes problematic.

Remember that it is still very early days for DEXs. They are looking at a 100x increase before centralized crypto exchanges are replaced. With tokenized securities it will be another two orders of magnitude to support the loads of traditional security exchanges. Add another two for mainstream consumer adoption.

Long term, they expect the majority of the trading volume to come from tokenized assets that currently don’t have a marketplace, like prediction markets or game items.

Zero Knowledge Proofs

A zero knowledge proof allows someone to do a computation on some data and prove that they did this computation correctly, without revealing the data.

ZKPs for scaling

Research done between 0x and Starkware shows that STARKs proofs can be verified on Ethereum today without requiring any changes to the protocol. The team is currently working on a proof-of-concept implementation to demonstrate the performance on testnet.

Evolving the 0x stack

ZKPs are a powerful new tool that are well-suited for the DEX use case, but how do they fit into the 0x roadmap? Isn’t this a completely different technology?

Right now 0x has the Standard Relayer API to connect liquidity together between different relayers, market makers, and 0x Instant. This works, but is kind of an old-world way of doing things. Each endpoint must be correctly implemented and each connection must be setup manually. The team is working on a peer-to-peer network transport layer that automates all of these connections, greatly increasing order flow throughout the ecosystem. As an added bonus, they are making the whole thing work in the browser so you can participate in the decentralized liquidity network without having to install a node!

With networked liquidity improved, the next step is to coordinate trades. Trade execution coordinators (TECs) are little services relayers can opt into. These coordinators provide a variety of benefits including protection against front-running, innovative marketplace mechanics, and soft cancels. They can do this while still allowing unrestrained liquidity sharing.

When trades are ready to be settled, they get collected in large batches and processed. The final result of all this is a small proof that shows all of it was done correctly. This proof is submitted to the on-chain contract for verification.

Looking even further ahead

Instead of straying away from the current design, the team hopes to replicate the 0x pipeline on different shards and stateful blockchains, and use cross-chain governance to push out synchronized updates. Each replica of the 0x pipeline, or “embassy,” will support local shard-specific trading activity and, due to the system’s extensibility, it should be able to support most use cases.

The highly scalable ZKP-based sidechain will plug into each of these embassies, allowing users to seamlessly transition from synchronously trading their assets locally with other people on the same shard to synchronously trading on a global network that connects markets together.

In March the team introduced 0x Mesh, a peer-to-peer network for sharing orders which will serve as an alternative to the Standard Relayer API. 0x Mesh will massively reduce the effort required to tap into the 0x networked liquidity pool and the technical work associated with maintaining a compliant endpoint. One of the most compelling aspects of 0x protocol is its ability to facilitate networked liquidity: the seamless flow of orders through a network of interconnected marketplaces and dApps. The Radar team has described networked liquidity as a paradigm shift that transforms the term “exchange” from a noun to a verb. The 0x team agrees with this assessment.

While market participants tend to meet in specific locations to facilitate more efficient markets, networked liquidity allows orders to flow outward through a growing number of web3 capillaries, reaching a broader cross-section of users. These interconnections act as a source of network effects that lead to a greater number of opportunities for market makers and better prices for end-users.

Over the past months, the 0x Core Team has shipped key components needed to facilitate networked liquidity. 0x Instant allows orders to flow to a variety of surfaces including popular Ethereum wallets (MyCrypto), dApps (Augur), and blockchain explorers (Coingecko, EtherScan). 0x Launch Kit provides a simple way for developers to launch a custom digital asset marketplace in a matter of minutes. The one underlying component that all of these products have heavily relied upon is the Standard Relayer API (SRA), which provides guidelines for sharing orders between endpoints. Moving forward, 0x Mesh can connect these products and tools in a more seamless way.

The team is planning to launch a beta version of 0x Mesh with a handful of early participants near the end of Q2 2019. The 0x Mesh beta will be written in Go and will be compiled to WebAssembly when run in the browser. It will use WebRTC as a first-class protocol for inter-node communication (both browser and non-browser based nodes) and will rely on signaling servers to bootstrap connections between peers. The team has developed a novel order eviction algorithm that precludes the need for explicit staking while preventing malicious nodes from filling up the available space on other nodes and evicting the orders of benign users.

Key points