crowetic/protocol
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Replace all links to wiki with links to guides section

Browse Source
This commit is contained in:
fabioberger
2019-08-27 17:25:58 +02:00
parent 62936e3502
commit 4b7a2e9d49
30 changed files with 312 additions and 201 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
packages/connect/README.md
View File

@@ -19,7 +19,7 @@ If your project is in [TypeScript](https://www.typescriptlang.org/), add the fol
## Usage
- [Docs](https://0xproject.com/docs/connect)
- [Tutorials](https://0xproject.com/wiki#connect)
- [Tutorials](https://0x.org/docs/guides/using-the-standard-relayer-api)
## Contributing

2
packages/ethereum-types/src/index.ts
View File

@@ -4,7 +4,7 @@ export type JSONRPCErrorCallback = (err: Error | null, result?: JSONRPCResponseP
/**
* Do not create your own provider. Use an existing provider from a Web3 or ProviderEngine library
* Read more about Providers in the 0x wiki.
* Read more about Providers in the guides section of the 0x docs.
*/
export type SupportedProvider = Web3JsProvider | GanacheProvider | EIP1193Provider | ZeroExProvider;

2
packages/instant/README.md
View File

@@ -2,7 +2,7 @@
## Integration
Looking to integrate 0x Instant into your web application or site? Check out the dedicated [instant documentation](https://0xproject.com/wiki#Get-Started-With-Instant) to get started. The documentation covers instant and related topics in depth. For a more "drag and drop" experience, check out our [configurator tool](https://0xproject.com/instant#configure). For on demand developer support, join our [Discord](https://discordapp.com/invite/d3FTX3M).
Looking to integrate 0x Instant into your web application or site? Check out the dedicated [instant documentation](https://0x.org/docs/guides/integrate-instant#ui-integration) to get started. The documentation covers instant and related topics in depth. For a more "drag and drop" experience, check out our [configurator tool](https://0xproject.com/instant#configure). For on demand developer support, join our [Discord](https://discordapp.com/invite/d3FTX3M).
Check out a live sample integration [here](https://www.rexrelay.com/instant).

2
packages/subproviders/README.md
View File

@@ -2,7 +2,7 @@
A few useful web3 subproviders including a LedgerSubprovider useful for adding Ledger Nano S support.
We have written up a [Wiki](https://0xproject.com/wiki#Web3-Provider-Examples) article detailing some use cases of this subprovider package.
We have written up a [guide](https://0x.org/docs/guides/web3-provider-explained#web3-provider-examples) article detailing some use cases of this subprovider package.
### Read the [Documentation](https://0xproject.com/docs/subproviders).

60
packages/website/less/all.less
View File

@@ -67,63 +67,3 @@ code {
font-family: 'Roboto Mono';
//background-color: #f2f6ff !important; // lightBlue
}
#wiki {
p {
color: #515151; // grey750
fontsize: 15;
}
a {
color: #1d5cde; // linkBlue
}
p,
blockquote,
ol,
dl,
li,
table,
pre {
margin: 15px 0;
}
li {
margin: 5px 0;
}
table {
padding: 0;
border-collapse: collapse;
}
table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0;
}
table tr:nth-child(2n) {
background-color: #f8f8f8;
}
table tr th {
font-weight: bold;
border: 1px solid #cccccc;
text-align: left;
margin: 0;
padding: 6px 13px;
}
table tr td {
border: 1px solid #cccccc;
text-align: left;
margin: 0;
padding: 6px 13px;
}
table tr th :first-child,
table tr td :first-child {
margin-top: 0;
}
table tr th :last-child,
table tr td :last-child {
margin-bottom: 0;
}
}

6
packages/website/mdx/core-concepts/index.mdx
View File

@@ -36,7 +36,7 @@ A 0x order has the following fields:
| 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](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#multiassetproxy) if multiple assets are involved). |
| 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](https://0x.org/docs/guides/v2-specification#assetproxy) 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 guarentee 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. |
@@ -127,13 +127,13 @@ In addition to an API standard, the 0x core team is also building [0x Mesh](htt
## Extending the 0x protocol
By design, the 0x protocol is built to be highly modular and extensible. Some changes to the protocol require approval from the ZRX token holders, such as the addition of an [assetProxy](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetproxy) (e.g., to support trading of a new token standard). Proposals for these types of changes are discussed in [ZEIPs](https://github.com/0xProject/zeips/issues) (0x improvement proposals).
By design, the 0x protocol is built to be highly modular and extensible. Some changes to the protocol require approval from the ZRX token holders, such as the addition of an [assetProxy](https://0x.org/guide/v2-specification#assetproxy) (e.g., to support trading of a new token standard). Proposals for these types of changes are discussed in [ZEIPs](https://github.com/0xProject/zeips/issues) (0x improvement proposals).
Another type of the 0x protocol extension that does not require any kind of approval to be used are aptly called [0x extensions](https://0x.org/extensions). 0x extensions add arbitrary logic that 0x orders must flow through before they can get filled or cancelled.
![Extension](/images/docs/extension.png "Extension")
Examples of the types of features this enables are trading whitelists (KYC, invite-only, etc...), Dutch auctions and [trade coordinators](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/coordinator-specification.md) to name a few. We are just beginning to see the innovation this ability to permissionlessly extend the 0x protocol will unleash.
Examples of the types of features this enables are trading whitelists (KYC, invite-only, etc...), Dutch auctions and [trade coordinators](https://0x.org/docs/guides/v2-coordinatior-specification) to name a few. We are just beginning to see the innovation this ability to permissionlessly extend the 0x protocol will unleash.
## Up next

20
packages/website/mdx/guides/0x-extensions-explained.mdx
View File

@@ -1,10 +1,10 @@
<img width="699" src="https://user-images.githubusercontent.com/27389/53459978-87dc7700-3a09-11e9-9b5c-cbff329a74c3.png">
<img width="699" src="https://user-images.githubusercontent.com/27389/53459978-87dc7700-3a09-11e9-9b5c-cbff329a74c3.png" />
We designed the 0x protocol to be extensible exchange infrastructure for the entire crypto economy. 0x's functionality can be extended through extension contracts, which broaden how 0x orders can be filled. There are a variety ways to build extension contracts. An Extension contract can perform work on the users behalf. They can validate that users belong to a specific group. Extension contracts can even be written to join multiple Decentralised Finance projects together.
0x allows for contracts to perform 0x operations, though before version 2 of the protocol there was no way to enforce that an order executed via a specific contract. The 0x order format now contains a field `senderAddress`. When this is defaulted to empty it is completely open for any anyone to fill. The Forwarder uses open orders with an unspecified sender address to perform a fill on behalf of the user. When the sender address is specified the 0x protocol ensures the operation originates from this address. For example it's possible to create a KYC (Know Your Customer) orderbook. This orderbook contains orders specifying the sender address as the KYC attestation contract. 0x protocol enforces all operations originate from the KYC contract in which all addresses have been validated by this contract.
### Forwarder Contract
## Forwarder Contract
Wrapping ETH into ERC-20 compliant wETH has been a large barrier to adoption for the greater Decentralised Finance ecosystem. The 0x core team wrote and deployed a Forwarder contract to address these issues. You have used the Forwarder Contract if you have purchased tokens through [0x Instant](https://0x.org/instant). The Forwarder is an example of an extension which performs work on the users behalf.
@@ -12,7 +12,7 @@ Users send ETH and a set of orders to the Forwarder contract and these funds are
The Forwarder extends the behavior of trading on 0x. It presents a different interface where the user can specify the amount of tokens they wish to buy and use ETH to buy them. This is an improved user experience to interacting with the lower level 0x Exchange contract. From a user's perspective it appears as if they are buying tokens using ETH directly.
<img width="575" src="https://user-images.githubusercontent.com/27389/53459986-8dd25800-3a09-11e9-87ce-14eff3464b28.png">
<img width="575" src="https://user-images.githubusercontent.com/27389/53459986-8dd25800-3a09-11e9-87ce-14eff3464b28.png" />
Projects can use the Forwarder contract and a Relayers orders in their own integrations. We've seen great adoption of 0x Instant, which uses the Forwarder under the hood. These projects are able to use the affiliate fee in the Forwarder to collect fees in ETH for the trades they originate.
@@ -37,23 +37,23 @@ The 0x Core team have deployed the Forwarder contract on all networks, though th
- [0x Starter Project](https://github.com/0xProject/0x-starter-project/blob/master/src/scenarios/forwarder_buy_erc20_tokens.ts#L19)
- [Forwarder Source Code](https://github.com/0xProject/0x-monorepo/blob/development/contracts/exchange-forwarder/contracts/src/MixinForwarderCore.sol)
### Dutch Auction Contract
## Dutch Auction Contract
The price of an asset decreases over time and the buyer submits a matching order when they believe the asset is appropriately priced. The Dutch Auction contract guarantees the asset is exchanged for the current price, given the block time. The Dutch Auction contract is an example of an extension which validates some state before matching two orders.
The Dutch Auction contract is powered by the 0x Exchange contracts [matchOrders function](https://0x.org/docs/contracts#Exchange-matchOrders) and extends the order format to include additional data. When using match orders, two orders are passed in as parameters, known as the sell order and the buy order. The seller of the asset creates an order for the asset at the lowest price. When a buyer decides the asset is at an acceptable price, they create a matching order for that amount. The buyer submits both the sell order and the buy order to the Dutch Auction contract.
<img width="825" src="https://user-images.githubusercontent.com/27389/53460197-4a2c1e00-3a0a-11e9-9cbe-1a143d31cd01.png">
<img width="825" src="https://user-images.githubusercontent.com/27389/53460197-4a2c1e00-3a0a-11e9-9cbe-1a143d31cd01.png" />
Within the Dutch Auction contract the current price of the asset is calculated given the starting price, the current block time and the expiration time of the order. The contract calculates the correct price and only permits the match to execute if the buy order contains a sufficient amount. Using match orders the caller of `matchOrders` receives any spread or excess in the exchange. In this case the Dutch Auction contract receives the spread and returns it to the seller.
As you may have noticed, the 0x order format does not contain any space for additional parameters. The setup for the Dutch Auction contract encodes additional data in the maker asset data that is compatible with the Asset Proxy. In the case of ERC-20, the asset data is ABI encoded as `ERC20Token(address)`.
<img width="629" src="https://user-images.githubusercontent.com/27389/53460021-a17dbe80-3a09-11e9-80e7-061559ed550b.png">
<img width="629" src="https://user-images.githubusercontent.com/27389/53460021-a17dbe80-3a09-11e9-80e7-061559ed550b.png" />
The Dutch Auction encodes additional parameters into the maker asset data, parameters such as starting amount and time the auction begins. These are extracted in the Dutch Auction contract and validated before calling `matchOrders`.
<img width="624" src="https://user-images.githubusercontent.com/27389/53460005-99be1a00-3a09-11e9-8f6b-d446672887f7.png">
<img width="624" src="https://user-images.githubusercontent.com/27389/53460005-99be1a00-3a09-11e9-8f6b-d446672887f7.png" />
Encoding of the additional parameters is provided on the [Dutch Auction contract wrapper](https://0x.org/docs/contract-wrappers#DutchAuctionWrapper-encodeDutchAuctionAssetData).
@@ -83,11 +83,11 @@ Note: In the case of calling `matchOrders` the `takerAddress` can be specified i
- [0x Starter Project](https://github.com/0xProject/0x-starter-project/blob/master/src/scenarios/dutch_auction.ts#L20)
- [Dutch Auction Source Code](https://github.com/0xProject/0x-monorepo/blob/development/contracts/extensions/contracts/src/DutchAuction/DutchAuction.sol#L29)
### Whitelist Contract
## Whitelist Contract
Interacting with a [Whitelist Contract](https://github.com/0xProject/0x-monorepo/blob/69025da2dcb4bded72cbf724c598ee09682d2dfc/contracts/exchange/contracts/examples/Whitelist.sol) is one way to ensure [compliant peer-to-peer trading on 0x](https://blog.0xproject.com/compliant-peer-to-peer-trading-4dab8e5c3162). Relayers intending to offer security tokens or other regulated assets can utilize a whitelist contract to automatically filter through a set of pre-approved Ethereum addresses. The Whitelist contract is an example of an extension which uses the execute transaction functionality of 0x.
<img width="689" src="https://user-images.githubusercontent.com/27389/53459994-92970c00-3a09-11e9-8c77-a02267033cc4.png">
<img width="689" src="https://user-images.githubusercontent.com/27389/53459994-92970c00-3a09-11e9-8c77-a02267033cc4.png" />
This type of extension makes use of the [0x Execute Transaction functionality](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#executing-a-transaction). When using execute transaction, the user signs their intent, and this is forwarded on to the 0x protocol via the extension contract. This applies to all operations available on 0x such as fill and cancel. This operation can be submitted by any third party, such as the Relayer itself. When a Relayer submits the operation on behalf of the user, they pay the gas.
@@ -125,7 +125,7 @@ The Whitelist template is a simple example of validating addresses before allowi
- [Whitelist Source Code](https://github.com/0xProject/0x-monorepo/blob/69025da2dcb4bded72cbf724c598ee09682d2dfc/contracts/exchange/contracts/examples/Whitelist.sol#L27)
- [BalanceThresholdFilter Source Code](https://github.com/0xProject/0x-monorepo/blob/development/contracts/extensions/contracts/src/BalanceThresholdFilter/MixinBalanceThresholdFilterCore.sol#L34)
### Differences to an Asset Proxy
## Differences to an Asset Proxy
While both an Extension contract and an Asset Proxy change the behavior of exchange on the 0x protocol, they are quite different. Extension contracts cannot change the behavior of settlement. For example, it is not possible to add new token standards with an extension contract.

12
packages/website/mdx/guides/contract-fillable-liquidity.mdx
View File

@@ -16,14 +16,14 @@ There are two key concepts that will be good to understand in order to make best
## 0x order
The 0x order is a message with a [specific structure](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#order-message-format). Conceptually, you can think of a 0x order as a promise from one user (the maker) to swap their token (the makerAsset) with another token (the takerAsset) at a specified rate. These orders can be fulfilled by interacting with the [0x exchange contract](https://etherscan.io/address/0x4f833a24e1f95d70f028921e27040ca56e09ab0b).
The 0x order is a message with a [specific structure](https://0x.org/docs/guides/v2-specification#orders). Conceptually, you can think of a 0x order as a promise from one user (the maker) to swap their token (the makerAsset) with another token (the takerAsset) at a specified rate. These orders can be fulfilled by interacting with the [0x exchange contract](https://etherscan.io/address/0x4f833a24e1f95d70f028921e27040ca56e09ab0b).
## 0x exchange contract
The 0x exchange contract is a smart contract deployed on the [Ethereum mainnet](https://etherscan.io/address/0x4f833a24e1f95d70f028921e27040ca56e09ab0b) and most [testnets](https://0x.org/wiki#Deployed-Addresses). Users send transactions to this smart contract in order to fulfill 0x orders. There are many options for filling orders using the contract, they are listed [here](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#filling-orders).
The 0x exchange contract is a smart contract deployed on the [Ethereum mainnet](https://etherscan.io/address/0x4f833a24e1f95d70f028921e27040ca56e09ab0b) and most [testnets](https://0x.org/docs/guides/0x-cheat-sheet#deployed-contract-addresses). Users send transactions to this smart contract in order to fulfill 0x orders. There are many options for filling orders using the contract, they are listed [here](https://0x.org/docs/guides/v2-specification#fillorder).
## 0x extension contracts
The 0x exchange contract is designed to be easily extendible through varying smart contracts that are referred to as extension contracts. Users can send their orders to an extension contract and expect augmented behavior that is not provided by the core 0x exchange contract. While any developer can develop and leverage extension contracts, the 0x core team has built, audited, and deployed a number of open source extension contracts. Learn more about them [here](https://0x.org/wiki#0x-Extensions).
The 0x exchange contract is designed to be easily extendible through varying smart contracts that are referred to as extension contracts. Users can send their orders to an extension contract and expect augmented behavior that is not provided by the core 0x exchange contract. While any developer can develop and leverage extension contracts, the 0x core team has built, audited, and deployed a number of open source extension contracts. Learn more about them [here](https://0x.org/docs/guides/0x-extensions-explained).
---
@@ -131,7 +131,7 @@ contract MyContract {
*Note:* Contract fillable liquidity integrations will be filling 0x orders “on behalf” of the user. Smart contract’s integrating 0x CFL would need to set an allowance for 0x exchange contracts before hand in the constructor or through an admin operated function.
There are many different ways to fill orders; developers in the 0x ecosystem have built a number of ways to interact with 0x protocol on-chain. For a complete list of options for filling 0x orders, check out the [0x protocol specification](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#filling-orders). A non-exhaustive list of great 0x integrations can be found here:
There are many different ways to fill orders; developers in the 0x ecosystem have built a number of ways to interact with 0x protocol on-chain. For a complete list of options for filling 0x orders, check out the [0x protocol specification](https://0x.org/docs/guides/v2-specification#fillorder). A non-exhaustive list of great 0x integrations can be found here:
* dYdX's exchange wrappers repo: https://github.com/dydxprotocol/exchange-wrappers
* Set protocol’s exchange wrappers repo: https://github.com/SetProtocol/set-protocol-contracts/tree/master/contracts/core/exchange-wrappers
@@ -188,9 +188,9 @@ The two main 0x smart contract interfaces are:
* *Exchange*: The main 0x exchange protocol smart contract interface
* Specifically asset-swapper interacts with `marketBuyNoThrow` and `marketSellNoThrow` functions
* *Forwarder*: An extension contract that abstracts wrapping ether and a number of other computations; only supports WETH/ERCXX pairs. Read more about forwarder [here](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/forwarder-specification.md)
* *Forwarder*: An extension contract that abstracts wrapping ether and a number of other computations; only supports WETH/ERCXX pairs. Read more about forwarder [here](https://0x.org/docs/guides/v2-forwarder-specification)
* Specifically asset-swapper interacts with `marketBuyWithEth` and `marketSellWithEth` functions
* (Future) *Coordinator*: An extension contract that enables the filling of coordinator orders; read more about coordinator 0x orders [here](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/coordinator-specification.md).
* (Future) *Coordinator*: An extension contract that enables the filling of coordinator orders; read more about coordinator 0x orders [here](https://0x.org/docs/guides/v2-coordinatior-specification).
SwapQuoteConsumer has a router logic that, dependent on the takerAddress and asset trading pair, determine the best 0x interface to provide output for.

186
packages/website/mdx/guides/integrate-instant.mdx
View File

@@ -12,7 +12,7 @@ Check out a live example on [mainnet](http://0x-instant-staging.s3-website-us-ea
## Orders
Additionally, 0x Instant requires a source of SignedOrders that users can fill. Most teams will opt to provide a [Standard Relayer API HTTP endpoint](https://0x.org/wiki#Questions-About-Instant), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](https://0x.org/wiki#Questions-About-Instant) for users to fill.
Additionally, 0x Instant requires a source of SignedOrders that users can fill. Most teams will opt to provide a [Standard Relayer API HTTP endpoint](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs) for users to fill.
## Affiliate Fees
@@ -61,12 +61,12 @@ Codepen [example](https://codepen.io/bmillman19/pen/qQzQQK)
| Option | Description |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| provider | An instance of an Ethereum [provider](https://0x.org/wiki#Questions-About-Instant). If none is provided, 0x instant will try to grab the injected provider if one exists, otherwise it will suggest the user to install MetaMask |
| provider | An instance of an Ethereum [provider](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs). If none is provided, 0x instant will try to grab the injected provider if one exists, otherwise it will suggest the user to install MetaMask |
| walletDisplayName | A display string for the wallet you are connected to. Defaults to our best guess (i.e. MetaMask, Coinbase Wallet) but should be provided if a custom provider is supplied as an optional config. |
| availableAssetDatas | An array of [assetDatas](https://0x.org/wiki#Questions-About-Instant) that can be purchased through Instant. Defaults to all token pairs from orderSource. Will throw an error if empty. |
| availableAssetDatas | An array of [assetDatas](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs) that can be purchased through Instant. Defaults to all token pairs from orderSource. Will throw an error if empty. |
| defaultSelectedAssetData | The asset that should be opened by default. If this is not provided, Instant will show "Select Token" if there are multiple availableAssetDatas. |
| defaultAssetBuyAmount | Pre-fill the amount of tokens to purchase. Defaults to 0. |
| additionalAssetMetaDataMap | An object with keys that are assetData strings and values that are objects that adhere to the [AssetMetaData schema](https://0x.org/wiki#Questions-About-Instant). The values represent the meta data for that asset. There is an internal mapping for popular tokens that cannot be overriden and only appended to using this configuration option. |
| additionalAssetMetaDataMap | An object with keys that are assetData strings and values that are objects that adhere to the [AssetMetaData schema](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs). The values represent the meta data for that asset. There is an internal mapping for popular tokens that cannot be overriden and only appended to using this configuration option. |
| networkId | Id of Ethereum network to connect to. Defaults to 1 (mainnet). |
| affiliateInfo | An object specifying what % ETH fee should be added to orders and where the fee should be sent. Max feePercentage is .05 (See examples below) |
| shouldDisableAnalyticsTracking | An option to turn on / off analytics used to make Instant a better experience. Defaults to false. |
@@ -161,7 +161,7 @@ zeroExInstant.render(
## Providing a Custom Token
Your token may not be currently supported by Instant by default. Check [here](https://github.com/0xProject/0x-monorepo/blob/development/packages/instant/src/data/asset_meta_data_map.ts) for a list of tokens supported by default. Check "What is assetMetaData?" in [the questions section](https://0x.org/wiki#Questions-About-Instant) for more information about the object being passed in. For the `orderSource` parameter you will likely need to pass in an array of [`SignedOrder`](https://0x.org/docs/order-utils#types-SignedOrder)s, unless you are running your own relayer, or know of a relayer that has liquidity for your custom token.
Your token may not be currently supported by Instant by default. Check [here](https://github.com/0xProject/0x-monorepo/blob/development/packages/instant/src/data/asset_meta_data_map.ts) for a list of tokens supported by default. Check "What is assetMetaData?" in [the questions section](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs) for more information about the object being passed in. For the `orderSource` parameter you will likely need to pass in an array of [`SignedOrder`](https://0x.org/docs/order-utils#types-SignedOrder)s, unless you are running your own relayer, or know of a relayer that has liquidity for your custom token.
```javascript
const erc20TokenAddress = '0xe41d2489571d322189246dafa5ebde1f4699f498';
@@ -188,7 +188,7 @@ zeroExInstant.render(
## Providing a NFT / ERC721
Instant does not come bundled with any NFT data, so you must provide the `additionalAssetMetaDataMap` parameter to make the integration work (Check "What is assetMetaData?" in [the questions section](https://0x.org/wiki#Questions-About-Instant) for more information about the object being passed in.) You must also provide the `defaultSelectedAssetData` parameter to open instant with the NFT you are selling. For the `orderSource` parameter you will likely need to pass in an array of [`SignedOrder`](https://0x.org/docs/order-utils#types-SignedOrder)s, unless you are running your own relayer, or know of a relayer that has liquidity for your custom token.
Instant does not come bundled with any NFT data, so you must provide the `additionalAssetMetaDataMap` parameter to make the integration work (Check "What is assetMetaData?" in [the questions section](#faqs), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#faqs) for more information about the object being passed in.) You must also provide the `defaultSelectedAssetData` parameter to open instant with the NFT you are selling. For the `orderSource` parameter you will likely need to pass in an array of [`SignedOrder`](https://0x.org/docs/order-utils#types-SignedOrder)s, unless you are running your own relayer, or know of a relayer that has liquidity for your custom token.
```javascript
const erc721TokenAddress = '0xf5b0a3efb8e8e4c201e2a935f110eaaf3ffecb8d';
@@ -220,7 +220,7 @@ Behind the scenes, the `AssetBuyer` class is aggregating liquidity and calculati
/**
* Get a `BuyQuote` containing all information relevant to fulfilling a buy given a desired assetData.
* You can then pass the `BuyQuote` to `executeBuyQuoteAsync` to execute the buy.
* @param assetData The assetData of the desired asset to buy (for more info: https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md).
* @param assetData The assetData of the desired asset to buy (for more info: https://0x.org/docs/guides/v2-specification).
* @param assetBuyAmount The amount of asset to buy (in wei).
* @param options Options for the request. See type definition for more information.
*
@@ -286,7 +286,7 @@ export interface BuyQuoteExecutionOpts {
```javascript
/**
* assetData: String that represents a specific asset (for more info: https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md).
* assetData: String that represents a specific asset (for more info: https://0x.org/docs/guides/v2-specification).
* assetBuyAmount: The amount of asset to buy (in wei).
* orders: An array of objects conforming to SignedOrder. These orders can be used to cover the requested assetBuyAmount plus slippage.
* feeOrders: An array of objects conforming to SignedOrder. These orders can be used to cover the fees for the orders param above.
@@ -333,3 +333,173 @@ const txHash = await assetBuyer.executeBuyQuoteAsync(quote);
```
As mentioned, you can also use the quote providing and fee abstraction functionality in `AssetBuyer` using your own liquidity. The interface is the same, except the factory method which no longer accepts a standard relayer API url but in memory orders.
# Learn about affiliate fees
As an end host of 0x Instant, you can charge users a fee on all trades made through Instant with the `affiliateFee` option. Simply specify an ethereum address and feePercentage (up to 5%), and a percentage of each transaction will be deposited into the specified address (denominated in ETH).
Example: 3% of transaction volume (in ETH) will de deposited into 0x50ff5828a216170cf224389f1c5b0301a5d0a230
```html
<head>
...
<script src="https://instant.0x.org/instant.js"></script>
...
</head>
```
```javascript
zeroExInstant.render(
{
orderSource: 'https://api.radarrelay.com/0x/v2/',
affiliateInfo: {
feeRecipient: '0x50ff5828a216170cf224389f1c5b0301a5d0a230',
feePercentage: 0.03,
},
},
'body',
);
```
# FAQs
## General
### Q: What is a SignedOrder?
A SignedOrder is a basic primitive of the 0x protocol. You can think of the SignedOrder as a set of parameters that define the terms of a trade, plus a signature that proves that the creator (also known as the 'maker') of an order has approved the trade. For example, a SignedOrder can specify: address A wants to trade 5 REP tokens in exchange for 1 WETH token. The order also includes signature produced by address A's private key and a hash of the order parameters. For exact JavaScript / TypeScript definition of a SignedOrder, refer to our [docs](https://0x.org/docs/0x.js#types-SignedOrder).
### Q: What is the Standard Relayer API?
The Standard relayer API is an HTTP specification that facilitates discovering and publishing SignedOrders. As an integrator of 0x Instant you will want to grab an API url from the [Relayer Registry](https://github.com/0xProject/0x-relayer-registry/blob/master/relayers.json). Check out the exact specification of the API in the [documentation](http://sra-spec.s3-website-us-east-1.amazonaws.com/).
### Q: What is a provider?
Check out this [article](https://0x.org/docs/guides/web3-provider-explained) in the guides section for an explanation of web3 providers. A dApp developer typically grabs this object from window.ethereum or window.web3.currentProvider. For advanced usage of providers check out this [article](docs/guides/web3-provider-explained) for some examples of how to create your own providers
### Q: How can I check liquidity of an asset prior to rendering Instant?
There is a helper method available at `zeroExInstant.hasLiquidityForAssetDataAsync` which takes in an assetData string and order source (Standard Relayer API url or an array of signed orders) and returns a Promise which resolves a boolean value indicating if there is an liquidity available for a given assetData.
See below for an example of how to check liquidity on Radar Relay for a given ERC20 token address:
```
<div id="liquidityContainer">Loading...</div>
<script>
const erc20TokenAddress = '0xd26114cd6EE289AccF82350c8d8487fedB8A0C07';
const assetData = zeroExInstant.assetDataForERC20TokenAddress(erc20TokenAddress);
zeroExInstant.hasLiquidityForAssetDataAsync(assetData, 'https://api.radarrelay.com/0x/v2/').then(l => {
document.getElementById('liquidityContainer').innerHTML = `Relayer has liquidity: ${l ? 'Yes' : 'No'}`;
});
</script>
```
Codepen [example](https://codepen.io/steveklebanoff/pen/dwExJz)
### Q: What is assetData?
As we now support multiple [token transfer proxies](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetproxy), the identifier of which proxy to use for the token transfer must be encoded, along with the token information. Each proxy in 0x v2 has a unique identifier. If you're using 0x.js there will be helper methods for this [encoding](https://0x.org/docs/0x.js#assetDataUtils-encodeERC20AssetData) and [decoding](https://0x.org/docs/0x.js#assetDataUtils-decodeAssetProxyId).
The identifier for the Proxy uses a similar scheme to [ABI function selectors](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#function-selector).
```
// ERC20 Proxy ID 0xf47261b0
bytes4(keccak256("ERC20Token(address)"))
// ERC721 Proxy ID 0x02571792
bytes4(keccak256("ERC721Token(address,uint256)"))
```
Asset data is encoded using [ABI encoding](https://solidity.readthedocs.io/en/develop/abi-spec.html).
For example, encoding the ERC20 token contract (address: 0x1dc4c1cefef38a777b15aa20260a54e584b16c48) using the ERC20 Transfer Proxy (id: 0xf47261b0) would be:
```
0xf47261b00000000000000000000000001dc4c1cefef38a777b15aa20260a54e584b16c48
```
Encoding the ERC721 token contract (address: `0x371b13d97f4bf77d724e78c16b7dc74099f40e84`), token id (id: `99`, which hex encoded is `0x63`) and the ERC721 Transfer Proxy (id: `0x02571792`) would be:
```
0x02571792000000000000000000000000371b13d97f4bf77d724e78c16b7dc74099f40e840000000000000000000000000000000000000000000000000000000000000063
```
For convenience, zeroExInstant exposes a `zeroExInstant.assetDataForERC20TokenAddress` method, which returns the `assetData` for a given ERC20 address.
For more information see [the Asset Proxy](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#erc20proxy) section of the v2 spec and the [Ethereum ABI Spec](https://solidity.readthedocs.io/en/develop/abi-spec.html).
### Q: What is assetMetaData?
In order to provide a good user experience, Instant requires data that is not available on-chain. This includes the `decimals`, `symbol` and `name` of the token along with optional information like `primaryColor`, and `iconUrl` that informs Instant how to theme itself when that token is selected. It also requires to know whether the token is ERC20 or some other standard via the assetProxyId field.
The keys in this mapping are the `assetData` (see "What is assetData?" above) for the corresponding token.
**Example assetMetaDataMap**
```js
{
'0xf47261b0000000000000000000000000744d70fdbe2bc4cf95131626614a1764df805b9e': {
assetProxyId: '0xf47261b0', // ERC20 Proxy Id
decimals: 18,
symbol: 'XXX',
name: 'My Custom Token',
primaryColor: '#F2F7FF', // Optional
iconUrl: 'https://cdn.icons.com/my_icon.svg', // Optional
},
}
```
| Field | Description |
| ----------------------- | ------------------------------------------------------------------------------------ |
| assetProxyId | Only ERC20 is supported and the value for assetProxyId should always be “0xf47261b0” |
| decimals | The number of decimal places this token requires |
| symbol | The token symbol (ex: `ZRX`, `BAT`, etc...) |
| name | The full name of the token (ex: `0x`, `Basic Attention Token`, etc...) |
| primaryColor (optional) | The color Instant will theme itself when this token is selected |
| iconUrl (optional) | The url to the icon to use for this token |
The icon referenced by `iconUrl` will go on top of a 26x26 circle that has `primaryColor` as a background. If an `iconUrl` is not provided, the specified token `symbol` will be displayed over the circle in white.
We provide assetMetaData for a subset of ERC20 tokens. You can call the helper function `zeroExInstant.hasMetaDataForAssetData` which returns a boolean indiciating whether or not we have assetMetaData for a given assetData string.
### Q: Do users need to have ZRX to pay for fees on orders?
Nope! The Asset Buyer will calculate the ZRX required to pay for fees on the desired orders, and automatically purchase ZRX from your order source to cover your fees as part of the order. Note that Instant cannot use a user's existing ZRX balance and the liquidity source must be able to provide ZRX / ETH orders.
### Q: Does this work with order matching relayers (vs. open orderbook)?
No, 0x Instant currently needs globally accessible orders and is only compatible with orders from open orderbook relayers.
### Q: What happens if there's not enough liquidity to purchase an asset?
To prevent massive price ranges, 0x Instant calculates a maximum amount of assets that a user can buy under a given amount of price slippage and restricts purchasing to that amount.
### Q: Can I pay for assets through 0x Instant using an ERC-20 token like WETH or DAI?
0x Instant currently only supports purchasing ERC-20 using ETH for now, but we're looking into adding ERC-20 to ERC-20 purchasing in the future.
### Q: Does 0x Instant work with permissioned liquidity pools that require KYC?
0x Instant currently passes all orders through a forwarding contract for wrapping ETH and filling orders and is therefore incompatible with many on-chain KYC solutions. Check with the KYC solution you're using to verify.
### Q: Can Instant be used to sell tokens that are not available on a relayer?
Even if an ERC20 token is not listed on a relayer, 0x Instant can be configured to source liquidity from a static set of orders, by providing an array of [`SignedOrder`](https://0x.org/docs/order-utils#types-SignedOrder)s as the `orderSource`.
### Q: How can I get help integrating Instant?
Join us on [Discord](https://discord.gg/d3FTX3M) and join the #instant channel to receive help from our dev team.
## Mobile
### Q: How can I make 0x Instant work in my mobile app?
For apps using React Native or apps that have a web view, the asset buyer engine will work out of the box with your application. For apps that are written in a native language like Java or Swift, you will need to wrap the asset-buyer logic in a JS interpreter.
## Affiliates
### Q: How do I make money as an affiliate?
If you host 0x Instant, you can designate an address that you own to receive a small % of ETH that users spend on assets. The fee percent maxes out at 5%. You can configure this in the AffiliateInfo setting.

6
packages/website/mdx/guides/legal-guide.mdx
View File

@@ -2,7 +2,7 @@ The wide variety of projects that can be built integrating 0x means that there a
_The information below is not legal advice. This is general legal information intended as a resource to the 0x ecosystem. To understand how this information may impact your project specifically, hire a good lawyer._
How all of the laws intersect with the exchange of crypto assets possible through 0x is still an evolving issue and demands careful consideration. For additional resources, check out the [0x Legal Library](https://github.com/0xProject/wiki/blob/master/legal/2-Legal-Library.md) that contains links to important cases, statements from regulators, and other legal commentary specific to the crypto asset industry.
How all of the laws intersect with the exchange of crypto assets possible through 0x is still an evolving issue and demands careful consideration. For additional resources, check out the [0x Legal Library](https://0x.org/docs/guides/legal-guide) that contains links to important cases, statements from regulators, and other legal commentary specific to the crypto asset industry.
# United States
@@ -16,7 +16,7 @@ So what is a security? Unfortunately, as even [federal courts have recognized](h
In particular, the U.S. Supreme Court has outlined a four-part test for determining whether a transaction qualifies as a form of a security called an “investment contract." Originally set forth in [SEC v. W.J. Howey Co.](https://scholar.google.com/scholar_case?case=12975052269830471754&q=sec+v+howey&hl=en&as_sdt=6,47#p298), the Court has explained that a transaction is an “investment contract” when it involves (1) an investment of money (2) in a common enterprise (3) with an expectation of profit (4) to be derived from the efforts of others.
There is a long history of cases interpreting whether various financial instruments meet this definition of a security, covering everything from [bank certificates of deposits](https://scholar.google.com/scholar_case?case=10900624885862830401) to interests in [whiskey barrels](https://scholar.google.com/scholar_case?case=14457626249500273939). Some of the most influential cases have been compiled [here](https://github.com/0xProject/wiki/blob/master/legal/2-Legal-Library.md#key-cases). However, there are many more cases analyzing various elements of the Howey test, each hinging on the specific facts of the particular transaction.
There is a long history of cases interpreting whether various financial instruments meet this definition of a security, covering everything from [bank certificates of deposits](https://scholar.google.com/scholar_case?case=10900624885862830401) to interests in [whiskey barrels](https://scholar.google.com/scholar_case?case=14457626249500273939). Some of the most influential cases have been compiled [here](https://0x.org/docs/guides/legal-guide#federal-securities-regulation-1). However, there are many more cases analyzing various elements of the Howey test, each hinging on the specific facts of the particular transaction.
As proof of the inherent difficulty in defining a clear border between what is and is not a security, there have been numerous instances of courts applying the Howey test to seemingly similar transactions and coming to different results. For example, there are several cases holding certain [real estate leases](https://scholar.google.com/scholar_case?case=4030348895733612487) to be securities when offered in a particular manner. Likewise, there are numerous cases addressing when the sale of a tangible product like [the sale of beavers](https://scholar.google.com/scholar_case?case=8958675023427121133) may be offered as part of a securities transaction. These cases demonstrate that courts place less of a premium on the nature of the underlying product being sold and more on the manner in which it was sold.
@@ -36,7 +36,7 @@ This suggested framework is not meant to be comprehensive, and depending on the
### The SEC's current position
The Securities and Exchange Commission (SEC), the primary regulator of the securities market in the US, has been active in voicing its opinion about certain activities in the crypto asset industry. The SEC's first major foray in the industry came in July 2017 in the form of [a report](https://www.sec.gov/litigation/investreport/34-81207.pdf) stating that sale of tokens by "The DAO" constituted the sale of securities. The SEC has since reached settlements with several industry participants and also issued several statements about when certain activity within the industry may be subject to securities regulations. A complete listing of those documents can be found [here](https://github.com/0xProject/wiki/blob/master/legal/2-Legal-Library.md#sec-statements--settlement-orders). Notably, some members of the SEC have said that they believe that the vast majority of tokens sold as part of a fundraising effort (so called "ICOs") were securities offerings.
The Securities and Exchange Commission (SEC), the primary regulator of the securities market in the US, has been active in voicing its opinion about certain activities in the crypto asset industry. The SEC's first major foray in the industry came in July 2017 in the form of [a report](https://www.sec.gov/litigation/investreport/34-81207.pdf) stating that sale of tokens by "The DAO" constituted the sale of securities. The SEC has since reached settlements with several industry participants and also issued several statements about when certain activity within the industry may be subject to securities regulations. A complete listing of those documents can be found [here](https://0x.org/docs/guides/legal-guide#federal-securities-regulation-1). Notably, some members of the SEC have said that they believe that the vast majority of tokens sold as part of a fundraising effort (so called "ICOs") were securities offerings.
In March 2019, the SEC's Strategic Hub for Innovation and Financial Technology (aka FinHub) issued a framework intended to help those within the crypto asset industry evaluate which assets may be viewed by the Staff of the SEC as securities. The [FinHub framework](https://www.sec.gov/corpfin/framework-investment-contract-analysis-digital-assets) identifies numerous factors to consider when analyzing whether the sale of a crypto asset meets the final two prongs of the Howey test, i.e., whether there is an expectation of profit based on the efforts of a third party. The framework places a strong emphasis on factors used to determine whether an "Active Participant" exists that provides "essential managerial efforts that effect the success of the enterprise, and investors reasonably expect to derive profits from those efforts."

48
packages/website/mdx/guides/market-making-on-0x.mdx
View File

@@ -18,7 +18,7 @@ Trading on a CEX (centralized exchange) requires that you deposit your assets in
0x orders can be hosted by anyone, rather than there being a single entity hosting the orders. Any entity that hosts and distributes 0x orders is called a "relayer". Currently most relayers are centralized entities hosting an API from which orders can be retrieved.
A 0x order is any data packet that contains an [order's details](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#order-message-format) together with a [valid signature](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#signature-types) (e.g. a valid elliptic curve signature generated from the traders Ethereum address) of it's contents.
A 0x order is any data packet that contains an [order's details](https://0x.org/docs/guides/v2-specification#order-message-format) together with a [valid signature](https://0x.org/docs/guides/v2-specification#signature-types) (e.g. a valid elliptic curve signature generated from the traders Ethereum address) of it's contents.
### 3. Settlement of trades
@@ -28,7 +28,7 @@ In order for the 0x smart contracts to move funds on the behalf of traders, the
### What about order matching?
There are two dominant relayer strategies in existence today: [matching](https://0xproject.com/wiki#Matching) and [open orderbook](https://0xproject.com/wiki#Open-Orderbook). Open orderbook relayers host orders that anyone can fill by directly sending a transaction (with the order details and desired fill amount) to the Ethereum blockchain. Using this model, the order in which transactions are filled is determined by the same algorithm used by miners to decide which transactions to include in the next block (more on this later).
There are two dominant relayer strategies in existence today: [matching](https://0x.org/docs/guides/relayer-strategies#matching) and [open orderbook](https://0x.org/docs/guides/relayer-strategies#open-orderbook). Open orderbook relayers host orders that anyone can fill by directly sending a transaction (with the order details and desired fill amount) to the Ethereum blockchain. Using this model, the order in which transactions are filled is determined by the same algorithm used by miners to decide which transactions to include in the next block (more on this later).
Matching relayers require traders to create the inverse 0x order to the one they wish to fill and submit it back to the matcher. The matching relayer will then fill both orders in one atomic transaction to Ethereum on the trader's behalf.
@@ -38,13 +38,13 @@ In both models, the relayer never has custody over a trader's assets.
0x orders only exist off-chain and are completely free to create. In order to create a valid 0x order, you can use the [@0x/order-utils](https://0xproject.com/docs/order-utils) Typescript/Javascript library, or alternatively the [0x-order-utils.py](http://0x-order-utils-py.s3-website-us-east-1.amazonaws.com/) Python library. These libraries will help you:
1. Generate an order in the proper format (e.g encoding/decoding [`assetData`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetdata))
1. Generate an order in the proper format (e.g encoding/decoding [`assetData`](https://0x.org/docs/guides/v2-specification#assetdata))
2. Generating a proper hash for the order contents
3. Sign the order with your elliptic curve signature
For a step-by-step walk-through on the above steps, as well as allowance setting, take a look at the [Create, validate, fill order tutorial](https://0xproject.com/wiki#Create,-Validate,-Fill-Order).
For a set of scenarios show-casing the above steps, as well as allowance setting, take a look at the [0x Starter Project](https://github.com/0xProject/0x-starter-project).
Note that the `salt` field of an order should be set to the current unix timestamp in milliseconds for full compatibility with the [`cancelOrdersUpTo`](#cancelling-orders) function. For low level details of how an order is created, please reference the [orders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#orders) section of the protocol specification.
Note that the `salt` field of an order should be set to the current unix timestamp in milliseconds for full compatibility with the [`cancelOrdersUpTo`](#cancelling-orders) function. For low level details of how an order is created, please reference the [orders](https://0x.org/docs/guides/v2-specification#orders) section of the protocol specification.
Once you have a valid 0x order, it can be submitted to a relayer. You can use the [POST /v2/order](https://github.com/0xProject/standard-relayer-api/blob/master/http/v2.md#post-v2order) endpoint of the Standard Relayer API for this purpose (see: [submitOrderAsync in 0x Connect](https://0xproject.com/docs/connect#HttpClient-submitOrderAsync)).
@@ -52,35 +52,35 @@ If you want to be notified whenever the order is filled by a trader, you should
## Filling orders
Orders may be filled by calling various methods on the [Exchange contract](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#exchange), as described in the [filling orders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#filling-orders) section of the protocol specification. In general, these methods can be broken down into 3 categories:
Orders may be filled by calling various methods on the [Exchange contract](https://0x.org/docs/guides/v2-specification#exchange), as described in the [filling orders](https://0x.org/docs/guides/v2-specification#filling-orders) section of the protocol specification. In general, these methods can be broken down into 3 categories:
### Single order fills
These methods are useful for filling single orders. All of these methods have slightly different failure conditions:
- [fillOrder](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#fillorder)
- [fillOrKillOrder](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#fillorkillorder)
- [fillOrderNoThrow](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#fillordernothrow)
- [fillOrder](https://0x.org/docs/guides/v2-specification#fillorder)
- [fillOrKillOrder](https://0x.org/docs/guides/v2-specification#fillorkillorder)
- [fillOrderNoThrow](https://0x.org/docs/guides/v2-specification#fillordernothrow)
### Multiple order fills
These methods are useful for filling multiple orders in a single transaction. Each method has different conditions around transaction failures and execution:
- [batchFillOrders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#batchfillorders)
- [batchFillOrKillOrders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#batchfillorkillorders)
- [batchFillOrdersNoThrow](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#batchfillordersnothrow)
- [marketSellOrders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketsellorders)
- [marketSellOrdersNoThrow](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketsellordersnothrow)
- [marketBuyOrders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketbuyorders)
- [marketBuyOrdersNoThrow](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketbuyordersnothrow)
- [batchFillOrders](https://0x.org/docs/guides/v2-specification#batchfillorders)
- [batchFillOrKillOrders](https://0x.org/docs/guides/v2-specification#batchfillorkillorders)
- [batchFillOrdersNoThrow](https://0x.org/docs/guides/v2-specification#batchfillordersnothrow)
- [marketSellOrders](https://0x.org/docs/guides/v2-specification#marketsellorders)
- [marketSellOrdersNoThrow](https://0x.org/docs/guides/v2-specification#marketsellordersnothrow)
- [marketBuyOrders](https://0x.org/docs/guides/v2-specification#marketbuyorders)
- [marketBuyOrdersNoThrow](https://0x.org/docs/guides/v2-specification#marketbuyordersnothrow)
### Matching order fills
A special case exists when filling both a buy and sell order of the same asset pair where the price of the sell order is less than or equal to the price of the buy order. These 2 orders can be simultaneously filled with no capital requirements by calling the [matchOrders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#matchorders) function.
A special case exists when filling both a buy and sell order of the same asset pair where the price of the sell order is less than or equal to the price of the buy order. These 2 orders can be simultaneously filled with no capital requirements by calling the [matchOrders](https://0x.org/docs/guides/v2-specification#matchorders) function.
### Interacting with different relayer models
Note that the process for filling orders differs when interacting with an [open orderbook](https://0xproject.com/wiki#Open-Orderbook) relayer or a [matching](https://0xproject.com/wiki#Matching) relayer. These orders can be differentiated by looking at an order's [senderAddress](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#senderaddress) and [takerAddress](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#order-message-format) fields.
Note that the process for filling orders differs when interacting with an [open orderbook](https://0x.org/docs/guides/relayer-strategies#open-orderbook) relayer or a [matching](https://0x.org/docs/guides/relayer-strategies#matching) relayer. These orders can be differentiated by looking at an order's [senderAddress](https://0x.org/docs/guides/v2-specification#senderaddress) and [takerAddress](https://0x.org/docs/guides/v2-specification#order-message-format) fields.
When both fields are set to 0 (as in the open orderbook model), the order can be filled directly by calling the desired fill function on the Exchange contract. The taker filling an order in this way benefits from [Ethereum transaction atomicity](#transaction-atomicity) and more granular control over [transaction failures](#transaction-failures). However, the onus of paying gas and choosing which specific orders to be matched with falls on the taker in this scenario.
@@ -88,7 +88,7 @@ In the matching model, the taker first submits a signed order to the matcher (wh
## Cancelling orders
There are multiple ways to cancel 0x orders by interacting with the [Exchange contract](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#exchange), each of which is described in the [cancelling orders](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#cancelling-orders) section of the protocol specification.
There are multiple ways to cancel 0x orders by interacting with the [Exchange contract](https://0x.org/docs/guides/v2-specification#exchange), each of which is described in the [cancelling orders](https://0x.org/docs/guides/v2-specification#cancelling-orders) section of the protocol specification.
The `cancelOrdersUpTo` approach is perhaps the least straight forward but also the most powerful for a market maker. It allows for the cancellation of an arbitrary number of orders for a fixed amount of gas. By creating orders where the `salt` field is equal to the current unix timestamp in milliseconds, you can cancel all orders that were created at or before a certain time in a single `cancelOrdersUpTo` call (a fixed size transaction). Note that any future orders created with a `salt` that is below the largest `salt` argument of a `cancelOrdersUpTo` call by your address will automatically be invalid.
@@ -98,7 +98,7 @@ Explicitly cancelling orders always requires an on-chain transaction. However, y
Since 0x orders live off-chain, they must be fetched from relayers. All relayers host APIs that allow you to pull orders from their orderbook. In order to make life easier for traders, many implement the [Standard Relayer API](https://github.com/0xProject/standard-relayer-api/), allowing you to use a single client to fetch orders from multiple relayers. Standard Relayer API clients exist in [Python](https://pypi.org/project/0x-sra-client/) and [Typescript/Javascript](https://0xproject.com/docs/connect).
To learn more about fetching orders from relayers, check out our [Find, submit, fill order from relayer tutorial](https://0xproject.com/wiki#Find,-Submit,-Fill-Order-From-Relayer).
To learn more about fetching orders from relayers, check out our [How to use the Standard Relayer API tutorial](https://0x.org/docs/guides/using-the-standard-relayer-api).
## Trading on Ethereum
@@ -106,13 +106,13 @@ When trading on a centralized exchange, you must integrate exclusively with the
### Ethereum node management
In order to monitor the Ethereum blockchain, you must interface with an Ethereum node. You can either integrate your market maker with a hosted node service such as [Infura.io](https://infura.io/) or you can [host your own node](https://0xproject.com/wiki#How-To-Deploy-A-Parity-Node). While developing your market maker, you might want to [setup Ganache](https://0xproject.com/wiki#Ganache-Setup-Guide), a fake Ethereum node used for testing purposes.
In order to monitor the Ethereum blockchain, you must interface with an Ethereum node. You can either integrate your market maker with a hosted node service such as [Infura.io](https://infura.io/) or you can host your own node. While developing your market maker, you might want to [setup Ganache](https://0x.org/docs/guides/ganache-setup), a fake Ethereum node used for testing purposes.
### Probabilistic finality
Since trades on 0x are settled by being included my miners into a block, settlement is subject to the same probabalistic finality as any other state-transition in Ethereum. Probabilistic finality means that no trade settlement is ever 100% final. It becomes exponentially more final with every additional Ethereum block that is mined ontop of the one it was included in.
What this means is that for a period of time settlement can still revert. This happens when there is a block re-organization, causing a valid next block to become "uncled" (i.e. no longer part of the main chain). It does not happen often, but it is an important edge-case to handle. [@0x/order-watcher](https://0xproject.com/wiki#0x-OrderWatcher) can help you handle all possible state changes related to the 0x orders you care about (including state reversions).
What this means is that for a period of time settlement can still revert. This happens when there is a block re-organization, causing a valid next block to become "uncled" (i.e. no longer part of the main chain). It does not happen often, but it is an important edge-case to handle. [0x Mesh](https://0x-org.gitbook.io/mesh) can help you handle all possible state changes related to the 0x orders you care about (including state reversions).
### Block timestamps
@@ -124,7 +124,7 @@ Because the 0x Protocol checks order expiration using block timestamps, the orde
In most blockchains, the miner decides which valid transactions to include in the next block they attempt to mine. They are expected to be economically rational agents who will prioritize transactions that pay them the most fees, however they have full discretion over transaction ordering.
Let's say a trader submits an order cancellation transaction; there are no guarantees about the order in which this transaction will be included in the blockchain. You can try and incentize miners to include it sooner by increasing the `gasPrice` (read: fee) paid for the transaction, but so can any other trader attempting to fill the order (read more about this problem in our [front-running, griefing and the perils of virtual settlement](https://blog.0xproject.com/front-running-griefing-and-the-perils-of-virtual-settlement-part-1-8554ab283e97) blog post series). Because of this race-condition, we recommend you use shorter expiration times on your orders rather than relying heavily on on-chain cancellations. Alternatively, you can use our [cancelOrdersUpTo](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#cancelordersupto) feature to cancel multiple orders in a single transaction.
Let's say a trader submits an order cancellation transaction; there are no guarantees about the order in which this transaction will be included in the blockchain. You can try and incentize miners to include it sooner by increasing the `gasPrice` (read: fee) paid for the transaction, but so can any other trader attempting to fill the order (read more about this problem in our [front-running, griefing and the perils of virtual settlement](https://blog.0xproject.com/front-running-griefing-and-the-perils-of-virtual-settlement-part-1-8554ab283e97) blog post series). Because of this race-condition, we recommend you use shorter expiration times on your orders rather than relying heavily on on-chain cancellations. Alternatively, you can use our [cancelOrdersUpTo](https://0x.org/docs/guides/v2-specification#cancelordersupto) feature to cancel multiple orders in a single transaction.
### Transaction failures
@@ -172,7 +172,7 @@ Currently we have the best tooling support for Javascript/Typescript and are act
If you plan on implementing custom infrastructure, you will need the following functionality at a bare minimum:
- Interacting with relayers over Websockets or HTTPS
- Encoding the [`assetData`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetdata) of an order using [ABIv2](https://solidity.readthedocs.io/en/latest/abi-spec.html)
- Encoding the [`assetData`](https://0x.org/docs/guides/v2-specification#assetdata) of an order using [ABIv2](https://solidity.readthedocs.io/en/latest/abi-spec.html)
- Hashing orders
- Cryptographically signing orders with the address you wish to trade with

2
packages/website/mdx/guides/page-template.mdx
View File

@@ -33,7 +33,7 @@ ___This text is bold and italicized___
# Sol-coverage
Sol-coverage <Note heading="Test note">This is a side-info callout used to explain things a little more when needed</Note> uses transaction traces in order to figure out which lines of Solidity source code have been covered by your tests. In order for it to gather these traces, you must add the `CoverageSubprovider` to the [ProviderEngine](https://github.com/MetaMask/provider-engine) instance you use when running your Solidity tests. If you're unfamiliar with `ProviderEngine`, please read the [Web3 Provider explained](https://0x.org/wiki#Web3-Provider-Explained) wiki article.
Sol-coverage <Note heading="Test note">This is a side-info callout used to explain things a little more when needed</Note> uses transaction traces in order to figure out which lines of Solidity source code have been covered by your tests. In order for it to gather these traces, you must add the `CoverageSubprovider` to the [ProviderEngine](https://github.com/MetaMask/provider-engine) instance you use when running your Solidity tests. If you're unfamiliar with `ProviderEngine`, please read the [Web3 Provider explained](https://0x.org/docs/guides/web3-provider-explained#more-complex-providers) guide.
The CoverageSubprovider eavesdrops on the `eth_sendTransaction` and `eth_call` RPC calls and collects traces after each call using `debug_traceTransaction`. `eth_call`'s' don't generate traces - so we take a snapshot, re-submit it as a transaction, get the trace and then revert the snapshot.

4
packages/website/mdx/guides/relayer-strategies.mdx
View File

@@ -53,7 +53,7 @@ Relayer Charlie says that he is willing to buy ZRX at a rate of 1000 ZRX per WET
## Rationale
Since this strategy does not require any commitments to be made until the trader agrees to a rate, any arbitrary off-chain negotiation process can occur before an order is signed. Once an order is signed, the relayer also has the option of hedging with external liquidity, so the relayer does not necessarily need as large reserves as with the [reserve manager](https://github.com/0xProject/wiki/blob/master/relayer-strategies/Reserve-Manager.md) strategy.
Since this strategy does not require any commitments to be made until the trader agrees to a rate, any arbitrary off-chain negotiation process can occur before an order is signed. Once an order is signed, the relayer also has the option of hedging with external liquidity, so the relayer does not necessarily need as large reserves as with the [reserve manager](https://0x.org/docs/guides/relayer-strategies#reserve-manager) strategy.
## Limitations
@@ -63,7 +63,7 @@ After a trader signs an order, the relayer is in no way obligated to fill that o
# Reserve Manager
A relayer can provide its own liquidity by frequently posting large orders with short expiration times where the `taker` field is equal to `0x0000000000000000000000000000000000000000`. This can be used separately from or in conjunction with the [open orderbook](https://github.com/0xProject/wiki/blob/master/relayer-strategies/Open-Orderbook.md) strategy.
A relayer can provide its own liquidity by frequently posting large orders with short expiration times where the `taker` field is equal to `0x0000000000000000000000000000000000000000`. This can be used separately from or in conjunction with the [open orderbook](https://0x.org/docs/guides/relayer-strategies#open-orderbook) strategy.
## Example

44
packages/website/mdx/guides/v2-coordinatior-specification.mdx
View File

@@ -1,6 +1,6 @@
# Architecture
[0x version 2.0](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md) introduced the concept of a [0x transactions](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#transactions), a new way to interact with the [`Exchange` contract](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#exchange). 0x transactions allow external accounts or contracts to execute Exchange methods in the context of the transaction signer, which makes it possible to add custom logic to the execution of trades or cancels.
[0x version 2.0](https://0x.org/docs/guides/v2-specification) introduced the concept of a [0x transactions](https://0x.org/docs/guides/v2-specification#transactions), a new way to interact with the [`Exchange` contract](https://0x.org/docs/guides/v2-specification#exchange). 0x transactions allow external accounts or contracts to execute Exchange methods in the context of the transaction signer, which makes it possible to add custom logic to the execution of trades or cancels.
The coordinator model makes heavy use of this concept in order to add an additional layer of verification to `Exchange` contract interactions. An order may specify a single coordinator's address that is responsible for approving any fills of the order. The coordinator can set custom rules that may be used to prevent trade collisions, enable free and instant cancels, or add time delays to filling order.
@@ -18,19 +18,19 @@ This specification will describe a specific implementation of each component tha
5. The taker submits the signed 0x transaction and approval to the `Coordinator` extension contract by calling `Coordinator.executeTransaction`.
6. The `Coordinator` contract verifies that the approval is valid/unexpired and executes the 0x transaction by calling `Exchange.executeTransaction`.
<Image src="https://github.com/0xProject/0x-protocol-specification/raw/master/v2/img/0x_v2_coordinator.png" align="center" marginBottom="4rem"/>
<Image src="https://0x-wiki-images.s3.eu-west-2.amazonaws.com/0x_v2_coordinator.png" align="center" marginBottom="4rem"/>
# Message Types
## Orders
The [`Coordinator` contract](#coordinator) is compatible with orders where the [`senderAddress`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#senderaddress) is equal to the address of this contract or the null address. If an order's `senderAddress` is null, that order may be filled or cancelled through the `Coordinator` contract or directly through the `Exchange` contract. For a full specification of the order schema, please see the [orders section](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#orders) of the 0x 2.0 specification.
The [`Coordinator` contract](#coordinator) is compatible with orders where the [`senderAddress`](https://0x.org/docs/guides/v2-specification#senderaddress) is equal to the address of this contract or the null address. If an order's `senderAddress` is null, that order may be filled or cancelled through the `Coordinator` contract or directly through the `Exchange` contract. For a full specification of the order schema, please see the [orders section](https://0x.org/docs/guides/v2-specification#orders) of the 0x 2.0 specification.
For the purposes of this specification, orders that specify the `Coordinator` contract as the `senderAddress` will be referred to as "coordinator orders".
## Transactions
The `Coordinator` contract processes regular [0x transaction](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#transactions) messages, using the `Exchange` 2.0 EIP712 domain header (see the Solidity type [here](#zeroextransaction)). Transactions may be signed with any valid [0x 2.0 signature type](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#signature-types).
The `Coordinator` contract processes regular [0x transaction](https://0x.org/docs/guides/v2-specification#transactions) messages, using the `Exchange` 2.0 EIP712 domain header (see the Solidity type [here](#zeroextransaction)). Transactions may be signed with any valid [0x 2.0 signature type](https://0x.org/docs/guides/v2-specification#signature-types).
In Solidity, this message is represented as:
@@ -134,20 +134,20 @@ When interacting with coordinator orders, the following Exchange methods must be
| Method | Approval required |
| ---------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| [`fillOrder`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#fillorder) | Yes |
| [`fillOrKillOrder`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#fillorkillorder) | Yes |
| [`fillOrderNoThrow`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#fillordernothrow) | Yes |
| [`batchFillOrders`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#batchfillorders) | Yes |
| [`batchFillOrKillOrders`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#batchfillorkillorders) | Yes |
| [`batchFillOrdersNoThrow`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#batchfillordersnothrow) | Yes |
| [`marketBuyOrders`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketbuyorders) | Yes |
| [`marketBuyOrdersNoThrow`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketbuyordersnothrow) | Yes |
| [`marketSellOrders`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketsellorders) | Yes |
| [`marketSellOrdersNoThrow`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#marketsellordersnothrow) | Yes |
| [`matchOrders`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#matchorders) | Yes |
| [`cancelOrder`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#cancelorder) | No |
| [`batchCancelOrders`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#batchcancelorders) | No |
| [`cancelOrdersUpTo`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#cancelordersupto) | No |
| [`fillOrder`](https://0x.org/docs/guides/v2-specification#fillorder) | Yes |
| [`fillOrKillOrder`](https://0x.org/docs/guides/v2-specification#fillorkillorder) | Yes |
| [`fillOrderNoThrow`](https://0x.org/docs/guides/v2-specification#fillordernothrow) | Yes |
| [`batchFillOrders`](https://0x.org/docs/guides/v2-specification#batchfillorders) | Yes |
| [`batchFillOrKillOrders`](https://0x.org/docs/guides/v2-specification#batchfillorkillorders) | Yes |
| [`batchFillOrdersNoThrow`](https://0x.org/docs/guides/v2-specification#batchfillordersnothrow) | Yes |
| [`marketBuyOrders`](https://0x.org/docs/guides/v2-specification#marketbuyorders) | Yes |
| [`marketBuyOrdersNoThrow`](https://0x.org/docs/guides/v2-specification#marketbuyordersnothrow) | Yes |
| [`marketSellOrders`](https://0x.org/docs/guides/v2-specification#marketsellorders) | Yes |
| [`marketSellOrdersNoThrow`](https://0x.org/docs/guides/v2-specification#marketsellordersnothrow) | Yes |
| [`matchOrders`](https://0x.org/docs/guides/v2-specification#matchorders) | Yes |
| [`cancelOrder`](https://0x.org/docs/guides/v2-specification#cancelorder) | No |
| [`batchCancelOrders`](https://0x.org/docs/guides/v2-specification#batchcancelorders) | No |
| [`cancelOrdersUpTo`](https://0x.org/docs/guides/v2-specification#cancelordersupto) | No |
`executeTransaction` will revert under the following conditions:
@@ -283,7 +283,7 @@ function getCoordinatorEndpoint(address coordinatorOperator)
# Signature Types
All signatures submitted to the `Coordinator` contract are represented as a byte array of arbitrary length, where the last byte (the "signature byte") specifies the signatures type. The signature type is popped from the signature byte array before validation. The allowed coordinator signature types are symmetric to the [Exchange signature types](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#signature-types), but do not include `Wallet`, `Validator`, and `PreSigned` types. The following signature types are supported:
All signatures submitted to the `Coordinator` contract are represented as a byte array of arbitrary length, where the last byte (the "signature byte") specifies the signatures type. The signature type is popped from the signature byte array before validation. The allowed coordinator signature types are symmetric to the [Exchange signature types](https://0x.org/docs/guides/v2-specification#signature-types), but do not include `Wallet`, `Validator`, and `PreSigned` types. The following signature types are supported:
| Signature byte | Signature type |
| -------------- | ------------------- |
@@ -302,7 +302,7 @@ An `Invalid` signature will always revert, much like the `Illegal` type. An inva
## EIP712
An `EIP712` signature is considered valid if the address recovered from calling [`ecrecover`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#ecrecover-usage) with the given hash and decoded `v`, `r`, `s` values is the same as the specified signer. In this case, the signature is encoded in the following way:
An `EIP712` signature is considered valid if the address recovered from calling [`ecrecover`](https://0x.org/docs/guides/v2-specification#ecrecover-usage) with the given hash and decoded `v`, `r`, `s` values is the same as the specified signer. In this case, the signature is encoded in the following way:
| Offset | Length | Contents |
| ------ | ------ | ------------------- |
@@ -312,7 +312,7 @@ An `EIP712` signature is considered valid if the address recovered from calling
## EthSign
An `EthSign` signature is considered valid if the address recovered from calling [`ecrecover`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#ecrecover-usage) with the an EthSign-prefixed hash and decoded `v`, `r`, `s` values is the same as the specified signer.
An `EthSign` signature is considered valid if the address recovered from calling [`ecrecover`](https://0x.org/docs/guides/v2-specification#ecrecover-usage) with the an EthSign-prefixed hash and decoded `v`, `r`, `s` values is the same as the specified signer.
The prefixed `msgHash` is calculated with:
@@ -528,7 +528,7 @@ Submit a signed 0x transaction encoding either a 0x fill or cancellation. If the
}
```
- `signedTransaction` - A signed [0x transaction](https://github.com/0xProject/0x-protocol-specification/blob/ad13141d9a2c6d93e06658d18c53e9f3d99442d4/v2/v2-specification.md#transactions) along with the `verifyingContractAddress` which is part of it's [EIP712 domain](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md#definition-of-domainseparator).
- `signedTransaction` - A signed [0x transaction](https://0x.org/docs/guides/v2-specification#transactions) along with the `verifyingContractAddress` which is part of it's [EIP712 domain](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md#definition-of-domainseparator).
- `txOrigin` - The address that will eventually submit the Ethereum transaction executing this 0x transaction on-chain. This will be enforced by the `Coordinator` extension contract.
#### Response

12
packages/website/mdx/guides/v2-forwarder-specification.mdx
View File

@@ -1,14 +1,14 @@
# Architecture
<Image src="https://github.com/0xProject/0x-protocol-specification/raw/master/v2/img/0x_v2_forwarder.png" align="center" marginBottom="4rem"/>
<Image src="https://0x-wiki-images.s3.eu-west-2.amazonaws.com/0x_v2_forwarder.png" align="center" marginBottom="4rem"/>
The Forwarding contract acts as a middleman between the user and the 0x Exchange contract. Its purpose is to perform a number of useful actions on the users behalf. Conveniently reducing the number of steps and transactions.
The 0x protocol [AssetProxy](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetproxy) contracts work as operators that are authorized to move tokens on behalf of users if an order with a valid signature can be produced. Since ETH is not a token and cannot be moved natively by a third party operator, Wrapped ETH (WETH) is introduced to adapt ETH to work in this environment. WETH requires a user to deposit ETH into the WETH contract (transaction) and approve (transaction) the AssetProxy operator to transfer the WETH on the user's behalf.
The 0x protocol [AssetProxy](https://0x.org/docs/guides/v2-specification#assetproxy) contracts work as operators that are authorized to move tokens on behalf of users if an order with a valid signature can be produced. Since ETH is not a token and cannot be moved natively by a third party operator, Wrapped ETH (WETH) is introduced to adapt ETH to work in this environment. WETH requires a user to deposit ETH into the WETH contract (transaction) and approve (transaction) the AssetProxy operator to transfer the WETH on the user's behalf.
When performing an exchange on 0x, fees may be required to be paid by the maker and takers in ZRX token. The AssetProxy needs approval to move these tokens (transaction) and ZRX tokens need to be pre-purchased (transaction).
A user is then able to find an order and perform a TokenA/WETH `fillOrder` on the 0x [Exchange contract](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#exchange) (transaction).
A user is then able to find an order and perform a TokenA/WETH `fillOrder` on the 0x [Exchange contract](https://0x.org/docs/guides/v2-specification#exchange) (transaction).
For first time purchasers of tokens, this is non-trivial setup that is unavoidable due to the design of the ERC20 standard. The Forwarding contracts purpose is to enable users to buy tokens in one transaction.
@@ -18,7 +18,7 @@ For first time purchasers of tokens, this is non-trivial setup that is unavoidab
The Forwarder contains all of the following logic:
- Presets approval to the [ERC20Proxy](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#erc20proxy) and the [ERC721Proxy](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#erc721proxy)
- Presets approval to the [ERC20Proxy](https://0x.org/docs/guides/v2-specification#erc20proxy) and the [ERC721Proxy](https://0x.org/docs/guides/v2-specification#erc721proxy)
- Converts ETH into WETH on behalf of the user
- Performs the exchange via the 0x Exchange contract
- Purchases ZRX on behalf of the user (ZRX fee abstraction)
@@ -41,7 +41,7 @@ This function buys a specific amount of assets (ERC20 or ERC721) given a set of
This function will revert under the following conditions:
- No ETH value was included in the transaction
- The `makerAssetData` contains an [`assetProxyId`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetdata) that is not supported (currently ERC20 and ERC721 only)
- The `makerAssetData` contains an [`assetProxyId`](https://0x.org/docs/guides/v2-specification#assetdata) that is not supported (currently ERC20 and ERC721 only)
- The entire `makerAssetFillAmount` cannot be filled
- The amount of ZRX paid in fees cannot be repurchased
- The supplied `feePercentage` is greater than 5% (represented as 0.05 \* 10^18)
@@ -89,7 +89,7 @@ This function attempts to buy as many ERC20 tokens as possible given the amount
This function will revert under the following conditions:
- No ETH value was included in the transaction
- The `makerAssetData` contains an [`assetProxyId`](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetdata) that is not supported (currently ERC20 and ERC721 only)
- The `makerAssetData` contains an [`assetProxyId`](https://0x.org/docs/guides/v2-specification#assetdata) that is not supported (currently ERC20 and ERC721 only)
- The amount of ZRX paid in fees cannot be repurchased
- The supplied `feePercentage` is greater than 5% (represented as 0.05 \* 10^18)
- The required ETH fee cannot be paid

4
packages/website/mdx/guides/v2-specification.mdx
View File

@@ -172,7 +172,7 @@ A trade is initiated when an [order](#orders) is passed into the [`Exchange`](#e
### ERC20 ↔ ERC20
<Image src="https://github.com/0xProject/0x-protocol-specification/raw/master/v2/img/0x_v2_trade_erc20_erc20.png" align="center" marginBottom="4rem"/>
<Image src="https://0x-wiki-images.s3.eu-west-2.amazonaws.com/0x_v2_trade_erc20_erc20.png" align="center" marginBottom="4rem"/>
Transaction #1
@@ -189,7 +189,7 @@ Transaction #1
### ERC20 ↔ ERC721
<Image src="https://github.com/0xProject/0x-protocol-specification/raw/master/v2/img/0x_v2_trade_erc20_erc721.png" align="center" marginBottom="4rem"/>
<Image src="https://0x-wiki-images.s3.eu-west-2.amazonaws.com/0x_v2_trade_erc20_erc721.png" align="center" marginBottom="4rem"/>
Transaction #1

8
packages/website/mdx/guides/web3-provider-explained.mdx
View File

@@ -48,7 +48,7 @@ await contractWrappers.setProvider(newProvider, networkId);
# Web3 Provider Examples
As described in the [Web3 Provider Explained](#Web3-Provider-Explained) section of the wiki, we at 0x have created a number of useful Web3 subproviders. These subproviders aren't only useful for 0x.js, they can be added to any application to provide resiliency, usability and to support hardware wallet functionality.
As described above, we at 0x have created a number of useful Web3 subproviders. These subproviders aren't only useful for 0x.js, they can be added to any application to provide resiliency, usability and to support hardware wallet functionality.
You can install the 0x subproviders package as follows:
@@ -58,6 +58,8 @@ npm install @0x/subproviders --save
The subproviders work best when they are composed together using the [Web3 Provider Engine](https://github.com/MetaMask/provider-engine). This is re-exported from `@0x/subproviders` so you don't need to install any additional dependencies.
## Metamask example
In the first example, we will make use of a browser extension wallet (e.g [Metamask](https://metamask.io/)) composed with an Ethereum node we control. This set up allows all of the account based activity (signing of messages and sending transactions) to route to the browser extension wallet, while allowing the data fetching requests to flow through to a specific Ethereum node of our choosing.
```typescript
@@ -84,6 +86,8 @@ providerEngine.start();
Using the configuration above, all account related requests (e.g signing and sending a transaction) go through the browser extension wallet. All other data fetching requests go through the RPC Subprovider. This example is great as an application can use their own synced Ethereum node, rather than relying on Metamask or Infura uptime.
## Ledger example
Within the 0x Subprovider package, we have also added a [Ledger Nano S](https://www.ledgerwallet.com/start/ledger-nano-s) subprovider. By adding this subprovider first into the Web3 Provider Engine, we are able to route all account based requests to the Ledger. We again use the RPC Provider for all other requests.
```typescript
@@ -148,6 +152,8 @@ It is important to remember that UI components and UX need to be considered when
- The hardware device is limited to handling one request at a time
- The hardware device is not capable of showing the message entirely on screen. An application [should confirm](https://github.com/ethfinex/0x-order-verify) what is displayed on the device
## RedundantRPCSubprovider example
In our last example we will add redundancy to the application by making use of the RedundantRPCSubprovider. The RedundantRPCSubprovider helps your application stay up when underlying Ethereum nodes experience network issues. To use this subprovider, simply provide it with a list of Ethereum node RPC endpoints and it will attempt each one in sequence until a successful response is returned.
```typescript

25
packages/website/scripts/algolia_meta.json
View File

@@ -107,7 +107,12 @@
"title": "0x Coordinator Specification (v2)",
"description": "A comprehensive technical spec of the first coordinator model developer by the 0x core team (soft-cancel variant)",
"tags": ["Coordinator", "Relayer", "Trader", "Protocol Developer"],
"topics": ["Coordinator", "Relayer", "Trader", "Protocol Developer"],
"topics": [
"Coordinator",
"Relayer",
"Trader",
"Protocol Developer"
],
"difficulty": "Advanced",
"path": "guides/v2-coordinatior-specification.mdx"
},
@@ -134,6 +139,22 @@
"topics": ["Relayer", "Trader"],
"difficulty": "Beginner",
"path": "guides/web3-provider-explained.mdx"
},
"market-making-on-0x": {
"title": "Market-making on 0x",
"description": "Learn how to market-make on 0x, and what the differences are between trading on a CEX vs. DEX",
"tags": ["Trader"],
"topics": ["Trader"],
"difficulty": "Beginner",
"path": "guides/market-making-on-0x.mdx"
},
"0x-extensions-explained": {
"title": "0x Extensions explained",
"description": "Learn about how you can extend 0x protocol with your own custom extensions adding white-listing, dutch auction mechanics and much more to 0x.",
"tags": ["Relayer", "Trader", "Extensions"],
"topics": ["Relayer", "Trader", "Extensions"],
"difficulty": "Advanced",
"path": "guides/0x-extensions-explained.mdx"
}
},
"tools": {
@@ -515,4 +536,4 @@
"externalUrl": "https://github.com/0xProject/0x-coordinator-server"
}
}
}
}

2
packages/website/ts/components/dropdowns/dropdown_resources.tsx
View File

@@ -27,7 +27,7 @@ const introData: LinkConfig[] = [
},
{
label: 'Legal Wiki',
url: `${WebsitePaths.Wiki}#Legal-Wiki`,
url: `${WebsitePaths.DocsGuides}/legal-guide`,
shouldOpenInNewTab: true,
},
];

7
packages/website/ts/components/fill_warning_dialog.tsx
View File

@@ -34,11 +34,8 @@ export const FillWarningDialog = (props: FillWarningDialogProps) => {
<div className="pt2" style={{ color: colors.grey700 }}>
<div>
At least one of the tokens in this order was not found in the token registry smart contract and may
be counterfeit. It is your responsibility to verify the token addresses on Etherscan (
<a href="https://0x.org/wiki#Verifying-Custom-Tokens" target="_blank">
See this how-to guide
</a>
) before filling an order. <b>This action may result in the loss of funds</b>.
be counterfeit. It is your responsibility to verify the token addresses on Etherscan before filling
an order. <b>This action may result in the loss of funds</b>.
</div>
</div>
</Dialog>

2
packages/website/ts/components/footer.tsx
View File

@@ -44,7 +44,7 @@ const linkRows: LinkRows[] = [
links: [
{ url: WebsitePaths.Docs, text: 'Documentation' },
{ url: constants.URL_GITHUB_ORG, text: 'GitHub', shouldOpenInNewTab: true },
{ url: constants.URL_PROTOCOL_SPECIFICATION, text: 'Protocol Spec', shouldOpenInNewTab: true },
{ url: `${WebsitePaths.DocsGuides}/v2-specification`, text: 'Protocol Spec', shouldOpenInNewTab: true },
],
},
{

2
packages/website/ts/index.tsx
View File

@@ -150,7 +150,7 @@ render(
<Route path={`${WebsitePaths.Docs}/:type/:page?/:version?`} component={DocsPage as any} />
{/* Legacy endpoints */}
<Redirect from={WebsitePaths.Wiki} to={WebsitePaths.DocsGuides} />
<Redirect from={WebsiteLegacyPaths.Wiki} to={WebsitePaths.DocsGuides} />
<Redirect from={WebsiteLegacyPaths.Jobs} to={WebsitePaths.AboutJobs} />
<Redirect from={WebsitePaths.Careers} to={WebsitePaths.AboutJobs} />
<Route component={NotFound as any} />

10
packages/website/ts/pages/extensions.tsx
View File

@@ -32,7 +32,7 @@ const extensionData: Extension[] = [
links: [
{
text: 'Explore the Docs',
url: `${WebsitePaths.Wiki}#0x-Extensions`,
url: `${WebsitePaths.DocsGuides}/0x-extensions-explained`,
},
],
},
@@ -43,7 +43,7 @@ const extensionData: Extension[] = [
links: [
{
text: 'Explore the Docs',
url: 'https://github.com/0xProject/0x-protocol-specification/blob/master/v2/forwarder-specification.md',
url: 'https://0x.org/docs/guides/v2-forwarder-specification',
},
],
},
@@ -54,7 +54,7 @@ const extensionData: Extension[] = [
links: [
{
text: 'Explore the Docs',
url: `${WebsitePaths.Wiki}#0x-Extensions`,
url: `${WebsitePaths.DocsGuides}/0x-extensions-explained`,
},
],
},
@@ -105,7 +105,7 @@ export class Extensions extends React.Component<Props> {
subline="Developers can build custom extensions on 0x to add new modes of exchange"
mainCta={{
text: 'Get Started',
href: `${WebsitePaths.Wiki}#0x-Extensions`,
href: `${WebsitePaths.DocsGuides}/0x-extensions-explained`,
shouldOpenInNewTab: true,
}}
secondaryCta={{ text: 'Get in Touch', onClick: this._onOpenContactModal.bind(this) }}
@@ -128,7 +128,7 @@ export class Extensions extends React.Component<Props> {
const HeroActions = () => (
<React.Fragment>
<Button href={`${WebsitePaths.Wiki}#0x-Extensions`} isInline={true} target="_blank">
<Button href={`${WebsitePaths.DocsGuides}/0x-extensions-explained`} isInline={true} target="_blank">
Get Started
</Button>

8
packages/website/ts/pages/instant.tsx
View File

@@ -22,7 +22,7 @@ const CONFIGURATOR_MIN_WIDTH_PX = 1050;
export const getStartedClick = () => {
if (window.innerWidth < CONFIGURATOR_MIN_WIDTH_PX) {
utils.openUrl(`${WebsitePaths.Wiki}#Get-Started-With-Instant`);
utils.openUrl(`${WebsitePaths.DocsGuides}/integrate-instant`);
} else {
utils.setUrlHash('configurator');
utils.scrollToHash('configurator', '');
@@ -43,7 +43,7 @@ const featuresData = [
},
{
label: 'Explore the Docs',
url: `${WebsitePaths.Wiki}#Get-Started-With-Instant`,
url: `${WebsitePaths.DocsGuides}/integrate-instant`,
},
],
},
@@ -55,7 +55,7 @@ const featuresData = [
links: [
{
label: 'Learn about affiliate fees',
url: `${WebsitePaths.Wiki}#Learn-About-Affiliate-Fees`,
url: `${WebsitePaths.DocsGuides}/integrate-instant#learn-about-affiliate-fees`,
},
],
},
@@ -140,7 +140,7 @@ export class Next0xInstant extends React.Component<Props> {
<Banner
heading="Need more flexibility?"
subline="Dive into our docs, or contact us if needed"
mainCta={{ text: 'Explore the Docs', href: `${WebsitePaths.Wiki}#Get-Started-With-Instant` }}
mainCta={{ text: 'Explore the Docs', href: `${WebsitePaths.DocsGuides}/integrate-instant` }}
secondaryCta={{ text: 'Get in Touch', onClick: this._onOpenContactModal.bind(this) }}
/>
<ModalContact isOpen={this.state.isContactModalOpen} onDismiss={this._onDismissContactModal} />

2
packages/website/ts/pages/instant/config_generator.tsx
View File

@@ -126,7 +126,7 @@ export class ConfigGenerator extends React.Component<ConfigGeneratorProps, Confi
}));
};
private readonly _handleAffiliatePercentageLearnMoreClick = (): void => {
window.open(`${WebsitePaths.Wiki}#Learn-About-Affiliate-Fees`, '_blank');
window.open(`${WebsitePaths.DocsGuides}/integrate-instant#learn-about-affiliate-fees`, '_blank');
};
private readonly _handleSRASelection = (event: React.ChangeEvent<HTMLSelectElement>) => {
const sraEndpoint = event.target.value;

2
packages/website/ts/pages/instant/configurator.tsx
View File

@@ -39,7 +39,7 @@ export class Configurator extends React.Component {
<Heading size="small" marginBottom="15px">
Code Snippet
</Heading>
<Link href={`${WebsitePaths.Wiki}#Get-Started-With-Instant`} isBlock={true} target="_blank">
<Link href={`${WebsitePaths.DocsGuides}/integrate-instant`} isBlock={true} target="_blank">
Explore the Docs
</Link>
</HeadingWrapper>

6
packages/website/ts/pages/market_maker.tsx
View File

@@ -43,7 +43,7 @@ export class NextMarketMaker extends React.Component<NextMarketMakerProps> {
links: [
{
label: 'Explore the Docs',
url: `${WebsitePaths.Wiki}#Market-Making-on-0x`,
url: `${WebsitePaths.DocsGuides}/market-making-on-0x`,
},
],
},
@@ -134,7 +134,7 @@ export class NextMarketMaker extends React.Component<NextMarketMakerProps> {
<Banner
heading="Start trading today."
subline="Check out our Market Making tutorials to get started"
mainCta={{ text: 'Tutorials', href: `${WebsitePaths.Wiki}#Market-Making-on-0x` }}
mainCta={{ text: 'Tutorials', href: `${WebsitePaths.DocsGuides}/market-making-on-0x` }}
secondaryCta={{ text: 'Apply Now', onClick: this._onOpenContactModal }}
/>
<ModalContact
@@ -158,7 +158,7 @@ export class NextMarketMaker extends React.Component<NextMarketMakerProps> {
private readonly _renderHeroActions = () => (
<>
<Button href={`${WebsitePaths.Wiki}#Market-Making-on-0x`} bgColor="dark" isInline={true}>
<Button href={`${WebsitePaths.DocsGuides}/market-making-on-0x`} bgColor="dark" isInline={true}>
Get Started
</Button>
<Button

2
packages/website/ts/types.ts
View File

@@ -424,6 +424,7 @@ export enum Docs {
export enum WebsiteLegacyPaths {
Deployer = '/docs/deployer',
Wiki = '/wiki',
Jobs = '/jobs',
ZeroExJs = '/docs/0x.js',
Connect = '/docs/connect',
@@ -444,7 +445,6 @@ export enum WebsiteLegacyPaths {
export enum WebsitePaths {
Portal = '/portal',
Wiki = '/wiki',
Docs = '/docs',
DocsApiExplorer = '/docs/api-explorer',
DocsCoreConcepts = '/docs/core-concepts',

5
packages/website/ts/utils/backend_client.ts
View File

@@ -17,7 +17,6 @@ const JOBS_ENDPOINT = '/jobs';
const PRICES_ENDPOINT = '/prices';
const RELAYERS_ENDPOINT = '/relayers';
const TOKENS_ENDPOINT = '/tokens';
const WIKI_ENDPOINT = '/wiki';
const CFL_METRICS_ENDPOINT = '/cfl-metrics';
const SUBSCRIBE_SUBSTACK_NEWSLETTER_ENDPOINT = '/newsletter_subscriber/substack';
@@ -49,10 +48,6 @@ export const backendClient = {
const result = await fetchUtils.requestAsync(utils.getBackendBaseUrl(), TOKENS_ENDPOINT);
return result;
},
async getWikiArticlesBySectionAsync(): Promise<ArticlesBySection> {
const result = await fetchUtils.requestAsync(utils.getBackendBaseUrl(), WIKI_ENDPOINT);
return result;
},
async subscribeToNewsletterAsync(email: string): Promise<Response> {
const result = await fetchUtils.postAsync(utils.getBackendBaseUrl(), SUBSCRIBE_SUBSTACK_NEWSLETTER_ENDPOINT, {
email,

20
packages/website/ts/utils/constants.ts
View File

@@ -86,8 +86,6 @@ export const constants = {
URL_GITHUB_ORG: 'https://github.com/0xProject',
URL_GITHUB_WIKI: 'https://github.com/0xProject/wiki',
URL_FORUM,
URL_PROTOCOL_SPECIFICATION:
'https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md',
URL_METAMASK_CHROME_STORE: 'https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn',
URL_METAMASK_FIREFOX_STORE: 'https://addons.mozilla.org/en-US/firefox/addon/ether-metamask/',
URL_COINBASE_WALLET_IOS_APP_STORE: 'https://itunes.apple.com/us/app/coinbase-wallet/id1278383455?mt=8',
@@ -123,22 +121,6 @@ export const constants = {
URL_VOTE_FAQ:
'https://blog.0xproject.com/vote-with-zrx-to-add-support-for-erc-1155-and-the-staticcallassetproxy-49a855807bcd#967f',
URL_ZEIP_REPO: 'https://github.com/0xProject/ZEIPs/',
DEVELOPER_TOPBAR_LINKS: [
{
title: Key.Wiki,
to: WebsitePaths.Wiki,
},
{
title: Key.Forum,
to: URL_FORUM,
shouldOpenInNewTab: true,
},
{
title: Key.LiveChat,
to: URL_ZEROEX_CHAT,
shouldOpenInNewTab: true,
},
] as ALink[],
TYPES_SECTION_NAME: 'types',
EXTERNAL_EXPORTS_SECTION_NAME: 'external exports',
TYPE_TO_SYNTAX: {
@@ -148,7 +130,7 @@ export const constants = {
DOCS_SCROLL_DURATION_MS: 0,
SCROLL_CONTAINER_ID: 'scroll_container',
SCROLL_TOP_ID: 'pageScrollTop',
CFL_DOCS: `${WebsitePaths.Wiki}#Contract-Fillable-Liquidity`,
CFL_DOCS: `${WebsitePaths.DocsGuides}/contract-fillable-liquidity`,
NETWORK_NAME_BY_ID: {
1: Networks.Mainnet,
3: Networks.Ropsten,