0x protocol: Detailed review on the project
Introduction
0x is an open protocol for decentralized exchange on the Ethereum blockchain. It is intended to serve as a basic building block that may be combined with other protocols to drive increasingly sophisticated dApps. 0x uses a publicly accessible system of smart contracts that can act as shared infrastructure for a variety of dApps. In the long run, open technical standards tend to win over closed ones, and as more assets are being tokenized on the blockchain each month, we will see more dApps that require the use of these different tokens. As a result, an open standard for exchange is critical to supporting this open economy.
Technology
Existing Work
Decentralized exchanges implemented with Ethereum smart contracts have failed to generate significant volume due to inefficiencies in their design that impose high friction costs on market makers. In particular, these implementations place their order books on the blockchain, requiring market makers to spend gas each time they post, modify or cancel an order. While the cost of a single transaction is small, frequently modifying orders in response to evolving market conditions is prohibitively expensive. In addition to imposing high costs on market makers, maintaining an on-chain order book results in transactions that consume network bandwidth and bloat the blockchain without necessarily resulting in value transfer.
Automated market maker (AMM) smart contracts are proposed as an alternative to the on-chain order book. The AMM smart contract replaces the order book with a price-adjustment model in which an asset’s spot price deterministically responds to market forces and market participants on either side of the market trade with the AMM rather than with each other. Benefits of the AMM include availability (it is always available to act as a counterparty, though the spot price it offers may be worse than what one could get from a more traditional exchange) and ease-of-integration with external smart contracts that need to execute market orders. The deterministic nature of price-adjustment models make them insensitive to market liquidity, meaning that trades cause prices to move the same amount in both thick and thin markets. In other words, AMMs impose artificial constraints on the supply curve. If the price-adjustment model is too sensitive, even small trades will produce large fluctuations in the spot price. If the price-adjustment model is not sensitive enough, the AMMs bankroll will quickly be depleted by arbitrageurs.
State channels are proposed as a means of scaling the Ethereum blockchain and reducing costs for a variety of applications — including exchange — by moving transactions off of the blockchain. Participants in a state channel pass cryptographically signed messages back and forth, accumulating intermediate state changes without publishing them to the canonical chain until the channel is closed. State channels are ideal for “bar tab” applications where numerous intermediate state changes may be accumulated off-chain before being settled by a single on-chain transaction (i.e. day trading, poker, turn-based games). If one of the channel participants leaves the channel or attempts to cheat, there is a challenge period during which the other participant may publish the most recent message they received from the offender. It follows that channel participants must always be online to challenge a dishonest counterparty and the participants are therefore vulnerable to DDOS attacks. While state channels drastically reduce the number of on-chain transactions for specific use cases, the numerous on-chain transactions and security deposit required to open and safely close a state channel make them inefficient for one-time transactions.
A hybrid implementation, which we refer to as “off-chain order relay with on-chain settlement,” combines the efficiency of state channels with the near instant settlement of on-chain order books. In this approach, cryptographically signed orders are broadcast off of the blockchain; an interested counterparty may inject one or more of these orders into a smart contract to execute trades trustlessly, directly on the blockchain. Friction costs are minimized for market makers because they can signal intent off-chain and transactions only occur when value is being transferred. We extend this approach by allowing anyone to act as the exchange and by making the protocol application-agnostic.
Specification
Figure 1 presents the general sequence of steps used for off-chain order relay and on-chain settlement. For now a few mechanisms that will become important later are ignored.
Figure 1: Off-chain order relay, on-chain settlement diagram. Gray rectangles and circles represent Ethereum smart contracts and accounts, respectively. Arrows pointing to Ethereum smart contracts represent function calls; arrows are directed from the caller to the callee. Smart contracts can call functions within other smart contracts. Arrows external to the Ethereum blockchain represent information flow.
1. Maker approves the decentralized exchange (DEX) contract to access their balance of Token A.
2. Maker creates an order to exchange Token A for Token B, specifying a desired exchange rate, expiration time (beyond which the order cannot be filled), and signs the order with their private key.
3. Maker broadcasts the order over any arbitrary communication medium.
4. Taker intercepts the order and decides that they would like to fill it.
5. Taker approves the DEX contract to access their balance of Token B.
6. Taker submits the makers signed order to the DEX contract.
7. The DEX contract authenticates makers signature, verifies that the order has not expired, verifies that the order has not already been filled, then transfers tokens between the two parties at the specified exchange rate.
Message Format
Each order is a data packet containing order parameters and an associated signature. Order parameters are concatenated and hashed to 32 bytes via the Keccak SHA3 function. The order originator signs the order hash with their private key to produce an ECDSA signature.
Point-to-point Orders
Point-to-point orders allow two parties to directly exchange tokens between each other using just about any communication medium they prefer to relay messages. The packet of data that makes up the order is a few hundred bytes of hex that may be sent through email, a Facebook message, whisper or any similar service. The order can only be filled by the specified taker address, rendering the order useless for eavesdroppers or outside parties.
Broadcast Orders
For liquid markets to emerge, there must be public locations where buyers and sellers may post orders that are subsequently aggregated into order books i.e. exchanges. Building and operating an exchange is costly and the protocol we have described so far does not provide an incentive for someone to take on such an expense. Broadcast orders solve this issue by allowing anyone to act as an exchange, maintain an order book (public or private) and charge transaction fees on all resulting liquidity. We refer to entities that host and maintain an order book as Relayers rather than exchanges. Where an exchange must build and operate proprietary infrastructure, execute trades and handle user funds, Relayers merely facilitate signalling between market participants by hosting and propagating an order book that consists of generic messages. Relayers do not execute trades on behalf of market participants as this would require market participants to trust the Relayer. Instead, Takers execute their own trades.
The message format for broadcast orders includes two changes to the point-to-point message format to facilitate public exchange and incentivize Relayers. First, broadcast orders do not specify a taker address, allowing a broadcast order to be filled by anyone that happens to intercept it. Second, broadcast orders include feeA, feeB, and feeRecipient parameters which specify transaction fee values and an address used by a Relayer to collect transaction fees. The exchange smart contract transfers these fees to feeRecipient if and when an order is filled. Figure 2 presents the sequence of steps Makers and Relayers use to negotiate transaction fees in a trustless way.
Figure 2: Relayers host and maintain an off-chain order book in exchange for transaction fees. This diagram illustrates off-chain order relay and the sequence of steps used by Makers and Relayers to negotiate transaction fees in a trustless way. Transaction fees are moved from the Maker and/or Taker to the Relayer upon settlement of a trade, extending the on-chain settlement process shown in Figure 2.
1. Relayer cites a fee schedule and the address they use to collect transaction fees.
2. Maker creates an order, setting feeA and feeB to values that satisfy Relayer’s fee schedule, setting feeRecipient to Relayer’s desired receiving address and signs the order with their private key.
3. Maker transmits the signed order to Relayer.
4. Relayer receives the order, checks that the order is valid and that it provides the required fees. If the order is invalid or does not meet Relayer’s requirements, the order is rejected. If the order is satisfactory, Relayer posts the order to their order book.
5. Takers receive an updated version of the order book that includes Maker’s order.
6. Taker fills Maker’s order by submitting it to the exchange contract on the Ethereum blockchain.
While it may seem odd that the Maker is specifying the transaction fees, keep in mind that Relayers ultimately have control over which orders get posted. Therefore, if the Maker wants their order to be posted to a specific order book, they must set feeA, feeB, and feeRecipient to values that satisfy the Relayer associated with that order book. Since fees are negotiated off-chain, Relayers may change a fee schedule dynamically and at their own discretion (for incoming orders that haven’t been signed yet, not for existing orders). Relayers may use information that is available on-chain or off-chain in setting and adjusting fees, allowing for exible fee schedules (at fees, percentage based, volume based, tiered, subscription models, etc). However, once the Relayer has accepted an order onto their order book, the order’s fee values cannot be changed.
Conventional exchange services use a matching engine to fill market orders on behalf of their users and users must trust that the exchange will provide them with the best available price. Generally, users can feel assured that these regulated entities will be held accountable if they attempt to cheat or in the event that a matching engine malfunctions. For 0x protocol to remain trustless, Relayers cannot be given the ability to execute trades on behalf of Makers and Takers. Instead, Relayers can only recommend a best available price to Takers who must then independently decide to sign and send the transaction to the blockchain. This means that 0x protocol cannot support true market orders, however, a well designed web application can approximate this type of user experience.
It is important to recognize that the feeRecipient address can point to any arbitrary smart contract. This means that complex Relayer incentive structures can be “plugged in” to 0x protocol. For example, a feeRecipient contract could be designed to split transaction fees between multiple Relayers or distribute transaction fees across a swarm of nodes according to the level of contribution each node makes in propagating an order book within a censorship-resistant p2p network.
Smart Contract
The exchange protocol is implemented within an Ethereum smart contract that is publicly accessible and free to use (no additional costs are imposed on users beyond standard gas costs). It is written in the Solidity programming language and contains two relatively simple functions: fill and cancel. The entire contract is approximately 100 lines of code and it costs approximately 90k gas to fill an order.
Signature Authentication
The exchange smart contract is able to authenticate the order originator’s (Maker’s) signature using the ecrecover function, which takes a hash and a signature of the hash as arguments and returns the public key that produced the signature. If the public key returned by ecrecover is equal to the maker address, the signature is authentic.
address publicKey = ecrecover( hash, signature( hash ) );
if ( publicKey != maker ) throw;
Fills & Partial Fills
The exchange smart contract stores a reference to each previously filled order to prevent a single order from being filled multiple times. These references are stored within a mapping; a data structure that, in this case, maps a 32 byte chunk of data to a 256 bit unsigned integer. Passing the parameters associated with an order into the Keccak SHA3 function produces a unique 32 byte hash that may be used to uniquely identify that order (the odds of a hash collision, finding two different orders with an identical hash, are practically zero). Each time an order is filled, the mapping stores the order hash and the cumulative value filled.
A Taker may partially fill an order by specifying an additional argument, valueFill, when calling the exchange smart contract’s fill function. Multiple partial fills may be executed on a single order so long as the sum of the partial fills does not exceed the total value of the order.
Expiration Time
An order’s expiration time is specified by the Maker at the time the order is signed. The expiration time is an unsigned integer value that represents the absolute number of seconds since the unix epoch. This value cannot be changed once it has been signed.
Time within the Ethereum virtual machine is given by block timestamps that are set each time a new block is mined. Therefore, the expiration status of an order does not depend upon the time at which a Taker broadcasts their intention to fill an order, instead it depends upon the time at which the fill function is being executed in the EVM by a miner. A miner cannot set the block timestamp of the current block to be earlier than the timestamp of the previous block.
Cancelling Orders
An unfilled and unexpired order may be cancelled by the associated Maker via the exchange smart contract’s cancel function. The cancel function maps an order’s hash to the order’s maximum value (valueA), preventing subsequent fills. Cancelling an order costs gas and, therefore, the cancel function is only intended to serve as a fallback mechanism. Typically, Makers are expected to avoid on-chain transactions by setting their order expiration times to match the frequency with which they intend to update their orders.
One issue with this approach is that it can create situations where a Maker attempts to cancel their order at roughly the same time a Taker is attempting to fill that same order. One of the two parties transactions will fail, wasting gas, depending upon the sequence in which the two transactions are mined. Uncertainty regarding the sequence in which transactions are mined could lead to undesirable outcomes at times. This uncertainty could increase if the Ethereum blockchain were to experience a significant backlog of pending transactions.
Protocol Token
Cryptoeconomic protocols create financial incentives that drive a network of rational economic agents to coordinate their behavior towards the completion of a process. While 0x is fundamentally a network protocol used to facilitate signalling between buyers and sellers (rather than a cryptoeconomic protocol), it is intended to serve as an open standard for dApps that incorporate exchange functionality. Establishing and maintaining an open standard is a coordination problem that adds operational overhead for all contributing parties; coordination can be especially challenging when each party has different needs and financial incentives. Protocol tokens can align financial incentives and offset costs associated with organizing multiple parties around a single technical standard. While aligning incentives around adoption is useful, protocol tokens can be used to address a much more challenging issue: future-proofing a protocol implemented within an immutable system of smart contracts via decentralized governance.
Decentralized Governance
Once an Ethereum smart contract is deployed to the blockchain its internal logic can’t be changed. Therefore, to update a protocol one must deploy a completely new smart contract that either forks the network or disrupts users and processes that depend on the protocol until they “opt-in” to the newest version. In the context of exchange, a disruptive protocol update could invalidate all open orders and require each market participant to approve a new smart contract to access their trading balances. Alternatively, the protocol could fork into two versions that operate in parallel, neutralizing network effects created by dApp interoperability. While smart contract abstraction may be used to continuously integrate updates into a protocol without disrupting higher-level processes, such an update mechanism can also create significant security risks for end users (in the worst case, an attacker could gain access to user funds). Protocol tokens may be used to drive a decentralized update mechanism that allows for continuous integration of updates into the protocol while also protecting the protocol’s users and stakeholders.
0x will be deployed to the Ethereum blockchain with a fixed supply of protocol tokens that will be issued to partnering dApps and future end users. Protocol tokens will have two uses: for market participants to pay transaction fees to Relayers and for decentralized governance over updates to the protocol. Decentralized governance will be used to securely integrate updates into 0x protocol according to the process shown in Figure 3. Initially, a simple multi-signature contract will be used for decentralized governance until a more sophisticated DAO is developed. 0x protocol and its native token will not impose unnecessary costs on users, seek rent or extract value from Relayers. The protocol’s smart contracts will be publicly accessible and completely free to use. No mechanisms will be put in place to benefit one group at the expense of another.
Figure 3: Protocol updates may be deployed without disrupting the network through a combination of contract abstraction and decentralized governance. End users provide a Proxy contract with access to the tokens they plan on trading. Stakeholders propose and elect protocol improvements that are implemented within entirely new smart contracts (DEX v2) via a DAO. The DAO authorizes new smart contract(s) to access user tokens by adding them to the Proxy contract’s whitelist and eventually unlists deprecated versions of the protocol.
Token Registry
Orders consist of hexadecimal bytecode that is machine-readable but that isn’t necessarily easy for a human to visually interpret. A Token Registry contract will be used to store a list of ERC20 tokens with associated metadata for each token: name, symbol, contract address, and the number of decimal places needed to represent a token’s smallest unit (needed to determine exchange rates). The registry will serve as an official on-chain reference that may be used by market participants to independently verify token addresses and exchange rates before executing a trade. Since the Token Registry will serve as trusted source of information, oversight will be required to add, modify or remove tokens from the registry. 0x stakeholders will provide this oversight. While the Token Registry will make it easy for users to verify the integrity of their orders, 0x protocol can be used to trade any token that uses the ERC20 token interface.
In the future, the protocol’s order format can be modified to facilitate human-readability. Tokens may be identified by a three character symbol registered in the Token Registry rather than by the token’s contract address. The Ethereum Name Service (ENS) can be used to identify Makers, Takers and Relayers by human-readable names, such as “theDunkle.eth”, rather than by an account or contract address.
- Off-chain order relay + on-chain settlement = low friction costs for market makers + fast settlement.
- Publicly accessible smart contracts that any dApp can hook into.
- Relayers can create their own liquidity pools and charge transaction fees on volume.
- Standardization + decoupling = Shared protocol layer
-provides interoperability between dApps
-creates network effects around liquidity that are mutually beneficial
-reduces barriers-to-entry, driving down costs for market participants
-eliminates redundancy, improves user experience and smart contract security
- Decentralized update mechanism allows improvements to be continuously and safely integrated into the protocol without disrupting dApps or end users.
A New Contract Architecture with Support For ERC-721 and Other Token Standards
V1 of 0x used primarily two smart contracts; our Exchange contract handled the logic of filling or cancelling trades, while our Proxy contract interfaced with ERC-20 contracts to modify token balances when trades were executed. This works well, but doesn’t scale as support for more types of assets is added beyond ERC-20 — we would need to constantly re-deploy the Proxy contract to support new standards, forcing everyone to set their allowance on the new Proxy contract to adjust their token balances.
In V2, instead of this single Proxy contract interfacing directly with other asset contracts to adjust balances, we deploy new Asset Proxies for each unique asset type. This way, 0x adds support for new token standards as they come out without having to redeploy a single Proxy — we just need to deploy a new AssetProxy for a particular standard.
To start, 0x is launching with support for ERC-20 as well as ERC-721, the standard for Non-Fungible Tokens. This means you can trade your Ethmoji, Fan Bits, CryptoKitties, LAND, or any other unique, collectible assets using 0x. This new, modular architecture will allow to add support for new token standards without having to modify our smart contracts and force developers and users to upgrade.
Support for EIP-712
0x’s very own Leonid Logvinov and Remco Bloemen wrote EIP-712, a standard for hashing structured data, and why we’re adding support for it in V2. You can see in the screenshot below how much more usable signing becomes with EIP-712.
Taker Abstraction
In V1 of 0x, the Taker of an order has always been msg.sender, the address that is directly calling the fillOrder function. In V2, the Taker will default to msg.sender, but can optionally be from another Ethereum address if a signature from that address is provided. This opens up a number of new use cases and makes existing uses of 0x much easier to implement such as:
- Relayers using the Order Matching model
- Creating orders that can only be filled by whitelisted addresses or that require a multisig to fill
- Building Trade Execution Coordinators to prevent front-running and griefing
Support for New Signature Types
In V1 of 0x, orders are created by signing a message using ECDSA, the standard encryption scheme for Ethereum. However, this is inherently limiting and restricts certain use cases.
In V2, we’re supporting new signature schemes like EIP-712 and Trezor, as well as allowing users to define their own verification functions within smart contracts. This allows orders to be created using multi-sig, BLS signatures, ring signatures, or any other encryption scheme and doesn’t require the 0x smart contracts to be re-deployed in the future to support these new use cases. Smart contracts can now generate 0x orders using a custom signature verification function.
Atomic Order Matching and Batch Settlement
In V1 of 0x, users could atomically batch fill transactions, but under the condition that they had upfront capital to fill the transactions in the first place. This enabled developers to build order matching relayers and arbitrage bots after passing this initial capital barrier.
In V2, orders can be atomically matched and filled together without needing capital other than ETH to cover gas costs. This greatly lowers the barrier to arbitrage trading and order matching.
Forwarding Contract
We know that ‘wrapping’ ETH into ERC-20-compliant WETH has been a big hurdle towards broader user adoption of 0x that’s not likely to go away anytime soon. We’ve been looking for solutions to make it easier for the long-tail of users to start tapping into the 0x networked liquidity pool, and we’re excited by the potential of the 0x forwarding contract and trade widget. With the forwarding contract, users can simply send ETH and the orders they want to fill, and the forwarding contract will wrap the ETH and fill the orders in one single transaction, eliminating the need for WETH for takers.
With V2, we will deploy our own version of a forwarding contract that anyone can use, with or without the 0x trade widget. It will of course be open source so that other teams can modify and deploy it as they see fit.
Team
0x has one of the most dedicated and respected teams in the community.
Will Warren — Co-founder & CEO.
Smart contract R&D. Previously applied physics at Los Alamos Nat Lab. Mechanical engineering at UC San Diego. PhD dropout.
Amir Bandeali — Co-founder & CTO.
Smart contract R&D. Previously fixed income trader at DRW. Finance at University of Illinois, Urbana-Champaign.
Fabio Berger — Senior Engineer.
Full-stack blockchain engineer. Previously software engineer at Airtable and founder of WealthLift. Computer Science at Duke.
Alex Xu — Director Of Operations.
Strategy and operations. Previously digital marketing at Google and vendor management at Amazon. Economics at UC San Diego.
Leonid Logvinov — Engineer.
Full-stack blockchain engineer. Previously blockchain engineer at Neufund. Computer Science at University of Warsaw.
Ben Burns — Designer.
Product, motion, and graphic designer. Previously designer at Airtable and Apple. Digital Design at University of Cincinnati.
Brandon Millman — Senior Engineer.
Full-stack engineer. Previously senior software engineer at Twitter. Computer Science and Electrical Engineering at Duke.
Tom Schmidt — Product Manager.
Previously engineering at Apple, product management at Facebook and Instagram. Computer Science at Stanford.
Jacob Evans — Ecosystem Engineer.
Previously software engineer at Qantas and RSA Security.
Blake Henderson — Operations Associate.
Operations and Analytics. Previously analytics at LinkedIn. Economics at UC San Diego.
Zack Skelly — Lead Recruiter.
Talent. Previously first recruiter at Heap, recruiting at Dropbox and Google. English Rhetoric and Composition at Pepperdine.
Greg Hysen — Blockchain Engineer.
Smart contract R&D. Previously lead distributed systems engineer at Hivemapper. Computer Science at University of Waterloo.
Remco Bloemen — Technical Fellow.
Previously cofounder at Neufund and Coblue. Part III at Cambridge. PhD dropout at Twente Business School.
Francesco Agosti — Engineer.
Full-stack engineer. Previously senior software engineer at Yelp. Computer Science at Duke.
Mel Oberto — Office Ops / Executive Assistant.
Daily Operations. Previously People Operations Associate at Heap. Marketing and MBA at Sacred Heart University.
Alex Browne — Engineer In Residence.
Full-stack blockchain engineer. Previously at Plaid. Open source guru and footgun dismantler. Computer Science and Electrical Engineering at Duke.
Peter Zeitz — Research Fellow.
Researching decentralized governance. Previously Assistant Professor of Economics at National University of Singapore Business School. PhD in Economics at UCLA.
Chris Kalani — Director Of Design.
Previously founded Wake (acquired by InVision). Early Facebook product designer.
Clay Robbins — Ecosystem Development Lead.
Growth & Business Development. Previously product and partnerships at Square. Economics at Dartmouth College.
Matt Taylor — Marketing Lead.
Growth & Marketing. Previously marketing at Abra and Square. Economics and Philosophy at Claremont McKenna College.
Eugene Aumson — Engineer.
Developer Experience. Previously senior software engineer in foreign exchange applications at Bloomberg LP.
Weijie Wu — Research Fellow.
Researching decentralized governance. Previously Researcher at Huawei and Assistant Professor at Shanghai Jiao Tong University. PhD in Computer Science at The Chinese University of Hong Kong.
Rahul Singireddy — Relayer Success Manager.
Previously community at Zeppelin, growth at Dharma, and cryptocurrency contributor at Forbes. Symbolic Systems at Stanford.
Jason Somensatto — Strategic Legal Counsel.
Legal. Previously head of blockchain and crypto practice at Orrick. JD from George Washington University and undergrad at UVA.
Steve Klebanoff — Senior Engineer.
Full-stack engineer. Previously Staff Software Engineer at AppFolio. Computer Science & Cognitive Psychology at Northeastern University.
And others.
People from GitHub:
- Amir Bandeali (abandeali1) Repositories — 5. Stars — 6.
- Alex Browne (albrow) Repositories — 75. Stars — 96.
- Brandon Millman (BMillman19) Repositories — 24. Stars — 33.
- Chris Kalani (chriskalani) Repositories — 1. Stars — 0.
- Jacob Evans (dekz) Repositories — 120. Stars — 596.
- Steve Klebanoff (steveklebanoff) Repositories — 37. Stars — 245.
- Zack (zorkary) Repositories — 0. Stars — 2.
Advisors
The advisors for the project founded or work at companies such as Polychain Capital, Coinbase, and Pantera Capital.
Fred Ehrsam — Co-founder of Coinbase. Previously FX trader at Goldman Sachs.
Olaf Carlson-Wee — Founder of Polychain Capital. First hire at Coinbase. Angel investor.
Joey Krug — Co-CIO at Pantera Capital. Founder of Augur. Thiel 20 Under 20 Fellow.
Linda Xie- Co-founder of Scalar Capital. Previously PM at Coinbase.
David Sacks — General Partner at Craft Ventures. Original COO of PayPal. Founder of Yammer.
Partnerships
List of dApps that will be (or are) using the 0x protocol
- Aragon
- Auctus
- Augur
- bZx
- Blocknet
- ChronoBank
- Dharma
- District0x
- dYdX
- EasyTrade
- Gods Unchained
- Hut34 Project
- Lendroid
- Maker
- MelonPort
- OpenANX
- Paradigm Protocol
- Request Network
- Set
List of relayers that will be (or are) using the 0x protocol
- Amadeus
- Bamboo Relay
- DDEX
- Dextroid
- ERC dEX
- Ethfinex
- IDT Exchange
- Instex
- Lake Project
- LedgerDex
- MobiDex
- OpenRelay
- Paradex
- Radar Relay
- Shark Relay
- Starbit
- The Ocean
- Token Jar
- Tokenlon
- Weswap
List of 0x trade explorers
Use case
We have seen a number of reviews which listed a number of 0x’s potential use cases, but in reality they are use cases of projects-users of 0x. And since in December 2017th 0x stated in their blog that “members of the 0x core team will not take a financial stake in, formally advise, or partner with other players in the 0x ecosystem”, the only use case of 0x is protocol for decentralized exchanges.
Social metrics
There are also 0x Forum and 0x Chat.
Markets and volume
Information from Coinlib.io:
TA
From TA perspective ZRX is currently testing a year support. With RSI so oversold we doubt it will break down immediately, thus expect some consolidation and a bounce from oversold levels. Further development will depend on performance of crypto market in general.
In BTC terms chart looks quite bullish with series of one-two`s with higher lows higher highs.
Competitors
There are 3 competitors of 0x, all of these projects focus on decentralized trading. I will try to outline main differences between projects in the table below:
Table compiled from blog post and project’s whitepapers.
Loopring and Kyber network misfit this table a little since they don’t have Maker/Taker definitive position. In Loopring anyone who posts an order is made both Maker and Taker, since it is a rare occurence to have a classical order matching. In Kyber Network Taker is a Reserve provider, his reserve is matched with suitable Maker’s order.
Roadmap
Timeline
2016
- Q4
- 0x founded
- Deployed pre-alpha contracts to Ropsten testnet
2017
- Q1
- Released whitepaper
- Q2
- Hired Fabio
- Deployed alpha contracts (upgradeable) to Kovan testnet
- Launched 0x OTC on Kovan
- 1st Place, Consensus 2017 Startup Competition
- Hired Leo
- Released 0x.js v0.8.0
- Q3
- Contracts moved from alpha to beta via governance on Kovan
- Hired Alex
- Hired Ben
- Token sale announcement
- Security audits completed
- 0x v1.0.0 deployed on mainnet
- ZRX token sale
- Hired Phillipe
- Radar Relay beta launch
- 0x.js updates
- 0x Portal announcement
- Standard relayer API draft published
- Q4
- 0x hackathon
- 0x external development grant program
- Relayer legal framework
- Website redesign
- 0x Portal feature updates
- Standard relayer API v1 finalized
- 0x.js v1.0.0 released
- Protocol features and optimizations R&D
- 0x v1.x.x deployed on Kovan and Ropsten testnets
2018
- Q1
- Governance R&D
- Reusable relayer UI components
- 0x v2.0.0 deployed on mainnet
- Q2
- Trade explorer v1 released
- Governance whitepaper
This roadmap was last updated in september 2017, pretty much all of the milestones were reached (except for governance whitepaper). No new roadmap was released yet, but a month ago Will Warren wrote on reddit that we will see it before the end of the year.
So I will try to outline some milestones of last months:
June — Release of the new 0x Portal
July — 0x’s V2 tools have been published
August-September — Update of wiki articles, 0x code sandbox and the 0x starter project, 0x Portal now supports creating and filling 0x v2 orders, The second version of the Standard Relayer API was finalized, the landing page got a mini-makeover.
September — Announcement the launch of 0x protocol v2.0!, The 0x V2 Bug Bounty
October — Blog post on Blockchain Governance
November — Introduction of the 0x Launch Kit
Token Mechanics
ZRX is a governance token, so all of the mechanics should be outlined in governance white paper, it should be released before the end of the year.
Token Metrics
Circulating Supply
546 057 244 ZRX
Total Supply
1 000 000 000 ZRX
The ZRX token sale took place last week, starting at 8am PT on August 15. Just 24 hours and 10 minutes into the sale, 100% of the 500M ZRX tokens that were set aside for sale had been purchased for a total of $24 million.
Token Launch (50%)
ZRX is inherently a governance token that plays a critical role in the process of upgrading 0x protocol. We are fully committed to formulating a functional and theoretically sound governance model and we plan to dedicate significant resources to R&D; we will provide greater clarity on the subject of governance in a future post.
Retained by 0x Org (15%)
Retained ZRX tokens will be used to incentivize future team members via token compensation packages as well as to sustain the operations of the 0x core development organization beyond the first five years. These assets will be used to support development at the protocol layer.
External Development Fund (15%)
The External Development Fund will be used to make targeted capital injections into high potential projects and teams that are attempting to grow the 0x ecosystem, strategic partnerships, hackathon prizes and for community development activities. These assets will be used to support development at the application layer.
Founding Team (10%)
The founding team’s allocation of ZRX will vest over a traditional 4 year vesting schedule with a one year cliff.
Early Backers & Advisors (10%)
Backers and advisors provided capital, resources and guidance.
Summary
Team: top tier team and advisors,
Idea: future of DEXs
Development stage: mainnet
Whitepaper: well composed, but outdated, no additional papers explaining token mechanics
Roadmap: really outdated roadmap, no new one yet
0x protocol has it’s mainnet up and running for quite some time, it has attracted a formidable number of relayers and projects to its ecosystem and with continuous development, with additions of new features, ecosystem can grow even more.
0x has a number of competitors which are quite close in both ideas and executions, but for now, on a bearish market, none of them can reach same position, network effect is on 0x’s side, and considering continuity of bear run it is safe to say that things will stay that way. Also since relayers are developing rapidly and try to increase their market share, this allows 0x to grow alongside with them. Popularity of relayers and projects using 0x attract even more projects, potential relayers to this platform.
The only thing missing in this project is governance. It was mentioned since 2017 a lot of times but we are yet to see governance white paper. Devcon4 presentation and last post on medium covering gouvernance we find quite insufficient.
