b14g Exploit Drains About 97M CORE; Exchanges Freeze 9M, Sources Disagree on Scope
Bitcoin staking platform b14g lost about 97 million CORE in an Oct. 31 exploit that drained 91 staking positions through zero-token withdrawals. The platform has paused affected contracts, and exchange partners reportedly froze roughly 9 million CORE linked to the attacker.
Written by CoinArticle’s AI Newsroom · from 2 cited sources. How we work
What Happened
The Bitcoin staking protocol b14g lost approximately 97 million CORE tokens in an exploit on Oct. 31, a loss the platform valued at $1.47 million. According to an investigation by blockchain analytics firm Bitquery, the attacker drained 91 staking positions in a single transaction at 09:29 UTC by submitting withdrawal requests for zero CORE.
Bitquery said the attacker submitted 99 zero-value withdrawal requests against staking positions it had not funded. Core's staking contract reportedly interprets a zero-token withdrawal as an instruction to withdraw the entire staked balance, and b14g's contract passed those instructions through without rejecting them. Bitquery said it had not reviewed b14g's source code and could not identify the precise programming error, and noted that the underlying logic had reportedly been in place for about 17 months.
Scope and Disputed Figures
The two sources agree on the core facts but differ on how much CORE was ultimately frozen. The Defiant reports that exchanges froze about 9 million CORE, while b14g's own account, as relayed in the reporting, describes exchange partners freezing approximately 9 million CORE linked to the attacker. Neither source provides a reconciled figure for how much of the 97 million remains recoverable, so the frozen amount should be read as a partial and unverified recovery number.
On the scope of the breach, both sources report that b14g said staked Bitcoin was unaffected. The BTC remains time-locked on the Bitcoin blockchain, and the exploit was limited to CORE deposits. Core DAO separately said the underlying blockchain was not compromised and that its consensus mechanism, validators, and staking contracts continued operating normally. It also said CORE staked directly with validators or through other protocols was not affected.
Fund Movements and Response Timeline
Blockchain records show b14g did not pause the affected contracts until 10:35 UTC, about 66 minutes after the initial attack. In that window, the attacker moved 23 million CORE from the original wallet through several newly created addresses. The timeline does not establish when b14g first detected the breach, though the platform said it paused contracts immediately after identifying the incident.
Bitquery traced some stolen funds to intermediary addresses linked to exchange infrastructure at Bybit, Gate.io and MEXC. It identified a service that supplied the attacker's initial transaction fees and later received about 11 million CORE before forwarding it to an MEXC deposit address. Bitquery cautioned that some intermediary wallets also handled other customers' assets, so not every onward transfer can be attributed directly to the attacker. As of the evening of Oct. 31, about 68 million CORE, roughly 70% of the stolen tokens, remained in three wallets.
Open Questions
The key unresolved items are the exact code defect, the date b14g first became aware of the issue, and how much of the stolen balance exchanges will ultimately freeze or return. Both the platform and Bitquery say recovery efforts are ongoing with the Core team, security partners and exchanges, and no final accounting has been published.
Why It Matters
For Traders
CORE holders should expect price pressure to track how much of the 68 million CORE still held by the attacker is frozen or moved, as that supply could reach the market.
For Investors
The incident exposes a cross-protocol dependency risk: a flaw in a third-party staking contract let an outside platform's logic drain assets, which will weigh on how sector risk is priced.
For Builders
Any protocol that forwards withdrawal calls to another contract should validate zero-value and unfunded-position inputs explicitly rather than assuming the downstream system will reject them.
This article is for information only and is not financial advice. Read the full disclaimer.
