Loopring Relays: To Share Liquidity, Or Not To Share Liquidity…
Loopring is an open protocol for building decentralized exchanges. Its standards are ‘strict’ when they need to be, as in when interacting with its public smart contracts, and loose — like a blank canvas — in how it invites ecosystem participants to build on and elevate the protocol.
Loopring, like most lower-layer protocols, relies on developers, dApps and other network participants to create alongside the infrastructure itself. The best way to mobilize a group of enterprising agents, as usual, is to introduce economic incentives and give them the flexibility to pursue their own path.
One such ecosystem agent that is free to innovate and set up their own Loopring-enabled business are relays.
As a reminder, a relay is a network participant that hosts an order book for traders to interact with. By organizing and displaying an order book, the relay paints a picture of the market for a given token. Traders can look at this order book and create their own orders directly from the safety of their own compatible wallet. Thus, the relay is performing a fundamental role for the ecosystem: connecting/aggregating users and creating a liquidity pool. Orders are matched in order-rings, which are stitched together by ring-miners and allow circular asset transfer. Ring-mining is a feature of relays — or can be done by a separate participant. For their service, relays deserve and receive a fee; either LRx tokens or MarginSplit (a share of the traders’ discounts realized by order-ring price improvement). Relays receive 80% of the fees for orders they facilitate, while wallets receive 20%.
Loopring will attract relays and wallets who are profit-maximizing entities that seek to win user attention and order flow by providing the best service to users. This can be accomplished by offering users the ‘best’ web/mobile app, the cheapest fees, the sharpest UX, or by focusing on specific user types, asset types, strategies, and demographics.
However, perhaps the primary consideration for any relay to decide is if they will share the orders they gather with other relays built on the Loopring protocol, or go it alone.
I. Share orders/liquidity with other relays
In our opinion, the default answer is to share orders with other relays, as this takes advantage of the very nature of the network. If connected to each other, relays can bootstrap their order books much more quickly and more easily match orders. This is an obvious advantage: the greater the pool of orders, the more possible matches, and resulting fees/profits. Loopring makes it very easy to communicate and interact with other relays, and has built a consortium reference implementation that any relay will be able to join.
The protocol also lends itself towards order sharing by making some other specific decisions in its protocol construction:
- Non-custodial, non-committal orders: since users’ assets are not ‘stuck’ in an order once placed, orders are extremely flexible to be sent and shared with other relays. If balances are insufficient to execute/settle once an order-ring is matched, the fill amounts will be scaled down, or simply rejected.
- Dual-authoring for anti-frontrunning: our patented solution to prevent frontrunning is achieved without sacrificing the ability to share orders. By decoupling orders from specific relays while maintaining the security assurance against stolen orders/rings, orders can be safely shared without worrying about their hard work as a relay being in vain.
In addition, relays can build and manage their own consortiums or sharing networks. They are free to create rules which decide fee sharing, accounting for ‘how much work’ each relay did in facilitating order-rings, and optimized for providing the best user experience together. As such, they stand a better chance of providing deep liquidity, and giving centralized exchanges a run for their money!
For example, perhaps a consortium will be built by a group of relays operating in a specific country, focusing on security tokens, and jointly operate to respect their jurisdiction’s securities laws. They could choose to only allow relays into their network that satisfy certain regulations, such as KYC/AML.
Besides communicating with other relays, a relay can also communicate with other network participants such as dApps, wallets, professional market makers, full DEXs/CEXs, and more. Conjoining all these sources and sharing orders on some rails is one of the great promises of decentralized exchange protocols.
II. Don’t share orders/liquidity with other relays
With all the promise and excitement of the above, it may be hard to imagine why a Loopring relay would ever choose NOT to share orders with their peers. What gives?
Like all else in the cryptosphere, there is usually a tradeoff hiding somewhere. While sharing is caring and leads to boundless pools of liquidity, there is indeed a tradeoff here: performance. Performance is a bit broad, so we’d prefer to call it ‘control over the trading experience’. With order sharing comes the loss of perfect control in offering users a guaranteed execution environment.
Specifically, it is difficult to offer market orders — with guaranteed immediate execution — if orders are being shared across many relays and other network participants. This is due to the inherent delay between order placement and a transaction being mined into the underlying blockchain. It’s also possible that there are some ‘stale’ orders on a co-relay’s books, which haven’t been removed or updated frequently enough.
Thus, a relay who wishes to cater to a certain type of trader, such as more active/professional traders, would gain some benefits in overseeing the entire order book themselves. For example, if ‘LoopRelayOne’ controls the single pipeline delivering order flow to its books, it can keep closer tabs on active orders, and enforce price-time priority — the matching engine most of us are familiar with from centralized exchanges — AKA, first-come-first-served. By knowing which orders came in first, and not having to rely on the underlying blockchain’s mining delay, it can preemptively match orders and ensure execution, even before settlement of the blockchain transaction.
Loopring offers a relay pursuing this strategy tools to deepen their own order book while maintaining the same defenses against frontrunning. Dual-authoring has a variant called Key-Sharing which can allow a relay to be fed orders from multiple wallets while ensuring no other relay has access to these wallet-generated orders. By controlling a specific key pair that is not broadcasted in orders in the mempool, it precludes orders from being stolen by mischievous middlemen or block miners.
Of course, a relay operating on its own is asking users to place some trust. To be clear, the solution is still non-custodial, and there is no risk of theft/hacking, but there is the risk that the relay can ignore your orders, or front-run you by themselves. They essentially control the single order book. The deterrent to this is simply reputation and business risk, which we can presume they want to avoid. Whereas some users may prefer a completely trustless system, others would not mind this tradeoff to access the corresponding speed/performance improvements.
Collaborate or Compete?
Relays must decide on their business model, strategy, and who is their target user. By focusing on their business goals, they will have a clear sense of whether to collaborate or compete with each other, or perhaps form new consortia.
Remember that relays are only one part of the Loopring ecosystem, and other participants such as wallets will have to make the same decisions. Wallets will receive 20% of the fees from matched order-rings they facilitate and will want to optimize the user experience as well as their bottom line.
It’s worth noting that, previously, wallets have not had obvious means of making a profit, even though their interface with the underlying blockchain is a crucial part of the user experience. With Loopring, they are now empowered to build sustainable businesses through facilitating decentralized exchange. Will a certain wallet provider only send orders to a specific relay, to a group of 5, or to any and all relays? We are excited to see the novel solutions our community will build on top of our open protocol.
For more up-to-date information, join us on social media:
⭑ Twitter: twitter.com/loopringorg
⭑ Reddit: reddit.com/r/loopringorg
⭑ Telegram: t.me/loopring_en
⭑ Telegram: t.me/loopringfans (Chinese)
⭑ Kakao: open.kakao.com/o/gJbSZdF (Korean)
