Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
- 0x protocol’s pipeline of smart contracts can accommodate upgrades without downtime or disruption to markets.
- The ZRX token will drive a governance process that allows stakeholders to securely execute these protocol upgrades.
- ZRX as a fee token enhances governance by ensuring the token distribution converges on a representative sample of protocol stakeholders over time.
- 0x protocol’s transition to community governance will occur in phases that shift control to ZRX holders.
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.
Phase I: Community Managed Token Registry
The 0x white paper proposes a Token Registry contract which stores ERC20 token metadata (i.e symbol, name, address, decimals) and that serves as a canonical on-chain reference that market participants use to verify token addresses and exchange rates before entering into a trade. Since the registry is a trusted source of information, oversight is needed when adding or modifying information within the registry. The 0x white paper proposed that 0x stakeholders would provide this oversight but, to date, the registry has been centrally managed by the 0x core team. Recently, the concept of a community managed on-chain registry has matured and been termed token curated registry (TCR). Staying consistent with our white paper, the first phase of our governance roadmap will transition the Token Registry contract to a community managed TCR.
This is a logical first step as a comprehensive registry of token metadata will be a valuable resource for the community, centrally managing the registry does not scale and a community managed TCR is a relatively low stakes cryptoeconomic system. Given sufficient vetting, dApps will be able to rely on the Token Registry to safeguard users from inadvertently interacting with malicious tokens. We plan for the transition to occur during the second half of 2018. We are working together with Aragon Labs, led by Luke Duncan, to make this a reality.
Phase II: Community Veto Power
While we want to shift governance over the 0x pipeline to token holders as soon as possible, launching a token voting scheme that hasn’t been properly vetted would be irresponsible. Instead, we will take an incremental step towards this goal by launching a system that allows upgrade proposals to be submitted by the 0x core team and vetoed by ZRX holders.
There are a few ways that this could work. At a high level, the 0x core team will work with the community to build social consensus off-chain, perhaps using tools similar to Carbon Vote to measure sentiment. Contracts that appear to have social consensus will be deployed to the blockchain and a proposal will be created to add the new contract to the 0x pipeline. At this point, ZRX holders will have a window of time during which they may veto the proposal on-chain. This is a low stakes, intermediate step that will shift influence to the community.
Phase III: Liquid Democracy
We are currently exploring liquid democracy, a delegative voting scheme, as a potential governance system for phase 3 of our governance roadmap. Liquid democracy has a few interesting properties that make it attractive for governance over the 0x pipeline.
Leaders such as Vitalik Buterin and Charlie Lee have coordinated large communities to embrace innovation in ways that would be challenging for a community without an explicit or implied leader. A common argument that follows is that the increased coordination costs associated with decentralized governance can hamper innovation (at least early on) and that a core dev team should make all of the decisions. A nice property of delegative voting is that these schemes allow the community to assign voting power to the core dev team, but voting power is extremely fluid and can naturally disperse as the project matures or as incentives delineate.
FAQ
Will this post attempt to address ZRX valuation?
No.
But MV=PQ…
Recent discussions around token mechanics reference velocity as a key driver of token value over time (see Vitalik, Multicoin). In summary, the value of a token that exists purely as a medium of exchange will approach zero as decentralized exchange solutions such as 0x push velocity towards infinity.
Average Network Value = Total Transaction Volume / Velocity
While casual users of 0x protocol may choose to pay slightly more to purchase ZRX just-in-time (~$0.11 gas/trade at the time of writing + the cost of crossing the spread), heavy users that are consistently trading on 0x protocol will save this amount on each trade by holding some amount of ZRX tokens to cover fees. It follows that the dollar value of ZRX tokens a trader may choose to hold is proportional to the dollar value in fees they plan on incurring over some time horizon, adjusting for volatility risk. Abstracting away medium of exchange tokens from end users is a core use case for 0x protocol and the ZRX token will capture some of this value through greater total transaction volume.
Velocity aside, ZRX is a governance token. The primary value proposition for ZRX was never that it would serve as a medium of exchange. Value is derived from the network effects around liquidity that are uniquely enabled by 0x protocol’s open design and sustained through governance.
Now, back to the technical questions.
What types of changes are planned for Ethereum that could impact 0x?
- New cryptographic primitives. Crypto abstraction (EIP101) and account abstraction (EIP86) will allow developers to leverage new signature schemes (RSA, ring signatures, Schnorr, BLS, SNARKS/STARKS) and hashing algorithms (BLAKE2b).
- New EVM capabilities. Ranging from simple changes such as the addition of the REVERT instruction to foundational changes like parallelizability, SIMD operations, and new opcodes that allow for static analysis.
- New Solidity features. Solidity is the most mature high-level programming language for writing Ethereum smart contracts, however, it is still young and evolving. As Solidity matures, there will be opportunities to make the 0x smart contracts more efficient, modular and extensible. For example, support for structured data in the contract ABI (EIP50) has only recently shipped in Solidity v0.4.20 — it is still experimental — but will allow for greater abstraction when passing structured data such as 0x orders between contracts.
- New high-level programming languages. While Solidity is the most popular programming language today, this may not always be the case. If alternatives like Vyper become more common, it may make sense to port the 0x contracts over to support new features and/or ensure developers can continue to contribute to the 0x code base.
- Migration to eWASM from EVM.
What types of changes could be made to 0x’s core functionality?
- Support for new token standards. The community has put forth ERC721, ERC821, ERC223, ERC777 and many other proposals for new token standards that address deficiencies in existing token standards or that allow for new use cases.
- More efficient trade settlement.
- More advanced trade functionality and fee sharing capabilities.
- Modifications to token mechanics.
- Modifications to the governance process.
What might happen if 0x couldn’t support upgrades?
While the Ethereum blockchain is in its infancy, there have been numerous examples of smart contracts requiring upgrades and going through disruptive migration processes.
Example 1: Augur’s REP token.
Augur was the first project to do a token sale on the Ethereum blockchain back in August of 2015. Augur’s Reputation token (REP) is an example of a smart contract that required mass migration due to an unforeseen vulnerability in the toolset used to compile the contract. In short, the original REP token contract was written in the Serpent programming language and compiled with the Serpent compiler, which were the default dev tools early on. A year later, the Augur team contracted out a security audit of the Serpent compiler to Zeppelin, which discovered a buffer overflow vulnerability that affected the REP token.
Ultimately, the Augur team had to freeze the REP contract — preventing transfers — and copy over the balances of many thousands of REP holders to a new ERC20 token contract that was built using more modern dev tools. The old REP token was being traded on more than 20 different centralized cryptocurrency exchanges at the time. They were all required to freeze trading to wait for the migration to complete. It was a disruptive and confusing process.
The fact that the migration was handled in a centralized way allowed it to be completed quickly. However, it could have been much worse. If Augur’s prediction market platform was live, the migration process would have brought markets to a halt and could have led to serious consequences as the REP token is used to resolve prediction market outcomes.
Example 2: EtherDelta
EtherDelta is one of the dApps that has been live for the longest amount of time. In the 18 months that EtherDelta has been live, the smart contract has been upgraded four times. Traders were required to withdraw their tokens from the deprecated EtherDelta contract and deposit them into a brand new smart contract. This is a tedious and costly process: a trader must complete three transactions to migrate a single ERC20 token to the new smart contract. If there are eventually going to be millions of traders and millions of tokens plugged into the 0x smart contracts, such a migration process could congest the blockchain for months at a time and incur enormous costs.
On-chain governance vs. social consensus?
Both are necessary. Social consensus should be used to drive the creation of formal proposals, which are then accepted or rejected on-chain.
How does governance work in 0x more technically?
The 0x pipeline is broken into modules:
- Orders are passed to the Exchange module, which contains the business logic for authenticating orders and settling trades.
- Governance contains the business logic for moving proposals through a formal on-chain governance process and adding/removing contracts from the pipeline.
- GeneralizedProxy ties the Exchange and Governance modules together and allows theExchange module to access users’ tokens via sub-proxies.
- In version 2 of 0x protocol, each token standard or class of digital asset will have it’s own SubProxy that has access to user trading balances.
Governance is used to remap the connections between different Ethereum smart contracts in the pipeline.
Adding support for a new token standard to the 0x pipeline. The Governance module adds a new SubProxy and ExchangeV3 contract to the whitelist contained within the GeneralizedProxy state.What other ideas around token mechanics were explored?
In considering how to couple the token to the core protocol and shift the token distribution towards a representative sample of stakeholders, we explored a range of possibilities. A couple of inflationary models we considered:
- Create a relayer subsidy that mints new ZRX tokens for each trade a relayer facilitates.
- Create a maker subsidy that mints new ZRX tokens to market makers that provide liquidity.
Inflationary models are interesting because tokens accrue to the people providing utility to the protocol and a subsidy can bootstrap early adopters. However, without a mechanism that is impossible to game such as PoW, relayers or market makers can wash trade to collect trade subsidies and inflate the token until it is worthless. We identified potential solutions, but they were impractical from an implementation standpoint.
Doesn’t low voter turnout make an “ideal” token distribution an ineffective metric by which to judge the robustness of a governance system?
We argue that voter turnout is driven by governance mechanics among other factors. Regardless of governance mechanics, for any governance system that relies on token voting, it is objectively better to drive the steady state token distribution towards a representative sample of stakeholders.
We can attempt to increase voter turnout by making it as easy as possible for voters to participate. Voting should be as simple as receiving a push notification to your phone and clicking a button. Or just delegating your vote to an expert that represents your interests.
Some relayers aren’t taking fees in ZRX. How and why?
Version 1 of 0x protocol was not optimized for relayers using the order matching strategy (find descriptions of the other strategies here). As a result, it is more gas efficient for matchers to take fees in the form of a spread rather than in the form of ZRX tokens. The figures below show a trade from an open order book relayer and a trade from an order matching relayer; to take fees in ZRX, an order matching trade would require two additional state changes.
A trade from an order matching relayer displayed on Etherscan. Tokens are transferred between maker and taker via the order matcher. The order matcher is taking a small chunk of tokens from each side of the trade. If fees were taken in the form of ZRX tokens, the maker and taker would each have an additional transfer of ZRX tokens to the order matcher (6 total token transfers).A trade from an open order book relayer displayed on Etherscan. Tokens are transferred directly between maker and taker. If fees were present, the maker and taker would each have an additional transfer of ZRX tokens to the relayer (4 total token transfers).
Version 2 of 0x protocol will add support for atomic order matching which will allow matchers (and arbitrageurs) to fill valid crossing orders on opposite sides of the market without requiring upfront capital and with the minimum number of token transfers.
Doesn’t requiring traders to purchase ZRX upfront create friction?
Yes, requiring ZRX for fees creates additional friction for new users getting started with 0x protocol. There are a variety of ways that we can reduce this friction. For example, the 0x trade widget will enable “1-click token purchases” and abstract away the need for WETH and ZRX. This will make it easier for casual, less price sensitive users to access relayer liquidity without having to go through an on-boarding process.
Will the 0x core team attempt to force relayers to take fees in ZRX?
No. While we believe that a broad distribution of ZRX tokens is critical for governance and have set ZRX as the default fee token, it is important that 0x protocol is as extensible as possible. We will not place additional constraints in 0x protocol that prevent relayers from routing around ZRX if it means that the protocol provides less room for developers to innovate.
Should future blockchains bake in their own native exchange protocol, absorbing something like 0x as a feature? (reference: Chris Burniske tweet)
First, are any blockchains doing this today? Yes. BitShares uses special transaction types for a native DEX that is built into the underlying blockchain. Stellar includes a native DEX that takes the form of an on-chain order book. Waves uses an off-chain order matching model that is somewhat similar to 0x in design but trades are natively baked into the Waves blockchain in the form of a special transaction type called an ExchangeTransaction.
There are serious drawbacks to hardcoding exchange functionality into the base protocol. The most obvious drawback is that the entire network must fork to modify exchange functionality. In contrast, 0x protocol can be modified without requiring the Ethereum blockchain to hard fork. This separation of concerns allows the 0x community to focus on improving exchange functionality without relying on or corresponding with the broader Ethereum community.
Further, hardcoding exchange functionality into the base protocol leaves no room for a creative ecosystem to form. Separating the tech stack into separate layers makes it easier for each layer to evolve free of technical debt in adjacent layers.
Governance in 0x Protocol was originally published in 0x Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.