DEX, don’t front run me bro

Getting your Trinity Audio player ready...

This article is written by Joel Dejesus.

The Solana transaction submission process is susceptible to front running. Consequently, trading on DEX’s is much riskier, especially on leveraged products. Regtech companies can open a new revenue stream by analyzing the relationship between Bitcoin funds and network validators that process transactions. And finally, Solana validators should add front-running counter-measures into the protocol to ensure fairness for all participants.

TLDR

Market participants, in two ways, bear front running costs:

• slippage – front runners see an order and buy/sell the asset and flip it to the order submitter; the submitter loses some basis points 
• liquidation – front runners run liquidation bots that get priority over an order submitter attempting to fund his/her position

Market participants in DEXs assume that:

• transactions are entered into the blockchain as validators receive them 
• trading counter-parties do not operate validators 
• best faith effort is applied equally to all transactions

The FINRA has guidance on how order submissions are supposed to work in derivative markets. I assume that validators should be run under this guidance, for lack of a better reference point. 

These assumptions are impossible to verify to any degree with the current transaction submission process.

Technical

Solana is a proof of stake blockchain. Servers that process transactions are called validators. Roughly every two days, the leader schedule covering the next 48 hours is calculated by the protocol. Leaders are picked from among the validators.

To send a transaction, one must talk to a validator and ask who the leaders will be for the next few minutes. Based on this information, one then sends a UDP packet with the transaction to the current and future leaders. The sender must keep sending UDP packets until a block is published by a leader containing the target transaction.

There is no handshake nor confirmation that the validator has received a transaction in this process. Therefore, the optimal strategy to get a transaction into a block is to do the equivalent of a DDOS attack (see BIND DNS reflection attack) on the next set of leaders. This slows the network down greatly

Developers appear to be addressing “spam” transactions by implementing a handshake over UDP (QUIC protocol), to be followed up with a transaction fee market. However, this only addresses the shortage in transaction processing capacity and does not touch the front running issue.

Is it really happening?

I have no evidence that front running is happening on Solana DEXs. I am not a regulator. Moreover, front running on DEXs does not seem to violate any laws in any jurisdictions that I know of.

However, I have analyzed the incentive structure of validators and recent market events to deduce that there is an opportunity for front running.

Incentives

Validators suffer no penalty for rejecting transactions. No record is kept of rejected transactions, so it is difficult for market participants to build up reputation data on validators.

Transactions on Solana are not settlement-only transactions (movement of funds) like in Bitcoin. Transactions contain market orders that directly affect the profit and loss of market participants. The profits a DEX-trader can make by colluding with enough validators theoretically outweigh running a validator following CFTC rule 8.4.10~. For example, in NFT mint drops (…), one can net several thousand USDs in a few minutes of bot action

Solana development trends

Developers in Discord channels have discussed measures to curtail “spam” transactions by:

• filtering by IP addresses
• filtering by wallet addresses

This proves that at least some validator operators have a filtering program between the network and the validator itself. Therefore, it is not a stretch to assume that some validators prioritize transactions by more than just first in, first out.

Regtech

Great inroads have been made into enforcing AML/CFT on various blockchains. There are a plethora of tools available to market participants that allow one to plug in a blockchain address and get a clean score.

There are surveillance tools for conventional markets that detect suspicious transactions, which covers MAR.

However, it would be nice if I could plug in a DEX trading pair address and the leader schedule and get a front-running risk score (like a heat map?). And with digital currency trading firms applying to clear derivatives, I imagine regulators like the FSA in Japan and the CFTC in the U.S. would love to have these tools to gain context on the behavior of digital currency trading firms operating in DEXs.

Solana core developers

I would like to see (humbly so request) core developers in Solana explicitly state front run is an issue and take this into account when upgrading the transaction submission process.

Conclusion

I am a fan of Solana and am invested in its future success. However, I see front-running as a risk that could derail Solana. I hope this risk can be mitigated with some creative new features in the validator.

I take responsibility for the material written here and will be happy to make corrections if need be.

Follow CoinGeek’s Crypto Crime Cartel series, which delves into the stream of groups—a from BitMEX to Binance, Bitcoin.com, Blockstream, ShapeShift, Coinbase, Ripple,
Ethereum, FTX and Tether—who have co-opted the digital asset revolution and turned the industry into a minefield for naïve (and even experienced) players in the market.