Introducing the Swiss Subnet: A Secure and Compliant Blockchain Infrastructure Leveraging the Internet Computer Protocol

Fellow Innovators and Advocates of the Internet Computer Ecosystem,

We are a Swiss-based team operating as Swiss Subnet AG, a legally registered entity in the Canton of Zug. With a clear vision to set up and exclusively operate a dedicated, geographically limited subnet on the Internet Computer, we believe the time is right to initiate discussions and gather feedback from the IC community.

Building on the approval of Proposal No. 128820 (SRC Motion Proposal), we are excited to introduce the Swiss Subnet—a bold initiative that combines the technology of the Internet Computer with the trusted legal frameworks of Switzerland and Liechtenstein.

The architecture of Swiss Subnet will seamlessly integrate the security and transparency of public blockchains with the privacy and control of private networks, offering a solution for data sovereignty and performance optimization.

Vision

Our goal is to establish a new subnet consisting of 13 nodes located within Switzerland and Liechtenstein under the Subnet Rental Canister rules.

Key distinguishing features of the Swiss Subnet include:

— Georestricted node topology, limited exclusively to Switzerland and Liechtenstein

— Enhanced security architecture, featuring a ‘canister-in-canister’ implementation

— Full FADP and GDPR compliance, ensuring robust data protection and regulatory adherence

These features, combined with ICP’s advanced storage and cross-chain transaction capabilities, provide businesses and developers with a legally sound and highly secure infrastructure.

Team

We are a team deeply committed to the transformative potential of Web3, supported by Business Professionals with expertise in tech, marketing, PR, sales, and community engagement. Collaborating with key IC contributors, we are already actively developing technical solutions that will bring this vision to life.

Implementation Plan

In compliance with NNS rules, Node Providers and Data Centers will adhere to approved topologies, and any onboarding will follow existing or future enforced procedures.

Why Switzerland and Liechtenstein?

While 10 nodes will be deployed in Switzerland, other three nodes are planned to be deployed in Liechtenstein. Such a configuration presents a distinct competitive advantage – allowing seamless access to both the Swiss market and the broader European Union market of 500 million people, while keeping the highest regulatory standards.

Switzerland and Liechtenstein share one of the most integrated administrative partnerships in the world, dating back over 100 years. This cooperation enhances the regulatory and operational efficiency of the Swiss Subnet, while ensuring jurisdiction-specific encryption and security.

Additionally, this strategic expansion will:

  • Leverage both Swiss Distributed Ledger Technology (DLT) Act and Liechtenstein’s Token and Trusted Technology Service Providers Act (TVTG).
  • Leverage both Swiss FADP and Europe GDPR data privacy laws.
  • Enable compliant tokenization of real-world assets.
  • Unlock new innovative use cases for financial institutions and enterprises.

Benefits for the Internet Computer

We believe the Swiss Subnet will deliver significant value to the ICP ecosystem by:

  • Driving Enterprise Adoption: Enabling use cases tailored to institutional and enterprise needs, which may not be feasible on public blockchains.
  • Driving HNWI Adoption: Additional security and privacy, embedded into the Swiss Subnet platform, makes our dApps more attractive to HNW individuals.
  • Boosting Economic Activity: Acting as a “Tenant” per SRC rules, the Swiss Subnet will contribute to cycle burning by renting computational capacity at full consumption rates (estimated burning of 820 XDR/day).
  • Expanding Ecosystem Growth: The Swiss Subnet team will actively participate in global conferences and events to showcase ICP’s technology and engage developers in building solutions tailored to real-world use cases.

Join the Conversation

  • The Swiss Subnet represents an exciting opportunity to expand the capabilities and reach of the Internet Computer.

We are eager to hear your thoughts:

  • What opportunities do you envision for the Swiss Subnet?
  • What challenges should we anticipate as we embark on this journey?
  • How can we collaborate to build a secure and innovative blockchain ecosystem?

Let’s work together to build the future of decentralized, compliant, and secure blockchain solutions.

Our website: www.subnet.ch

The Swiss Subnet Team

18 Likes

Having observed this initiative for a while, I applaud this coming to realization. Beyond the technicalities, I believe this is of strategic importance for a number of reasons:

  • User demand - trustworthy custody remains essential for hi value assets. From watches, to real estate, to bankable assets, Switzerland and Liechtenstein have always been a trusted haven to safeguard assets. The region has adjusted itself to the modern transparent, compliant and digital era. Becoming a trusted location to house node infrastructure that protects digital assets is only a logical next step for the CH-FL region.
  • Infra - visitors of the region commonly remark that “Things just work over here”. This is more than trains and clocks ticking on time. It is deeply routed in the DNA of the country, a poor farming region less than 100 years ago, to engineer, build and maintain things for reliability and durability.
  • Decentralization - the country did not wait for blockchain to install decentralized governance. As one of the only countries in the world, it has referenda giving its people legislative power. It also decentralizes extensive power to its cantons, each of which will have a node of the Swiss Subnet.
  • Institutional use - CH and FL have an extraordinary large number of multinational corporations and institutions who increasingly look for strong protection of their digital assets, client data, patents, trademarks and intellectual property. Such enterprise use cases require a combination of public blockchain infra with sovereign infrastructure on own territory.
  • Advanced legislation - for a small nation, its legislator has been agile to adjust regulation to the digital age. Admittedly, much of it has remained intentions on paper. Initiatives like the Swiss Subnet will enable this to become a reality.

I congratulate the Swiss Subnet AG team for this initiative and hope that the community will join me in supporting them.

4 Likes

Your insightful comments on the Swiss Subnet are much appreciated! :switzerland:

We acknowledge the strategic importance of blending Switzerland’s reputation for precision and reliability with blockchain technology. Our goal is to create a robust and compliant infrastructure for digital asset management.

The ‘canister-in-canister’ approach, with FADP and GDPR compliance, aims to address security and regulatory needs. We are focused on providing a stable environment for institutional adoption of blockchain.

Your observations are valuable as we continue to develop and refine the Swiss Subnet. We welcome ongoing feedback as we contribute to the evolving blockchain landscape.

Thanks for the support! :sparkles:

3 Likes

The ‘canister-in-canister’ approach

I have not heard this term before, could you explain what you mean by this?

6 Likes

Hi Michael,
Appreciate your interest in the project!

The canister-in-canister architecture is a core feature of the Swiss Subnet that strengthens security by allowing controlled deployment of canisters through other canisters. Developers can use this method to deploy secure, battle-tested canisters with specific functions.
Moreover, data encryption within the canister is handled through an application-layer encryption mechanism that leverages a zero-knowledge (ZK) approach.

Please let us know if you wish to discuss this further.

1 Like

Hello Swiss Subnet Team,

Good to connect on this platform and LinkedIn. Looking forward to your feedback.

  1. Can you provide a detailed breakdown of the 820 XDR/day cycle burning estimate, including how it translates to ICP token burning over time?
  2. How will the subnet’s operations affect ICP’s overall tokenomics, particularly in terms of deflationary pressure versus new ICP minted for node provider rewards?
  3. Will the Swiss Subnet team propose incentives for token holders to vote on their proposals, such as increased voting rewards or community airdrops?
  4. What risks or challenges do you foresee in deploying and maintaining the subnet, and how will you address them to protect token holder interests?

I will reserve the rest of my questions so as to not bombard this platform with a huge volume of exchanges.

All thee Best!
:infinity: :switzerland: :cloud:

1 Like

Let me provide better questions after reviewing the code.

  1. The code estimates 820 trillion cycles/day for the Swiss Subnet (App13CH). Can you confirm how this translates to ICP burning over a 180-day rental period, accounting for exchange rate fluctuations?

  2. How will you handle potential errors in convert_icp_to_cycles (e.g., ledger failures), as seen in the locking function’s error logging?

  3. The execute_rental_request_proposal function awaits subnet creation polling. What is the timeline for completing this feature, and how will NNS governance be notified of new subnets?

  4. The App13CH condition specifies Swiss nodes. How will you ensure the 13 nodes (10 in Switzerland, 3 in Liechtenstein) remain independent, and what happens if a node fails, potentially triggering NNS slashing?

  5. Are node providers pre-selected, and how will their performance be monitored to avoid issues in the locking timer?

  6. The canister logs events for transparency (e.g., persist_event). How will these logs be audited to ensure FADP/GDPR compliance, and what additional features are planned for data sovereignty?

  7. The locking function notes potential scheduling issues (“we risk not accounting for a few days”). What redundancy measures are in place to ensure timers run reliably?

  8. The canister-in-canister implementation is mentioned in the proposal but not in the code. Can you clarify its integration and benefits for security?:

  9. The canister supports enterprise rentals, but how will you market the Swiss Subnet to attract dApp developers, and are grants planned to encourage development?

  10. What use cases (e.g., tokenized assets) are prioritized, and how will they increase ICP demand, given the canister’s payment structure?

Really appreciate your time in answering these question as I am really excited for the potential of a project to attract institutional players to the IC protocol! Switzerland has the Crypto valley and highest per capita of high net worth individuals, this project is a perfect marriage.
:infinity: :switzerland: :cloud:

1 Like

Interesting, I’ve just read up on some context. It appears that some of the minor implementation details for subnet rental may have changed since that post was written more than a year ago.

My understanding is that once this proposal executes yebeg-uqaaa-aaaar-qbk7a-cai will be the only principal that is whitelisted for deploying canisters to this new subnet. Are there plans to whitelist more principals @Swiss_Subnet?

I’m unclear on the process of node selection. This isn’t specified by the proposal payload. Is it correct to understand that this subnet will begin with zero nodes, and a follow up proposal will be needed to assign nodes to the subnet?

  • Location: The nodes will be distributed across various Swiss cantons and Liechtenstein to ensure geographic diversity and prevent high concentration in any single location.

This requirement isn’t captured by the IC Target Topology. Should it be considered enforced/enforceable by the NNS?

  • Node Operators: Only Switzerland/Liechtenstein-based node providers may participate in the formation of the new subnet to ensure adherence to proper regulations and operational standards.

Similar question for this point. By ‘Switzerland/Liechtenstein-based node providers’ are you referring to the node provider entity, or their nodes, or both?

On a more general level, this whole upfront rental agreement thing is interesting. I’m a little unclear on how the ICP burning mechanism works. Is it the same as usual (canisters on the subnet burn cycles)? If so, why is there a need for the subnet to be billed for cycles?

Other than an implicit expectation that yebeg-uqaaa-aaaar-qbk7a-cai is responsible for paying the bills for this subnet to it keeps running, what authority do they have over this subnet other than being whitelisted to deploy canisters to it? In the future, if more principals are whitelisted, are they still subservient to / dependent on yebeg-uqaaa-aaaar-qbk7a-cai in some way?

Presumably anyone could pay the subnet bills by transferring ICP to the correct account (though I’m still unclear on why this is needed if the canisters are also burning ICP).

2 Likes

Anyways proposal 136408 is live so let us argue the pros and cons before voting.

Adopted Proposal #136408 — Zack | CodeGov

Leaving this here just in case:

.

1 Like

@Lorimer , @ZackDS , @BANG , thanks for your interest and for your questions. We appreciate them very much.
Subnet rental is a very new mechanism, and we spent much time modeling various situations, including those concerns you raise.
We will share our view, but it’ll take some time – May 1st came unexpectedly. :slight_smile:

2 Likes

After reading EDPB guidelines, link in Dom’s post, I vote to adopt :white_check_mark: Proposal 136408. Swiss Subnet utilizing Canister in Canister model meets EDPB compliance.
:infinity: :switzerland: :cloud:

1 Like

Thank you, @BANG, for your support and thoughtful questions!

We’ll make sure all of them are answered — either by us or by the DFINITY team, as some relate to the code developed by them.

In the meantime, here are a few non-technical responses:

4. Each node provider’s independence will be ensured by onboarding them through the same process as any other provider. If a node fails, we expect the NNS to automatically appoint a replacement (this is still under discussion).

5. Node providers on the Swiss Subnet are subject to the same rules and governance as those on the broader Internet Computer network. No exceptions.

9. We believe the Swiss Subnet — combining the full capabilities of ICP with additional features like territorial data boundaries — is a great fit for the corporate world. We’ll be promoting it as an infrastructure platform that enables dApp development with a unique value proposition. Developers will also be eligible for grants to support their work.

10. Some pilot use cases are listed in our whitepaper and on the website. While corporate users are a key audience, we also see strong potential among public sector institutions. For example, Identity-as-a-Service is attractive for government use, while secure document management is highly relevant for corporations.

Additionally, we’re introducing a new concept for tokenization: not NFTs, but DOCs (Digital Ownership Certificates). it represents a fully on-chain asset where all data, including content, is written to the Swiss Subnet.

Of course, we anticipate that the Subnet’s capacity will eventually be reached, and when that happens, we’ll apply for expansion to serve more clients.

1 Like

@Lorimer , thanks for the questions!

We refer to the node provider’s entity – all new nodes will be operated by legal entities registered in Switzerland or Liechtenstein.

1 Like

My pleasure and roger that!

Truly appreciate the replies to the inquiries. Looking forward to more updates and participating in the DAO.

All Thee best!

2 Likes

Hi @BANG, thanks for your questions. I can answer the Subnet Rental Canister (SRC) and ICP related questions:

  1. The exchange rate for these 820 TC/day is fixed by the time the proposal was created. When the proposal was created, that meant 41075.50372445 ICP. This means that over the course of 6 months, all of these ICP will be burnt.

  2. If an error happens during proposal execution, that will lead to a failed proposal execution. It would require to recreate the proposal. However, given that we use unbounded calls to the external canisters involved here (without a timeout), the responses are essentially guaranteed. The same holds for the future conversions, and there we will retry every day and check if there are ICP to be converted.

  3. This will be changed to a push-based mechanism where the NNS would notify the SRC on subnet creation. We will implement this until there is a proposal out to form the swiss subnet on the node level.

  4. The nodes used for the Swiss subnet will have the same requirements as all other nodes on the ICP, so the same risks apply as for other nodes.

  5. Note that the SRC runs on the NNS subnet, not on the swiss subnet, to avoid these concerns.

  6. These are only logs from the SRC itself, not for canisters on the swiss subnet. GDPR/FADP compliance needs to be ensured by the individual apps running on the swiss subnet.

  7. We run this job every day, but only every 30 days a customer is “billed”. Together with the monitoring solutions we can timely react if something continues to go wrong.

  8. This would be a question for the @Swiss_Subnet team, what I can say is that this is independent of the SRC.

  9. For @Swiss_Subnet

  10. Again for @Swiss_Subnet. Regarding ICP demand; since the subnet is payed for in ICP, which will be burnt, this is one natural way to decrease ICP supply.

4 Likes

Hi,

yebeg-uqaaa-aaaar-qbk7a-cai will be the only principal that is whitelisted for deploying canisters to this new subnet.

That is correct. Note that that ID is a canister, which can implement additional access logic on top. That access logic is up for @Swiss_Subnet to be defined at their will. On a protocol level, this canister is the only one that can e.g. create canisters.

I’m unclear on the process of node selection

The nodes will be onboarded acc. to the standard NNS node onboarding procedure.

Is it correct to understand that this subnet will begin with zero nodes, and a follow up proposal will be needed to assign nodes to the subnet?

The swiss subnet is in the target topology already, meaning the community intends to form such a subnet in the future. Once enough (13) nodes in the correct locations are ready, they can form the new subnet. Once the subnet is live, it can be configured by the Subnet Rental Canister to be accessible only by yebeg-uqaaa-aaaar-qbk7a-cai.

The tenant pays in ICP upfront for the subnet, and then canisters on the rented subnet will not burn cycles for storage or computation (similar to canisters on the NNS subnet), but might still require cycles for chain signatures or calling other canisters’ paid endpoints.

5 Likes

Hello @fxgst much appreciated! Thank you for taking the time to thoroughly answer my inquires!

Your detailed insights into the SRC’s operations were exceptionally valuable, deepening my understanding of ICP’s technical prowess.

The breakdown of 820 trillion cycles/day equating to 41,075.50372445 ICP burned over 180 days, locked at a fixed exchange rate, underscores the subnet’s deflationary power. A major win for the protocol and community of us holders.

The robust error handling reflects a strong focus on reliability, directly addressing my concerns about ledger failures and locking function scheduling risks.

Again, thank you and the Foundation for entertaining my questions!

All Thee Best!
:infinity: :cloud:

2 Likes

Thank You, Internet Computer Community

Swiss Subnet AG is honored and thrilled to be approved as the first private blockchain subnet on the Internet Computer. This milestone represents not only a major step for us but also a meaningful advancement for enterprise innovation within the IC ecosystem.

We are sincerely grateful for the trust and support from the community. Your vote of confidence motivates us to break new ground, foster impactful enterprise solutions, and help incubate the next generation of dApps on the Internet Computer.

Special shoutout to Noku for your continued belief and collaboration.

With gratitude,
The Swiss Subnet AG Team

4 Likes

Congrats and we are looking forward for updates, one thing to consider if you don’t mind is adding a DARK mode to https://subnet.ch . It is painful to read all that good info, and I am guessing that will be the center of attention going forward.

1 Like

I think it would be really useful to clearly outline the steps that need to take place, and which ones require a proposal, what those proposals will actually do, and what order those proposals will come in.

The Proposal to Commence the Swiss Subnet with 13 Nodes proposal has now executed, but I don’t think it commenced a 13 node subnet. I don’t think I’m the only one left wondering. These things need to be clearer if you expect people to vote in an informed way.

So this subnet will always be only as decentralised as the canister that was registered when ‘commencing’ the subnet (I suspect not, but I’d appreciate more clarity)? Could you clarify what other privileged powers this canister has, other than e.g. creating canisters? Presumably there’s still a whitelist, and/or other canisters that are deployed to that subnet implicitly have the power to deploy more.

@Swiss_Subnet are there plans to decentralise control over the canister? It’s currently controlled by p45yr-pzogn-v2gx5-eepbp-lv7c3-m3xkj-y5xtg-h7flz-4dpha-7mir3-sqe