What it is

Bramble gives devices and automated workers private network access without a coordination server that acts as the authority. It builds an encrypted WireGuard mesh between devices. The list of allowed devices, their revocation status and their service grants live in an ENSv2 subname registry on Ethereum (Sepolia testnet).

ENS (Ethereum Name Service) maps human-readable names to on-chain records. Bramble uses a name such as worker.<tailnet>.eth for each device.

The problem

A typical private network, such as a Tailscale tailnet, relies on a coordination server. That server decides which devices may join. If it is down, blocked or compromised, the network follows it.

I noticed two problems with this model:

• Seat-based pricing. Tailscale charges per seat. Small companies can feel pushed to stay on the free tier by rotating accounts or using other workarounds.
• A single point of failure. One day MagicDNS name resolution stopped working on Tailscale, and the service was down for an hour or two. That showed me the coordination layer is a single point of failure, at least for name resolution.

AI agents add a third problem. An agent that needs a private service usually receives that service's credential, so a leaked agent leaks the backend.

Bramble moves that decision to a public registry. Each peer checks the registry itself, so no single server can admit, block or revoke a device.

Why I built it

I build tools after I run into a problem, as I did with ChronoVault. Bramble started the same way, with the Tailscale problems above.

I first built it at ETHOnline 2026. I did not finish it there, because I had other commitments at the time. The core networking worked, but onboarding and the user interface were almost absent. At ETHGlobal Mumbai I set out to fix that, and most of the new work below came from that goal.

How it works

1. An administrator enrolls a device by writing its public key to the registry.
2. Each peer resolves the registry on its own. A peer configures a WireGuard key only after it finds an authorized record for it.
3. A separate service grant controls which private services a device may reach. The approval service writes grants, but it does not enforce them. The gateway enforces them.
4. Peers that cannot reach each other directly use a relay. Relay operators are discovered through ENS. A node pays for a relay session through x402 (an HTTP payment standard) with testnet USDC on Hedera.

What changed for ETHGlobal Mumbai

Bramble existed before the hackathon. The baseline is commit 28e2a8f, tagged pre-mumbai. The team added the following during the event:

• An approval service and web UI for service-access requests, device enrollment and revocation.
• Agent access. An MCP server lets a coding agent request private access and call the private service without holding the backend credential. Each agent has a spend cap and HashScan links.
• A device installer and local UI, so a new device installs with one command.
• Tor transport for ENS reads and payment requests. The node's IP address is hidden from the RPC provider. Requests fail closed until Tor is ready.
• Hedera Consensus Service (HCS) audit records. Each grant, revocation and payment gets a salted commitment on a Hedera topic.
• Relay-first forwarding for devices without a payer key.

Notable implementation details

• Tor inside the sidecar, with no daemon. The sidecar uses tor-js, which runs Arti (the Tor Project's Rust client) as WebAssembly. Bun's fetch has no SOCKS support, and a system Tor daemon would add a process and disk state to every node. We replaced the library's socket layer because its close() left direct TCP sockets open.
• No local state by design. A CI check fails if the node runtime writes local state. The cost is a full Tor bootstrap on every restart.
• Fail closed. Until Tor is ready, protected requests are rejected instead of going out directly. The sidecar answers 503 on every route except /health.
• Retry under a fresh circuit. In our spike, about 1 in 10 first requests failed. torFetch retries once under a new isolation key, because Tor keeps reusing a failed circuit.
• Guardrails as code. One check fails if any mesh endpoint appears on-chain. Another enforces the no-local-state rule.
• Raw viem instead of ensjs. It was the only client we proved against the custom ENSv2 deployment addresses.

Status

Bramble is a hackathon prototype. The README separates what is verified from what is not:

• Enrollment and service grant and revoke ran on cloud nodes.
• A release installs and enrolls on a non-cloud Linux machine. In the recorded run, that fresh device did not reach the private service, so fresh-device access is not yet working.
• In recorded cloud runs, calls failed about 46 to 51 seconds after a service grant was revoked.
• Hole punching across separate NATs is untested.
• All keys are software keys. An administrator who loses a key can lose control of the registry.

Install a device

Run the installer, then open the local UI that it prints (normally http://127.0.0.1:7777):

curl -fsSL https://get-bramble.whyash5114.com/install.sh | sh

The installer checks the archive checksum and installs bramble, brambled and bramble-sidecar under ~/.bramble/bin/. Join the tailnet in the UI, then ask the operator to approve enrollment. A service grant is a separate approval.

To build from source, install Node.js 22, pnpm 10, Bun and Go, then run:

pnpm install --frozen-lockfile
pnpm verify
pnpm test:access-flow

Outcome

A team of contributors built Bramble. At ETHGlobal Mumbai it won:

• ENS: first place for Best Integration of ENSv2 into an Existing Project.
• Hedera: the Built on Hedera prize in the Continuity track.
• Finalist in the Continuity track.

The ETHGlobal showcase page has the full submission. The repository uses the MIT licence.