VP.NET on Building the Unbreakable VPN: Hardware-Sealed Privacy, SGX Architecture, and Why Data Shouldn’t Exist

At a time when “no-logs” promises are easily broken and VPNs often trade trust for convenience, VP.NET is forging a radically different path, one rooted in cryptographic guarantees, hardware-based isolation, and an uncompromising vision of user freedom.

In this in-depth interview with the founders of VP.NET, TechNadu explores how a team of privacy maximalists, cypherpunks, and technologists came together to eliminate the word ‘trust’ from the VPN equation entirely. From Mt. Gox-era security failures to the fallout of 2020’s global surveillance awakenings, each founder brings a unique personal and technical journey that shaped their zero-compromise approach to digital privacy.

They walk us through the SGX-powered infrastructure that physically prevents data collection, explain how their VPN service can’t spy on users, even if compelled by law, and share why building in the U.S., under full legal transparency, may be more accountable than hiding behind offshore jurisdictions.

Whether it’s triple-layered identity abstraction, plans for anonymous payments, or ditching browser extensions for a privacy-first browser, VP.NET is challenging everything we’ve come to accept about online anonymity.

Read on to discover why the team behind VP.NET believes the safest data is data that never existed and how they’re turning that principle into a next-generation privacy platform.

1. Can you walk us through your professional background, especially the pivotal moments or experiences that shaped your views on digital privacy and security? What personally motivates your commitment to the mission behind VP.Net VPN?

Andrew: I’ve been heavily focused on privacy from the earlier days of the internet when IRC (Internet Relay Chat) was the world’s peer-to-peer social network. IP addresses were exposed on IRC, publicly, and thus IRC bouncers became both a vanity and later a need (to protect against IP-based attacks for privacy).

Since then, I’ve been actively working in the privacy space and participating in the various communities that have popped up therein (like Bitcoin).

My personal motivation for VP.net stems around hardline privacy maximalism. I was sidelined for a while, which I’ll probably discuss publicly more in detail in the future. That said, the mission to provide privacy to the whole world never stopped, and the timing and team consisting of real cypherpunks is going to finish what those that came before us started.

Matt: 2020 changed the way I see the world. I have always been an entrepreneur, starting businesses in insurance, construction, import, and hardware distribution. Business has always been my passion.

But 2020 opened my eyes to a harsher reality. I saw how quickly freedom can vanish, how easily dissent can be silenced, and how surveillance was no longer a distant fear but an immediate threat. I knew I could not stay silent.

In 2023, I launched my podcast to encourage people to think for themselves, question dominant narratives, and defend their freedoms. Its success allowed me to connect with many like-minded individuals who believe in individual liberty and personal responsibility.

Privacy is freedom. That is what motivates VP.Net. We are building freedom tools that protect people from surveillance and data compromise, not just because it is good business, but because it is essential for preserving human freedom.

Mark: Mt. Gox destroyed everything I believed about security.

I was doing everything right, including proper cryptography, defense in depth, and essentially following every best practice in the book. I genuinely thought we'd built something bulletproof. Then I watched it all vanish because of attack vectors the world never saw coming.

The users who trusted us lost everything. The weight of losing users' funds is a weight you carry forever. You realize that no matter how good your intentions, no matter how careful you are, centralized repositories of data create massive single points of failure. The recent Coinbase AML leak just proved the pattern holds—even world-class teams with unlimited resources can't escape the fundamental problem of having data to lose.

While we were able to recover a substantial amount of funds at an order of magnitude higher value and return these to customers, nevertheless, the experience completely rewired how I think about privacy and security. At VP.net, we're eliminating the need for guardians entirely.

Using Intel SGX enclaves, we built a system where your traffic is anonymized in hardware-sealed environments that even we can't access. Mixing happens in verifiable isolation, your connection emerges unlinkable, and there's literally nothing sensitive to steal or subpoena.

The broader vision is simple: the safest data is data that never existed.

Every breach starts with something being collected and stored. Every privacy violation begins with surveillance infrastructure that seemed reasonable at the time. We're betting that the future belongs to systems that treat user data as toxic waste rather than valuable assets.

Mt. Gox taught me that even perfect execution can fail catastrophically when the architecture itself is flawed. This time, we're building the architecture so that even the most sophisticated attackers, and not even ourselves, will ever have access to data that doesn't even exist.

Roger: I care about privacy for the same reason I’ve spent my entire adult life promoting voluntary peaceful exchange: without it, economic freedom doesn’t exist. If every bank account, phone call, or web search can be subpoenaed or surveilled on a whim, then the politicians and bureaucrats—not you—decide what you can buy, whom you can help, or where you can travel. 

You don’t publish your ATM balance on a billboard; likewise, you shouldn’t be forced to reveal every satoshi you spend. Privacy is simply the practical expression of the non‑aggression principle: it lets peaceful people interact without having a gun pointed at their heads or a dossier built behind their backs. 

That’s exactly why I helped to create vp.net. Traditional VPNs ask you to trust a marketing slogan. VP.net locks identity‑to‑traffic mapping inside Intel SGX secure enclaves so even the server admin, or even a court order, can’t correlate “user X” with “website Y.” It’s cryptographically verifiable privacy, and it means your freedom isn’t dependent on the goodwill of some company in an offshore jurisdiction. 

By separating who you are from what you do online, we give every individual the practical power to say “no” to surveillance and “yes” to voluntary cooperation. That is the cornerstone of a world where innovation, charity, and free trade thrive because they’re chosen, not coerced.

2. Operating out of the United States, which is a part of 5 Eyes, 9 Eyes, and 14 Eyes alliances, is controversial for a VPN, given FISA, gag orders, and secret subpoenas. How does SGX practically shield your infrastructure from these legal pressures, and can VP.NET cryptographically prove that it isn't leaking metadata under government coercion?

We were very well aware of the different legal jurisdictions and how they affect the ability to effectively operate a VPN service. It is a serious problem that VPN providers are operating from some of the most obscure countries, wherein it becomes increasingly difficult to hold them accountable.

The US has some of the strongest accountability laws in the world, in addition to the strongest consumer protections. Additionally, and fortunately for us, it is impossible to do anything in secret without our entire user base being made aware, thanks to our SGX infrastructure with its attestation capabilities.

As a result, with the removal of this risk, the US becomes a better jurisdiction than any other.

3. How exactly does VP.NET's SGX-based architecture differ from traditional VPNs? Most VPNs use standard encryption, promise no logs, and run on commodity servers. Why should someone believe VP.NET offers something materially better, not just philosophically different?

Traditional VPNs are able to link traffic sources to their destinations because source traffic is decrypted by the VPN provider, in the clear and open, as it is subsequently routed thereafter.

When you mentioned that VPNs “promise no logs,” that to anyone serious about privacy and security would have made that a non-starter. Promises have often proven unreliable, especially from strangers who lack repercussions from said falsehoods.

With VP.NET, promises are not part of the security and privacy architecture. Instead, traffic is decrypted inside the SGX enclave, which is inaccessible, even if you have server-root access (master access). In addition, as we had packet batching, obfuscation, padding, mixing, and dummy traffic, therewith in said enclave, the destination traffic is unable to be linked even through timing.

As a result, VP.NET is the first and only VPN that is physically unable to spy on its users, even if it wanted to. This positions VP.NET as a categorically different, next-generation VPN service.

It’s really inconceivable to use any other VPN once you know VP.NET exists.

4. What’s the current global server footprint (number of servers, locations, SGX clusters), and how do you load-balance user traffic while preserving anonymity at scale? Additionally, do you have virtual servers? What are your plans regarding operating in a region where VPN is blocked?

We currently operate a world-class private network of 377 bare metal, SGX-enhanced servers across the world. Load balancing is handled automatically based on server load measurements, with lower load servers gaining priority over their busier counterparts.

We do not have any virtual servers. We do not plan to deploy servers in regions where VPN services are blocked or are required to log.

5. Can you explain your triple-layered identity mapping system in full? What happens from the moment a user logs in to the moment traffic exits the VPN? What logs exist, even temporarily, in the enclave?

This is a great question.  Let’s follow the line from Client, through VP.NET, to the Website Destination.

• The user chooses a VPN endpoint (or automatically chooses the least latent, closest endpoint thereto).
• User connects:
  1. The client gets a token when the user is identified.
  2. Client connects to the enclave and verifies its authenticity thanks to the enclave attestation
  3. Client uses a token to enable a one-time use public key on the Verified Privacy™ Enclave Server they wish to connect to.
  4. Standard connection happens via WireGuard® protocol.
• The user sends packets through the Enclave Server.
• Enclave server batches, pads, obfuscates, and creates dummy traffic to undermine timing analysis.
• The enclave server delivers packets to the internet destination.

6. What specific privacy and security features are built into VP.NET, both in terms of architecture and real-world protection?

VP.NET includes all of the typical privacy offerings the world has come to expect with VPN services. Additionally, with our inclusion of Verified Privacy™ enclaves using SGX, we provide the only VPN service that can guarantee privacy.

In terms of real-world protection, our team consists of veterans we’ve worked with in the security and privacy space in the past, and additionally, all of our internal policies strongly prevent any social engineering through a defense-in-depth organizational architecture.

7. SGX is central to your security model, but what if its integrity were compromised, either through an exploit or a covert vulnerability? Could a malicious enclave update silently leak user data? And what safeguards does VP.NET have in place to respond if trust in SGX were ever meaningfully questioned?

SGX is a well-established technology with a wide variety of security researchers both monitoring and attempting to break it every day.

Intel has processes in place for the not so frequent instances where SGX broke for a specific CPU architecture or microcode version that will cause certificates to be revoked, and we are also subscribed to Intel’s vendor mailing lists and closely monitoring SGX security so we can pull any vulnerable server out of our pools or apply security updates as made available.

We also apply all of the expected security processes typically applied in infrastructure deployments of this nature, so SGX being compromised in itself would not be enough to allow user traffic to be leaked.

As we grow, we are planning to support other trusted computing vendors such as AMD with their SEV technology, which would allow us to quickly pull all use of a specific vendor should the need arise. In addition, we may also offer a layered service with multiple technologies (similar to how Tor works, but with trusted computing vendors).

8. VP.NET’s pricing appears higher than many leading VPN services, especially considering the standard features offered, such as unlimited bandwidth, 5 simultaneous connections, and 24/7 support. Could you explain the rationale behind this pricing model and what value or innovation justifies the premium?

VP.NET tries to be in line with most VPN providers and their offerings. Due to our previous experiences in running VPN services, we learned that 5 is closer to the ceiling of numbers of devices that users use with a VPN account.

That being said, the servers we use, which include SGX, are considerably more expensive than the typical bargain-basement E3-level machines most providers use.

9. What payment methods do you support, and how are those payments de-identified or abstracted from user identity? For example, if someone pays via Stripe or PayPal, how do you ensure no residual link to the activity?

We support payments by card (including Apple Pay, Google Pay, Amazon Pay, etc), cryptocurrency, and some local payment methods as available through our payment providers. Payments are linked to the user’s own account in order to allow management of the subscription, renewals, etc. However, when a user connects to the VPN, the VPN server has no information other than the subscription end time.

The SGX enclave, when it receives a connection request from a user (using the user’s authentication token), will verify the validity of the token and add the user’s public key to its allowed list when valid.

No connection between the user’s activity, payment method, or identity exists.

10. For non-technical users: how would you explain the benefit of Intel SGX enclaves in plain terms, and why is that a game-changer for privacy?

Imagine you wish to send a physical mail parcel to a destination in the world. If you use a mail service, while you sealed your envelope, they could easily open it, read it, and re-seal it without anybody knowing. This is similar to the state of the VPN industry today.

We changed things. Now, if you wish to send a mail parcel, you would include a locked box with a key that only the receiver has. Even if the mail deliverer tries to open and read, they simply can’t.

True privacy for everyone is here.

11. What steps has VP.NET taken to audit or open-source parts of its software stack, especially around the SGX implementations? Are you planning third-party audits?

At VP.NET, we’ve been discussing with a number of well-known security researchers in terms of conducting an audit on our implementation and the scope thereof.

We hope to have completed and published these findings and any changes (if necessary) as soon as possible.

12. Has VP.NET ever been penetration-tested by a third-party red team, especially your enclave interaction model and kill switch mechanisms? Can you share the redacted findings?

We’ve not yet conducted penetration testing with a third-party red team. That said, we’re also planning this accordingly.

With that said, the majority of red team exploits involve social engineering, which most VPNs are susceptible to, except for us.

Even in the event that a staff member, including our founding executive team, is compromised, it is impossible to secretly include logging or a backdoor.

13. Your claim is "we can't log, even if we want to." What if Intel or a government agency introduces a backdoor into SGX microcode? How do you mitigate hardware trust collapse?

There is a large community of security researchers that continually monitor and reverse engineer Intel microcode updates for this very reason. As a result, it would be very difficult for an update like this to go unnoticed, and furthermore, the repercussions from said actions would be devastating to both Intel and, frankly, the US markets broadly.

Furthermore, even a targeted microcode update attack with several participants would be further difficult, as we rely on updates distributed by widely used Linux vendors that come with the vendor’s signature and verified package hashes.

In short, this attack would be far too expensive for Intel and the US to execute. At VP.NET, we’re constantly monitoring all vulnerability lists, forums, and general communities, as well as Intel microcode communities, and are very actively ensuring the security of our systems.

In the future, this will become even more difficult as we tune our architecture to support AMD SEV as well as other trusted environments.

14. Traditional VPNs can obfuscate traffic, bypass firewalls, and help users in authoritarian regions regain access to censored content. Can VP.NET reliably handle advanced deep packet inspection (DPI) and censorship circumvention? Or does the SGX model limit your flexibility in those edge cases?

VP.NET relies on the same encryption protocol used by WireGuard® to encrypt traffic. WireGuard® is a proven protocol and known to be resistant to a number of attacks, including deep packet inspection.

SGX does have some limitations, especially in terms of available memory, but unlike most VPN providers who utilize budget E3-class machines, we’ve built both a highly efficient infrastructure and spent considerable funds to deploy a best-in-class VPN that provides both high speeds and actual privacy.

15. Have you actively tested VP.NET against nation-state firewalls like China’s GFW or Iran’s DPI? If not, is there a roadmap to address this?

As of now, we have not yet tested within these regions. As things are early, we’ve had feedback signaling things work.  However, in the event an active approach is taken by these firewalls, we will look into providing pinholes for said firewalls. Additionally, this is also already planned by year-end, regardless.

16. You rely on Intel's attestation infrastructure. If that gets revoked, censored, or surveilled, does VP.NET still work? Is this a single point of failure in your trust model?

We started with Intel, which is the world’s leading vendor in trusted computing, but we will support more architectures, including AMD SEV, in the future.

17. What's your plan for onboarding the next million users? Do you see VP.NET as a mass-market product, or will it remain niche, focused on journalists, activists, and privacy maximalists?

We strongly believe everyone deserves privacy. We’re working on building VP.NET as both a mass market consumer service, but additionally, we hope to work with various infrastructure providers to include the technology directly therein.

Privacy must be the default.

18. Has VP.NET secured patents for all of its core technologies, or are there still pending intellectual property rights or patent applications awaiting approval? How do you plan to protect your innovations from replication before those are finalized?

We have patents pending across various aspects of our verifiable and guaranteed privacy solution.  Further, we’re actively securing the same protections in other markets as we speak. We are looking into developing a source-available license allowing netizens and companies alike to build and utilize our technology with limitations that would trigger the need for a Commercial Use License.

19. What’s on the roadmap for the next 12–18 months? Are there plans for browser extensions, decentralized infrastructure, anonymous payments, or integration with crypto wallets?

Our next 12-18 months look really exciting. We’re not in the market for creating a browser extension because browser extensions, as privacy, are a fallacy. 99.99999% of websites use TLS 1.2 and below, wherein the HELLO packet serves the server-name (destination) in plaintext.

This means that it is impossible for these connections to be private. You can decide what that means about each VPN company that has been doing this until now.

As for us, we’re privacy maximalists and will be taking a different approach. Instead, we intend to provide our own browser, which will resolve this issue. Additionally, we have anonymous payments coming with the Freedom Dollar, among others, and quite a few other exciting features we will announce as they mature.