ARC-34: Allow Multi-Hop Swaps to Bypass the Spread Limit

Summary

Add new logic in the router contract to allow any max spread in multi-hop swaps.

Abstract

The current version of the router contract has a limitation when it comes to multi-hop swaps: it always enforces a maximum spread. This condition works fine for single hop swaps but it can cause multi-hop ones to revert even though the swap output for that particular path would have been the optimal one. For this reason, multi-hop swaps should be allowed to bypass the spread limit.

Motivation

The main motivation for this proposal is to improve the overall swap experience on the Astroport protocol. Currently, multi-hop swaps can revert due to the max spread limitation enforced at the router level. This happens even though certain multi-hop swaps are the optimal ones between two target tokens.

Proposed Code

The code for the new router contract version can be found here.

Test Cases

Test cases for the newly proposed implementation can be found here.

Security Considerations

The main risk associated with this proposal is that the router contract may stop working altogether.

Auditor Information and Report

There is currently no audit for this new version of the router contract.

Licensing

GNU General Public License v3.0

Governance Action

The executable message used to upgrade the router on Terra 2 mainnet (phoenix-1) looks as follows:

{
  "submit_proposal": {
    "title": "Upgrade the Router to allow multihop swaps to bypass the spread limit",
"description": "This update disables the max spread limitation on multihop swaps",
    "messages": [
      {
        "order": "1",
        "msg": {
            "wasm": {
                "migrate": {
                    "contract_addr": "terra1j8hayvehh3yy02c2vtw5fdhz9f4drhtee8p5n5rguvg3nyd6m83qd2y90a",
                    "new_code_id": 523,
                    "msg": "e30="
                }
            }
        }
    }
    ]
  }
}

Disclaimers/Conflicts of Interest

The author is a paid service provider of Delphi Labs Ltd. Additionally, the author has a development stake of ASTRO tokens.

2 Likes

Apologies if this is a dumb question but will this be for Classic and Luna2 or just one? Also, thank you for putting the time into this to advance the community :slight_smile:

This proposal is only aimed at the Terra 2.0 Astroport instance

Could you explain why you need to adjust the belief_price to MAX in order to bypass the max spread, instead of dealing with the max_spread parameter?

From my understanding the problem with dealing with the max_spread parameter is that it would require to upgrade pool contracts which would be a bigger pain, this way you only upgrade the router contract and even tho it’s setting belief_price to MAX which is what’s used to calculate spread, we just confirm the assertion of the min_received.

2 Likes