# NIP-14: Nym Exit Policy Update – Opening Additional Ports for Applications and Community Services

Node Operators
,
1
ID title created status kind author(s) champions
NIP-14 Nym Exit Policy Update – Opening Additional Ports for Applications and Community Services 27-07-2026 proposed standard Serinko, Nym network technical lead & devrel serinko@nymtech.net, Jaya, Chief of strategy jaya@nymtech.net Merve, Operator technical mentor merve@nymtech.net, Sudo, Head of community simon.toth@nymtech.net

NIP-14 proposes updating the Nym exit policy to open additional TCP and UDP ports requested by NymVPN users and the node operators community.

The goal is to improve compatibility with proxy services, gaming platforms, voice communication applications, decentralized services, remote desktop applications, and community-hosted infrastructure while maintaining privacy, security, and operator governance.

Motivation

The Nym exit policy defines which ports are accessible on exit nodes to ensure privacy, security, and reliable service.

The requested additions include:

  • Proxy Services – require additional port ranges for SOCKS5 and HTTP proxy providers.
  • DarkFi / DarkIRC Services – require TCP port 9600 for DarkIRC clearnet configuration support.
  • Space Station 14 Services – require TCP/UDP port 1212 for game server communication.
  • RustDesk Services – require ports for remote desktop infrastructure communication.
  • Syncplay Services – require ports used by official and community Syncplay servers.
  • Viber Services – require additional ports for Viber desktop communication.
  • WhatsApp VoIP Services – require additional ports for voice and video calling.
  • Nightfall.city Services – require port 1900 for community-hosted services.
  • AnyDesk Services – require port 6568 for remote desktop communication.
  • SPICE Services – require port 1923 for remote desktop protocol communication.
  • Croc Services – require additional ports for peer-to-peer file transfer communication.
  • Iroh Services – require UDP port 7842 for decentralized networking communication.
  • Telegram Services – require UDP ports for group call support and STUN communication.

This update will follow operator governance, consistent with previous exit policy changes (example).

Since NIP-1, exit policy decisions are managed via Nym Governator to ensure transparency and accountability.

Proposal to Enable Ports for NymVPN Users

Proxy Services

Nodemaven SOCKS5 proxy services:

*:1080-2080

Nodemaven HTTP proxy services:

*:8081-9080

Proxy-seller services:

*:10001-10999

DarkFi / DarkIRC Services

DarkIRC clearnet communication:

*:9600

Space Station 14 Services

Game server communication:

*:1212

RustDesk Services

Remote desktop communication:

*:21114-21119

Syncplay Services

Syncplay server communication:

*:8995-8999

Viber Services

Viber desktop communication:

*:5242
*:5243
*:7985

WhatsApp VoIP Services

WhatsApp voice and video calling:

*:5224-5227

Nightfall.city Services

Nightfall.city communication:

*:1900

AnyDesk Services

Remote desktop communication:

*:6568

SPICE Services

Remote desktop protocol:

*:1923

Croc Services

Croc file transfer communication:

*:9009-9013

Iroh Services

Iroh communication:

*:7842

Telegram Services

Telegram group call support, STUN services:

*:32001-32003

Stragglers

Battlefield / EA:

*:3659

Magic Wormhole:

*:4001

Jitsi:

*:4443

Note: Some of the ports are within already opened ranges, but we keep them in the NIP for transparency. If the ranges already include the newly proposed ports, they will stay as they are.

Voting options

Voting takes place at Nym Governator. Proposed options:

  • YES: Approve opening the above ports.
  • NO: Reject the proposal entirely.

Submit any concerns with supporting documentation for review before finalizing.

Process

If the vote meets quorum and a majority approves:

  1. A pull request will update the exit policy.
  2. The Network Tunnel Manager (NTM) will be updated to allow operators to configure WireGuard exit policy ports in line with the Mixnet policy.

Background

The Nym exit policy protects operators and users by controlling accessible ports.

Previously, Network Requesters used a centralized allow list. To decentralize control and enhance privacy, Nym transitioned to a deny list, forming the current exit policy.

Exit nodes in Gateway mode act both as:

  • SOCKS5 Network Requesters
  • Exit nodes for IP traffic from mixnet and VPN clients

Applying a uniform policy ensures reliable, privacy-preserving service for all NymVPN users.

More Ports for Games | New Feature?
Can't connect to custom ports
Suggestions to open more ports
2

@rwrv1 @Numbless @Lando

2 Likes
3

This proposal is scheduled to be published on Governator within the next few hours and will subsequently be submitted to the operators for voting. Once the proposal has been published, no further additions or removals will be possible.

If there are any ports you would like to have included, please submit your requests as soon as possible to ensure they can be considered before publication.

4
1 Like
5

I see that Hermes Stakepool rejects this NIP, I’m curious to know the reasoning behind that.

1 Like
6

in a nutshell, the reason is, that he is not an fan to open up mass ports on exit nodes.
and i agree with him.

furthermore also agree that the consensus for voting for nips has to be improved.
it makes no sense that some people which don’t run an exit node but they are able to vote for.

regards

2 Likes
7

Yes, I was wondering about the same. I think it makes sense not to open dozens to thousands of consecutive ports, but opening several ports to allow a certain service to work should be OK.

As I stated previously, the Internet is more than just websites and mail, and opening just 80 and 443 is not enough for normal Internet usage, and having to disable VPN for other services to work may be far more dangerous for some people than having these ports open.

I can understand not opening ports for a game that uses a random port from a range of thousands or anything even remotely like that, but I think that allowing certain services to work that people may really rely on is crucial for Nym. It’s important for privacy (not having to connect outside the VPN), usability (not having to worry something won’t work), and trust (non-tech people won’t complain that the service is broken and more people will be satisfied with it).

I think that ultimately there should be more discourse around this issue, and the community should be more vocal if someone thinks that certain ports should not be open.

Regarding the way voting is performed, I don’t have much to say because I am not competent enough in how all the crypto/blockchain/consensus stuff works in Nym, so I can’t really say whether I agree with you on that or not.

8

Im also not an pro operator.

I had my node approx. 9 month, then it was the decision to extend or not.

After some considerations i decided to shutdown the service for now.

Furthermore, there is no rocket science that is not a good idea to open up mass port ranges and give the none exit node ops the power for voting which has nothing to do with them.

And yes, i have some basic knowledge but other op like @wunderbaer from hermes or @starryxyzstarryxyz have much more experience and knowledge.

if we want to lead an basic discussion about this we need some advanced op’s like these ones.

fourtunately some members from nym team like @serinko has also mentioned in the op chat that he is willing to listen to the exp. node ops.

nym has to decide which way they want to go here but i think its always an good approach to listen on the pro ones and not blindly trust the masses

BTW:

This is not an attack or an offense against the nym team, its just some points which may should be discussed to improve the nym network and their statement for privacy overall so really no offense

Regards

3 Likes
9

Hi everybody,

yes I am indeed not a fan of opening thousands of ports within one NIP.

starryxzy summarized it perfectly in the Matric channel:

1. The Misleading Nature of NIP

The current NIP lacks a neutral stance, emphasizing only the positive aspects of this decision while rarely mentioning potential negative impacts. Since operators cannot fully understand all the implications involved, there seems to be no reason to vote against it.

2. The Misleading Nature of Port Descriptions

Binding specific ports to specific services in the narrative is fundamentally flawed. You can justify opening thousands of ports based on gaming requirements, but we have no way of knowing whether this simultaneously opens permissions for hundreds of other unintended services. Except for privileged ports, there is virtually no one-to-one mapping between ports and services.

To some extent, this answers Konstantin’s question: it’s not about which ports carry exceptionally high risk, nor is it about whether we should open ports for WhatsApp specifically—rather, it’s that we fundamentally don’t know what we’re actually allowing through.

3. Current Port-Opening Policy Lacks Security Logic

We’ve turned port-opening into a “dependent variable” of user growth and user demand. Clearly, the more users there are, the more services they use, and the more ports need to be opened. Port-opening doesn’t reflect security principles—instead, it appears to be a milestone tracking user growth and increasing demands.

Another self-contradiction we exhibit is that we’re actively soliciting opinions everywhere about which ports should (not must) be opened—as if our use of a whitelist isn’t a security strategy, but rather a sign of lack of imagination. It’s as though we simply don’t know what other ports should to be opened and require others to enlighten us.

4. Asymmetrical Operator Attitudes

First, there’s an inherent structural flaw: we allow mixnet nodes to decide the port policy for exit nodes (through voting). For mixnet nodes, this is a decision-making process that carries no direct risk for them. However, given the limited number of mixnet nodes, this hasn’t yet had a significant impact.

Second, only a minority of operators actively pay attention to their own node situation and the broader NYM ecosystem; most simply follow “herd behavior.” This is most evident in NIP-5 and NIP-6. In the NIP-5 example, when 57% of nodes completed voting, the final outcome was still unpredictable—we still didn’t know whether the new quorum threshold would settle at 15% or 20% (At that moment, the gap might only be several hundred thousand to over a million tokens.). It wasn’t until the 20% option gained a slightly noticeable advantage due to some unexpected factors (2-4%) that it won overwhelmingly, with final votes for 20% being twice those for 15%. This is clearly not a rational outcome.

The 57% refers to the proportion among nodes that actually voted, not the proportion of all nodes in the network. In NIP-5, over half of the nodes didn’t cast any votes at all.

5. Official Expectations in Voting

Claiming that the official team had no expectations regarding voting outcomes is simply dishonest. If this were a genuine need, having a vote rejected would mean some staff member would need to face users and explain that their request has been denied—and that’s not easy work, even setting aside the question of potential user attrition.

Through various interactions, the operator will sense the team’s expectations, and this will inevitably influence the final result.

6. The Core Contradiction

However, this inconvenience—a necessary consequence of abuse prevention—is an inherent trade-off built into the current system to support sustainable development of decentralized VPNs. Because decentralized VPN operators aren’t large enough in scale, they lack any bargaining power—providers can even terminate service without notification. If each node generates 10% monthly profit, single node can afford service termination at most once a year before falling into losses. Not to mention other potential legal issues.

Exit policy whitelisting should imply the principle of “no opening unless necessary,” where “necessary” means the threshold for changing rules should be very high, rather than a series of resolutions being initiated and passed at high frequency.

If we cannot decline user requests and honestly tell users what additional benefits a decentralized VPN offers compared to centralized VPNs, and what they might lose, we cannot resolve this contradiction.

I personally am not opposed to opening ports, and I believe most operators share this view—but with the prerequisite that these decisions must genuinely enhance the community’s overall interests, and that the process itself be necessary and deliberate. However, our current logic on the port-opening issue is extremely crude, or arguably doesn’t exist at all. I believe this point is equally indisputable.

**What I’ve stated above is simply a factual observation—it should not be viewed as an attack on any individual.
**
—-

This said, the vote has concluded and there isn’t much we can do. I am considering starting a “negative NIP” to have those ports closed again. It simply doesn’t make any sense to open thousands of proxy ports for one specific service that was requested by one single user…

Thanks Wunderbaer
Hermes Stakepool Germany

4 Likes
10

While I am not a node operator yet, I fully support the opinions from both of you.

For me it makes absolutely no sense to open ports for gaming, streaming, torrenting or so called “social media” sites, where users have already registered and can’t in advance register without giving any details away.

Mixnet friendly services, which do not consume a lot of bandwidth, or at least Mixnet friendly websites for regular browsing / education / repositories etc. are mostly welcome by operators, I guess.

For all other tasks NymVPN users have fast mode and operators of such entry and exit points should allow all traffic.

To help operators like you, maybe it would be a good idea, that the Nym team could consider two versions of NymVPN. A NymVPN lite version, which only has fast mode and no anonymous mode and a standard edition like we have now.

This could also attract more new users if this lite version would be cheaper in price like the current version we have and gives these users the required privacy for their daily streaming, torrenting, social media which they are already registered with.

Best regards
Ch1ffrepunk

11

Hey,

thanks you for your opinion. I do understand where you come from and honestly share similar thoughts about the gaming/SoMe side. I don’t see a great usecase for gaming over VPN anyways (latency, no need for privacy since you are registered anyways, etc) and from what I understood it was a single user’s request who sometimes host the gaming server for other players and doesn’t want them to see his real ip/location. But even if this was techncially valid I consider this an edge case.

But my concern is a different one also for the VPN (Fast mode) side of things. We all have to understand that exit operators are exposing themselves to serious risks. From abuse complaints that need to be answered in time, possible shutdown of their vps (often without compensation → financial loss, to having their home raided (happened to TOR opeerators in the past). And for that reason the exit operators should be the only ones to decide over opening ports or not. It’s simply nonsense to have people vote that aren’t affected at all… :smiley: I had the legal side of this checked at least for Germany (with the support of NYM) and while it is legal under german and EU law it’´s a thin line to walk. Even if you are legally “safe” the above mentioned things can still happen - and will happen at some point! One of our main lines of defense is “This exit follows a policy that aims to restrict abusive use as much as possible” and that has worked with abuse complaints in the past at least. The more ports we open the more ridiculous this argumentation becomes. How shall I or my lawyer prove our point about a “restrictive exit policy” when we open three thousand random ports for what ever service (“proxy services”, lol) at once based on a community vote of mainly people not affected by the decision. Sorry that’s simply nonsense. And that also means I would disagree with your plan to open NymVPN/Fast-mode completely tbh. This would expose the exit operators to magnitudes more of abuse complaints (expecially DDoS and Mail spam) imho. I haven’t thought about the Mixnet side of things in detail tbh…

Long story short:
We have to decide if we want to have a “general open” policy and add blocks as we go, or the other way around (which is the status quo at the moment). I would advocate for the later as it has proven to work for NYM as well as for TOR.

For this specific NIP I would suggest we remove all the ports for proxy services from the allow list again and only keep the ones for specific game services (as we have a good argumentation why these ports have been opened). Then have another NIP for the three port ranges in questions. This new NIP should be lead by a discussion beforehand WHO requested these ranges for WHAT type of service exactly.

Going forward from here I vouch for allowing exit node operators only to vote on opening ports. Everything else makes no sense imho.

Thanks for listening,

Wunderbaer

@serinko @jayapapaya

4 Likes
12

Sorry, I did not knew yet that the same nodes are used for fast mode too. In that case you are absolutely right and I apologize for not knowing this yet!

Best regards
Ch1ffr3punk

2 Likes
13

Yes it’s the same nodes, but different ports and protocols… :slight_smile: A node can basically be:

NymVPN: Entry/Exit
Mixnet: Entry/Mixnode/Exit

1 Like
14

Thanks for explaining this to me! My plan is to run soon an exit node with the following settings:

./nym-node run --id mynode --mode exit-gateway --open-proxy false --nr-allow-local-ips true --accept-operator-terms-and-conditions etc.

What I like to archive with this, is that regular NymVPN users can not use the clear net Internet, but that I can offer Nym internal services on my VPS server pointing to local IP addresses / ports from server applications, where in some cases Nym’s nym-client or nym-socks5-client users have to pay anonymously via zk-nym, to use my services.

This will not apply to my upcoming NymX Mail architecture, as it is free of charge and does not need NymVPN, in order to work globally and decentralized, for journalists, activists, whistle blowers or privacy enthusiasts, while maybe using a USB stick in an Internet Café or public library etc!

Best regards
Ch1ffr3punk

15

Hey @wunderbaer
Thank you writing this up. there are also some points written by @oceanus to be posted on this topic. I would like to merge all of these opinions and proceed as fillowing:

  1. Share all opinions here
  2. Setup a call between operators and Nym represented by me and @merve
  3. Create a solid one proposal from those
  4. run it through Nym exec as well to get some feedback from VPN users side
  5. Put it into a vote

Let me know what you think about this flow.

1 Like
16

Hi @serinko - thank you very much for picking this topic up! Yes, sounds like a solid plan…

Reg. what you said about @oceanus - is this something you want me to collect from the Matrix channel or will you do that? didn’t quite understand…

Thanks Matthias

17

I would like to submit one proposal for consideration.

I am unable to participate in the discussion or the call, so I am putting my full position in writing here. I will not be able to participate in the discussion in the thread, but I hope you will judge the proposal on its content.

I am not asking for a concrete solution to be decided here, as this is outside the scope of this NIP. I would like the following question to be considered: what responsibilities currently remain with Exit operators, and how might that responsibility structure affect Exit capacity?

I previously operated several Exit nodes, but after receiving repeated abuse notices, I converted them to Mixnodes.

Under the current structure, ordinary operators are increasingly likely to avoid running Exit nodes in order to avoid legal risk, as I did.

Over time, this creates a selection pressure toward operators who are able to bear the legal risk of operating an Exit.

Effective protection for Exit operators is one of the important factors in maintaining sufficient Exit capacity.

This is not simply a question of reward levels, but a design issue concerning the structure of the legal burden placed on Exit operators. Increasing rewards may increase participation, but it does not reduce the underlying legal burden directly borne by Exit operators.

Port restrictions are similar. Reasonable port restrictions may reduce some forms of abuse, but they cannot remove the underlying legal burden on Exit operators. Some traffic cannot be identified by port at all (BitTorrent is one example), while some traffic cannot be distinguished as legal or illegal based on the port alone (copyright infringement over HTTPS, for example). No matter how we adjust the granularity of the Exit policy, we cannot control whether an abuse notice is generated in the first place.

I support narrowing the ranges discussed in this NIP, and I also support @wunderbaer’s position that voting on the Exit policy should be limited to Exit operators. However, neither of these changes the underlying structure of the responsibility borne by Exit operators.

I see two possible directions for consideration.

Option 1 — Nym operates the Exits

Structure: This would have the same basic structure as a conventional VPN provider.

Advantage: The cost of the relay layer would continue to be covered by operators. Nym’s exposure would be limited to the Exits, with a more predictable upper bound.

Disadvantage: Residential IPs could not be implemented.

Option 2 — Nym provides legal support for Exit operators

Structure: Exit operators would be responsible only for keeping the node running, while Nym would handle abuse responses and the necessary follow-up.

Advantage: Operating Exits on residential IPs would become possible. A major barrier to an individual running an Exit on a home connection is legal risk. If that risk is reduced, the number of participants may increase. As a result, this could increase Exit capacity and contribute to greater anonymity.

Disadvantage: Nym’s operating costs and legal exposure may increase. However, this is the same general type of burden that VPN providers normally carry.

I am not advocating for one option over the other.

My request

I would like this issue to be added to the agenda for the operator call alongside the port range discussion.

The port issue is worth solving in its own right.

However, Exit operators currently bear the direct burden of responding to abuse and legal matters concerning traffic that they cannot inspect themselves and for which they cannot choose individual connections.

Unless this changes, I expect converting to a Mixnode to remain a rational response for any operator who receives a notice.

I am not asking for an immediate decision on this issue as part of this NIP.

I simply believe that it is worth discussing as a structural issue that cannot be resolved through adjustments to the Exit policy alone.

2 Likes
18

Hi @userm5 - Thank you very much for your thoughts and your general support!

While I am not part of the NYM core team I would still love to give my thoughts on your two proposed solutions.

While it might sound like good ideas at first glance I personally think both approaches are fundamentally flawed and undermine the privacy and resilience concept NYM is based on.

Option 1:

As you said yourself the EXIT nodes are the heart of any vpn/mixnet/privacy system and by centralizing all exits into the hands of one entity basically gives up NYM’s vision of a distributed and censorship resistant network.

Option 2:

It sounds daunting to have the NYM team cover the abuse complaints and follow ups, that’s simply not realistic. I am not a lawyer but how you reply to abuse complaints and what that legally means for you personally would be different for each and every jurisdication which itself would alread make it impossible for NYM to handle. For example an operator located in europe would refer to EU law to defend his operations (e.g. “Why it is within the legal boundaries to operate this node under law XYZ”) and completely different for an operator from the US or elsewhere. I don’t know how we would think NYM could handle this. Plus I could imagine it also changes the situation drastically when NYM takes this over on behalf of their operator as they then, technically, become one “enitity”. Again I am not a lawyer but it’s similar in general labour law when working with freelancers. If you include them in your regular day-to-day processes they are not freelancers anymore, but employees, generating completely different legal liabilities for the company. So I could imagine this being similar when NYM starts acting on their operator’s abuse complaints.

Furthermore when a case should indeed go to court for some reason the costs for that could quickly reach very high amounts - economically not feasible for NYM to cover that for each and every abuse complaint.

So as far as I am concerned I think that’s the wrong way to tackle this.

What we would need instead is a solid framework for exit node operators to act on if they are willing to. This includes, but is not limited to:

  1. A much stronger voice for exit node operators to decide which ports/services are being opened. I would even advocate to only have exit node operators vote on port changes and completely dismiss voting for these decisions for entry and mixnode operators. Who takes the risk also makes the decisions.

  2. A clear educational path for interested operators what opening additional ports (possibly) means in regards to amount of abuse reports, court orders, etc. to make sure they can take educated decisions.

  3. A best practices documentation that exit node operators can follow. Like local laws for several countries, recommendations on useful insurances, creation of legal entities to mitigate personal liabilities, etc. This could be a community driven but NYM supported initiative, maybe.

  4. A compensation model that covers more than just the bare minimum for exit node operators (as in even higher rewards for exit nodes in comparison to entry/mixnodes) that makes it more attractive (and financially stable) to run an exit node at all. This might be the most complicated one tbh as it heavily depends on the success of NYM as a profitable network.

Hope that makes sense and happy to discuss further in the next call :slight_smile:

2 Likes
19

I think the intent of my original proposal was not fully understood. I apologize for not making this explicit, but my concern is that the network has no control over where Exit node operations become concentrated. The entities capable of absorbing these risks may include not only large private operators, but also entities with state backing.

My proposal raises the question of what responsibilities Exit operators currently bear, and how that structure affects Exit nodes, as an issue that cannot be resolved through expanding port restrictions alone.

I am not considering how to make Exit node operation a financially sustainable business.

My concern is whether NYM can actually maintain the properties that an anonymity network is supposed to have.

For anonymity and resilience, I do not believe that the number of Exit nodes alone is the most important metric.

The distribution of the entities operating them is also important. If the legal and abuse-related risks associated with operating an Exit are too high for individuals and small operators, those operators will eventually leave, leaving only operators with sufficient capital, legal resources, insurance, and infrastructure to absorb those risks.

That is precisely the concentration problem I was trying to raise.

Your suggestions of higher rewards, insurance, incorporation, and legal advice all address the question of how to continue operating despite the risks.

What I am asking is why Exit operators are structured to bear those risks in the first place.

The current responsibility structure could reinforce the concentration of Exit operations among operators with the capital, legal resources, insurance, and other resources needed to absorb those risks.

If even higher rewards cannot cover these costs, economic rationality may eventually lead to a concentration of operators as well.

Based on your response, it seems that we are not discussing the same problem.

From my perspective, the question is not “How can we make Exit node operation a sustainable business?” It is “How can we design the network so that operating an Exit does not require the level of risk tolerance and resources of a large corporation, while maintaining the decentralization necessary for anonymity and resilience?”

If this cannot be addressed, I do not believe that simply increasing the number of Exit nodes will solve the problem.

I would like us to consider whether the network has a structure that can preserve decentralization and resilience, while remaining safe for the people who actually use it.

20

this could be the legal form of an association by and for nym operators?