Public Utility Canisters and the NNS - A rarely used veto option

[skilesare]

Getting Subscriptions back up

TLDR: See the heading “Suggestion 2” - I have given a lot of options here to show that I’ve tried to think through this issue thoroughly and I think this Suggestion 2 - Independent Install Canister that the NNS can occasionally, rarely veto an upgrade, is the most secure, least complex and invasive solution.

See: NNS Controlled Subscription Utility
See: Regarding NNS controlling application canisters

I apologize for it taking so long for me to get back to this issue, but as I’m back to the point where I’d like to get the subscription canister back online so that people can use it, I’d like to attempt to find a solution to the default REJECT votes on NNS-controlled canisters that are not “protocol level” issue. As the conversation unfolds, I would like to highlight several points and potential solutions that might help us move forward.

---

1. Understanding DFINITY’s Position

The dilemma DFINITY faces was made clear by Diego back when this was announced:

1. If DFINITY Abstains on NNS canister install/upgrade proposals, a malicious canister could repeatedly submit code-upgrade proposals that remain unresolved until their expiration and effectively stall (or at least slow down) the network’s emergency capabilities needed for upgrading the NNS.

2. If DFINITY Auto-Accepts, then malicious code could inadvertently be installed under the NNS’s authority—a risk that would undermine trust in the network’s governance.
   Because of these threats, DFINITY has decided to vote REJECT on canister upgrades unless they have personally reviewed and audited the code. However, DFINITY also emphasizes that they have limited resources and cannot feasibly audit every piece of code that might be proposed.

   …I’ll add the following that I’ve discovered through some conversations with folks at DFINITY…

3. If enough people don’t care about your canister and don’t govern it properly by following someone malicious, stupid, or ill-informed, or just disinterested or just not-voting, then the integrity of the NNS is brought down by successful attacks on NNS controlled Assets. This is bad for the network.

---

2. Why an SNS Isn’t Always a Viable Alternative

Some might suggest that developers should simply use the SNS to launch and govern their canisters rather than relying on the NNS. However, there are several reasons why an SNS may not be ideal for utilities or “protocol support” canisters:

1. Lack of a Sustainable Revenue Model

• An SNS is effectively its own DAO with a governance token. If that canister’s functionality does not generate meaningful fees or other revenue streams to support the DAO, the token’s value could stagnate near zero.
• In a scenario where the token has little real-world utility or demand (e.g., “governance only” with minimal user fees), it will be difficult to attract external interest or sustain development.

2. Limited Liquidity and Risk of DAO Capture
   • With low liquidity in the governance token, a small group of opportunistic investors or even a single whale could accumulate controlling stakes cheaply.
   • This creates a risk of governance capture—where a few participants can outvote everyone else and effectively control the canister’s code. We’ve seen precursors of these dynamics in early SNS projects like SNS-1 → Dragginz where one investor bought up more than 50% of the tokens.
3. Overhead
   • Even though the SNS can provide some decentralization, it also introduces “governance overhead,” more upgrade complexity, and the lingering question of whether enough participants will engage in (and pay attention to) its proposals. I believe it takes on the order of thousands of dollars a year to keep an SNS up and running with cycles at the moment.
4. Overkill for Simple “Protocol Support” Utilities
   • If a canister is meant to be a small, lightweight protocol utility, spinning up a new token-based DAO can be disproportionate overhead.
   • It fragments community attention and adds another token to the ecosystem—even when there is no real need for a separate token economy.
     It is a great solution for some things, but likely not for things like RPC canisters, subscription canister, etc.
5. Takeover
   • We’re already seeing some weakness in SNS governance as more and more are being taken over by 51% attacks. These operate as intended, I suppose, but it exposes the fact that securing DAOs has a time vector to it and if you don’t keep interest/value above a threshold forever, your DAO is exposed.

---

3. Potential Considered Solutions & Directions

Despite DFINITY’s valid concerns, there may be ways to preserve the security guarantees of the NNS while allowing developers beyond DFINITY to build “protocol support” canisters that the community can trust provided we get some clear answers on options from DFINITY. Below are some alternative approaches:

3(a). Use a Different Mechanism to Avoid Blocking the NNS

• Abstain via an Alternative Installer

  Instead of having the NNS directly install or upgrade user-submitted code, we could deploy a minimal “installer” canister that checks for a passed proposal on the NNS. The NNS would only vote on a) a “motion proposal” or b) “Install Code” proposal that targets a “blackhole” canister (i.e., a canister that always traps).

  • With a) a standard motion proposal is submitted with some kind of json config in the body (instead of using the InstallCode proposal type). The alternative install canister can treat this purely as a signaling mechanism. If the motion passes, an entirely separate minimal installer executes the upgrade.
  • With b) the upgrade call from the NNS itself would fail immediately (so it can’t stall the NNS), and the “installer” canister—when it sees the proposal pass—installs the code on the NNSs behalf. The Protocol Support canister would need to set this alt-installer as the sole controller.
  • Both a and b would prevent the stalling scenario and remove the impetus for DFINITY to “auto-reject” allowing them to abstain and let the NNS non-followers decide.
  • Another pro is that since DFINITY won’t vote on these, NNS users will either be forced to vote or update their following to ensure that they cast their vote and get their rewards. This could drive decentralization of the motion proposal topic
  • A con here is that if only a small subset vote on these than anyone controlling a significant amount of VP could attack your canister. This is likely more of an issue currently than it will be in the future.
  • Of course, we should consider the trade-off of extra governance proposals (voting fatigue), but this is hopefully addressed via liquid democracy and following. Community feedback is key here

3(b). Clarify the Definition (and Treatment) of “Protocol-Level Canisters”

If the community wants certain canisters (e.g., subscription utilities, exchange-rate feeders, EVM RPC canisters, etc.) to be recognized as “protocol-level” (or “protocol-support”) canisters, then:

1. We could define a governance path that marks certain user proposals as “Protocol Support.”
2. Those canisters could then go through a more formal review pipeline, perhaps with a community-led or third-party audit funded by a DAO or grants.
3. On completion, the community (including DFINITY) could recognize them as “protocol-level,” making them eligible for simpler or faster upgrade approvals under a documented process.

However, even if such a “protocol-support” classification exists, we still face the resource constraint: DFINITY cannot audit everything. This is where the community, independent auditors, or a dedicated code-review DAO might step in. Given that DFINITY currently moves a significant portion of the vote on things like they would have a virtual veto, but in the spirit of cooperation, I think it would be viable to separate high value initiatives worth funding out of the foundation at their discretion.

I feel like at some point entities other than DFINITY have to be able to provide protocol support canisters or we just won’t scale and we’ll have a hard time being taken seriously as we discuss our open protocol.

3(c). Define Requirements for “Sufficiently Audited” Code

Right now, no one knows what threshold of review would convince DFINITY to move from “auto-reject” or “heavy skepticism” to “abstain” or “accept.” Defining these criteria is crucial:

• Security Checklists or “Must-Have” Audits
  We could create a standardized security or audit checklist—tailored for Motoko and Rust.
• Community-Approved Auditors
  DFINITY (and the community) could recognize a panel of known auditors who maintain some track record of thorough code review in ICP-specific contexts.

If we had these requirements in writing, teams like ours (and future teams) could plan ahead for how to bring a canister up to standard.

3(d). Decentralizing the Voting Base

Another long-term path is to reduce the effective veto power that one large (or small group of large) voter(s) have over these canister upgrades. This is obviously an uphill battle: many neurons simply follow DFINITY, and re-routing them all to a broader set of delegates might take significant community organizing. Still, if the community wants more “yes” votes on user-proposed, high-value canisters, we need to improve the distribution of voting power and reduce reliance on single-entity follow.

3(e). Collect a group of interested parties and use Orbit to do multi-sig for upgrades

Unfortunately, this seems like the most likely immediate solution. The problem is, specifically with the subscription canister, I don’t know if I trust any small cabal of people with the 30 years worth of monthly payments from thousands of accounts. I know as an individual that I do not want to be personally responsible for that, probably not for 1/5th of that responsibility.

Broadly spreading the responsibility across all NNS voters with DFINITY abstaining and having the ability to step in with an upgrade veto during a 4 day vote if someone rings the alarm bells seems much more secure to me when we start talking about this kind of value.

---

4. Inheriting Security from the NNS vs. Creating an SNS

We would gain a lot by being able to rely on the NNS’s security guarantees, especially for canisters that govern significant value or hold sensitive logic (like subscription management). The SNS is often recommended as an alternative, but see section 2 above.

What I mean by “inheriting security”: Most eth L2s have an escape hatch that they put in. For example, on Optimism, when you withdraw your ETH back to the main chain, you have to wait 7 days. During that period anyone can contest the withdrawal and the withdrawer must provide a witness or will lose their ETH. I believe there may be another process through, which you can always withdraw your ETH even if the L2 is malfunctioning. Through this process Optimism is said to ‘Inherit the security of Ethereum’. I’d like a process by which we can do that on the IC such that our canisters can inherit the NNS’s security of at-stake ICP.

In a sense, we have this security since the NNS can install any canister if it wants to(see the taggr incident) but we have no practical mechanism to do so since DFINITY has closed the door.

Suggestion

Suggestion 1:

I’d suggest that abstaining from 1B above would be both the least complex and the easiest to roll back if we end up in a situation where the NNS is overwhelmed with proposals. @Lorimer would be able to use this as a solution to his Neuron management proposals as well. This at least gets my canister up and running and ‘controlled’ by the NNS the way I’d like and solves the NNS upgrade problem.

The only con that I see is that DFINITY stands to lose some maturity by abstaining.

Maturity Solution: Create a “Community Motion” topic that gets 0 credits toward maturity and that most of the community can ignore. This would put a burden on the person running the system to try to attempt to get more than 3% of the NNS to actually care, else they’ll never be able to pass anything.

Further Enhancement: I could also imagine an additional parameter to this topic that would allow a per community flag and thus people could follow on a per community basis…but this starts to gain complexity and I’d like to get the canister back up and running in weeks and not months.

These items would likely be very susceptible to the “overthrow” attack where someone with more VP than the small interested community could attack the canister.

Suggestion 2 ← This is what we will pursue unless there is significant push back:

Instead of asking for permission for upgrades, we will set up an upgrade canister that forces a 4-day window for pending upgrades and make this the controller of the canisters we want to be ‘public utility’ canisters. At any point during this window, a user may submit a veto motion proposal to the NNS. This is just any standard Motion Proposal but it has a payload that our install canister will look for. By filing this motion proposal with the install canister you can put the upgrade in limbo until the motion passes or fails.

Public Utility Canisters will self-govern which controllers can invoke an upgrade(as they already do), so not just anyone can trigger an upgrade. You, as the controller can manage this however you want and set up whatever transparent process you want. For example, “For upgrades we will post code 3 days before submitting an upgrade request; the NNS then has 4 days to file a Veto if they don’t like it.” All the NNS can do is veto that upgrade by someone staking some ICP into a motion to veto proposal(no extra work for the NNS team).

This lets non-SNSs define a process for upgrades that work for their applications and yet gives the full backing of the NNS when we need it. Someone wanting to block an upgrade will need to stake ICP, create the veto upgrade proposal, and make their case. If the NNS disagrees and rejects the motion, then they lose their ICP.

The pros

• The happy path will never bug the NNS. As long as upgraders stick to their word, publish their code, and act in good faith, and the community doesn’t go sideways, the should be no veto proposals and no votes.
• Pretty high on the permissionless scale.
• Significantly removes the incentive for someone to threaten my life or livelihood in exchange for ripping people off.

The cons

• handling of emergency upgrades to deal with bugs or stuck canisters. Plan B would be to beg the NNS taggr style to be more proactive. This would put some burden back on DFINITY.
• If the managing group goes so malicious(a blatent rug pull, refusal to post upgrade code as open source) that we reach some kind of stalemate where they keep trying to upgrade and the public (or some anon with too much time and/or money to burn) keeps trying to veto and winning it could get a bit chatty. I’ll have to think through how we might handle this without NNS intervention, but we can consider the happy path in the meantime.
• Dfinity may for some reason decide to always auto veto. I’d expect some significant justification as to why and I hope we can pursue this option with DFINITY at least abstaining.
• The owners of the controller of the public utility canister will still have some upgrade control and thus some amount of trust and ability to ‘pull a fast one’ if not enough people are paying attention. They are going to have to use something like orbit or a multisig toolkit to make the class to do the upgrade and this can be more tedious than one would want an more responsibility than one would want with a bunch of capital on the line(although the ultimate backstop of the NNS protecting me from being held at gunpoint or threat of financial terrorism and being forced to rob people blind is actually a huge relief)

---

Clarifying Questions For DFINITY

So a couple of direct questions:

1. DFINITY: Please let us know if one, both, or neither of these pathways are acceptable at the moment

A) Would DFINITY at least commit to abstaining to install veto proposals for publicly declared utility canisters that commit to open-sourced upgrades.

or

B) The Install Code proposal to a blackholed instant trap canister - Alternative Installer

or

C) Motion proposals with json in the body - Alternative Installer

If none of the above is acceptable

2. DFINITY: Please let us know if one, both, or neither of these pathways are acceptable at the moment

a) Please consider defining public guidelines for what an independent team must do for an audit or security checklist for DFINITY to move from “default reject” to “abstain” or “approve.” Without those guidelines, it’s hard to make forward progress.

or

b) Please consider allowing motion proposals to allow the NNS to designate certain projects as Protocol Support and advise on a budget that you all would make available for reviewing/auditing canisters or grants for trusted third parties that at least allow DFINITY to move to abstain.

Action Items for Others

1. Community: Please let your voice be heard on this subject.
2. Community: When and how do we start the push for more distributed voting authority on the NNS? This is not a short-term fix, but a necessary piece of the puzzle if we want to allow more third-party “protocol-level” canisters under NNS control in the future.

Thank you for putting up with this wall of text. We’re all trying to solve the same challenge: letting the Internet Computer evolve safely and permissionlessly—yet without letting malicious proposals hijack the NNS or degrade trust. The good news is: we have several alternative paths. I look forward to hearing more ideas and moving the discussion into tangible next steps.

[borovan]

The Problem with the “Veto Model”

The original proposal suggests replacing DFINITY’s review process with an opt-in veto window for NNS-controlled upgrades. This approach introduces several flaws:

1. Security Theater
   A 4-day veto window assumes the community is engaged enough to detect and reject malicious upgrades in real time. History shows this is not the case—most voting follows DFINITY, and many neurons do not participate at all.

2. Shifting Risk to Users
   By bypassing DFINITY review, the proposal effectively transfers upgrade security risk to NNS voters—without compensation, coordination, or adequate tooling. The idea that protocol-level security can be crowd-sourced in 96 hours is dangerously naive.

3. Opens the Door to Exploitation
   Defining vague “public utility” canisters, controlled by self-selected actors, creates a pathway for future abuse. Once precedent is set, bad actors can replicate the same process under the guise of legitimate infrastructure.

4. Undermines Network Trust
   The Internet Computer’s trustworthiness is rooted in DFINITY’s reputation, engineering, and principled governance. Weakening DFINITY’s role through informal upgrade systems dilutes that trust—and invites comparison to other chains where security is optional.

[Lorimer]

@skilesare

I feel like at some point entities other than DFINITY have to be able to provide protocol support canisters or we just won’t scale and we’ll have a hard time being taken seriously as we discuss our open protocol.

I think this is an important point.

However, it’s hard enough to incentivise voters to take an active role in reviewing existing protocol infrastructure changes. Perhaps this needs tackling first?

Something I’m not clear on is how the canister does in fact inherit security from the NNS. There’s a risk that is just appears to do so (but doesn’t).

[skilesare]

Sure…certainly some problems, but its the least number of problems I’ve found across the solution space so far.

1. Agree 100%. If we don’t have proper tools and/or enough interested people then it doesn’t work. It would be up to the application developer to ensure that this hurdle was overcome, otherwise users would be foolish to engage with it. I think in the short term this may only work if DFINITY abstains from these votes(which causes a maturity problem). Working some proactive ways to bootstrap over the ‘give a damn’ hurdle.
2. Hmmm…“The idea that protocol-level security can be crowd-sourced in 96 hours is dangerously naive”…and yet we do it every day on the NNS. Certainly not super well, given the recent evidence, but we have secured 2B+ of value for 4 years(yes, mostly because of DFINITY’s hard work and dedication, see 4). DAOs either work or they don’t. Maybe they don’t. As far as timing, what time period would you suggest? The current proposed window is actually a full 12 days. Announcment → 4 day wait → File upgrade → 4 day wait → If a veto up until the last minute → 4 day vote. These types of canisters are, hopefully, unlikely to be upgraded that often, so a month review would not be out of line unless someone discovered an active security issue.
3. This is a problem across crypto. We don’t have immutability or f,orkability which some other systems use to avert the bad actor problem, but no one really does it well. We can all dox, kyc, and sue each other in court, but that doesn’t seem very crypto of us. I’m certainly open to solutions here, but I think if we wait to solve this problem, no one will ever release anything ever again. Con-men gonna con-man.
4. This seems to be two different statements.

The first, “Undermines Network Trust” is one statement, and yes, if the application does not pass the ‘give a damn’ test where enough people on the NNS care enough to actually govern it and no one cares enough to actually raise a veto when a malicious one comes in there it just doesn’t work. Working on a “give a damn” solution for that, but provided it passes that hurdle the next step would be to argue that any issue irrelevant to 100% of NNS voters is not an issue that the NNS should be addressing because it would undermine network trust. This might actually be a strong argument if it was what the NNS was doing, but it isn’t. We vote on subnet selection, which only a few people care about and know enough about to vote. We vote on replicas, which is important to everyone, but almost no one is an expert. We vote on SNS, which surely not everyone cares about. We even have do-nothing motion proposals that rarely touch everyone’s interest. To an extent, governance is about crowd-sourcing governance of small things to a wide range of people to attempt to provide enough oversight to keep everyone in line and collect enough network intelligence that things don’t go off a cliff. One could argue that to the extent “we’ve” governed anything is all handwavey theater because DFINITY has actually governed it all. That brings us to statement 2.

“The Internet Computer’s trustworthiness is rooted in DFINITY’s reputation, engineering, and principled governance.” That is very straightforward statement. If we have two epochs :

1. DFINITY is the Internet Computer
2. The DFINITY Foundation is a major contributor to the Internet Computer blockchain

Which Epoch are we in now?

1. If you want to say we are in 1, then fine…I’ll accept your criticism that this would undermine their trust because they are wholly responsible, in which case we are still dependent on DFINITY for scaling and anyone building anything useful outside of a dapp should just stop and let DFINITY do it.
2. If we are in 2 then I’d wholeheartedly disagree and state the obvious that the NNS has to stand as its own, separate from DFINITY, scale without DFINITY, and this will demand building and deploying things not built by DFINITY and independent of their “reputation, engineering, and principled governance”. Now, in this epoch the NNS better damn well step up and take on that mantle and demand that level of rep, engineering, and principled governance.
3. If you’d like to argue that we’re still in 1 and when ready we’ll move to 2, then I’ll move my argument there and ask if this veto system would be a good way to bootstrap important functionality that one day may become core functionality of the network when we get to epoch 2 and if we should start now or wait. My to-do list is long, I can loop back to this later(although I’d argue that subscriptions would be a pretty good thing to add to the network now).
4. If your argument is that epoch 2 doesn’t exist and we will never get there because this is “our” playground and we’ll never give it up and we’ll never let you play in it and only DFINITY can scale and only DFINITY can contribute for all times ever…well…ok then. But that would be disappointing…and why all the theater…just give them the keys. “other chains where security is optional” would be the exact definition of this.

Thanks for the thoughts…they are helpful and have forced me to think more about this ‘give a damn’ problem.

[skilesare]

@Lorimer

Something I’m not clear on is how the canister does in fact inherit security from the NNS. There’s a risk that is just appears to do so (but doesn’t).

I’ll grant that it would inherit the full extent of the security as it is unlikely that everyone would care enough to pro-activley govern it, but, as above, I’d argue that is true of many of the topics the NNS governs. The fact that the NNS would have the ability to stop a malicious upgrade certainly implies that it would inherit some of the security of the NNS in certain situations. The veto solution minimizes that surface area to reduce complexity, spammyness, and demand on DFINITY resources and solves the technical NNS stall problem better than some of the other solutions I’ve seen. The alternative is ‘trust me bro’. Open to other solutions that are better.

@Lorimer

However, it’s hard enough to incentivise voters to take an active role in reviewing existing protocol infrastructure changes. Perhaps this needs tackling first?

I think our right and that this may have to be part of the solution…I’m thinking through it. This is always going to be dependent on the use case. In the case of the subscription canister, I think I can draw a pretty straight line from initial incentivisation to organic governance and just need to find the right pen to draw the line.

[borovan]

We’re trying to bootstrap decentralized infrastructure without the institutional mechanisms that actually make decentralization work. The veto model is clever, but it leans too hard on the assumption that:

1. Someone will care enough to veto malicious proposals in time
2. Voters will be informed, incentivized, and engaged
3. Partial NNS oversight = “inherited security”

In practice, most neurons follow DFINITY. If DFINITY abstains, and no one else steps up, this model appears decentralized while being trivially capturable. That’s not a theoretical risk — it’s happening across DAOs everywhere.

“Security theater” isn’t a personal insult — it’s a technical term for when the perception of safety masks the absence of real enforcement.

If we want the NNS to govern protocol infrastructure, then great — let’s build:

• Shared audit requirements
• Transparent upgrade pipelines
• On-chain accountability for controllers

If we don’t, then let’s not pretend “anyone can veto” is meaningful assurance. A 12-day delay is not governance if no one is watching.

I fully agree that Epoch 2 — where the NNS is independent of DFINITY — is the goal. But if we build on soft mechanisms, we may get the illusion of decentralization without the integrity. And that’s worse than doing nothing.

[skilesare]

@borovan

If we want the NNS to govern protocol infrastructure, then great — let’s build:

• Shared audit requirements
• Transparent upgrade pipelines
• On-chain accountability for controllers

This is where I’m ending up as well. I think I’ve solved the problem DFINITY had with the original ‘let the NNS install canister’ problem, but I am left with these to ponder. They have to be addressed and tooled if we want any hope of methods achieving their purpose.

[lara]

Hi all,

we’ve discussed this internally and DFINITY currently has the following view on canisters under NNS control:

• DFINITY only adopts upgrades of canisters that it has reviewed
• DFINITY is OK with abstaining from voting for other canisters upgrades if this helps certain use cases from the community (with a condition explained next).
• Due to the current security risk that NNS root can have open call contexts and be un-upgradable, DFINITY would like to limit the above to only canisters that are hosted on the more secure fiduciary subnet.
• Consequently, DFINITY would still reject upgrades to canisters on other, lower replication, subnets. This part can be reconsidered if NNS root is eventually updated and doesn’t have the shortcoming anymore.

@skilesare would this provide what you need for your use case? Could your canister be redeployed on the fiduciary subnet?
@Lorimer also pining you here as this might solve some of the D-QUORUM requirements?

[skilesare]

Yes. We can certainly deploy on the fiduciary subnet…and it would make sense to do so.

Thank you for taking the time to reconsider!

Any comments or thoughts about the ‘veto only’ option mentioned above? Would DFINITY abstain from those? I’d hope these would be few and far between. My current thinking would be to recruit a set of doxxed deployers that would mostly do upgrades via something like Orbit. Only if people felt we did not follow our own independent self-defined upgrade process, were trying to hide something, or steal funds(I guess someone could do it just to troll us as well but their ICP would be at risk) would it ever get to the NNS and it would just be a ‘motion’ proposal.

If you would abstain, would you rather option 1 (every upgrade goes through the NNS with DFINITY abstaining) or 2 (only vetos hit the NNS when necessary)?

[lara]

Yes. We can certainly deploy on the fiduciary subnet…and it would make sense to do so.

Great to hear!

Any comments or thoughts about the ‘veto only’ option mentioned above? Would DFINITY abstain from those?

We did discuss the topic a bit more generally and therefore haven’t touched this explicitly.
I can take a note to double check with folks here, but I might only get around to this in 2 weeks due to different holidays.

Some personal inputs:

• I agree with statements made in this thread that there are still some downsides to putting things under NNS control, like a false sense of security if no one actually feels accountable for reviewing / verifying things, voter fatigue, and potential negative effect for the NNS if the quality of canister upgrades is bad. I therefore think it is a great idea to keep these factors in mind for the solution, potentially only using NNS proposals for activities that happen rarely!
• I wonder whether the motion-proposal-approach is a bit harder to understand for end-users (which can mean it results in less trust) as this is not what motions are normally used for. I haven’t thought it through, but was wondering if an Orbit-like approach can also be combined with an NNS-triggered upgrade only when needed: maybe normally the canister is upgraded via multi-sig and an intermediate canister that enforced a delay. Then a “veto” could be realized by upgrading the intermediate canister and removing the upgrade that is awaiting the delay. Granted, maybe this is not actually easier to understand as it also involves some indirections (just brainstorming).
• What would probably be easier is, but does not achieve exactly the same properties, would be to just add NNS as an extra-controller that would only be used to upgrade a canister in an emergency situation. This has less indirections and just uses a different controller and different path for certain scenarios.

[skilesare]

These second two points are what I’m considering with the “veto” option. Others have considered I call it something like “independent upgrade” or “improved upgrade”:

We have an independent installer canister with a couple special functions. It is blackholed so it can’t be upgraded(maybe there is a fallback/lifeline canister but it operates in the same way as follows) 99% of the time an n of m multisig “Utility Board” just releases the source for an upgrade, wait four days, and then trigger an install that waits 4 days to do the install. The code on the independent cansister takes care of this and since it is the only controller on the Utility Canister it is the only way to upgrade without direct NNS interferance. If the “Utility board” tries to pull a fast one, someone ideally pushes back before they submit the upgrade and they make a change. If they refuse and submit the upgrade anyway, then the protesting user makes a NNS motion proposal stating their case. They then file that motion proposal with the independent install cansister and it will wait until the motion settles to do the install. If the NNS accepts the veto then the upgrade will be cancled. If they reject it then they upgrade goes ahead.

If a troll gets enough VP and DFINITY abstains, then yes, the troll could block the upgrade for ever. It would be on the Utility board to rally the NNS to reject the veto.

But this is better than having a Utility with 10 Million TVL and terrorists show up at the houses of 3 of 5 board memebers and kidnap your family and threaten them if you don’t rug your users. And probably better than having the NNS vote on EVERY upgrade because until you get critical mass, who cares? A big enough maven will promote it to the NNS if you try to rug people and make a big, outsized signal to the network when necessary.

A governance maven can be the vetoer-in-chief and the NNS doesn’t have to hear about it unless someone actually does something bad instead of ledgislating every upgrade and providing this evidence and that evidence constantly. Let a smaller group handle it…it only takes one disaffected party to raise a flag that it needs more attention.

Enjoy your vacation!

[Lorimer]

Out of interest what sort of upgrades are you imagining being necessary @skilesare, and what sort of upgrade cadence?

I’m thinking that handing over a half-finished product or one that otherwise has a high maintenance burden to the NNS would be undesirable.

Just thinking out loud, but if we’re talking about relatively simple utilities, why not get it working in a well-specified manner, and put it under NNS control with a clear declaration that NNS action should only be needed in the event than an IC API has changed (resulting in a breaking change)? A bit like blackholing, but with a way of handling the rare exceptional case.

Rare and simple seems to be a good place to start (rather than arbitrarily frequent and arbitrarily complex). Maybe you’ve already specified this sort of thing (sorry if I missed it).

[skilesare]

@Lorimer

Out of interest what sort of upgrades are you imagining being necessary @skilesare, and what sort of upgrade cadence?

I don’t think you’d want to use either method for something inflight and unfinished. The original subscription canister was put under NNS control when we felt it had enough completed features with all additional features dependent on future tech that there was not much reason to expect any kind of significant pro-active upgrade cadeance. After a month or so we did find some typos in the log and some queries that were not optimized or out of order. When we announced the intent to submit the upgrade proposal DFINITY announced that they’d reject any upgrades that they had not written. I don’t expect this new deployment will need an upgrade until something comes along like a new payment standard or there is a fundamental change in some cycle charges that we need to take into consideration.

Small bugs and system API changes were the reason we didn’t just blackhole it in the first place. Some of our other services had be disrupted by changes to governance apis so we needed some route to upgrade if necessary. I’m certainly not suggesting that folks should start just throwing random canister under the NNS. This is one reason I like the veto function mentioned above. People can make progress with a small group of interested parties and nothing happens at the NNS unless someone feels that something significant is going off the tracks.

[borovan]

Since we’ve got multiple people trying to extract value from the ecosystem, DOLR AI canisters maliciously breaking subnets, do we even want to have this conversation?

I wouldn’t trust the people in the ecosystem to clean my car without stealing it, let alone put canisters on the NNS subnet.

[skilesare]

No one is talking about putting anything on the NNS subnet. I don’t think you can do this and am not asking to do so. From my understanding the fiduciary subnet is open to public use and is different than the NNS subnet. This is just about setting(or not setting) the NNS as the canister controller. In this instance, I’m trying to see a method to NOT set the NNS canister as a controller is a viable option as it requires no change the existing system and, in all happy paths, no NNS involvement whatsoever. Only in instances of clear swampary would one submit something to the NNS for action(blocking of an upgrade).

I’m seeking the least worst solution given the current configuration that is least annoying to the NNS and provide sufficient security to users of the canisters and safety to controllers of the canisters.

[borovan]

Ok right so its a 34 node subnet and just has stronger security guarantees and increased cost right?

Is this a subnet “type”, ie could we see many more fiduciary subnets in the future?

Also isn’t the OGY token on the SNS subnet?

[skilesare]

I think there is only one public fiduciary subnet at the moment: https://dashboard.internetcomputer.org/subnet/pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae

I’d imagine with ICP success you’d get many more of these. Right now it looks like this is mostly populated with SNS Dapp canisters. I’m not sure what most of them are doing.

Yes, the OGY canister is on the SNS subnet after moving to the SNS a couple of years ago. The original OGY canister was lunched before there was such a thin and it migrated.

This canister being discussed is not an OGY canister. It is a general purpose subscription canister that lets you add payment to your dapp/service/game in any ICRC1/2 token with a couple lines of code.

[Zane]

its a 34 node subnet and just has stronger security guarantees and increased cost right?

That’s correct.

Is this a subnet “type”

Yes it’s a subnet type, you can choose to deploy on the fiduciary subnet when creating the canister.

could we see many more fiduciary subnets in the future

I think that’s the plan if there is enough demand, hopefully we’ll also get “fiduciary” subnets with way more replication.

[borovan]

Anybody have any idea why ICL and ICS are all over that subnet? WTN I can understand, but what reasons would you have to be on the expensive subnet if you’re an exchange?

[infu]

@borovan

what reasons would you have to be on the expensive subnet if you’re an exchange

There is one bad reason I can think of, the more nodes the subnet has, the higher chance your nodes consistently stays in there. If you extract data quicker as NP from pools you can frontrun, rearrange tx. Far fetched, but a reason non the less.