Katacomb VPN
A desktop client for the Sentinel decentralized VPN network. Pick a node anywhere in the world, pay for a session on-chain, and Katacomb brings up the tunnel on WireGuard, AmneziaWG, OpenVPN, V2Ray, XRAY or Hysteria2, whichever that node speaks. No accounts, no subscription to a single provider: bandwidth is bought directly from independent node operators with a wallet you hold the keys to.
A look inside
What it does
Everything runs locally against the chain. There is no Trinity Stake server in the path.
Protocols
Each node runs exactly one. The client connects to all six and refuses only nodes advertising an unknown type.
| Protocol | Interface | How it runs | Notes |
|---|---|---|---|
| WireGuard | sntl0 | root (wg-quick) | Uses the distro wireguard-tools |
| V2Ray | sntl-tun | userspace + tun2socks | Bundled core; encrypted DNS over DoH |
| OpenVPN | sntl-ovpn | root (openvpn) | The node's PKI issues the client cert |
| XRAY | sntl-tun | userspace + tun2socks | VLESS + Reality; bundled core |
| AmneziaWG | sntl0 | root (awg-quick) | WireGuard fork with DPI-evasion params |
| Hysteria2 | sntl-tun | userspace + tun2socks | QUIC; refuses to connect without a TLS pin |
Multi-hop chains only work on V2Ray and XRAY. The mechanism is v2ray-core's proxySettings.tag, which the other protocols have no equivalent for. Bundled binaries are SHA-256 pinned; both the app and the root daemon refuse to execute one whose hash doesn't match.
Download
Verify what you downloaded
Every release ships a SHA256SUMS covering both artifacts. Put it next to the download and check it:
sha256sum -c SHA256SUMS --ignore-missing
A checksum on its own only proves the file arrived intact. Anyone who can replace the download can replace the checksums with it. It means something when the checksums reach you from somewhere the binaries don't, which is the point of listing the signing key on this page rather than only on the release:
gpg --verify SHA256SUMS.asc SHA256SUMS
Signing key740A F267 B0D8 162B E477 779D 7315 246A 6E67 F3C6
Before you install
- Linux x86_64 only. There is no Windows, macOS or mobile build.
- Connecting spends real funds. A session is a blockchain transaction priced in
udvpnand paid to the node operator. Failures on the client side are refunded automatically; a session you actually used is not. A multi-hop chain is two sessions and two deposits. - Wallet storage needs an OS keyring. GNOME and KDE ship one; on a bare XFCE or LXQt install, add
gnome-keyring. A missing keyring means saving a wallet is refused outright rather than silently falling back to weak encryption. - On Ubuntu 24.04+, prefer the .deb. With unprivileged user namespaces restricted, the AppImage starts with Chromium's sandbox disabled. The
.debinstalls the AppArmor profile that keeps it on.
Security model
The design assumption worth stating plainly: node operators are treated as adversaries. Their handshake data turns into configs that wg-quick, openvpn and iptables execute as root, and a single PostUp line in a WireGuard config is a root shell. So every node-supplied config passes an allow-list validator first, and anything not explicitly permitted is rejected, including every OpenVPN directive that can run a script. The privileged helper re-validates independently, because its socket is the real trust boundary, and the renderer runs sandboxed with context isolation and no Node access.
Payment order matters too: preflight checks run before the session is paid for, and a failure during the handshake or validation cancels the session and refunds it.
What multi-hop does not do. It protects against one dishonest node: with two hops, neither end holds both your identity and your destinations. It does not make you anonymous. Two operators working together can still correlate the circuit on traffic volume and timing, since the same bytes cross both hops at the same moments. That is a hard ceiling, not something a client can close.
The full model, including the invariants that must not regress, is in the repository.