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

Fix links in guides

Browse Source
This commit is contained in:
fabioberger
2019-08-29 14:20:04 +02:00
parent 25077affc8
commit 7217bfa35e
12 changed files with 53 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -55,7 +55,7 @@ The Dutch Auction encodes additional parameters into the maker asset data, param
<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/tools/contract-wrappers#DutchAuctionWrapper-encodeDutchAuctionAssetData).
Encoding of the additional parameters is provided on the [Dutch Auction contract wrapper](https://0x.org/docs/tools/contract-wrappers#encodeDutchAuctionAssetData).
```typescript
// Additional data is encoded in the maker asset data, this includes the begin time and begin amount

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

@@ -173,7 +173,7 @@ exchange.tokenToTokenSwapInput(...)
kyberNetworkProxyContract.swapTokenToToken(...)
```
Kyber and Uniswap rely on purely on-chain mechanisms to provide liquidity; 0x, however, sources liquidity from off-chain entities called relayers or from 0x mesh, a peer-to-peer network. With this in mind, a number of off-chain computations must occur to prepare 0x liquidity for use in a smart contract.
Kyber and Uniswap rely on purely on-chain mechanisms to provide liquidity; 0x, however, sources liquidity from off-chain entities called relayers or from [0x mesh](https://0x-org.gitbook.io/mesh/), a peer-to-peer network. With this in mind, a number of off-chain computations must occur to prepare 0x liquidity for use in a smart contract.
Asset-swapper is a convenience javascript package that does most, if not all, of the off-chain work required for smart contract developers to easily leverage 0x protocol.

2
packages/website/mdx/guides/ganache-setup.mdx
View File

@@ -3,7 +3,7 @@ In order to run 0x.js methods that interact with the Ethereum blockchain (i.e fi
# Install Ganache-cli locally
```
npm install -g ganache-cli@6.1.6
npm install -g ganache-cli
```
In order to run Ganache-cli with all the latest V2 0x protocol smart contracts available, you must first download [this Ganache-cli snapshot](http://ganache-snapshots.0x.org.s3.amazonaws.com/0x_ganache_snapshot-2.4.0.zip) and save it. Next unzip it's contents with:

48
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](#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.
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) for users to fill.
## Affiliate Fees
@@ -55,18 +55,18 @@ Codepen [example](https://codepen.io/bmillman19/pen/qQzQQK)
| Option | Description |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `orderSource` | Accepts either a [Standard Relayer API HTTP endpoint](https://github.com/0xProject/standard-relayer-api/blob/master/http/v2.md) or an array of signed 0x [orders](https://0x.org/docs/tools/order-utils#types-SignedOrder) |
| `orderSource` | Accepts either a [Standard Relayer API HTTP endpoint](https://github.com/0xProject/standard-relayer-api/blob/master/http/v2.md) or an array of signed [0x orders](https://0x.org/docs/tools/order-utils#interface-signedorder) |
## Optional
| Option | Description |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `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 |
| `provider` | An instance of an Ethereum [provider](#q-what-is-a-provider), 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](#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. |
| `availableAssetDatas` | An array of [assetDatas](#q-what-is-assetdata), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#q-what-is-a-signedorder) 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](#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. |
| `additionalAssetMetaDataMap` | An object with keys that are assetData strings and values that are objects that adhere to the [AssetMetaData schema](#q-what-is-assetmetadata), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#q-what-is-a-signedorder). 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. |
@@ -77,7 +77,7 @@ Codepen [example](https://codepen.io/bmillman19/pen/qQzQQK)
## Serving Own Liquidity
```javascript
```typescript
zeroExInstant.render(
{
// these can come from your own api, or anywhere
@@ -91,7 +91,7 @@ zeroExInstant.render(
Using [/asset_pairs](https://github.com/0xProject/standard-relayer-api/blob/master/http/v2.md#get-v2asset_pairs) to find all \*/WETH pairs
```javascript
```typescript
zeroExInstant.render(
{
orderSource: 'https://api.radarrelay.com/0x/v2/',
@@ -104,7 +104,7 @@ zeroExInstant.render(
This will give you more control over what provider is passed in and where RPC calls are directed
```javascript
```typescript
zeroExInstant.render(
{
orderSource: 'https://api.radarrelay.com/0x/v2/',
@@ -117,7 +117,7 @@ zeroExInstant.render(
## Providing a Default Token
```javascript
```typescript
zeroExInstant.render(
{
orderSource: 'https://api.radarrelay.com/0x/v2/',
@@ -132,7 +132,7 @@ zeroExInstant.render(
3% of transaction volume will de deposited into 0x50ff5828a216170cf224389f1c5b0301a5d0a230
```javascript
```typescript
zeroExInstant.render(
{
orderSource: 'https://api.radarrelay.com/0x/v2/',
@@ -147,7 +147,7 @@ zeroExInstant.render(
## Providing your own callback handler
```javascript
```typescript
zeroExInstant.render(
{
orderSource: 'https://api.radarrelay.com/0x/v2/',
@@ -161,9 +161,9 @@ 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](#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/tools/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 FAQ section](#q-what-is-assetmetadata), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#q-what-is-a-signedorder) 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/tools/order-utils#interface-signedorder)s, unless you are running your own relayer, or know of a relayer that has liquidity for your custom token.
```javascript
```typescript
const erc20TokenAddress = '0xe41d2489571d322189246dafa5ebde1f4699f498';
const erc20TokenAssetData = zeroExInstant.assetDataForERC20TokenAddress(erc20TokenAddress);
@@ -188,9 +188,9 @@ 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](#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/tools/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 FAQ section](#q-what-is-assetmetadata), but teams may optionally source liquidity themselves and pass in specific [SignedOrders](#q-what-is-a-signedorder) 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/tools/order-utils#interface-signedorder)s, unless you are running your own relayer, or know of a relayer that has liquidity for your custom token.
```javascript
```typescript
const erc721TokenAddress = '0xf5b0a3efb8e8e4c201e2a935f110eaaf3ffecb8d';
const erc721TokenId = 31097;
const erc721AssetData = zeroExInstant.assetDataForERC721TokenAddress(erc721TokenAddress, erc721TokenId);
@@ -216,7 +216,7 @@ zeroExInstant.render(
Behind the scenes, the `AssetBuyer` class is aggregating liquidity and calculating the orders that need to be filled for a given user request. For teams that require a more custom integration or advanced functionality, they can use the AssetBuyer class directly and skip the Instant UI. Below are the methods you will most likely be interacting with.
```javascript
```typescript
/**
* 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.
@@ -253,7 +253,7 @@ async executeBuyQuoteAsync(buyQuote: BuyQuote,
Where the option types are as follows:
```javascript
```typescript
/**
* feePercentage: The affiliate fee percentage. Defaults to 0.
* shouldForceOrderRefresh: If set to true, new orders and state will be fetched instead of waiting for the next orderRefreshIntervalMs. Defaults to false.
@@ -284,7 +284,7 @@ export interface BuyQuoteExecutionOpts {
`getBuyQuoteAsync()` and `getBuyQuoteForERC20TokenAddressAsync()` are used to retrieve a `BuyQuote` object that contains information about buying a specific amount of asset that can be displayed to the user.
```javascript
```typescript
/**
* 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).
@@ -322,7 +322,7 @@ There are several static `AssetBuyer` factory methods that can be used to constr
## Full AssetBuyer Example:
```javascript
```typescript
const provider = window.ethereum;
const sraUrl = 'https://api.radarrelay.com/0x/v2/';
const zrxAssetData = '0xf47261b0000000000000000000000000e41d2489571d322189246dafa5ebde1f4699f498';
@@ -348,7 +348,7 @@ Example: 3% of transaction volume (in ETH) will de deposited into 0x50ff5828a216
</head>
```
```javascript
```typescript
zeroExInstant.render(
{
orderSource: 'https://api.radarrelay.com/0x/v2/',
@@ -375,7 +375,7 @@ The Standard relayer API is an HTTP specification that facilitates discovering a
### 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
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 the [examples](https://0x.org/docs/guides/web3-provider-explained#web3-provider-examples) of how to create your own providers
### Q: How can I check liquidity of an asset prior to rendering Instant?
@@ -399,7 +399,7 @@ 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).
As we now support multiple [token transfer proxies](https://0x.org/docs/guides/v2-specification#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/tools/0x.js#encodeerc20assetdata) and [decoding](https://0x.org/docs/tools/0x.js#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).
@@ -426,7 +426,7 @@ Encoding the ERC721 token contract (address: `0x371b13d97f4bf77d724e78c16b7dc740
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).
For more information see [the Asset Proxy](https://0x.org/docs/guides/v2-specification#erc20proxy) section of the v2 spec and the [Ethereum ABI Spec](https://solidity.readthedocs.io/en/develop/abi-spec.html).
### Q: What is assetMetaData?
@@ -485,7 +485,7 @@ To prevent massive price ranges, 0x Instant calculates a maximum amount of asset
### 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/tools/order-utils#types-SignedOrder)s as the `orderSource`.
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/tools/order-utils#interface-signedorder)s as the `orderSource`.
### Q: How can I get help integrating Instant?

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

@@ -1,8 +1,10 @@
# Introduction
The wide variety of projects that can be built integrating 0x means that there are no uniform legal standards applicable to all projects. That being said, there are certain legal regimes that are more likely than others to impact the projects being built on 0x. This document surveys some of the relevant laws and regulations that developers should be aware of and potentially seek qualified and individualized legal advice on to ensure compliance.
_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://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.
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](#legal-library) that contains links to important cases, statements from regulators, and other legal commentary specific to the crypto asset industry.
# United States
@@ -16,7 +18,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://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.
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](#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 +38,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://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.
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](#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."

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

@@ -1,4 +1,4 @@
This tutorial will attempt to bridge the knowledge-gap between market-making on centralized cryptocurrency exchanges (e.g Binance) and market-making on 0x, a decentralised exchange protocol built on Ethereum (see: [technical protocol specification](/guides/v2-specification)).
This tutorial will attempt to bridge the knowledge-gap between market-making on centralized cryptocurrency exchanges (e.g Binance) and market-making on 0x, a decentralised exchange protocol built on Ethereum (see: [technical protocol specification](https://0x.org/docs/guides/v2-specification)).
## High-level primer
@@ -36,7 +36,7 @@ In both models, the relayer never has custody over a trader's assets.
## Creating orders
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/tools/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:
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://0x.org/docs/tools/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://0x.org/docs/guides/v2-specification#assetdata))
2. Generating a proper hash for the order contents
@@ -46,7 +46,7 @@ For a set of scenarios show-casing the above steps, as well as allowance setting
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/tools/connect#HttpClient-submitOrderAsync)).
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://0x.org/docs/tools/connect#submitorderasync)).
If you want to be notified whenever the order is filled by a trader, you should also submit the order to a [0x Mesh node](https://0x-org.gitbook.io/mesh/) instance you are running.
@@ -96,7 +96,7 @@ Explicitly cancelling orders always requires an on-chain transaction. However, y
## Fetching off-chain orders
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/tools/connect).
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://0x.org/docs/tools/connect).
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).
@@ -167,7 +167,7 @@ The 0x protocol expects a user's assets to be located in their own wallet, rathe
### What is the state of 0x developer tooling?
Currently we have the best tooling support for Javascript/Typescript and are actively improving support for Python. Visit the [developers section](https://0xproject.com/docs) of our site for a full-list of developer tools avaiable.
Currently we have the best tooling support for Javascript/Typescript and are actively improving support for Python. Visit the [developers section](https://0x.org/docs) of our site for a full-list of developer tools avaiable.
If you plan on implementing custom infrastructure, you will need the following functionality at a bare minimum:

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://0x.org/docs/guides/relayer-strategies#reserve-manager) 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](#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://0x.org/docs/guides/relayer-strategies#open-orderbook) 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](#open-orderbook) strategy.
## Example

10
packages/website/mdx/guides/using-the-standard-relayer-api.mdx
View File

@@ -1,4 +1,4 @@
In this tutorial, we will show you how you can use the [@0x/connect](https://github.com/0xProject/0x.js/tree/development/packages/connect) package in conjunction with [0x.js](https://github.com/0xProject/0x.js/tree/development/packages/0x.js) in order to:
In this tutorial, we will show you how you can use the [@0x/connect](https://0x.org/docs/tools/connect) package in conjunction with [0x.js](https://0x.org/docs/tools/0x.js) in order to:
- ask a relayer for fee information
- submit signed orders to a relayer with appropriate fees
@@ -8,7 +8,7 @@ In this tutorial, we will show you how you can use the [@0x/connect](https://git
You can find all the `@0x/connect` documentation [here](https://0x.org/docs/tools/connect).
You can find a list of relayers that comply with the Standard Relayer API [here](https://github.com/0xProject/0x-relayer-registry)
You can find a list of relayers that comply with the Standard Relayer API [here](https://github.com/0xProject/0x-relayer-registry/blob/master/relayers.json)
# Setup
@@ -77,7 +77,7 @@ import { getContractAddressesForNetworkOrThrow } from '@0x/contract-addresses';
## Instantiating a Provider and ContractWrappers
First, we need to instantiate an instance of ContractWrappers and a Provider. In our case, since we are using our local node (ganache), we will use **http://localhost:8545**. You can read about what providers are [here](#Web3-Provider-Explained).
First, we need to instantiate an instance of ContractWrappers and a Provider. In our case, since we are using our local node (ganache), we will use **http://localhost:8545**. You can read about what providers are [here](https://0x.org/docs/guides/web3-provider-explained).
```typescript
import { RPCSubprovider, Web3ProviderEngine } from '0x.js';
@@ -251,7 +251,7 @@ Now let's actually verify whether the order we created is valid
await contractWrappers.exchange.validateOrderFillableOrThrowAsync(signedOrder);
```
If something was wrong with our order, this function would throw an informative error. If it passes, then the order is currently fillable. A relayer should constantly be [pruning their orderbook](#0x-OrderWatcher) of invalid orders using this method.
If something was wrong with our order, this function would throw an informative error. If it passes, then the order is currently fillable. A relayer should constantly be [pruning their orderbook](https://0x-org.gitbook.io/mesh/advanced-topics/db_syncing) of invalid orders using this method.
## Submitting the order to the relayer
@@ -282,7 +282,7 @@ if (response.asks.total === 0) {
## Filling an order
`OrderbookResponse` contains two fields, `bids` and `asks`. `Bids` is a [`PaginatedCollection`](https://0x.org/docs/tools/connect#types-PaginatedCollection) of [`APIOrder`](https://0x.org/docs/connect#types-APIOrder)s where for each order, the `makerAssetData` field is equal to the `quoteAssetData` provided by the `OrderbookRequest` and the `takerAssetData` field is equal to `baseAssetData`. `Asks` is the opposite of `bids`. For each order, the `makerAssetData` field is equal to the `baseAssetData` and the `takerAssetData` field is equal to `quoteAssetData`.
`OrderbookResponse` contains two fields, `bids` and `asks`. `Bids` is a [`PaginatedCollection`](https://0x.org/docs/tools/connect#interface-paginatedcollection-t) of [`APIOrder`](https://0x.org/docs/tools/connect#interface-apiorder)s where for each order, the `makerAssetData` field is equal to the `quoteAssetData` provided by the `OrderbookRequest` and the `takerAssetData` field is equal to `baseAssetData`. `Asks` is the opposite of `bids`. For each order, the `makerAssetData` field is equal to the `baseAssetData` and the `takerAssetData` field is equal to `quoteAssetData`.
The Standard Relayer API guarantees that the orders are sorted by price, and then by _taker fee price_ which is defined as the `takerFee` divided by `takerAmount`. After _taker fee price_, orders are to be sorted by expiration in ascending order.

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

@@ -6,13 +6,13 @@ The coordinator model makes heavy use of this concept in order to add an additio
A coordinator has 2 components that differentiate it from a traditional relayer:
1. The [`Coordinator` contract](#coordinator), which is a [0x extension contract](/docs/guides/v2-specification#filter-contracts) that verifies transactions have been approved by the correct set of coordinators.
1. The [`Coordinator` contract](#coordinator), which is a [0x extension contract](https://0x.org/docs/guides/0x-extensions-explained) that verifies transactions have been approved by the correct set of coordinators.
1. A [coordinator server](#reference-coordinator-server) that approves or rejects 0x transactions under different conditions.
This specification will describe a specific implementation of each component that intends to create a market structure that is more favorable for liquidity providers while allowing for liquidity to be consumed by smart contracts. See the reference server [design choices](#design-choices) section for more information. The flow for filling an order with the coordinator model is as follows:
1. A taker selects the desired order(s) and creates a valid signed 0x transaction to fill the order(s) (e.g. `batchFillOrdersNoThrow`).
2. The taker looks up the Coordinator server endpoint(s) corresponding to the order(s) using the [Coordinator Registry](#CoordinatorRegistry) smart contract.
2. The taker looks up the Coordinator server endpoint(s) corresponding to the order(s) using the [Coordinator Registry](#coordinatorregistry) smart contract.
3. The taker sends a fill request with the signed 0x transaction to the coordinator server that corresponds to each order.
4. After a 1 second delay, the coordinator server responds with a signed approval.
5. The taker submits the signed 0x transaction and approval to the `Coordinator` extension contract by calling `Coordinator.executeTransaction`.
@@ -30,7 +30,7 @@ For the purposes of this specification, orders that specify the `Coordinator` co
## Transactions
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).
The `Coordinator` contract processes regular [0x transaction](https://0x.org/docs/guides/v2-specification#transactions) messages, using the `Exchange` 2.0 EIP712 domain header. 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:
@@ -44,7 +44,7 @@ struct ZeroExTransaction {
## Approvals
0x transactions that call any `Exchange` fill methods must be approved by a coordinator. The approval includes the following fields (see the Solidity type [here](#coordinatorapproval)):
0x transactions that call any `Exchange` fill methods must be approved by a coordinator. The approval includes the following fields:
| Parameter | Type | Description |
| ----------------------------- | ------- | ------------------------------------------------------------------------------------- |
@@ -392,7 +392,7 @@ Fill transaction requests should be rejected under the following conditions:
All other fill requests must be approved by the coordinator server exactly `SELECTIVE_DELAY_MS` after the request is received.
When a valid transaction request has been received, the coordinator server must broadcast a [`FILL_REQUEST_RECEIVED`](#fill_request_received) message to all connected Websocket clients. After a duration of `SELECTIVE_DELAY_MS`, the server should approve the fill request and simultaneously broadcast a [`FILL_REQUEST_APPROVED`](#fill_request_approved) message to all connected Websocket clients (if any orders contained in the transaction have not been soft cancelled in the mean time).
When a valid transaction request has been received, the coordinator server must broadcast a [`FILL_REQUEST_RECEIVED`](#fill_request_received) message to all connected Websocket clients. After a duration of `SELECTIVE_DELAY_MS`, the server should approve the fill request and simultaneously broadcast a [`FILL_REQUEST_ACCEPTED`](#fill_request_accepted) message to all connected Websocket clients (if any orders contained in the transaction have not been soft cancelled in the mean time).
## Handling cancels
@@ -479,7 +479,7 @@ Some networks and their Ids:
| 4 | Rinkeby |
| 50 | 0x Ganache snapshot |
If a certain network is not supported, the response should **400** as specified in the [error response](#error-response) section. For example:
If a certain network is not supported, the response should **400** as specified in the [error response](#errors) section. For example:
```json
{

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

@@ -137,7 +137,7 @@ The `feePercentage` and `feeRecipient` are a feature in the Forwarding contract
## Optimizing calldata
Calldata is expensive. As per Appendix G of the [ETHeum Yellowpaper](#https://ETHeum.github.io/yellowpaper/paper.pdf), every non-zero byte of calldata costs 68 gas, and every zero byte costs 4 gas. There are certain off-chain optimizations that can be made in order to maximize the amount of zeroes included in calldata.
Calldata is expensive. As per Appendix G of the [Ethereum yellow paper](#https://ETHeum.github.io/yellowpaper/paper.pdf), every non-zero byte of calldata costs 68 gas, and every zero byte costs 4 gas. There are certain off-chain optimizations that can be made in order to maximize the amount of zeroes included in calldata.
### Assuming order parameters

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

@@ -133,7 +133,7 @@ The `ERC721Proxy` performs the transfer by calling the token's `transferFrom` me
### MultiAssetProxy
The `MultiAssetProxy` expects an `amounts` (`uint256` array) and a `nestedAssetData` (array of [`asseData`](#assetdata) byte arrays) to be encoded within its own `assetData`. Each element of `amounts` corresponds to an element at the same index of `nestedAssetData`. The `MultiAssetProxy` will multiply each `amounts` element by the `amount` passed into `MultiAssetProxy.transferFrom` and then dispatch the corresponding element of `nestedAssetProxy` to the relevant [`AssetProxy`](#assetproxy) contract with the resulting `totalAmount`. This contract does not perform any `transferFrom` calls to assets directly and therefore does not require any additional user approvals.
The `MultiAssetProxy` expects an `amounts` (`uint256` array) and a `nestedAssetData` (array of [`assetData`](#assetdata) byte arrays) to be encoded within its own `assetData`. Each element of `amounts` corresponds to an element at the same index of `nestedAssetData`. The `MultiAssetProxy` will multiply each `amounts` element by the `amount` passed into `MultiAssetProxy.transferFrom` and then dispatch the corresponding element of `nestedAssetProxy` to the relevant [`AssetProxy`](#assetproxy) contract with the resulting `totalAmount`. This contract does not perform any `transferFrom` calls to assets directly and therefore does not require any additional user approvals.
This contract expects its `assetData` to be encoded using [ABIv2](http://solidity.readthedocs.io/en/latest/abi-spec.html) with the following 4 byte id:

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

@@ -38,14 +38,6 @@ A great use case for custom providers is to support additional ways for your use
Many people use browser extension wallets (e.g [Metamask](https://metamask.io/)). These services inject a web3 provider into the page so that your dApp can relay signing requests. We wrote [SignerSubprovider](https://github.com/0xProject/0x-monorepo/blob/cd08a9c1218fa7c4819e31248e50da2a4f45ee36/packages/subproviders/src/subproviders/signer.ts) so that we could route all signing requests to the injected provider, but have all other requests handled by another backing Ethereum node.
## Updating the provider used by `@0x/contract-wrappers`
If at some point the provider used by your dApp changes (e.g if your user wants to use their Ledger Nano S to sign orders), it is important that you update the provider used by your `@0x/contract-wrappers`. You can do this by calling [setProvider](https://0x.org/docs/tools/contract-wrappers#ContractWrappers-setProvider).
```typescript
await contractWrappers.setProvider(newProvider, networkId);
```
# Web3 Provider Examples
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.
@@ -88,7 +80,7 @@ Using the configuration above, all account related requests (e.g signing and sen
## 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.
Within the 0x Subprovider package, we have also added a [Ledger Nano S](https://shop.ledger.com/products/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
import {