GIP-98: Should GnosisDAO invest in HOPR to kickstart development of GnosisVPN?

Governance GIPs
26

I wanted to also take the opportunity to highlight the decentralized nature of the HOPR network which shows another angle of alignment between HORP and Gnosis and which is a value proposition of onboarding HOPR node runners as Gnosis validators. We created this Dune Dashboard that highlights that there’s only 2 HOPR Safes with more than 10 connected HOPR nodes and only 10 run more than 1 HOPR node.

I think that is a significant difference from many other projects in the ecosystem in that HOPR nodes are operated by individuals and not professional node operating corporations. Many of HOPR nodes are running on DappNodes out of their operators’ homes, thanks to our partnership with and custom branded HOPR DappNode devices.

2 Likes
27

Thank you for your responses. I must express, however, my remaining scepticism.
Upon reviewing the codebase, the associated costs seem unjustifiable. Though I prefer to remain unnamed, I can evaluate this matter accurately.

I propose the following adjustments:

  1. The total cost should be reduced to $500,000
  2. Implement a milestone-based funding model, wherein funds are disbursed upon achieving specified benchmarks

Nevertheless, I anticipate that these suggestions may be overlooked, as this has been my experience with DAOs in the past, sadly.

1 Like
28

Thanks for looking at our code - that’s what FOSS is about and I’d appreciate specific feedback. It would help me to respond to you if you made your criticism explicit. Are you saying “your code looks so poor that it’s not even worth the $1.5m of this first proposal” or “you basically did 90% of the work that’s needed for this first milestone of Gnosis VPN and only have like 3 man months of work left and hence $1.5m is too much”?

As outlined in detail in the OP, I absolutely agree with your notion of milestone-based payouts and that’s exactly what we suggest here in this proposal.

2 Likes
29

From my analysis today, it appears that the majority of the tasks associated with GnosisVPN have been successfully completed, with only minor discrepancies remaining.

The remaining objectives include developing the front-end and enhancing the performance of HOPR, which I would argue the former is out of scope, but given Gnosis Ventures initiative, I find it acceptable.

I must apologize if my scrutiny seems excessive. However, I believe the funding requested exceeds the necessary amount. In line with the principles of DAOs and the ethos of cryptocurrency, we should adhere to the maxim: Don’t trust, verify.

Edit: Additionally, can you specify the milestones you are referring to? The proposal seems vague in that aspect. What is the value given to each deliverable? Or is the grant given up-front?

1 Like
30

From my analysis today, it appears that the majority of the tasks associated with GnosisVPN have been successfully completed, with only minor discrepancies remaining.

Thanks again for digging into the code and the proposal this deeply - that’s something I rarely see in DAOs but as you mention, that is extremely valuable to ensure funds are not misappropriated.

As you have mentioned in earlier comment, RPCh is already operational: GitHub - Rpc-h/RPCh: RPCh is the only private RPC provider. Uses HOPR under the hood.

Correct, but that has almost nothing to do with the proposed work here.

Deliverables 1.2 and 1.3 have been met (90% there), given that RPCh encompasses similar functionalities, albeit with different endpoints on the exit-nodes

Generally, the intent of this work is to not just provide short-term gains and PoC, but actually a sustainable product development plan which seeks to bring Gnosis VPN as a viable product to a significant market - in line with the Gnosis 3.0 setup. That is important to understand as, indeed, we could make a quick & dirty first version of pHTTP and Gnosis VPN that would never be rolled out in production. But the goal here is actual product development. RPCh has comparatively tiny payloads compared to what you would typically utilize within the use of a web browsing setup.

Thus, the assumption of deliverables 1.2 and 1.3 being 90% there is incorrect. The current version that is in the repo which you also refer to in your next point is utilizing a relatively simple specific purpose solution built for the Ethereum RPC standard only. For example, the setup cannot handle websockets, additional HTTP header fields or other HTTP verbs. That means the entire architecture of this extremely opinionated and non-optimized form of the protocol needs to be overhauled from the ground up. That is deliverable 1.1 which then gets implemented in deliverable 1.2.

As the entry/exit node behavior changes with these additional requirements, entry and exit nodes also need to be reimplemented. This also needs to be tested wrt performance as I expect some large payloads to not get delivered within a timeout window. Beyond per-resource performance assessments, we also need to consider network-wide load assessments to judge which websites and services are in scope of the allow-listed first version of Gnosis VPN which is in scope of this proposal for the first PoC.

The RPCh code has been relabelled to GitHub - hoprnet/pHTTP-lib: p(rivate)HTTP library, which seems to represent the CORE code in RPCh

To be precise we started extracting and generalizing the core of RPCh which should present the basis for the Gnosis VPN work into a separate library. RPCh will become a user of that library, therefore this isn’t a simple re-branding and presents only the first step before we start re-designing and re-writing this for the much larger capabilities of Gnosis VPN compared to the specific purpose use case of RPCh.

The remaining objectives include developing the front-end and enhancing the performance of HOPR, which I would argue the former is out of scope, but given Gnosis Ventures initiative, I find it acceptable.

I don’t understand why a front-end - without which the proof of concept is entirely unusable for normal users - would be considered out of scope. We normally focus on making tech as approachable for end-users as possible and Gnosis does too.

Edit: Additionally, can you specify the milestones you are referring to?

The deliverables 1.1 - 1.5 culminating with a release of a proof-of-concept version of Gnosis VPN is the first milestone. Further milestones would be subject to an additional Gnosis DAO proposal.

What is the value given to each deliverable? Or is the grant given up-front?

We would prefer upfront payment.

Finally it is important to point out that this proposal is not a grant. Gnosis DAO is not just sponsoring product development work but is receiving a significant value worth of HORP tokens on top of the product development work.

1 Like
31

As a noob, I would like to know what would be the implications of exit/entry nodes with people using the product with their already KYCed addresses on Gnosis Pay with this product?

I know the PoC is supposed to provide limited access to certain endpoints to help out with privacy. However, as all the people who have signed up for a Gnosis Card provided their KYC info to Fractal, and Gnosis Pay, and most probably Monavate also having access to this info as well, I am curious to get an insight on the implications of what a decentralized VPN network powered by HOPR node runners in terms of prejudicing the user’s privacy (especially if the node runner is using the same credentials/IP/or whatever you wish to call it is known by regulatory bodies or poor opsec by the node runner).

Would it pose a risk to the node runner as being KYCed, would it pose a risk to the user with a KYCed address, would it pose a risk to the entire network due to the failure of either?

EDIT: I do think we need a decentralized VPN solution and this is one of the proposals that got me excited on Gnosis 3.0/consumer product oriented roadmap!

6 Likes
32

That’s a very good - and non-noob - question! Let’s dissect it:

First of all, what are the implications for entry and exit nodes? Entry nodes see the end-to-end encrypted metadata of the traffic. So the entry node which is directly in contact with a user of course sees that user’s IP address and metadata such as the size of requests and reponses they send. The latter can be partially mitigated by sending data via multiple entry nodes. In fact, HOPR is designed to make the switching of routes very efficient, to provide decrease the necessary trust in individual entry nodes.

The exit node, on the other hand, has no way of knowing the user’s metadata, so specifically they don’t see the user’s IP address. But the exit node makes the actual requests and sends back the responses so that webserver sees the websites that are being accessed, but they don’t see from who, so the exit node does not see the IP address or other metadata and is specifically also not able to link individual requests to the same user.

Thus, if you are concerned about your KYC-ed identity being linked to your web-browsing activities, Gnosis VPN should be able to better protect you against de-anonymizing of your traffic than other means. The only exception is of course if the entire chain of nodes all collude (including entry and exit nodes and Gnosis Pay KYC providers) - but there’s really no system that could protect you against that.

I’m very happy to hear that Gnosis VPN makes you excited about the Gnosis 3.0 roadmap - we see the same!

3 Likes
33

This proposal is now live for voting on Snapshot.

4 Likes
34

Enthusiastically voted yes. Let’s do this!

3 Likes
35

@SCBuergel

I haven’t voted on this decision on snapshot yet, but I’d like to know: you say HOPR tokens at -30% discount.

But how many HOPR tokens are you going to sell to the Gnosis Dao at this rate? (Maybe it was mentioned but I must have missed it).

1 Like
36

Hi, happy to clarify the amounts mentioned in the OP. The amount of HOPR tokens sold to Gnosis DAO equals $1.5m / (HoprPrice90dTWAP * 0.7). For the TWAP we created this Dune dashboard. The TWAP will run until end of the Snapshot proposal and will change a little bit - but at current values that would be approximately
1.5m / 0.108 * 0.7 = 19.84m HOPR

2 Likes
37

Thank you very much for this more detailed information!

3 Likes
38

Thank you everyone for the fruitful discussion and for all voters - the proposal has now been voted upon with 99.94% in favor on Snapshot page.

The Dune dashboard for the 90d HOPR TWAP has been updated with the end time of the end of the voting period and the final price is $0.111753491. Thus Gnosis DAO will purchase

1'500'000 / (0.111753491 * 0.7) = 19'174'856 HOPR
4 Likes
39

Congratulations! I’m excited to see how this project progresses.

4 Likes
40

For the record, the OTC deal will be executed through the following DAO address: eth:0x849d52316331967b6ff1198e5e32a0eb168d039d

1 Like
41

Transaction was fully executed.
HOPR received in this tx.
USDC sent on this tx.

4 Likes
42

Intro

This report provides an overview of the work being done as part of the GIP-98 following its approval in 04/2024.

The HOPR team focused on four work streams which have mostly been carried out in parallel:

  • Finalization, release and support of HOPRd v2.1.x
  • Implementation of uHTTP (formerly pHTTP)
  • Design and development of VPN capabilities for HOPRd
  • Development of HOPRd v2.2.x

Finalization, release and support of HOPRd v2.1.x

The development of v2.1.x had been in full swing since October 2023. Its focus was the replacement of Node.JS as HOPRd’s runtime engine onto become a Rust-native application. This marked the last step of migrating HOPRd from being a Node.JS Typescript-based application to a Rust application. The main benefits coming out of this effort were improved performance, improved stability and better maintainability moving forward. For Gnosis VPN, the improved performance of v2.1.x would already be a welcome side-effect for a better user experience.

The release v2.1.0 changelog (Release HOPR - v2.1.0 · hoprnet/hoprnet · GitHub) includes all details. Notably, the resource consumption of HOPRd went down, making the operation of a HOPRd node more economically viable than before.

Further patch releases up to v2.1.3 most recently fixed minor bugs which HOPRd runners experienced.

With release v2.1.3 we achieved a massive increase in throughput per node. While a HOPRd v2.0.x node was able to handle 2 packets/sec a HOPRd v2.1.3 node can handle 200 packets/sec reliably, a 100x improvement. Below we depict an overview of Grafana charts of a 30min recording of sending messages at a rate of 200 packets per second from one node via a random selection of one out of five intermediate mix nodes back to the same sending node.

messages-rate
messages-rate935×494 46.3 KB

Figure 1: Rate of received messages, showing that HOPRd is able to reliably send 200 packets per second.

success-ratio
success-ratio934×497 63.9 KB

Figure 2: Success ratio, showing that over the entire 30min recording period the success ratio was over 99.7%, i.e., less than 1 in 300 packets was lost

message-latency-quantiles
message-latency-quantiles939×540 38.5 KB

Figure 3: Message latency quantiles showing that 50% of all packets were received in under 280ms, 90% of all packets were received in under 410ms and 95% of all packets were received in under 440ms.

These results surpassed our original throughput expectations for deliverable 1.5 by a factor of at least 10x.

Additional stress tests which focus on mixer throughput that are run on more powerful consumer laptops have already shown significantly higher throughput than the lab setup results shown above. These can be run by anyone who is interested by following these steps:

  1. Install Nix, the dependency management tool used in HOPRd’s toolchain: Download | Nix & NixOS
  2. Check out HOPRd branch tb/20240731-stress: GitHub - hoprnet/hoprnet at tb/20240731-stress
  3. Run the following command in the checked out sources:
nix develop .#smoke-tests -c make stress-test-local-swarm
  1. Wait, as this will take a while. The results will be shown at the end.

Implementation of uHTTP (formerly pHTTP)

Early on pHTTP was rebranded as u(nlinked)HTTP to signal the most important aspect of unlinking sender and receiver of HTTP requests, thereby protecting the sender’s IP metadata while using web services.

The uHTTP library was developed as FOSS and is available on Github.

To assist dissemination we developed a showcase dApp called MyTokenTracker which highlights the need for uHTTP and shows its effect. The code for MyTokenTracker is open-source as well.

The running dApp can be used at mytokentracker.xyz

We presented uHTTP, MyTokenTracker, as well as a general outlook on Gnosis VPN, at DappCon24 Berlin.

This work completes the deliverables 1.1 and 1.2 of the GIP-98 proposal. Nevertheless, further improvements to uHTTP will be made as we move forward.

Design and development of VPN capabilities for HOPRd

In our original proposal we envisioned the first useful VPN-like functionality to be delivered through a web-browser extension which used uHTTP (see deliverable 1.4 for reference). However, after an initial experimentation phase we discovered that existing web browsers limit web extension functionality too much, making it impossible to design a solution with a good UX. Thus, we pivoted and started focusing on OS-level VPN capabilities, functionality that was originally planned for a later stage.

More specifically, we started designing and implementing the HOPR Session message protocol. This protocol enables HOPRd to expose TCP and UDP ports which can be used to tunnel traffic over TCP and UDP through the HOPR network, both base building blocks to support real VPN functionality in the future.

What does that mean for Gnosis VPN exactly? Firstly, it means the first PoC will act more like existing VPNs from a UX perspective than the original proposal envisioned. This is a welcome change, because user behaviour will not need to change, making Gnosis VPN easier to pick up. Secondly, the first PoC will be closer to the final design, allowing for more time to test and improve performance and reliability as we move forward.

Development of HOPRd v2.2.x

HOPRd v2.2.x is meant as the target release for the Gnosis VPN PoC. As such, it must also provide further performance and stability improvements to cater to VPN-like traffic. Besides the HOPR Session message protocol described in the previous section, we already completed some other notable improvements which we show here in an incomplete list:

Outlook

The focus of the next few months will be on completing the initial implementation of VPN capabilities in HOPRd such that a PoC can be set up and tested. Moreover, work on v2.2.x is planned to complete as well, such that the release can move into an extended testing phase to ensure it sufficiently supports the initial Gnosis VPN PoC.

Thanks for reading. All comments, questions and feedback are appreciated.

12 Likes
43

Introduction

This quarterly report provides an overview of the work being done as part of GIP-98 as a continuation of the work already described in report #1 above.

The HOPR team focused on the following work streams:

  • Wireguard-based VPN architecture
  • Optimizations in HOPR Session protocol
  • Further development of HOPRd v2.2.x
  • Smart contract audit

Wireguard-based VPN architecture

The decision to implement the HOPR Session protocol (see the previous report for context) allows us to shift the bulk of the VPN work to the HOPR side, leaving the GnosisVPN client and server lightweight and streamlined. Having completed the initial HOPR Session protocol implementation, we focused on designing an architecture which could leverage that functionality, be as simple as possible, and relied on existing, well-tested technologies where possible. A key component of this decision was choosing a VPN protocol to use on top of the HOPR mixnet.

With these considerations in mind, we opted to leverage Wireguard [1] as the integration point with the operating system.

Using Wireguard as our VPN protocol has multiple advantages:

  • Wireguard is widely used by vendors like ProtonVPN and Tailscale; as a result it has been optimized and comprehensively tested
  • Wireguard is available natively on some operating systems as well as in many user-space implementations, giving us plenty of options to choose from
  • Wireguard speaks plain UDP, which is already supported by the HOPR Session protocol; therefore it’s directly compatible with HOPR itself

The final architecture is simple, with all interaction between client and server happening in a private and secure fashion.

GnosisVPN-architecture
GnosisVPN-architecture437×572 34 KB

Figure 1: GnosisVPN architecture integrating HOPR and Wireguard VPN protocols. The bold line represents the flow of user traffic and the thin lines are configuration and other control flows.

We will provide more details on the architecture and interaction flows in the next report.

Optimizations in HOPR Session protocol

The HOPR Session protocol allows other clients to use the HOPR network via simple TCP and UDP connections. However, this generic support comes with downsides of having to handle a multitude of combinations of packet sizes and bandwidth. Without optimizations, it would be easy to overload individual nodes or the entire HOPR network. To handle these more reliably, we’ve spent the past months optimizing many parts of the protocol:

  • UDP stream parallelization: Each CPU core is now used to receive data, reducing back-pressure and potentially dropped packets on the network interface.
  • Network segment batching: Small network segments are combined into a single HOPR packet. This dramatically reduces the network overhead within the HOPR protocol in such use cases, therefore improving the user experience.
  • Fast acknowledgment: By prioritizing acknowledgements over other protocol messages, further retransmissions are prevented, further reducing the network overhead.

These are just a few examples of possible improvements As each new use case is tested, we expect to discover further potential optimizations. Each optimization reduces network overhead and improves the user experience of the GnosisVPN PoC. We are aware that while users value privacy, there are limits to the trade-offs they are prepared to accept in terms of latency, stability, etc. Therefore, these optimizations will be a priority for the remainder of the PoC work.

Further development of HOPRd v2.2.x

Besides the aforementioned HOPR Session protocol improvements and many bug fixes, some additional changes made it into the v2.2 release.

The latter changes will allow the HOPR network to move away from 100% ticket winning probability (as currently used within the network) to a much lower value, significantly reducing the number of on-chain interactions HOPR relay nodes need to make to earn rewards. This value can be configured through an on-chain oracle. The lower ticket winning probability is a major enabler for making GnosisVPN viable as it allows users to transmit larger amounts of data over the network in an economical way.

Smart contract audit

Since the HOPRd v2.2 release will be used as the basis for the GnosisVPN PoC, we welcomed the opportunity to get the HOPR smart contracts audited once more, this time by Côme du Crest, Security Researcher at Gnosis.

Côme provided us with a very good report showing that he discovered issues we haven’t been aware of and general improvements. None of the discoveries is critical. Therefore, all feedback was added to the smart contract change scope for HOPRd v3.0 as part of which we will overhaul our smart contracts and can make backwards-incompatible changes. Some changes were already applied to the v3 development branch in Response to audit 20240826 by QYuQianchen · Pull Request #6489 · hoprnet/hoprnet · GitHub

The audit report has been added to our Github repository.

We are thankful to Côme for his efforts.

Outlook

The required work for HOPRd v2.2 is almost complete, with the remainder mostly being bug-fixing and testing and general optimization for VPN usage. HOPRd v2.2 is set to launch before the end of the GIP-98 timeframe. In parallel, work will continue on an end-to-end setup and demonstration of the GnosisVPN PoC, including the GnosisVPN Client, GnosisVPN Server and GnosisVPN Registry components (see Figure 1 above). Thanks to our previous work implementing and optimizing the HOPR Session protocol, completing these final components necessary for the GnosisVPN PoC should be relatively straightforward and is scheduled to be completed within the timeframe given in GIP-98.

Thanks for reading. All comments, questions and feedback are appreciated.

10 Likes
44

Introduction

This is the final report for GIP-98. Intermediate quarterly progress has previously been reported in the first and second quarterly reports.

This report marks the end of the project and work on the Gnosis VPN proof of concept (PoC). Follow-up work on the Gnosis VPN MVP and v1 will be described in detail in the next proposal.

In this report we introduce the Gnosis VPN PoC and provide guidelines on how to get started using it. We also briefly explain the new HOPRd v2.2.0 release before giving a recap and update on the original proposal scope.

Gnosis VPN Proof of Concept

The PoC of Gnosis VPN has been completed and we’ve made it available to the general public. The PoC consists of the following components:

  • Public website: The user-facing public website is https://gnosisvpn.com. It is conceived as the landing page for users interested in Gnosis VPN and provides relevant onboarding information such as links to HOPRd documentation and guidelines on how to set up the PoC as a user.
  • Server Dashboard: Users need to find available Gnosis VPN servers before trying to connect via the PoC. This information is published on https://gnosisvpn.com/servers.
  • Gnosis VPN CLI: The PoC is still developer-oriented and requires the use of a CLI tool. The code can be found on Github, with binaries for Linux and MacOS being published on Github as releases.
  • Gnosis VPN servers: We’ve worked together with the Gnosis infrastructure team to set up an initial set of servers to enable the PoC and support it in the near future.

The best place to learn about the PoC is the public website. But for the sake of clarity of this report we want to give a brief overview here too.

Gnosis VPN PoC, when considered within the scope of a VPN connection, consists of the following software components:

  1. Web browser
  2. Gnosis VPN client
  3. Wireguard client
  4. HOPRd entry node
  5. HOPR network
  6. HOPRd exit node
  7. Wireguard server
  8. SOCKS5 server
  9. Destination web service

Gnosis VPN architecture
Gnosis VPN architecture1600×318 107 KB

The user’s web browser is configured to use a SOCKS5 proxy, which points to the Wireguard connection. Therefore, all traffic will be passed through Wireguard, through the underlying HOPR network, and eventually will reach the SOCKS5 server. That means all HTTPS connections made by the web browser are end-to-end terminated between the web browser and the web server it is trying to reach, which is one of the fundamental privacy goals of the PoC.

The Wireguard connection is set up by first configuring the Wireguard client with the information received from the PoC onboarding flow. At this point Wireguard will try to connect to the chosen Wireguard server, but not be able to open a connection because the HOPRd entry node needs to be configured to provide a private session to the Wireguard server. This final step can be completed by using the Gnosis VPN client (cli tool) to set up the session as documented in the PoC user guide. The HOPRd entry node will establish a private session to the HOPRd exit node which will forward all data to the Wireguard server. At this point the Wireguard client will automatically open a connection to the Wireguard server. Once the connection is open, the user has a working end-to-end VPN connection using the Gnosis VPN PoC.

You can see footage of the PoC in action here. The website at https://gnosisvpn.com has been updated to reflect the latest progress. If you run a HOPR node, you can try the PoC for yourself by following the instructions here.

HOPRd v2.2.0

Over the last 8 months we’ve put a lot of effort into HOPRd to support the functional and performance requirements of Gnosis VPN. This focus has led to the introduction of the HOPR Session protocol (which we’ve covered in the previous two reports), massive improvements in our packet processing pipelines and many other improvements to make HOPRd more stable, performant and reliable.

Release v2.2.0 was published on Github. Updated documentation can be found on our documentation hub. This release provides the foundation for the Gnosis VPN PoC. Over the last 2 weeks the majority of the HOPR network has already migrated to v2.2.0, therefore can support PoC usage as needed.
The work on v2.2.0 has also given us a lot of insight and ideas on how to make HOPRd better in the future and be able to turn the Gnosis VPN PoC into an end-user product.

Recap

As we’ve mentioned in our past reports, while working on Gnosis VPN we discovered that some of our original ideas and deliverables could be improved upon even within the scope of proposal 1. Therefore, we changed the scope as we progressed, always keeping in mind that the final outcome must provide a great foundation for Gnosis VPN. The result is a PoC which far exceeds the expectations set at the outset of this project.

Given these changes, it’s useful to look back and give a quick summary on the status of the original deliverables for reference.

Deliverable 1.1: pHTTP technical design

  • Status: completed
  • Progress was reported in quarterly report #1
  • pHTTP (private HTTP) was renamed to uHTTP (unlinkable HTTP)

Deliverable 1.2: JS client library

Deliverable 1.3: Implementation of exit and entry components

  • Status: completed
  • Progress was reported in quarterly report #1

Deliverable 1.4: pHTTP web-browser extension (PoC)

  • Status: abandoned
  • While preparing for this deliverable we noticed we could create a much better Gnosis VPN with improved privacy guarantees and user experience. This led us to abandon this original deliverable and work on native VPN capabilities instead.
  • Progress on VPN capabilities was reported in quarterly reports #1 and #2 and this final report

Deliverable 1.5: Performance improvements in HOPRd to enable pHTTP

  • Status: completed
  • Progress was reported in all reports
  • Relaying throughput is reliably 1,200 packets per second, 60x more than the original target and a 600x improvement compared to the version at the time of posting this GIP

Outlook

Although we were confident it was feasible to build a VPN connection over the HOPR network in this way, we were uncertain about the performance which could be achieved. Now the work has been completed, we’ve seen the results are 600x higher than where we started, and 60x higher than our target, with many avenues available for further improvement. It’s therefore clear to us that this is a viable approach to building a VPN product which works at scale.

The work on Gnosis VPN Proposal 1 has been beneficial for the HOPR network as well as the Gnosis community at large thanks to the completion of the Gnosis VPN PoC. We want to thank the GnosisDAO for trusting us with their support for this work on a prototype for a new and exciting end-user product in the Gnosis ecosystem. Throughout the project the Gnosis team has been supportive via feedback and discussions on ideas and visions.

We are looking forward to moving beyond this technical showcase to building Gnosis VPN as a user-focused product and pushing the boundaries of a fundamental privacy technology enabled by Gnosis and HOPR. We are proposing the next stage of Gnosis VPN development in proposal 2 which covers moving from a developer-oriented PoC to a user-oriented MVP and on to a market-ready version 1 of the Gnosis VPN product. This work will be driven by the goal of making Gnosis VPN the first truly decentralized, uncensorable and user-friendly VPN.

7 Likes
45

Fantastic effort :raised_hands:

We look forward to seeing what you have planned for proposal 2.

2 Likes