# Orchid: an open source VPN built on a bandwidth marketplace, paid with nanopayments

> Orchid is a Dart and C++ project that pairs a VPN client with a decentralized marketplace for bandwidth, where providers run a server, a directory lives on Ethereum, and payment happens in probabilistic nanopayments. It suits people who want to build their own client or run a provider node, and it is a poor fit for anyone expecting a packaged VPN binary with a simple connect button.

**OrchidTechnologies/orchid** — Orchid: VPN, Personal Firewall

- Repository: https://github.com/OrchidTechnologies/orchid
- Website: https://www.orchid.com/
- Stars: 705 · Forks: 119
- Language: Dart
- License: AGPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/orchidtechnologies-orchid

## A VPN that sits on top of a bandwidth marketplace

Orchid describes itself as a decentralized marketplace for bandwidth, and the architecture is easiest to read from the folder names. A provider runs a server in the srv-daemon folder, and that server talks to a decentralized directory that runs on Ethereum in the dir-ethereum folder. On top of that marketplace sit two things: a VPN application spread across the app- and vpn- folders, and a lower level client daemon currently in cli-shared.

So the VPN is not the product of the project in the way it is with a commercial tunnel. The tunnel is one client of the marketplace, and the marketplace is the part that matches bandwidth supply with demand. The project is candid about that ordering, describing the VPN as something the team happens to provide on top of the marketplace.

The other part of the design is transport. The project states that it strives to use off the shelf transport protocols whenever possible, naming WebRTC and, in its own words, layered UDP. Because the code is entirely open source under a free software licence, the AGPLv3, the authors say you can remix the stack into anything you want.

That remixing hint is the most interesting thing in the description for an engineer. It means the transport layer, the provider daemon and the client are separable in practice, and a team that wants the traffic plumbing without an Ethereum directory is not locked out of the code.

## Probabilistic nanopayments on an Ethereum layer 2

Users pay for service with what the project calls streaming probabilistic nanopayments, described as a layer 2 Ethereum scaling solution. The authors position it as somewhere between a one-to-many payment channel and a probabilistic roll-up, and they say it builds on older work that they consider seminal, into which they poured effort into economic incentive design and practical integration.

The code for that part lives separately, in the lot-ethereum folder, and the project calls it somewhat separate, on the assumption that you might want to use it for something else.

What this design buys is a payment mechanism that does not require settling every byte of a session on the base layer. The directory in dir-ethereum and the payment logic in lot-ethereum are therefore separable from the VPN client, and both of them depend on an Ethereum connection. For an end user, that is a substantial piece of infrastructure to be willing to operate or to depend on.

It also changes the failure surface. A tunnel whose service is metered by a payment channel has a different set of failure modes from a flat-rate tunnel, and this is the point where a reader who has used ordinary VPNs will find the architecture unfamiliar. The description does not document how a client behaves when a payment channel runs dry, so the practical answer sits in code that is not explained here.

## Building from source means cloning submodules and a specific toolchain

The build story is the part of the project that most affects whether you can realistically use it. The claim is that Orchid is extremely easy to build, and the reason is that every single library dependency is included as a git submodule, so there is no external dependency resolution step. The first thing you must do is therefore:

```bash
git submodule update --init --recursive
```

After that the build system compiles those dependencies, which is why there is no lengthy DEPS list. The required tooling is specific: in addition to the standard set of C and C++ development tools such as autotools, bison, flex and make, the project requires clang 16 or newer, plus ldd, and it notes that neither binutils ld nor gold is sufficient. Some dependency build scripts use Python, one insists on meson and ninja, and a couple of the libraries are written in Rust. The author mentions gcc as a possible future target.

The documentation policy is unusual and worth knowing before you start. The project states that it is neither practical nor appropriate for its documentation to detail how to install these toolchains, because the instructions differ per operating system, per distribution and sometimes per version. The recommended approach is the usual one: try to build, and when an error says a tool is missing, install it.

There are shortcuts for the impatient, which are referenced as scripts in the env folder: env/setup-mac.sh for macOS and env/setup-lnx.sh for Ubuntu or Arch. Once the toolchain is in place you can enter any subfolder, such as app-android, app-ios, cli-shared or srv-daemon, and run make.

## The Docker path exists for people who refuse to trust a binary

There is a second build route, framed around a specific trust scenario. If your goal is only to build a copy of Orchid and you are not prepared to install a compiler, nor willing to trust Orchid, Apple, Google or GitHub to hand you safe binaries, but you are comfortable with the source code, then you can avoid installing anything except Docker. The route is a script in the env folder:

```bash
env/docker.sh
```

The script starts from a bare official Ubuntu image and then installs Rust, clang, NDK and the rest from official first-party sources, and it does not involve binaries produced by the project in any way. The author is explicit that this shifts the trust to Docker itself, and describes the path as a last resort to allow non developers to build from source.

One condition is easy to miss. Even with Docker, you still need the full source checkout, including the submodules. Docker removes the compiler requirement, not the checkout requirement, so a shallow clone without the recursive submodule step will not build.

Note also the scope. This path builds a copy for you to run yourself. It is not an end user install of a VPN client with a subscription flow and a support contract, and reading it as one will set the wrong expectation for a project whose repository is a pile of C++, Dart and Rust build targets.

## The vendored dependency wall is the real cost of building Orchid

Look at the top level of the repository and the scale of the build becomes clear. Alongside the application folders there are a set of min- prefixed directories that each hold a vendored project: min-boringssl, min-cairo, min-glib, min-http3, min-icu4c, min-jinja2cpp, min-krypton, min-openssl, min-pcre2, min-v8, min-webrtc, min-wireshark and min-zlib. There is also eng-mediasoup, a solidity tree in openzeppelin-solidity, a risc zero directory in cyk-risc0, and application specific folders such as gui-orchid, lib-protocol, lib-shared, eth-sender, pac-ethereum, pac-serverless and gai-frontend and gai-backend.

Compiling V8, the WebRTC stack, a Wireshark library set, BoringSSL and OpenSSL is a heavy build. The project does hedge that it is not using anything weird, and that meson is probably the rarest dependency, but a build of that shape still needs time, disk and memory, and the project itself names running out of memory or disk space as the two plausible failure modes beyond a missing command.

The benefit of that approach is reproducibility in a narrow sense. Every dependency is pinned as a submodule in one repository, so there is no separate dependency list to keep in sync and no upstream fetch that can change under you. The cost is that a security update to any of those vendored trees arrives as a commit to this repository rather than as an upstream release, so the upgrade path for the whole stack is the project, not the individual project.

## Where Orchid is the wrong tool

Three situations rule it out, and the project is honest enough to hint at all of them.

First, if you want to run a VPN without building software. There is no released desktop or mobile client described here, only source trees for Android, iOS, Linux, macOS and Windows under the app- folders, plus gui-orchid for a graphical interface. The installation path is a build, and the project frames the Docker script as a last resort for people who want to build from source rather than a normal install.

Second, if you want to run a traditional tunnel with a flat monthly fee and a support contract. Orchid's service is metered through a payment channel on an Ethereum layer 2, and the directory runs on Ethereum. That is a different product shape with different dependencies, and the payments component is described as somewhat separate, which is another way of saying it was designed to be removable.

Third, if you are on a platform the project does not target. The build documentation names macOS, Ubuntu and Arch for the setup scripts, and the applications cover the common desktop and mobile platforms. There is no claim of support for other operating systems, and given the toolchain requirements, including clang 16 or newer and ldd, a platform without that tooling is a problem.

Licence-wise, the AGPLv3 is the most consequential detail for a commercial user. The project states the entire stack is under that licence, and it explicitly invites remixing. Any distribution of a modified Orchid as a service or a binary falls under the copyleft terms of AGPLv3, and how that applies to a specific business model is a question for a lawyer rather than for this article.

## Release history and maintenance: active code, slow tags

The two signals here point in different directions, and it is worth separating them. The repository is not archived, and the last push was on 2026-10-04. The published releases, however, are old: v0.9.44 on 2025-01-19, v0.9.43 on 2023-04-12 and v0.9.42 on 2022-12-30. The version numbers are still in the 0.9 range, so there is no 1.0 marker to wait for.

That gap between commit activity and tagged releases has a practical effect. If you are evaluating the project, you should treat the master branch as the moving target and the tags as a distant reference point, and be aware that a tagged version will not contain the recent work. The project also has a .readthedocs.yml and mkdocs.yml alongside a docs folder, so there is a documentation site, and the .github folder suggests community and issue processes, but the number of people relying on this in production is not something the repository states.

For a project whose core value is a self hosted provider and a payment rail, that means the usual diligence applies. Check the commit history in the areas you depend on, especially the vendored min- trees and the lot-ethereum payment code, and read SECURITY.md before running a provider node with real funds behind it.

## Conclusion

Orchid fits a developer who wants to run a bandwidth provider node, or a team that wants to reuse its WebRTC and layered UDP transport without the Ethereum marketplace attached, and it does not fit a user who wants an installable VPN client with a management UI. Verify first that you can build it, because the dependency tree is vendored through submodules and includes clang 16+, ldd, meson, ninja and Rust, and the last published release v0.9.44 dates from 2025-01-19 even though the last push was on 2026-10-04.

## FAQ

### What is Orchid and what problem does it solve?

Orchid is a decentralized marketplace for bandwidth where providers run a server from the srv-daemon folder and talk to a directory that runs on Ethereum in dir-ethereum. On top of that marketplace the project provides a VPN application and a lower level client daemon in cli-shared.

### How do I build Orchid from source?

Clone the full source including submodules with git submodule update --init --recursive, install the required toolchain including clang 16 or newer and ldd, then run make inside any subfolder such as app-android or cli-shared. The env folder also holds setup scripts for macOS and for Ubuntu or Arch.

### Can I build Orchid with Docker instead of installing a compiler?

Yes, by running env/docker.sh, which starts from a bare official Ubuntu image and installs Rust, clang, NDK and the rest from first-party sources. You still need the complete source checkout including submodules, and the project describes this route as a last resort for building from source.

### How do users pay for Orchid service?

Users pay with streaming probabilistic nanopayments, described as a layer 2 Ethereum scaling solution sitting between one-to-many payment channels and probabilistic roll-ups. The payment code lives in the lot-ethereum folder and the project treats it as separable from the VPN client.

### What licence does Orchid use and can I remix it?

The whole stack is open source under the AGPLv3, and the project says you can remix the stack into anything you want because it prefers off the shelf transports such as WebRTC and layered UDP. The AGPL copyleft terms are what a commercial redistribution has to take into account.

## Sources

- [License: AGPL-3.0](https://github.com/OrchidTechnologies/orchid/blob/master/LICENSE)
- [OrchidTechnologies/orchid on GitHub](https://github.com/OrchidTechnologies/orchid)
- [Project website](https://www.orchid.com/)
- [README](https://github.com/OrchidTechnologies/orchid/blob/master/README.md)
- [Releases](https://github.com/OrchidTechnologies/orchid/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/orchidtechnologies-orchid