GIP-122 Quarterly Update #5
Introduction
As part of GIP-122, we committed to giving quarterly updates on the development and launch of Gnosis VPN. We are pleased to present the fifth overview of our progress so far. Deliverable identifiers refer to the list provided in GIP-122.
HOPRd v4
In the previous update we reported that HOPRd v4 was feature complete for the scope we had planned, with further work still needed around optimization, path finding, and stabilization. This quarter we continued that work and focused on integrating the v4 changes more deeply across the GnosisVPN stack.
The most important work this quarter was around path planning, transport performance, telemetry, and channel lifecycle management. These areas are directly relevant to deliverables A1 (Remove dedicated HOPR node requirement), B3 (Short time-to-first-use), C1 (HOPR network supports thousands of mix nodes), C2 (HOPR network provides enough bandwidth to handle Gnosis VPN requirements), and D1 (Local VPN entry).
On the protocol and networking side, we continued improving graph-based path planning and peer discovery. HOPRd now exposes more useful network graph and status information, which helps automated routing decisions and debugging. The path-planning work also now propagates path costs end-to-end, which is important for selecting valid routes that are suitable for sustained GnosisVPN traffic.
We also continued optimizing the packet processing pipeline. Several changes reduced overhead in the transport path and session handling, including improvements to packet encoding and decoding, session configuration, and egress handling. These improvements are not immediately visible to users as individual features, but they are essential for making GnosisVPN more stable and performant as more users are onboarded.
Finally, we improved telemetry and status reporting across HOPRd. More session and component-level metrics are now exposed via OpenTelemetry and related interfaces. This gives us much better visibility into client behavior, route quality, session stability, and channel state, all of which are important while we continue testing with real users.
Edge client and channel lifecycle
A significant amount of work also went into the edge-client layer, which is the part of the system that allows GnosisVPN users to connect without running a full HOPR node. This remains a key component of deliverable A1.
The major change this quarter was the introduction and adoption of a unified channel lifecycle strategy. This brings channel opening, funding, closing, and finalization into a single configurable strategy instead of relying on separate pieces of logic. The same work also improves how channel capacity is calculated and how the client reacts to changes in balances, ticket prices, and winning probabilities.
This is important for two reasons: First, it reduces the amount of manual setup and intervention required from users. Second, it gives the client better information about funding levels needed to support real VPN traffic. Together, these changes move GnosisVPN closer to the intended user experience: a VPN client which handles the HOPR-specific complexity internally, rather than exposing it to the user.
We also improved Safe and wxHOPR handling. The client now supports a simpler single-address funding flow, with automatic movement of wxHOPR into the Safe. This is a major UX improvement because it removes another piece of manual channel and balance management.
General purpose indexing with blokli
Our dedicated indexer, blokli, continues to be an important part of the GnosisVPN architecture. In earlier updates we explained that moving indexing into a dedicated component helps edge clients avoid a lengthy local indexing process and improves time-to-first-use. This quarter we continued extending blokli beyond its initial GnosisVPN-focused use case.
A major focus was reliability and observability. blokli now exposes more metrics, including support for OpenTelemetry export, and has better generated metrics documentation. This improves our ability to monitor deployed infrastructure and diagnose issues during user testing.
We also improved Safe-related indexing and inspection. blokli now supports more detailed reporting on Safe internal transaction status and reasons for reversion, improved Safe queries, and better compatibility checks between clients and servers. These are important because GnosisVPN relies on accurate chain state and funding information, but the user should not need to understand or debug that chain state themselves.
In parallel, blokli’s local development and testing setup was improved to match the deployed network more closely. This makes it easier to test funding, ticket price, and winning probability behavior before changes are shipped into production-like environments.
Development progress and releases can be followed on Github: GitHub - hoprnet/blokli: Indexes on-chain events related to HOPR smart contracts and provides the HOPR Indexer API · GitHub
GnosisVPN client improvements
We continued improving the GnosisVPN client, with a focus on security, routing, funding, diagnostics, and general reliability. These changes are directly relevant to deliverables A2 (Provide VPN app which handles all configuration and logic), B3 (Short time-to-first-use), C2 (HOPR network provides enough bandwidth to handle Gnosis VPN requirements), and D1 (Local VPN entry).
Improvements this quarter include:
- Traffic leak protection: We added a connection-time kill-switch to prevent traffic leaks before the VPN is fully connected and until it is disconnected. This is an important step for making the VPN safer to use as a default network path.
- Routing and DNS improvements: We overhauled routing logic, improved routing teardown, added DNS bypass handling for private ranges, and continued the move toward more robust Linux routing using netlink and nftables. These changes improve reliability and reduce the risk of DNS or routing leaks.
- Simpler funding flow: We consolidated channel funding and introduced single-address funding support. The client can now move wxHOPR into the Safe automatically, reducing manual steps for users.
- Better route and exit health: Connectivity checks and exit health were consolidated into a unified route health model. This helps the client make better decisions about usable routes and fallback behavior.
- Session and SURB improvements: We added session pseudonym caching to reuse already warmed-up session SURBs on the exit. This helps reduce repeated setup work and contributes to better session startup behavior.
- Improved diagnostics: The status command now works better offline and can show pending connections. We also added more detailed debugging output and improved formatting for balances and addresses.
- More reliable shutdown and recovery: We fixed several worker, socket, routing, and setup edge cases which could previously lead to confusing states or unreliable shutdown behavior.
Many smaller bugs were also fixed across the client. These included fixes for funding status reporting, routing table restoration, macOS App Nap behavior, service directory setup, peer address handling, and better surfacing of initialization errors.
As always, progress can be followed on the Github repository: https://github.com/gnosis/gnosis_vpn-client
GnosisVPN app and user experience
In addition to the lower-level client work, we continued improving the desktop app. The focus this quarter was to make the app clearer, more responsive, and easier to use during onboarding and testing. Huge thanks to the members of Gnosis Ltd and the wider Gnosis community who participated in the first phase of user testing.
The app now includes in-app update check functionality, allowing users to see when a newer version is available. This is important while the client is still moving quickly and while we are onboarding users in larger groups.
We also redesigned exit node switching. The previous dropdown has been replaced with a clearer modal flow, including confirmation, inline warnings, and a “Don’t ask again” option. The app also now handles Auto mode more intelligently, using health information to select and sort nodes.
Funding and usage visibility were improved as well. The app now includes a dedicated funding screen, better balance display, QR and copy improvements, and clearer information about data usage, wxHOPR, and remaining credit. This is important because funding is still one of the most unfamiliar parts of the VPN experience for users who are not already deeply familiar with HOPR.
Several changes also make the app feel more responsive. The app now reacts immediately to connect and disconnect events, shows clearer synchronization progress, and displays recovery countdown information when needed. We also improved tooltips, version display, Linux tray icons, and general UI layout details.
Together, these changes make the product easier to test and bring us closer to the Version 1 goal of a market-ready client for users who should not need to understand the underlying HOPR mechanics.
Packaging, testing, and release infrastructure
We also spent time improving the release and testing infrastructure around GnosisVPN. This is less visible than app changes, but it is important for scaling testing and onboarding.
For Linux users, we introduced a signed APT repository and bootstrap installer for Debian and Ubuntu. This makes installation and updates easier and more reliable than manually downloading packages from Github releases. We also improved package signature verification documentation and release artifact publishing.
Across the GnosisVPN repositories, we added snapshot and nightly builds, improved CI workflows, and migrated more builds to Depot runners. We also added more hardening to workflows, including pinned action SHAs, security audit workflows, Codeowners, container scanning, and more restrictive GitHub Actions permissions.
We also continued expanding automated testing. In particular, system tests now start the client and verify download and IP lookup behavior through GnosisVPN against the deployed network. This gives us better coverage of real-world behavior and helps us catch regressions before users encounter them.
New releases continue to be published in the dedicated top-level Github repository: https://github.com/gnosis/gnosis_vpn/releases
Funding
As part of the ongoing funding for this GIP, HOPR received 1.2m USDS in exchange for 73,201,396.3971578118 HOPR tokens. The transactions can be found here and here.
Outlook
We are now preparing the final stretch before showcasing Gnosis VPN at DappCon 2026 in Berlin. This will be an important opportunity to put the application in front of more future users, collect feedback, and identify further product improvements. If you’re attending DappCon, please visit our booth and try out the latest version of the VPN.
Testing has dropped to a slower pace while we implement the feedback from the first round, but is planned to pick up again strongly after DappCon. Current usage can be seen on the dashboard: https://dune.com/hopr/gnosisvpn-active-users
Over the coming months we will focus on stabilizing the current client and app, improving onboarding, and continuing to test the full GnosisVPN stack with real users.
We will also keep working on routing, funding, telemetry, and release infrastructure so that the product can support larger user batches more reliably.
Everything is progressing according to our projected timelines. We look forward to hearing your feedback!