Good to finally see an official statement from @injective — and genuinely good news in it: the exploit is contained and patched, consensus was never compromised, and staked INJ was never at risk. Credit for that.
A few points of precision, though, because I've been documenting this from the chain and I think an accurate record helps everyone — including Injective.
On "upgraded, not halted": on-chain, block 181,027,005 was the last one produced at 16:09:59 UTC, and the next block didn't arrive for roughly four hours (one block, 181,027,001, took ~37 minutes on its own). There was no upgrade proposal on-chain, and the binary the network restarted on is tagged safeharbor. I understand the intent behind "accelerated upgrade," but a multi-hour stop in block production is what most people will read as a halt. Precision here actually protects credibility more than softening it does.
On "isolated to ecosystem applications": the exploit ran through native https://t.co/8GNmj8ooUz / https://t.co/SFQHwUJah1 module messages, and the fix — v1.20.3-safeharbor.1 — is a patch to the core chain's own code (a missing insurance-fund denom check, plus disabling binary options on mainnet). So it's fairer to say the vulnerability was in a core module that apps used, rather than in the apps themselves. That's not a knock — it just matters for where the fix and the lesson sit.
Two things the community would value: roughly how much was drained, and confirmation of who made the shared pool whole (it reads full today, which is reassuring — worth stating plainly). For context, ~$4.9M is still sitting in the attacker's wallet, unmoved.
None of this changes the important part: funds are safe and the hole is closed. I'm long INJ and I want this ecosystem to win — which is exactly why I'd rather the story be told straight. Happy to be corrected on any of the above; every number is one public query away.
Receipts in the replies: the frozen block, the ~37-min gap, and the v1.20.3...v1.20.3-safeharbor.1 diff.
@GrinDroid@ericinjective But to be honest this was my first in depth chain analysis. I just was wondering what was happening becuase my own money was unreachable for hours. 😂 What do you use for your token analysis? Maybe we should build something together 🙂
🚨 EXPLOITER TRACE: Unmasking the "stolz.sol" Cluster 🧵👇
An attacker rarely leaves just on-chain noise—they usually leave a digital footprint. Trace analysis on the exploiter reveals a clear profile: an extremely active Solana memecoin & perpetuals trader who got a bit too comfortable.
1️⃣ The Identity Anchor: stolz.sol
Wallet: ApdjRwfTxMhDpwD2m27MBzy4K3rHSgGADFoNp89ynXVm
SNS Domain: Holds the domain stolz (German for "proud"). Verified via Bonfida API & held as an SNS NFT in the wallet.
Activity: >1,000 transactions, active since April 2024 (started with a Magic Eden trade).
NFT Hoard: 48 NFTs on Magic Eden, including 24x Blatant, 7x Watermelon Club Pass, DAWGz, y00t, Solswipe, AlphaAlerts, and a Solana ID Priority Pass.
Memecoin Degen: Dozens of Relay swaps swinging $FARTCOIN, $PENGU,$TRUMP, $JUP & $SOL.
* OPSEC: Social records (Twitter, Discord, TG) are empty—yet the domain choice speaks for itself.
2️⃣ Converging Wallets & Derivatives Focus
Traces show multiple wallets converging on the exact same target accounts:
Zeta Markets Trader (4iBr...VCbB): 177 txs, heavy perpetuals trading. Seeded by a 27,173 SOL exchange hot wallet. Pattern: A perps trader attacking a derivatives exchange—100% behaviorally consistent.
Feeder Wallets (G8Bg...1upA & J5Bfa...NS6J): Systematically funded the attack infrastructure with genesis SOL transfers.
3️⃣ The Vulnerability: KYC Exchange Trails
This is where it gets dangerous for the attacker. Transfers connected to centralized exchanges (CEXs) link these wallets directly to KYC-backed identities.
| Deposit / Withdrawal Address | Exchange | Active Since | Evidence |
ASTyfSima4LLAdDgoFGkgqoKowG1LZFDr9fAQrg7iaJZ | Exchange Hot Wallet | Dec 2023 | Direct Genesis Funding (0.53 SOL) to Perps Wallet |
| FpwQQhQQoEaV... | Centralized Exchange | Nov 2024 | Genesis Funding (0.24 SOL) to Feeder Wallet |
💡 Takeaway: Hubris always comes back to bite. Instead of using a clean privacy wallet, the exploiter relied on a mature trading cluster tied to CEX funding and NFT history. Forensics just need to follow the subpoenas.
#Solana #CryptoSecurityq @injective #OnChainAnalysis #Web3Exploit #BlockchainForensics
Everyone's watching the ~$5M the Injective exploiter stole. It's still sitting in one wallet, untouched. The money that actually tells you something is somewhere else.
There's a second wallet cluster tied to this operator, and it doesn't hold stolen funds — it holds his own. In the 48 hours around the exploit, ~356 ETH (~$890K) left MEXC's hot wallet 0x9642b23Ed1E01Df1092B92641051881a322F5D4E in 113 separate tranches into 0x92478333…30b7, topped up with ETH sent straight from Binance hot wallets. It then consolidated into 0x1F71e4ab…694B — 340 ETH in one move, tx 0x00ca364d2f5c0b3680e7e34fdb8bf9b53f520a02395c18e1ac442fbb1c666bca.
Let me be exact about the link, because precision is the whole point here. I cannot prove this cluster shares a private key with the exploit wallet. The addresses are different, and the bridge between them runs through Solana, where ed25519 keys can't be matched to Ethereum's secp256k1 by construction. So this is not "same key." It's something almost as hard to argue away: the proven exploit wallet and this second cluster both fund the exact same personal Solana wallet, hours apart, on the same day.
AhAqhRBPbBSheEvwrknu1pLdb3GwDVQcBs1rfudBacDj — active since 2024, sweeps everything it receives into one exchange deposit. The exploit wallet 0x792C fed it 7.36 SOL at 17:31 UTC on Aug 31. The second cluster's 0x1F71e4ab fed it 22.05 SOL at 21:37 UTC the same day. Same wallet, same off-ramp, same hands.
And where did that ~$890K go? Not onto the stolen pile — it was washed. ~$519K into Monero via Hyperliquid and the https://t.co/QCHOsoqcwL bridge (HL deposit 0x35d11189d081e41276b1b846802dee210c10189a), and 4.9885 BTC through Chainflip, still unspent at bc1qjawpvznfqnasx9gsl5wjwrjg58zyytlzmsse3v.
Now read the timeline again. The stolen $5M is frozen in place, too hot to touch. What he rushed to launder was his own exchange capital — because @MEXC and @binance both hold his KYC, and he knows it. Every one of those 113 withdrawals has a real name behind it.
Verify every hash yourself. @injective
The Injective exploiter isn't a ghost who appeared on Sunday.
One of the wallets that received his test ETH has been depositing to Binance for weeks — before the exploit. Same vanity family as the attack cluster. The 1,980 ETH is still sitting. The offramp already has a name attached, at an exchange.
Receipts. 🧵
People keep saying the trail dies at https://t.co/f5h55ORj60. That's the seed. It isn't the whole trail.
During the halt the exploiter sent 0.31 ETH from his operating wallet to:
`0x8B4cae3ED33B74fdbb63395248F5f38FfE696A68`
That address is not a fresh burner. First inflows: February 2024. Vanity suffix `…6a68` — the same family as the other probe wallets in this cluster.
Now the part that matters.
In July and August 2026 — weeks before Sunday — that same wallet sent USDC, ten times, to:
`0xEe7aE85f2Fe2239E27D9c1E23fFFe168D63b4055`
Arkham labels that address as a Binance hot wallet (Proof of Reserves). ~$838 USDC, plus 285 USDT to Binance 14 on August 7.
That is a person using Binance as an offramp. Before the exploit. Not after.
Sunday, 16:15 UTC: exploiter → 0x8B4cae3E, 0.3084 ETH.
Sunday, 16:22 UTC: 0x8B4cae3E sweeps 0.338 ETH to Binance 14 (`0x28C6c062…`).
Same minute, a second vanity in the cluster (`0x3244C94b…3159`) sweeps to the same Binance hot wallet.
Two wallets. One minute. One exchange.
I am not saying I have a legal name. I don't.
I am saying: the person who controls that key has been sending dollars to Binance since July. Binance can open the account. The 1,980 ETH in `0x5A18C382…69EA` still hasn't moved. The KYC trail is older than the crime.
Second receipt, because it clarifies how this was even possible.
The "dead oracle" wasn't just a forgotten dApp.
Proposal #458, November 2024. Submitted by an Injective Labs member (they disclosed it in the text). It removed Frontrunner's last relayer (`inj1ttpxf6…`) to "reduce overhead."
It did not deregister the provider. Frontrunner stayed in the oracle registry with zero relayers for 21 months. That is exactly the no-price state the refund path needs.
Labs didn't exploit it. They left it loaded.
I'm long INJ. Not shorting, not selling, not sponsored. I want the chain I hold to be precise about what happened, and I want the person who drained the pool identified through the door they already walked through.
Happy to be corrected. Every address above is one public query.
@injective
Injective's patch closed the hole. Here's the path back to trust it hasn't taken yet — and what it means for you as a user.
For users: on-chain, the shared pool is whole and the exploit is closed. Your funds look safe. But ~$5–6.5M was drained, the pool is full again, and no one has said who backfilled it. You're trusting an unverified repair. The ~$4.9M is still sitting in the attacker's wallet, unmoved.
What the team owes everyone, in order:
1. A post-mortem. What the bug was (a missing insurance-fund denom check), the timeline, the total, the fix.
2. The number, and who covered the loss — say plainly whether users are whole and who paid.
3. Fix the bounty program. A white-hat disclosed a $500M bug in Nov and got $50K offered, reportedly unpaid. Pay it. Or keep training finders to exploit instead of report.
4. An independent audit of the whole derivative/insurance module — the vulnerable function serves perps too, not just binary options.
5. A status page. Actual communication.
@injective
Is Injective still at risk after the patch? I read the fix, so here's the honest read.
The specific hole is closed — twice: a denom-equality check in the insurance-fund payout, plus binary options hard-disabled on mainnet. Not trivially re-exploitable.
But three things the patch quietly admits:
1. A basic "do the currencies match?" check was missing from money-moving code. Where one validation was absent, others can be. That's a rigor problem, not a line-of-code problem.
2. They didn't just fix binary options — they killed them on mainnet. If the denom check fully closed it, you wouldn't need the kill switch too. Belt-and-suspenders means they don't fully trust that module.
3. The vulnerable function isn't binary-options-only. It's called from perp liquidation and socialized-loss paths too — Injective's core product. The missing check lived in shared derivative code; binary options was just the easy permissionless trigger. Now patched everywhere, but that's how close it sat to the main product.
Verify: compare v1.20.3...v1.20.3-safeharbor.1 on https://t.co/fllU7UHKhn. @injective
I read the actual emergency patch Injective shipped during the halt. It corrects the record on what the bug even was — and shows the "fix" is half repair, half kill switch.
The diff is one commit, ~91 lines: v1.20.3 → v1.20.3-safeharbor.1, public now under https://t.co/fllU7UHKhn.
Media framed this as a "market ID collision." The patch touches no ID hashing. The real bug is one missing check. When a market settled with a deficit, PayDeficitFromInsuranceFund paid it out of an insurance fund without verifying the fund's currency matched the market's currency. The fix adds exactly that:
if insuranceFund.DepositDenom == marketQuoteDenom { return nil } — otherwise error.
That's the whole exploit. The attacker created markets quoted in USDC / USDT / ATOM, but backed them with insurance funds denominated in INJ — and the deficit payout drew from the mismatched fund without conversion or validation. On-chain, you can see it: the attacker created 299 insurance funds, every one denominated in INJ, paired with stablecoin/ATOM markets. The patch and the chain tell the same story.
The second half of the fix isn't a fix at all. It's a kill switch. Four new checks now hard-disable binary options whenever ChainID == "injective-1" — market launch, limit orders, batch orders, and settlement all short-circuit on mainnet. Binary options weren't repaired and reopened. They were turned off.
So: the actual root cause was a missing denom-equality check in the insurance-fund deficit path — a check that also guards the perp liquidation and socialized-loss paths, now hardened across all of them. Not an ID collision. And the headline feature that got drained is simply gone from mainnet.
Everything here is in the public diff — compare v1.20.3.lf.
Nobody's connecting the Injective exploit to the reason it was inevitable. Here's the pattern.
November 2025: a white-hat, @al_f4lc0n , responsibly discloses a critical Injective bug through Immunefi — one that let any user erase any account on the chain, up to ~$500M at risk. Injective's response? They pushed a mainnet upgrade to fix it the very next day (so they used the report), offered him $50K against a $500K max — a tenth — then went quiet for three months and, per his account, never even paid the $50K.
August 2026: someone finds a bug in the binary-options settlement module. They don't report it. They drain ~$5M+ across 299 markets and taunt the community while doing it.
These two events are the same story. When a chain pays peanuts for responsible disclosure and ghosts the people who hand it $500M saves, it isn't "securing the ecosystem" — it's teaching every future bug-finder that the honest path pays $50K and an insult, while the dishonest path pays millions and leaves in an afternoon. You get the security culture you incentivize.
The binary-options bug was the vulnerability. The bounty program was the root cause.
Sources: f4lc0n's Immunefi disclosure (Nov 30, 2025) is public; the $50K/$500K dispute was widely reported. On-chain exploit details in my earlier threads.
Disclosure: not sponsored, I want the chain I hold to fix the incentive, not just the code. @injective
People assume the Injective exploiter was a whale — $9.75M in USDC deposits will do that. The chain says the opposite: it was a small player who recycled a tiny seed through the bug hundreds of times.
The only external money that ever entered this operation was 22.75 ETH (~$56K), sent from https://t.co/f5h55OQLgs — a no-KYC, non-custodial instant swapper based in the Seychelles (no account, no email, no identity; you just paste a destination address). tx 0x3d1e130d…. From there they bridged a few thousand dollars of working capital onto Injective and started looping.
The "$9.75M deposited" is the same small capital cycled ~258 times through the no-price refund — each round returning ~1.5×. Net extraction across four assets: ~$5.14M USDC, $1.08M USDT, $175K Noble-USDC, 57K ATOM ≈ $6.5M total. Not a fund. Not a desk. One person turning ~$56K into millions on a permissionless bug.
And that origin is the point: the seed came through a no-KYC Seychelles swap, so the trail dead-ends with no identity attached — by design. The only realistic paths to a name now are https://t.co/f5h55OQLgs voluntarily cooperating, or the attacker slipping up and cashing the 1,980 ETH out through a KYC exchange that freezes it. Until then, it's a ghost with a $56K bankroll and a 90× exit.
All on-chain: MsgDeposit/MsgWithdraw on inj10ykxh78…, and the https://t.co/f5h55OQLgs funding tx above. Sum it yourself.
Disclosure: not sponsored. @injective
I summed every one of the exploiter's 1,522 transactions. In USDC alone they deposited $9.75M and withdrew $14.89M — a net $5.14M pulled from Injective's shared exchange pool. Add USDT ($1.08M), Noble-USDC ($175K) and ATOM (57,414 tokens) and net extraction is ~$6.5M across four assets. The "$2.79M USDC" figure everyone's repeating undercounts it by ~2×, and it wasn't one token — it was four. MsgDeposit/MsgWithdraw on inj10ykxh78… — sum them yourself. @injective