GIP-122: Should GnosisDAO support the continued development of Gnosis VPN to bring it to market?

SCBuergel · February 13, 2025, 8:22pm

GIP-122: Should GnosisDAO support the continued development of Gnosis VPN to bring it to market?

In Favour
Against

0 voters

GIP: 122
title: Should GnosisDAO support the continued development of Gnosis VPN to bring it to market?
author: Sebastian Bürgel on behalf of HOPR Association
status: Draft
type: Funding
created: 2025-02-13
duration: 24 months
funding: $4.8m + 500 GNO

Abstract

HOPR has completed the first proof-of-concept version of Gnosis VPN, a trustless, decentralized, uncensorable VPN service running on top of the HOPR network. The results were far in excess of expectations, demonstrating the viability of Gnosis VPN. More details can be found in our closing report for proposal 1.

However, it is still only a proof of concept. To continue development, the next stage would be to turn Gnosis VPN into a truly web3-native product with decentralized tech and incentive structures, ready to take to market and aligned with the goals of the Gnosis ecosystem. The HOPR team has scoped out the necessary work and assessed that it will take 24 months, with the first MVP version available within the first year of work.

The two-year research and development roadmap would focus broadly on four areas:

Turning the proof of concept into a minimum viable product which does not require users to run their own HOPR node
Taking that minimum viable product and turning it into a market-ready product for minimally crypto-savvy users
Optimizing the HOPR protocol to support the increased demands of a VPN service
Hardening the privacy of every component of Gnosis VPN to ensure that the service is uncensorable.

In parallel, it will be necessary to scale and further decentralize the HOPR network and set of Gnosis VPN exit node runners, as well as providing mechanisms for properly incentivizing exit node runners while ensuring users can trust them. We are confident that Circles v2 is the ideal vehicle for these mechanisms, but further research and implementation is needed.

Each improved iteration of Gnosis VPN is targeted at a different user persona, broadly representing an order of magnitude increase in the user base. Over the course of this project, and in keeping with the Gnosis 3.0 vision we would take Gnosis VPN from a proof of concept able to support under 100 users, to a service ready to support many globally distributed users on a host of different devices.

To achieve this roadmap, GnosisDAO would invest $4.8m into HOPR over two years, in exchange for HOPR tokens at a 90d TWAP ending on the day of each installment.

In addition, similar to GIP-98, 500 GNO would be provided to incentivize the onboarding of new node runners to bootstrap the service.

The Ideal Gnosis VPN

Gnosis VPN is conceived as a trustless, decentralized VPN built on top of the HOPR network, Gnosis Chain and Circles v2. Gnosis VPN usage is anonymous and uncensorable. The HOPR network is leveraged to provide enhanced anonymity guarantees, hiding IP-level metadata of all data going through the VPN. This provides far superior trust assumptions for users than regular VPNs or alternative anonymous communication networks such as Tor. Circles v2 will be used to handle user authentication and user-server trust relationships. This will allow for a frictionless end-user experience and requires fewer trust assumptions between users and third-party services.

Gnosis VPN is a web3-native product with minimal trust assumptions and no reliance on RPC providers or traditional bootstrap nodes. The technical roadmap to get there is outlined in more detail below.

In addition, the commercial alignment of Gnosis VPN and Gnosis DAO is strengthened by the total absence of a traditional "business model”. Gnosis VPN and HOPR are developed as Free and Open Source technology, and all value from the Gnosis VPN service will accrue to node runners, either Gnosis Chain validators (via gas fees), HOPR mixnet relay node runners, or Gnosis VPN exit node operators. No IP will remain with HOPR Association and team and no fees or other revenue from Gnosis VPN would be extracted by them.

The Current State of Gnosis VPN

Over the past 9 months, HOPR has built a proof-of-concept (PoC) version of Gnosis VPN, as specified in GIP-98. The focus was on demonstrating that anonymous data transport is possible at acceptable speeds for modern internet users. The original proposal did not foresee the creation of full-fledged end-to-end VPN capabilities during that period; however, we managed to build a PoC which provides a secure Wireguard VPN connection running over the HOPR network. The PoC is developer-oriented still, requiring some technical knowledge and effort to set up, but does in the end provide a secure, anonymous and working VPN connection.

If you already have or are willing to run a HOPR node, you can test the PoC version for yourself here. However, since this is a technical showcase, the setup is still moderately complex. Future versions will bring greatly improved usability, with an “unrestricted” version of the PoC planned within 6 months which can support all HOPR relay node runners and has greatly streamlined onboarding

The PoC successfully uses the HOPR Session protocol (a protocol designed by the HOPR team as part of GIP-98 which allows raw TCP and UDP traffic to be sent directly over HOPR) to channel requests to exit node runners across the HOPR mixnet. Relaying nodes are successfully paid in HOPR tokens for this service, as can be confirmed via on-chain ticket redemption transactions. The exit node processes the request and serves the result to the user by transmitting it back across the HOPR mixnet. Latency and throughput fall well within usable thresholds (and are actually much better than predicted).

Crucially, the PoC successfully obscures the user’s IP metadata thanks to the HOPR mixnet. Further work is needed on the VPN client to make the service truly uncensorable. This will form a major research component of this proposal.

As stipulated in GIP-98, the PoC version has a limited allow-list of sites to visit, chosen from the Gnosis ecosystem. All exit nodes are controlled by Gnosis. Users are required to control their own HOPR node to act as an entry node.

You can also view footage of Gnosis VPN in action without these restrictions here, including streaming YouTube at 720p. This footage was gathered under ideal test conditions (all Gnosis VPN exit nodes controlled by Gnosis, relay nodes controlled by individual node runners from the HOPR community, in diverse physical locations); users trying the PoC will likely experience somewhat lower performance, especially if many users are connected simultaneously.

More details can be found in our final quarterly report for GIP-98, or at https://gnosisvpn.com, but the key takeaways are:

HOPR Session protocol was successfully implemented to securely tunnel TCP and UDP traffic via the underlying HOPR network
Relaying throughput is reliably 1200 packets per second, 60x more than our GIP-98 target of increasing from two packets per second to 20.
Latency is not negligible, but falls well within usable thresholds
In ideal conditions, speeds of up to 1.8Mbps are reached between sender and receiver, 100x the target set in GIP-98
All traffic is successfully routed via the HOPR mixnet, and all relay nodes are paid correctly

Despite these successes, there are still limitations. The technical requirements and restrictive allowlisting of sites limits the user base. Exit nodes are still controlled by a single entity. Establishing an initial connection once the initial setup has been completed can take some minutes. While the current network can support the PoC, it is unlikely that it could sustain hundreds of users while maintaining tolerable latency and throughput. Although the HOPR mixnet provides a high level of privacy to users, the PoC could still theoretically be identified and blocked on the server side under the current setup.

Fixing these limitations will be the focus of this second phase of development.

Second Phase

This GIP covers the continued development of Gnosis VPN to bring it to market, directly continuing the work done in the first phase (covered by GIP-98).

The next iteration of Gnosis VPN moving from PoC through MVP (end of 2025) to version 1 (end of 2026) will require significant architecture updates to HOPRd and the Gnosis VPN product components to deliver unique features.

This phase focuses on four upgrades to Gnosis VPN, each of which has its own deliverables:

A) Turn the developer-oriented PoC into an MVP usable by end users.
B) Turn the MVP into a market-ready product (version 1).
C) Scale the underlying HOPR network to ensure scalability of the Gnosis VPN product.
D) Hardening the privacy of all Gnosis VPN product components to build a maximally uncensorable service.

Although these are presented broadly in development order, this is a complex project with many interdependencies and parallel workstreams, and a lot of separate and ongoing research.

We will also spend some time over the next six months improving the usability of the PoC and reducing its restrictions, with the goal of being able to support all HOPR relay node runners with good performance.

A lot of the development work is highly technical, including advanced bespoke cryptography. In order to easily understand each iteration of Gnosis VPN, it may be more intuitive to think in terms of the target user base. Each iteration is targeted towards an expanded set of users, with changing requirements as a result. The different user personas for each version are defined as follows:

The current PoC targets technically capable users who are willing to spend time to set up their own HOPR node and use the Gnosis VPN CLI tool in a shell to configure and start the Gnosis VPN connection. Moreover, these users are willing to stake funds, specifically wxHOPR tokens, on their HOPR node to enter the HOPR network and pay for outgoing VPN traffic. An unrestricted version of the PoC, available within six months, will reduce onboarding time significantly but still be targeted at HOPR node runners.
The MVP (9 months) will lower the technical barrier of entry by integrating the HOPR node into the Gnosis VPN software itself. VPN connections can be started through UI applications. Thus, users are no longer required to enter a shell or set up server-side software. However, users must still stake wxHOPR tokens and need to understand how to acquire those.
The first “stable” release of Gnosis VPN (18 months) will further reduce requirements by eliminating the need to stake wxHOPR thanks to streamlined edge nodes (see deliverable A1i for a definition). Integration with Pay, Metri and Circles v2 will let users easily acquire the small amount of tokens needed to use Gnosis VPN through the app itself. Users are still expected to have some knowledge of the crypto ecosystem.

Towards Uncensorability

Providing an anonymous VPN and an uncensorable VPN are related but distinct challenges. Anonymous means that, as far as possible, no-one should know you are using Gnosis VPN or what you are using it for without you choosing to disclose those facts. Being uncensorable means that no-one should be able to stop you from using the service. Gnosis VPN should be both anonymous and uncensorable.

Anonymity is a difficult problem, but HOPR’s technology is well-equipped to solve it: the HOPR mixnet obscures all user data and metadata, even from participants within the mixnet. There are other places (e.g., onboarding, payments, discoverability of exit nodes) where it is important that mechanism design does not leak metadata of network participants, but care will be taken at every stage to minimise trust assumptions and maintain similar levels of anonymity as provided by the mixnet.

Strong anonymity helps towards censorship resistance (it’s hard to stop things if you can’t see who is doing them), but it is not quite sufficient. There are three places where censorship might occur: between the user and the entry node, within the mixnet, and between the exit node and the requested site / service.

Within the multi-hop HOPR mixnet, this problem is solved: individual relayers cannot see what they are relaying or to and from where data is being sent. Malicious third parties running nodes gain no access to identifying information. The only way to censor an individual transmission is to take down the entire network, which should prove technologically and economically unfeasible once the network achieves sufficient scale.

On the entry side, the problem is solved by the user being in full control of their entry node. For the PoC version this currently creates an unreasonable technical burden for a global VPN service (both in terms of knowledge and system requirements), but the development of HOPR edge node capabilities as part of the MVP will allow for more lightweight nodes which can run easily on a wide range of devices.

The complexity lies in the exit nodes, and should be approached from multiple angles. On the exit node side, Gnosis VPN is theoretically censorable in various ways: the entity providing the site or service could identify a request as coming from a Gnosis VPN exit node and refuse to serve it; some external actor, likely a state or ISP provider, could identify a Gnosis VPN exit node operator and block their internet service; finally, exit node runners themselves may choose to refuse a user’s request.

Some components of a solution are already in place: because Gnosis VPN exit node operators will consist of a large number of globally distributed users, it will be technologically and economically unfeasible to block them all. They will also likely be using IP addresses which fall outside the standard ranges used for VPN blocking. If individual nodes are identified and blocked, they can be replaced (but this should be mitigated to ensure incentives are correct for being an exit node operator).

Since exit node operators expose their true IPs, it is reasonable that individual node operators should be able to refuse to serve particular requests (e.g., because of the jurisdiction where they are based). But this becomes a broadcast and discoverability problem: exit node runners should be able to broadcast what they will and won’t do, and users should be able to easily find and switch between exit nodes which meet their needs. A naive version of this functionality is seen in the PoC’s allowlist settings for exit nodes.

Additionally, Gnosis VPN exit node operators should be able to not publicly announce their service but only make it known to a trusted circle of users who can utilize their VPN exit capabilities. Thus, Gnosis VPN effectively provides a framework for customizable VPN service and user groups that are not publicly known and thus not censorable by anyone outside the circle of trusted users.

The trust graphs and group functionality within Circles v2 seem an ideal base for building these mechanisms. We have several ideas for mechanisms here which we intend to test throughout the development period.

This is a complex, research-heavy set of design problems, but one which will be tackled in parallel with building a globally scalable version of Gnosis VPN which, even without these improvements, would still be more anonymous, decentralized and have better trust assumptions than any other VPN currently on the market.

Project Deliverables

A) Turn the developer-oriented PoC into an MVP usable by end users.

The current PoC requires users to install, set up and maintain their own HOPR node. They must also configure Wireguard manually as well as use a command-line interface to start a Gnosis VPN connection. Although this is well-documented and tested, this is still a high barrier to entry and requires time, knowledge and a willingness to commit significant capital in the form of staked wxHOPR.

The Gnosis VPN MVP will be usable by end users without that strong technical knowledge. To achieve this, we have outlined the following deliverables:

Remove dedicated HOPR node requirement

HOPR edge node support: Running a HOPR node on end-user devices (e.g., laptops) is hard because these provide limited uptime, resources and connectivity compared to servers in datacenters or dappnodes at home. However, supporting that deployment scenario is critical to making applications like Gnosis VPN viable and scale to large amounts of users.
Automated on-boarding: The current multi-step process to set up the node and configure it correctly will be shortened and require as little user input as possible. While this automation will be complex, it will reduce the points where users could fail in their journey.

Provide VPN app which handles all configuration and logic

Support macOS and Linux (selected distributions): These platforms have been chosen to support a large potential end-user group while keeping desktop application development in a manageable scope since each platform adds complexity. More platforms will be added in follow-up work.
“Single-click” installation: A smooth and fast installation process must be supported for all supported platforms. This will be a big improvement over the PoC which requires downloading pre-built binaries manually and setting them up locally using a shell. However, this work comes with lots of platform-specific requirements and testing effort.

B) Turn the MVP into a market-ready product (version 1.0).

Removing the need for a dedicated full HOPR node is a major milestone in building a viable Gnosis VPN. However, in keeping with the Gnosis 3.0 vision, it will be necessary to move beyond highly embedded crypto users and attract a broader range of user types. Looking at standard VPN usage behaviours, it’s clear that we will need to support a wide variety of devices and operating systems, particularly mobile, bringing a native web3 product to mobile platforms.

The MVP UX will be optimized to enable end users to get their VPN up and running as quickly as possible. Global content restrictions, which were mainly in place due to bandwidth requirements will be lifted.

We envision the following deliverables:

Mobile platform support

iOS / iPadOS: Only selected versions, likely the most recent major version, will be supported. More versions will be added in follow-up work. The VPN should integrate as a VPN service in the OS VPN subsystem. This requires extensive work on new test and release automation as is usual for mobile applications.
Android: Only selected versions and devices, likely the most recent major version, will be supported. More versions and devices will be added in follow-up work. This requires extensive work on new test and release automation as is usual for mobile applications.

Support desktop platforms

macOS: Better integration as a network VPN service and support for older OS releases. Ideally the app should be published through the App Store; however, that is dependent on approval by Apple.
Linux: More supported distributions and package managers.

Short time-to-first-use

Under 2min to set up and open a VPN connection: Even privacy-valuing users are unwilling to wait long periods simply because a product is decentralized. Hitting this target depends on the HOPR edge node support and being able to connect to the HOPR network and use it within a very short time.

Integrated onboarding and discovery via Circles v2

Use Circles v2 as the identification method: This and the following items will begin with research into their feasibility, but we believe Circles v2 is the best way to streamline onboarding, discovery, and UX within the Gnosis ecosystem without creating additional tokens.
Integrate with existing Circles v2 ecosystem
Reduce UX friction by not requiring additional registration

C) Scale the underlying HOPR network to ensure scalability of the Gnosis VPN product.

Gnosis VPN works by channeling requests to dedicated exit nodes over the HOPR mixnet, via up to three HOPR relay nodes. However, this naturally means that as user numbers grow, the number of relay and exit nodes must scale to support this. As the network grows, discoverability and pathfinding become more crucial.

Work will be done to optimize the HOPR protocol to ensure a feasible ratio between users and node runners, but ultimately for a decentralized network a higher ratio here is a feature, not a bug. Growing and supporting a network of potentially tens of thousands of nodes will require significant work and optimization.

We envision the following deliverables here. These are intentionally broad because the nature of this work is to experiment, test, and improve, and problems cannot easily be predicted in advance. However, the HOPR team has met with excellent success at meeting its scaling goals thus far.

HOPR network supports thousands of mix nodes: The current size of the network is around 500 nodes. Most p2p sub-systems and protocols have to be improved to reliably scale beyond 1000 nodes and support 1000s of users. Having more mix nodes is a prerequisite for higher global bandwidth support.
HOPR network provides enough bandwidth to handle Gnosis VPN requirements: The performance of individual mix nodes must be optimized to handle traffic more efficiently without sacrificing privacy guarantees. Moreover, network topology and pathfinding must be improved to provide sustained bandwidth for individual edge nodes.
Grow the number of HOPR node runners and Gnosis VPN exit node runners to support the MVP: From version 1.0, the economics of Gnosis VPN should be such that sufficient revenue exists to support the necessary node runners. However, until that time, it will be necessary to incentivize users to join to ensure we have a network of sufficient size to support the user base and test improvements on the road to version 1. The proposal requests an additional 500 GNO to use as incentives for these initiatives.

D) Harden the privacy and censorship-resistance of all Gnosis VPN product components.

A common shortcoming with VPNs is that their entire IP ranges are deny-listed by internet services or internet access providers, rendering the VPNs useless to their users. Gnosis VPN is well-placed to mitigate this thanks to its decentralized network which leverages the internet access of all network participants, whose IPs are likely to fall in the residential range, which is harder to block.

However, ensuring that Gnosis VPN becomes uncensorable at scale will require significant research and development specifically in the second half of the proposal. This work is split into four main contributions:

Local VPN entry: Each user will have their own access into the VPN platform through a user-owned HOPR node. In the PoC this is a full HOPR node, while the final product relies on the HOPR edge node functionality (as described in A.1.i). Either way, access to the VPN does not rely on third-party systems and is therefore fully decentralized.
Decentralized VPN exit: Gnosis VPN uses many different servers run by different network participants. This ensures that even if individual entities are shut-down, the Gnosis VPN product as whole will continue to function. While the PoC will work mainly through servers which are run by Gnosis itself, further decentralization will be achieved in the MVP and final product.
Permissionless server registry and discovery: Server operators must be able to show their availability to users. Therefore, they must be able to register themselves in a service registry and users must be able to discover available servers. We plan to leverage Circles v2 in order to create decentralized trust groups which enables small and tiny Gnosis VPN server operators to exist in a permissionless manner.
Protection against abuse: Gnosis VPN server operators must be able to discover and prevent abuse of the service they provide. The definition of abuse must be configurable, with specific settings decided by each exit node operator. Operators must be able to deny service to users if abuse is detected, and must be able to reflect that in the trust graph using Circles v2. For the service to be usable, operators’ abuse configurations must be easily discoverable by users, allowing them to understand the capabilities provided by a given server and to choose their exit server accordingly.

As with anything involving complex network topologies, these last two deliverables will potentially prove to be challenging problems. The final goal is an uncensorable version of Gnosis VPN which gives any users striving for maximum anonymity the ability to create their own closed group within the wider VPN service, accessible only to those they trust. This is very different from standard P2P and DHT-based approaches to discovery and broadcast. While we believe Circles v2 will help unlock these challenges, we still expect these parts of the project to be very research heavy with long timelines.

Rationale

The need for this follow-up proposal was already outlined in GIP-98. However, almost a year later it is worth revisiting and sanity checking this.

The need for a decentralized, trustless, uncensorable VPN service is stronger than ever. Digital privacy has never been more under threat, and access to web services is increasingly gated by those services, ISPs and states.

The PoC delivered through GIP-98 shows that an anonymous, unblockable VPN is feasible. In addition, the challenges to provide high performance, while real, are less pronounced than we feared. PoC performance in ideal conditions was 100x higher than predicted.

A VPN service is also a natural fit for the Gnosis 3.0 vision of onboarding more users to the Gnosis ecosystem. The value of the global VPN market is estimated at over $70b annually in 2024, growing to half a trillion dollars by 2034. The pandemic and rise in remote working has triggered a boom in the already fast-growing industry, with VPN usage estimated to have jumped by over 10% in the US in the past year.

Although Gnosis VPN will be a Gnosis product, the HOPR team is best placed to continue development through this second stage. We have the expertise and momentum from working on Phase 1, and Phase 2 includes challenging architecture, cryptography, research, and mechanism design problems which no other team is better equipped to tackle successfully.

The HOPR team is small, focused, and consistently produces results. GIP-98 was completed on time and within budget. We hit all our reporting and milestone deadlines, and the results exceeded the stipulated deliverables by orders of magnitude. We have already successfully worked with the Gnosis team to establish the Gnosis-hosted infrastructure for the PoC and are well-placed to continue working with Gnosis on the much broader range of challenges presented by Phase 2, which include business development and legal considerations.

Project Timeline, Milestones and KPIs

The proposed start of this project is from the moment the proposal is voted upon and executed. The project will run for 24 months. Development will be fully Free and Open Source, and progress reports will be provided to GnosisDAO on a quarterly basis, as we did for GIP-98.

Reporting and Updates

In addition to providing quarterly reports, we plan to publish three major product updates over the course of this project:

MVP (Month 9) – Focusing on aspect A
Version 1 (Month 18) – Focusing on aspects B and C
Version 2 (Month 24) – Focusing on aspect D

Although each update focuses on particular aspects of the deliverables outlined above, the interconnected nature of the development and research means that each update will include full and partial deliverables from across the whole project scope. The diagram below shows the full list of deliverables associated with each update.

In addition, by month 6 the current PoC will be updated to an unrestricted version, with a significantly streamlined onboarding process.

Minor product updates might be published within each of these timeframes in varying frequencies depending on the amount of bug-fixes and new features.

KPIs

To ensure the project is on track, six-monthly user KPIs will be used to assess progress. By month 6, the unrestricted version of the PoC will be able to support all HOPR node runners as users.

From month 12, monthly active users will be defined based on Wireguard server registrations and activity contributing to HOPR protocol revenue.

Month	Version	User KPI
6	Unrestricted PoC	Support for all HOPR node runners
12	MVP	100 MAU
18	Version 1	150 MAU
24	Version 2	500 MAU

Timeline

The table below collates the timelines for this project, along with the various versions, deliverables and KPIs

Month	Version Update	Full Deliverables	Partial Deliverables	KPI
6	PoC (unrestricted)			Usable by all HOPR node runners
9	MVP	A1,A2,D1	B1,B2,B3,C1,D2
12				100 MAU
18	Version 1	B2,B3,B4,C1,D2	B1,C2,D3,D4	150 MAU
24	Version 2	B1,D2,D3,D4		500 MAU

About HOPR

HOPR is a Swiss-based project building privacy infrastructure for web3. The HOPR network is a mixnet which uses proof-of-relay to incentivize relay nodes using the HOPR token.

HOPR has been active since 2020 and launched its HOPR token in February 2021. HOPR’s mixnet is fully functional, and currently has over 300 active relaying nodes. Of these, fewer than 10% are run by the HOPR team.

HOPR has a longstanding relationship with Gnosis. The HOPR network is incentivized using the HOPR token on Gnosis Chain. HOPR’s staking and node management tools are built on top of Safe. In 2022, HOPR conducted research in collaboration with Gnosis to highlight potential privacy issues related to validator sniping on Gnosis Beacon Chain.

Since 2024, HOPR has been working on Gnosis VPN, the first fully decentralized, trustless, uncensorable VPN network.

Funding and Team

HOPR is requesting $4.8m to fund this proposal, paid in four equal installments of $1.2m. The first will be paid when the proposal passes, with subsequent installments paid every six months, contingent on hitting the user milestones outlined above. In exchange, GnosisDAO will receive HOPR tokens at a 90-day TWAP ending on the day of each installment.

In addition, similar to GIP-98, 500 GNO would be provided to incentivize the onboarding of new node runners to bootstrap the service.

HOPR has a streamlined, purely tech-focused team consisting of 9 full time engineers who work exclusively on HOPR. As part of this proposal, we would employ a 10th engineer to focus full-time on testing and QA and later on an 11th engineer to strengthen our R&D team.

All team members and their work can be found in the respective repositories of the following GitHub organization: HOPR · GitHub