3,400 BTC Returned To The Liquid Network

Liquid Network Follow-Up: 3,400 BTC Returned, But the Math on Recovering the Rest Doesn’t Work.

It’s been a wild 24 hours in the Bitcoin space, while the main chain remains unaffected.

Tick tick, next block!

While Bitcoin’s price hasn’t moved dramatically, the Liquid side chain has been decimated and, ironically, has had more eyes on it than ever before because the base asset, L-BTC, is unbacked after a hack.

The self-described white hats behind Liquid Network’s $320 million exploit have made good on part of their word. Of the roughly 4000 BTC drained from the federation’s reserve, 3,400 BTC has now been sent back to Blockstream’s peg address, leaving the attacker holding 598.5 BTC — an amount that looks suspiciously like a self-assigned “bug bounty” rather than a number that emerged from any negotiated agreement.

With the reserve partially restored, the network is now sitting at approximately 85.552% backed, meaning roughly 598.5 BTC in circulating L-BTC still has no real Bitcoin behind it.

What About the Other “598.5 BTC”?

Framing an unreturned balance as a bounty is a familiar move in these kinds of incidents. Legitimate white hat bounty programs typically pay out somewhere in the 5–10% range of recovered value for a critical vulnerability disclosure, occasionally higher for catastrophic bugs.

While most of the funds were returned, a 15% security audit fee is a hefty price to pay.

That’s a meaningfully different situation from a white hat returning funds and waiting for the protocol to determine and pay a bounty through its own process — here, the “fee” was taken first, with the return framed after the fact as generosity rather than negotiated settlement.

Could Transaction Fees Realistically Cover the Shortfall?

One question worth answering with actual numbers: if the missing 598.5 BTC were never returned, could Liquid simply earn its way back to full backing through ordinary transaction fee revenue?

Using Liquid, typical fees are cheap; while this is great for users, it’s not great for generating revenue, since the volume simply isn’t there. If we average around 25 satoshis per transaction, the math is worth running.

Hacker’s wallet: https://mempool.space/address/bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte

598.5 BTC is equal to 59,850,000,000 satoshis. At 25 satoshis per transaction, fully recouping that amount through fee revenue alone would require approximately 2.394 billion transactions.

For context on how large that number actually is: Liquid’s entire network processed 1,163,119 transactions across the whole first quarter of 2026, a period the network itself flagged as a five-fold year-over-year growth milestone.

December 2025 set the network’s single-month record at 242,000 transactions.

Putting those two numbers side by side is not a flattering comparison.

If we use this as a baseline, the rough estimate of how long it would take to recoup 598.5 BTC purely through fee revenue at various levels of network activity, including Liquid’s actual recent volume and a series of increasingly optimistic hypothetical growth scenarios.

Even if Liquid’s transaction volume grew, which is unlikely given the state of the network, it would still take years. Even at a hundredfold from its current pace—a scale of adoption that would represent an entirely different network than the one that exists today—recouping the shortfall through fees alone would still take roughly five years.

At anything resembling Liquid’s actual, real-world growth trajectory, the number stretches into centuries even if fees are increased. It’s also worth noting this exercise is somewhat artificial to begin with: Liquid’s transaction fees are paid to compensate block-signing functionaries for network operation, not collected into any kind of treasury fund designed to backstop reserve shortfalls.

No existing mechanism would automatically route fee revenue toward repairing the peg, even if the maths worked out favourably. The fee revenue was never a plausible route to making the reserve whole, and framing any part of this shortfall as something the network will simply “earn back” over time doesn’t hold up against the actual numbers.

Speculating on Other Paths to Recovery

If fees can’t close the gap, a handful of more plausible paths remain—some with real precedent elsewhere in crypto’s history of handling shortfalls.

A federation-funded top-up.

The most straightforward option is this:

If it were financially feasible, it’s not as if companies have 500 BTC just lying around. This could be done by raising funds through selling equity or issuing debt to acquire the funds, secure the Bitcoin, and pay down the debt over time.

Blockstream and the rest of the federation members could collectively inject fresh BTC into the reserve to restore full backing, treating the shortfall as a shared operational loss rather than waiting on the attacker’s goodwill.

This mirrors how Bitfinex handled its 2016 hack, where losses were initially socialised across all users before the company gradually repaid the shortfall from company revenue over the following years.

Given the federation is made up of established exchanges and institutions with balance sheets, a coordinated capital injection — even a partial one spread proportionally across members — is a possible path but not a probable one to restoring the peg without depending on the hacker at all.

Continued negotiation for a fuller return

The 3,400 BTC returned so far suggests the attacker is engaging in good faith to some degree, or at least is sensitive to public pressure and reputational framing.

Continued public and direct negotiation — potentially including a legitimately agreed bounty rather than a self-assigned one — could still recover some or all of the remaining 598.5 BTC, particularly if Blockstream is willing to formalise a bounty figure the attacker finds acceptable in exchange for a full return and a technical write-up of the exploit.

A market-priced discount absorbing the gap organically

The other option is for L-BTC to trade at a floating rate, like a 15% discount.

Rather than formally restoring the peg to 100%, the market could simply price L-BTC at a discount reflecting the 85.552% backing ratio until reserves are topped up through other means.

In this scenario, arbitrageurs buying discounted L-BTC now, betting on eventual full restoration, effectively “recoup” the gap through their own risk-taking rather than the network doing so directly — though this shifts the loss onto whoever holds L-BTC in the interim rather than genuinely fixing the shortfall.

Legal action

If the hacker does leave traces back to themselves, and doesn’t play ball, given the exploit involved deliberately engineered transactions rather than a passively discovered bug, the federation members retain the option to pursue this through law enforcement and civil channels regardless of the “white hat” framing, particularly if negotiations stall or the attacker’s returns fall well short of the full amount.

None of these options is mutually exclusive, and the likeliest outcome is probably some combination: continued pressure and negotiation squeezing out a further partial return, alongside a federation-funded top-up covering whatever gap remains once the attacker’s goodwill runs out.

But ultimately, we’re all just speculating on Twitter and nostr while watching the Liquid Network block explorer.

While the court system is an option, if the hacker is found, these proceedings can take years to work through, and by then those funds could have been lost, transferred, or spent, with a partial or no recovery being the final outcome.

What Covenants Could Have Done Differently

Both this incident and the earlier Coldcard RNG vulnerability share something worth dwelling on: in each case, the real moment of loss wasn’t just the underlying bug — it was that once exploited, the attacker had completely unrestricted freedom to move funds to an address of their own choosing, instantly and irreversibly. Covenants — a category of Bitcoin script opcodes that restrict how a UTXO can be spent in the future, rather than simply who is authorised to spend it — are specifically designed to close that exact gap, and both incidents illustrate distinct, practical use cases for them.

Use Case 1: Vaults as a Coldcard-Style Failsafe

The Coldcard bug meant a subset of previously generated private keys were weaker than they should have been, and potentially derivable by an attacker with enough compute and a sufficiently narrowed entropy space. In a conventional wallet, once an attacker holds that private key, they can construct a valid signature and move funds to any address instantly — game over, no recourse.

A vault covenant — constructions like OP_VAULT, or vault designs built on OP_CHECKTEMPLATEVERIFY (BIP 119) — changes that dynamic entirely. Rather than a private key granting direct, unrestricted spending authority, a vaulted UTXO can only be spent into a pre-committed “unvaulting” transaction, itself subject to a mandatory time delay, commonly somewhere between a few hours and several days, before funds can actually reach their final destination.

Critically, a separate clawback path, controlled by a different key kept in a more secure, less frequently used location, can redirect the funds to a recovery address at any point during that delay window, invalidating the thief’s withdrawal entirely.

Applied to the Coldcard scenario: even if an attacker successfully derived a weak private key and broadcast a withdrawal, a vaulted wallet wouldn’t hand over the funds immediately.

The legitimate owner, noticing the unexpected unvaulting transaction, would have a window — hours or days — to trigger the clawback and move funds to safety before the thief’s transaction could finalise.

A stolen key becomes far less useful to an attacker because possession alone no longer guarantees they get to keep what they steal.

Use Case 2: Destination Allowlisting for Federation Reserves

Liquid’s exploit worked differently — the attacker didn’t steal a key at all; they tricked the federation’s own validation logic into treating a fraudulent transaction as legitimate, and the honest, uncompromised signing infrastructure then authorised a real BTC withdrawal on their behalf. A covenant enforcing destination allowlisting could have acted as an entirely independent second line of defence here, regardless of whether the underlying range-proof and cache-key bug existed at all.

In this design, the federation’s mainchain reserve UTXO wouldn’t just be secured by an 11-of-15 multisig — it would additionally be covenant-restricted so that any peg-out could only ever move funds to a small, pre-approved set of destinations, such as back into the federation’s own reserve structure, or to addresses registered and reviewed in advance as legitimate peg-out recipients.

An attacker exploiting a consensus bug to mint fraudulent L-BTC and request a peg-out could still trick the internal accounting into believing the withdrawal was valid, but a covenant on top of the reserve UTXO would refuse to release funds to an arbitrary, previously unseen address like the one used in this exploit.

The underlying bug could still exist, but its blast radius would be contained: fraudulent mints wouldn’t translate into fraudulent withdrawals reaching addresses outside the federation’s control.

Why These Incidents Matter for Covenant Development

Neither OP_VAULT nor OP_CTV is live on Bitcoin’s mainnet today — both remain proposals, tested primarily on sidechains, signets, or in research contexts, with years of ongoing debate over which specific covenant design Bitcoin should ultimately adopt, if any. OP_CHECKTEMPLATEVERIFY is formally specified in BIP 119 (bitcoin/bips, BIP 0119), authored by Jeremy Rubin, and constrains a transaction’s future spend to a pre-committed template hash rather than an arbitrary output.

OP_VAULT was proposed by James O’Beirne and Greg Sanders in a January 2023 bitcoin-dev mailing list post and accompanying draft specification, building on CTV-style template commitments to add the delayed-withdrawal-plus-clawback structure described above.

Ironically, Liquid’s own Elements codebase already supports more expressive scripting than Bitcoin mainnet, including OP_CAT, one of the building blocks several covenant designs rely on — yet this exploit occurred at the validation layer, beneath where any covenant would even apply, a useful reminder that covenants are a complement to careful protocol engineering, not a replacement for it.

Still, two high-profile, high-value incidents within weeks of each other — one exposing what happens when a stolen key grants instant, irreversible spending authority, and the other exposing what happens when a reserve has no independent check on withdrawal destinations — are exactly the kind of concrete, dollar-denominated case studies that tend to accelerate stalled protocol conversations.

It wouldn’t be surprising if both incidents get cited repeatedly over the coming months by developers pushing for renewed momentum behind getting a covenant opcode — whether OP_CTV, OP_VAULT, or some successor design — through Bitcoin Core’s slow, consensus-driven soft fork process.