0x V2 Timeline Update

⌨️ Technical Development Core Protocol
1

Hi all —

We hope you’re as excited as we are about the fast-approaching launch of 0x V2! We want to make sure that you’re fully prepared for the migration and are able to take advantage of many of the new features launching with V2. Below is a projected timeline of the V2 launch as well as checklist you can follow to make sure you’re prepared for the migration.

Please let us know if you need further guidance or have more questions. We are eager to assist our relayers in providing a smooth transition to V2.

Est. Sept 3rd: Estimated mainnet launch of 0x V2

  • We recommend doing a test integration with our Kovan deployment or ganache snapshot. 0x.js has been updated to V2 for easier migration.
  • Clear your orderbook of V1 orders.
  • Contact your market makers to make sure they cancel V1 orders and repopulate orderbooks for V2
  • Upgrade your SRA implementation to V2 (http://sra-api.s3-website-us-east-1.amazonaws.com/)
  • Migrate to 0x V2 Exchange and Proxy contracts. Addresses will be published on Medium, our wiki, and our Dev email list. 0x.js will also be updated to have the contract addresses loaded into the mainnet config.
  • Users will need to re-set allowances on the new ERC-20 Asset Proxy and (if applicable) ERC-721 Asset Proxy

Est. Sept 10th: 0x Portal only features 0x V2 relayers

  • Update your entry in the Relayer Registry to remain added in Portal

Early October: 0x Trade Widget launches

  • Only works with Standard Relayer API V2
  • Accepts any Standard Relayer API V2 endpoint to source liquidity or host may pass in specific orders
  • Launching with support for Web
  • Working on integrations with a few popular mobile wallets and account explorers

Around December: 0x V1 Pipeline is turned off by 0x Multisig

  • All V1 orders no longer fillable

Additional Resources

0x V2 Upgrade Guide: 0x V2 Upgrade Guide

0x Standard Relayer API V2: https://github.com/0xProject/standard-relayer-api

0x.js V2: https://0xproject.com/docs/0x.js

0x V2 Starter Project: https://github.com/dekz/0x-v2-beta-starter

2

I posted this sometime ago on Rocket.Chat and Polezo recently echoed the question. I would like to hear your thoughts on it;

If a new exchance contract contains a vulnerability and needs to be removed from the authorizedAddresses list, doesn’t it make more sense to keep the most recent old exchange contract? Otherwise all the relayers are stuck with no exchange contracts for X days. “i.e. v1 should not be deprecated until v3 is on main net, v2 not deprecated until v4, etc.”

3 Likes