How does aggregation work?

When we talk about the best router, we don't want to get two or three DEXs and a few bridges. Instead, we want to know all the possible options for transferring token A on chain X to token B on chain Y.

That's why we created our Via Router, aggregating more ‘DEXs, bridges, and chains than any other project, to ensure users can find the best routes, with the most liquidity and cheapest fees, to swap their tokens across chains

First, our router shows routes from more bridges and DEXs than any other aggregator on the market.

Generally, there are three ways to make any-to-any cross-chain transactions, and Via is one of the few protocols that supports them all:

  1. Make multiple transactions on different blockchains These are the routes provided by our partners Li.Fi, Socket.Tech and Rango. In the first transaction, you do the swap and bridge, and in the second (and sometimes the third), you do the swap on the target chain. This solution is safe but highly inconvenient due to the need to stay on the site for a long time to make the second (third) transaction, while the rate has not changed much. If the rate changes a lot, the transaction on the target chain with the to_token_amount promised earlier will fail, and the user will lose money for gas and will remain with an intermediate token. It is also worth noting that these aggregators have a complex slippage logic, which does not guarantee the receipt of the requested number of tokens, but only indicates a conditional slippage of 3% to each protocol. This means that if the slippage in the first and second transaction is equal to 3%, the total slippage will amount to 6%.

  2. Make one transaction through decentralized bridges that have integrated DEXs. This solution, offered by our partners deBridge and Symbiosis, ensures much faster, convenient, and safer transactions since the slippage tolerance is guaranteed. However, the final to_token_amount will be lower than what you would get with several transactions (there is a saving on external contract calls). Therefore, looking it from the point of view of the final amount of token received, this option is inferior to the one at point 1.

  3. Make one transaction through semi-centralized bridges, which will trigger a second transaction on the target chain. This solution is provided by our partners Rubic and XY. They have integrated DEXs into their bridges, which is much more convenient than making several transactions but sometimes less secure due to partial centralization. What’s more, these bridges make refunds in stablecoins if the slippage of the second transaction did not allow the transaction to be completed due to a conversion rate change.

Secondly, Via has the most advanced sorting for every taste

Unlike other aggregators, the Via interface will not only show all the available routes and highlight the best one in terms of the final amount of token received or the fastest one in terms of transaction time but also a comprehensive list of data-based characteristics and information about all available routes

  1. Smart sorting takes into account all possible variables, such as the cost of gas for approvals and transactions, the protocols fees, slippage, the security and decentralization of the third-party protocols we integrate, and more.

  2. Sorting by time: unlike other aggregators, we show the actual time of the route based on current historic data and not the approximate hard-coded time.

  3. Sorting by security considers the presence and novelty of audits, historical statistics on the successful execution of transactions, and decentralization.

  4. The maximum return shows the tokens received at the output, taking into account the most likely, minimum possible number of tokens the user can receive through the route (accounting for slippage). And also the most likely.

Thirdly, we are the only ones who figured out the cross-chain slippage

When you transfer large amounts cross-chain, you want to ensure that you don't lose a few percent on slippage. This can be hard to do with protocols because they have fixed slippage that cannot be changed. HOP, for instance, has a fixed 5% slippage rate.

That is why we devoted a great deal of effort discussing with other teams to understand how exactly their slippage mechanisms work. That allowed us to bring slippage settings into a familiar, user-friendly interface that will show the routes with the selected slippage.

Last updated