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:
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).
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:
Make SNSes control their respective Swap.
Enable SNSes to upgrade their respective Swap canisters.
Upgrade existing Swaps to the latest version (one last time via NNS proposals).
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:
BOOM DAO
Catalyze
DecideAI DAO
Dragginz
ELNA AI
Gold DAO
ICGhost
ICLighthouse DAO
ICPanda DAO
ICPSwap
Kinic
Neutrinite
Nuance
OpenChat
OpenFPL
Seers
Sneed
SONIC
TRAX
YRAL
The proposals for the following SNSs are live, with voting ongoing:
CYCLES-TRANSFER-STATION
DOGMI
EstateDAO
ICPCC DAO LLC
ICVC
KongSwap
Motoko
ORIGYN
WaterNeuron
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).
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?
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.
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.
Application Canister Management Proposals:
135244 135243 135242 135241 135240 135239 135238 135237 135236 135235 135234 135233 135232 135231 135230 135229 135228 135227 135226 135225 135224 135223 135222 135221 135220 135219 135218 135217 135216 135215 135214 135213 135212 135211
Vote: ADOPT
Comments: There were a total of 34 proposals to revoke NNS Root control over SNS swap canisters. These proposals were under the Application Canister Management proposal topic. The CodeGov NNS known neuron typically follows DFINITY on this proposal topic, but current these proposals are very near the end of the voting period (2 - 38 hours). Therefore, I reviewed and voted manually on each of these proposals. I found no discrepancies between the summary and payload of each proposal based on a review of the root and swap canisters identified by a query of the root canister using the list_sns_canisters method. The NNS root was not listed as a controller in the payload of the proposal.
About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Indeed, these proposals were made by a community member, that they have the intended effect announced earlier, and so they didn’t need to be re-submitted by a DFINITY neuron.
That’s a detail that I didn’t realize when I was voting. Fortunately, you had posted that this change is planned with plenty of advanced notice. The proposals seem consistent with that plan. I’m glad DFINITY reviewed them as well and voted.
Now that I see who submitted these proposals, I’m not surprised.
Application Canister Management Proposals 135657
Vote: ADOPT
Comments: The CodeGov NNS known neuron typically follows DFINITY on this proposal topic, but current proposal has only 2 hours left in the voting period on a Sunday. Therefore, I reviewed and voted manually on this proposal. I found no discrepancies between the summary and payload of each proposal based on a review of the root and swap canisters identified by a query of the root canister using the list_sns_canisters method. The NNS root was not listed as a controller in the payload of the proposal.
About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
