This particular route (swap) consists of two transactions. However, the number of transactions required for swapping different coins and across different chains may vary and depend on several factors such as the source coin, the destination coin, and the number of available addresses for signing transactions.
Step 1
In this step, we prepare the data for the chains and assets that our routing system supports. This data enables us to display the source and destination tokens to users and query and display swap route in the next step.
Query swap route. This query returns a tradesRoute collection, along with other properties. Based on this data, we can show the user which providers we will use, the amount of fees in dollars and assets for each transaction, and thus calculate the total fees and approximate transaction time in seconds.
chainName: This variable is obtained from step 1.1.
contract: This variable is obtained from step 1.2.
srcToken: This variable has the format ${chainName}.${contract} and represents the token to be swapped.
destToken: This variable also has the format ${chainName}.${contract} and represents the token to receive in exchange.
For native tokens, the format is ${chainName}.${nativeTokenName}. For example, Ethereum's native token is "ETH", so the format would be "ETH.ETH". For Polygon, it's "POLYGON.MATIC", and for Binance Smart Chain, it's "BSC.BNB".
slippage: This variable represents the percentage of slippage tolerance for the trade.
addresses: This variable is a collection of addresses available to sign transactions. For this swap, we only need one, as the trade takes place within the Avalanche chain.
destAddress: This variable represents the address that will receive the swapped Avalanche (USDT) upon completion of the trade.
amountSource: This variable represents the amount of Avalanche (AAVE) to be swapped.
infiniteApproval: Using this prop is not mandatory, but it allows users to avoid approving trades when swapping ERC20 tokens. However, it's important to note that the first approval still needs to be granted.
The mutation creates a new route and generates a unique routeId, which is essential for the subsequent steps to retrieve trades (transactions) related to the current route (swap). The input for this mutation is of type RouteInputTypeV2, and all the necessary properties are obtained from the response of the previous query.
To retrieve trades associated with a particular routeId, which is obtained as a response from the previous step, execute the relevant query. Note that the response to this query will change in subsequent steps, and therefore, it's necessary to periodically poll this query to keep track of the transaction statuses.
In this step, the query returns collections of two trades, both with null values for their status and txHash, as we haven't signed or broadcasted any transactions yet. The first transaction on the route can be signed and broadcasted. If a transaction property is not required by the current , its value is set to null e.g. property unsignedStdTx for bitcoin like transactions. In the next step, the tradeId field in the transaction is required to update the trade and track the transaction status.
The process of signing, broadcasting, and updating the trade is repeated for each transaction in the trades obtained from the previous step.
5.1 Sign and broadcast transaction to the network.
On this stage, we have a transaction prepared as a response to the previous step's query (TradesV2). We need to sign this transaction and broadcast it in order to obtain its hash.
Transaction hash
5.2 Update route trade by mutation that takes routeId, tradeId, transactionHash.
When we receive the broadcasted transaction hash, we update the trade by performing a mutation that allows us to track the transaction status and obtain the next transaction to sign.
Re query of trades (step 4) in this step returns different response.
The first trade now has a status of SUCCESS, indicating that the transaction has been confirmed, and the txHash has been assigned the value of the first signed transaction in step 5.2. Right after previous step the status of the transaction could be PENDING and transaction property gets null value. As for the second trade, it now has transaction data that needs to be signed, which we will do in the next step.
Continuously query (step 4) until all trade statuses show as SUCCESS. Once all trades have a SUCCESS status, the current swap is considered complete and the amount of Avalanche (USDT) will be transferred to the destination address.