Subnet Rental
Dear ICP community
This is a follow-up on the ‘Subnet Rental & Swiss Subnet’ post. The goal of this post is to provide an update on some changes in the design of the subnet rental feature, and to give you, the community, a chance to discuss them before submitting a motion proposal. Note that this post is about the general subnet rental feature, not the Swiss subnet specifically.
Summary of the previous post
- We propose to create a feature which allows users to rent a subnet.
- Renting a subnet gives the tenant exclusive access to the subnet’s resources.
- Instead of topping up canisters with cycles, the tenant pays for the whole subnet by transferring ICP to the Subnet Rental Canister (SRC). The ICP are converted to cycles and burned over time.
- A rental agreement is entered by the tenant and the NNS community via a proposal of a new type. This proposal is executed by the SRC, a new canister under NNS control which is responsible for the whole rental agreement lifecycle and for the payment flow.
- If the funds the user provides to the SRC run out, the subnet’s services can be (reversibly) suspended, and later, the rental agreement can be (irreversibly) terminated.
For details, please see here.
Changes
The main change is that the subnet creation process becomes part of the rental setup.
There may not yet exist a subnet with a suitable topology at the time when a prospective tenant wishes to enter an agreement with the NNS. The tenant can therefore propose to create a subnet for the purpose of renting and specify the desired topology in that same proposal. This is advantageous for the community, because they can accept or reject a special-topology subnet based on the knowledge that it will be used for rental and that there already exists an entity that is willing to pay for it for a minimum amount of time.
Subnet rental setup process
- The user pays a deposit of ICP to a subaccount of an ICP Ledger account controlled by the SRC. The amount is expressed in XDR and covers six months worth of node provider rewards, scaled by the subnet size and including an exclusivity surcharge. The cost for a typical subnet size can be queried from the SRC.
- The user creates a proposal of type “Rental Subnet Request”, which contains the user’s principal and a description of the desired topology (or alternatively, an existing subnet id). If the community accepts this proposal, the given topology is considered an addendum to the official target topology. This should facilitate the creation of the necessary new nodes, even in regions that otherwise would be considered saturated. If the proposal is rejected, the deposit is refunded.
- In the next weeks or months, new node providers are onboarded and nodes created in order to fill the specified topology. If this process takes overly long, the tenant can cancel the process by requesting a refund of their deposit by calling a method on the SRC. Initially, 90% of the deposit is refundable, but every 30d, another 10% become non-refundable. This is considered to be compensation for the work that is being done by the network in the meantime and will be burned for deflation. If no refund is requested and the subnet ends up being created, the full deposit is counted towards the first six months of rent.
- When the necessary nodes exist, a subnet creation proposal must be submitted. This proposal type is extended with an optional field “initial_proposal_id”, which should refer to the initial subnet rental request proposal. On execution, the subnet is created and associated with the principal in the initial proposal. The SRC whitelists the user’s principal and transitions into the billing phase.
Please share your thoughts on these changes. Other aspects, such as the billing phase, remain unchanged from the previous post.
Next steps
- Discussion of the updated proposal (in this post)
- Reaching a rough consensus on the proposal
- Submission of a motion proposal: Does the community agree that the subnet rental feature should be implemented?
Thank you for your contributions!