If you're building a serious project on the Ark protocol and need bitcoin moving, you're likely reaching for Barkd. 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. Webshops, exchanges, payment processors, and self-hosted node platforms are the obvious fit.

But running Barkd in the cloud raises an awkward question. The daemon holds a BIP39 mnemonic, derives keys from it, and signs Ark 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.

We've spent the last few weeks experimenting with what it would take to close that gap using a Trusted Execution Environment (TEE). 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.

Worth flagging up front: Barkd isn't the only way to use Bark. Mobile and desktop apps reach for the Bark SDK instead, where keys already live on the user's own device and a TEE isn't needed. 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. The CPU vendor's attestation also lets a third party verify what code is running inside.

Intel SGX: a dead end on consumer hardware

Our 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 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.

Needless to say we quickly abandoned this route.

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

Next stop 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. Every step had a surprise.

The bigger problem is architectural. The parent instance proxies all of Barkd's network traffic. It can't read the TLS contents, but it can drop or delay connections. Barkd has time-sensitive work to do. If the parent blocks round participation long enough for VTXOs to expire, that's a potential loss of funds. You've protected the keys but the leverage the host instance has still remains.

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. The hypervisor sees ciphertext. Barkd runs completely unmodified, with normal networking, normal disk persistence, no vsock plumbing, no proxy sitting in the middle of every connection.

The setup flow is uneventful, which is the point:

$ 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

That's it. AMD's attestation then 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 Telegram bot somewhere. From there, you grab the authentication token Barkd generates and plug that into your application.

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, and 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 worth being upfront about what's protected and what isn't.

This is a meaningful step short of full self-custody, but certainly not a replacement for it.

$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.

For protecting wallet keys from your cloud provider, $63 a month is hard to argue with.

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, attestation 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

That's the convenience of a hosted wallet with a trust model much closer to self-custody. The gap between this research and that product is mostly engineering, not unsolved cryptography. The hard part, running Barkd in a TEE with hardware-protected keys, already works. What's left is locking down the image, building the attestation pipeline, and packaging it into something customers can verify without needing to understand SEV-SNP internals.

If that's the kind of work you'd want to plug into, subscribe to our newsletter or come find us in the community forum.