The Clock is Part of the Protocol

I had just finished writing (published later) The Ugly Exit is the Protocol when Markus Sturm published Liquid, Ark & Co. – Die Illusion des Layer 2.

I expected to disagree with more of it than I did. His criticism of Liquid lands for exactly the reason I have been circling around: what matters is not where a system says it settles, but what remains yours when its operators, software and assumptions are having their worst day. The Liquid incident was especially revealing because the multisig did not simply vanish; the authorization machinery apparently reached the wrong conclusion and the signers faithfully acted on it. The trust surface was never only eleven keys out of fifteen. It included software correctness, deployment, validation, operational controls and the competence of everyone maintaining the bridge between L-BTC and Bitcoin.¹

Where Markus pushed me harder was Ark. He gets to Bark, Second's Ark implementation, and writes: “Self-Custody – mit Kalendererinnerungen, die hoffentlich funktionieren.” Self-custody, in other words, with calendar reminders that hopefully work.¹ It is a good line because there is a real problem hiding inside the joke. A VTXO has a clock. If it is not spent, renewed or exited before that clock runs out, the protocol eventually changes who can claim the underlying bitcoin. Second makes this explicit in its own terms: VTXOs have built-in expiries, wallet software normally renews them while online, and an expired VTXO may be swept by the Ark server.²

So I do not think the right response is that expiry does not matter. I think the more useful question is what kind of risk expiry introduces.

Seven days is not seven-day custody#

I recently ran into this experimentally while trying to stretch an Arkade escrow beyond the lifetime of the VTXOs underneath it. The wallet/configuration I was testing was giving me roughly seven-day VTXO expiries while the commercial contract I wanted to express could easily last thirty, sixty or ninety days. At first that looks fatal. How can a sixty-day escrow live inside state that wants attention every seven days?

But there are two different questions hiding there. The first is whether the operator can simply take the sats during those seven days. In the Ark constructions I care about, that is not the design: the VTXO carries a Bitcoin-enforceable exit path, and confirmed fallback paths are constrained by Bitcoin transactions rather than a discretionary redemption promise.³ The second question is whether I must do something before the deadline in order to retain that position. That is Markus's stronger point.

A seven-day VTXO can be self-custodial in the cryptographic sense and still be operationally unforgiving. If my laptop is dead, my wallet never reconnects and nobody broadcasts or refreshes the state, my unilateral exit is not very useful after the relevant timeout has passed. So I have added another question to the framework from my previous essay: who owns the ugly exit, and who has to remain awake to preserve it?

The length of the timeout matters, but I increasingly think it matters less than the quality of the machinery around forgetfulness. A twenty-eight-day expiry with a brittle wallet can be worse than a seven-day expiry with a redundant, non-custodial watcher that automatically refreshes healthy state and exits unhealthy state. Conversely, a seven-day clock with no dependable liveness layer is not something I would want underneath serious long-duration value.

Short expiries may even have useful economic properties. Capital is not left committed indefinitely, stale state gets cleaned up faster, and the operator or liquidity provider does not need to warehouse obligations forever. But those gains are purchased by making liveness an explicit part of the security model. That is not nothing. It is simply a different thing from custody.

The missing category is liveness delegation#

This is where our Arkade escrow experiment became more interesting than I expected. We ended up needing something watchtower-like: not another owner of the money, but an entity that could notice deadlines, maintain state, trigger a refresh, or broadcast the protective transaction when necessary. That sounds at first like rebuilding trusted infrastructure, but only if the watcher receives the keys required to steal the principal.

The more interesting construction is one where the watcher can perform only the actions that preserve an already-authorized state. Give it enough authority to keep the contract alive or to force the safe exit, but not enough authority to redirect the bitcoin to itself. Then the dependency changes character: I am no longer trusting a custodian with the asset; I am depending on infrastructure for liveness while cryptography restricts what that infrastructure can do.

Lightning already lives with versions of this problem. Channels are not passive bearer objects. State has to be maintained, the chain has to be monitored, keys need to remain operational, and professional nodes are deliberately engineered as always-on systems. ACINQ itself has written at length about the operational security required to keep a large Lightning node online and able to react to Bitcoin state.⁴ This is why “just use Phoenix” does not quite close the argument for me.

Phoenix solves a different problem beautifully#

I understand why Markus lands on Phoenix as the exception he is comfortable recommending. Phoenix is an unusually clean example of infrastructure helping the user without simply becoming the user's custodian. ACINQ manages the ugly parts of Lightning, Phoenix uses a single dynamic channel and splicing, and the user does not have to manually manage a pile of channels.⁵

For payments, that is extremely compelling. But the thing I have been trying to build is not merely a payment. I want a commercial contract that can say: these sats are committed to a transaction for weeks or months; one set of conditions releases them, another refunds them, another may require evidence or an attestation, and the ordinary happy path should not require a human escrow company holding the principal.

Could I keep that escrow directly on L1 and use Phoenix only to move value in and out? For simple escrow, yes. Bitcoin already gives us multisig, signatures, hashes and timelocks. A 2-of-3 escrow or a DLC-style contract does not need CTV. But that is not the entire functionality I was testing in Arkade.

What current Bitcoin lacks is a clean general covenant primitive for constraining and rolling forward richer transaction templates. CHECKTEMPLATEVERIFY is still a Draft BIP, not an activated Bitcoin consensus feature. Its attraction is that it can commit a spend to a transaction template and reduce some of the interactivity and storage burden of presigned constructions.⁶

So saying “put it on L1” can quietly change the product. It works very well when the contract is one static output with a handful of eventual spend branches. It becomes much less elegant when I want cheap, repeated state transitions, delegated enforcement, more elaborate settlement flows, or a contract that moves through several states without putting every transition on-chain. That is precisely the territory Ark is trying to explore.

Economic security never really disappears#

The more I work through these systems, the less convincing I find the idea that one of them will finally remove all active infrastructure. Liquid has federation security. Lightning has liquidity, channel state, online nodes and fee management. Phoenix makes those problems vastly more tolerable, but it does so by operating excellent infrastructure around a Bitcoin-enforceable channel. Ark has operator liquidity, VTXO lifetimes, exit trees and liveness. Arkade adds programmable state and its own pre-confirmation security model.³

Long-lived L1 escrow avoids the VTXO-refresh problem, but it pays with blockspace, capital lock-up, fee uncertainty and a much narrower state machine. The moment the contract depends on something happening in the physical world, we are back to witnesses, oracles, bonded arbiters or some other source of economic truth. There is no point pretending these dependencies vanish.

The useful question is whether the dependency has the power to steal, or merely the responsibility to keep the machinery moving. A watchtower that can wake me up or publish a presigned exit is not the same security object as a federation that controls the reserve. An auto-signer restricted to a narrow, pre-authorized policy is not the same thing as handing an operator discretionary custody. The system can have infrastructure without surrendering the failure path.

So how long should a VTXO live?#

This is where I think Markus and I may disagree less than it first appears. I agree that short expiries make forgetfulness dangerous. His calendar-reminder criticism is deserved if the user is literally expected to remember to open an app before a deadline. I am less convinced that the answer is simply to make VTXOs live much longer.

If the protocol economically benefits from shorter-lived state, I would rather make the maintenance automatic, redundant and constrained. My wallet knows the deadline, my own device can refresh normally, an independent watcher can alert me if the operator stops cooperating, and a narrowly authorized enforcer can broadcast the already-valid exit if I disappear. None of those parties should be able to substitute its own destination or rewrite the economic contract.

If that works, the seven-day clock becomes mostly an infrastructure heartbeat. If it does not work — if maintaining the contract ultimately means handing somebody else enough authority to seize or rewrite it — then Markus has identified a much deeper flaw.

The ugly exit still has to belong to me#

My first essay ended with a simple preference: I would rather use a system that fails into an expensive, ugly Bitcoin transaction than one that fails into a polite request to a federation. Markus adds an uncomfortable qualification: an ugly exit that belongs to me but expires while I am asleep is not enough. I agree.

Where I differ is that I do not think this automatically sends us back to Lightning for every application. Phoenix may currently be the cleaner answer for everyday payments. It does not yet give me the programmable, long-lived commercial contract I am looking for. Plain L1 can hold a simple escrow for years, but without currently activated covenant functionality it cannot reproduce every useful off-chain state machine cheaply.

So the research problem gets narrower: can we make liveness delegable without making ownership delegable? Can a watchtower, auto-signer or bonded enforcer keep an Ark contract healthy without ever gaining the ability to become the beneficiary? Can a sixty-day trade escrow safely ride through a series of seven-day VTXOs while its economic terms remain unchanged? And can we make the machinery boring enough that the user never has to set Markus's calendar reminder in the first place?

The clock is part of the protocol. So is who holds the alarm clock.

---

Publishing / placement notes#

Suggested title: The clock is part of the protocol

Alternative titles: Who has to stay awake? / Ark, Phoenix and the right to forget / The ugly exit needs an alarm clock

Suggested subtitle: A response to Markus Sturm on Ark, Phoenix, and what self-custody asks us to remember.

Suggested tags: bitcoin, ark, arkade, lightning, phoenix, layer2, selfcustody, tradefinance

Suggested Nostr intro / note: Markus Sturm's Ark criticism found the missing variable in my own “ugly exit” test: not just whether I can exit without permission, but how long I can safely do nothing. I think that makes Ark's liveness problem more interesting, not fatal.

Image guidance: 01_contract_clock_vs_vtxo_clock.png after the seven-day experiment; 02_ownership_time_liveness.png around the middle and as the best social preview candidate; 03_phoenix_vs_arkade.png after the Phoenix/L1 section.

---

Sources / technical notes#

1. Markus Sturm, “Liquid, Ark & Co. – Die Illusion des Layer 2”, YakiHonne, September 2026. https://yakihonne.com/article/s/markusturm@primal.net/draft-1789329349325 ↩︎

2. Second, Terms of Service §1.6 — VTXO Expiry; Renewal; Expired VTXOs, revised August 10, 2026. https://second.tech/terms ↩︎

3. Arkade, Terms of Service / Security Model. https://arkadeos.com/terms-of-service ↩︎

4. ACINQ, “Securing a $100M Lightning node”. https://acinq.co/blog/securing-a-100M-lightning-node ↩︎

5. ACINQ, “Introducing the new Phoenix: a 3rd generation self-custodial Lightning wallet” and “Swaproot”. https://acinq.co/blog/phoenix-splicing-update and https://acinq.co/blog/phoenix-swaproot ↩︎

6. BIP 119, OP_CHECKTEMPLATEVERIFY, Draft. https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki ↩︎