A $ 3.9 Million 'Master Key':
How a Hacker Drained B² Network

On July 23, 2026, approximately $ 3.9 million worth of B2 tokens was withdrawn from B² Network’s staking contract. What makes the incident unusual is that the attacker did not exploit the code in the conventional sense. Instead, they gained control of a privileged key used by the project to upgrade its contracts, quietly replaced the contract’s underlying logic, and made the contract release the funds itself. The stolen assets then disappeared across four blockchains.

BitOK analysts reconstructed how the attacker used this 'master key' and where the stolen funds ultimately went.

The first point to understand is that the weak link was not the contract code itself, but the access controls governing who could change it. Before going further, here are three terms that are central to the incident:

A simple analogy helps explain the exploit. Imagine an office where every payment is processed by an automated cashier that follows instructions stored in a safe. The cashier cannot be bribed and does not make mistakes; it simply executes what is written. A technical administrator, however, is authorized to rewrite those instructions. The attacker gains administrator access and adds a new rule: 'When this signal is received, transfer all funds to this account.' The cashier follows the updated instruction without violating any of its rules. The attacker never had to break the cashier - they changed the rules it was required to follow.

The key facts:

Important: There was no repeated withdrawal caused by a coding error, no price-oracle manipulation, and no malfunction in reward accounting. The decisive event was the unauthorized replacement of the contract's logic.

After receiving the B2 tokens, the attacker did not keep the funds in their original form. The tokens were sold through LiquidMesh trading infrastructure. The resulting BNB and WBNB were consolidated in the second wallet, and the WBNB was unwrapped back into native BNB. From there, the flow split into several branches.

Investigator's note: WBNB is the wrapped version of BNB - a tokenized format used in decentralized trading. Unwrapping it back into native BNB made the subsequent transfers easier to execute.

The transfer routes were as follows:

Two routes that initially appear different - one directly from BNB Chain and another passing through Ethereum - ultimately converge at the same destination: the NEAR Intents service layer. This is crucial to understanding why the trail becomes difficult to follow.

How the attacker moved the funds. The graph was built using BitOK's Graph tool.

A possible, but unconfirmed, exit into Zcash should also be noted. Transactions involving ZEC were observed within the NEAR/HOT infrastructure. This may indicate that part of the funds was converted into Zcash, but no public withdrawal address could be conclusively linked to the stolen assets. Zcash should therefore be treated as a possible direction of travel, not a confirmed endpoint.

The funds can be publicly traced to several boundaries. It is important to distinguish between the last visible node and the actual final owner: a service deposit or bridge may be only an intermediate step, not a wallet controlled by the attacker.

Bottom line: Most of the traceable flow entered NEAR Confidential Intents, partly directly and partly through Ethereum. Another confirmed branch ended at a Solana collector wallet. Once the funds entered NEAR, the public link to the ultimate recipient wallets was lost, and there is no conclusive evidence that all of the funds were withdrawn into Zcash.

Important: NEAR Intents pools deposits from many users and processes them through internal operational wallets. A single deposit does not necessarily correspond to a single withdrawal, and matching amounts or closely timed transactions are not proof on their own. Conclusive deanonymization would require internal service records covering user intents, deposits, and withdrawals.

The attacker's most valuable asset was neither capital nor a sophisticated market strategy, but access to a trusted upgrade key. Once in control of that key, the attacker replaced the staking contract's logic, made it release the B2 tokens, sold them for BNB, and moved the proceeds across several blockchains, directing most of the traceable flow into NEAR's privacy-oriented service layer.

The use of multiple routes and confidential deposits indicates that the effort to obscure the trail was planned in advance.

The main lesson is that a smart contract is only as secure as the authority that can change its logic.

In this case, the funds did not disappear into a single mixer. They moved through four blockchains and into a privacy-oriented service layer. Investigators could trace the deposits into that layer, but not the ultimate recipient. This once again demonstrates how difficult asset recovery becomes after such a withdrawal. The cost of securing privileged keys is negligible compared with the price of an exploit.