SoroswapAggregator Technical Overview

Smart Contract Structure and Operation

The Soroswap-Aggregator smart contract is designed to optimize trade execution across multiple decentralized exchanges (DEXes) on the Soroban platform. The contract's primary function is to receive user trade requests, including the tokens to be swapped, the amount, and a distribution array that dictates how the trade is split across available DEXes.

Core Components

  1. DEX Registry: A dynamic list within the smart contract that maintains the addresses and interfaces of integrated DEXes. This registry allows the aggregator to interact with different liquidity pools directly.

  2. Swap Functionality: The core swap function which processes trades based on the input parameters:

    • fromToken and destToken: Addresses of the trading pair.

    • amount: The total amount of fromToken to be swapped.

    • minReturn: The minimum acceptable return amount in destToken.

    • distribution: An array specifying how the trade should be distributed across the DEXes.

Optimization Algorithm

The optimization algorithm plays a pivotal role outside of the smart contract, typically running off-chain due to its computational complexity. It analyzes current market conditions, including liquidity depth, gas costs, slippage, and DEX fees, to generate the optimal distribution array for a given trade. This array is then passed to the smart contract along with the swap request.

How the Optimization Works:

  1. Data Collection: Gather real-time data from each DEX in the registry regarding prices, liquidity depths, and fees.

  2. Scenario Analysis: Calculate the potential outcome of distributing the trade across different combinations of DEXes.

  3. Cost-Benefit Calculation: Evaluate the trade-off between transaction costs (including gas fees and DEX fees) and the benefits (minimized slippage and maximized returns).

  4. Distribution Generation: Output the optimal distribution strategy that offers the best return after all costs.

Smart Contract Execution

Upon receiving a trade request with the specified distribution, the smart contract performs the following steps:

  1. Validation: Verify that the sum of the distribution array matches the total amount to be traded and that the minReturn is achievable.

  2. DEX Mapping: Identify which DEXes correspond to each element of the distribution array using the DEX registry.

  3. Trade Execution: For each non-zero element in the distribution array, interact with the corresponding DEX's smart contract to execute the portion of the trade allocated to it.

  4. Result Aggregation: Collect and aggregate the results of each partial trade to ensure the total return meets or exceeds the minReturn. If the aggregation meets the criteria, complete the transaction; otherwise, revert all partial trades to protect the user from unfavorable execution.

Challenges and Considerations

  • Gas Efficiency: Executing multiple trades across different DEXes can be gas-intensive. The smart contract and optimization algorithm must prioritize gas efficiency to ensure the benefits of aggregation outweigh the costs.

  • Security and Risk Management: Interacting with multiple DEXes increases exposure to smart contract vulnerabilities. Rigorous security audits and continuous monitoring of integrated DEXes are essential.

DEX Management

Static Integration with Dynamic Address Management

  • Integrated DEX List with Admin-Controlled Updates: The Soroswap-Aggregator smart contract will feature a hardcoded list of supported DEXes, chosen based on their reliability, liquidity, and compatibility with the aggregator's objectives. This list includes specific functionalities and interfaces required to interact with each DEX, ensuring that swaps are executed efficiently and securely.

  • Dynamic Address Management: To retain the ability to respond to changes within the DEX landscape—such as contract updates, migrations, or critical protocol upgrades—the smart contract will implement a mechanism for dynamically updating the addresses of the integrated DEXes. This functionality will be restricted to an admin role, specifically designated to the contract's maintainers or developers.

    • Admin-Controlled updateDEXAddress Function: The contract will include an updateDEXAddress function, allowing the admin to update the contract address of any DEX in the list. This function requires two inputs: the identifier of the DEX (which could be an index or a name) and the new smart contract address for the DEX.

Key Considerations

  • Security and Integrity: The ability to update DEX addresses is a powerful feature that must be handled with the utmost care to maintain the aggregator's integrity and user trust. Measures such secure key management, and thorough testing of address updates are essential to mitigate risks.

  • Transparency and Accountability: Maintaining transparency regarding any changes made to DEX addresses is crucial. Detailed logs and justifications for each update should be readily available to users, ensuring accountability and maintaining confidence in the platform.

  • Monitoring and Verification: Continuous monitoring of integrated DEXes for updates or security advisories is critical. The admin team must have procedures in place to quickly verify and implement required changes to DEX addresses, ensuring the aggregator remains functional and secure against evolving threats.

Understanding the DexDistribution Struct

The DexDistribution struct is designed to instruct the aggregator on how to split and execute a swap across multiple DEX protocols. Each DexDistribution object contains three key pieces of information:

  • index: Identifies the specific DEX protocol where the swap will be executed.

  • path: Specifies the token swap path required by some DEXes, particularly useful for multi-hop swaps where a direct pair might not be available.

  • parts: Indicates how many parts of the total swap amount should be routed through this particular DEX protocol.

Example Explanation

Consider a scenario where a user wants to swap Token A for Token B, but to optimize the swap, the trade is split across two different DEX protocols, each possibly requiring a different path for the swap. The distribution for this swap might look something like this:

let distribution = vec![
    DexDistribution {
        index: 0, // Protocol 0, e.g., "Soroswap"
        path: vec![TOKEN_A, TOKEN_B, TOKEN_C], // Required swap path for Soroswap
        parts: 3, // 3 parts of the trade to go through Soroswap
    },
    DexDistribution {
        index: 1, // Protocol 1, e.g., "Phoenix"
        path: vec![TOKEN_A, TOKEN_C], // Required swap path for Phoenix
        parts: 2, // 2 parts of the trade to go through Phoenix
    }
];

In this distribution:

  • 3/5 of the total swap amount is routed through Protocol 0 (Soroswap), following the path [TOKEN_A, TOKEN_B, TOKEN_C].

  • The remaining 2/5 is routed through Protocol 1 (Phoenix), following the path [TOKEN_A, TOKEN_C].

Swap Execution Process

When executing the swap, the aggregator will:

  1. Calculate the Total Parts: Sum the parts from each DexDistribution object to determine the total number of parts the swap amount will be divided into. In this example, the total is 5 parts.

  2. Determine Amount per Part: Divide the total swap amount by the total number of parts to find out how much each part represents.

  3. Execute Swaps Based on Distribution: For each DexDistribution in the array:

    • Calculate the specific amount to swap through each protocol by multiplying the amount per part by the parts specified in the DexDistribution.

    • Execute the swap on the specified protocol (index) using the determined amount and following the provided path.

    • Ensure that each swap meets or exceeds any minimum output requirements and is completed before the specified deadline.

Key Points

  • The path allows for flexibility in handling swaps that require multiple hops, accommodating the specific requirements of different DEX protocols.

  • The parts attribute allows the aggregator to dynamically allocate the swap amount across different protocols, optimizing for factors like slippage, gas fees, or liquidity depth.

  • The index serves as a straightforward way to reference each protocol. While this example uses integer indices for simplicity, it's crucial in the actual implementation to map these indices to the specific smart contract addresses or interface methods required to interact with each DEX.

Conclusion

The Soroswap-Aggregator smart contract represents a sophisticated tool for optimizing DEX trades on the Soroban platform, requiring a carefully crafted balance between on-chain efficiency and off-chain computational complexity. The success of the aggregator hinges on its ability to dynamically adapt to the DeFi marketplace's fluidity, ensuring secure, efficient, and optimal trade execution for users.

PreviousSoroswapAggregator DesignNextPartners

Last updated