Problem with the incentives of the current GUI Provider fee system, and a proposed solution

Hi everyone. I’m CEO and Technical Director here at Global Liquidity.

My team and I are working on a new kind of order book level trading interface called TRADE : Serum, where our tagline is, “Automated Trading for Everyone.” The concept is that we bring simple algorithmic order fulfillment to end users, with a friendly real-time 3D “heads up display”.

TRADE makes it easy to be a maker, and not just a taker. Our “Smart Orders” allow you to do things like “join the bid” or “shave the bid” aka improve the price minimally. In coming months, we will add more complex automated trading features, including simple market making.

When starting out on this project, we were attracted to Serum’s “GUI Provider” fee system, which allows teams like ours to collect 20% of the Serum fees, on the trades made using our interface.

I see a problem with the incentive structure of this fee collection mechanism, and I have a general idea of how we might implement a fix.

Currently, the only way to collect fees, as a third party interface provider, is that you will receive 20% of the fees on all taker orders placed using your interface.

There are no fees for maker orders, so interface providers receive nothing when they facilitate a maker order.

Since most GUIS are best suited to placing market orders, this structure has been acceptable.

The trouble here, though, is that this fee structure serves to incentivize GUI providers only to keep making interfaces suitable for placing market orders, because fees are only collected on taker orders placed using the interface.

Our plan for TRADE is that it will bring everyone the opportunity to be a market maker, and to have access to modern algorithmic order fulfillment strategies. We see there will be a great demand for this sort of activity, as a next-generation form of yield farming. The problem is, that even as we succeed at this plan, our users will tend to be makers. This will be a feature of the advantage our users have over others armed only with market orders and traditional limit orders. Currently, we will collect no fees on the majority of the trades that we are facilitating.

This has caused me to consider that we may need to do all trading from on-chain bots, where we could implement our own fee structure, but it feels like this should be something that Serum’s core fee system should handle.

If a third party interface provider can make tools that simplify the process of adding liquidity to Serum, the provider should be incentivized by collecting some fee on maker orders placed using the providers interface or on-chain bot.

How would this work?

What if we update the fee system so that both maker and taker orders, placed by third party GUI providers, collect the same 20% fee.

This would mean that in some cases, two fees would be paid. This makes sense to me.

Think of this like a maker rebate where the rebate goes to the provider.

This could be paid for in one of two ways.

It could be deducted from Serum’s fee, so Serum would pay out 40% and not 20% of collected trading fees, when third party GUI providers are on each end of the trade. Alternatively, this fee could be passed through to the end user, so that maker orders cost the equivalent of the 20% fee needed to pay the provider. In cases where there is no third party provider, as with professional market making firms and others running program trading systems for their own wallets, these fees would be both paid and collected by the same user, so they would net to zero.

If a third party can bring lots of new maker orders into the system, by way of a new kind of interface, that third party should be incentivized to do it, and the overall effect on the Serum ecosystem could be dramatic, as automated trading on Serum sees mass adoption. Even if this means lower margins for Serum, because of an increased fee payout, the overall fee intake would increase many times over, because this new wave of “consumer” automated trading will see order volumes increase massively.

If there is another approach to this altogether, I’m all ears.

1 Like