OAK — OnChain Attack Knowledge

Worked example · 2026-10

b14g — withdrawal requests for 0 CORE were passed through to Core's staking code, which reads 0 as "withdraw everything" — b14g / Core — 2026-10-31

Loss
~97.05M CORE (~$1.47M at ~$0.0151 per CORE) per Bitquery's reconstruction; b14g's own figure is "approximately 97M CORE". b14g's tracing: about 68M CORE still on Core and about 9M CORE frozen by exchange partners. BTC staked through b14g is time-locked on Bitcoin and was not affected.
OAK Techniques observed
OAK-T9.016 (Contract Accounting / State-Invariant Flaw — primary, per Bitquery, not yet confirmed by b14g. The attacker made 99 withdrawal requests for 0 CORE across 91 b14g orders in one transaction. Core's staking code reads a zero amount as a request for the full staked balance, and b14g's contract passed the 0 through, so each order paid out in full. The caller made calls the contract allowed; the contract's idea of "how much" was wrong. See techniques/T9.016-contract-accounting-state-invariant-flaw.md). No key was stolen and no new code was deployed (Bitquery). No better-fitting Technique exists: T9.015 is specific to signature verification.
Attribution
unattributed. Attacker addresses are the two b14g published.
Key teaching point
Treat 0 as an invalid amount at your own boundary, and never forward a user amount to an underlying contract whose meaning of 0 you have not checked. A wrapper that validates only "does this user own this order" lets a sentinel value in the downstream API ("0 means all") turn a no-op into a full withdrawal.

Summary

At 09:29:51 UTC on 2026-10-31 a wallet with no prior history sent one transaction to the b14g proxy that withdrew about 97.05M CORE staked through b14g and sent it to attacker-controlled addresses. b14g paused the affected contracts, posted a security update at 16:38 UTC, and said a post-mortem would follow. Core DAO said the Core network, consensus, validators and directly staked CORE were unaffected. The mechanism comes from Bitquery's on-chain reconstruction, repeated by RektRadar; b14g has not yet published its post-mortem.

Timeline (UTC)

Stages. Flaw: b14g forwards a 0 amount to staking code that treats 0 as "all". Take: one transaction empties 91 orders. Money: wallet A moves coins to new wallets and exchange-linked addresses. Response: pause, statements, freezes. Times are from Bitquery, b14g, Core DAO and OAK's check of the Core RPC.

When What happened OAK
Before 2026-10-31 (since when: undisclosed) b14g's contract is a proxy whose logic had been unchanged for 17 months (Bitquery). Withdrawal requests of 0 CORE are passed to Core's staking contract, which reads 0 as the full stake with that validator. The faulty line in b14g's code has not been published. T9.016
2026-10-31 09:00:42 Wallet A, new and with no prior record, receives its only funding, 615.62 CORE, from a service Bitquery labels "service Y" (0x63c619d68c0f6daacf09f0a11ad03cea5f9ee1d8). —
2026-10-31 09:29:51 Drain transaction 0xe1947f325e1f0bc22290ea97dc5b2ce44827fbb56e1cc40abaeda1d2ed04f62c: wallet A calls the b14g proxy with 99 requests for 0 CORE across 91 orders; 97,045,563 CORE released (Bitquery). Traced by OAK on the Core RPC: block 0x262fe8d, timestamp 09:29:51 UTC, status success, 99 event logs emitted by the b14g proxy. T9.016
2026-10-31 09:37 → 10:10 Wallet A sends 23.4M CORE to 11 new addresses (Bitquery). —
2026-10-31 10:15 → 11:15 Service Y passes 11.16M CORE of stolen coins to a deposit address Bitquery labels MEXC (0x8251321719179b7dc5680c5722741347756753ec). —
2026-10-31 10:35:51 The b14g multisig pauses the contract, 66 minutes after the drain. Bitquery notes that when b14g first detected the problem cannot be confirmed on-chain. A user withdrew 80 CORE normally at 09:59:12 through the same function. response
2026-10-31 10:36:33 Wallet A moves the remaining 73,646,178 CORE to wallet B (Bitquery). Between 10:41 and 10:47 wallet B sends 15M CORE to four new addresses; one returns 4,999,999 CORE at about 10:50. —
2026-10-31 16:38 b14g posts its security update: contracts paused; about 68M CORE remains on Core; about 9M CORE frozen by exchange partners; post-mortem promised. response
2026-10-31 17:24 Core DAO: the Core network is secure; it is helping b14g and exchanges trace and freeze funds. response
2026-10-31 19:43 Bitquery: 68.15M CORE (70%) unmoved: 63.65M in wallet B and 4.5M in two new wallets. —

Key addresses:

The Ethereum address 0x91926046e148c66869d71B9Fa37306e82DDc8934 in RektRadar's daily roundup belongs to a different incident (a Troves Starknet vault, per a Defimon-relayed Troves on-chain message) and is not part of b14g.

What is not known

  • b14g's own explanation of the cause: its post-mortem was announced but not yet published at last check.
  • Which line of b14g's code forwards the 0 amount. Bitquery says the code was not reviewed.
  • Whether the amount is "one transaction" in the user sense: RektRadar's summary says one transaction, the body says 91 orders; the on-chain record shows one transaction containing 99 requests.
  • When b14g first detected the problem, and where wallet B's coins went after 19:43 UTC on 10-31.

Root-cause evidence

Public references

Techniques demonstrated (1)

More incidents