Boundary Nodes as Censors

@harrison has come up with what is in my opinion a brilliant potential path for dealing with the weighty censorship issues that the community has been facing since the Super Mario 64 incident. Please weigh in on this proposal. Various people have been discussing this behind the scenes but it’s time to bring it to light. Let’s see if this could work.

The idea is to move censorship to the boundary nodes. We force all canister interaction through these nodes, and we make them legally accountable for the content that they allow to be served to their clients. If a boundary node operator receives a DMCA request (or any other legal request), they have the option of blocking the offending canister according to their own internal decision making process.

To avoid consolidation of censorship power into one main tyrannical censor, anyone should be allowed to run a boundary node. Obviously all of the boundary node code should be open source. But the boundary nodes would remain separate from the IC protocols, not participating in consensus, only serving as the gateways to the Internet Computer network.

This idea may be a great compromise between those who want total censorship-resistance and those who want to make sure harmful content can be stopped. The core IC protocols would remain censorship-resistant, and anyone could spin up boundary nodes to serve content. But each boundary node would need to find a place in this world to operate. Considering each boundary node instance will not inherit the decentralization properties of the IC, it may be difficult to run a non-legally-compliant node, but may still be possible.

For example, DFINITY may continue running the small number of boundary nodes that they currently run at But we may also see other boundary nodes at,, or any other domain name. Those running the boundary nodes will need to interface with the centralized world to provide their services. If DFINITY doesn’t do a good job, then other interested parties may spin up boundary nodes. We may see multiple boundary node operators competing to offer the best gateways into the network.

Combining boundary node censors with plausible deniability for node operators, we may move the responsibility for dealing with most of the less-egregious legal issues from the node operators and the NNS to the boundary nodes. They can take the brunt force of legal complexities, and a decentralized network of boundary nodes can serve the people’s varying interests. More existential issues, such as a Silk Road 2, may require much more contentious action, such as an NNS vote. But boundary node censors may be a stop-gap solution that can help us get to the next step in figuring out what censorship-resistance on the Internet Computer means.

We need to act quickly. Super Mario 64 was just the beginning.


I wholeheartedly agree, its not even over yet, Mario is back and Pokemon is following him, its just a matter of times before we see a new proposal.

I think @harrison proposal is a good compromise, I only have 1 question, would boundary nodes still receive ICPs for their work, if so we need a way to reward nodes with better hw, connection more than bad ones, not only to provide a better experience but also to limit the amount of minted ICP, right now nodes are limited by the foundation mainly to counter inflation, if anyone could host a node on a rasperberry inflation would skyrocket.


Then you force technical IT server-managing people to also be legal experts and takedown request-parsers. They better be paid well otherwise we will end up with too few boundary nodes for high-bandwidth apps. I prefer the IC to handle this for node operators, in a crypto court system like Kleros.

This is maybe an immediate interim solution but not an elegant one.


How does this solve the issue of child porn being uploaded to the IC? Because this will happen. It only solves the issue of ordinary node providers not being responsible for it. Although this isn’t entirely clear.

So then what is the profile of a boundary node provider? Honestly I am not sure who on earth would want to be a boundary node provider. It is either legal risk from governments or a risk of loss of revenue if they go offline.


IRL service providers just shut down the service if there is a DMCA violation, they dont verify anything, its up to the offended party to contest it and if there is a dispute it goes to court.

1 Like

Then trolls will just DMCA everything on the IC.


CP is easier to deal with and can be banned by the NNS, thats cause its evident something either is CP or not, DMCA is abusable and copyright laws aren’t simple, thats why they are settled in court by experts.

1 Like

This is a valid concern.

This approach is used very successfully by IPFS. See Legal | IPFS. is an IPFS gateway run by Protocol Labs that has it’s own content policy, however anybody else can run an IPFS gateway (for example Fleek has it’s own IPFS gateway), and we can have our own separate content policy, just as anyone else in the world can run an IPFS gateway and set their own policy (or decide to have none). The important part is that the censorship happens above the core protocol. Both IPFS and Filecoin protocols do not have any censorship at the protocol level - it is all handled at the gateway level, and it works great.

My idea is essentially for the IC to adopt the exact same approach.


Are boundary nodes equipped to deal with tons of DMCA take down requests? Do they have any incentive to not automatically take down everything that has a takedown request and adjudicate it later?


Analogous also to Arweave Wiki Content-Policies (
This is the way to go.


How would you propose enforcing this policy to limit the power of the NNS? Currently the NNS has the power to do anything.

For IPFS, do they choose (however IPFS governance works) not to censor at the protocol level or is it not possible to censor at the protocol level?


It’s not possible. Which is the way it should be for all protocols.

My recommendation regarding limiting the power of the NNS would be that after the boundary nodes are decentralized, a proposal should be submitted/voted on that essentially removes the ability for the NNS to vote canisters off the network. Therefore making it impossible for the IC protocol to censor.


Can we clarify what boundary nodes do in the first place? In my limited understanding, they are a “middle man” for data traffic between a subnet and an end user. What are their speed requirements compared to a node in a subnet? How many boundary nodes do we currently have on the internet computer? Would running a boundary node be appealing anymore with these added complexities? How easy is it for a boundary node to censor the content they serve?

Agreed that we need interim solutions as we work to decentralize the network and get plausible deniability online for nodes.


As someone who runs one of the largest IPFS gateways, I can confidently say that yes it is quite easy to deal with. We’ve been running an IPFS gateway for over 2 years that does 600TB of data transfer a month, and we’ve actually never received a DMCA. Bc one thing to keep in mind is similar to Web2 and IPFS, the first line of defense will always be the user facing app/interface/url. For example if something gets posted on DSCVR that infringes, the DMCA is going to go to DSCVR first, not the Boundary Node/Gateway operator. It typically would only then go to the Boundary Node/Gateway operator if the app/interface didn’t listen.

The main issue with the IC right now is the foundation serves all content for the entire IC via So if you solve that problem by decentralizing the boundary nodes and allowing anyone to run a gateway, then you can get rid of the NNS/protocol having anything to do with censorship, which is how it needs to be for the IC to have any chance at succeeding.


In the case of DSCVR, the only reason it’s not getting to the node provider is because they are a “good actor.” Would it be safe to assume anyone putting child porn or something similar on the IC won’t be as cooperative?

1 Like

Thats a fair assumption. But in that case as I mentioned it could be handled by the gateways or other layers above the protocol as second and third lines of defense. Which is very similar to how Web2 works (if the app/site doesn’t listen, typically then it will go to AWS or whatever platform the content is hosted on, or to DNS, or the app stores, etc.). And the system doesn’t work in 100% of instances but that’s ok. The important part is the internet itself isn’t involved in censoring/keeping things off the internet completely. It’s always handled above the base layer. Censoring at the base layer is a death sentence for the IC.


I’m interested to explore this idea, sounds quite promising and elegant.

One thing to remember is that even if canister takedowns are removed as a proposal type, I don’t believe it’s necessarily permanent as it could always get voted back.


Makes a lot of sense, thanks Harrison and Jordan for sharing. Maybe early to say, but this feels like something very worthy of the community pushing for. Would be great to see consensus develop, curious to see if some of the folks with strong opinions agree.

One philosophical note–if a proposal passed to remove NNS power to censor, could it not be compelled to just put that functionality back in the future?


it could. but that’s true of any protocol with on chain governance, the IC is not unique in that regard.

i think the bigger issue is the foundation’s messaging/culture/stance around the issue. with any other web3 protocol, it is very well understood that censorship at the protocol level is absolutely unacceptable and goes against everything Web3 stands for. and if any protocol voted to start censoring, I think it’s well understood that most of that protocols community would leave the community (or fork the project and re-launch it without censorship), and the original protocol would die. I think the same would happen to the IC if they don’t remove it, or if it was ever voted back in.