PSA: Upcoming SNS proposal types: RegisterExtension, ExecuteExtensionOperation, UpgradeExtension

[aterga]

Dear SNS users, developers of SNS-related frontends and tools,

The Governance team is preparing to propose a release of three new proposal types for the SNS:

• RegisterExtension — registers an extension canister under the control of the DAO.
• ExecuteExtensionOperation — executes an operation of a priorly registered extension on behalf of the DAO.
• UpgradeExtension — upgrades a priorly registered extension.

The current use case for these proposals is to support the upcoming SNS Liquidity Pools feature, as discussed here. Here’s what we expect:

1. When the NNS blesses the first extension, it will become available for registration. (This will be an extension of type Treasury Manager, providing two operations — deposit and withdraw). This will not force any SNS to use the extension, but rather enable those SNSs that want to use it. Note that only an NNS-blessed extension Wasm will be possible to register, which is much different from, e.g., regular SNS-controlled dapp canisters.
2. The first SNS project that decides to use extensions (e.g., because that community would like to improve how their DEX-allocated assets are managed) will submit a RegisterExtension.
3. When an extension is being registered, the community probably already known what it wants to use that extension for, so there must be a way to trigger the initial operation right after registration. Therefore, the RegisterExtension proposal can already include, e.g., the initial deposit amounts while registering a Treasury Manager extension.
4. After the extension is registered, it can be queried by anyone (e.g., to read audit-related info) and the SNS community can trigger its (privileged) operations via ExecuteExtensionOperation proposals. These, of course, may also take input parameters, e.g., the deposit amounts in deposit and the optional withdraw accounts for withdraw (for the Treasury Manager example).
5. To upgrade an extension, the SNS can use the ExtensionUpgradeArg proposal type. An extension can be upgraded only to another NNS-blessed Wasm version.

Important details:

• To avoid tailoring the SNS candid API to a particular type of extensions, we opted for arguments in a JSON-like format; this implies that the input argument schema needs to be communicated separately. For each new extension type, we plan to document it in the developer docs and provide an CLI tool that simplifies proposal creation when that makes sense.
• The proposal descriptions are going to be specific for each extension type, so the voters wouldn’t have to know anything about the argument schemas. For example, while registering a Treasury Manager extension, voters will see at a glance the initial deposit amounts (how much tokens will be allocated from the SNS treasury) in the proposal description.
• The topic of a RegisterExtension proposal depends on the extension type, e.g., registering a Treasury Manager extension will fall under the Treasury & asset management (critical) topic. Similarly, the topics of ExecuteExtensionOperation proposals vary on the specific operation being triggered by that proposal.

We are planning to propose enabling these new features in the next two weeks. Stay tuned, and please let us know here if you have any questions or concerns.

[rem.codes]

Will community efforts to build extensions be supported?

[aterga]

Will community efforts to build extensions be supported?

It depends.

If you mean adding new instances of existing extension types (e.g., subsequent Treasury Manager implementations for multiple DEXs that meet the strict requirements outlined in treasury_manager.did), then yes, we definitely want to support this. We’re just starting with a reference implementation, and it’s up to the communities to pick this up. Note that the specifics of how to get a community implemented extension blessed by the NNS are still not clear, but I think it’s reasonable to expect that we figure them out once there’s a serious candidate.

However, if you mean adding new extension types, then this is much harder, as it requires

• Designing a new API layer that suites all extension instances of that type. This is almost as hard as designing a new ICRC standard.
• Supporting that API in the SNS framework.
• Working out a reference implementation, and getting it approved by the NNS.

Hope this clarifies it; we are, or course, curious to hear what you think.

[rem.codes]

I must say im not totally up to date regarding the extensions and the surrounding limitations and requirements, other then what you already explained.

Last week a few point were brought up that could be natively added to an SNS or maybe via an extension, for example;

• add a canister that handles known neurons for SNSes
• add an archive canister for proposals and voting history

[msumme]

@rem.codes

Will community efforts to build extensions be supported?

The concept of SNS Extensions is to provide integration points into the core SNS framework that would allow plugging in functionality that would otherwise have to be baked into the SNS framework itself.

As a kind of example, think about CMS’s like Wordpress that have a massive plugin ecosystem that allows building all sorts of things on top of an otherwise vanilla blog platform.

What if DAO communities could also be plug and play? What if you could just make an SNS (or some other community-driven DAO) and then bolt on everything you need to manage and sustain a community around an idea or interest?

I think community-driven development would be ideal. (We would probably have to make a distinction between the NNS-launched SNSs and the freely launchable SNSs so that the latter could have more latitude in installing extensions that have not undergone the same level of scrutiny. That would allow more experimentation and risk-taking.)

It would be amazing if there were more DAOs driving communities, and they could just be plug-and-play with everything you need to build your own community.

Here’s a brain dump of ideas… no promises that any of this will be acted on, but I just want to seed some ideas into the conversation about what categories might be possible.

1. Extensions that can interact with proposals:

   • Scalable pubsub for proposals and voting.
   • Pre-processing proposals for AI spam detection, or helpful summaries, or adding community moderators.

2. Extensions that can interact with neurons:

   • Custom maturity rewards for activity other than voting (like dApp activities, or something like StackOverflow reputation which can be tokenized)
   • Access control API based on staking requirements without revealing neuron identities.
   • Allowing neuron penalties for misbehaving community members (i.e. they agree to some terms and have to put up a neuron as collateral)

3. Other TreasuryManager Extensions:

   • Simple cycles manager (maybe by integrating with existing services like CycleOps)
   • Micro-lending platform

4. Non-privileged extensions:

   • Extensions like forums or members-only areas that have their own automatically added proposal types and management (i.e. quickly integrate canisters with lots of proposals to be managed by the SNS).

Some of this may overlap with what @skilesare is doing (as mentioned here: AstroFlora and EthDAOs). The SNS may not be the right platform for all of this or any of this.

If there’s an interest in these building blocks, start expressing it. Whether it’s SNS or the AstroFlora, we would need to find an early market to help define the capabilities of what gets built. If there’s a market, maybe the work can get funded.

It seems empowering non-technical users to spin up a DAO with tokens and everything they need to run a community could give community builders an economic engine that will sustain their projects.

Could we get a micro-creator economy using DAO building blocks? What kinds of plug-n-play functionality would be needed to drive adoption? What other use cases can you imagine? How can we support easily starting micro-projects and micro-communities even for non-technical people?

I’m very interested in getting some feedback. The IC has the best DAO tools available IMO, b/c of the capabilities of the platform, and if we could put these in the hands of thousands of communities, who knows what they might build?

[bitel911]

@aterga

To avoid tailoring the SNS candid API to a particular type of extensions, we opted for arguments in a JSON-like format; this implies that the input argument schema needs to be communicated separately. For each new extension type, we plan to document it in the developer docs and provide an CLI tool that simplifies proposal creation when that makes sense.

I assume this would be only needed to be executed once after the sale, and for all sns’s that want to enable it for their treasury right?

How will the json format be correctly and parsed into the / canisters alongside other proposals ?

Lets say we want to build a extention on this treasury manager, are all arguments for the treasury manager Json-like-format?

@aterga

we plan to document it in the developer docs and provide an CLI tool

@aterga

The topic of a RegisterExtension proposal depends on the extension type, e.g., registering a Treasury Manager extension will fall under the Treasury & asset management

I assume Each SNS can add their own Extensions, or is this for the full SNS canister framework?

Sorry to ask maybe very basic questions, Im very interested in this topic as I had send you a message regarding that TreasuryBalancer extension.

[rem.codes]

Thanks for the extensive response, that does bring up other questions as wel,

To give some more context about what i’m doing, we are finalizing SNS creation via toolkit, below you can find a screenshot to get an impression.

We are thinking of providing a total of 3 options to decentralize a project;

• SNS via NNS (proposal, forum post etc)
• SNS via toolkit (we can not name it an SNS but it would use the same framework and codebase, but without the restrictions set by dfinity) (not visible in screenshot)
• Toolkit project (in house solution with more flexible governance options for teams which late could be converted to an SNS)

Would it be that extensions also become configurable via the SNS initialization? or would this always be a step after a successfull SNS?

[dfisher]

Will SNSs be integrated with Caffeine? So non-technical users can build DAOs easily. This would be cool !

[skilesare]

@aterga

To avoid tailoring the SNS candid API to a particular type of extensions, we opted for arguments in a JSON-like format; this implies that the input argument schema needs to be communicated separately. For each new extension type, we plan to document it in the developer docs and provide an CLI tool that simplifies proposal creation when that makes sense.

Can we please NOT use json. Everything else is candid, and if you need extensibility, we have the ICRC3 Value or ICRC16 formats. Please keep it candid. Motoko is slowed down significantly when we start parsing things outside of candid.

[skilesare]

I had a great conversation with @msumme last week and there will be more coming soon. AstroFlora was specifically built to be an ‘npm for dao tools’, complete with transparency and accountability built in from the start.

We only have the alpha out at the moment at https://muwct-xiaaa-aaaaj-a2ffq-cai.icp0.io/. All you can really do right now is bring your own canister and deploy an ICRC-75 list server, but we should have more in the coming week/s. Bring an empty canister that has a7pjh-xiaaa-aaaai-atlbq-cai as the controller and you can add it and deploy the list server wasm(warning, right now the would theoretically give me access to you canister that I don’t really want so use at your own risk…solutions coming soon).

Long term, this app will give you the dfx commands you need to add a canister to your SNS or other DAO and it is all API-ifed on the back end so that tools like CycleOps and Toolkit can interact with it and give push-button deployment options.

It is meant to be a playground where more unique DAO experiments can live with added accountability.

See this thread for short demos: AstroFlora and EthDAOs

Further, Prometheus is using the framework for their MCP app management and orchestration, so hopefully it has extensibility beyond just DAO stuff: Prometheus Protocol Wins USA Nationals, Launches Genesis Program to Build the AI Agent Economy

[Henry_Suso]

Please elucidate.

Caffeine can currently make apps (cansiters) and if fed sns dao endpoints, interact with the daos. Do you mean launching a dao via caffeine? This would probably possible with gigabrain prompts. But those daos wouldn’t be sns daos.

[aterga]

@skilesare

Can we please NOT use json. Everything else is candid, and if you need extensibility, we have the ICRC3 Value or ICRC16 formats. Please keep it candid. Motoko is slowed down significantly when we start parsing things outside of candid.

We are using Candid. What I meant by “JSON-like format“ is similar to the ICRC-3 Value type. The exact Candid representation is:

type PreciseValue = variant {
  Bool : bool;
  Blob : blob;
  Text : text;
  Nat : nat64;
  Int : int64;
  Array : vec PreciseValue;
  Map : vec record { text; PreciseValue };
};

This is much better to use than an opaque blob (e.g., the one being used for custom proposal payloads payload : blob;) because it’s human-readable. Yet it is not tailoring the SNS Governance API to any particular extension API (which is one of the points of having extensions).

[skilesare]

Ahh…perfect. Thanks!

Why the Nat64 and Int64? Could we at least label them as such? That way ICRC16 will still be a superset of both?

We already have some working tools that degrade gracefully to the ICRC-3 value type(and would for this as well if you use Nat64 and Int64 instead) GitHub - ZhenyaUsenko/motoko-candy-utils . It gives you things like Schemas and Pulling out values via path variables.

Also specs like ICRC-105 which tracks configuration changes would let you just insert without having to unwrap Nat and Int to recast to Nat64/Int64.

The full super set is below

/// Specifies a single property.
  public type PropertyShared = {name : Text; value : ICRC16; immutable : Bool};

  /// A collection of `PropertyShared`.
  public type PropertiesShared = [PropertyShared];

public type ICRC16 = {
    #Int : Int;
    #Int8: Int8;
    #Int16: Int16;
    #Int32: Int32;
    #Int64: Int64;
    #Ints: [Int];
    #Nat : Nat;
    #Nat8 : Nat8;
    #Nat16 : Nat16;
    #Nat32 : Nat32;
    #Nat64 : Nat64;
    #Float : Float;
    #Text : Text;
    #Bool : Bool;
    #Blob : Blob;
    #Class : [PropertyShared];
    #Principal : Principal;
    #Option : ?ICRC16;
    #Array :  [ICRC16];
    #Nats: [Nat];
    #Floats: [Float]; 
    #Bytes : [Nat8];
    #ValueMap : [(ICRC16, ICRC16)];
    #Map : [(Text, ICRC16)];
    #Set : [ICRC16];
  };

[bitel911]

Its not a complete blackbox, I can tell you how the development flow and structure works on caffeine if you have the interest for it

[aterga]

The first-ever SNS extension is running live here.