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 makerFee and 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 feeBurnPercentage.
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 feeBurnPercentage can 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 feeBurnPercentage can 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.
I am a big proponent of dividend based token economy, which I think create stronger incentive for the whole ecosystem to grow where the more successful your “competitors” are, the more you are rewarded yourself. I believe the incentive to collaborate would be slightly lower in this kind of implementation compared to direct fee splitting (since direct gains would be higher, especially for smaller relayers that don’t posses many ZRX), but is definitely worth investigating.
Another thing I do like about security tokens is that they create a stronger incentive for agents other than relayers/exchanges to become active players in the governance of the protocol. For instance, if a handful of large relayers possess most of the tokens in the future, they could impose a “minimum stake” for new relayers to have access to the shared liquidity and this minimum stake value could be very high. This has the short-term advantage that existing relayers would see less competition. However, with dividends, it’s at their advantage to maximize the growth of the entire ecosystem. In addition, now you have other players that have a strong incentive to prevent such decisions, which could impair the growth of the ecosystem as well. Currently, since users don’t have an expectation of financial returns, they don’t have an explicit incentive to take part in the governance of the protocol.
I think the worst part of this proposal is that participants aren’t necessarily rewarded in proportion to the amount of work they put in (i.e there is a huge free riding problem). Overall I’m not a huge fan, but I thought it was an interesting way to avoid the “origin of fill” problem.
I think the most promising solution involves the use of BLS/Schnorr signatures. The main issue currently is that the original order and signature are always exposed, creating an incentive for users to bypass the fee split. With BLS/Schnorr signatures, an affiliate relayer can simply add its signature to the original. The new signature can be tied to both the affiliate and origin relayer without exposing the original signature. Both relayers would still need a prearranged agreement (could be a simple on-chain mapping of origin relayer => affiliate relayer => percentageSplit).
The main issue is that these can’t be efficiently implemented in Ethereum today, to my knowledge.
But the contract would need to be able to expose both the affiliate and relayer address in order to interact with them, correct? If the smart contract can do it, how could any third party not be able to? Nevertheless, what probably matter the most is that the taker will not be able to have a valid signature only containing the original relayer, unless he was able to found the original order without the affiliate’s help … but at that point no affiliate scheme would help.
Also, I believe you can use Schnor and/or BLS signature schemes since Byzantium. The former is relatively simple, but not sure about BLS.
You would know the addresses of both relayers, but you wouldn’t be able to get the original order signature without actually querying the origin relayer (and you would have to know which address maps to each relayer, which isn’t necessarily static).
BLS signatures are possible right now, although they are prohibitively expensive (our estimate for verifying one is ~ 400k gas). I haven’t seen anything regarding Schnorr signatures on Ethereum yet, but I’d be interested in taking a look if you could point to some resources.