Barkd is what you run when you want to enable bitcoin payments server-side. It's our reference daemon wallet: a single binary that runs alongside your other services and exposes a REST API for sending and receiving Ark, Lightning, and on-chain payments. It's best for exchanges, payment processors, merchants, and self-hosted node platforms.

But most people will want to run Barkd in the cloud, which poses security risks. The daemon holds a BIP39 mnemonic, derives keys from it, and signs transactions. On a standard cloud VM, the cloud provider, the hypervisor, and other tenants on the same physical host can theoretically read what's in that VM's memory. The keys are only as safe as the hardware underneath them, and in this case you don't own the hardware.

I've been experimenting with using a Trusted Execution Environment (TEE) to help minimize that trust requirement.

The short version: it works. Barkd runs unmodified inside an Azure confidential VM, the keys are hardware-protected from the infrastructure provider, and the bill comes in at less than a nice dinner each month.

It runs in an AWS Nitro enclave too, but that route requires more work due to the connectivity needs of Barkd.

For server applications only

While Barkd isn't the only way to use Bark, it is the best for servers. Mobile and desktop devs should normally reach for the Bark SDK instead, where keys already live on the user's device and a TEE isn't relevant. This article is about the server-side case, where the keys have to sit on a machine you don't physically control.

What a TEE actually buys you

A TEE is a slice of CPU and memory the rest of the machine can't see into. The hypervisor schedules it, the host OS sits underneath it, other tenants share the same silicon, but none of them can read the bytes inside.

For Barkd, that means the mnemonic and the derived keys can sit in RAM that the cloud provider literally cannot decrypt, even with full hypervisor access.

Intel SGX: a dead end on consumer hardware

My first attempt was Intel SGX on a ThinkPad X13 (i5-10310U). On paper, the CPU supports it. In practice, Lenovo's BIOS doesn't expose the Flexible Launch Control (FLC) toggle, and without FLC the Linux kernel refuses to create the SGX device. A Thinkpad P1 Gen4 with a Xeon W-11855M then shockingly turned out not to support SGX at all. Intel quietly dropped it from 11th-gen client silicon. We're 0 for 2 on the SGX front.

Thinkpad X13 specs in CLI

AWS Nitro Enclaves: it works, but you pay in plumbing

Next up was AWS Nitro Enclaves. We built a working proof of concept: Barkd compiles, runs inside the enclave, and serves its REST API through a vsock bridge. It connects to the Ark server and Esplora through vsock proxies running on the parent EC2 instance.

It works...but requires some custom rigging.

A Nitro Enclave has no network of its own, so every byte of traffic shuttles in and out over vsock using socat and vsock-proxy. It has no disk, so wallet state vanishes on restart unless you bolt on a KMS-sealed backup system that encrypts the wallet database and stores it in the host instance. The loopback interface doesn't come up automatically—lots of annoying surprises.

The bigger problem was architectural: the parent instance proxies all of Barkd's network traffic. While it can't read the TLS contents, it can drop or delay connections, which is a no-go because Barkd relies on a lot of time-sensitive operations. E.g., if the parent blocks round participation long enough, VTXOs could expire.

Azure confidential VMs: where things clicked

Azure's DC-series confidential VMs, running on AMD's SEV-SNP, turned out to be the straightforward answer.

The CPU encrypts every page of guest memory and the hypervisor only sees ciphertext. Barkd runs completely unmodified, with normal networking, normal disk persistence, and no fancy vsock plumbing or proxy sitting in the middle of every connection.

The setup flow was nice and simple:

$ ssh azureuser@<vm-ip>
$ curl -L https://gitlab.com/ark-bitcoin/bark/-/releases/bark-0.1.4/downloads/barkd-0.1.4-linux-x86_64 \ --output barkd
$ chmod +x barkd
$ ./barkd --datadir ~/.bark

From there, you grab the authentication token Barkd generates and plug that into your application.

AMD's attestation even lets a third party verify what's running inside the VM, so you can prove it's the real Barkd binary, not a modified version that quietly ships keys off to a server somewhere.

Diagram: trust boundary comparison across a standard cloud VM, an AWS Nitro Enclave, and an Azure SEV-SNP confidential VM, showing which components sit inside vs. outside the hardware-protected boundary in each case

Where the trust model still has gaps

The TEE protects Barkd from:

  • Azure
  • the hypervisor
  • co-tenants on the same hardware

It does not protect against anyone with SSH access to the guest itself. Whoever controls the VM still controls the keys.

The trust boundary is also wider than SGX or Nitro: the entire guest kernel sits inside the TEE, not just the Barkd process. A kernel exploit inside the VM would expose the keys. For a single-purpose VM running nothing but Barkd, the kernel attack surface is minimal, but it's important to be aware about what's protected and what isn't.

$63 a month, less than half the Nitro setup

The smallest Azure confidential VM, DC2as v5, runs at $0.086 per hour, working out to about $63 a month. Two vCPUs and 8 GB of RAM is overkill for barkd, but it's the smallest SEV-SNP instance Azure offers.

The equivalent Nitro setup is closer to $140 a month, because you need a minimum of 4 vCPUs: two for the enclave, two for the parent to handle all that vsock plumbing.

Toward a hosted Barkd that can't touch your keys

The same AMD EPYC silicon Azure rents is available on bare-metal pricing too. A dedicated provider could rack these machines and offer locked-down Barkd micro-instances as a service: an immutable VM image with no SSH, no remote access, and ttestation covering the whole boot chain. The provider handles uptime and connectivity to the Ark server, but can't touch the keys.

Diagram: future hosted-barkd architecture showing a user verifying an attestation report before trusting a locked-down SEV-SNP VM that runs only barkd with an immutable image, no SSH, no remote access, talking to the Ark server

The goal of this work was to lay the groundwork for getting a hosted wallet with a trust model much closer to self-custody. To productize this, there's still a lot of engineering work to solve, like locking down the image, building the attestation pipeline, and packaging it into something customers can verify without needing to understand SEV-SNP internals. But I hope this project demonstrated it can work, and without any new cryptography.

For more updates like this (and product releases), subscribe to our newsletter or come find us in the community forum.