Why I'm Still Building on Liquid

On September 6, someone minted roughly 4,000 L-BTC out of thin air and pegged it out for real bitcoin. It was the biggest crypto theft of the year and it happened on the chain I've spent the last year building on. So this is a good moment to write down why I chose Liquid, whether the exploit changes that, and what I actually think about the alternatives.

Short version: it doesn't change it. Not because the hack wasn't bad. It was. It's because the reasons I picked Liquid were never "Liquid is safe." They were "Liquid is the only place I can write the kind of Bitcoin contracts I want to write, and the work survives even if Liquid doesn't."

What actually happened#

The facts, as best as they've been reported so far:

• Liquid uses confidential transactions. Amounts are hidden behind Pedersen commitments and validated by range proofs. Range proof verification is expensive, so Elements caches the results.
• Elements built the cache key by concatenating variable-length fields without length prefixes. That made it possible to construct a cache key collision: an invalid output that looked, to the cache, like a proof that had already been verified.
• The attacker spent about 14 hours planting dozens of cheap transactions to warm the cache, then at block 4,050,336 created an inflationary output that nodes accepted without re-verifying.
• The unbacked L-BTC was pegged out through SideSwap, a federation member holding a peg-out authorization key. SideSwap wasn't compromised. Neither were the functionaries. The 11-of-15 signers approved the withdrawal because, per the software they were running, the chain state was valid.
• Federation reserves dropped from about 4,205 BTC to about 197 BTC in 23 minutes.
• Hours after the drain, an OP_RETURN appeared on chain reading "we are whitehats. contact us on chain," with a promise to return the funds once every node was patched. The next day, September 7, they returned 3,400 BTC. On September 9 they demanded a 10% bounty for the remaining 598.5 BTC, or else. Blockstream refused to pay. Adam Back said the 1:1 peg will be covered regardless.

Let me be blunt about the "whitehat" label, since a lot of coverage repeated it uncritically. A whitehat reports the bug and doesn't touch the money. This person drained 95% of the reserves, kept $47 million, and is now trying to extort a bounty with the remainder. That's theft followed by ransom. It's my opinion and it's also the law. Returning most of what you stole doesn't change what you are.

• A fix had been committed publicly to the Elements repo on September 1, five days before the exploit, but no tagged release with the fix was running on functionary nodes. Elements 23.3.4 shipped September 9 with length-prefixed cache keys and an emergency switch to disable the cache entirely. Blocks resumed September 10. Peg-outs were still paused as of this writing.

So: a consensus bug in the node software, not a key compromise and not a federation failure in the trust-model sense. That distinction matters and I'll come back to it.

Why Liquid in the first place#

Bitcoin's scripting language is deliberately limited. That's a feature for a settlement layer and I'm not arguing against it. But it means two things I want are missing:

1. An expressive contract language. Bitcoin Script can't inspect the transaction that spends it in any meaningful way. You can't say "this coin may only move to an output that looks like X."
2. Covenants. Same thing from the other direction. Without introspection, you can't build vaults, rate-limited wallets, non-custodial pooled UTXOs, or an AMM whose pool the operator can't rug, all enforced at the consensus layer.

Liquid has both. Simplicity activated on Liquid mainnet on July 31, 2025 after eight years of development. It's a combinator language with no loops and no recursion, designed so that contracts can be statically analyzed and formally verified. It runs alongside Elements' existing introspection opcodes, which have been on Liquid since the Taproot upgrade there. Together that's the most expressive consensus-enforced contract environment that exists on anything pegged to bitcoin.

That's what I'm building on. The first thing I shipped was anchor, an immutable constant-product AMM where each pool is a covenant-controlled UTXO with no admin key, no upgrade path, and no off-chain coordinator. Anyone can open a pool between two Liquid assets and nobody, including me, can touch the funds outside the rules. That project is what got Jan3 interested enough to contract me for what I'm working on now, which is still private while the prototype gets built out. Same idea though: operator actions gated by covenants instead of trust, and a unilateral exit for every user.

None of this is possible on Bitcoin today. Every piece of it needs either introspection or a covenant. And Bitcoin may never get them. CTV (BIP 119) has an activation client live with a signaling window that opened March 30, 2026 and a 90% miner threshold. Miner signaling has been at zero. No major pool has committed. OP_CAT has a BIP number and no activation parameters. Meanwhile BIP-110 tried to force an unrelated change through in August with a 55% threshold, got 2.5% of blocks, and its minority chain died after two blocks. That's the current appetite for soft forks. I can hope, and I do, but I'm not going to wait.

The goal is hyperbitcoinization, not Liquid#

I want to be clear about what I'm optimizing for. I'm not trying to make Liquid win. I'm trying to build things that make bitcoin usable as the money for everything, and I need a place to do the work where the rules are enforced by consensus rather than by a company's goodwill.

Liquid is an experiment. It might disappear. Blockstream might lose interest, the federation might fragment, the peg might break in a way that can't be papered over. If that happens, what I lose is a deployment target. What I keep is:

• Working, tested contract designs for covenant-enforced pools and exits.
• The tooling I had to write to get there.
• Every lesson about what breaks when you actually try to run this stuff.

Simplicity's stated roadmap has always been Liquid first, then Bitcoin testnet, then Bitcoin mainnet once it's battle-tested. If Bitcoin ever gets covenants, in any form, the designs port. If it doesn't, they port to whatever the next Bitcoin-pegged experiment is. The code is transitory. The understanding isn't.

The alternatives, honestly#

I looked at all of these before picking Liquid and I've looked again since the hack. Here's where I land on each.

Spark#

Spark is Lightspark's statechain-based L2. It's technically interesting: users hold bitcoin off-chain in 2-of-2 arrangements with a set of operators using threshold signatures, transfers are instant, and there's a unilateral exit path if the operators go away. It launched in beta in April 2025 and has real volume now, mostly stablecoins.

Unilateral exit is good and I don't want to dismiss it. My problem is with who's building it and why. Lightspark's entire business is connecting regulated institutions to Lightning. Their UMA protocol has KYC, AML, sanctions screening, and travel rule messaging built into the payment flow. Their customers are Coinbase, Xapo, Nubank, Bakkt. They've raised at least $175 million from a16z, Paradigm, and Coatue, and they acquired Striga, a licensed European e-money platform.

That's a company whose product is the bridge between your bitcoin and your bank account, and whose investors expect returns that routing Lightning payments doesn't produce. I can't prove what they do with the data that flows through that bridge. I can say that the incentives point in exactly one direction, and that a system designed to attach identity to payment flows will do so, because that's what it's for. Tying your UTXO history to your bank account is the opposite of what I'm trying to build toward. Spark might be a fine place to move stablecoins for a business that's already fully surveilled. It's not a place to build for hyperbitcoinization.

Drivechain#

BIP 300 and 301 never got activated on Bitcoin. After years of trying, LayerTwo Labs stopped asking and hard-forked instead. The fork is called eCash, ticker ECX, and it's a separate coin airdropped 1:1 to BTC holders. Alpha launched at block 963,648 on August 23, 2026, with a permanent mainnet targeted for around October 31. Drivechains are now a feature of that coin, not of Bitcoin.

To avoid confusion: this "eCash" has nothing to do with Chaumian ecash like Cashu or Fedimint. It's a Bitcoin fork with a new name.

I don't have anything against Paul Sztorc personally and BIP 300 was a serious proposal. But once the sidechain design ships on an altcoin, it's an altcoin. The whole value of building on a Bitcoin sidechain is that the asset is bitcoin. Drivechain is out.

Rootstock, Stacks, and the EVM sidechains#

Rootstock is the fairest of these to Bitcoin. Gas is paid in rBTC, which is pegged bitcoin, and the PowPeg is a 5-of-9 federation with keys in Ledger HSMs that only sign after seeing enough cumulative proof of work. Merge-mined by a large share of Bitcoin hashrate. That's a legitimate design.

But it's an EVM chain. The contract model is Ethereum's, with Ethereum's failure modes, and the ecosystem is organized around the RIF token and whatever DeFi is fashionable this quarter. If I wanted to build on the EVM I'd build on the EVM. I don't. And its federation model is the same category as Liquid's, so it doesn't buy me anything on the trust axis either.

Stacks is worse. It has its own token, STX, that pays for transactions and secures the network. sBTC is a bitcoin-backed asset held by a signer set that's economically bonded in STX. So the security of your bitcoin depends on the price of a different coin. That's the shitcoin problem in its purest form and there's no engineering around it.

Ordinals, inscriptions, Runes, BRC-20, Alkanes#

This is the most tempting category because the asset is unambiguously bitcoin and the chain is unambiguously Bitcoin. Alkanes in particular is doing real work: WASM contracts, AMMs, and more, all riding on Bitcoin transactions.

The problem is that Bitcoin doesn't know any of it exists. Every one of these is a metaprotocol. The state lives in indexers, the rules live in an off-chain spec, and Bitcoin nodes validate none of it. If two indexers disagree, there's no consensus mechanism to resolve it. "Consensus" is whichever indexer the exchanges run. That's a shared belief about what the chain means, not something the chain enforces.

It's also crippled by L1 itself. Every operation is a full Bitcoin transaction paying full Bitcoin fees, with no confidentiality and no ability to have the base layer enforce a covenant. You get the cost of Bitcoin without the guarantees of Bitcoin.

I'm building things that have to survive a century. A protocol where the meaning of the ledger depends on an indexer's interpretation isn't a serious foundation for that, regardless of how much volume it does this year.

Taproot Assets on Lightning#

Taproot Assets is real and it's shipping. Tether's USDT is live on it as of March 2026. Multi-asset Lightning channels work. Version 0.8 is out.

But it's a Lightning Labs product, not a Lightning protocol. It runs on lnd and only lnd. The core protocol was submitted as a set of draft BIPs that remain in draft, and the Lightning integration is meant to be a bLIP, not a BOLT. There is no cross-implementation spec that Core Lightning, Eclair, or LDK have agreed to. That's not a criticism of the engineering. It's a description of the situation: one company controls the protocol, and building on it means betting on that company's roadmap for as long as your thing needs to exist.

And underneath it is Lightning, which is a hard enough foundation on its own. The original Poon-Dryja paper is 59 pages. The BOLTs have grown enormously since. Channel state, HTLCs, watchtowers, force-close games, liquidity management. Now stack a multi-asset layer with its own proof trees on top, and hold it all together across implementations that don't all support it. It's the wild west again, just with better marketing.

Ark, BitVM rollups, and the rest#

Ark deserves a mention because it's the closest thing to what I want on Bitcoin proper. Arkade and Bark are on Bitcoin mainnet, and the unilateral exit story is real. But on Bitcoin without covenants, Ark depends on the operator and the users presigning everything, and VTXOs expire on a timer, so if you don't exit or refresh in time you're relying on the operator. That's exactly the gap covenants close, and it's why the covenant-enforced version of this idea has to be built on Liquid first.

BitVM bridges are the other honest attempt at trust-minimized bitcoin on another chain. Citrea's mainnet launched in January with a BitVM2 bridge. It's early, it's complex, and the rollup is an EVM. Worth watching. Not where I'm building.

What the hack does and doesn't change#

The exploit was a bug in the node software, the same class of bug that Bitcoin itself has had. CVE-2018-17144, the inflation bug in Bitcoin Core, would have let anyone print bitcoin if it had been exploited. It was patched before that happened. Liquid wasn't so lucky. That's a difference in outcome, not in kind.

What the hack does tell me:

• Elements needs more eyes. A fix sat in a public repo for five days before functionaries were running it. That's a release process problem and it's fixable.
• Confidential transactions carry real complexity cost. Every layer of cryptography is another place for a cache key to collide.
• The federation is a real trust assumption, and the peg only survived because Blockstream can afford to make it whole. That was always true. Now it's demonstrated.

What it doesn't tell me:

• That covenants and expressive scripting are the wrong thing to build with. The contract layer was never the problem.
• That there's a better place to do this work. I just went through the list.

I'm not naive about the federation. Liquid is trusted in a way that Bitcoin is not, and I've never pretended otherwise. But the contracts I'm writing are the same contracts I'd write on Bitcoin if Bitcoin could run them. The trust in Blockstream is a deployment detail. The trust in the covenant is the product.

A side note on CTV and OP_CAT#

If you take one thing from this: the reason people build on Liquid, Stacks, Rootstock, Citrea, or Alkanes is that Bitcoin won't let them build on Bitcoin. Every one of those is a workaround for a missing primitive.

CTV is small, well-understood, and has been reviewed for six years. It gives you templated outputs: enough for vaults, congestion control, and real non-custodial batching. OP_CAT is one opcode that, combined with Schnorr, gets you general introspection. Either one would let a large fraction of the work happening on sidechains move home.

So here's the ask. Go read BIP 119 yourself. It's short, and the activation client and its parameters are public. Don't take my word for it, and don't take the word of whoever is loudest against it. If you read it and decide it's a bad idea, say why, publicly, on Nostr, X, Stacker News, Reddit, or wherever you post. That's useful. If you read it and decide it's a good idea, say that too, and then run the activation client. The signaling window is open until March 30, 2027 and needs 90% of miners. Miners follow demand they can see. Right now the only thing they can see is silence, and silence reads as no.

I'd rather be building on Bitcoin. Until that's possible, I'm building the same things on the one chain that lets me, and I'm keeping the code portable for the day it is.