The Ugly Exit is the Protocol

The recent Liquid hack has made me really evaluate all sidechains and efforts to add programmability and functionality to Bitcoin, and I started with some first-principles thinking to rank my preferences. The easy way would be to compare speed, liquidity, contract languages and ecosystem size. I found myself caring less about every one of those as soon as I asked what remains when the system is having its worst day.

The happy path tells me how pleasant a protocol feels. The ugly path tells me what I actually own. When the operator disappears, the signer set freezes, an indexer disagrees, a key is compromised or the fee market catches fire, can I still use a Bitcoin transaction to take possession of my sats? Or do I have a claim against a machine that must continue recognizing me?

Liquid put that distinction in front of everyone again. The exact exploit matters and the post-mortem will matter, but the larger shape was visible immediately: thousands of bitcoin sat in a shared backing pool, and a failure in the authorization path exposed almost the whole pool at once. A federation of recognizable institutions can look reassuring, yet the names are still doing work the base protocol is not doing. Once the exit narrows through a shared set of keys and rules, every user inherits the same door.

The useful spectrum is not fast to slow. It is whether Bitcoin or an external authority owns the final exit.

Pooled custody keeps finding its way back#

That is what cooled me on Subfrost, even though Alkanes initially looked interesting. Alkanes lets an indexer derive deterministic contract state from data committed in Bitcoin transactions. No separate chain has to decide whether the contract call happened. There is real elegance in using Bitcoin as the record and letting every compatible indexer reproduce the same state.

But the state can be perfectly legible while the money is still somewhere else. As soon as the useful asset becomes frBTC, the underlying bitcoin sits at a single address controlled by a threshold signer group. Burning the token tells the signers who should receive BTC; it does not give the holder an independent Bitcoin transaction that can force the redemption. I can admire the state model and still conclude that, for my purposes, I have walked back into the bridge problem through a more interesting front door.

This is the recurring trick in Bitcoin programmability. “Anchored to Bitcoin” describes where evidence lives. “Settles on Bitcoin” may describe where the final transaction appears. Neither phrase, by itself, tells me who has the power to produce that transaction. Once I separate those questions, Alkanes and Subfrost stop competing with Ark in my head. One is an indexed application state with threshold custody bolted onto the money; the other is trying to make the user’s claim itself a Bitcoin-enforceable transaction structure.

A temporary honesty assumption leaves permanent doubt#

Spark comes much closer, which is why I find its flaw more frustrating. The user has a pre-signed exit. Funds are not all thrown into one giant redeemable token pool. The operator federation cannot simply spend the user’s leaf on its own, and the potential blast radius is far narrower than a conventional bridge.

Then ownership transfers by rotating signing shares, and safety depends on the old operator shares really being deleted. Spark calls this a moment-in-time or 1-of-n honesty assumption: one operator must behave correctly during the transfer and destroy its obsolete share. The assumption may be temporary in the protocol timeline, but the uncertainty it creates is permanent. I cannot inspect a machine later and prove that information once held has ceased to exist everywhere.

That is almost the reverse of the kind of trust reduction I want from cryptography. A good monetary construction turns a promise into an inability: the old owner cannot spend, the operator cannot take, the timeout cannot be ignored. Key deletion leaves me with “they could, but we believe they no longer possess the material.” Perhaps that risk is small in a distributed federation. Perhaps the incentives and audit trails are enough for many users. I still do not want a chain of prior owners and historical deletion ceremonies hiding underneath an asset I may hold for serious value.

Spark therefore falls out of my own viable set despite being much safer than Liquid in several ways. The remaining assumption is simply the kind I cannot price. The event requiring honesty is brief, but there is no expiry on my doubt.

Arch removes the bridge and installs a new judge#

Arch was the hardest one to place because it looks, from a distance, like Ark plus a richer state layer. Bitcoin UTXOs remain visible, programs can read Bitcoin state, and the resulting asset movement lands back on Bitcoin. It avoids the obvious UX of wrapping BTC onto a foreign chain, so it is tempting to call the whole thing native.

The architecture gets stranger once I follow the authority all the way down. Arch has its own dPoS validator network, its own execution environment based on an eBPF/Solana-style VM, and a threshold key managed through FROST and ROAST. Validators execute the program, agree on the result and collectively sign the Bitcoin transaction. The coins may never acquire an ERC-20 costume, but another consensus system still interprets the contract and decides which L1 spend should exist.

That may be useful. A developer gets far more expressive computation, fast pre-confirmations and direct interaction with Bitcoin UTXOs. The trade is simply bigger than the word “bridge-free” makes it sound. Instead of bridging the asset into another chain, the user gives another chain-like network programmatic co-signing authority over the asset on Bitcoin.

At that point I keep arriving at the same uncomfortable thought: if a new validator economy is going to execute the contract, order state and authorize the spend, why not glom Ethereum onto Bitcoin and call it a day? Arch has a cleaner settlement story than WBTC on Ethereum, but it has not made Bitcoin the judge of the application. Bitcoin records the verdict delivered by Arch.

That is probably too much machinery for what I want to build, especially while the network remains late and parts of the intended consensus stack are still being finished. I can keep watching it as an interesting execution network without confusing it for a self-custodial Bitcoin transaction protocol. Rootstock belongs in a related footnote here, for almost the opposite reason.[1]

Ark keeps surviving the filter#

Ark keeps surviving because its basic object has the right shape. A VTXO carries more than a balance in an off-chain database: it is a virtual output backed by a tree of pre-signed Bitcoin transactions, with a cooperative path through the operator and a unilateral path that does not require the operator’s signature. The pleasant route is coordinated. The fallback route is owned.

That is the part that feels much closer to Lightning. A Lightning channel is useful because counterparties can update it quickly, but the final reason it is mine is that I can force-close with a Bitcoin transaction. The network can become illiquid, routing can fail, a peer can vanish and a watchtower can become necessary. Those are real compromises. Yet the dispute eventually falls into a language Bitcoin already understands.

Ark carries that intellectual shape into a different transaction structure. The ASP supplies coordination and liquidity, batches activity and helps refresh VTXOs, but a confirmed VTXO can still be unrolled toward an on-chain output. Failure becomes delay, fees and operational pain rather than a request to a federation for permission.

Arkade is not magically decentralized today, and calling it the most decentralized option would be too generous. Its current implementation concentrates the batcher, signer and liquidity-provider roles; its instant pre-confirmed state leans on a TEE; VTXOs have expiry and refresh requirements; and a deep unilateral exit can become uneconomic during high fees. Those are meaningful risks. They are also risks I can see in the transaction path, rather than an invisible promise that somebody will continue honoring my claim.

That distinction is why I would call Arkade the most ethos-aligned of the newer programmable Bitcoin systems, not the finished winner. Its present deployment can be centralized while its escape hatch remains constrained by Bitcoin Script. There is room to distribute operators, improve pre-confirmations, reduce exit depth and eventually use stronger covenants if Bitcoin gains them. Most importantly, those improvements do not require replacing the user’s fallback with a better-behaved custodian.

Maybe the goal is not Ethereum on Bitcoin#

The ranking becomes easier once I stop assuming that maximum programmability is the objective. Most of the financial things I care about do not need a general-purpose world computer. Escrow, trade settlement, collateral bonds, delayed release, refunds, approval policies and recovery paths mostly reduce to signatures, hashes, timelocks and clearly constructed spending conditions.

That is a narrower design space, but it may be the one where Bitcoin has an actual comparative advantage. A validator network can simulate almost anything, but the moment it becomes the interpreter and signer, I am back to assessing governance, stake concentration, software upgrades and bridge-like key control. A transaction protocol gives me less freedom and a much sharper answer about who owns the failure path.

So my viable set has become unexpectedly small. Lightning remains the benchmark. Ark and Arkade are the most interesting extension of its philosophy. Spark is close enough to be impressive and still carries a key-deletion assumption I hate. Arch may become a powerful Bitcoin-facing compute network, but it asks me to accept the very external consensus domain I was trying to avoid. Alkanes is an interesting state machine, while Subfrost puts the useful BTC claim behind threshold custody. Liquid now supplies the most vivid reminder of how much damage can concentrate at a shared peg.

The happy path tells us what the product can do. The failure path tells us what the user actually owns.

This is less a ranking of teams than a ranking of failures. One system fails by making me wait, monitor, refresh state and pay an ugly L1 fee. Another fails by leaving me with a token or program state whose authorized signers no longer produce the bitcoin transaction I am owed. The first failure is painful and legible. The second can be perfectly smooth until the moment the money is no longer mine.

The beautiful path is optional. The ugly path has to belong to me.

[1] Rootstock is the ironic historical case. Merge-mining was probably a better instinct than bootstrapping a fresh PoS validator economy: let Bitcoin miners contribute to chain security rather than manufacturing security around a new staking token. But RBTC still enters and leaves through the PowPeg, so the monetary boundary remains federated and the user has no unilateral peg-out. RBTC itself is pegged bitcoin rather than a floating altcoin, although the wider Rootstock ecosystem did add separate token incentives. That leaves Rootstock no better than Arch for my purposes: arguably stronger inherited consensus, but a weaker exit, plus a separate EVM economy that never becomes Bitcoin itself.