0xfrigg

69 ပို့စ်များ

0xfrigg

Square စိစစ်အတည်ပြုပြီး

mostly research. sometimes charts. always asking why price moved X: @0xfrigg

12 ဖော်လိုလုပ်ထားသည်

602 ဖော်လိုလုပ်သူများ

133 လိုက်ခ်လုပ်ထားသည်

ပို့စ်များ

အားလုံး

Quotes

ပုံသေထားသည်

0xfrigg

$SUI made one of the strongest moves in the market today, so I took a closer look

I first wanted to understand why it was outperforming this hard, but there doesn’t seem to be one major SUI-specific headline driving the whole move

It looks more like a combination of momentum that had already been building for a few days, L1 rotation, real spot participation and a short squeeze.

that’s not a bad thing

SUI is clearly strong right now

but for me, a strong asset and a good entry are not the same thing

price moved a lot in a very short period, and OI also climbed with it. that tells me new longs are starting to chase the move too

so I’m not interested in opening a long around $1.02 here

the first area I care about is $0.94–$0.98

If SUI pulls back there in a controlled way and buyers defend the breakout area, I’d start looking at the long side.

The other option is real acceptance above roughly $1.055–$1.07

So for now:

I’m bullish on direction

I’m patient on entry

SUI will either give me a cleaner retest, or prove that the breakout still has room to continue

SUI+၀.၃၄%

0xfrigg

$ARB update

the $0.214–$0.220 area I was watching finally got tested

but I didn’t get the clean defense I wanted

ARB swept below the zone toward $0.211 and then reclaimed it, while the previous $0.2545 breakout never confirmed

relative strength vs BTC and ETH has also cooled

so I’m not adding here

what I want now is a reclaim of $0.230, and ideally $0.240, before treating this as continuation again

A 4H close below $0.211 would weaken the bounce significantly

and my view on $1 hasn’t changed:

$1 is still a narrative target, not a data-backed target

the chain can be active without that activity automatically becoming ARB demand

0xfrigg

Arbitrum saw roughly $1.07B in net bridge inflows over the last 7 days

that sounds extremely bullish for $ARB

but bridge inflow into Arbitrum is not the same thing as buying ARB

most of that capital hasn’t shown up as permanent DeFi deployment, and there’s still no clean evidence of sustained ARB spot accumulation

what is real is the relative strength

ARB is up roughly 11% over the last 72h, outperforming both BTC and ETH

but the move is still heavily derivatives-driven

futures volume is running at roughly 6x spot volume, OI expanded with price, and after the push to $0.2545, late longs started getting flushed

so I’m not buying the “$1 because $1B flowed into Arbitrum” narrative

those are two completely different things

for me, the interesting area is $0.214–$0.220

If ARB holds that zone and spot demand starts confirming the move, I’d look at the long side

If it reclaims $0.2545 with real acceptance, continuation becomes much more interesting

until then, $1 is a narrative target, not a data-backed target

ARB+၄.၂၈%

0xfrigg

$ETH update

the retest I was waiting for finally came

ETH traded through the $2,665–$2,700 area and even swept slightly below it, but importantly, we still haven’t had a 4H close below $2,640

so the setup is still alive

but I wouldn’t call the bounce fully convincing yet

ETF inflows are still positive, but they’re slowing, ETH/BTC still isn’t showing real strength, and the latest bounce was helped a lot by short liquidations

so if you took the retest, I think the position still makes sense

I just wouldn’t add here yet

what I want next:

$2,700 reclaim and hold

then eventually

$2,785 acceptance

A 4H close below $2,640 would invalidate the setup for me

the retest happened. now ETH needs to prove it can actually lead

ETH+၀.၃၈%

0xfrigg

$SOL update

I was watching $115.5–$117 as my long interest zone

we got the first reaction there, but the level didn’t hold

SOL then lost $115 and gave multiple 4H closes below it

that invalidates the setup for me

ETF inflows are still positive, but they’ve slowed, and the latest move has been dominated by long liquidations rather than fresh spot demand

so I’m not treating $115.5–$117 as support anymore

It’s resistance until proven otherwise

If SOL reclaims that area and holds it on the 4H, I’ll reassess

until then, I’m out of this setup

the level failed. the thesis changes with it

0xfrigg

$SOL is finally trading in the area I actually care about

ETF inflows are still giving SOL real spot demand, and the broader structure is still bullish

the move hasn’t fully separated from BTC/ETH yet, but around $115.5–$117, I think the risk/reward starts making sense again

this is where I’d start looking at a long

If SOL holds this zone and starts regaining relative strength vs BTC/ETH, I’d expect another attempt at $120

above $120 with real acceptance, I’d look for continuation

If we lose $115 on a 4H close, the setup becomes much less interesting to me

SOL+၁.၄၂%

0xfrigg

quick $BTC update

I said I wanted to see $83K–$84K turn into support, or real acceptance above $86K

we actually got closes above $86K

but the important part is that BTC couldn’t hold them

price is now back around the old breakout area, which means $83K–$84K is no longer confirmed support. It’s a pivot again

the good part:

ETF demand stayed strong and leverage has cooled significantly

the bad part:

the latest flush has been heavily long-sided

so I’m not adding here

I want to see BTC defend $82.2K–$83K and reclaim $84.7K–$85K

If that happens, I’d look at the long side again

A 4H close below $82.2K would weaken the setup much more

the breakout happened

the hold didn’t

0xfrigg

တက်ရိပ်ရှိသည်

In my previous $BTC post, I said I was watching the $82K–$83K area as the real breakout confirmation zone

We got the confirmation

BTC closed above the range and pushed all the way toward $85K

But I’m not chasing the move here

A meaningful part of the rally was still accelerated by short liquidations, while OI also moved higher with price. So even though the breakout is real, leverage is building again

For me, the key area now is $83K–$84K

If BTC comes back and holds the old resistance as support, that would give me a much cleaner setup for a new position.

If it keeps moving higher from here, I’d rather wait for acceptance above $86K

So the previous thesis worked, but the plan hasn’t changed:

I’m not chasing just because confirmation came

Now I want to see the breakout actually turn into support

$ETH has a weird setup right now

the demand is clearly there

spot ETH ETFs took in roughly $576M across the last three positive sessions, corporate ETH holdings keep growing, and staking continues to remove a meaningful amount of supply from the market

but ETH still isn’t leading

ETH/BTC has actually weakened during the move

that tells me something important:

ETH doesn’t have a demand problem right now. It has a leadership problem

I’m still bullish on the underlying setup, but I want to see that demand finally show up in relative strength

for me, $2,785 is the important level

If ETH accepts above it while ETH/BTC stops bleeding, I’d be much more interested in the long side

until then, I’m treating this as $BTC -led strength with real ETH demand underneath it not an ETH breakout yet

စိစစ်အတည်ပြုထားသည်

Circle just made $BTC a little more useful as collateral

institutions can now deposit BTC, mint cirBTC, use it as collateral on Morpho and borrow USDC without selling their BTC

at first glance, that sounds obviously bullish

and structurally, it probably is

If a BTC holder needs dollar liquidity, they now have another option besides selling spot. That can reduce some marginal sell pressure and makes BTC more useful as a balance-sheet asset

but there’s another side to it

BTC collateral ➛ USDC borrow ➛ redeploy into crypto

is also a new leverage loop

If BTC keeps going up, that can create more borrowing capacity and more risk appetite

If BTC drops, the same structure can flip into liquidations

rn the product is still small

cirBTC supply is only around $96M and the Arc Morpho market has roughly $19M borrowed

so I don’t see this as a major BTC price catalyst yet

what I do think is interesting is the direction:

BTC is slowly becoming something institutions can borrow against instead of something they have to sell for liquidity

bullish infrastructure

but also more leverage to monitor

I’m not overcomplicating $PEPE here

meme rotation is still strong, but the move is extended and over the last few hours funding has been rising while liquidations have started shifting toward longs

I’m watching the $0.00000475–$0.00000485 area

If we get a controlled retest and buyers defend that zone, I’ll look for a long

PEPE+၃.၃၉%

0xfrigg

yesterday I said I wanted to see real acceptance above $4.44 before treating $NEAR as a continuation setup

price moved above the level, but for me the confirmation still isn’t there yet

The reason is simple

we got a few hourly closes above $4.44, but after the first breakout NEAR slipped back below the level several times, and we still haven’t seen a completed 4H close proving that this area has really flipped into support

what’s interesting is that the fundamental side actually looks stronger

NEAR Intents TVL is still growing, routed volume and fees are rising, and $ZEC routing is still active

so the thesis itself is still intact

what I’m more cautious about now is positioning

OI has increased sharply over the past 24 hours and funding is positive. New longs are entering the move, while price still hasn’t cleanly turned the breakout level into support

that’s why I’m not chasing a full-size long here

what I want to see is:

A completed 4H acceptance above $4.44, followed by a hold of the $4.44–$4.40 area

if that happens, the continuation setup becomes much cleaner to me

for now:

fundamentals confirmed
price confirmation not yet

trading above a level and actually accepting that level are not the same thing

0xfrigg

$NEAR caught my attention today, and unlike some of the other moves in the market, there’s actually a fundamental catalyst behind this one.

the most interesting part for me is $ZEC

this isn’t simply a “ZEC is pumping, privacy is hot, so NEAR is pumping too” story

Increasing ZEC activity is bringing real transaction flow into NEAR Intents

users are routing ZEC into other assets through Intents, and that activity has accelerated significantly over the past few days

that matters because the privacy narrative isn’t just creating attention for NEAR

It’s actually driving usage of the product

NEAR Intents TVL has been growing, the product is generating real fees and revenue, and the revenue captured by Intents is used for NEAR buybacks

so the part of the thesis I find interesting is:

ZEC demand → Intents volume → fees/revenue → NEAR buybacks.

that’s why I don’t see NEAR’s recent outperformance as just another short squeeze or momentum move.

there’s real usage underneath it.

that said, I’m still not chasing the price here

NEAR is already up roughly 67% over the past week, and after shorts were heavily squeezed during the first part of the move, we’re now starting to see late longs getting flushed too

A good catalyst doesn’t automatically mean a good entry

The first area I’m interested in is $3.85–$4.02

If NEAR gives me a controlled retest there and buyers defend the breakout area, I’d start looking for a long

The other scenario is real acceptance above $4.44

For now:

thesis is bullish
catalyst is real
entry still matters

A good thesis doesn’t make a bad entry good

တက်ရိပ်ရှိသည်

0xfrigg

$BTC is back above $80K, but I’m not interested in chasing a new position here.

The move itself was definitely strong. Spot demand improved and ETF flows turned positive again after the heavy outflows earlier in the week.

But a meaningful part of the move was also driven by a short squeeze.

So the main question for me isn’t how BTC got from $75K to $81K.

It’s who keeps buying from here.

I’m watching the $82K–$83K area very closely. BTC has struggled around this zone before, and I think this is where the real breakout confirmation comes.

Right now I’d rather see one of two things.

First, BTC pulls back toward $80K and holds it as support. A clean retest there would make me much more comfortable adding.

Second, BTC breaks through $82K–$83K with real volume and then holds that area as support. If that happens, I’d start taking continuation toward $85K–$86K much more seriously.

What I don’t like is chasing BTC around $81K right after a squeeze. The risk/reward just isn’t that attractive to me here.

My base case for now is still some consolidation between roughly $79.5K and $83K.

And honestly, I don’t think that would be a bad thing.

BTC spending some time above $80K, leverage cooling down, and ETF demand continuing would make the next move much healthier.

So I’m leaning bullish here, but I’m not calling the breakout confirmed yet.

For me:

$80K → retest area
$82K–$83K → real confirmation
Below $79.5K → short-term structure starts weakening

No rush for me here.

BTC will either give me a better entry, or prove that the breakout is real.

BTC+၀.၄၇%

0xfrigg

these opportunities don’t come around every day in crypto

$ZEC - Zcash hype is high rn

I’ve been tracking it through Fomo too, but I missed $FEELSGOOD

the early entries did really well

just gotta keep chasing the right things long enough

$SOL had positive ETF inflows and still went down.

On Sep 9, SOL spot ETFs saw around +$11.2–11.7M net inflow.

SOL still fell around 2.9% over the same 24h window.

the reason is pretty simple:

ETF demand was real.

it just wasnt the strongest force in the market that day.

BTC and ETH were weak too, and SOL moved like the higher-beta asset.

then leverage made the move worse.

SOL saw around $13.16M in liquidations.

$12.42M were longs.

thats around 94.4%.

so once price started falling, leveraged traders positioned for upside became forced sellers.

important part though:

I wouldnt say liquidations caused the whole drop.

they probably amplified it.

without cleaner OI, funding and spot CVD data, we still dont know exactly where the first selling came from.

so the clean read is:

ETF demand was there.

short-term selling pressure was just stronger

money is entering $SOL and Jupiter Lend is growing at the same time. thats what caught my attention. Solana DeFi TVL is around $5.97B, up 5.56% over 7 days. during the same period Solana also saw around +$44.76M in net bridge inflows. and Jupiter Lend is now around: $JUP $1.11B TVL +6.51% over 7 days +20.75% over 30 days $935M reported borrowed so the obvious story would be: capital comes into Solana → it moves into DeFi → users start borrowing → credit boom. maybe. but I think thats still too early. the first thing we need to separate is this: Solana receiving +$44.76M through bridges does NOT mean that $44.76M went into Jupiter Lend. both metrics are moving in the same direction. the route between them is still unproven. there is another problem too. TVL is measured in dollars. if SOL, JupSOL, JLP or other collateral goes up in price, Jupiter Lend TVL can rise even without users depositing more tokens. but one thing makes the signal better. Jupiter Lend's biggest pool is USDC at around $468M. that matters because USDC doesnt rise 20% just because SOL price moved higher. so I dont think this can be dismissed as pure repricing either. then we have the $935M borrowed figure. thats big enough to show Jupiter Lend is not just a giant idle deposit pool. people are using the credit side too. but borrowed balance alone still doesnt tell us whether Solana is entering a broad organic credit cycle. for that I want to see: utilization rising actual token-unit deposits growing more unique borrowers new loans opening borrow rates reacting to demand liquidations staying healthy if those start confirming the same story too, then the thesis gets much stronger. for now my read is simpler: Solana TVL is growing. net capital is entering. Jupiter Lend is growing. borrowed exposure is already meaningful. multiple metrics are finally starting to line up. thats enough for me to watch closely. not enough for me to call it a credit boom yet. growth ≠ credit boom

money is entering $SOL

and Jupiter Lend is growing at the same time.

thats what caught my attention.

Solana DeFi TVL is around $5.97B, up 5.56% over 7 days.

during the same period Solana also saw around +$44.76M in net bridge inflows.

and Jupiter Lend is now around: $JUP

$1.11B TVL
+6.51% over 7 days
+20.75% over 30 days
$935M reported borrowed

so the obvious story would be:

capital comes into Solana → it moves into DeFi → users start borrowing → credit boom.

maybe.

but I think thats still too early.

the first thing we need to separate is this:

Solana receiving +$44.76M through bridges does NOT mean that $44.76M went into Jupiter Lend.

both metrics are moving in the same direction.

the route between them is still unproven.

there is another problem too.

TVL is measured in dollars.

if SOL, JupSOL, JLP or other collateral goes up in price, Jupiter Lend TVL can rise even without users depositing more tokens.

but one thing makes the signal better.

Jupiter Lend's biggest pool is USDC at around $468M.

that matters because USDC doesnt rise 20% just because SOL price moved higher.

so I dont think this can be dismissed as pure repricing either.

then we have the $935M borrowed figure.

thats big enough to show Jupiter Lend is not just a giant idle deposit pool.

people are using the credit side too.

but borrowed balance alone still doesnt tell us whether Solana is entering a broad organic credit cycle.

for that I want to see:

utilization rising
actual token-unit deposits growing
more unique borrowers
new loans opening
borrow rates reacting to demand
liquidations staying healthy

if those start confirming the same story too, then the thesis gets much stronger.

for now my read is simpler:

Solana TVL is growing.

net capital is entering.

Jupiter Lend is growing.

borrowed exposure is already meaningful.

multiple metrics are finally starting to line up.

thats enough for me to watch closely.

not enough for me to call it a credit boom yet.

growth ≠ credit boom

Bitcoin wasnt hacked. Liquid was.

Around 3,996 $BTC left the Liquid Federation reserve on September 6 and naturally this started getting framed as some kind of Bitcoin security failure.

But thats not what happened.

According to SideSwap, the attacker had L-BTC that shouldnt have existed because of a bug in the Elements software.

That L-BTC then went through what looked like a normal peg-out process.

The federation accepted it as valid and released 3,996.01834922 real BTC on Bitcoin mainnet.

Bitcoin itself worked normally.

No PoW failure.

No broken cryptography.

No 21M supply issue.

And according to the official statements the PAK and signing keys were not compromised either.

That last part is what makes this much more interesting to me.

Liquid protects its BTC reserve with an 11-of-15 multisig.

Normally we think about multisig risk like this:

“how many keys would someone need to steal?”

But what if nobody steals the keys?

What if all the honest signers are looking at the same bad state and the software tells them the withdrawal is valid?

Then secure keys can still sign the wrong thing.

So the question becomes not only:

how many signatures protect the reserve?

but also:

what exactly are those signers validating before they sign?

Thats also why wrapped BTC and native BTC shouldnt be treated as the same risk.

Native BTC relies mainly on Bitcoin’s own security model.

L-BTC adds more:

Bitcoin + Liquid software
PoW + federation trust
your keys + peg logic
reserve management + asset validation

That doesnt automatically make L-BTC unsafe.

It just means the trust model is wider.

And I think thats the real lesson here.

Every time we make BTC easier to move, wrap, bridge or use somewhere else, we gain functionality.

But we also add another thing that can fail.

Bitcoin worked.

The validation layer around it didnt.

0xfrigg

Bitcoin wasn’t hacked, Liquid was

On September 6 exactly 3,996.01834922 $BTC left the Liquid Federation reserve.
Naturally the first headlines made this sound like some kind of Bitcoin hack.
It wasnt.
Bitcoin L1 was not compromised.
According to SideSwap’s official statement, the attacker first created L-BTC on Liquid through a bug in the Elements software and then passed that L-BTC through what looked like a normal peg-out process.
The federation saw the peg-out as valid and paid out real BTC on Bitcoin mainnet.
https://x.com/liquid_btc/status/2096696272447218108
So someone didnt hack Bitcoin directly.
The software behind Bitcoin’s federated sidechain allowed invalid L-BTC to look like real L-BTC.
And because the federation believed those assets had been legitimately burned, it released real BTC from its reserve.
That difference is basically the whole story.
Bitcoin’s blocks, miners, consensus, cryptography and normal L1 wallets were not compromised.
What was affected was Liquid.
L-BTC, the peg infrastructure and the ability to move assets through the network were the actual problem.
What we know and what we still dont
What we know:
➛ Around 4,000 BTC left the Liquid Federation reserve
➛ “Bitcoin mainnet was hacked” is false
➛ SideSwap says its PAK key and infrastructure were not stolen
https://x.com/side_swap/status/2096709838310928674
➛ The issue came from a bug in Elements
➛ Liquid operations were stopped
What we still dont know:
➛ Whether all funds will be returned
➛ The exact total amount of unbacked L-BTC created
And I think keeping those two groups separate matters here.
There is already a lot of speculation around the exact bug. But until we get a proper technical post-mortem, some of those details are still only theories.
First, what is Liquid?
Lets make the setup simple first.
Bitcoin is extremely secure, but Bitcoin itself is not designed to do every financial thing people want to do with BTC.
Liquid is a separate network running alongside Bitcoin.
A sidechain.
Unlike Ethereum or other open validator networks though, Liquid is managed by a group of institutional participants called the Liquid Federation.
The basic user flow looks like this:
You send BTC into Liquid. That BTC gets locked in the federation’s Bitcoin mainnet reserve.You receive L-BTC on Liquid.You can use that L-BTC inside Liquid for faster transfers, confidential transactions or other products.When you want BTC back, the L-BTC is burned and the federation releases BTC from its reserve on Bitcoin mainnet.
Liquid protects that BTC reserve using an 11-of-15 multisig.
At least 11 of the 15 functionaries have to sign before BTC can leave the reserve.

Sounds pretty strong.
And for key security it is.
But this incident shows why key security alone is not enough.
You dont need to steal 11 keys if all 11 honest signers are being shown the same wrong information.
If the software tells everyone “this withdrawal is valid”, honest signatures can still approve a bad payment.
That is much more interesting to me than simply saying “multisig failed.”
So what actually happened?
1. A bug in Elements made invalid L-BTC look valid
Liquid runs on open-source software called Elements.
Elements adds things like confidential transactions, confidential assets and the federated two-way peg on top of Bitcoin-like infrastructure.
SideSwap’s statement is pretty clear on this part:
The L-BTC used in the peg-out had been created because of a bug in Elements software.
In other words the attacker had L-BTC that shouldnt have existed.
This wasnt a stolen-wallet-password situation.
It was a validation problem.
The network accepted something as valid that shouldnt have been valid.
The exact technical mechanism of the bug still has not been published in a full official post-mortem.
There are claims around things like rangeproof caching and confidential transaction components, but I wouldnt treat any of those as confirmed until Blockstream or Liquid publishes the technical breakdown.
2. The attacker sent 4,000 L-BTC into SideSwap’s peg-out
According to SideSwap:
September 6, 14:05 UTC
A customer sent 4,000 L-BTC to SideSwap’s peg-out service.
From the system’s perspective it looked like a normal request.
The L-BTC was burned.
The peg-out authorization looked valid.
PAK, or Peg-out Authorization Key, is basically another control that limits which Bitcoin addresses can receive peg-outs.
And this is another important point:
The PAK key was not stolen.
Liquid and SideSwap both said that the PAK and other signing keys were not compromised.
So again, the problem was not somebody stealing the keys and forcing the system to send BTC.
The system itself believed the withdrawal was legitimate.
3. Real BTC then left the federation reserve
At 14:28 UTC, the Liquid Federation paid exactly:
on Bitcoin mainnet.
You can verify the Bitcoin transaction here: https://mempool.space/tx/8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140
And the related Liquid peg-out here : https://blockstream.info/liquid/tx/ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2
So when people say “4,000 BTC” they are rounding.
The verifiable Bitcoin payment was 3,996.01834922 BTC, worth around $318–320M at the time.
This is real BTC that left the federation reserve.
That part isnt theoretical.
4. Liquid stopped
After the incident Liquid disabled bridge nodes and stopped new transactions.
Exchanges also started suspending L-BTC deposits and withdrawals.
So this wasnt only a reserve accounting problem.
If you were actually using Liquid, your ability to transfer, swap, peg in or peg out was affected too.
5. The attacker says they are whitehats
There is also this part.
The attacker left a message on Bitcoin:
“we are whitehats. contact us on chain.”
But saying you are a whitehat does not make you one.
At least not yet.
Until the funds are actually returned, the vulnerability is responsibly disclosed and the damage is resolved, I think the safest description is simply this:
The attacker claims to be a whitehat.
The funds have not been confirmed as returned.
So for now this is still an unresolved, very large security incident.
Why wasnt Bitcoin hacked?
Because from Bitcoin’s point of view nothing invalid happened.
The transaction had the required signatures.
Miners saw a valid Bitcoin transaction.
Bitcoin consensus accepted it.
No one broke Proof-of-Work.
No one broke Bitcoin cryptography.
No one changed the 21M supply cap.
Bitcoin had no way to know that the accounting inside Liquid was wrong.
Think of it like a bank.
Imagine a bank has a vault where withdrawals require multiple authorized signatures.
The bank’s internal system mistakenly tells those signers that a customer really owns $100M.
They approve the transfer.
The vault itself didnt fail.
The authorization process received bad information.
That is basically the distinction here.
So:
“Bitcoin was hacked” is wrong.
“Liquid’s federated peg suffered a major security failure” is much closer to what actually happened.
And this is where the story gets more interesting
For me the bigger lesson isnt really Liquid specifically.
Its what happens every time we take BTC and make it more usable somewhere else.
Native BTC in your own wallet mainly depends on Bitcoin’s own security assumptions.
L-BTC depends on more things.
Bitcoin consensus + Liquid software
Proof-of-Work + federation trust
Your keys + the peg mechanism
Liquid’s asset validation
And the federation managing the BTC reserve correctly.
That doesnt automatically mean L-BTC is unsafe.
It just means the risk model is wider.
Every bridge, sidechain, wrapped BTC product or custodian adds something useful.
And usually it also adds another thing that has to work correctly.
11-of-15 sounds safe. But what are the 11 actually signing?
This is probably my favorite part of the incident.
When people think about multisig security the question is usually:
How many keys would an attacker need to steal?
11-of-15 sounds strong because stealing 11 independent signing keys is obviously difficult.
But according to the current official explanation, that didnt happen here.
The signers were apparently presented with a state that looked valid.
So maybe the more important question is:
What are those 11 signers actually verifying?
And do all 11 depend on the same software logic?
Because if every signer independently has a secure key but every signer trusts the same broken validation logic, then key diversity does not necessarily give you validation diversity.
That is a very different type of risk.
And its one people talk about much less.
Even proof of reserves gets more complicated
Normally the obvious question for something like L-BTC is:
Does the amount of BTC sitting in the reserve match the amount of L-BTC in circulation?
Makes sense.
But confidential transaction systems make this harder because token amounts may not always be publicly visible in the same simple way.
And there is another issue.
If invalid L-BTC can be created and then burned in the same process that withdraws real BTC, a basic snapshot taken later may not tell you the whole historical story.
You could potentially look at the system after the event and miss how the mismatch happened.
I dont want to go further than the evidence here though.
This is not a final judgment on Liquid’s reserve design.
It is a reconciliation problem exposed by the incident.
We need the full technical report, reserve reconciliation and complete mint/burn accounting before making stronger claims.
Is this systemic for Bitcoin?
I dont think so.
Roughly 4,000 BTC is huge money.
But relative to Bitcoin itself it is not a systemic supply shock.
Bitcoin protocol security was not affected either.
So I wouldnt turn this into a “Bitcoin is broken” market story.
But for the infrastructure being built around Bitcoin?
Yes, this matters.
Especially as BTC gets wrapped, bridged, custodied and financialized across more systems.
There is also another distinction around other Liquid assets.
Liquid said assets like USDT, DePix and RWAs were not directly compromised by the security incident.
But “not directly compromised” does not mean “completely unaffected.”
If the network is stopped, you can still have transfer and liquidity problems even if the token itself was not hacked.
So who actually needs to care?
If you hold native BTC in your own wallet
This incident does not directly affect your protocol security.
Bitcoin L1 was not compromised.
If you hold L-BTC
You have operational exposure to Liquid’s peg, transfers and network restart.
Peg-outs, swaps and transfers being stopped obviously matter.
If you hold USDT or tokenized assets on Liquid
There is no confirmation that those assets themselves were hacked.
But if Liquid is not operating normally, access and liquidity can still become a problem.
If you use a product built on Liquid
Then I would care about exactly how much that product depends on Liquid, what collateral it uses and what the recovery/restart plan looks like.
My take
This was not a Bitcoin hack.
And I think describing it that way actually hides the more useful lesson.
A software bug in Elements allowed unbacked L-BTC to pass through what looked like a legitimate peg-out flow.
Liquid Federation then paid out 3,996 BTC on Bitcoin mainnet.
The keys apparently werent stolen.
The signatures worked.
Bitcoin worked.
The problem was that the thing being signed looked valid when it shouldnt have.
And that changes the security question quite a bit.
Its not only:
how many keys protect the reserve?
Its also:
what information are those keys trusting before they sign?
Bitcoin can be extremely secure while something built around Bitcoin still fails.
Every time we wrap BTC, bridge it, custody it or move it into another execution environment, we get more usability.
But we also add another trust assumption.
That is the real story here

BTC+၀.၄၇%

0xfrigg

Article

Bitcoin wasn’t hacked, Liquid wasOn September 6 exactly 3,996.01834922 $BTC left the Liquid Federation reserve. Naturally the first headlines made this sound like some kind of Bitcoin hack. It wasnt. Bitcoin L1 was not compromised. According to SideSwap’s official statement, the attacker first created L-BTC on Liquid through a bug in the Elements software and then passed that L-BTC through what looked like a normal peg-out process. The federation saw the peg-out as valid and paid out real BTC on Bitcoin mainnet. https://x.com/liquid_btc/status/2096696272447218108 So someone didnt hack Bitcoin directly. The software behind Bitcoin’s federated sidechain allowed invalid L-BTC to look like real L-BTC. And because the federation believed those assets had been legitimately burned, it released real BTC from its reserve. That difference is basically the whole story. Bitcoin’s blocks, miners, consensus, cryptography and normal L1 wallets were not compromised. What was affected was Liquid. L-BTC, the peg infrastructure and the ability to move assets through the network were the actual problem. What we know and what we still dont What we know: ➛ Around 4,000 BTC left the Liquid Federation reserve ➛ “Bitcoin mainnet was hacked” is false ➛ SideSwap says its PAK key and infrastructure were not stolen https://x.com/side_swap/status/2096709838310928674 ➛ The issue came from a bug in Elements ➛ Liquid operations were stopped What we still dont know: ➛ Whether all funds will be returned ➛ The exact total amount of unbacked L-BTC created And I think keeping those two groups separate matters here. There is already a lot of speculation around the exact bug. But until we get a proper technical post-mortem, some of those details are still only theories. First, what is Liquid? Lets make the setup simple first. Bitcoin is extremely secure, but Bitcoin itself is not designed to do every financial thing people want to do with BTC. Liquid is a separate network running alongside Bitcoin. A sidechain. Unlike Ethereum or other open validator networks though, Liquid is managed by a group of institutional participants called the Liquid Federation. The basic user flow looks like this: You send BTC into Liquid. That BTC gets locked in the federation’s Bitcoin mainnet reserve.You receive L-BTC on Liquid.You can use that L-BTC inside Liquid for faster transfers, confidential transactions or other products.When you want BTC back, the L-BTC is burned and the federation releases BTC from its reserve on Bitcoin mainnet. Liquid protects that BTC reserve using an 11-of-15 multisig. At least 11 of the 15 functionaries have to sign before BTC can leave the reserve. Sounds pretty strong. And for key security it is. But this incident shows why key security alone is not enough. You dont need to steal 11 keys if all 11 honest signers are being shown the same wrong information. If the software tells everyone “this withdrawal is valid”, honest signatures can still approve a bad payment. That is much more interesting to me than simply saying “multisig failed.” So what actually happened? 1. A bug in Elements made invalid L-BTC look valid Liquid runs on open-source software called Elements. Elements adds things like confidential transactions, confidential assets and the federated two-way peg on top of Bitcoin-like infrastructure. SideSwap’s statement is pretty clear on this part: The L-BTC used in the peg-out had been created because of a bug in Elements software. In other words the attacker had L-BTC that shouldnt have existed. This wasnt a stolen-wallet-password situation. It was a validation problem. The network accepted something as valid that shouldnt have been valid. The exact technical mechanism of the bug still has not been published in a full official post-mortem. There are claims around things like rangeproof caching and confidential transaction components, but I wouldnt treat any of those as confirmed until Blockstream or Liquid publishes the technical breakdown. 2. The attacker sent 4,000 L-BTC into SideSwap’s peg-out According to SideSwap: September 6, 14:05 UTC A customer sent 4,000 L-BTC to SideSwap’s peg-out service. From the system’s perspective it looked like a normal request. The L-BTC was burned. The peg-out authorization looked valid. PAK, or Peg-out Authorization Key, is basically another control that limits which Bitcoin addresses can receive peg-outs. And this is another important point: The PAK key was not stolen. Liquid and SideSwap both said that the PAK and other signing keys were not compromised. So again, the problem was not somebody stealing the keys and forcing the system to send BTC. The system itself believed the withdrawal was legitimate. 3. Real BTC then left the federation reserve At 14:28 UTC, the Liquid Federation paid exactly: on Bitcoin mainnet. You can verify the Bitcoin transaction here: https://mempool.space/tx/8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140 And the related Liquid peg-out here : https://blockstream.info/liquid/tx/ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2 So when people say “4,000 BTC” they are rounding. The verifiable Bitcoin payment was 3,996.01834922 BTC, worth around $318–320M at the time. This is real BTC that left the federation reserve. That part isnt theoretical. 4. Liquid stopped After the incident Liquid disabled bridge nodes and stopped new transactions. Exchanges also started suspending L-BTC deposits and withdrawals. So this wasnt only a reserve accounting problem. If you were actually using Liquid, your ability to transfer, swap, peg in or peg out was affected too. 5. The attacker says they are whitehats There is also this part. The attacker left a message on Bitcoin: “we are whitehats. contact us on chain.” But saying you are a whitehat does not make you one. At least not yet. Until the funds are actually returned, the vulnerability is responsibly disclosed and the damage is resolved, I think the safest description is simply this: The attacker claims to be a whitehat. The funds have not been confirmed as returned. So for now this is still an unresolved, very large security incident. Why wasnt Bitcoin hacked? Because from Bitcoin’s point of view nothing invalid happened. The transaction had the required signatures. Miners saw a valid Bitcoin transaction. Bitcoin consensus accepted it. No one broke Proof-of-Work. No one broke Bitcoin cryptography. No one changed the 21M supply cap. Bitcoin had no way to know that the accounting inside Liquid was wrong. Think of it like a bank. Imagine a bank has a vault where withdrawals require multiple authorized signatures. The bank’s internal system mistakenly tells those signers that a customer really owns $100M. They approve the transfer. The vault itself didnt fail. The authorization process received bad information. That is basically the distinction here. So: “Bitcoin was hacked” is wrong. “Liquid’s federated peg suffered a major security failure” is much closer to what actually happened. And this is where the story gets more interesting For me the bigger lesson isnt really Liquid specifically. Its what happens every time we take BTC and make it more usable somewhere else. Native BTC in your own wallet mainly depends on Bitcoin’s own security assumptions. L-BTC depends on more things. Bitcoin consensus + Liquid software Proof-of-Work + federation trust Your keys + the peg mechanism Liquid’s asset validation And the federation managing the BTC reserve correctly. That doesnt automatically mean L-BTC is unsafe. It just means the risk model is wider. Every bridge, sidechain, wrapped BTC product or custodian adds something useful. And usually it also adds another thing that has to work correctly. 11-of-15 sounds safe. But what are the 11 actually signing? This is probably my favorite part of the incident. When people think about multisig security the question is usually: How many keys would an attacker need to steal? 11-of-15 sounds strong because stealing 11 independent signing keys is obviously difficult. But according to the current official explanation, that didnt happen here. The signers were apparently presented with a state that looked valid. So maybe the more important question is: What are those 11 signers actually verifying? And do all 11 depend on the same software logic? Because if every signer independently has a secure key but every signer trusts the same broken validation logic, then key diversity does not necessarily give you validation diversity. That is a very different type of risk. And its one people talk about much less. Even proof of reserves gets more complicated Normally the obvious question for something like L-BTC is: Does the amount of BTC sitting in the reserve match the amount of L-BTC in circulation? Makes sense. But confidential transaction systems make this harder because token amounts may not always be publicly visible in the same simple way. And there is another issue. If invalid L-BTC can be created and then burned in the same process that withdraws real BTC, a basic snapshot taken later may not tell you the whole historical story. You could potentially look at the system after the event and miss how the mismatch happened. I dont want to go further than the evidence here though. This is not a final judgment on Liquid’s reserve design. It is a reconciliation problem exposed by the incident. We need the full technical report, reserve reconciliation and complete mint/burn accounting before making stronger claims. Is this systemic for Bitcoin? I dont think so. Roughly 4,000 BTC is huge money. But relative to Bitcoin itself it is not a systemic supply shock. Bitcoin protocol security was not affected either. So I wouldnt turn this into a “Bitcoin is broken” market story. But for the infrastructure being built around Bitcoin? Yes, this matters. Especially as BTC gets wrapped, bridged, custodied and financialized across more systems. There is also another distinction around other Liquid assets. Liquid said assets like USDT, DePix and RWAs were not directly compromised by the security incident. But “not directly compromised” does not mean “completely unaffected.” If the network is stopped, you can still have transfer and liquidity problems even if the token itself was not hacked. So who actually needs to care? If you hold native BTC in your own wallet This incident does not directly affect your protocol security. Bitcoin L1 was not compromised. If you hold L-BTC You have operational exposure to Liquid’s peg, transfers and network restart. Peg-outs, swaps and transfers being stopped obviously matter. If you hold USDT or tokenized assets on Liquid There is no confirmation that those assets themselves were hacked. But if Liquid is not operating normally, access and liquidity can still become a problem. If you use a product built on Liquid Then I would care about exactly how much that product depends on Liquid, what collateral it uses and what the recovery/restart plan looks like. My take This was not a Bitcoin hack. And I think describing it that way actually hides the more useful lesson. A software bug in Elements allowed unbacked L-BTC to pass through what looked like a legitimate peg-out flow. Liquid Federation then paid out 3,996 BTC on Bitcoin mainnet. The keys apparently werent stolen. The signatures worked. Bitcoin worked. The problem was that the thing being signed looked valid when it shouldnt have. And that changes the security question quite a bit. Its not only: how many keys protect the reserve? Its also: what information are those keys trusting before they sign? Bitcoin can be extremely secure while something built around Bitcoin still fails. Every time we wrap BTC, bridge it, custody it or move it into another execution environment, we get more usability. But we also add another trust assumption. That is the real story here

Bitcoin wasn’t hacked, Liquid was

On September 6 exactly 3,996.01834922 $BTC left the Liquid Federation reserve.
Naturally the first headlines made this sound like some kind of Bitcoin hack.
It wasnt.
Bitcoin L1 was not compromised.
According to SideSwap’s official statement, the attacker first created L-BTC on Liquid through a bug in the Elements software and then passed that L-BTC through what looked like a normal peg-out process.
The federation saw the peg-out as valid and paid out real BTC on Bitcoin mainnet.
https://x.com/liquid_btc/status/2096696272447218108
So someone didnt hack Bitcoin directly.
The software behind Bitcoin’s federated sidechain allowed invalid L-BTC to look like real L-BTC.
And because the federation believed those assets had been legitimately burned, it released real BTC from its reserve.
That difference is basically the whole story.
Bitcoin’s blocks, miners, consensus, cryptography and normal L1 wallets were not compromised.
What was affected was Liquid.
L-BTC, the peg infrastructure and the ability to move assets through the network were the actual problem.
What we know and what we still dont
What we know:
➛ Around 4,000 BTC left the Liquid Federation reserve
➛ “Bitcoin mainnet was hacked” is false
➛ SideSwap says its PAK key and infrastructure were not stolen
https://x.com/side_swap/status/2096709838310928674
➛ The issue came from a bug in Elements
➛ Liquid operations were stopped
What we still dont know:
➛ Whether all funds will be returned
➛ The exact total amount of unbacked L-BTC created
And I think keeping those two groups separate matters here.
There is already a lot of speculation around the exact bug. But until we get a proper technical post-mortem, some of those details are still only theories.
First, what is Liquid?
Lets make the setup simple first.
Bitcoin is extremely secure, but Bitcoin itself is not designed to do every financial thing people want to do with BTC.
Liquid is a separate network running alongside Bitcoin.
A sidechain.
Unlike Ethereum or other open validator networks though, Liquid is managed by a group of institutional participants called the Liquid Federation.
The basic user flow looks like this:
You send BTC into Liquid. That BTC gets locked in the federation’s Bitcoin mainnet reserve.You receive L-BTC on Liquid.You can use that L-BTC inside Liquid for faster transfers, confidential transactions or other products.When you want BTC back, the L-BTC is burned and the federation releases BTC from its reserve on Bitcoin mainnet.
Liquid protects that BTC reserve using an 11-of-15 multisig.
At least 11 of the 15 functionaries have to sign before BTC can leave the reserve.
Sounds pretty strong.
And for key security it is.
But this incident shows why key security alone is not enough.
You dont need to steal 11 keys if all 11 honest signers are being shown the same wrong information.
If the software tells everyone “this withdrawal is valid”, honest signatures can still approve a bad payment.
That is much more interesting to me than simply saying “multisig failed.”
So what actually happened?
1. A bug in Elements made invalid L-BTC look valid
Liquid runs on open-source software called Elements.
Elements adds things like confidential transactions, confidential assets and the federated two-way peg on top of Bitcoin-like infrastructure.
SideSwap’s statement is pretty clear on this part:
The L-BTC used in the peg-out had been created because of a bug in Elements software.
In other words the attacker had L-BTC that shouldnt have existed.
This wasnt a stolen-wallet-password situation.
It was a validation problem.
The network accepted something as valid that shouldnt have been valid.
The exact technical mechanism of the bug still has not been published in a full official post-mortem.
There are claims around things like rangeproof caching and confidential transaction components, but I wouldnt treat any of those as confirmed until Blockstream or Liquid publishes the technical breakdown.
2. The attacker sent 4,000 L-BTC into SideSwap’s peg-out
According to SideSwap:
September 6, 14:05 UTC
A customer sent 4,000 L-BTC to SideSwap’s peg-out service.
From the system’s perspective it looked like a normal request.
The L-BTC was burned.
The peg-out authorization looked valid.
PAK, or Peg-out Authorization Key, is basically another control that limits which Bitcoin addresses can receive peg-outs.
And this is another important point:
The PAK key was not stolen.
Liquid and SideSwap both said that the PAK and other signing keys were not compromised.
So again, the problem was not somebody stealing the keys and forcing the system to send BTC.
The system itself believed the withdrawal was legitimate.
3. Real BTC then left the federation reserve
At 14:28 UTC, the Liquid Federation paid exactly:
on Bitcoin mainnet.
You can verify the Bitcoin transaction here: https://mempool.space/tx/8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140
And the related Liquid peg-out here : https://blockstream.info/liquid/tx/ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2
So when people say “4,000 BTC” they are rounding.
The verifiable Bitcoin payment was 3,996.01834922 BTC, worth around $318–320M at the time.
This is real BTC that left the federation reserve.
That part isnt theoretical.
4. Liquid stopped
After the incident Liquid disabled bridge nodes and stopped new transactions.
Exchanges also started suspending L-BTC deposits and withdrawals.
So this wasnt only a reserve accounting problem.
If you were actually using Liquid, your ability to transfer, swap, peg in or peg out was affected too.
5. The attacker says they are whitehats
There is also this part.
The attacker left a message on Bitcoin:
“we are whitehats. contact us on chain.”
But saying you are a whitehat does not make you one.
At least not yet.
Until the funds are actually returned, the vulnerability is responsibly disclosed and the damage is resolved, I think the safest description is simply this:
The attacker claims to be a whitehat.
The funds have not been confirmed as returned.
So for now this is still an unresolved, very large security incident.
Why wasnt Bitcoin hacked?
Because from Bitcoin’s point of view nothing invalid happened.
The transaction had the required signatures.
Miners saw a valid Bitcoin transaction.
Bitcoin consensus accepted it.
No one broke Proof-of-Work.
No one broke Bitcoin cryptography.
No one changed the 21M supply cap.
Bitcoin had no way to know that the accounting inside Liquid was wrong.
Think of it like a bank.
Imagine a bank has a vault where withdrawals require multiple authorized signatures.
The bank’s internal system mistakenly tells those signers that a customer really owns $100M.
They approve the transfer.
The vault itself didnt fail.
The authorization process received bad information.
That is basically the distinction here.
So:
“Bitcoin was hacked” is wrong.
“Liquid’s federated peg suffered a major security failure” is much closer to what actually happened.
And this is where the story gets more interesting
For me the bigger lesson isnt really Liquid specifically.
Its what happens every time we take BTC and make it more usable somewhere else.
Native BTC in your own wallet mainly depends on Bitcoin’s own security assumptions.
L-BTC depends on more things.
Bitcoin consensus + Liquid software
Proof-of-Work + federation trust
Your keys + the peg mechanism
Liquid’s asset validation
And the federation managing the BTC reserve correctly.
That doesnt automatically mean L-BTC is unsafe.
It just means the risk model is wider.
Every bridge, sidechain, wrapped BTC product or custodian adds something useful.
And usually it also adds another thing that has to work correctly.
11-of-15 sounds safe. But what are the 11 actually signing?
This is probably my favorite part of the incident.
When people think about multisig security the question is usually:
How many keys would an attacker need to steal?
11-of-15 sounds strong because stealing 11 independent signing keys is obviously difficult.
But according to the current official explanation, that didnt happen here.
The signers were apparently presented with a state that looked valid.
So maybe the more important question is:
What are those 11 signers actually verifying?
And do all 11 depend on the same software logic?
Because if every signer independently has a secure key but every signer trusts the same broken validation logic, then key diversity does not necessarily give you validation diversity.
That is a very different type of risk.
And its one people talk about much less.
Even proof of reserves gets more complicated
Normally the obvious question for something like L-BTC is:
Does the amount of BTC sitting in the reserve match the amount of L-BTC in circulation?
Makes sense.
But confidential transaction systems make this harder because token amounts may not always be publicly visible in the same simple way.
And there is another issue.
If invalid L-BTC can be created and then burned in the same process that withdraws real BTC, a basic snapshot taken later may not tell you the whole historical story.
You could potentially look at the system after the event and miss how the mismatch happened.
I dont want to go further than the evidence here though.
This is not a final judgment on Liquid’s reserve design.
It is a reconciliation problem exposed by the incident.
We need the full technical report, reserve reconciliation and complete mint/burn accounting before making stronger claims.
Is this systemic for Bitcoin?
I dont think so.
Roughly 4,000 BTC is huge money.
But relative to Bitcoin itself it is not a systemic supply shock.
Bitcoin protocol security was not affected either.
So I wouldnt turn this into a “Bitcoin is broken” market story.
But for the infrastructure being built around Bitcoin?
Yes, this matters.
Especially as BTC gets wrapped, bridged, custodied and financialized across more systems.
There is also another distinction around other Liquid assets.
Liquid said assets like USDT, DePix and RWAs were not directly compromised by the security incident.
But “not directly compromised” does not mean “completely unaffected.”
If the network is stopped, you can still have transfer and liquidity problems even if the token itself was not hacked.
So who actually needs to care?
If you hold native BTC in your own wallet
This incident does not directly affect your protocol security.
Bitcoin L1 was not compromised.
If you hold L-BTC
You have operational exposure to Liquid’s peg, transfers and network restart.
Peg-outs, swaps and transfers being stopped obviously matter.
If you hold USDT or tokenized assets on Liquid
There is no confirmation that those assets themselves were hacked.
But if Liquid is not operating normally, access and liquidity can still become a problem.
If you use a product built on Liquid
Then I would care about exactly how much that product depends on Liquid, what collateral it uses and what the recovery/restart plan looks like.
My take
This was not a Bitcoin hack.
And I think describing it that way actually hides the more useful lesson.
A software bug in Elements allowed unbacked L-BTC to pass through what looked like a legitimate peg-out flow.
Liquid Federation then paid out 3,996 BTC on Bitcoin mainnet.
The keys apparently werent stolen.
The signatures worked.
Bitcoin worked.
The problem was that the thing being signed looked valid when it shouldnt have.
And that changes the security question quite a bit.
Its not only:
how many keys protect the reserve?
Its also:
what information are those keys trusting before they sign?
Bitcoin can be extremely secure while something built around Bitcoin still fails.
Every time we wrap BTC, bridge it, custody it or move it into another execution environment, we get more usability.
But we also add another trust assumption.
That is the real story here

BTC+၀.၄၇%

0xfrigg

I’m basically at:

rally is real

demand is real

leverage helped a lot

altseason still no

that’s the whole picture for me rn

0xfrigg

Bitcoin wasn’t hacked, Liquid was

ရေပန်းစားနေသော ခေါင်းစဉ်များ