ARC-105: Prepare Astroport for the Hub Transition

Summary

This proposal aims to mitigate the risk of IBC errors and other unforeseen issues that may occur during the Hub migration to Neutron. It achieves that by temporarily granting upgrade authority to the builder multisig on each outpost.

Abstract

Currently, the Astral Assembly holds authority over all outpost deployments via an IBC controller and IBC satellite contracts, where the satellite contracts are responsible for the upgrading and updating of all Astroport contracts on a specific chain. The Astral Assembly communicates with these satellite contracts through IBC channels, which are specifically whitelisted by governance. The next Neutron upgrade will enable features we need for xASTRO and this proposal aims to proactively mitigate risks that can arise during the move.

During the Hub move (i.e., transitioning the Astral Assembly from Terra to Neutron as previously proposed and approved), there will be a period where the Astral Assembly will simultaneously exist on two chains. However, on one of those chains, the assembly will not hold any voting power. During this time, Astroport will be at high risk if a governance IBC channel were to fail, as there would be no way for the adversely affected Astroport outpost to recover from that failure until the channel itself was recovered. This will essentially leave the outpost disconnected for a minimum of 7 days or until the next proposal passes, which could be extremely problematic -. This is a practical risk as we’ve had issues with IBC channels and messages failing in the past, requiring a re-submission and vote of proposals.

Most notably:

  1. The failure of ARC-85 to Neutron
  2. The failure of ARC-78 to Sei
  3. The failure of ARC-51 to Injective

To mitigate this risk, Astroport contributors propose that a temporary multisig is granted the power to upgrade and update contracts on all Astroport outposts, until the hub migration is complete. This process is expected to take a maximum of two months although we plan to have it completed within a month and will begin after the Neutron chain upgrade at the end of November. This will allow the contributors to continue the move and reconnect an outpost even if an IBC channel fails, without the delays inherent in governance.

Outline of IBC Transactions During the Hub Move

The following lists some of the IBC transactions required during the Hub move that would be affected by any IBC channel or relaying issues.

  1. Deploy Treasury on Neutron and mint new native ASTRO via IBC governance from Terra
  2. Deploy Staking and native xASTRO
  3. Deploy IBC controller on Neutron
  4. Temporarily disable Neutron Maker contract via IBC governance from Terra
  5. Migrate Neutron Satellite into Assembly via IBC governance from Terra
  6. Temporarily disable all generators via IBC governance from Terra to Neutron, Injective and Sei
  7. Enable new IBC connections on Injective and Sei via IBC governance from Terra to Injective and Sei
  8. Temporarily disable maker on Injective, Sei and Terra via IBC governance from Terra
  9. Create new IBC governance channels from Neutron
  10. Whitelist governance channels to allow Neutron to take control via IBC governance from Terra
  11. Migrate Terra Assembly to Satellite and whitelist IBC channel for Neutron to take control over Terra. At this stage Terra governance no longer has power over Astroport
  12. Deploy conversion contracts for old CW20 ASTRO to new TokenFactory ASTRO
  13. Set up emissions via IBC governance from Neutron
  14. Set new ASTRO denom on all outposts via IBC governance from Neutron to Terra, Sei and Injective
  15. Convert old CW20 ASTRO to new ASTRO on Terra and transfer back to Treasury on Neutron via IBC proposal

Multisig Information

The 2/3 multisigs to be used on each chain is listed below:

  • Sei: sei1g82rlvd3vwn3mfkgu7nge00pasm7d0ehgwc9rh
  • Injective: inj1fnumgs2wns8lra7zq36783set5cgud7l6dkf6v
  • Neutron: neutron1qlfhh69ydzznkq8vt5yawp7jzksnemf7lzy3kv
  • Terra: terra1ac5k25x29qw302wqfp8qh3zgtpxtumx8zfwl09

Executable Message

The first executable message for this proposal looks as follows:

[
  {
    "wasm": {
      "update_admin": {
        "contract_addr": "neutron1ffus553eet978k024lmssw0czsxwr97mggyv85lpcsdkft8v9ufsz3sa07",
        "admin": "neutron1qlfhh69ydzznkq8vt5yawp7jzksnemf7lzy3kv"
      }
    }
  }
]

The second executable message looks as follows:

[
  {
    "wasm": {
      "update_admin": {
        "contract_addr": "sei12fykm2xhg5ces2vmf4q2aem8c958exv3v0wmvrspa8zucrdwjeds2e2ntx",
        "admin": "sei1g82rlvd3vwn3mfkgu7nge00pasm7d0ehgwc9rh"
      }
    }
  }
]

The third executable message looks as follows:

[
  {
    "wasm": {
      "update_admin": {
        "contract_addr": "inj1rsrefjc7xnl6d6fm6avl706nu5y6nkpxffyevq",
        "admin": "inj1fnumgs2wns8lra7zq36783set5cgud7l6dkf6v"
      }
    }
  }
]

The fourth executable message looks as follows:

[
  {
    "wasm": {
      "update_admin": {
        "contract_addr": "terra1k9j8rcyk87v5jvfla2m9wp200azegjz0eshl7n2pwv852a7ssceqsnn7pq",
        "admin": "terra1ac5k25x29qw302wqfp8qh3zgtpxtumx8zfwl09"
      }
    }
  }
]

Copyright

Copyright and related rights waived via CC0.

3 Likes