General Availability of Application Subnets

To our developer community,

We are excited to announce that additional application subnets have been added to the network via NNS proposals for general use. This means that you can now follow the Network Deployment Quick Start Guide to deploy canister smart contracts to the network using ICP utility tokens.

There are currently two types of application subnets. Verified subnets are for apps that have been reviewed and approved by the Internet Computer community through an NNS proposal, and public app subnets like those that were added to the network today are for general use. Compute and storage costs are configured to be lower for verified subnets. More information about the configuration of these two subnet types can be found in the source code here.

To deploy your app to a verified subnet, you can submit a proposal to the NNS with your Principal ID. This should be the same Principal ID that you use to deploy and manage your canister smart contracts (most likely your dfx principal). The NNS will then put your proposal out for a community vote. If the community accepts your proposal, you will be able to deploy your canisters to a verified subnet using the Principal ID you provided in the proposal. For information on how to submit a proposal, please check out this detailed walkthrough.

We can’t wait to see your apps running on the network! :rocket:

54 Likes

Can’t wait to see this, buuurn :fire::fire::fire:

1 Like

Congratulations everyone. We’re getting there.

3 Likes

I’m so excited to see how many public canisters are going to exist in a week!!!

2 Likes

Will your canister is change when moving from general to verified?

1 Like

Let’s goooooooooo :sunglasses: :earth_asia: :rocket:

dfx deploy --network=ic

The invocation to the wallet call forward method failed with the error: An error happened during the call: 2: Couldn’t send message

why?

@matthewhammer it looks like one of your canisters is on a verified subnet. Can you share what happened with yours?

I confess some ignorance. @alexa.smith helped me get set up, and I think she placed me there.

I believe that moving is involved. But again, I am ignorant to the firsthand experience. If someone has that, they can contribute it and that would help a lot.

I believe that it consists of getting a new canister ID for each canister, and having to recreate your stable state there (how to get from the old one to the new one without messages or a local file dump and re-upload?), and most complex of all, having to set up a flow in your app for users to associate their old Principal ID and their new ID, each distinct because II makes them distinct for users’ security (anti-tracking).

3 Likes

Do we still need to submit a NNS proposal to allow our principal to deploy canisters on the (cheaper) verified application subnet?

Unfortunately, the original instructions no longer work.

These subnet types merged a long time ago so the costs are all the same: Proposal to unify app subnet types

3 Likes

Hmm, then do you know why dfx 0.10.0 distinguishes between application and verifiedapplication subnets then? What is different between the two?

Wasnt aware it did that. Let me ask.

I did the implemntation of the parameter pass-through and wasn’t aware that application == verifiedapplication, therefore I just added all three options as possible values.

Following some links in Alexa’s post above, I found this subnet type configuration file. Everything is the same between application and verifiedapplication, so I’m quite confident that the two are entirely equal.

3 Likes

Thank you for clarifying.

I just learned of one difference between the subnet types: Canisters on application subnets cannot send cycles to canisters on verified application subnets.

But from a local development perspective they’re still the same.

2 Likes