Bridge Aggregation Technology
PreviousTech Stack: Leveraging Composable Finance’s Mosaic TechnologyNextStrategies: Yield Optimization and Portfolio Management
Last updated
Last updated
The following is adapted from an article published by our Lead Advisor, 0xbrainjar, written in collaboration with our founder 0xmoonscraper, and is available here.
To accomplish its cross-layer and cross-chain functionality, Instrumental has collaborated with Composable Labs to develop bridge aggregation technology which sources transfer routes from Composable’s Mosaic bridge as well as other available bridges from the broader DeFi community.
Bridge aggregation begins with data collection and representation. Specifically, information regarding the current network of bridges is sourced at a given cadence and a matrix constructed containing information about their speed, fee, liquidity, and more. Based on this, we built a graph representation of this network snapshot:
The first step towards a bridge aggregation algorithm is data processing and representation. We pose the problem in graph form and solve it using graph traversal. Nodes generally represent network-token combinations and edges are the available bridges supporting that route.
This completes the problem setup. The goal is now to traverse this graph in a way that is most optimal to the user. To do this, we seek to move the funds from A to B (say a Curve LP position from Arbitrum to Polygon) via a route optimizing an objective defined by the user. This objective may be the fastest route, cheapest route, or a combination of the two (think of picking a flight through a flight aggregator such as Google Flights). With Instrumental, we can provide historical information as well as what to expect in terms of speed and fees for a given route.
In general, there can be several options for bridges and routes to traverse for transferring funds from a source chain to a destination chain. Hence, it is crucial to have the most up-to-date version of the graph for the chains and bridging options. This can be handled in a way similar to The Graph where data — the bridge network — is collected and indexed. Once the latest network snapshot is available, the next step is to find the best bridges and route(s) to transfer the funds.
Our algorithm follows a two-step approach, where it will first find the best bridges for graph edges based on the criteria chosen by the user (such as fastest bridge, cheapest bridge, etc.) for a given asset to transfer (whether it is USDC, wETH, wBTC, etc.). In other words, the algorithm will first transform the multi-connected directional graph, known as a multigraph, to a uni-connected directional graph. The transformed graph will appear different based upon the distinct criteria selected by the user.
If a single bridge on a specific edge does not have enough available liquidity, a combination — or aggregation — of bridges could fulfill the requirement. For such cases, the algorithm will choose more than one bridge but will still transform that particular edge to a uni-connected edge with a cost function equal to the sum of functions of the selected bridges.
If the liquidity of multiple bridges on a specific edge does not sum up to the required liquidity needs, the algorithm will still consider them and will include that edge in the transformed graph. Later, in step two — route selection — the algorithm will take into account that available liquidity while picking the best route(s) for moving the funds.
Once the graph is transformed to a uni-connected directional network, the next step is to find the best route(s) based on the user’s chosen criteria. For this purpose, the algorithm will compute the k-shortest routes from the source to the destination chain using the transformed graph, where the value of k will depend on the level of graph connectivity.
To explain, for a densely connected graph a relatively high value of k can be used and vice versa. Furthermore, the objective of k-shortest paths will be to find paths with a minimizing cost function that could be a weighted sum of transfer fees and transfer speeds that can be tailored to user-specific requirements.
After computing the k-shortest paths, the algorithm will choose route(s) that satisfy minimized cost and liquidity constraints and will update the information about the available liquidity on each edge of the chosen route(s) accordingly.
The bridge aggregator framework can provide a user interface (UI) allowing people to set a number of transfer parameters such as maximum fee, desired speed, privacy, reliability and many more customizable settings based on their requirements. However, for less savvy users, the bridge aggregator will provide the following simple three options:
Cheapest: move funds while minimizing the (total) transfer fee
Fastest: move funds while minimizing the (total) transfer time
Best: move funds with a trade-off between transfer fee and transfer time
The UI will also display historical information regarding fees paid and time spent transferring funds. This can help the user decide whether saving money or saving time is most beneficial. Additionally, a comparison will be shown with all bridges considered for the transfer with their metrics displayed.
Instrumental has identified several areas for future work to enhance this bridge aggregator. A worthwhile direction may be to model the bridge aggregation as an Integer Linear Programming (ILP) problem with our parameters. Unlike the heuristic algorithm described above, the ILP model will jointly solve the bridges and routes selection in one step using a larger solution space; therefore, it will result in an optimal solution. A potential downside to this is that an ILP model would take a long time especially as the size of the graph becomes larger with new layer 1 (L1) and layer 2 (L2) chains and bridge solutions developed in the crypto ecosystem.
Another interesting area of future work will be to study the fee model of existing projects for bridging across chains. Based on the fee structures of these bridges, the algorithm can be tweaked to split the fund transfer among alternative bridges. We could then compare this to see if splitting that transfer further reduces the fee compared to when all the funds are transferred through a single bridge when enough liquidity is available at its minimum fee.
Additionally, in applications where the goal is to minimize the disturbance to any given bridge’s liquidity rather than minimizing the cost, it will be valuable to adopt a flow-optimization model to distribute the assets across even more bridges. Another hybrid solution to be examined is the combination of k-shortest routes and flow algorithms. This is possible by creating a sub-graph from the k-shortest routes and then running flow algorithms over the sub-graphs to find the best bridges with enough liquidity.
The bridge aggregator is at the core of Instrumental, and it is what enables seamless cross-chain and cross-layer LP position optimization. For Instrumental’s bridge aggregator technology, Mosaic is just one of the bridge sources we will leverage. In time, we plan to incorporate more of these bridge services. As we do so, we envision Instrumental to become a strategy hub for cross-chain and cross-layer arbitrage opportunities.
