Making Swap a proper SNS canister

Governance SNS Project Governance
,
1

TL;DR. Upgrading Swap canisters is now overly complicated, as they are NNS-controlled. We propose to simplify the upgrade process by putting SNS Swaps under SNS control.

Background

When a new SNS is deployed, NNS’s “SNS-W” canister uses the latest blessed Swap wasm, just as it does for all other canisters comprising the SNS framework (Governance, Root, Ledger suite). However, an existing Swap doesn’t get upgrades when an SNS is upgraded. Instead, it is now only possible to upgrade Swaps using NNS’s InstallCode proposals. As a consequence, SNSes are not incentivized to, and practically never do upgrade their Swap canisters.

Furthermore, the Swap wasm hash is now a component of the SnsVersion structure, alongside Governance, Root, and the Ledger suite. When an UpgradeToNextVersion proposal is adopted on the SNS, the SNS always tries to go to the next version along the blessed upgrade sequence from SNS-W. But if the next step in the sequence corresponds to upgrading Swap, the SNS just pretends that the upgrade succeeded by bumping the SNS version, without doing anything useful. This makes the concept of SNS versions confusing, as the SNS itself often reports that it has a version that does not make sense from the perspective of SNS-W (which is the source of truth).

Problem statement

The status quo causes the following problems:

  1. Upgrading Swaps requires the NNS community to do a lot of manual work. It is sometimes necessary to upgrade swaps, e.g., to patch security bugs, migrate some data, and for switching from heartbeats to timers. However, upgrading all the existing Swaps requires elaborate testing (to justify that it’s safe to upgrade to the latest version, skipping all the historical versions) and even then is still a lot of work (since we have ca. 30 existing SNSes, each with its own Swap canister).

  2. This makes the SNS API versioning confusing. The order in which Swap canisters are upgraded is not enforced, so an SNS at a given version might run against almost an arbitrary version of Swap. This is a problem not just for community projects, but also for the SNS framework itself, as some “official” SNS features (e.g., treasury transfer limits) depend on the Swap API providing particular information in a particular format.

Proposed solution

The Governance team is proposing to make Swap controlled and upgraded by the SNS. Treating Swap like all other SNS canisters has a number of advantages. In particular, Swap’s wasm hash would become a meaningful component of the SnsVersion structure, and Swap upgrades would happen in a deterministic order, via SNS proposals.

Next steps

DFINITY is planning to propose to the following changes:

  1. Make SNSes control their respective Swap.

  2. Enable SNSes to upgrade their respective Swap canisters.

  3. Upgrade existing Swaps to the latest version (one last time via NNS proposals).

    Details: Proposal to Upgrade the Oldest Swap Canisters

5 Likes
2

Update regarding the 1st step in the plan above (Make SNSes control their respective Swap)

The NNS has adopted the first few proposal batches, so currently the following SNSs are already in control of their respective Swaps:

Done:

  1. BOOM DAO
  2. Catalyze
  3. DecideAI DAO
  4. Dragginz
  5. ELNA AI
  6. Gold DAO
  7. ICGhost
  8. ICLighthouse DAO
  9. ICPanda DAO
  10. ICPSwap
  11. Kinic
  12. Neutrinite
  13. Nuance
  14. OpenChat
  15. OpenFPL
  16. Seers
  17. Sneed
  18. SONIC
  19. TRAX
  20. YRAL

The proposals for the following SNSs are live, with voting ongoing:

  1. CYCLES-TRANSFER-STATION
  2. DOGMI
  3. EstateDAO
  4. ICPCC DAO LLC
  5. ICVC
  6. KongSwap
  7. Motoko
  8. ORIGYN
  9. WaterNeuron
  10. Yuku DAO

Note that many of the proposals for changing Swap controllership have been submitted independently by @krzysztofzelazko (https://dashboard.internetcomputer.org/neuron/5944070935127277981), resulting in some duplicates. DFINITY will evaluate these independently and vote in favor of adopting them so long as they are either useful (i.e., unique) or harmless (i.e., duplicates that can yield voting rewards).

To see all proposals related to the new Swap controllership, please refer to https://dashboard.internetcomputer.org/governance?s=100&topic=TOPIC_APPLICATION_CANISTER_MANAGEMENT

3 Likes
3

A few questions on this change. Currently it looks like some swap canisters are controlled by both the NNS Root and the SNS Root, and others are only controlled by the NNS Root.

Will there be a point in the future where some Swap canisters will be controlled by the NNS and others only by the SNS (NNS Root removed as controller), or will the NNS Root always be a controller of swap canisters to preserve backwards compatibility?

1 Like
4

it looks like some swap canisters are controlled by both the NNS Root and the SNS Root, and others are only controlled by the NNS Root.

Correct: the 20 Swaps from the “Done” list above are controlled by both the NNS Root and their respective SNS Root, which enables both the NNS and the SNS communities to adopt upgrades for those canisters.

This is an intermediate state; an upcoming version of SNS Governance, if adopted, will enable upgrading Swaps just like any other SNS framework canister.

Dfinity will then propose to revoke NNS control from all Swaps. If adopted, this will leave only the SNS Root as the controller of its respective Swap, completing the transition.

2 Likes
5

@aterga Can you give a 1-2 week heads up in this thread before you remove the NNS Root as a controller?

This is a breaking change for us, so we’ll need to modify some things on our end before this goes live.

I’d also imagine this would be a breaking change for other apps that had previous monitoring for their swap canisters.

2 Likes
6

Hi @icme ,

Thanks for asking — yes, there will be a 2-week notice that I’m going to post here, announcing that the NNS is expected to give up control over Swaps. As an early heads up, I expect this to happen by the end of this year.

2 Likes