* abi-gen-wrappers: fix half-baked folder rename
* .circleci: give cache more descriptive name
* abi-gen: rename type field. tsName->langLocalName
* contract-artifacts: add devdoc to ERC20Token.json
Artifact changes crafted manually: re-generated artifacts from within
@0x/contracts-erc20, and then copied them into @0x/contract-artifacts,
but only committed the changes that added devdoc.
Modified @0x/contracts-erc20/compiler.json to include devdoc in the
hopes that next time contract-artifacts are re-generated en masse, the
devdoc output will just come along for the ride.
Compiling ERC20 TypeScript wrappers after adding devdoc to the artifacts
revealed some inconsistencies in the types. ethereum-types'
DevdocOutput REQUIRED many fields which are not always present,
depending the devdoc contents itself. Relaxing the requirement had some
ramifications.
* abi-gen: Python!
Lots more to come, but so far generating typed methods with some
parameter validation and with reasonable docstrings; enough to make
ERC20 work.
* existing erc20 python wrapper: re-order methods
In order to minimize the diff in the upcoming commit of the
auto-generated version.
* existing erc20 python wrapper: rename method
Rename method _erc20 to _get_contract_instance.
* existing erc20 python wrapper: rename vars
Rename method parameters to match names used in contract methods.
* existing erc20 python wrapper: correction
Contract method `allowance` previously was returning a transaction hash,
but it's a const method, so changed it to return the int that the
underlying method returns.
* contract_wrappers.py: pull in generated code
Custom setup.py command to pull in code previously generated into
../../packages/abi-gen-wrappers/src/generated-wrappers/py.
Changes to existing wrapper code reflect differences between the old,
manually-written wrapper and the new, auto-generated wrapper.
Reconfigured Circle CI to give Python build access to the output of the
TypeScript build, in order to import the generated wrappers from there.
* abi-gen: sanitize docstrings for pycodestyle lint
* abi-gen-templates.py: expose ABI from template
Use ABI given by template, not gotten by name from
zero_ex.contract_artifacts.
Also, expose ABI as a static method.
* py wrappers: contract addr to ctor, not methods
In all Python wrappers (old, manual ones; and new, generated ones), have
client pass the contract address to the wrapper's constructor, rather
than to the individual method calls.
* py wrappers: remove unused param `account_address`
* py wrappers: document use of `private_key`
* Rename file erc20_wrapper.py to erc20_token.py
To match the name of the underlying contract.
* Update CHANGELOG.json's
* git rm erc20_token.py
No need to keep it checked in. Doing so would require manual overhead
of keeping the generated copy in sync with the generation code, which
may get overlooked and cause confusion for others. Authoritative source
will be the published package on PyPI.
* abi-gen-templates: tweak CHANGELOG wording
Co-Authored-By: Fabio B <kandinsky454@protonmail.ch>
* Include transaction parameters in const calls too
* Doc contract_address param to gen'd wrapper ctor
* make myself a CODEOWNER of abi-gen*
* rename ids: langLocalName -> languageSpecificName
* Move Python generation to its own packages/ folder
* Stop duplicating contract artifacts in Python pkg!
Thanks to the way we're now using the `./setup.py pre_install`
convention, there's no longer a need to check the artifacts in to the
Python package.
* move py templates BACK to abi-gen-templates
I got a little overzealous in the previous commit that moved ALL the
python stuff into the new packages/python-contract-wrappers folder.
* Update known-good test output: prettify
* add getABIEncodedTransationData to gen'd code
It was added into the template in the following commit, but the
corresponding checked-in generated code was not updated accordingly.
f51c4f9617
* Fix missed instance of languageSpecificName change
* abi-gen: refine pipeline for testing gen'd code
- generate wrappers for test fixture contracts (dummy, etc) not in `yarn
build` but in `yarn test`
- rename folder test/generated-test/generated-wrappers to
test/generated-test/known-good, and stop writing test output to there,
instead writing it to a new test/generated-test/output folder.
- sol-compile test fixture contracts in every test run
- run unit tests separately from tests of generated and built TypeScript
wrappers. The existing `yarn run_mocha` will run unit tests, and
there's a new `yarn run_contract_wrapper_tests`.
* abi-gen: test Python gen [known test failures]
Also generate TypeScript wrapper test code into a TypeScript folder
(alongside the newly created Python folder).
Known-good code manually corrected (from generated code) to reflect
known problems that still need to be addressed. Namely:
- base contract and tx params should be imported from canonical
package, not relative path. relative path is working for wrapping
OUR contracts, but would not be usable in a more general
context.
- return type missing for some generated methods.
These outstanding problems are currently causing this test to fail.
* fix failing abi-gen test: missing return types
* fix failing abi-gen test: qualify imports
* in py wrapper, simplify base class initialization
per
https://github.com/0xProject/0x-monorepo/pull/1878#discussion_r299248641
* move 3rd party typings to typescript-typings
* make package python-contract-wrappers private
* make Xianny CODEOWNER of base-contract & templates
* abi-gen: clarify --help for --backend
* remove superfluous CHANGELOG entry
0x-sra-client
A Python client for interacting with servers conforming to the Standard Relayer API specification.
Read the documentation
Schemas
The JSON schemas for the API payloads and responses can be found in @0xproject/json-schemas. Examples of each payload and response can be found in the 0x.js library's test suite.
pip install 0x-json-schemas
You can easily validate your API's payloads and responses using the 0x-json-schemas package:
from zero_ex.json_schemas import assert_valid
from zero_ex.order_utils import Order
order: Order = {
'makerAddress': "0x0000000000000000000000000000000000000000",
'takerAddress': "0x0000000000000000000000000000000000000000",
'feeRecipientAddress': "0x0000000000000000000000000000000000000000",
'senderAddress': "0x0000000000000000000000000000000000000000",
'makerAssetAmount': "1000000000000000000",
'takerAssetAmount': "1000000000000000000",
'makerFee': "0",
'takerFee': "0",
'expirationTimeSeconds': "12345",
'salt': "12345",
'makerAssetData': "0x0000000000000000000000000000000000000000",
'takerAssetData': "0x0000000000000000000000000000000000000000",
'exchangeAddress': "0x0000000000000000000000000000000000000000",
}
assert_valid(order, "/orderSchema")
Pagination
Requests that return potentially large collections should respond to the ?page and ?perPage parameters. For example:
$ curl https://api.example-relayer.com/v2/asset_pairs?page=3&perPage=20
Page numbering should be 1-indexed, not 0-indexed. If a query provides an unreasonable (ie. too high) perPage
value, the response can return a validation error as specified in the errors section. If the query specifies a page
that does not exist (ie. there are not enough records
), the response should just return an empty records
array.
All endpoints that are paginated should return a total
, page
, perPage
and a records
value in the top level of the collection. The value of total
should be the total number of records for a given query, whereas records
should be an array representing the response to the query for that page. page
and perPage
, are the same values that were specified in the request. See the note in miscellaneous about formatting snake_case
vs. lowerCamelCase
.
These requests include the /v2/asset_pairs
, /v2/orders
, /v2/fee_recipients
and /v2/orderbook
endpoints.
Network Id
All requests should be able to specify a ?networkId query param for all supported networks. For example:
$ curl https://api.example-relayer.com/v2/asset_pairs?networkId=1
If the query param is not provided, it should default to 1 (mainnet).
Networks and their Ids:
Network Id | Network Name |
---|---|
1 | Mainnet |
42 | Kovan |
3 | Ropsten |
4 | Rinkeby |
If a certain network is not supported, the response should 400 as specified in the error response section. For example:
{
\"code\": 100,
\"reason\": \"Validation failed\",
\"validationErrors\": [
{
\"field\": \"networkId\",
\"code\": 1006,
\"reason\": \"Network id 42 is not supported\"
}
]
}
Link Header
A Link Header can be included in a response to provide clients with more context about paging For example:
Link: <https://api.example-relayer.com/v2/asset_pairs?page=3&perPage=20>; rel=\"next\",
<https://api.github.com/user/repos?page=10&perPage=20>; rel=\"last\"
This Link
response header contains one or more Hypermedia link relations.
The possible rel
values are:
Name | Description |
---|---|
next | The link relation for the immediate next page of results. |
last | The link relation for the last page of results. |
first | The link relation for the first page of results. |
prev | The link relation for the immediate previous page of results. |
Rate Limits
Rate limit guidance for clients can be optionally returned in the response headers:
Header Name | Description |
---|---|
X-RateLimit-Limit | The maximum number of requests you're permitted to make per hour. |
X-RateLimit-Remaining | The number of requests remaining in the current rate limit window. |
X-RateLimit-Reset | The time at which the current rate limit window resets in UTC epoch seconds. |
For example:
$ curl -i https://api.example-relayer.com/v2/asset_pairs
HTTP/1.1 200 OK
Date: Mon, 20 Oct 2017 12:30:06 GMT
Status: 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 56
X-RateLimit-Reset: 1372700873
When a rate limit is exceeded, a status of 429 Too Many Requests should be returned.
Errors
Unless the spec defines otherwise, errors to bad requests should respond with HTTP 4xx or status codes.
Common error codes
Code | Reason |
---|---|
400 | Bad Request – Invalid request format |
404 | Not found |
429 | Too many requests - Rate limit exceeded |
500 | Internal Server Error |
501 | Not Implemented |
Error reporting format
For all 400 responses, see the error response schema.
{
\"code\": 101,
\"reason\": \"Validation failed\",
\"validationErrors\": [
{
\"field\": \"maker\",
\"code\": 1002,
\"reason\": \"Invalid address\"
}
]
}
General error codes:
100 - Validation Failed
101 - Malformed JSON
102 - Order submission disabled
103 - Throttled
Validation error codes:
1000 - Required field
1001 - Incorrect format
1002 - Invalid address
1003 - Address not supported
1004 - Value out of range
1005 - Invalid signature or hash
1006 - Unsupported option
Asset Data Encoding
As we now support multiple token transfer proxies, 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 and decoding.
The identifier for the Proxy uses a similar scheme to ABI function selectors.
// ERC20 Proxy ID 0xf47261b0
bytes4(keccak256('ERC20Token(address)'));
// ERC721 Proxy ID 0x02571792
bytes4(keccak256('ERC721Token(address,uint256)'));
Asset data is encoded using ABI encoding.
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 more information see the Asset Proxy section of the v2 spec and the Ethereum ABI Spec.
Meta Data in Order Responses
In v2 of the standard relayer API we added the metaData
field. It is meant to provide a standard place for relayers to put optional, custom or non-standard fields that may of interest to the consumer of the API.
A good example of such a field is remainingTakerAssetAmount
, which is a convenience field that communicates how much of a 0x order is potentially left to be filled. Unlike the other fields in a 0x order, it is not guaranteed to be correct as it is derived from whatever mechanism the implementer (ie. the relayer) is using. While convenient for prototyping and low stakes situations, we recommend validating the value of the field by checking the state of the blockchain yourself, such as by using Order Watcher.
Misc.
- All requests and responses should be of application/json content type
- All token amounts are sent in amounts of the smallest level of precision (base units). (e.g if a token has 18 decimal places, selling 1 token would show up as selling
'1000000000000000000'
units by this API). - All addresses are sent as lower-case (non-checksummed) Ethereum addresses with the
0x
prefix. - All parameters are to be written in
lowerCamelCase
.
This Python package is automatically generated by the OpenAPI Generator project:
- API version: 2.0.0
- Package version: 1.0.0
- Build package: org.openapitools.codegen.languages.PythonClientCodegen
Requirements.
Python 2.7 and 3.4+
Installation & Usage
pip install
If the python package is hosted on Github, you can install directly from Github
pip install git+https://github.com/GIT_USER_ID/GIT_REPO_ID.git
(you may need to run pip
with root permission: sudo pip install git+https://github.com/GIT_USER_ID/GIT_REPO_ID.git
)
Then import the package:
import sra_client
Setuptools
Install via Setuptools.
python setup.py install --user
(or sudo python setup.py install
to install the package for all users)
Then import the package:
import sra_client
Getting Started
Please follow the installation procedure and then run the following:
from __future__ import print_function
import time
import sra_client
from sra_client.rest import ApiException
from pprint import pprint
# create an instance of the API class
api_instance = sra_client.DefaultApi(sra_client.ApiClient(configuration))
asset_data_a = 0xf47261b04c32345ced77393b3530b1eed0f346429d # str | The assetData value for the first asset in the pair. (optional)
asset_data_b = 0x0257179264389b814a946f3e92105513705ca6b990 # str | The assetData value for the second asset in the pair. (optional)
network_id = 42 # float | The id of the Ethereum network (optional) (default to 1)
page = 3 # float | The number of the page to request in the collection. (optional) (default to 1)
per_page = 10 # float | The number of records to return per page. (optional) (default to 100)
try:
api_response = api_instance.get_asset_pairs(asset_data_a=asset_data_a, asset_data_b=asset_data_b, network_id=network_id, page=page, per_page=per_page)
pprint(api_response)
except ApiException as e:
print("Exception when calling DefaultApi->get_asset_pairs: %s\n" % e)
Contributing
We welcome improvements and fixes from the wider community! To report bugs within this package, please create an issue in this repository.
Please read our contribution guidelines before getting started.
Install Code and Dependencies
Ensure that you have installed Python >=3.6, Docker, and docker-compose. Then:
pip install -e .[dev]
Test
Tests depend on a running instance of 0x-launch-kit-backend, backed by a Ganache node with the 0x contracts deployed in it. For convenience, a docker-compose file is provided that creates this environment. And a shortcut is provided to interface with that file: ./setup.py start_test_relayer
will start those services. With them running, the tests can be run with ./setup.py test
. When you're done with testing, you can ./setup.py stop_test_relayer
.
Clean
./setup.py clean --all
Lint
./setup.py lint
Build Documentation
./setup.py build_sphinx
More
See ./setup.py --help-commands
for more info.
Documentation for API Endpoints
All URIs are relative to http://localhost
Class | Method | HTTP request | Description |
---|---|---|---|
DefaultApi | get_asset_pairs | GET /v2/asset_pairs | |
DefaultApi | get_fee_recipients | GET /v2/fee_recipients | |
DefaultApi | get_order | GET /v2/order/{orderHash} | |
DefaultApi | get_order_config | POST /v2/order_config | |
DefaultApi | get_orderbook | GET /v2/orderbook | |
DefaultApi | get_orders | GET /v2/orders | |
DefaultApi | post_order | POST /v2/order |
Documentation For Models
- OrderSchema
- PaginatedCollectionSchema
- RelayerApiAssetDataPairsResponseSchema
- RelayerApiAssetDataTradeInfoSchema
- RelayerApiErrorResponseSchema
- RelayerApiErrorResponseSchemaValidationErrors
- RelayerApiFeeRecipientsResponseSchema
- RelayerApiOrderConfigPayloadSchema
- RelayerApiOrderConfigResponseSchema
- RelayerApiOrderSchema
- RelayerApiOrderbookResponseSchema
- RelayerApiOrdersChannelSubscribePayloadSchema
- RelayerApiOrdersChannelSubscribeSchema
- RelayerApiOrdersChannelUpdateSchema
- RelayerApiOrdersResponseSchema
- SignedOrderSchema
Documentation For Authorization
All endpoints do not require authorization.