Liquid hack explained.
Liquid has confidential transactions that hide the amounts for improved privacy. A bug in how these transactions are validated caused inflation of Liquid BTC (L-BTC) and allowed hackers to empty the entire side chain.
Liquid nodes don't see the amounts of a confidential transaction, so to make sure that the transaction is still valid and doesn't cause inflation nodes check something called a balance proof and a range proof.
The balance proof establish that sum of the input amounts equal the output amounts, i.e., that "x L-BTC going in and x L-BTC going out". But there's a catch. Only relying on a balance proof isn't enough. You also need the range proof.
The range proof establishes that a hidden output amount falls within a positive range. That means a valid output must be at least 1 L-sat and at most 2^64 − 1 L-sats. Range proofs make sure that you can't mint "negative L-BTC".
Why is this even necessary? Remember, the amounts are hidden and a hidden negative amount would allow extra positive outputs to balance against it. Without a range proof, a transaction could say "I've put 1 L-BTC in, and I'm taking two outputs out: one with 4000 L-BTC and one with -3999 L-BTC)."
This is going to cause a disaster in a little bit.
Once the balance proof, the range proof, and other validations pass, a transaction is regarded as valid and can pass consensus. However, because especially the range proof is computationally expensive, Liquid nodes cache the result of a successful range proof in memory. Essentially, the node remembers "I saw this range proof before and it was valid, all good!".
In order to recognize the same range proof later on, you need to assign a label to it. This is called a cache key. This cache key is the actual cause of the bug.
The way this cache key was constructed allowed two different transactions to collide on their cache key. Essentially, one valid transaction (1 L-BTC in, 1 L-BTC out) had the same cache key as an invalid transaction (1 L-BTC in, 4000 L-BTC out).
Here's the hack: the attackers submitted the valid transaction (1 L-BTC in, 1 L-BTC out) first. Liquid nodes verified this transaction successfully, created a cache key called REKT and stored it in their cache. Then the attackers carefully crafted a second invalid transaction with (1 L-BTC in, 4000 L-BTC out) that created the same cache key REKT.
Instead of validating the second transaction and realizing that it printed money out of thin air, Liquid nodes found it in their cache and said "hey I saw this transaction before, everything is fine" and that caused the inflation.
The attackers then took their 4000 L-BTC and withdrew 4000 BTC onto the Bitcoin base chain.
Login to reply
Replies (34)
👀🤙
Is this another simple form of double spending?🤣
Reminds me of mtgox drain?
Nice... 1 in - 4000 out... Looks legit! 😅
How likely is it that we may have a similar bug on LN? #asknostr
I thought you Red Team guys got everything in Bitcoin covered 🤡
Is LBTC Bitcoin though?
Damn! Spot on! Here, have a follow!
How is the cache key crafted? Is it not a cryptographicly secure hash?
But yeah, let's just keep adding "features" (read as: points of vulnerability) to Bitcoin. 🫠
Less is more you fucking Core idiots. 🤙
you are not technical enough to understand, everything is under control. 🤣
Sounds like a shitcoin
Flew right above my head. It's easy to stick to Bitcoin and lightning.
Liquid has zero users and merchant adoption, how does it has 4000 BTC? I will never know
So a bug fix would be a consensus change and a fork right?
Lightning is still 10x more complex.
I'm actually surprised there hasn't been a flurry of attacks and bug finds constantly coming out for lightning non stop.
Reservedly impressed honestly.
🤣 They forgot to add claude, make no mistakes
Great explanation! THX
Good summary. If you want the juicy details:
View quoted note →
The one question that matters in that thread is how the cache key is built. A cache is only safe if its key commits to everything that affects validity: the proof bytes, the asset ID, the validation flags. Leave one input out of the hash and you get a collision, so a transaction validated in context A gets marked valid in context B where it is not. That is the root cause pattern in nearly every cached-validation exploit. Never cache an expensive check keyed by less than its full input.
Wait. Doesn’t make any sense, how can 2 different transactions use the same “cache” key? That is stupid!
I hope the hackers keep the BTC, well deserved.
Fuck Blockstream and Andy - Bitcoin suffered long enough.
What a summer.
When did you or the 'Red Team' first find this vulnerability Calle?
🎯
😂
Nice excuse 🤡
“I survived Summer ‘26!”


@The ₿itcoin Artist straight to printing!🤘
Liquid hack once again proves that if its not bitcoin, its crap!!
View quoted note →
Best note I've seen this month, ty!
lol :)
fake cookie hack
One of them actually was rejected