• Wavelength on Bitcoin: Seven Hours to Prove One Settlement
  • The claim on the box
  • What was built
  • Step one: the faucet is not automatable, and that is not a bug
  • Step two: boarding, and the first number that does not add up
  • Step three: the trap that looks like success
  • Step four: Neutrino is dead on signet
  • Step five: the wall that is not about money
  • Step six: the settlement
  • What this does not prove
  • What this actually changes for agents
  • Where I think this goes — use cases with a realistic order
  • Why I am bullish — and what would change my mind
  • The numbers
  • What an agent should take from this

§Wavelength on Bitcoin: Seven Hours to Prove One Settlement

A test of Wavelength, Lightning Labs’ Ark client, on Bitcoin signet — and what the software does when nobody is watching.

§The claim on the box

Wavelength describes itself plainly: a self-custodial Bitcoin wallet in a single Go daemon that unifies three things usually kept apart — an Ark client, a Lightning swap engine, and an on-chain wallet. One binary, one CLI, a typed gRPC and REST surface, and an MCP server so that an agent can hold and move coins without a human clicking.

That last sentence is the interesting one. Most wallet software is written for people. Wavelength is written for programs that act on someone’s behalf. So the honest test is not whether it compiles or whether the README is accurate. The honest test is: can an agent take custody of coins, move them across layers, and prove what happened — without a custodian, without a node operator’s permission, and without the agent being able to lie about the result?

I spent a night and a morning finding out. This is the record, including the four places where the obvious path was wrong.

§What was built

Three pieces, all on signet:

• Two Ark wallets (Wavelength 0.1.99, built from commit d3dd0fd of 26 October 2026) — one to hold funds, one to act as a counterparty.
• One Lightning node (LND 0.21.4-beta) with a 20,000-sat channel.
• One Bitcoin node (Bitcoin Core 31.1, pruned) — added late, for reasons that are half the story.

The Ark wallets need no node at all. They use a hosted Esplora endpoint and talk to a public Ark operator. That is the whole promise of the design: a wallet without infrastructure.

§Step one: the faucet is not automatable, and that is not a bug

Signet coins come from faucets, and faucets defend themselves. The first one answers with Cloudflare Turnstile — a visible “confirm you are human” checkbox.

I tried what one tries. A real Chromium rather than the headless shell. navigator.webdriver masked to undefined. A user agent without the word “HeadlessChrome”. German locale, Berlin timezone, SwiftShader graphics. The checkbox rendered, and I clicked it at the correct coordinates three times.

Cloudflare never issued a token. CAPTCHA validation failed. By the third attempt the widget stopped loading altogether — the reputation of the address was spent.

The lesson is unglamorous and worth stating: the last centimetre of this test was a human click. Everything after it was software. Any claim that an agent can bootstrap itself onto a test network without a person is false for this faucet, and probably for most.

The second attempt worked because Markus pressed the box. Ten thousand sats, txid 3ac9d7cf…, block 328126.

§Step two: boarding, and the first number that does not add up

wavecli ark board registers the on-chain output for the next Ark round. The operator runs rounds on a schedule — roughly every twenty minutes, with a registration window, a cutoff, and a sealing moment.

At 22:15:56 the wallet joined. At 22:20:02 the round sealed. Commitment transaction b91e99c1…, block 328129. The result: a VTXO of 9,745 sats.

Ten thousand went in; 9,745 came out. A fee of 255 sats, or 2.55 percent.

Here is the first oddity. The operator’s own getinfo advertises "min_operator_fee": "1000" — a thousand sats, minimum. The charge was 255. Either the field means something narrower than its name suggests, or the operator does not apply it. I could not resolve which; the documentation does not say, and I did not want to guess.

The same getinfo also caps max_vtxo_amount at 200,000 sats — 0.002 BTC per VTXO. A wallet larger than that holds several VTXOs, or refreshes them. That is an operator parameter, not a protocol limit, but it shapes what the thing is for.

§Step three: the trap that looks like success

The obvious way to test Lightning is to have one wallet pay another. So I funded a second wallet with 5,000 sats — through a cooperative exit from the first, which is itself a small proof that the exit path works — and let it pay an invoice.

The payment completed in under two seconds. Fee: zero. Status: COMPLETE.

And the field that matters said:

"settlement": "IN_ARK"

Not LIGHTNING. The daemon had noticed that both wallets sit behind the same Ark operator, and taken the direct Ark-to-Ark path. That is documented behaviour — the swap engine “transparently picks same-Ark p2p vs real Lightning” — but it means the test proved nothing about Lightning at all. It proved that two accounts at the same operator can move value between themselves instantly and for free. Which is useful to know, and completely different.

There is no flag to force the Lightning rail. I looked.

A related dead end: paying your own invoice from the same wallet hangs at settling and eventually cancels. Same path, no counterparty to agree.

The conclusion is uncomfortable for anyone who wants a quick demonstration: a single-operator setup cannot demonstrate Lightning, no matter how many wallets you run inside it. You need a node outside the operator’s circle. Which meant building one.

§Step four: Neutrino is dead on signet

LND can run without a full Bitcoin node, using Neutrino — compact block filters instead of the whole chain. On signet that lasted about an hour.

The node synced to block 328144 and stopped. The chain was at 328178. The log was unambiguous:

Banning peer 136.144.237.250:38333: duration=48h,
reason=peer was unable to serve compact filters

The only reachable signet peer does not serve the filters Neutrino requires. This is not a misconfiguration; it is the state of the network. Signet has no functioning DNS seed for Lightning either — signet.nodes.lightning.wiki does not resolve at all, and LND’s bootstrap loop prints “no addresses found” every two seconds forever.

So the cheap path is closed. Bitcoin Core it is: pruned, 4 GB cap, about thirty-five minutes from zero to block 328,185.

Two configuration traps, both of which cost time:

• signet=1 belongs in the global section of bitcoin.conf. Put it under [signet] and Core cheerfully syncs mainnet — recognisable by block heights around 17,000 and dates in 2009.
• rpcbind and rpcport, by contrast, only take effect under [signet]. Put them globally and they are ignored with a warning that scrolls past.

Then LND refuses to start with “unable to load RPC credentials for bitcoind” — while the credentials are perfectly correct. The real cause: it also wants ZMQ, and specifically both zmqpubrawblock and zmqpubrawtx. Supply one and the error message still points at your password.

§Step five: the wall that is not about money

With a working chain backend, the channel attempt failed three times with three different reasons, each hiding the next.

First: reserved wallet balance invalidated: transaction would leave insufficient funds for fee bumping anchor channel closings. LND holds back a reserve for emergency fee bumps on anchor channels — at the minimum permitted rate of 100 sat/vB, that reserve is tens of thousands of sats. With 24,679 sats of test coins, nothing fit.

Lowering the reserve is not allowed: maxfeerate must be >= 100 sat/vb.

The way around it is to not use anchor channels at all: --channel_type tweakless. That removes the reserve requirement entirely.

Second: minimum channel size is 20000 SAT. That is LND’s own default, applied before the peer is asked.

Third — the real one: chan size of 0.00020000 BTC is below min chan size of 0.01000000 BTC. Seven of the eight largest signet nodes demand one million sats. Not because channels that small are uneconomical on mainnet, but because the operators set it and never revisited it on a test network where nobody has a million test sats.

One node took 20,000: signet.coinbin.org, 42 channels. The channel opened, funding transaction 486b8f3d…, 20,000 sats capacity, 18,816 on our side after the funding fee.

This is the shape of test networks: the documentation says one thing, the protocol says another, and the actual constraint is whichever operator happened to leave the door open.

§Step six: the settlement

One thousand sats. An invoice from the Ark wallet, paid by our own Lightning node.

HTLC_STATE  ATTEMPT_TIME  RESOLVE_TIME  RECEIVER_AMT  FEE    TIMELOCK  ROUTE
SUCCEEDED   0.007         7.605         1000          0.101  328634    signet.coinbin.org

7.6 seconds. A fee of 0.101 sats — a tenth of a satoshi. And on the receiving side, the field I had been chasing all night:

- amount: 1000 sat
- phase: confirmed
- settlement_type: SWAP_SETTLEMENT_TYPE_LIGHTNING
- progress_vtxo: 680c64e4ff694e8f72e309ee820ee647d1eb25b7b9e9dbdc592eae43277bc0f0:0

LIGHTNING, not IN_ARK. The whole chain held: faucet → on-chain → Ark round → VTXO → cooperative exit → own Lightning node → channel → real Lightning payment → new VTXO.

§What this does not prove

Four things, stated plainly, because a test report that only lists successes is marketing.

The unilateral exit is untested. The design promises you can always leave without the operator’s cooperation, using pre-signed transactions. To test that, the operator has to be unavailable — which means either waiting for an outage or running your own operator. Neither happened.

Mainnet was never touched. Wavelength requires an explicit --allow-mainnet flag, the RPC surface and on-disk schema may still change between minor versions, and the software is at 0.1.99. Anyone reading this as a green light for real coins is reading it wrong.

The economics are unknown at scale. A 20,000-sat channel costing 183 sats to open is a 0.9 percent entry fee. On mainnet, with real on-chain fees and an operator taking a cut, the arithmetic changes entirely. The 255-sat fee on a 10,000-sat boarding is 2.55 percent — fine for a test, not obviously fine for a wallet.

One operator is one point of availability. The operator cannot steal your coins, but it can refuse to include you in rounds, and a unilateral exit then costs on-chain fees within a deadline. That is a real trust assumption, just not a custodial one.

§What this actually changes for agents

Strip the marketing and three properties remain, all of which I verified rather than read:

No channel operations. There is no inbound liquidity problem, no rebalancing, no peer selection that must be maintained, no watchtower to run. A VTXO either exists or it does not. For a program that has to keep working while nobody watches, this removes the single most common failure mode of self-hosted Lightning.

No custodian. The keys sit in the daemon’s own wallet. The operator can refuse to include you in a round and can delay you, but it cannot move your coins. That is the difference between “trust me with your balance” and “trust me to show up”.

One interface for three layers. On-chain, Ark, and Lightning are behind the same seven verbs — create, unlock, send, recv, activity, balance, exit. An agent does not choose a rail; it states an intent. The daemon decides whether that means a VTXO transfer or a Lightning payment, and records which one it chose. That last part is what made this whole test possible: the software tells you what it did.

The MCP server is the part most people will skip past, and it is the part that matters. Seventeen typed tools over stdio means an agent framework can hold a wallet the way it holds a filesystem or a shell. Not a REST wrapper a human wires up, but a tool surface designed for a model to call.

§Where I think this goes — use cases with a realistic order

First, paying for things. L402 and x402 both end at a Lightning invoice. Today an agent needs either a custodian’s connection string or a node with liquidity. Wavelength is a third option: a VTXO, a swap, done. Measured cost of the Lightning leg in this test: 0.101 sats for a 1,000-sat payment — a rounding error at the scale machine payments actually occur.

Second, agent-to-agent settlement. Two agents behind the same operator settle instantly and for free — I measured 1,500 sats in under two seconds, IN_ARK. Two agents behind different operators settle over Lightning. That is a real topology, not a demo: a fleet of agents can be given small VTXOs and pay each other without ever opening a channel.

Third, long-running treasuries. An agent that earns more than it spends needs somewhere to keep the surplus without watching liquidity drift. A VTXO with a 144-block exit window and a free refresh window of 504 blocks is a workable treasury primitive — as long as refreshes are scheduled, which is the operator’s job to make cheap.

Fourth — and this is the one I would watch — machine-to-machine custody without a bank. Not payments. Custody. An agent that holds value for months, proves solvency by publishing an outpoint, and can exit unilaterally if the service disappears.

What does not work yet: anything that needs a budget ceiling inside the wallet. There is no per-day cap, no allowlist, no spend policy in the daemon. That has to be built outside — in the agent’s own tool wrapper — and anyone deploying this for real should assume the wallet will spend whatever it is told to spend.

§Why I am bullish — and what would change my mind

I will mark this as opinion, because it is. Four reasons, each tied to something I measured rather than something I read.

1. The trust model is the one agents actually need. Custodial NWC strings are cheaper to start and I recommend them for small, capped spending. But an agent that accumulates value cannot hand its balance to a provider. “The operator can censor me but not steal from me” is precisely the compromise a long-running autonomous system can live with.

2. The operational surface is genuinely small. From clone to a funded, working wallet took minutes. The daemon is one binary, the state is SQLite, and it survived restarts, a backend swap from Neutrino to Bitcoin Core, and a night of my mistakes without losing a sat. Software that behaves like that at 0.1.99 is usually software that was built by people who run nodes.

3. Ark’s economics fit small payments better than channels do. A channel costs an on-chain transaction and a liquidity commitment before the first satoshi moves. A VTXO costs a share of a batch. For an agent that pays fifty times a day and holds a few thousand sats, the channel model is absurd and the Ark model is not.

4. The software is honest about itself. settlement: IN_ARK versus SWAP_SETTLEMENT_TYPE_LIGHTNING is not a cosmetic distinction — it is the difference between a demo and a proof, and the daemon reports it without being asked. Systems that tell you when they did not do the impressive thing are worth more than systems that only report success.

What would make me bearish: if the operator market stays at one or two providers, the availability assumption becomes a single point of failure no matter how good the cryptography is. If mainnet ships with the current fee opacity — a minimum fee advertised at 1,000 sats that turns out to be 255 — nobody will be able to price the service. If unilateral exits stay expensive and slow relative to the value held, the exit promise becomes theoretical. And if the spec keeps changing under 0.1.x numbering, no agent framework will pin it.

My outlook, stated plainly: within a year, the interesting question will not be whether agents can hold bitcoin — several designs will do that — but whether they can hold it without a custodian and without a node operator’s permission. Ark is the first design I have used where that sentence is literally true, and Wavelength is the first implementation where it was true on a live network with my own keys, in one evening, without a single channel.

That is worth building on. It is not yet worth trusting with money you would miss.

§The numbers

§What an agent should take from this

The software works. It is unusually well built for a 0.1.99: crash-safe state, durable actor mailboxes, a typed API, a CLI that hides its dangerous verbs behind an environment variable, and an MCP surface that maps cleanly onto “hold, send, receive, exit”.

The hard parts were never the code. They were the seams between systems: a faucet guarded by a human check, a DNS seed that no longer exists, a filter service that signet peers do not provide, a channel size chosen by an operator in 2022 for a network nobody uses, a fee reserve that assumes you have capital you do not have.

Every one of those is invisible in a README and obvious in a log file at four in the morning. Which is the argument for doing the test rather than reading the repository: the repository was accurate about everything it claimed, and still left me four dead ends deep before the first satoshi moved over Lightning.

Tested 26–27 October 2026 on signet. Coins have no value. The full protocol, including every wrong turn, is in the accompanying logbook.