NIP-10: Nym Exit Policy Update – Opening Ports for Dash, SIP, Voice, TeamSpeak, and Litecoin Services

General
,
1

NIP-10: Nym Exit Policy Update – Opening Ports for Dash, SIP, Voice, TeamSpeak, and Litecoin Services

ID title created status kind author(s) champions
NIP-10 Nym Exit Policy Update – Opening Ports for Dash, SIP, Voice, TeamSpeak, and Litecoin Services 31-03-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

NIP-10 proposes updating the Nym exit policy to open specific TCP and UDP ports, enabling NymVPN users to access Dash network, SIP, Voice, Filetransfer, TeamSpeak, and Litecoin P2P services while maintaining privacy and network security.

Motivation

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

Dash, SIP, Voice, TeamSpeak, and Litecoin P2P services require specific TCP/UDP ports. Currently, these ports are blocked, limiting NymVPN users who rely on these services. Opening these ports improves usability without compromising privacy or security.

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

Proposal to Enable Ports for NymVPN Users

TeamSpeak Services

  • Voice: UDP 9987
  • Filetransfer: TCP 30033
  • ServerQuery (raw): TCP 10011
  • ServerQuery (SSH): TCP 10022
  • WebQuery (HTTP): TCP 10080
  • WebQuery (HTTPS): TCP 10443
  • TSDNS: TCP 41144

Cryptocurrency / P2P Services

  • Litecoin P2P: TCP/UDP 9333
  • Dash network: TCP/UDP 9999

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.

1 Like
2

Hi guys !!
Hmm overall I’m in favor of the direction, a few things I want to flag before this goes to vote though

The TeamSpeak bundle makes sense i guess. It’s still widely used in gaming communities and private orgs that don’t want to touch Discord :laughing: , so opening those ports is a genuine usability win. No strong objections there

The crypto P2P ports (Litecoin 9333, Dash 9999) I’m more mixed on. Not against them in principle, but running a Dash full node or masternode behind an exit gateway is the kind of traffic that can raise flags with certain hosting providers, especially given PrivateSend. Operators on more restrictive VPS contracts might inadvertently be in violation of their ToS without realizing it…

The bigger concern for me is UDP 9987. Open UDP voice ports on exit nodes are a classic DDoS amplification vector, it’s exactly why Tor has historically kept these closed. I’m not saying it’s a dealbreaker, but I’d want to know how the NTM handles rate limiting on that port specifically before voting yes. Is there any mitigation already baked in, or is that assumed to be handled upstream?

Last thing: is there any plan to make this opt-in per port at the operator level rather than all-or-nothing? In my case I run nodes on residential lines or with hosting providers where P2P crypto traffic is more of a concern than TeamSpeak. Having the granularity to say “yes to TS, no to Dash” would be useful for me…

Happy to vote YES if the UDP amplification question gets addressed

Thanks for putting this together :blush:

3

Hey @koutakou and thank you for your response.

The situation of operators vs ToS of some providers is of a dynamic nature by the design. The reality of running nodes for a Mixnet + WG network (Nym) - on decentralised foundation, serving as a privacy web for clients (the VPN / product) - with an aim to attract every day users, will inherently be always testing the limits of what providers can handle.

There are a few ways to deal with that:

  1. Keep the discussion with the users (requiring broader exit policy → better UX) as well as with the operators (requiring not end up with their nodes being shut down) as well as with the providers themselves, educating them. While at the same time keep looking for new providers and sharing these findings with each other through our community counsel pages. And unfortunately sometimes migrate from bad providers to good ones (excuse my tor language :smiley: )

  2. Be conservative and don’t open questionable ports. This would make it easier for operators but less attractive for users

  3. The opposite of previous point with the opposite impact.

I am for point 1. And I am committed to make it work to find the ground on which the users and operators can meet, and preferably can invite as many providers as well.

This of course takes quite some work and listening to all sides well as well as aligning the rewards be that by tokenomics or the various programs we have in place to support people running nodes.

4

Of course for you the situation is very specific as you run residential type of nodes. We can talk about needed support in that situation here or in DM, depends on your comfort.

5

To your technical questions.

  • Dash: I think that we should be opening ports for people using various blockchains as metadata leakage is one of the major problems for those users and therefore it’s something we have to count on as a problem to solve for the operators.

  • Voice ports: I was not thinking about any rate limit, but this can be a solution. Do you have in mind a more concrete proposal regarding that? We have already rate limit on 465 as you can see here in NTM.

Let me know what you think. I will wait until tomorrow afternoon to open the vote to make sure people have space to voice their opinions.

1 Like
6

Hey @serinko, appreciate the framing. That’s how I read it too, and honestly I’d rather build in that messiness than pretend there’s a tidy answer waiting around the corner

Option 1, no hesitation. Running a residential node with all the ambiguity that comes with it is kind of the whole point for me. I’m not here to wait until someone else has smoothed the path. I want to be part of the people laying the stones :grin:

On UDP 9987 I’ve been turning this over since I saw your message. The srcip hashlimit that works on 465 doesn’t really translate here because the whole threat is spoofed sources, the attacker never shows their real IP, so locking on srcip just doesn’t catch it. The amplification lives on the outbound side: small forged packet in, big TeamSpeak response out toward some poor third party

I don’t have a polished solution to hand, I’d want to actually sit with it and test before claiming otherwise, but my “instinct” is that dstip-based rate limiting and an outbound packet size ceiling would do more work than what’s there now. Caps the amplification ratio even if you can’t identify the real source. Worth exploring together if you’re open to it. I’m happy to run experiments on my own nodes once there’s something concrete to try

Voting YES when it opens. Let’s keep building :rocket:

7

I have to catch up with you on this and with the level that you are familiar with this topic. Overall sounds great.

1 Like