0x Documentation
Search…
0x Cheat Sheet
A collection of commonly used addresses, endpoints, and values across 0x products.

0x API Endpoints

We will support Ropsten testnet until October 25, 2022 as this testnet has already been deprecated by the Ethereum Foundation. Developers should plan to migrate to Goerli by that date.

Exchange Proxy Addresses

This is the primary contract for all interactions with the protocol. It is also the allowance-target/spender/operator for any ERC20, ERC721, and ERC1155 assets being traded. For most networks the address is identical, but be aware that a small number (marked with a *) are slightly different. The ABI can be found in the protocol repo's IZeroEx.json file.
  • Ethereum (Mainnet): 0xdef1c0ded9bec7f1a1670819833240f027b25eff
  • Ethereum (Goerli): 0xdef1c0ded9bec7f1a1670819833240f027b25eff
  • Ethereum (Ropsten): 0xdef1c0ded9bec7f1a1670819833240f027b25eff
We will support Ropsten testnet until October 25, 2022 as this testnet has already been deprecated by the Ethereum Foundation. Developers should plan to migrate to Goerli by that date.
  • Polygon: 0xdef1c0ded9bec7f1a1670819833240f027b25eff
  • Polygon (Mumbai): 0x4Fb72262344034e034fCE3D9c701fD9213A55260*
  • Binance Smart Chain: 0xdef1c0ded9bec7f1a1670819833240f027b25eff
  • Optimism: 0xdef1abe32c034e558cdd535791643c58a13acc10*
  • Fantom: 0xdef189deaef76e379df891899eb5a00a94cbc250*
  • Celo: 0xdef1c0ded9bec7f1a1670819833240f027b25eff
  • Avalanche: 0xdef1c0ded9bec7f1a1670819833240f027b25eff

Ancillary Contract Addresses

These contracts are used within the 0x ecosystem but are not intended for direct interaction with users except in rare circumstances. They are less likely to remain fixed (compared to the Exchange Proxy Address). The latest addresses can be found in the protocol repo's addresses.json file. A subset of commonly used addresses can be found in Contract Addresses.

The 0x order message format

At the core of 0x is a standard order message format. The order message format describes one party's commitment to trade assets at very specific terms with another party. By defining a standard message format for orders, 0x allows anyone who adheres to the standard to use 0x for settlement and build their application using the many open-source tools designed to work with 0x orders.
A 0x order has the following fields:
Text
Description
makerAddress
The party that creates the order. The maker is also one of the two parties that will be involved in the trade if the order gets filled.
takerAddress
The party that is allowed to fill the order. If set to a specific party, the order cannot be filled by anyone else. If left unspecified, anyone can fill the order.
makerAssetData
Contains all the identifying information about the asset(s) the order maker is trying to sell.
takerAssetData
Identifying information of the asset(s) the taker must trade in exchange for the maker's asset(s).
makerAssetAmount
Amount of the maker's asset(s) being offered by the maker.
takerAssetAmount
Amount of the taker's asset(s) the maker will accept in exchange for their maker asset(s). In order to calculate the price the maker is offering, one can divide the makerAssetAmount by the takerAssetAmount (the calculation is a bit more complex if multiple assets are involved).
expirationTimeSeconds
Timestamp in seconds of when the order expires. Expired orders cannot be filled.
salt
A value that can be used to guarantee order uniqueness. Typically it is set to a random number.
feeRecipientAddress
The entity that will receive any fees stipulated by the order. This is typically used to incentivize off-chain order relay.
makerFeeAssetData
Identifying token information of the asset(s) the maker must pay to the feeRecipientAddress.
takerFeeAssetData
Identifying token information of the asset(s) the taker must pay to the feeRecipientAddress.
makerFee
The fee to be paid by the order maker to the feeRecipientAddress in the event of an order fill. Partial fills result in partial fees.
takerFee
The fee to be paid by the taker to the feeRecipientAddress in the event of an order fill.
senderAddress
An advanced field that doesn't need to be set. It allows the maker to enforce that the order flow through some additional logic before it can be filled (e.g., a KYC whitelist) -- more on the ability to extend 0x later.