Pact
Search…
⌃K

Smart Router

The initial launch of Pact on mainnet saw all swap executions routed to a single instance of a liquidity pool that the user manually selected. Users needed to manually choose the swaps with the highest TVL and deepest liquidity to ensure optimal results.
With the new Smart Router, Pact provides a more effective trade execution pathway, minimising price impact and slippage, resulting in the best possible pricing for traders.
Smart Router provides for:
  • Split Orders: The router can execute swaps across multiple pathways simultaneously, achieving better prices than any given single pool;
  • Advanced algorithm logic: The router incorporates advanced logic, which takes into account a more comprehensive data and parameter set to find traders the best price and most efficient trade path;
  • Improved efficiency through deeper liquidity: The router allows liquidity providers to focus on creating deep liquidity for common tokens (such as the ALGO native token and/or stablecoins) to improve overall efficiency. Contemporaneously, the router also allows traders to swap between two tokens that may not have their own native liquidity pool without the complexity of conducting multiple individual swaps;
  • Extensibility and true composability: The router is designed with true extensibility and composability in mind. On the one hand, developers and market participants can leverage the router to build applications and strategies on top of Pact. On the other hand, it also opens up the potential for Pact to route trades to other liquidity pools in future.

Split Orders

Smart Router achieves better pricing by splitting trades across multiple pools. Trades can now be split across up to four paths and up to three pools* to take advantage of liquidity depth in different pools.
For example, Smart Router can make ALGO/goBTC trade more efficiently. The router splits the trade across five pools using bridge tokens such as USDC and goETH, optimising the most efficient route.
Example: Smart Router User Interface showcases the split orders and routes to optimise the trade.
Notably, the split order is done simultaneously within a single transaction. This eliminates any slippage that interim market movements may cause should the individual transactions have been executed separately.
Route Limitations
The limitation of four paths is imposed by a constraint on the Algorand blockchain, which can currently only support 16 transactions in an ‘atomic’ group in a smart contract call. Each split order can take 2-4 transactions (below).
With four split orders, this can add up to a maximum of 16 transactions, as demonstrated below:
  • Opt-in to all ASAs in a route (only applicable if not already opted-in);
  • Deposit source asset (the asset that I want to swap);
  • Call to router contract for the swap;
  • Opt-out (only applicable if opted-in is required).

Advanced algorithm

To optimise for the most efficient route, the Smart Router considers multiple data points, including:
  • Liquidity levels of various pools (including those involving bridge tokens);
  • The fee tier associated with each pool;
  • Multiple potential candidate routes and varying splits.
For example, not every trade has a direct token pair; even if it does, it may be cheaper to use a bridge currency/token instead. For example, while tokens A:B might have a directly tradable pair, it is often cheaper to trade Token A → ALGO → Token B, if these pairs are sufficiently more liquid.
Smart Router also considers the fees associated with each pool. This becomes increasingly important as Pact liquidity providers continue to take advantage of Pact’s multiple fee-tiers feature to optimise their LP strategies across multiple fee-tier pools.
The algorithm is based on the Knapsack Problem, optimising the trade route with up to five paths across three liquidity pools. Given the negligibility of network costs on the Algorand blockchain, to simplify the logic, the algorithm is not currently network cost-aware.

Enabling efficiency through deeper liquidity for commonly traded tokens

Smart Router is also intended to facilitate the overall efficiency of trades. This is done by incentivizing and enabling liquidity providers to focus on creating deep liquidity for common tokens such as the ALGO native token and/or stablecoins.
As an illustration, users can efficiently trade from Token A to a stablecoin such as USDC with its execution routed through a deep ALGO/USDC liquidity pool. In this case:
  • Broader market participants are incentivized to provide liquidity for ALGO/USDC, not only because ALGO is a commonly traded pair with USDC but also because other tokens are likely to be traded to USDC.
  • Liquidity providers for Token A also benefit as they can provide liquidity for Token A and ALGO, relying on the router to direct trades to the ALGO/USDC pool. The liquidity provider will not be required to provide liquidity specifically for Token A and USDC.
Overall, all market participants should benefit from the efficiency optimisations provided by Smart Router.
Secondly, traders can now swap between two tokens that may not have their own native liquidity pool. Previously, traders may have needed to conduct multiple swaps across separate transactions, which have associated risks of failing the subsequent hops and leaving the trader with potentially unwanted assets. Smart Router provides this functionality in a single transaction and eliminates issues related to partial fills.

User interface

Smart Router is enabled by default for all users. Users can hover over the Smart Router icon to peak into your trade route. While not recommended, users can also disable Smart Router in the trade settings modal.

Extensibility and Composability

Smart Router has been designed with extensibility and composability in mind, turbo-charging Algorand’s market-leading capabilities. Anyone can now leverage Smart Router to develop various bespoke strategies and applications.
The overall architecture of the Smart Router consists of two components:
  • Smart Router Application Programming Interface (API), which incorporates the routing algorithm to find the optimal path for a particular swap;
  • Smart Router smart contract, which is responsible for determining the correct amounts to fulfil multiple swaps, and subsequently its transaction creation and execution (see True composability and atomicity below). The smart contract has an ABI-compliant interface for extensibility and sits as a proxy to the underlying exchange contracts to Pact’s liquidity pools.
The Smart Router API and Smart Router smart contract are public and can be used by anyone, including market participants and developers building decentralised finance (DeFi) applications.

True composability and atomicity

The Smart Router smart contract can be used by anyone and is uniquely designed to take a group of swap parameters in a single smart contract call. These parameters include:
  • Deposit amount;
  • Source assets and target assets (pools);
  • Minimum expected amount (applicable for the swap only).
This means you can compose multiple swaps without worrying about the complexities of making multiple calls for individual swaps.
To illustrate with a ‘triangular arbitrage’ swap from Tokens A -> B -> C -> A, the drawback of constructing multiple swaps individually without a router is identifying the output amount from each swap (e.g. A->B) and utilising this output amount in subsequent swaps (e.g. B->C). This can lead to failed transactions and remnants of tokens B and C in the user’s account. In other words, the router contract determines the specific amounts required to fully swap the required assets across multiple swaps.
The transaction is also guaranteed to be ‘atomic’, meaning that all swaps in the group are to be successful, otherwise, the entire group will revert and fail, further simplifying the complexity associated with making individual swaps, including opting in and opting out of ASAs. Other Automated Market Makers (AMMs) without an advanced router contract cannot facilitate these transactions.

For market participants and arbitrageurs

For market participants and arbitrageurs, developing strategies involving the execution of multiple swaps and integrating with other decentralised finance (DeFi) protocols, for example, via the use of flash loans, is uniquely enabled by Pact.

For Developers

For developers, leveraging Pact’s capabilities is as easy as utilising Smart Router API and Smart Router smart contracts.
Smart Router API: With Smart Router API, developers can retrieve the optimal route path when trading between tokens (see Example API Output below).
Smart Router smart contract: With the Smart Router smart contract, Pact has designed a compliant Application Binary Interface (ABI) that can be used and leveraged by other smart contracts and dApps. For example, this means that developers can:
  • Use custom route paths through the Pact liquidity pools Smart Router smart contract will handle the transaction creation and execution. An example of this use case may be finding an arbitrage opportunity within Pact liquidity pools. Developers can then call the smart contract with a circular route to execute the arbitrage trade. (e.g. if there is an arbitrage opportunity in ALGO/USDC/TREES triangle, developers can enter the route ALGO -> USDC -> TREES -> ALGO to execute it in one transaction).
  • Add custom transactions before or after the route Developers can also add custom transactions before or after the route and compose them in the same transaction group as the Smart Router smart contract. This allows expansive use cases like flash loans and other Decentralised Finance (DeFi) applications.

For liquidity providers

Pact’s user interface currently supports routing to whitelisted exchange smart contracts on the Pact platform. However, the design also enables Pact to expand this in future. For example, Pact can route trades to other liquidity pools from other AMMs, market makers and other partners in the Algorand ecosystem. Currently, the Smart Router contract supports contracts with the same interface as Pact’s exchange contracts, though while using the web app, the algorithm will only route to Pact pools.