Data Aggregation & Analysis Layer / Transaction Pool Formation
Last updated
Last updated
Please note that this is a basic explanation of the algorithm, and more complex processes occur behind the scenes to ensure optimal performance and security.
Transaction pool is a set of verified and validated arbitrage opportunities that are passed by Aggregation & Analysis Layer to Execution Layer for their Execution. The process of Transaction Pool formation is as follows: (i) Opportunities Identification; (ii) Opportunity Analysis & Validation; and (iii) Opportunities Prioritization.
First that Arbix takes into account when searching for relevant arbitrage opportunities is whether there is an opportunity as such, meaning whether there is profit to take. Depending on the stage of development of Arbitrage Engine it will also identify and tie to the actual opportunity the arbitrage type, and propose respective routing for it, which is further revised in the next stage of the algorithm. If it meets the opportunity criteria it passes the opportunity for further analysis & validation.
Arbix Arbitrage Math. Arbix uses the basic principles with several differences:
Infrastructure Costs and other expenses are covered by Protocol Fees, meaning that expenses are equal to transaction costs only;
There are no bridging fees due to parallel executions. On each operational network, there are respective pools to execute arbitrage from and receive profit to. Arbix softly rebalances these pools by leveraging Quotex features;
Protocol fees are taken as a percentage of the profit, which does not affect the profitability of arbitrage opportunities.
Therefore, Arbix math formula looks as follows:
Example:
Arbitrage contract detects an arbitrage opportunity involving Ethereum (ETH) on two exchanges on 2 different networks. It notices that the price of ETH on Exchange A on ERC-20 is $3,050, while on Exchange B on BSC, it's $3,000, revealing a $50 price discrepancy.
Planning the trade, Arbitrage engine decides to buy 1 ETH on Exchange B for $3,000 and sell it on Exchange A for $3,050.
The arbitrage engine calculates the costs involved: $3 in gas fees, $1 in transaction fees, and $0 for bridging from BSC to ERC-20, totaling $4. There are no bridging fees because Arbix uses parallel execution with multi-chain pools. Infrastructure costs are already included in the protocol fees, and there are no other expenses involved.
Automatically calculating the profitability of the trade, the Arbitrage Engine buys 1 ETH on Exchange B on BSC for $3,000 with its respective liquidity pool and sells 1 ETH for $3,050 on Exchange A on ERC-20 with another liquidity pool.
The profit calculation is as follows:
Despite the initial $50 opportunity, various costs reduce the final earnings to $46. Users receive a pro rata share of the profits based on their deposit, after Arbix deducts its fee from the net profit to cover infrastructure and operational expenses. This example also illustrates that it is more cost-effective for users to provide liquidity to Arbix than to perform arbitrage manually.
Further on this level of algorithm, the opportunity is being analyzed for: (i) profitability; (ii) minimum received criteria; and (iii) sufficient liquidity; (iv) routing.
Profitability. The opportunity is being analyzed as whether it is profitable, meaning that opportunity is greater than expenses.
“Minimum Received” Criteria. After calculating the expected profit, Arbix applies a “minimum received” practice to ensure conservative and secure trading. This approach establishes a lower boundary for the expected outcome of a trade, taking into account the highest possible slippage that could occur.
In practice, this means that the Arbix engine calculates the expected profit while considering a set slippage tolerance (for example, 0.1%). The algorithm assumes the worst-case scenario for slippage - essentially, the highest possible slippage within the set tolerance. By setting this conservative boundary, the system safeguards against unexpected losses due to slippage. Any actual slippage that turns out to be lower than the worst-case scenario simply results in additional profit, as the trade would exceed the minimum expected outcome.
This strategy ensures that even in less-than-ideal market conditions, the trade remains profitable or at least meets the minimum acceptable return, as well as that users are protected from adverse market movements while also allowing for the possibility of extra earnings if market conditions are more favorable than anticipated.
Sufficient Liquidity. The Arbitrage Engine performs a thorough analysis of order books and liquidity levels to ensure that each arbitrage opportunity is executed with maximum efficiency. The algorithm is designed to adapt to varying market conditions, particularly during periods of tighter liquidity or high market volatility.
In scenarios where liquidity is less abundant, the algorithm strategically opts for more frequent trades with smaller values. This approach helps to minimize any potential price impacts that could arise from executing large trades in low-liquidity environments. By carefully managing trade sizes and frequencies, the Arbitrage Engine ensures that arbitrage opportunities are capitalized on without disrupting market prices, thereby preserving the integrity and profitability of the trade.
Routing. After analyzing liquidity, the Arbitrage Engine revises the proposed routing by taking into account all previous analyses to check if there is a more optimal routing option available. This involves reassessing the potential paths for executing trades, considering factors like current market conditions, available liquidity, and potential risks. The algorithm evaluates all these details to determine the most efficient arbitrage routing, ensuring that the execution of arbitrage opportunities is both profitable and secure.
The logic behind the Arbitrage Engine algorithm ensures that users achieve maximized returns by efficiently using their liquidity. Its efficiency hinges on the rational use of users' liquidity, prioritizing the following criteria: (i) Net Profit, (ii) Complexity (including execution time, the number of actions required, type of arbitrage, and other factors), and (iii) Risks (selecting the most secure environment for executing arbitrage opportunities). It forms a Transaction Pool with arbitrage opportunities ranked in order of their priority, taking into account the mentioned criteria.
Based on these priorities, the algorithm in the Beta 1.0 version will prioritize transactions in the following order:
Most Profitable Opportunities. Transactions offering the highest net profit are executed first.
Simple Opporunities. If opportunities have equal profitability, on-chain arbitrage is prioritized over cross-chain arbitrage to minimize complexity and risk.
Low Risk Opportunities. If the remaining opportunities are either all on-chain or all cross-chain, the arbitrage engine will consider the trustability of the platform based on internal preset metrics and statistics of the venues.
After prioritization, the Transaction Pool is formed taking into account the amount of the available public liquidity in all Liquidity Pools.