Fee sharing and networked liquidity in the matching model

There has been a lot of discussion about different ways to incentivize relayers to share liquidity (see ZEIP 12). Most of these discussion have been around using the open orderbook strategy. However, building these incentives for the matching model has it’s own parallel set of issues and is really a completely different problem.

This is an approach that relayers using the matching model could take to splitting fees (thanks to @wwarren for the original idea). This is already completely possible in v1 of the 0x protocol.

Alice and Bob are both relayers using the matching model. They agree to split fees off-chain in exchange for broadcasting each other’s liquidity. Charlie is a trader using Alice’s relayer. He sees one of Bob’s orders that he wants to fill, and requests the fees for doing so from Alice. Alice responds with a matching unsigned order that specifies herself as the feeRecipient but Bob as the taker. Charlie signs the order and sends it to Alice, who then sends the order to Bob (probably with a signature to prove the order is originating from her). Bob matches the orders, and both Alice and Bob receive some fee.

This can be made more efficient with atomic order matching or ZEIP 18, but is something that can be easily done right now. It can also easily be extended to include any number of relayers using the matching model.

The downside is that it doesn’t allow for much granularity in splitting fees, since Bob would only ever receive <= the makerFee of his own order (he wouldn’t receive anything from Alice’s order). It also means that Alice is relying on Bob to match the shared orders, which could create a poor UX if Bob refuses for any reason.

Thoughts? To relayers planning on using the matching model, would you consider splitting fees in this way?


I think one major issue currently the is not many relayers. How to incentivise bootstrapping new ones?

@benjyz how many relayers do you think are necessary? There are already 10-15 live on mainnet right now.

With meaningful volume - currently only Radar. I think having only 1 major one is bad for decentralisation.