* Code generation scripts
* Generated code
* Change test config to hit 0x-launch-kit
* Ran prettier on generated code
* First test case, of get_asset_pairs()
* Use launch kit docker image to faciliate CI tests
* Fix markdown rendering for GitHub and PyPI
* Add URL for PyPI to link back to GitHub
* Add one-line package description to README.md
* Remove git_push.sh
* Remove unimplemented tests
* Add sra_client to top-level README package list
* Remove repeated-everywhere long description
* Add shorcuts for publishing
* Remove TypeScript examples
The OHLCV script in data pipeline quits early when we get no data from Crypto Compare. Sometimes Crypto Compare gives us a valid empty response (e.g. when we query for way back in time) and we need to just continue. This adds better filtering for the types of Crypto Compare responses to detect when we should continue and when we should really quit.
* [WIP] pull OHLCV records from Crypto Compare
* lint
* refactor to pull logic out of script and into modules
* add entity test for ohlcv_external entity
* implement rate limit and chronological backfill for ohlcv
* add unit tests; cleanup variable names
* Fetch OHLCV pairs params from events table
* better method names
* fix outdated test
* lint
* Clean up after review
* oops
* fix failing test
* better filtering of most recent records
* fix bug when generating pairs
* fix default earliest backfill date
* fix bug with retrieving backfill time
* prettier
* Introduce framework for running basic tests for entities
* Add pipeline tests to CircleCI config
* Make pipeline tests more configurable and fix CircleCI config
* Add coverage dir to pipeline package
* Add basic tests for all exchange event entities
* Add tests for remaining entities
* Create separate test scripts in package.json and add new info to README
* Update db_setup.ts to revert migrations even if you are using docker
* Automatically pull the postgres image if needed
* Add comment about why NumberToBigIntTransformer is needed
* Implemented basic functionality for using cache layer of LocalRefResolver
* Use `importlib` instead of `imp`, since it's been deprecated. Legacy `load_module()` reloads modules even if they are already imported, causing tests to fail when run in non-deterministic ordering, so we replace it with `import_module()`
* development:
fix: add --exclude-missing flag to yarn clean command
Update CHANGELOG
fix: remove getApproved check from OrderValidator since approval is removed after a single transfer
Add comment
Force scaling input component to rerender when a different asset is chosen
Send in explicit props
feat(instant): Add more event properties to heap
Move out generating of event properties, and send in orderSource
autofocus -> hasAutoFocus
fix(instant): Right align amounts
fix(instant): Autofocus text amount input
* 'development' of github.com:0xProject/0x-monorepo:
Add additional CHANGELOG to types package
Add CHANGELOG entry
Fix prettier
Fix `SimpleContractArtifact` type
Update abi-gen-wrappers
Add @0x/types to dependencies of `@0x/abi-gen-wrappers`
Allow a `SimpleContractArtifact` to be passed into `deployFrom0xArtifactAsync`
Update issue template
fix(instant): Use new valid svg image for instant
isDisabled -> isInputDisabled
Allow user to select other token on success
fix: do not use document on import
fix(instant): Don't allow changing of assets when order processing
fix: npmignore file ignoring index.d.ts
fix: specify new location of index.js in package.json
feat: fix instant build and add to project references
chore: make instant public
* development: (37 commits)
Add 0x-order-utils.py library to developers home
Fixes to CONTRIBUTING.md
Improve our CONTRIBUTING.md instructions
fix(order_utils.py): publish docs to S3, not RTD (#1264)
fix: make instant package private
feat: refer to map file in postpublish configs
feat: add new bundle name to bundle watch
fix: tslint ignore rule in wrong place
Update blog post feature
Fix disclaimer on mobile
Add smart contract docs to Developer Home
Add Apache license link
Fix capitalization in title
Remove excess semi-colon
Point directly to README for docs link
Update icons
Update LICENSE
Fix disclaimer
Add blogpost URL
Add disclaimer
...
* development: (110 commits)
fix: fix exceeds block gas limit error
chore(instant): fix lint error
fix: remove unused vars
Send in affiliate info as option
Have heartbeat update not trigger errors
fix: remove redundant handler
feat: make onUnlockWalletClick different based on ON
chore: remove wallet panel content for mobile
feat: use blue for wallet prompt on mobile
feat: use stable version of bowser
fix: add http to external url string
feat: make onUnlockWalletClick different based on ON
chore: remove wallet panel content for mobile
feat: use blue for wallet prompt on mobile
feat: use stable version of bowser
feat: expose webpack-dev-server content to local network
fix(website): remove node env definition from webpack
fix(website): currentProvider called on undefined
chore: update yarn lock
feat: use capital values for enums
...
Also moved is_valid_signature() into main package module, for
simplicity.
Also consolidated a handul of in-line pylint disable directives into the
.pylintrc config file.
* development:
Publish
Updated CHANGELOGS
Fix a bug when undefined was been tried to convert to an array
feat(instant): add extra asset metadata
chore: fix linter error
Improve logo spacing
fix: lowercase supplied address before comparing with derived addresses (which are not checksummed)
Remove unused instance variable
update yarn.lock
Increase logo size
Replace remaining scroll-links with Link component
Adjust paddin
Fix menuItem background colors depending on the context
Remove "Home" menu item, instead make different parts of logo link to different sections of the website
Rename tutorial to match verb structure
chore: Make `External exports` clickable on sidebar
style: reduce border size on version dropdown
style: make line-height of sidebar title 26px, make sure still bottom aligned with version picker
Update yarn.lock
style: remove small gap under topbar
# Number of days of inactivity before an issue becomes stale
daysUntilStale:30
# Number of days of inactivity before a stale issue is closed
daysUntilClose:7
# Issues with these labels will never be considered stale
exemptLabels:
- pinned
- security
# Label to use when marking an issue as stale
staleLabel:stale
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment:>
This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs. Thank you
for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment:>
This issue has been automatically closed because no activity occured in 7 days after being marked as stale. If it's still relevant - feel free to reopen. Thank you
Thank you for your interest in contributing to 0x protocol! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes!
We welcome contributions from anyone on the internet and are grateful for even the smallest contributions. This document will help get you setup to start contributing back to 0x.
### How to contribute
### Getting started
If you'd like to contribute to 0x protocol, please fork the repo, fix, commit and send a pull request against the `development` branch for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check with a core dev first on [our RocketChat #dev channel](http://chat.0xproject.com) to ensure those changes are in-line with the general philosophy of the project and/or to get some early feedback which can make both your efforts easier as well as our review and merge procedures quick and simple.
1. Fork `0xproject/0x-monorepo`
2. Clone your fork
3. Follow the [installation & build steps](https://github.com/0xProject/0x-monorepo#install-dependencies) in the repo's top-level README.
4. Setup the recommended [Development Tooling](#development-tooling).
5. Open a PR with the `[WIP]` flag against the `development` branch and describe the change you are intending to undertake in the PR description. (see [our branch naming conventions](#branch-structure))
We encourage a “PR early” approach so create the PR as early as possible even without the fix/feature ready, so that devs and other contributors know you have picked up the issue. These early PRs should indicate an 'in progress' status by adding the '[WIP]' prefix to the PR title. Please make sure your contributions adhere to our coding guidelines:
Before removing the `[WIP]` tag and submitting the PR for review, make sure:
*Pull requests adding features or refactoring should be opened against the `development` branch
*Pull requests fixing bugs in the latest release version should be opened again the `master` branch
*It is properly formatted with Prettier (`yarn prettier`)
*It passes our continuous integration tests (See: [Enabling code coverage checks on your fork](#enabling-code-coverage-checks-on-your-fork) for instructions on getting the `submit-coverage` test to pass on forks)
* You've created/updated the corresponding [CHANGELOG](#CHANGELOGs) entries.
* Your changes have sufficient test coverage (e.g regression tests have been added for bug fixes)
### Code quality
### Branch structure
Because 0x.js is used by multiple relayers in production and their businesses depend on it, we strive for exceptional code quality. Please follow the existing code standards and conventions. `tslint` and `prettier` (described below) will help you.
We have two main branches:
If you're adding functionality, please also add tests and make sure they pass. We have an automatic coverage reporting tool, so we'll see it if they are missing ;)
If you're adding a new public function/member, make sure you document it with Java doc-style comments. We use typedoc to generate [awesome documentation](https://0xproject.com/docs/0xjs) from the comments within our source code.
*`master` represents the most recently released (published on npm) version of the codebase.
*`development` represents the current development state of the codebase.
If the sub-package you are modifying has a `CHANGELOG.md` file, make sure to add an entry in it for the change made to the package. For published packages, only changes that modify the public interface or behavior of the package need a CHANGELOG entry.
ALL PRs should be opened against `development`.
#### Enabling code coverage checks on your fork
Branch names should be prefixed with `fix`, `feature` or `refactor`.
If you simply fork the repo and then create a PR sourced from it, your PR will fail its test coverage check. This is because the 0x CircleCI configuration sets the `COVERALLS_REPO_TOKEN` environment variable to the token for 0xProject/0x-monorepo, but when running the check against your fork the token needs to match the repo that is your fork, rather than the 0x repo.
* e.g `fix/broken-wiki-link`
* If the PR only edits a single package, add it's name too
* e.g `fix/website/broken-wiki-link`
To facilitate this check, after creating your fork, but before creating the branch for your PR, do the following:
### CHANGELOGs
1. Log in to [coveralls.io](https://coveralls.io/), go to Add Repos, and enable your fork. Then go to the settings for that repo, and copy the Repo Token identifier.
2. Log in to [CircleCI](https://circleci.com/login), go to Add Projects, click the Set Up Project button corresponding to your fork, and then click Start Building. (Aside from step 3 below, no actual set up is needed, since it will use the `.circleci/config.yml` file in 0x-monorepo, so you can ignore all of the instruction/explanation given on the page with the Start Building button.)
3. In CircleCI, configure your project to add an Environment Variable, with name `COVERALLS_REPO_TOKEN`, and for the value paste in the Repo Token you copied in step 1.
At 0x we use [Semantic Versioning](http://semver.org/) for all our published packages. If a change you make corresponds to a semver bump, you must modify the package's `CHANGELOG.json` file accordingly.
Now, when you push to your branch, CircleCI will automatically run all of the checks in your own instance, and the coverage check will work since it has the proper Repo Token, and the PR will magically refer to your own checks rather than running them in the 0x CircleCI instance.
Each CHANGELOG entry that corresponds to a published package will have a `timestamp`. If no entry exists without a `timestamp`, you must first create a new one:
### Styleguide
```
{
"version": "1.0.1", <- The updated package version
"changes": [
{
"note": "", <- Describe your change
"PR": 100 <- Your PR number
}
]
},
```
We use [TSLint](https://palantir.github.io/tslint/) with [custom configs](https://github.com/0xProject/0x-monorepo/tree/development/packages/tslint-config) to keep our code style consistent.
If an entry without a `timestamp` already exists, this means other changes have been introduced by other collaborators since the last publish. Add your changes to the list of notes and adjust the version if your PR introduces a greater semver change (i.e current changes required a patch bump, but your changes require a major version bump).
To lint your code just run: `yarn lint`
### Development Tooling
We also use [Prettier](https://prettier.io/) to auto-format our code. Be sure to either add a [text editor integration](https://prettier.io/docs/en/editors.html) or a [pre-commit hook](https://prettier.io/docs/en/precommit.html) to properly format your code changes.
We strongly recommend you use the [VSCode](https://code.visualstudio.com/) text editor since most of our code is written in Typescript and it offers amazing support for the language.
#### Linter
We use [TSLint](https://palantir.github.io/tslint/) with [custom configs](https://github.com/0xProject/0x-monorepo/tree/development/packages/tslint-config) to keep our code-style consistent.
Use `yarn:lint` to lint the entire monorepo, and `PKG={PACKAGE_NAME} yarn lint` to lint a specific package.
If you want to change a rule, or add a custom rule, please make these changes to our [tslint-config](https://github.com/0xProject/0x-monorepo/tree/development/packages/tslint-config) package. All other packages have it as a dependency.
We use [Prettier](https://prettier.io/) to auto-format our code. Be sure to either add a [text editor integration](https://prettier.io/docs/en/editors.html) or a [pre-commit hook](https://prettier.io/docs/en/precommit.html) to properly format your code changes.
If using the Atom text editor, we recommend you install the following packages:
Our CI will also run TSLint and Prettier as a part of the test run when you submit your PR. Make sure that the CI tests pass for your contribution.
## Fix `submit-coverage` CI failure
### Branch structure & versioning
If you simply fork the repo and then create a PR from it, your PR will fail the `submit-coverage` check on CI. This is because the 0x CircleCI configuration sets the `COVERALLS_REPO_TOKEN` environment variable to the token for `0xProject/0x-monorepo`, but when running the check against your fork the token needs to match your repo's name `your-username/0x-monorepo`.
We use [semantic versioning](http://semver.org/), but before a package reaches v1.0.0 all breaking changes as well as new features will be minor version bumps.
To facilitate this check, after creating your fork, but before creating the branch for your PR, do the following:
We have two main branches: `master` and `development`.
1. Log in to [coveralls.io](https://coveralls.io/), go to `Add Repos`, and enable your fork. Then go to the settings for that repo, and copy the `Repo Token` identifier.
2. Log in to [CircleCI](https://circleci.com/login), go to `Add Projects`, click the `Set Up Project` button corresponding to your fork, and then click `Start Building`. (Aside from step 3 below, no actual set up is needed, since it will use the `.circleci/config.yml` file in 0x-monorepo, so you can ignore all of the instruction/explanation given on the page with the `Start Building` button.)
3. In CircleCI, configure your project to add an environment variable, with name `COVERALLS_REPO_TOKEN`, and for the value paste in the `Repo Token` you copied in step 1.
`master` represents the most recent released (published on npm) version.
`development` represents the development state and is a default branch to which you will submit a PR. We use this structure so that we can push hotfixes to the currently released version without needing to publish all the changes made towards the next release. If a hotfix is implemented on `master`, it is back-ported to `development`.
Now, when you push to your branch, CircleCI will automatically run all of the checks in your own instance, and the coverage check will work since it has the proper `Repo Token`, and the PR will magically refer to your own checks rather than running them in the 0x CircleCI instance.
<!--- The following points should be used to indicate the progress of your PR. Put an `x` in all the boxes that apply right now, and come back over time and check them off as you make progress. If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
* [ ] Prefix PR title with `[WIP]` if necessary.
* [ ] Prefix PR title with bracketed package name(s) corresponding to the changed package(s). For example: `[sol-cov] Fixed bug`.
* [ ] Add tests to cover changes as needed.
* [ ] Update documentation as needed.
* [ ] Add new entries to the relevant CHANGELOG.jsons.
[0x][website-url] is an open protocol that facilitates trustless, low friction exchange of Ethereum-based assets. A full description of the protocol may be found in our [whitepaper][whitepaper-url].
[0x][website-url] is an open protocol that facilitates trustless, low friction exchange of Ethereum-based assets. For more information on how it works, check out the [0x protocol specification](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md).
This repository is a monorepo including the 0x protocol smart contracts and numerous developer tools. Each public sub-package is independently published to NPM.
@@ -18,63 +18,74 @@ If you're developing on 0x now or are interested in using 0x infrastructure in t
[](https://gitter.im/0xProject/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
| [`0x.js`](/packages/0x.js) | [](https://www.npmjs.com/package/0x.js) | A Javascript library for interacting with the 0x protocol |
| [`@0x/abi-gen`](/packages/abi-gen) | [](https://www.npmjs.com/package/@0x/abi-gen) | Tool to generate TS wrappers from smart contract ABIs |
| [`@0x/assert`](/packages/assert) | [](https://www.npmjs.com/package/@0x/assert) | Type and schema assertions used by our packages |
| [`@0x/asset-buyer`](/packages/asset-buyer) | [](https://www.npmjs.com/package/@0x/asset-buyer) | Convenience package for discovering and buying assets with Ether |
| [`@0x/base-contract`](/packages/base-contract) | [](https://www.npmjs.com/package/@0x/base-contract) | BaseContract used by auto-generated `abi-gen` wrapper contracts |
| [`@0x/connect`](/packages/connect) | [](https://www.npmjs.com/package/@0x/connect) | A Javascript library for interacting with the Standard Relayer API |
| [`@0x/contract-addresses`](/packages/contract-addresses) | [](https://www.npmjs.com/package/@0x/contract-addresses) | Used to get known addresses of deployed 0x contracts |
| [`@0x/dev-utils`](/packages/dev-utils) | [](https://www.npmjs.com/package/@0x/dev-utils) | Dev utils to be shared across 0x projects and packages |
| [`@0x/fill-scenarios`](/packages/fill-scenarios) | [](https://www.npmjs.com/package/@0x/fill-scenarios) | 0x order fill scenario generation |
| [`@0x/order-utils`](/packages/order-utils) | [](https://www.npmjs.com/package/@0x/order-utils) | A set of utilities for generating, parsing, signing and validating 0x orders |
| [`@0x/order-watcher`](/packages/order-watcher) | [](https://www.npmjs.com/package/@0x/order-watcher) | An order watcher daemon that watches for order validity |
| [`@0x/sol-compiler`](/packages/sol-compiler) | [](https://www.npmjs.com/package/@0x/sol-compiler) | A thin wrapper around Solc.js that outputs artifacts, resolves imports, only re-compiles when needed, and other niceties |
| [`@0x/sol-cov`](/packages/sol-cov) | [](https://www.npmjs.com/package/@0x/sol-cov) | Solidity test coverage tool |
| [`@0x/sra-spec`](/packages/sra-spec) | [](https://www.npmjs.com/package/@0x/sra-spec) | OpenAPI specification for the standard relayer API |
Visit our [developer portal](https://0xproject.com/docs/order-utils) for a comprehensive list of core & community maintained packages. All packages maintained with this monorepo are listed below.
| [`0x-order-utils`](/python-packages/order_utils) | [](https://pypi.org/project/0x-order-utils/) | A set of utilities for generating, parsing, signing and validating 0x orders |
| [`0x-sra-client`](/python-packages/sra_client) | [](https://pypi.org/project/0x-sra-client/) | A Python client for interacting with servers conforming to the Standard Relayer API specification |
| [`0x.js`](/packages/0x.js) | [](https://www.npmjs.com/package/0x.js) | An aggregate package combining many smaller utility packages for interacting with the 0x protocol |
| [`@0x/contract-addresses`](/packages/contract-addresses) | [](https://www.npmjs.com/package/@0x/contract-addresses) | A tiny utility library for getting known deployed contract addresses for a particular network. |
| [`@0x/contract-wrappers`](/packages/contract-wrappers) | [](https://www.npmjs.com/package/@0x/contract-wrappers) | JS/TS wrappers for interacting with the 0x smart contracts |
| [`@0x/order-utils`](/packages/order-utils) | [](https://www.npmjs.com/package/@0x/order-utils) | A set of utilities for generating, parsing, signing and validating 0x orders |
| [`@0x/order-watcher`](/packages/order-watcher) | [](https://www.npmjs.com/package/@0x/order-watcher) | An order watcher daemon that watches for order validity |
| [`@0x/migrations`](/packages/migrations) | [](https://www.npmjs.com/package/@0x/migrations) | Migration tool for deploying 0x smart contracts on private testnets |
| [`@0x/sra-spec`](/packages/sra-spec) | [](https://www.npmjs.com/package/@0x/sra-spec) | OpenAPI specification for the Standard Relayer API |
| [`@0x/connect`](/packages/connect) | [](https://www.npmjs.com/package/@0x/connect) | An HTTP/WS client for interacting with the Standard Relayer API |
| [`@0x/asset-buyer`](/packages/asset-buyer) | [](https://www.npmjs.com/package/@0x/asset-buyer) | Convenience package for discovering and buying assets with Ether |
| [`@0x/sol-compiler`](/packages/sol-compiler) | [](https://www.npmjs.com/package/@0x/sol-compiler) | A wrapper around solc-js that adds smart re-compilation, ability to compile an entire project, Solidity version specific compilation, standard input description support and much more. |
| [`@0x/sol-cov`](/packages/sol-cov) | [](https://www.npmjs.com/package/@0x/sol-cov) | A solidity test coverage tool |
| [`@0x/abi-gen`](/packages/abi-gen) | [](https://www.npmjs.com/package/@0x/abi-gen) | Tool to generate TS wrappers from smart contract ABIs |
| [`@0x/tslint-config`](/packages/tslint-config) | [](https://www.npmjs.com/package/@0x/tslint-config) | Custom TSLint rules used by the 0x core team |
| [`@0x/types`](/packages/types) | [](https://www.npmjs.com/package/@0x/types) | Shared type declarations |
| [`@0x/typescript-typings`](/packages/typescript-typings) | [](https://www.npmjs.com/package/@0x/typescript-typings) | Repository of types for external packages |
| [`@0x/assert`](/packages/assert) | [](https://www.npmjs.com/package/@0x/assert) | Type and schema assertions used by our packages |
| [`@0x/base-contract`](/packages/base-contract) | [](https://www.npmjs.com/package/@0x/base-contract) | BaseContract used by auto-generated `abi-gen` wrapper contracts |
| [`@0x/dev-utils`](/packages/dev-utils) | [](https://www.npmjs.com/package/@0x/dev-utils) | Dev utils to be shared across 0x packages |
| [`@0x/fill-scenarios`](/packages/fill-scenarios) | [](https://www.npmjs.com/package/@0x/fill-scenarios) | 0x order fill scenario generator |
If you want to see helpful stack traces (incl. line number, code snippet) for smart contract reverts, run the tests with:
```
yarn test:trace
```
**Note:** This currently slows down the test runs and is therefore not enabled by default.
## Backing Ethereum node
By default, our tests run against an in-process [Ganache](https://github.com/trufflesuite/ganache-core) instance. In order to run the tests against [Geth](https://github.com/ethereum/go-ethereum), first follow the instructions in the README for the devnet package to start the devnet Geth node. Then run:
```bash
TEST_PROVIDER=geth yarn test
```
## Code coverage
In order to see the Solidity code coverage output generated by `@0x/sol-cov`, run:
```
yarn test:coverage
```
## Gas profiler
In order to profile the gas costs for a specific smart contract call/transaction, you can run the tests in `profiler` mode.
**Note:** Traces emitted by ganache have incorrect gas costs so we recommend using Geth for profiling.
```
TEST_PROVIDER=geth yarn test:profiler
```
You'll see a warning that you need to explicitly enable and disable the profiler before and after the block of code you want to profile.
```typescript
import{profiler}from'./utils/profiler';
profiler.start();
// Some call to a smart contract
profiler.stop();
```
Without explicitly starting and stopping the profiler, the profiler output will be too busy, and therefore unusable.
Example smart contracts that interact with 0x protocol.
## Usage
Contracts can be found in the [contracts](./contracts) directory.
This package contains example implementations of contracts that interact with the protocol but are _not_ intended for use in production. Examples include [filter](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#filter-contracts) contracts, a [Wallet](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#wallet) contract, and a [Validator](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#validator) contract, among others.
## Contributing
We strongly recommend that the community help us make improvements and determine the future direction of the protocol. To report bugs within this package, please create an issue in this repository.
For proposals regarding the 0x protocol's smart contract architecture, message format, or additional functionality, go to the [0x Improvement Proposals (ZEIPs)](https://github.com/0xProject/ZEIPs) repository and follow the contribution guidelines provided therein.
Please read our [contribution guidelines](../../CONTRIBUTING.md) before getting started.
### Install Dependencies
If you don't have yarn workspaces enabled (Yarn <v1.0)-enablethem:
Smart contracts that implement extensions for the 0x protocol.
## Usage
Contract extensions of the protocol can be found in the [contracts](./contracts) directory. This directory contains contracts that interact with the 2.0.0 contracts and will be used in production, such as the [Forwarder](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/forwarder-specification.md) contract.
## Bug bounty
A bug bounty for the 2.0.0 contracts is ongoing! Instructions can be found [here](https://0xproject.com/wiki#Bug-Bounty).
## Contributing
We strongly recommend that the community help us make improvements and determine the future direction of the protocol. To report bugs within this package, please create an issue in this repository.
For proposals regarding the 0x protocol's smart contract architecture, message format, or additional functionality, go to the [0x Improvement Proposals (ZEIPs)](https://github.com/0xProject/ZEIPs) repository and follow the contribution guidelines provided therein.
Please read our [contribution guidelines](../../CONTRIBUTING.md) before getting started.
### Install Dependencies
If you don't have yarn workspaces enabled (Yarn <v1.0)-enablethem:
Contracts that make up and interact with version 2.0.0 of the protocol can be found in the [contracts](./contracts) directory. The contents of this directory are broken down into the following subdirectories:
* [protocol](./contracts/protocol)
* This directory contains the contract interfaces that make up version 2.0.0. A full specification can be found [here](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md).
## Bug bounty
A bug bounty for the 2.0.0 contracts is ongoing! Instructions can be found [here](https://0xproject.com/wiki#Bug-Bounty).
## Contributing
We strongly recommend that the community help us make improvements and determine the future direction of the protocol. To report bugs within this package, please create an issue in this repository.
For proposals regarding the 0x protocol's smart contract architecture, message format, or additional functionality, go to the [0x Improvement Proposals (ZEIPs)](https://github.com/0xProject/ZEIPs) repository and follow the contribution guidelines provided therein.
Please read our [contribution guidelines](../../CONTRIBUTING.md) before getting started.
### Install Dependencies
If you don't have yarn workspaces enabled (Yarn <v1.0)-enablethem:
Contracts can be found in the [contracts](./contracts) directory. The contents of this directory are broken down into the following subdirectories:
* [libs](./contracts/protocol)
* This directory contains the libs.
* [test](./contracts/test)
* This directory contains mocks and other contracts that are used solely for testing contracts within the other directories.
## Contributing
We strongly recommend that the community help us make improvements and determine the future direction of the protocol. To report bugs within this package, please create an issue in this repository.
For proposals regarding the 0x protocol's smart contract architecture, message format, or additional functionality, go to the [0x Improvement Proposals (ZEIPs)](https://github.com/0xProject/ZEIPs) repository and follow the contribution guidelines provided therein.
Please read our [contribution guidelines](../../CONTRIBUTING.md) before getting started.
### Install Dependencies
If you don't have yarn workspaces enabled (Yarn <v1.0)-enablethem:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
