In decentralized exchanges, there is no need to turn to a central authority for clearing, asset custody, or balance updates, because transaction settlement always takes place on-chain. Rather than interacting with a central clearinghouse or custodian, users publicly verify the outcome of trades on the blockchain ledger.

All decentralized exchanges feature on-chain settlement. An on-chain settlement is necessary to eliminate the need to trust a centralized exchange for asset custody, trade settlement, and to ensure that account balances are correct. It’s worth noting that while on-chain settlement eliminates many of the abuses that are possible on centralized exchanges, it makes DEXs susceptible to others.

The underlying mechanisms of decentralized exchanges open them up to attacks that in some cases look similar to those that can disrupt centralized exchanges, and in other cases are entirely unique to DEXs.

If, for example, multiple traders have spotted an arbitrage opportunity at the same time involving a trade between two cryptocurrencies on two different exchanges, they might both submit a transaction request to the Ethereum Network for the trade, creating a competitive bidding process among them to execute the transaction first.

This auction process creates a time delay between the moment a blockchain transaction is broadcast to the network and the moment that the same transaction is mined into a block and registered to the blockchain, a delay that gets longer when the network is congested with many transactions in the order queue. This makes certain kinds of abusive “attacks” on decentralized exchanges possible, which essentially consist of “frontrunning” transactions. 

Frontrunning in a DEX is both similar and different. In a DEX, an individual might observe a transaction after it is broadcast publicly to a network, but before it is finalized, and attempt to have their own transaction confirmed before or instead of the observed transaction. This can take the form of several kinds of attacks:

• Displacement attack: This exploit attempts to substitute a different transaction for one that has been identified as profitable. After discovering a transaction request in the order queue that could be profitable, a frontrunner sets the gas price for their transaction to be higher than that of the target transaction. By linking their transaction to a higher incentive, a front-runner can generally expect miners to give it a higher priority than the one they’re attempting to front-run.
• Insertion attack: This exploit places transactions between a potential transaction between two counterparties, extracting value from both sides of the original transaction. In this kind of an attack, a frontrunner sees buy and sell orders with a significant value spread as they’re published to the blockchain but before they’re finalized, and immediately attempts to buy from the trader selling at a lower price while selling from the trader buying at a high price. Without the insertion, the two counterparties might have settled their transaction at the midpoint of the spread; with the insertion, the attacker carves out the full spread as their own profit. While this type of insertion attack is “symmetric” (e.g., an attack that impacts two separate counterparties), there’s also an asymmetric form of the insertion attack: For example, if a trader who has an offer out to sell at a low price attempts to cancel that order due to rapid appreciation in the asset they’re trying to sell, a frontrunner can insert a quick purchase order to acquire the asset at the low price before the cancellation is processed, then turn around and sell the asset at the new higher market price.
• Suppression attack: This exploit seeks to temporarily delay the completion of other transactions while the frontrunner completes their profitable transactions. This can be done by entering a transaction with very high incentive and then flooding the market with a series of low-value transactions that are attached to relatively high incentives, which congest the system as miners complete them, ensuring that the frontrunner’s transaction clears without competition.

Ultimately, what we see is that the present-day version of DEXs solve some of the problems of centralized exchanges, mirror other ones, and introduce a few of their own. The difference is that in centralized exchanges, abuses can only be handled through regulation, investigation and enforcement — a process that requires a resource-intensive central body, which itself might be prone to abuse, to coordinate and carry out. By contrast, in DEXs, marketplace vulnerabilities can be addressed transparently and iteratively via open-source code — which means that if users encounter flaws in our present “DEX 1.0,” we can address them and constantly improve how DEXs operate in versions 2.0, 3.0 and beyond.