The open orderbook relayer model benefits from very easily being able to share liquidity without permission from any other relayer. However it is very difficult to trustlessly split fees or create extra incentives for broadcasting another relayer’s orders.
The main issues with approaches outlined in ZEIP 12 are:
- Fee sharing is non-enforceable. The taker must voluntarily pass in the affiliate relayer’s address in order to split fees. However, this will always cost extra gas, creating a disincentive to do so. Since the taker always has access to the original order, it is very easy to bypass these extra gas costs.
- There are potentially trustless ways to split fees, but they are interactive, complex, and probably very gas inefficient.
One potential solution that can be implemented in a future version of 0x protocol is this:
Orders could contain a new parameter:
feeBurnPercentage. This percentage of both the
takerFee would be sent to a burn address when an order is filled, regardless of the origin of the fill. Relayers could decide to rebroadcast another relayer’s orders only if
feeBurnPercentage is greater than some threshold. Relayers who want to share their orders would set a higher
Assuming that relayers hold ZRX and/or are receiving ZRX from fees, they would have an incentive to rebroadcast orders from other relayers. A ZRX holder could theoretically make money without charging fees or hosting their own orderbook simply by broadcasting orders from other relayers.
The advantages to this approach are:
- It does not matter where the fill originated, which is arguably the hardest problem to solve trustlessly.
- It is very flexible, and
feeBurnPercentagecan be adjusted dynamically.
- It is simple and relatively gas efficient.
Potential problems with this approach:
- It is hard to measure direct economic impact of rebroadcasting orders.
- It rewards relayers who hold larger amounts of ZRX.
- Assuming relayers can only charge a maximum fee of X in order to stay competitive, they are now receiving a smaller percentage X. This might not be an issue, since
feeBurnPercentagecan always be 0.
Note that a similar strategy can be implemented in the current version of 0x protocol (v1). A relayer’s fee recipient address can be a deposit contract that burns some percentage of every withdrawal. The main difference would be that there is no good way for the relayer’s
feeBurnPercentage to be updated dynamically in this case. However, this may not matter if this number is not very volatile.