Subnet Rental & Swiss Subnet

Subnet Rental & Swiss Subnet

Dear ICP community!

Multiple community members have expressed interest in renting an entire ICP subnet. There seem to be sufficient use cases that justify the introduction of subnet rental on the Internet Computer. Subnet rental means that a whole subnet can be rented by a tenant (a person or company). The tenant gets exclusive access to the subnet and its resources and has to pay the full expenses incurred by running the subnet, i.e., the full node provider rewards incurred by the operation of the subnet.

Subnet rental is particularly interesting to allow for subnets that are tailored to the needs of the tenant, e.g., in terms of decentralization, security properties, and countries where the data processing is performed. Subnets tailored to the needs of a tenant can help realize beneficial properties for their tenant, as for example:

  • All subnet nodes are located in one specific country or region, e.g., Switzerland. This can be important to reach regulatory compliance or cater to the reputation of a specific country, Switzerland in the example, as a highly stable and reliable country.
  • Node providers of such subnets are chosen by the NNS using the NNS-adopted node optimization framework (Proposal 125367). Special properties for such subnets are defined in terms of a target topology update for optimal fit for the intended use case, e.g., banks, NGO organizations like ISO or ITU, or universities, in order to obtain a more proof-of-authority-like consensus property in this subnet. As always, such target topology updates are proposed to the NNS for a vote.
  • All together, such a subnet can realize specific high-security or compliance requirements thanks to the combination of factors determining their setup.

It is important to note that the selection of node providers, data centers, and nodes for the subnet is done by the NNS and not the tenant, thereby following all the basic rules of ICP.

Note that such tailored subnets currently do not fit into the overall ICP decentralization strategy which decentralizes every subnet as aggressively as possible on a global scale. Thus, they make only sense in the context of subnet rental.

More general advantages of rented subnets are discussed next:

  • Guaranteed performance and service quality for the tenant as the general public cannot deploy canisters on this subnet and thus subnet resources such as ingress capacity, compute, and storage do not need to be shared with others.
  • The Internet Computer at large benefits from rented subnets in that the rent paid corresponds to a 100% utilization of the subnet. This would increase the cycle burn rate for the IC considerably.
  • The Internet Computer becomes a platform that can host a wider variety of applications, namely such that would not be eligible to run on the typical subnet of the IC, e.g., due to the countries nodes are located in. This argument is mainly regulatory driven.
  • Help grow ICP overall by admitting new classes of use cases and create positive traction for the whole ecosystem.

Using Web 2 for an analogy, one can see subnet rental as analog to having a dedicated machine in the Web 2 setting instead of using cloud computing with collocation of random clients on the same machine. Similar advantages apply in Web 2 as do on the Internet Computer, namely security and guaranteed performance and resource availability for the tenant. The same drivers that motivate dedicated machines in Web 2 motivate subnet rental in Web 3 on the Internet Computer. Following this line of argumentation, there is a clear use case for subnet rental.

How can subnet rental be realized?

A main tenet of subnet rental is that rent is paid by the tenant, giving the tenant exclusive access to the subnet and that canisters deployed on a rented subnet do not need to pay cycles for their operation. The subnet is let to a tenant principal corresponding to an entity (person or business) that wants to use the subnet for their projects.

Prerequisite: Availability of a subnet to rent

As a prerequisite, a subnet for rent must be available. This is achieved via the ICP topology model which strives to establish a target node topology for the Internet Computer, thereby also including the subnets that are for rent. The currently adopted target topology already contains a 13-node Swiss subnet, for example. Note that the Swiss subnet’s “Subnet limit country” parameter, i.e., the maximum number of nodes in a single country, has been wrongly set to 2 and needs to be set to 13 in a future proposal to make a single-country subnet work.

In the general case, a prospective tenant would make an NNS proposal to update the ICP topology model to contain the subnet they would like to rent later.

If such a topology proposal gets accepted, the subnet needs to be established, be it by means of nodes of existing node providers or new node providers bringing in new nodes to the network according to special requirements of the to-be-established subnet, e.g., nodes in a specific country or region. All of this fully follows the regular NNS-driven processes of node provider onboarding, data center onboarding, and onboarding of new nodes, and finally the creation of a new subnet, in this case flagged as a for-rent subnet.

The above is orthogonal and necessary, but not part of the actual proposal for subnet renting. In the remainder of the discussions, we assume that the subnet to be rented has been made available as outlined above.

Required technical components

A simple and non-invasive way for implementing subnet rental on ICP is to realize the required logic as part of a Subnet Rental Canister (SRC) that is running under the control of the NNS on the NNS subnet. This canister must handle the conclusion of a subnet rental agreement, the initial and periodic billing, the offboarding in case a tenant wants to move off the subnet, and possible service suspension in case of rent not being paid.

Process of renting a subnet

The process for a tenant to rent a subnet that has been made available with an ICP topology change and node provider, data center, node onboarding, and subnet creation is described next.

Deposit by the tenant

A prospective tenant makes an ICP deposit to a publicly known address controlled by the SRC, specifically to a subaccount derived from the tenant’s principal and the id of the subnet in question. The amount of ICP transferred must cover the subnet cost for an initial rent duration (e.g., 6 months) and is calculated from the current ICP/SDR exchange rate and a set price per day. Due to exchange rate fluctuations, the real duration of the initial period may be shorter or longer.

Note: Subnet rental must be economically viable for the Internet Computer, including that it must be guaranteed that a subnet that is specifically created for the intention to be rented, with specific properties regarding node providers, data centers, and decentralization, generates rent for the defined initial duration and is not abandoned by the tenant a short time after being rented out. For this reason, the proposal above mandates a prepayment of the rent for the subnet upfront to cover the subnet cost for this initial period.

NNS proposal for renting the subnet

The following steps include the tenant making an NNS proposal for renting the subnet and the actions triggered by this proposal as outlined next.

  • The prospective tenant makes a payment to the subaccount derived from their principal and the subnet id.
  • They create a subnet rental request NNS proposal (this is a new proposal type), containing their principal, a list of other principals to be whitelisted and the subnet id of the subnet to be rented.
  • The governance canister validates the proposal by checking that no other proposal of this type exists.
  • The proposal is opened up for a community vote.
  • After the community vote, the proposal executes code on the SRC:
    • If the community rejects the proposal or the proposal is invalid due to a bad subnet ID or insufficient funds, the request is archived as rejected and the rejected tenant can call a refund method on the SRC.
    • If the community adopts the proposal, the SRC performs the following actions:
      • The SRC calls an existing method on the CMC (Cycles Minting Canister) to whitelist the tenant principal to be allowed to deploy canisters on the rented subnet.
      • The SRC creates and persists the rental agreement, and starts the billing process.

From this point on, the tenant principal has the sole authority to deploy, run, and manage canisters on the subnet.


Billing for the initial rental period

At the start of the billing phase for the rental agreement, the initial deposit is transferred to another subaccount, derived from the subnet id only. It is now no longer refundable and will start to be burned.

Billing after the initial rental period

A subnet that can be rented is assigned some additional parameters related to subnet renting during its creation; examples for those parameters are given next:

  • daily_cost: 1000 XDR
  • initial_rental_period: 183 days
  • billing_period: 30 days
  • warning_threshold: 60 days

After the initial deposit is used up (this should be approximately after the initial rental period, but may happen sooner or later due to exchange rate fluctuations), the tenant is expected to regularly transfer ICP to their subaccount on the SRC. It should be ensured that the rent for the next period, e.g., month, is covered to avoid service interruption. There should always be enough ICP available in the rent account to cover the subnet cost for the warning_threshold time period to avoid warnings. The warning status can be queried via API, so warnings are pull-based.

The SRC runs the following billing process periodically:

  • This process withdraws an amount of ICP from the rent address every billing period, e.g., every month, to cover the rent for the upcoming period. In the above subnet configuration example it would withdraw ICP worth 1000 SDR from the rent account every month. The withdrawn ICP are converted to cycles and burned. In this success case, the output of the billing process is active, meaning that the subnet state is active and the subnet should continue normal operation.
  • In case of insufficient funds being available on the rent account, the output of the billing process is suspended, meaning that the subnet is in suspended state.

Service suspension

If insufficient ICP is available on the rent account to cover the subnet operation, services are suspended. This state is reversible and can be lifted by the tenant by paying. If the services are suspended for too long, a community member may create a rental termination proposal. Service suspension means that update calls and / or query calls are blocked on the whole subnet.

Termination of a rental agreement

After the prepaid initial period, a tenant can terminate a running rental agreement by creating a rental termination proposal. During the execution of this proposal, the subnet is purged and brought into a state where it is ready for rental again.

Details to the processes of service suspension and termination of rental agreements still need to be worked out in detail, but should follow best economic principles and the best interests of the Internet Computer.

Swiss subnet

A Swiss subnet, henceforth also referred to as S2, comprising 13 nodes is intended to be constructed and rented as a first use case of subnet rental. The community has already accepted the “Swiss subnet” in Proposal 125549, note, however, that the “Subnet limit country” parameter is wrong and needs to be set to 13 in a future proposal as all nodes will be in a single country. Node provider (NP), data center (DC), and node operator onboarding shall be done as per the NNS-approved node optimization model (Proposal 125367).

There are already concrete plans about which projects to host on the subnet. Details on the projects can not yet be presented to the public, but what can be said is that the Swiss subnet helps reach regulatory, security, and trust constraints for those use cases. Also, a fully Swiss subnet is appealing to some of the projects intended to be hosted due to the excellent reputation Switzerland has.


In this post, we have outlined how subnet rental can be introduced to ICP. We have several next steps on our mind to progress the work on subnet rental:

  • We would like to ask the community for feedback and ideas on this proposal. The request for feedback comprises both the general concept of subnet rental as well as the concrete proposed realization.
  • Based on the feedback, we will consolidate the proposal and converge it to have (at least) rough consensus in our community.
  • Once (rough) consensus has been achieved, we would proceed with a motion proposal with the following goals:
    • Asking the community whether subnet rental should be implemented;
    • Modifying the target topology for the Swiss subnet to change the “Subnet limit country” from 2 to 13.

We are looking forward to your valuable inputs and to having a lively discussion on the topic of subnet rental!


Wow this is incredibly detailed. Is this related to the UTOPIA project?


Couple questions.

  1. Node Providers
  • who would they be?
  • same node provider selection criteria for subnet rentals?
  • do you need to decentralize node provider owners within a subnet like today?
  1. Node Provider Compensation
  • would these node providers be compensated from the nns as they are today?
  • is any part of the tenant rent going to pay node providers or is the icp entirely burned?
  • would these node providers be compensated the same?
  1. Tenants
  • could you please provide examples of tenants that want to use a subnet rental for regulatory purposes. If you could convince a government to issue a cbdc that would be insane
  1. Chicken and egg problem
  • how is it possible to set up a Swiss subnet rental before there’s a tenant to pay for the rental? Will it be required to find the tenant in advance of buying the machines and assembling the subnet?
  • in the example of the Swiss subnet, with 13 nodes. How many node owners are there?

I think this is a brilliant idea. It makes a lot of sense to adapt core capabilities of the IC to the needs of organizations that want to consider using its resources.

This is a very attractive proposition.

This initial implementation of subnet rental is focused on a topology where all nodes are located in one country. Would it be correct to assume that the subnet rental idea could also apply to use cases where the organization renting the subnet wants to optimize performance (e.g. fewer nodes for gaming applications) or wants to make sure that all nodes are located in a specific slate of countries? Or do you envision the subnet rental idea to be driven primarily by the need for all nodes to exist in the same country?


All very good questions, let me provide some answers.

Following the target IC topology and the fact that there are still some data centers in Switzerland that have unused nodes, it would probably be a combination of already available nodes in Swiss data centers as well as a selection of new nodes. Each NP should only have one nodes to have strong decentralization along the NP dimension. Also, each DC should have one node only, same argument.

Yes, the compensation is envisioned to be exactly the same in the current thinking. The rent would be converted to cycles and burnt and ICP would be minted using the regular process to remunerate the NPs. This means that the subnet would have 100% utilization in terms of cycles burn rate.

One example could be an asset-backed coin that intends to be 100% Swiss, another example a dapp that must ensure compliance with Swiss banking regulations, i.e., no data may be stored outside of Switzerland. Indeed, a government use case would be really awesome. But the prospective tenant is a private entity for the “Swiss subnet”.

There is a prospective tenant available who has strong intentions to rent the subnet for a specific project, and potential follow-up projects with others. For example, the first data center intended to be used for this subnet is probably the most secure data center of Switzerland, housed deep inside a Swiss mountain, nuclear strike proof and virtually impenetrable (NNS proposal, forum post, forum post). As you can see, the intention here is to set this subnet up with elevated security.

There would be 13 node providers and data centers, only 1 node per node provider and data center.

@SvenF, @georgi, @emilio.canessa, or @michael-weigelt may have more to add.


The UTOPIA project is different in that a UTOPIA is a completely separate subnet-like things not part of the ICP, but connected to it, owned and operated by some entity, i.e., it is not decentralized like a rental subnet. The rental subnets essentially are subnets that are part of the IC, but with different decentralization rules, e.g., all nodes in a specific country. Both UTOPIA and rental have very interesting value propositions in terms of bringing ICP technology to new use cases that could (or would) otherwise not benefit, but follow different paradigms to realize them.


Yes, of course, this would also be something to consider in the future. Any kind of different rule of decentralization that makes sense for a prospective tenant would in principal be something that the community can consider accepting for a rental subnet. I think it makes sense as long as it helps bring new use cases to ICP and help it grow.


Fascinating stuff. Thank you. Out of interest, do you have a sense for the rental markup to tenants?

For example, suppose the 13 node providers in aggregate together making $20k a month total from the NNS in rewards.

In this case, what does it cost the tenant to rent the subnet?

Presumably it is inherently deflationary from the start?


Indeed, looking forward for the first rental subnet and its dapps to come!

Regarding NP rewards, we thought it’s already excellent to be inflation neutral, i.e., in the current thinking the rent is set such that it is expected to be close to the NP rewards minted. The divergence between the two is driven by exchange rate risk because the first year’s rent takes a fixed ICP/XDR rate and afterwards rent is charged monthly. For the first year, the divergence in either direction may be substantial due to exchange rate risk, but in the following lease time it’s well within reasonable bounds in most conditions. Can you think of an approach that makes the rent paid match even more closely the actual NP rewards minted?


Surely you’d want it to be deflationary? Point is to improve ICP tokenomics.

Would it be unreasonable to charge rent in XDR? Sure, annual costs will fluctuate in the local currency but the tenant is paying to be a part of a global crypto network which seems like a reasonable price to pay. Some years would be a bit higher, some years would be a bit lower.

Perhaps if you set the rent to the XDR rewards paid in total to the subnet plus a markup (10%?) that would be good?

Building on this idea, with the cycles ledger coming out couldn’t tenants prepay for cycles for a couple years to lock in the rate? Or if not use a third party provider to hedge their costs?


Really cool to see this move forward! I think this could be one of the ‘accidental killer features’ for ICP adoption.

That’s actually what’s intended (SDR is the same as XDR):

I also think a small markup is pretty important. As written now, the subnet will be provided ‘at cost’, which is a bit too little. IMO the fair cost would also cover the period where the subnet is created but not rented out, and some of the ‘admin work’ the NNS governance performs. ICP shouldn’t need to be run like a for-profit business, but as a whole it should try to cover its total cost.


Why 13 nodes and not 6 or 30?why have these restrictions on optionality?

1 Like

Any plans for orbital nodes? It’s a logical progression to have multiple nodes orbiting earth at least in my view. ICP is alien tech… I was thinking it would have government/high security subnet use cases - that we could charge a premium in cycles for - if pulling of a launch like that and obviously recouping the additional costs of deployment would be feasible - but if there is demand, I think it would be doable. From a marketing and public relations standpoint - everyone in the industry would be talking about it. Maybe years away, but the “nuclear strike proof data center” got my imagination running.


I was thinking this too when I first read the post. It will be interesting to watch what develops.

I think this is an important point and seems consistent with what @dfisher has also expressed so far. A slight markup seems reasonable.

I think you might have intended to ping @dieter.sommer on this question. Personally, I think it should be up to the organization that wants to rent a subnet to specify how many nodes should be included.


What kind of limits will these subnets have from a technical perspective? I know there are some sensitive properties like cycles accounting, outcalls, and Tecdsa stuff. How do other subnets interoperate with these subnets with assurances that no funny business is going on as these subnets will likely have different security and risk configurations.


Ok I misunderstood. Now I understand. The reason for the potential divergence in the first year is because rent is paid upfront for the tenant, whereas node provider rewards are paid monthly. In the second year there is a timing match; in the first year there is a timing mismatch.

This makes sense to give skin in the game to the tenant since they are not buying hardware and the node providers are. Makes sense.


If I am a project that wants to issue a stable coin, maybe I’m a government, what are the pros / cons of renting a subnet versus using UTOPIA?

It seems if I don’t want decentralization of node providers, UTOPIA is my best bet.

It seems if I do want decentralization of node providers, but I need to control access to the subnet for some reason, subnet rental is better. It seems like subnet rental would be a good option for consortiums. If a collection of banks want to band together to create a stable coin they can not only rent a subnet, but also they should be able to be the node providers themselves, if that’s what they want…


100%. ICP needs to promote a culture of developer choice, barring technical infeasibility.


Maybe a side topic but I have searched the forums for a description of the UTOPIA project you are referring to without any result. I have a vague understanding of what it is based on posts referring to it here and on X/Twitter but am hoping that you or anyone else could link to a post or article explaining the concept.
It sounds like a proposal that was discussed and developed back around genesis that happened before I and others joined the community?


Go through Dominic’s tweets and you’ll find stuff on it there. He also presented on it and you may find it in the deck on the website towards the end