0x Mesh
Search…
latest
Getting started
Advanced topics
GraphQL clients
Contributing
Custom order filters
Mesh supports the creation of separate sub-networks where 0x orders that adhere to a specific schema are shared. Each sub-network is built around a custom order filter. The custom filter defines which orders are allowed to be shared within a sub-network. For example:
- All orders for a specific asset pair (e.g., WETH/DAI)
- All orders for non-fungibles (i.e., ERC721, ERC1155)
- All orders used by a specific DApp
A custom filter may be passed into Mesh as a JSON Schema via the
CUSTOM_ORDER_FILTER environment variable. Messages that contain orders that don't match this schema will be dropped. As a limitation, filtering is only possible by looking at the static fields of an order. So for example, it is not possible to filter orders by doing an on-chain check or sending an HTTP request to a third-party API. We don't expect that this limitation is going to be a problem in practice and it comes with the huge benefit of enabling cross-topic forwarding in the future (more on that later).New order and message schemas.
All orders must match the following JSON Schema:
1
{
2
"id": "/rootOrder",
3
"allOf": [
4
{
5
"$ref": "/customOrder"
6
},
7
{
8
"$ref": "/signedOrder"
9
}
10
]
11
}
Copied!
/signedOrderis the JSON Schema that will match any valid 0x orders./customOrderis the custom schema passed in through theCUSTOM_ORDER_FILTERenvironment variable.
Organizing the JSON Schema for orders like this means that
CUSTOM_ORDER_FILTER can be relatively small. It doesn't need to contain all the required fields for a signed 0x order. It just needs to contain any additional requirements on top of the default ones.Example custom order schemas
All orders:
The following
CUSTOM_ORDER_FILTER doesn't add any additional requirements. All valid signed 0x orders will be accepted. This is the default value if no custom filter is passed in.1
{}
Copied!
Orders with a specific sender address:
1
{
2
"properties": {
3
"senderAddress": {
4
"pattern": "0x00000000000000000000000000000000ba5eba11",
5
"type": "string"
6
}
7
}
8
}
Copied!
Mainnet WETH <-> DAI orders:
1
{
2
"oneOf": [
3
{
4
"properties": {
5
"makerAssetData": {
6
"pattern": "0xf47261b00000000000000000000000006b175474e89094c44da98b954eedeac495271d0f",
7
"type": "string"
8
},
9
"takerAssetData": {
10
"pattern": "0xf47261b0000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
11
"type": "string"
12
}
13
}
14
},
15
{
16
"properties": {
17
"makerAssetData": {
18
"pattern": "0xf47261b0000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
19
"type": "string"
20
},
21
"takerAssetData": {
22
"pattern": "0xf47261b00000000000000000000000006b175474e89094c44da98b954eedeac495271d0f",
23
"type": "string"
24
}
25
}
26
}
27
]
28
}
Copied!
Any ERC721 order:
1
{
2
"oneOf": [
3
{
4
"properties": {
5
"makerAssetData": {
6
"pattern": "0x02571792.*",
7
"type": "string"
8
}
9
}
10
},
11
{
12
"properties": {
13
"takerAssetData": {
14
"pattern": "0x02571792.*",
15
"type": "string"
16
}
17
}
18
}
19
]
20
}
Copied!
Augur V2 orders:
1
{
2
"properties": {
3
"makerAssetData": {
4
"pattern": ".*${AUGUR_ERC1155_CONTRACT_ADDRESS}.*"
5
}
6
}
7
}
Copied!
Where
${AUGUR_ERC1155_CONTRACT_ADDRESS} needs to be replaced with the Augur ERC1155 token used to represent the outcomes of their various prediction markets.As you can see by the above examples, JSON-Schema has support for regular expressions allowing for partial matching of any 0x order field.
Limitations
Nodes that are spun up with a custom filter will share all their orders with nodes that are either using the exact same filter or the default "all" filter (i.e., "{}"). They will not share orders with nodes using different custom filters (even if a given order matches both filters) because each filter results in a separate sub-network. Therefore, custom filters are most useful for applications where users care about a distinct subset of 0x orders.
If you wanted to connect two sub-networks with overlapping valid orders, you could spin up a Mesh node for each sub-network and additionally run a bridge script to send orders from one sub-network to the other. Longer term, we hope to add support for cross-topic forwarding, which will allow Mesh nodes to do this under-the-hood.