Roadmap and the role of the ZRX token
- 0x protocol’s pipeline of smart contracts accommodate upgrades with out disruption to markets.
- ZRX as a fee token enhances governance by ensuring the token distribution converges on a representative sample of protocol stakeholders.
- 0x protocol’s transition to community governance will happen in phases that shift control to ZRX holders.
- The ZRX token will drive a governance process that permits stakeholders to securely execute these upgrades to the protocol.
Public Infra Demands Coordinated Upgrades
In October of 2016, Amir Bandeali decided to build a decentralized exchange on the Ethereum blockchain. The intention was to create a for-profit business around an efficient, proprietary system of smart contracts that would allow folks to charge trading fees. As he met with other Ethereum projects in the dev community, he 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 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 Bandeali that the system of smart contracts could have the greatest impact if we were to open it up for anyone to plug into. They started repurposing our proprietary system into an open protocol around December 2016.
Having spent time developing on Ethereum and seeing quick iteration across all layers of the technology stack, they knew that upgrades to the system would be frequent (and unavoidable). So, they designed the system to accommodate upgrades. Conceptually, the 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 six months or so.
Around this time, they were seeing signs of an emerging token economy on the Ethereum blockchain that could grow to become much larger in scale than they initially imagined. A few thoughts occurred:
- Opt-in upgrades could fragment the network into incompatible subnetworks (similar to a hard fork), destroying the network effects.
- An open protocol for exchange could possibly support a global network of interconnected exchanges, marketplaces as well as dApps that share infrastructure, thus leading to network effects.
- This pipeline of smart contracts could end up facilitating many billions of dollars in exchange so the upgrade process must therefore be extremely secure as well as invulnerable to censorship and/or government interference. In other words, admin over upgrades must be decentralized.
- The process of upgrading the pipeline of smart contracts must be coordinated by stakeholders rather than by a central party and should thus occur without disrupting markets.
Token Voting Schemes Decentralize Governance
They began exploring ideas around decentralized on-chain governance in January of last year, often meeting with Fred Ehrsam to plan.
Plenty of teams were experimenting with governance at the blockchain consensus layer, however there was little existing work related to governance implemented within smart contracts. Augur’s decentralized oracle — which was used to resolve the outcomes of prediction markets — was perhaps the closest analogy however 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.
A well designed on-chain token voting scheme could decentralize the governance process. Furthermore, a well designed token could draw a connection between protocol participation and influence. This basically boiled down to two pertinent questions (1) Governance mechanics (e.g. how does on-chain token voting actually work…) (2) Token mechanics e.g how does the token tie into use of the protocol.
Committing to a particular token voting scheme was premature, mainly because 0x was still merely a cool idea.
More to the point, there were no tools available for analyzing cryptoeconomic systems – and committing 0x to any particular voting scheme at the outset would have been tricky. Instead, they decided to leave governance open ended and thus to take incremental steps towards token voting as the field of associated tools and decentralized governance advanced.
Tokens Should 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 folks to work backwards.
- Who are the stakeholders in 0x protocol? Relayers, market makers, traders, and dApp developers.
- What makes for a good governance process? All stakeholders’ interests are accounted for in the governance process.
- Can token mechanics guarantee the token distribution naturally converges on a representative sample of protocol stakeholders over time?
A good question is to ask: if the governance process experiences a huge failure in which an objectively harmful proposal is passed, which group of stakeholders thus has the most to lose?
While the entire ecosystem is hurt in this event, traders are the only group that necessarily reveal their digital assets to the compromised pipeline of smart contracts.
It is key that traders have enough influence over the governance process to potentially veto malicious 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.
Take 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.
The team initially explored having traders place ZRX security deposits that could be deleted in the case of accidental overcommitment by makers (i.e placing orders for more funds than they have available) by enforcing a 1:1 correspondence between open orders and security deposits.
If a market maker assigned two orders to the same security deposit or if one of their live orders became unfunded, their associated deposit would be further slashed.
This mechanism would not only help avoid some race conditions, it would also ensure traders acquire tokens in proportion to their use. Eventually they determined that the implementation would add significant complexity to the smart contracts and lead to a sub-par user experience.
It was also not ideal 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.
The only feasible mechanism we at CBNN could identify that would ensure ZRX tokens end up in the hands of traders (at least the heavy hitters) was to require ZRX be used to pay fees to the relayers. From an implementation standpoint, this was by far the simplest solution. However, forcing new users to acquire ZRX tokens can be an unnecessary point of friction when getting started.
We believe this to be the most reasonable mechanism to date, and we believe that the community should be actively involved in evolving token mechanics if a better approach becomes more feasible in the near future.
The 0x core team has made consistent progress building out infrastructure for digital asset exchange. The team at Aragon has been building aragonOS which provides modular smart contract building blocks that can be assembled to create complex as well as 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.
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 as well as risk; there is a high probability that the roadmap will evolve as new tools 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) and that serves as an on-chain reference that market participants use to verify token addresses as well as exchange rates before entering into a trade.
Because the registry is a trusted source of info, oversight is necessary when adding or modifying information within the registry. The 0x white paper proposed that 0x stakeholders would provide this oversight however, to date, the registry has been centrally managed by the 0x core team.
Recently, the concept of a community managed on-chain registry has progressed and been termed token curated registry (TCR). Staying consistent with the white paper, the first phase of the 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 doesn’t scale and a community managed TCR is a relatively low stakes cryptoeconomic system.
Given good vetting, dApps will be able to rely on the Token Registry to safeguard users from accidentally interacting with nefarious tokens.
Phase II: Community Veto Power
While they want to shift governance over the 0x pipeline to token holders ASAP, launching a token voting scheme that hasn’t been properly vetted would be irresponsible to say the least. Rather, they 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 potentially vetoed by ZRX holders.
There are a few ways that this could function. The 0x core team will work with the community to build social consensus off-chain, perhaps using tools similar to Carbon Vote in order 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. Thus, ZRX holders will have a window of time during which they may veto the proposal on-chain. This is a low stakes, intermediary step that will shift influence to the community.
Phase III: Liquid Democracy
The research team is currently exploring liquid democracy, a delegative voting scheme, as a potential governance system for phase 3 of the governance roadmap. Liquid democracy has a few neat properties that make it optimal for governance over the 0x pipeline.