I keep coming back to the same question people keep asking in group chats and trading desks: if Liquid can produce blocks again, why can users still not pull Bitcoin off the network? The short answer is that block production and peg outs are not the same job. One keeps the sidechain moving. The other opens the vault. After the September incident, that vault is still closed on purpose.
What Actually Happened Before Peg Outs Were Frozen
On September 6, an attacker exploited a consensus weakness in Elements, the software that powers Liquid. The result was ugly and simple. Roughly 4,000 unbacked LBTC appeared, then moved through the normal withdrawal path. Federation signers released about 3,996 BTC from the reserve. That is not a rounding error. That is a real hole in a system that was supposed to keep Bitcoin locked until a valid peg out was proven.
The actors later painted themselves as white hats and sent back 3,400 BTC after patched nodes were confirmed. About 602 BTC is still in recovery mode. I do not find that framing comforting. Intent after the fact does not change the fact that the reserve was drained through a live process that should have rejected the request.
Two failures sat on top of each other: a consensus bug in Elements and a gap in how one federation member handled peg out authorization.
Liquid halted bridge nodes first. Block production came back on September 9 with a corrected chain. User transactions followed. Peg outs did not. That last piece is the one still hanging over every wallet that holds LBTC and wants native Bitcoin again.
Why Elements v23.3.4 Matters More Than The Press Release
Elements uses confidential transactions. Amounts stay hidden. Nodes still need cryptographic proofs that those amounts are valid. Rangeproofs do that work. The flaw lived in how Elements cached rangeproof verification results.
An earlier change stripped some transaction context from the cache key. That created a consensus bug. A cached pass could be reused in a different setting. A first fix closed the obvious hole. A second weakness remained in how fields were combined inside that cache key. The September attacker used that second weakness to mint an output whose value was not backed by its inputs.
Version 23.3.4 changed the construction of rangeproof and surjection proof cache keys by serializing each field with a length prefix. Different input sets should no longer collide into the same key through the method used in the attack. The hardened fix landed in the 23.3.x branch on September 8. The tagged release went out the next day.
In my view, shipping a patch is only half the story. Turning withdrawals back on without a second pair of eyes would be reckless. That is why the September 28 ecosystem update matters. An independent external audit of Elements v23.3.4 is now running. Liquid framed it as another validation layer before peg outs return. Fair enough. I would rather wait for that review than watch another unbacked withdrawal hit the reserve.
The PAK Reset Is Not A Cosmetic Change
Peg outs on Liquid are not a free-for-all. They run through Peg out Authorization Keys, or PAKs. Each entry has two parts. An offline piece is derived from a member’s Bitcoin receiving wallet. An online key signs peg out requests.
Functionary nodes use the offline component to check that the Bitcoin destination belongs to a registered entry. The private keys that control the receiving coins are supposed to stay offline. The online key lives on an Elements node because it has to sign the request that tells the federation to release Bitcoin.
The design idea is simple. If something upstream fails, coins that leave through a peg out should still sit in a cold wallet. Moving them further should take a second, slower action. That extra layer failed in September. After creating unbacked LBTC, the attacker used a federation member with a live PAK to process the withdrawal. That member received about 4,000 LBTC through its service. Signers then released nearly 3,996 BTC on the main chain.
The member later said the federation already knew the authorization key ran online and that this setup had been visible in past peg outs for years. It also said nobody told it to change the arrangement or pause peg outs before the incident. That is a messy sentence to sit with. Visibility is not the same thing as approval. Approval is not the same thing as a safe design.
Liquid’s latest update now says existing PAK entries are being replaced. The federation is also pushing to keep the relevant peg out keys in cold storage before withdrawals resume. That is the right direction. It is also the kind of work that does not finish on a marketing calendar.
So When Do Peg Outs Come Back?
Here is the honest version. Liquid has not given a date. Not a week. Not a window. The September 28 note only said the audit and the PAK changes are steps toward a safe restart, with another update expected shortly.
I know that answer feels thin if you are sitting on LBTC and watching Bitcoin move without you. It is still the only answer that matches the facts. Peg outs remain the last restricted operation. Transactions are back. Blocks are back. The bridge that releases BTC from the reserve is not.
- External audit of Elements v23.3.4 is in progress.
- Existing PAK entries are being replaced.
- Peg out receiving keys are being forced into a colder setup.
- No official restart date has been published.
If those four items look sequential, they are. The network is not going to flip a switch because social media is impatient. The reserve already lost coins once through a path that looked normal on the surface. Restarting that path without finishing the key work would be a strange definition of recovery.
How The Staged Recovery Actually Unfolded
The first move after the exploit was blunt. Bridge nodes stopped. That cut the pipe between Liquid and Bitcoin. Then functionary nodes took the patched software. Block production resumed on the corrected chain on September 9. After that, ordinary transfers came back while the federation watched the network.
That sequence makes sense if you think in layers. First you stop the bleeding. Then you restore the ledger. Then you let people move value inside the sidechain. Only after that do you reopen the door that can empty the Bitcoin reserve. Peg outs sit at the end because they are the only operation that can turn a software bug into coins leaving the federation wallet.
I’ve found that people mix up “the network is live” with “the peg is live.” Those are different products. A confidential sidechain can settle internal transfers all day and still refuse to mint a Bitcoin transaction. That is the state Liquid is in now.
| Recovery stage | Status | What it unlocks |
| Bridge halt | Done in early September | Stops new reserve withdrawals |
| Patched block production | Resumed September 9 | Corrected chain keeps moving |
| User transactions | Restored later in September | Internal Liquid activity |
| Elements audit and PAK reset | Underway as of September 28 | Preconditions for peg outs |
| Bitcoin peg outs | Still suspended | Native BTC leaving the reserve |
The Reserve Math People Keep Skipping
About 4,000 BTC left during the incident. 3,400 BTC came back after the patch confirmation. That leaves roughly 602 BTC still outside. Liquid’s later assessment treated that remainder as a recovery problem, not a closed case. A bounty demand tied to the leftover coins was rejected. The plan, as stated, is to work with law enforcement, exchanges, forensic shops, and other service providers.
Does that remaining balance delay peg outs by itself? Not necessarily. The restart condition Liquid keeps repeating is security work, not a 100 percent coin recovery. Still, a reserve that is short by hundreds of Bitcoin is not a detail you shrug off. Peg outs are a promise that LBTC can become BTC. That promise only holds if the reserve can meet valid requests.
Perhaps the most interesting part is how ordinary the withdrawal looked. The attacker did not need a novel bridge exploit after the fake coins existed. The peg out process did what it was built to do. That is why the PAK configuration and the consensus bug have to be treated as one incident, not two separate stories.
What Cold Storage Changes In Practice
Moving peg out keys into cold storage sounds tidy. In practice it means slower operations and fewer people who can sign in a hurry. That is the point. Speed is how the September withdrawal completed before anyone could interrupt it. Friction is the patch for that class of failure.
The offline wallet model only works if the receiving keys are actually offline and if the online signer cannot silently redirect coins to a hot destination. Replacing PAK entries is how you kill old assumptions. You do not keep a key that already proved it could be used in the wrong environment and hope policy language will save you next time.
I would rather see a slower peg out than a pretty dashboard that hides the same operational gap. Users who need Bitcoin on the main chain will complain. They should. They should also remember what happened the last time the path was convenient.
Confidential Transactions Made The Bug Harder To Spot
Liquid hides amounts. That is a feature for markets and treasuries that do not want every transfer printed in public. It is also a feature that makes some verification mistakes less obvious to casual observers. Nodes still check proofs. Humans watching a block explorer do not see the same raw numbers they would see on Bitcoin.
The cache collision did not need a loud, invalid-looking amount sitting in the open. It needed a verification result that could be reused. Once that happened, the output could pass checks that should have failed. Then the peg out machinery treated the resulting LBTC as real.
This is why the length-prefixed cache key is not a minor cleanup. It is an attempt to stop two different field sets from hashing into the same slot. If that sounds abstract, think of it as a filing cabinet that used to put two unrelated folders in the same drawer. The clerk then stamped both as approved.
What Users Should Do While The Bridge Stays Closed
If you hold LBTC and planned a peg out, you wait. There is no unofficial side door that is safer than the official one. Moving coins around inside Liquid can still make sense for settlement. Turning them into BTC cannot happen through the federation path until the restart is announced.
- Treat LBTC as stuck on the sidechain until Liquid says otherwise.
- Watch for the next ecosystem update, not rumor screenshots.
- Do not assume a software tag alone equals a live peg.
- Keep an eye on how new PAK entries are described, especially cold storage claims.
- Plan liquidity on Bitcoin itself if you need main-chain coins soon.
None of that is exciting. It is still better than pretending a date exists because people want one. In my experience, networks that invent dates after a reserve incident tend to walk them back. Silence plus a checklist is less elegant. It is also less likely to blow up twice.
Why Federation Design Makes Restarts Slow On Purpose
Liquid is not a single operator flipping a server. Functionaries have to run the new software. PAK lists have to be replaced across the set. Receiving keys have to be proven cold. An outside auditor has to finish looking at 23.3.4. That is a lot of people who can block a premature restart, and that is good.
A federation can look clumsy from the outside. It can also stop one rushed member from reopening a dangerous path. The September case showed what happens when one member’s authorization setup does not match the story the architecture tells. Replacing entries is how you reset that story.
I do not think “shortly” means this week. It might. It might not. The word only means Liquid expects to talk again before the work is finished. That is useful. It is not a calendar invite.
The Difference Between A Patch And A Safe Peg
A patch stops a known collision. A safe peg needs more than that. It needs keys that cannot be used from a hot box. It needs members who cannot process a giant withdrawal because a service wallet happened to be convenient. It needs an audit that is not just a rubber stamp on a tag that shipped in a hurry.
Elements v23.3.4 may be the right code. The audit is how outsiders check that claim. If the review finds another cache quirk, peg outs should stay off. If it clears the release, the PAK work still has to finish. Code and keys are separate gates. Both have to open.
Restoring blocks restores a ledger. Restoring peg outs restores a promise against a Bitcoin reserve. Those are not the same milestone.
What A Responsible Restart Should Look Like
When Liquid finally turns peg outs back on, the announcement should be boring. It should name the audited build. It should say old PAK entries are dead. It should say receiving keys sit in cold storage. It should say monitoring is in place for abnormal withdrawal size and destination patterns. If the note is only “we’re back,” that is not enough.
I would also want limits. Not because limits make a pretty chart. Because the last incident moved thousands of Bitcoin through one service path. A system that can lose that much in one pass needs tripwires. Rate limits, extra confirmations, and delayed release windows are not anti-user. They are how you keep a sidechain from becoming an ATM for the next cache bug.
Restart checklist that actually matters: Audited Elements build Replaced PAK set Cold receiving keys Withdrawal monitoring Clear public status, not a vague vibe
The Market Question Hiding Under The Technical One
LBTC is only as useful as the exit. While peg outs are frozen, the token still moves inside Liquid, but the Bitcoin peg is a one-way story with a locked door. That changes how treasuries, market makers, and ordinary holders think about inventory. Some will wait. Some will price a discount. Some will pretend nothing changed because internal transfers still clear.
The discount question is the one I keep hearing off the record. If you cannot redeem, you are holding a claim. Claims trade. They also panic. A clean restart shrinks that gap. A messy restart, or another delay after “shortly,” widens it.
This is why the next update matters more than the last one. The last update told us work is happening. The next one needs to tell us whether the audit is clean and whether the key ceremony is done. Until then, every “when” is speculation dressed up as analysis.
Lessons Sidechains Keep Learning The Hard Way
Pegs fail in two families. The first is math: proofs, caches, consensus rules. The second is operations: who can sign, where keys live, how fast coins can leave. Liquid got hit by both in one week. That combination is what made the withdrawal possible.
Other bridged systems have learned the same lesson with different logos. A perfect contract with a sloppy signer is still a hole. A perfect signer with a broken verifier is still a hole. You need both sides tight at the same time. That is not a slogan. It is the only way a reserve survives contact with an attacker who understands the stack.
I’ve sat through enough post-mortems to know the tempting line: “this was a unique bug.” Unique bugs still travel through ordinary doors. The ordinary door here was a peg out that looked valid because the ledger said the coins existed.
Reading The September 28 Update Without The Spin
Strip the ecosystem note down and you get three facts. The audit started. The PAK list is being rebuilt. Peg outs are still off. Everything else is tone. Tone is not a date.
The update also implies Liquid thinks it is closer than it was in mid-September. That is probably true. Closer is not open. If you need a single sentence for a client memo, use that one.
Will the next note include a day? Maybe. I would not build a trade around that hope. Build it around the gates. When the audit result and the new PAK set are both public, the wait is almost over. Until those two items exist in the open, the wait is the policy.
A Straight Answer For Anyone Who Skipped To The End
Liquid will restore Bitcoin peg outs after the external review of Elements v23.3.4 and after the federation finishes replacing PAK entries and locking receiving keys in cold storage. There is no published calendar. Transactions inside the network already work. The reserve door does not.
That is the whole plot. The rest is context so the plot does not sound like a shrug. If you hold LBTC, keep your plans flexible. If you write about this market, stop converting “shortly” into a Tuesday. If you operate a similar peg, look at your cache keys and your hot authorization setup before someone else does it for you.
The network is not dead. The withdrawal path is paused because the last time it ran, thousands of Bitcoin left on the back of unbacked paper. Waiting is irritating. Reopening too early would be worse. I would rather be irritated than write a second incident article with a bigger number in the headline.
