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:
{
"id": "/rootOrder",
"allOf": [
{
"$ref": "/customOrder"
},
{
"$ref": "/signedOrder"
}
]
}
/signedOrder
is the JSON Schema that will match any valid 0x orders./customOrder
is the custom schema passed in through theCUSTOM_ORDER_FILTER
environment 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.
{}
Orders with a specific sender address:
{
"properties": {
"senderAddress": {
"pattern": "0x00000000000000000000000000000000ba5eba11",
"type": "string"
}
}
}
Mainnet WETH <-> DAI orders:
{
"oneOf": [
{
"properties": {
"makerAssetData": {
"pattern": "0xf47261b00000000000000000000000006b175474e89094c44da98b954eedeac495271d0f",
"type": "string"
},
"takerAssetData": {
"pattern": "0xf47261b0000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"type": "string"
}
}
},
{
"properties": {
"makerAssetData": {
"pattern": "0xf47261b0000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"type": "string"
},
"takerAssetData": {
"pattern": "0xf47261b00000000000000000000000006b175474e89094c44da98b954eedeac495271d0f",
"type": "string"
}
}
}
]
}
Any ERC721 order:
{
"oneOf": [
{
"properties": {
"makerAssetData": {
"pattern": "0x02571792.*",
"type": "string"
}
}
},
{
"properties": {
"takerAssetData": {
"pattern": "0x02571792.*",
"type": "string"
}
}
}
]
}
Augur V2 orders:
{
"properties": {
"makerAssetData": {
"pattern": ".*${AUGUR_ERC1155_CONTRACT_ADDRESS}.*"
}
}
}
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.
Last updated
Was this helpful?