My goal for this post is to help readers understand how the ZRX token allows stakeholders to securely upgrade 0x protocol without downtime or disruption to markets and why governance is critical when building public financial infrastructure on top of a rapidly evolving tech stack. This post will explain why we initially decided to create 0x protocol and the thought process behind its design. Next, we discuss 0x’s governance roadmap including specific deliverables and timelines. Finally, an FAQ section provides detailed explanations for common questions posed around the ZRX token and governance.

Public Infra Demands Coordinated Upgrades

In October of 2016, Amir Bandeali and I decided to build a decentralized exchange on the Ethereum blockchain. Our intention was to create a for-profit business around an efficient, proprietary system of smart contracts that would allow us to charge trading fees. As we met with other Ethereum projects in the developer community, we came to realize that a wide variety of decentralized applications would require exchange functionality and that many of these projects were planning to launch their own one-off exchange implementations that varied in approach, efficiency and quality. This seemed like a recipe for a bad outcome, not only because these projects were duplicating their efforts, but because liquidity would be fragmented across a patchwork of application-specific decentralized exchanges.

A mounting body of evidence eventually convinced Amir and I that our system of smart contracts could have the greatest impact if we were to open it up for anyone to plug into. We started repurposing our proprietary system into an open protocol around December 2016.

0x is a pipeline of smart contracts. Sections of the pipeline can be replaced and upgraded over time.

Having spent time developing on Ethereum and seeing rapid iteration across all layers of its technology stack, we knew that upgrades to our system would be frequent and unavoidable [find details in FAQ]. So, we designed our system to accommodate upgrades. Conceptually, our system of smart contracts was designed to act as a pipeline where orders enter one end of the pipeline and token balances are modified at the other end. The pipeline was broken into modular segments that could be replaced, allowing us to merge in upgrades without having to shut down markets to migrate our users over to a brand new pipeline every 6 months or so. While upgrading the pipeline was a simple process when we were the only stakeholder, we were now building public infrastructure.

Around this time, we were seeing signs of an emerging token economy on the Ethereum blockchain that could grow to become much larger in scale than we initially imagined. A few thoughts occurred to us:

An open protocol for exchange could support a global network of interconnected exchanges, marketplaces and dApps that share infrastructure, leading to network effects. Opt-in upgrades could fragment this network into incompatible subnetworks (similar to a hard fork), destroying network effects. The process of upgrading the pipeline of smart contracts should be coordinated by stakeholders rather than by a central party and should occur without disrupting markets. This pipeline of smart contracts could end up facilitating many trillions of dollars in exchange so the upgrade process must be extremely secure and invulnerable to censorship or government intermediation. In other words, governance over upgrades must be decentralized.

Token Voting Schemes Decentralize Governance

We began exploring ideas around decentralized on-chain governance in January 2017, often meeting with Fred Ehrsam to brainstorm. Plenty of teams were experimenting with governance at the blockchain consensus layer, but there was little existing work related to governance implemented within smart contracts. Augur’s decentralized oracle — used to resolve the outcomes of prediction markets — was perhaps the closest analog but it was designed to drive consensus around objective truth. Governance over 0x protocol would need to function more like a political process where stakeholders with varying needs and incentives use an on-chain mechanism to come to consensus around which contracts to drop into the pipeline. Merkle’s DAO’s, Democracy and Governance paper and Vitalik’s DAOs, DACs, DAs essay contained pioneering thoughts, but were strictly theoretical.

While there were (and still are) many open questions, it was clear that a well designed on-chain token voting scheme could decentralize the governance process. Further, a well designed token could draw a connection between protocol participation and influence. This basically boiled down to two overarching questions (1) token mechanics i.e. how does the token tie into use of the protocol and (2) governance mechanics i.e. how does on-chain token voting actually work?

Committing to a particular token voting scheme was premature at that point, not least of all because 0x was still just a cool idea. Further, there were no tools available for modeling or analyzing cryptoeconomic systems and committing 0x to any particular voting scheme at the outset would have been a shot in the dark. Instead, we decided to leave governance open ended and to take incremental steps towards token voting as the field of decentralized governance and associated tools matured.

Tokens Need to be in the Hands of Stakeholders

Having determined that upgrades would rely on some form of token voting, we began thinking about if and how the token could interact with exchange functionality to enhance governance. This required us to work backwards.

What makes for a good governance process? All stakeholders’ interests are represented and accounted for in the governance process.

Who are the stakeholders in 0x protocol? Relayers, market makers, dApp developers and traders.

Can token mechanics ensure the token distribution naturally converges on a representative sample of protocol stakeholders over time?

We don’t simply want a wide distribution, we want a distribution that aligns interests and leads to healthy outcomes. A good starting point is to ask: if the governance process experiences a catastrophic failure in which an objectively harmful proposal is passed, which group of stakeholders has the most to lose? While the entire ecosystem is hurt in this scenario, traders are the only group that necessarily exposes their digital assets to the compromised pipeline of smart contracts.

It is critical to maximize the overlap between Ethereum addresses that hold ZRX and the addresses that could lose funds in the case of a successful attack on the governance system.

It is critical that traders have enough influence over the governance process to veto malicious or unfavorable proposals. It follows that 0x token mechanics should naturally maximize the overlap between ZRX holders and the traders that have provided the 0x pipeline with access to their digital assets. Note: a decently designed governance system will include a time delay between when a proposed change to the pipeline is approved and when it becomes active, providing time for traders to safely remove access to their funds if needed.

We initially explored having traders place ZRX security deposits that could be slashed in the case of accidental or intentional overcommitment by makers (placing orders for more funds than they have available) by enforcing a 1:1 correspondence between open orders and security deposits. If a maker assigned two orders to the same security deposit or if one of their live orders became unfunded, their associated deposit would be slashed. This mechanism would not only help us avoid some race conditions, it would also ensure traders accrue tokens in proportion to use. Eventually we determined that the implementation would add significant complexity to the smart contracts and lead to a mediocre user experience. It was also unappealing to force liquidity providers to lockup a scarce resource that could become expensive with adoption; it doesn’t make sense to put an upper bound on the number of liquidity providers that can exist simultaneously.

Given practical constraints, the only feasible mechanism we could identify that would ensure ZRX tokens end up in the hands of traders (at least the heavy users) was to require ZRX be used to pay fees to relayers. From an implementation standpoint, this was by far the simplest solution. On the other hand, forcing new users to acquire ZRX tokens can feel like an unnecessary point of friction when getting started. Ultimately, we believe this to be the most reasonable mechanism to date, and we believe that the community should be involved in evolving token mechanics if a better approach becomes feasible in the future.

Governance Roadmap & Timeline

In the time that has passed since releasing our white paper, the 0x core team has made consistent progress building out infrastructure for digital asset exchange. In parallel, the talented team at Aragon has been building aragonOS which provides modular smart contract building blocks that can be assembled to create complex and upgradeable DAOs. While Aragon is providing the building blocks we need for governance, the broader community has yet to produce a set of tools for modeling and analyzing sophisticated cryptoeconomic systems. We are now committed to developing these tools internally (check out our research and engineering roles).

0x protocol’s transition to community governance will occur in phases that shift control to token holders over time. Each phase will increase in complexity and risk; there is a high probability that our roadmap will evolve as new tools and data become available.