Astroport, a cutting-edge Automated Market Maker (AMM) and Decentralized Exchange (DEX), offers two primary methods for swapping tokens: regular swaps and router swaps.
Regular swaps make use of the pool contract directly, allowing users to swap tokens in a straightforward and efficient manner. Router swaps, on the other hand, utilize the router contract to compute a custom path between two tokens that don't share a pool. This enables users to benefit from multiple trading pairs and liquidity pools.
To support these two types of swaps, the Astroport web app (app.astroport.fi/swap) leverages a custom backend architecture that determines potentially efficient swap paths that users may select to input into the router contract. This backend process includes the following steps:
- Data Retrieval: Retrieve all pools from the Astroport API.
- Graph Building: Build a token/pool graph using the retrieved pool data. This graph represents the relationships between tokens and pools.
- Route Computation: Compute all possible swap routes in the token/pool graph using a depth-first search algorithm.
- Route Storage: Save the computed routes in a database (e.g., DynamoDB) for future use.
- Route Retrieval: When users request a token swap, the platform retrieves the precomputed routes from the database.
- Swap Data Object: The UI outputs a data object that embodies the results of the route calculation, which the user can then choose to execute on through the user’s third party wallet (and the relevant blockchain’s validators) if so desired.
In this article, we'll dive deep into the backend architecture of astroport.fi and how it supports router swaps, algorithmically determining potentially efficient swap paths.
Retrieve Pool Data
The journey to determine swap paths begins with collecting information about all available liquidity pools on the platform. Liquidity pools are pairs of tokens that can be traded on the DEX. astroport.fi gathers this data from its API, which aims to store reasonably current information (programmed to update in real time based on onchain events) about the AMM’s on-chain state and available trading pairs. This allows building a graph to represent the relationships between tokens, which we'll discuss next.
Build a Graph
Once the pool data has been gathered, the astroport.fi backend proceeds to create a graph representing the connections between different tokens. In this graph, tokens function as nodes, while pools act as edges that link these nodes. The primary purpose of this graph is to model the relationships between tokens to make it easier to find potentially efficient routes for swapping assets.
Constructing this graph involves iterating through the list of pools and extracting information about the tokens involved in each pool. The backend then creates a "PoolEdge" object for each pool containing the pool's address, type, and the tokens involved. This information is used to build an adjacency list, which is a data structure that represents the graph by mapping each token to the pools it's connected to.
Compute All Routes
With the graph in place, the astroport.fi backend calculates all possible routes between every pair of tokens in the graph. This is achieved using a depth-first search (DFS) algorithm. A DFS algorithm is a way of traversing the graph by exploring as far as possible along each path before backtracking. This approach is designed to consider every potential route between tokens, allowing astroport.fi to find potentially efficient paths for swaps.
The DFS algorithm operates by marking a starting token node as visited and then exploring each of its unvisited neighbors. Once a neighbor has been visited, the algorithm recursively continues to explore its neighbors until it reaches the desired end token. When a route between the start and end tokens is found, the algorithm stores the route, backtracks, and proceeds to explore other potential routes.
To prevent infinite loops and optimize the search process, the algorithm employs a maximum depth (MAX_DEPTH) limit. This constraint ensures that the search does not explore routes beyond a certain depth, reducing computational overhead and improving efficiency.
During the DFS traversal, the algorithm also checks for duplicate routes by generating a hash for each route and storing it in a set. This allows the algorithm to keep track of unique routes and avoid storing duplicate paths, further enhancing efficiency.
Save the Routes
After all the routes have been computed, astroport.fi saves the results in a database for future reference. This step is crucial because it enables the platform to quickly access and provide the potentially efficient swap paths for users when they request a trade. By storing the routes, astroport.fi avoids the need to recalculate them for every new request.
Route Retrieval and Display
When users request a token swap on astroport.fi, the platform retrieves the precomputed routes from the database. The backend processes the request by identifying the user's desired input and output tokens and filters the available routes based on the user's preferences, such as slippage tolerance and maximum trade depth. After filtering, the platform displays the most efficient route to the user, showcasing associated costs, including any fees and price impacts.
Swap Execution and Confirmation
Once the user confirms the route and swap, the astroport.fi backend constructs a transaction data object that can be fed to the user’s third-party wallet application and, from there, broadcast to RPC nodes and validating nodes to implement the token swap, using the router contract with the chosen route. During this process, the backend identifies potentially efficient trading paths, adhering to the user's specified slippage tolerance and other constraints. After the swap has been executed by the user through the applicable third-party resources, a transaction receipt is generated by astroport.fi from on-chain data, confirming the details of the completed swap. This receipt is then displayed to the user as a record of the transaction, providing them with relevant information such as tokens exchanged, amounts, and fees incurred.
Risks/Assumptions
It is important to note that the swap routes produced by astroport.fi may not be optimal, are offered as an informational convenience only (not a warranty or promise of best execution and not advice) and should be used with caution. The route calculator assumes that the pool data and token prices are up-to-date, liquidity is sufficient, and slippage remains within tolerable levels. However, there is always a risk that the data could be stale due to network latency, sudden changes in token prices, or significant shifts in liquidity. Additionally, the algorithm's efficiency may be limited by the depth of the search, which could result in missed opportunities for more optimal routes. Ultimately, users are responsible for evaluating their own swap routes and deciding whether to use the astroport.fi swap calculator or perform their swaps in some other way.
Conclusion
astroport.fi determines swap paths by following a systematic approach that starts with gathering pool data, building a graph to represent token relationships, computing all possible routes between tokens, and finally storing the routes for future use. This intricate process allows the platform to provide users with potentially efficient trading routes to select for their swaps.
The depth-first search algorithm at the core of astroport.fi’s route determination process plays a crucial role in finding potentially efficient routes for token swaps. By implementing constraints like maximum depth and route hashing, the platform can optimize its search process and minimize computational overhead.
As a decentralized exchange, Astroport continually evolves to accommodate new tokens and liquidity pools. The process of determining swap paths must be periodically repeated to keep the platform's route information up-to-date.
DISCLAIMER
Remember, Terra 2.0, Injective and Astroport are experimental technologies. This article does not constitute investment advice and is subject to and limited by the Astroport disclaimers, which you should review before interacting with the protocol.
