Boundary Node Roadmap

The boundary nodes are the gateway to the Internet Computer (IC), which allow users to seamlessly access the canister smart contracts running on it: through stock browsers users are served web-content fully from the chain. To this end, the boundary nodes translate the users’ requests into API canister calls, route these calls to the subnet running the canister and load balance among the subnet’s replica nodes. In addition, boundary nodes provide caching and other services for improved performance.

At the end of last year, the NNS community adopted a motion proposal outlining the long-term research and development directions for the boundary nodes. In this post, we provide an update and provide an outlook on the future of the boundary nodes.

We just completed a major milestone by moving the boundary nodes to the same platform as the replica nodes. More specifically, boundary nodes now use the same host- and guest-OS architecture as the replica nodes, which is based on standard Ubuntu and often referred to as “IC-OS”. Thanks to this change, we can build on existing best practices and prepare the boundary nodes to be community-managed via the Network Nervous System (NNS). This is a key precondition to further decentralize the deployment and management of boundary nodes.

In the following, we present the target architecture we aim for and highlight the main features we will work on to reach this target.

Future Boundary-Node Architecture

Design Goals

The design goals for the boundary node target architecture are:

  • No single point of trust: users can interact with the IC without having to trust a single entity. Besides significantly reducing trust assumptions, this requirement increases the IC’s availability as there is no single point of failure.
  • Useability: users can conveniently access the IC using stock browsers as it is already possible today, i.e. standard web browsers with no additional modifications or add-ons.
  • Censorship resistance and legal compliance: individual boundary node owners are able to independently comply with local legal frameworks, e.g., blocking gambling services in a particular geography, without restricting other boundary nodes. This requirement ensures that boundary nodes do not have to comply with the least common denominator globally.
  • Open: anyone can run a boundary node and we aim to maximize the functionality managed by the IC community through the NNS.

HTTP Gateways and API Boundary Nodes

To understand the new architecture, we first have to look at today’s boundary nodes, which serve mainly two roles: (1) they act as HTTP gateways and (2) they serve as endpoints for API canister calls.

The future boundary architecture foresees the decomposition of today’s boundary nodes into two different kinds of nodes, each assuming one of these roles.

  • HTTP gateways: provide an endpoint to the users that terminates TLS, serves the service worker and translates the users’ HTTP requests to API canister calls.
  • API boundary nodes: provide an endpoint that handles API canister calls by routing them to the correct subnet and replica node, and provides caching and rate-limiting to protect the IC.

This decomposition is motivated by different trust assumptions. HTTP gateways require users’ trust as they terminate TLS and serve the service worker, which contains the IC’s public keys. In contrast, API boundary nodes come with significantly lower trust assumptions.

The following figure depicts the new architecture using HTTP gateways and API boundary nodes. Next, we will explain how this architecture achieves the design goals.

Community-owned Boundary Nodes

In order to achieve the “no single point of trust” goal, boundary nodes must be owned and controlled by multiple parties:

  • HTTP gateways will be self-managed, which means that anyone can run an HTTP gateway under their own domain with their own policies without NNS-approval. Then, DFINITY will just be one of many HTTP gateway owners and users can choose the gateway they trust most and through which they access the IC. Hence, there will be no “single point of trust” and we achieve the “censorship resistance and legal compliance” design goal.
  • API boundary nodes will be managed and rewarded through the NNS akin to the replicas today (shaded blue area). The vast majority of the API boundary nodes will be provided by third parties (green) and a few by DFINITY (pink).

In summary, community members will both run HTTP gateways and API boundary nodes.

Access Paths

Depending on a user’s tech-savviness and usability preferences, this architecture allows to access the IC through different paths:

  • Stock browser: A user can choose their trusted HTTP gateways by picking the corresponding domain. Thereby we achieve the “useability” design goal. While this path comes with a choice of a HTTP gateway, it still requires the trust in a single gateway owner.
  • IC-native clients contain the IC’s public keys and can access the API boundary nodes directly (red arrows). In the future, there will be many different native clients such as mobile applications and web-extensions. We also plan to develop a web-extension for the browser, which translates HTTP requests for the IC into API canister calls directly in the browser allowing users to completely bypass the HTTP gateway.

In conclusion, for convenience, users will rely on HTTP gateways but if they choose a native client, they don’t need HTTP gateways. API boundary nodes are always part of the path from a client to a replica node but they are truly decentralized and under the control of the NNS.


Ultimately, we plan to further reduce the required trust by building a decentralized DNS infrastructure directly on the IC. However, we haven’t worked out a concrete architecture yet.

Upcoming Features

In addition to the new boundary node architecture, we are working on improving the user experience and the security of the IC. In particular, we are working on:

  • Search engine optimization (SEO): By the end of September, we will rollout an update to the boundary nodes allowing search engines to index canisters on and enabling previews on social media (e.g., Twitter cards). We achieve that by letting crawlers and bots bypass the service worker similar to
  • Asset caching: In November, we will release an update that enables asset caching as introduced in DFX 0.11.1. This update allows the browser and service worker to cache static assets and therefore improve the load times experienced by dapp users.
  • Custom domains: After that, we will start working on bringing custom domains to the IC. While it is already possible today, it requires extra developer effort by handling the SSL certificate and a server to host the service worker (see Documentation). Our goal is to seamlessly integrate the domains into the existing boundary nodes, in the future HTTP gateways, such that developers can use friendly domain names with minimal effort – only the DNS record of the domain has to be adapted.

In the longer term, we focus on increasing privacy and integrity to improve the overall security. We aim to seal the boundary nodes and provide means for users to validate their integrity. To this end, we use hardware-based trusted execution, specifically, we are relying on AMD SEV-SNP, and allow users to remotely attest the authenticity of the boundary nodes’ hard- and software. In addition, we are working on an enhanced response certification that prevents malicious replicas and boundary nodes from modifying the HTTP responses.

Next Steps & Roadmap

Q4 2022:

  • The boundary nodes team focuses on the useability features:
    • enabling SEO (ETA: end of September)
    • asset caching (ETA: November)
    • supporting custom domains (no specific ETA, but the intent is to finish by the end of the year)
  • The order of magnitude: months.

Q1 2023:

  • The team starts implementing the new boundary node architecture that decomposes boundary nodes into “HTTP gateways” and “API Boundary Nodes”.
  • As of today, there is no specific ETA for this decomposition (it could go into Q2 for example), but decomposing will include:
    • Anybody being able to run an HTTP gateway (no NNS approval needed)
    • Anybody being able to run an API Boundary node (NNS approval needed) and get rewarded for it.
  • The order of magnitude: months.
  • As the team knows more, the team will update on this thread.

We hope this post addresses a lot of the questions the community has raised about boundary nodes in the past months. We look forward to your feedback on how we plan to strike a balance between decentralization, useability, and security.


Thanks the update, those are really exciting plans!

Could you expand on how you plan to design the reward scheme for the API boundaries nodes, will it depend on the number of API calls & if so how can we keep track of this metric in a trustless manner ?


Hi Seb, the exact reward scheme is part of the overall redesign of the boundary node architecture. We are working on that and will provide more details as soon as we have them!


Is there any plans for building a decentralized CA/TLS infrastructure on IC?

1 Like

Extremely excited about the progress being made here! Can’t wait to hear what final design for integrating boundary nodes with the NNS will look like.


Is this documented anywhere? Is it by default or configurable? We have assets that appear static but can be updated via the http_qurey_upgrade functionality…how does this interact with that?


This is awesome! Great work all around.


How does, or does this, work interact with the ICx proxy that is currently used? We use a fork of that want to be prepared for any architectural changes.


I think this will be really powerful, as it would let HTTP gateways (not just API boundary nodes) be managed by the NNS. I thought the timeline for this would be earlier, to be honest.

By the way, I’m assuming DFINITY will provide the IC-OS for both the HTTP gateways and the API boundary nodes in the future. All the user has to do is run the gateway server and register its DNS.

1 Like

Actually, perhaps I misspoke: wasn’t there a plan for decentralized SSL certificates at some point, especially now that threshold ECDSA is released? I think this would be the enabler for NNS-managed HTTP gateways.

@skilesare today the asset canister is only certifying the body of the response. We have an idea for an enhancement that will allow us to certify the headers as well.
With certified headers in place, it would allow the service worker to trust cache control headers and cache certified assets in a secure way.


Hey @skilesare, can you elaborate on how you are using the icx-proxy fork? A little context could help me tell you how you might be impacted by some of those changes.

We use it to host a custom URL. We also have some extra code that handles range requests for video streaming for safari and some redirect code for handling content on storage canisters with more grace(without changing the URL).


Yes, we will make all the relevant code available such that anyone can run an HTTP gateway on their own infrastructure. The API boundary node code will also be public like the replica code today.


Is there going to be an economic incentive to run a HTTP Gateway?

I believe the current intent is “NO”, but API-boundary nodes will.

The intent is that the NNS accepts the API-boundary nodes so the community can keep control on the minting rate. Since HTTP gateways are not regulated by the NNS, they also do not receive ICP from the NNS.

Of course, if it turns out this is a problem, then I can imagine, there will be new iterations (just like decomposing the functionality of boundary nodes is itself an iteration).


Just wondering why someone would run a HTTP Gateway if not out of pure kindness :thinking:

One incentive would be to keep access to your (IC-based) site available - just like some companies contribute to OpenSource projects they would have an interest in keeping the IC alive


We are working on something similar, not sure if we should also call it boundary node. It’s Java/JVM based node that can open connection from/to canister to different proprietary systems like Kafka or DBs (Oracle, MySQL). I assume such nodes will mainly run on private networks, such systems are using non HTTP protocols to connect and they are not typically exposed to public internet. Yeah, we can call it Oracles even if I do not like much that term. Maybe rather integration nodes. With our IC Apache Camel integration and Apache Karavan VS Code plugin we really want to minimize development (no code or minimal code) and deployment to internal Kubernetes/Docker infrastructure. Such components can be even pre build, to connect to existing IC services. Just trying to figure out the best terminology, to make it easy to understand. I am going to work on short video, to demonstrate dev/deployment experience.


Is there any status / timeline for adoption of AMD SEV-SNP? Or is it already implemented?

1 Like