Daniel Wang, our founder, has researched and developed an enhanced solution for front-running prevention called Dual Authoring. We have applied for patents and coded the solution into our smart contracts. This feature will be deployed as part of our 1.2 protocol release. We believe Dual Authoring will bring us a very good competitive advantage.

Front-Running in Decentralized Exchanges

“Front running is the illegal practice of a stockbroker executing orders on a security for its own account while taking advantage of advance knowledge of pending orders from its customers.” [wikipedia]

In decentralized exchanges, front-running is when someone tries to mine transactions, before mining other transactions that are already in the pending transaction pool (mempool). This can be achieved by specifying a higher transaction fee (gas price), and if the front-runner happens to be a miner he can order pending transactions in a way that benefits himself.

The major scheme of front-running in Loopring (and any protocol for order-matching) are order-filch and ring-filch. Order-filch is when a front-runner steals one or more orders from a pending ring settlement transaction, and ring-filch is when a front-runner steals the entire ring from the pending transaction.

Before continuing, it is worth mentioning that the default Loopring match-engine does not guarantee First-Come-First-Serve (instead, it uses the over-the-counter or OTC model), meaning that orders’ timestamps are totally ignored. This further implies that front-running a trade has no impact on the actual price of that trade — Loopring only supports limit-price orders.

Anatomy of Orders and Rings in Loopring 1.0 & 1.1

Orders and Signatures

Orders in Loopring are created by wallets and tools that can help to manage a user’s private keys. Orders are JSON snippets and are transferred to relays in the form of a JSON payload via APIs. Here is an example of an order in Loopring 1.0 release:

An Order in Loopring 1.0

Where the owner field represents the order’s owner_address from which tokens will be transferred once the order is filled. The order (including the owner_address ) must be signed with owner_address ’s private key. The order is valid only if the order_signature (represented by the r , v , and s ) is valid.

As illustrated by the diagram below, the order_signature is actually signed against the order’s hash (or order_hash ), which is the keccak256 function output of all other fields except r , v , and s .

A Order in Loopring 1.0 and 1.1

It is easy to compute the order_hash which is then used to verify whether the signing address is indeed the owner_address in the order or not. Relays will verify the signature of each order they receive; the Loopring Protocol smart-contract also verifies order signatures when 1) orders are submitted as part of a ring and 2) orders are submitted for cancellation.

Rings and Signatures

Rings don’t take a JSON form, rather, they are represented by all the parameters of the submitRing function provided by the Loopring Protocol. But if we visualize a ring, it will look like something below — it encapsulates all the data of its orders (a ring can have 2 to 10 orders). The miner of the ring will also populate its address (the miner_address ) and other mining parameters (or ring parameters) into the ring so that the submitRing function will behave differently based on these input parameters.