TL;DR

• Speed, security and cost are the three key elements of swap transactions. In different scenarios, the priority of the elements differs
• For ordinary users, large Swap transactions are more likely to become the target of MEV attackers than small Swap transactions
• The ultimate speed and extremely low transaction costs are also the key to searcher’s leadership in competition
• Speed is the first element of Auto Snipe for Trading Bot

Introduction

Swap transaction refers to transaction of token exchange in DeFi. Unlike traditional trading system based on order book, it relies on automatic market makers(AMMs) to provide liquidity and is executed by smart contracts. Speed, security and cost are the three elements of Swap transactions. To different transaction originators, or one originator in different trading scenarios, the priority of the these elements vary.

The originators of Swap transactions can be simply divided into three types: User, Searcher and Trading Bot. Users send Swap transactions from mobile or web clients. Searchers calls smart contracts to send bundles including Swap transactions after capturing the arbitrage signal. Trading Bot automatically send Swap transactions after capturing the snipe signal.

This article attempts to analyze the trading scenarios of the above transaction originators based on speed, security and cost, to help transaction originators know about the best execution of Swap transactions on BSC.

Speed, Security and Cost

Before analysis, it is necessary to clearly define the speed, security and cost for each type of Swap transaction originator.

Speed

Speed is divided into signal capture speed and transaction inclusion rate.

Singal capture speed refers to the latency of capturing arbitrage signal. Low latency means that signal can be captured faster than competitors to win first-mover advantage. For Searcher, the signal could be the price difference between the pair of tokens on different exchanges; for Trading Bot, the signal could be the activation of the target token pair(Auto Snipe).

Transaction inclusion rate refers to the probability of a transaction being included in the very next block. For BSC adopting the PBS mechanism, the core idea of improving transactions inclusion rate is as follows:

• Route transactions to Builder with very low lantency

  When the transaction is verified by the RPC, it will be forwarded to the Builder. Since nodes of Builder are deployed globally, in order to reduce the latency of communication due to geographical location, RPC provider also needs to build a distributed network around the world, which synchronizes transactions with high-speed based on proprietary optimized network protocol, to acheieve low-lantency transaction forwarding across continents and oceans.

  

  Compared with RPC in North Americanin directly forwarding tx3 to Builder or Validator in European, the latency can be reduced by 50-200ms if first synchronize tx3 to the European RPC based on the QUIC protocol through the distributed network, and then forwarded to the Builder or Validator nearby.

• Improve the probability that transactions being forwarded to the Proposer

  In the EVM chain adopting PBS mechanism, the Proposer is responsible for producing blocks. Receving blocks from Builders, the Proposer selects the block with the highest value and synchronizes it to the Validator for verification and execution. In order to ensure that the transactions can be included in the block which wins the block aution, the transactions should be forwarded to the mainstream Builders on the chain.

  

  A single Builder does not have the absolute strength to win the block auction. If transactions are forwarded to a single builder, then the transaction inclusion rate is positively correlated with the Builder’s block production rate, which poses a risk of dependence.

• Increase gas fee

  The transaction gas fee is the basis of the block value. In the mainstream block construction algorithms of Builder, gas fee is the most important factor. If the gas fee is insuffcient, there is a risk that the transaction may not be included in the very next block. It should be noted that enough transaction fee can increase the transaction inclusion rate, but it will also increase the trading cost.

Security

Security means that a transaction is successfully executed on chain, while the transaction is kept private and the users' asset is protected from MEV attacks and losses.

When it comes to trading on chain, in addition to the notorious rug pull and phishing attacks, another attack method has gradually become known, which is the MEV attack. Unlike rug pull and phishing attacks, which launch attacks by defrauding users' trust, the target of MEV attacks is the transaction itself. The MEV attack bot continuously monitors the leaked transaction information in real time. If it is profitable, it will launch an attack transaction and let it execute in the expected order with the attacked transaction to obtain the underlying profit.

In the EVM chain under PBS mechanism, transactions are broadcast in the network of peers via P2P, which gives MEV attackers an opportunity to exploit

MEV attacks are mainly divided into sandwich, frontrunning and few malicious backrunning. Among them, sandwich attacks have the greatest impact on user assets, and Swap transactions are their main attack target. The attacker will insert a transaction before and after the swap transaction, buy the target token in the pre-transaction, raise the price of the target token, force the user to exchange the target token at the slippage limit, and sell the target token at a high price in the post-transaction to earn profits, while the user suffers slippage losses.

The root cause of the MEV attack is the full or partial leakage of transaction information, and the privacy of the transaction is not guaranteed during the on-chain process, the direct attack blocking idea is to send the transaction to the MEV-protected RPC, which will forward transactions to the next node of transaction routing through the private channel, to shield attackers from real-time monitoring and minimize the attack surface.

It should be noted that some MEV-protected RPCs will auction unauthorized disclosed transaction information based on business strategies. Due to the newly added attack aspects, transactions may be subject to single-block or cross-block non-atomic sandwich attacks, and even due to the additional layer of message visible entity, some transactions may be leaked to the public P2P node network, completely exposed to the MEV attacker's view.

Before the MEV solution that guarantees complete invisibility truly becomes the infrastructure of DeFi, transaction originators must seek trustworthy entities and try to minimize the disclosure of transactions during trading. For originators who have transaction disclosure requirements, they can send transactions to trusted MEV protection RPCs; for originators who expect transactions to be fully private on the chain, they can directly send transactions to Builders within a controllable range, which can reduce transaction delays by streamlining transaction links while ensuring full transaction privacy.

Cost

Cost refers to the cost of a transaction from submission to inclusion, which is mainly divided into transaction cost and non-transaction cost.

Transaction costs

For ordinary user, transaction costs refer to platform fee, gas fee and slippage losses caused by attacks. For Searcher who can control slippage losses, transaction costs mainly refer to gas fees; For Trading Bot, which send snipe transactions on behalf of users in the scenario of Auto Snipe, the transaction costs such as platfrom fees, slippage losses and gas fees are all borne by the user.

Non-transaction costs

Non-transaction costs refers to the infrastructure costs paid to improve the speed and security of transactions. Non-transaction costs are generally borne by project builder such as wallets, DEXs, and Trading Bots. For example:

• In order to reduce the latency of transaction routing, purchase a muil-cloud server to build a globally distribued network of RPCs.
• In order to improve the probability of the transaction being received by the Validator, pay to lift the API rate limit of mainstream builders.
• In order to enhance the security of transactions, access to the MEV-protected RPC and pay to lift the rate limit of API.

The analysis of transaction scenario

Users

Speed and cost are the elements of Swap transactions that users can intuitively feel. Increasing gas fees can improve the transaction inclusion rate, but it will also increase transaction costs and impact the transaction experience. It is the responsibility of wallets and DEXs to provide users with high transaction inclusion rate, and the method should be changed from passively increasing transaction costs(borne by users) to actively increasing non-transaction costs(borne by project builders).

While the transaction inclusion rate is guaranteed, the transaction cost can be further reduced.

In the scenario of large swap transactions, the slippage loss is greater than the gas fee, and the opposite is true for small ones. Suppose a user exchanges 600 USDT for 1 BNB on Ethereum, sets the slippage to 1%, and the gas fee is 0.0001 BNB, if the transaction is traded with the slippage limit due to MEV attack, the slippage loss will be 1 BNB *1% = 0.01 BNB, which is much greater than the gas fee; Assuming that a user exchanges 3 USDT for 0.005 BNB, the slippage loss in the same scenario is 0.005 BNB * 1% = 0.00005 BNB, which is much less than the gas fee.

In large Swap transactions, slippage losses account for a higher transaction cost, and users' slippage losses are the source of profit for MEV attacks. Therefore, large Swap transactions are more likely to become targets of MEV attackers than small Swap transactions. As a project builder, wallets and DEX can provide users with MEV-protected RPC to help users avoid slippage losses and reduce transaction costs.

While for small swap transactions, gas fee account for a higher transaction cost, and users are more concerned about how to save gas fee. The project builders can help users save gas fees in some special scenarios:

• Transaction revert: The transaction may fail to be executed on chain due to the failure of contract call, since the gas has already been consumed during the transaction execution, the gas fee can not be refunded.

• Transaction cancellation: At present, the common practice of cancelling transactions is to submit another transaction with same nonce but higher transaction fee, in an attempt to replace the original transaction and be included in a block, so as to achieve the effect of “canceling” the original transaction.

It is mentioned earlier that transactions in EVM chain will be broadcasting immediately after verification, resulting in RPC losing control of the transaction routing, and the subsequent nodes of routing are not responsible for the trading experience. The fees of reverted or cancelled transaction have to be borned by users.

For the above special scenarios, RPC can execute the transaction in advance, and if it is found that the transaction may fail to be executed, the transaction can be temporarily retained until the state change meets the execution conditions, and then sent to the Builder. The same applies to transaction cancellation.

Searcher

In addition to the alpha strategy, speed and cost are also key in the Searcher competition.

Compared with users, Searcher has more and higher requirements for the speed of swap transactions. In addtion to the ultimate transaction inclusion rate, Searcher also focuses on signal capture speed. Signal capture is a prerequisite for arbitrage, and the sooner the arbitrage signal is captured within a slot, the more transactions Searcher can arbitrage.

In the scenario of atomic arbitrage, where signals are generated from public mempool or private orderflows, Searcher can deploy bots near relays of high-performance network or RPC endpoint to subscribe to transactions with low latency, eliminating the impact of geographic location on communication.

In terms of cost, compared with users, Searcher bears not only transaction costs but also non-transaction costs, including the mentioned cost paid to improve the probability that transactions being forwarded to the Builder, with very low lantency. Searcher can access to MEV-protected RPC on BSC, which will forward the bundle to the mainstream builders to improve the transaction inclusion rate.

The transaction costs of Seachers can be simply divided into gas fees and bribe. The gas fee is equal to gasUsed * gasPrice, which is relatively fixed, and the bribe depend on the degree of competition between Searchers.

In the calculation of each arbitrage opportunity, assuming that non-transaction costs are not taken into consideration, arbitrage profit = arbitrage space - gas fee - bribe, and arbitrage profit greater than 0 can be regarded as an opportunity. When the competition is not fierce, Searcher expands its profit margin by reducing the bribe; when the competition becomes fierce, expecially in the case of atomic arbitrage where the signal is exposed, Searcher’s alpha strategy is evenly matched, and gas fees become even more important. Lower gas fees allow Searcher to calculate more arbitrage opportunities and increase the frequency of arbitrage. Currently, Builders of BSC already allow clients to sumbit 0 gwei transactions.

Trading Bot

In the scenario of Auto Snipe, Trading Bot needs to capture the activation event fo the target token pair at the first time with the ultimate signal capture speed. Meanwhile, due to the fierce competition, Snipe transactions must be included in the very next block, and the position within the block must be right after the transaction of activation of target token pair, otherwise users will buy the target token at a higher price than the competitors.

At present, the head Trading Bot has launched the feature of Block-0 Snipes, which supports appending Snipe transactions right after the transaction of activation of target token pair, and submitting these transactions to Builders as a bundle. The essence is to integrate the transaction value, improve the transaction inclusion rate, and utilize the atomization of the bundle to ensure the snipe transaction can be executed at the right position.

In view of this feature, Trading Bot can also access the sendBundle API provided by trusted MEV-protected RPC, which will protect snipe transactions from frontrunning and reduce non-transaction cost of lifting the rate limit of Builders’ API, since the bundle can be forwarded to the mainstream builders on chain.

Summary

Speed, security and cost vary in meaning and priority for different swap transaction initiators. Therefore, the needs of swap transaction initiators are also different in the above swap scenarios.

Speed, security and cost are the key elements of the trading experience for users. Wallets and DEXs can access full privacy mode of MEV-protected RPCs, which helps users avoid slippage losses by enabling MEV protection in large swap transaction and save gas fees in small swap transactions, while ensuring high trasaction inclusion rate.

Searcher and Trading Bot pursue the ultimate signal capture speed, and need to subscribe to mempool transactions or private orderflows with extremely low latency, while reducing the non-transaction cost generated by self-built high-performance nodes. It is recommended to access to professional high-performance network services.

In addition, since the low transaction cost can help Searcher expand the range of arbitrage opportunities, Searchers in BSC can pay attention to builders that receive 0 gwei transactions to consolidate the competitive advantage of strategy.