# Still Built on Trust: What a Basic On-Chain Check Reveals About Binance After the $6.3 Billion Hack

*Karaptic Research · Oleg · November 4, 2026*

## It started with an empty spreadsheet

On October 29, 2026, Binance lost about $6.3 billion. The largest crypto theft on record. The first explanation was a compromised laptop of a DevOps engineer, and within hours the internet had a story about a North Korean spy to go with it. Let's leave that one to the Bond films.

I keep some of my own money on Binance. So I did what Binance has told its users to do since FTX: I went to check. I opened the Proof of Reserves page and downloaded the address file for the latest snapshot, October 31.

It was a spreadsheet with a header row. Coin, network, address, balance, height, custodian. Nothing under it.

I tried the previous snapshot. Empty. And the one before. Empty. The newest file that actually had addresses in it was from January 1, 2025.

That is where the next two days went. No inside access, no special tools. A browser, a block explorer and a public RPC node. One click led to the next, and at the end of it was this:

**Binance can create any amount of Binance-Peg USDT, USDC, ETH, BTCB and fifteen other tokens, at any moment, with a single signature.** Nothing in the contracts stops it. No cap, no delay, no second signer. The only limits are Binance's internal policies and whoever controls that signature. I did not just read this in the code. I simulated it: a mint of one billion tokens from that address goes through.

Before anything else, two things to be clear about.

First, Binance has been paying. It pledged to cover every dollar. By its own account it had replenished about 90% of the affected assets by October 31, using its SAFU fund, its Futures Insurance Fund and company money, and about 95% by November 2. It says ten assets, including BTC, ETH, USDT and USDC, are fully backed 1:1, and that the remainder is mostly tokens outside the top ten. These are Binance's statements; I did not verify them independently. As far as I can tell, customers did not lose money. Sources: Binance updates of [October 31](https://www.binance.com/en/square/post/383244799724069) and [November 2](https://www.binance.com/en/square/post/383927782377840).

Second, compensation and verifiability are different guarantees. Binance can make users whole quickly, and appears to be doing so. That tells a user nothing about what limits the creation of tokens, the upgrade of their contracts or the movement of their collateral. That is what I looked at, and where users still have to trust the company's internal rules.

After FTX, Ankr, Gala and Bybit, the question is simple. What actually stands between the largest exchange in the world and someone printing money? In every part I could check, the answer was the same: trust.

## Summary

Five days after the hack, Binance's pegged-token system on BNB Chain still rests on single externally owned accounts (EOAs), plain keys rather than contracts with rules. One of them can mint, without any on-chain limit, 19 Binance-Peg tokens. In USDT, USDC and ETH alone those tokens represent more than $11.9 billion.

Every claim below comes from public contract calls, public explorers and Binance's own disclosure pages. Every one can be reproduced with the addresses in the appendix.

What the check found:

- **Mint authority.** EOA `0xF68a…f62d` is the owner of 19 Binance-Peg tokens on BNB Chain, including 9.18 billion USDT, 1.59 billion USDC, 65,301 BTCB and 505,000 ETH. Ownership passed to it from Binance: Deployer 2 in September 2020, and the address has never changed. A simulated mint of one billion tokens from it succeeds. Its last mint was on October 28, 2026, the day before the hack.
- **Upgrade authority.** Ten of the 21 tokens I examined, USDC among them, are upgradeable proxies. A second EOA, `0xd2f9…d6c4`, can replace their code entirely. It was funded by the mint key.
- **Collateral.** More than $10.2 billion of declared collateral (9,184,997,801 USDT and 454,999 ETH) sits on one EOA on Ethereum. The USDT backing matches the BNB Chain supply almost to the dollar. The ETH figures do not reconcile from public data.
- **The hacked wallet.** Binance 14 no longer carries the attacker's EIP-7702 delegation. The same address is still signing, and about six hours after the theft it swept leftovers to Binance: Cold Wallet 20.
- **Disclosure.** Proof of Reserves address files for every snapshot after January 2025 that I downloaded contained a header row and no addresses. They were still empty when I re-checked on November 3, after Binance announced its latest proof was complete. That concerns the files, not the proof itself.

The two findings connect. The mint contract allows a billion tokens to be created without proving that matching collateral exists. Keeping supply in line with reserves is a Binance procedure, not a rule in the code. That is exactly why independent reconciliation matters. Binance invited its users to verify. When I tried the public route, the address files came back empty. The verification Binance advertised and the result available to me did not match.

This does not show that Binance has issued unbacked tokens. It shows that, today, the public cannot confirm from code or from the published address files that it has not.

In one sentence: my checks identify concentrated on-chain authority and gaps in publicly reproducible reconciliation. They do not establish compromised keys, inadequate off-chain controls, or present undercollateralization.

The architecture in one picture:

| Key | Type | What it can do |
| --- | --- | --- |
| Mint key `0xF68a…f62d` | plain EOA, address unchanged since Sep 2020 | mint any amount of 19 Binance-Peg tokens |
| Proxy admin `0xd2f9…d6c4` | plain EOA, funded by the mint key | replace the code of 10 tokens |
| Collateral wallet `0x47ac…D503` | plain EOA on Ethereum | move 9.18B USDT and 454,999 ETH of declared backing |

The first two control the tokens directly. The third backs them only by Binance's promise. None of the three is a multisig or a timelock on-chain.

## What happened on October 29

On the evening of October 29, 2026, attackers moved about $6.36 billion out of Binance wallets across ten blockchains, most of it within roughly 20 minutes, according to [TRM Labs](https://securityweek.com/6-billion-binance-hack-bears-hallmarks-of-north-koreas-tradertraitor). Binance puts the impact at about $6.3 billion. That is roughly four times the $1.5 billion Bybit theft of February 2025.

Binance's preliminary account is short. A compromised DevOps engineer's laptop gave the attacker access to a service container, from which it submitted unauthorized withdrawal transactions. Binance says it found no evidence that wallet private keys leaked ([The Record](https://therecord.media/binance-hit-by-record-6-billion-crypto-hack)). Co-CEO Richard Teng called the attack complex and multi-stage. A later update said the laptop was one of several entry points.

The on-chain record fills in the mechanics. The attack address was funded through Tornado Cash on October 28. On October 29 it deployed a contract and submitted a single transaction carrying 50 EIP-7702 authorizations for the hot wallet Binance 14, one for each nonce from 18,914,775 to 18,914,824, because the attacker did not know the wallet's live nonce ([CryptoTicker](https://cryptoticker.io/en/binance-hack-on-chain-analysis/)). One matched. Binance 14 was delegated to the attacker's contract and, about three minutes later, sent out 167,464 ETH and 63 tokens, including 1.615 billion USDT.

One detail matters for everything that follows. An EIP-7702 authorization can only be signed with the private key of the account being delegated. So the delegation required a valid authorization for Binance 14. Binance says it found no evidence of private-key leakage. Abuse of its signing infrastructure is one possible explanation, but the full signing path has not been publicly established.

About $3 billion has been frozen, much of it by Tether and Circle. TRM Labs and Chainalysis attribute the theft with high confidence to TraderTraitor, the North Korean unit the FBI blamed for Bybit. Chainalysis says its strongest evidence was seeing Binance funds [commingle in real time](https://decrypt.co/382224/trm-and-chainalysis-tie-6-4b-binance-hack-to-north-koreas-tradertraitor) with proceeds of the September Bitget theft. As of October 30 no government had confirmed the attribution. Binance has pledged to cover all losses and has not yet published a full root cause.

## How I checked

Two days, nothing a user cannot reach. I read contract state directly from public RPC nodes for BNB Chain and Ethereum, at BNB Chain block 131,453,648 and Ethereum block 26,335,069 on November 3, 2026, with simulations at BNB Chain block 131,503,659. I read verified source code and event logs on BscScan and Etherscan. I compared the results with Binance's Proof of Reserves and Proof of Collateral for B-Tokens pages.

For each contract I followed the first steps of a standard smart-contract audit: identify the owner, establish whether the owner is a contract with its own rules or a plain key, check whether supply can be created and whether a cap or delay applies, and check whether the code can be replaced and by whom.

One rule for myself. A statement is reported as fact only where the chain proves it: an owner returned by the contract, code read in full, a balance at a given block, a simulated call. Where a conclusion depends on interpretation, I say so. Where it depends on information only Binance has, I name the gap instead of guessing.

### The trail

The January 1, 2025 file, the last one with data, had 784 rows, 273 addresses, 34 assets. The hacked wallet, Binance 14, was in it with 273,160 ETH and 1.24 billion USDT. So it was part of the official reserve, not some forgotten side wallet.

I opened the first address in the list, Ceffu 9 on BNB Chain, held by Binance's custodian Ceffu. In January 2025 it held roughly $125 million to $130 million across 14 assets. In November 2026 BscScan valued it at about $8.3 million. Between March and early May 2026 roughly $590 million flowed in and $630 million flowed out. An operational wallet, not cold storage.

Its history was full of junk tokens and fake transfers. More on that in the side note. Under the noise was one real transaction that mattered. At 02:02 UTC on October 30, six hours into the incident, Ceffu 9 sent 453.61 Binance-Peg ETH to Ceffu: Custody Hot Wallet 2. That wallet is an EOA holding about 526,398 BNB and $129 million in tokens.

The token in that transfer was Binance-Peg ETH. So I opened its contract and read the code. The `mint` function answered to one owner. `owner()` returned an EOA that had minted XLM the day before the hack. I called the same function on 20 more Binance-Peg contracts. The same address came back 18 more times. Ten of the contracts turned out to be proxies with an administrator of their own. Binance's Proof of Collateral page led me to the collateral wallet, and the event logs to the ownership history.

Each step took minutes. None needed anything but a browser. That is the uncomfortable part.

## Finding 1: one key mints 19 tokens, and its address has not changed since 2020

Binance-Peg tokens (Binance calls them B-Tokens) are BEP-20 versions of other assets on BNB Chain. Binance says each one is backed 1:1 by the original asset, held in its reserve wallets. The contracts enforce none of that. The backing is a promise; the minting is code.

I called `owner()` and `getOwner()` on 21 of the largest Binance-Peg contracts. Nineteen return the same address, `0xF68a4b64162906efF0fF6aE34E2bB1Cd42FEf62d`.

| Token | Supply on BNB Chain | Contract |
| --- | --- | --- |
| USDT (BSC-USD) | 9,184,991,740 | fixed code |
| USDC | 1,588,999,877 | upgradeable proxy |
| ETH | 505,000 | fixed code |
| BTCB | 65,301 | fixed code |
| DOGE | 2,564,000,000 | upgradeable proxy |
| ADA | 451,907,178 | fixed code |
| XRP | 325,800,000 | fixed code |
| SHIB | 9.21 trillion | upgradeable proxy |
| XLM | 53,380,000 | upgradeable proxy |
| MATIC | 21,931,517 | upgradeable proxy |
| DOT | 16,000,000 | fixed code |
| FIL | 15,010,000 | upgradeable proxy |
| LINK | 9,000,000 | fixed code |
| UNI | 6,760,000 | upgradeable proxy |
| ATOM | 2,499,994 | fixed code |
| AVAX | 2,000,000 | upgradeable proxy |
| ETC | 949,833 | upgradeable proxy |
| LTC | 745,000 | fixed code |
| BCH | 96,500 | fixed code |

Supply read with `totalSupply()` at BNB Chain block 131,453,648, rounded to the unit.

Of the 21 contracts checked, 19 share this owner: 10 with fixed code and 9 upgradeable proxies. Binance-Peg SOL is also a proxy but has a different owner, `0xa6ca…d2aa`. Binance-Peg TRX follows a different pattern, and I found no comparable mint function in it.

**The owner is a plain key.** The address holds no code, so it is an EOA, not a multisig or a timelock contract. Rules such as "two of three signers" or "wait 48 hours" cannot be attached to an EOA on-chain. It has sent 2,189 transactions and carries no EIP-7702 delegation.

**Minting has no limit.** I read the verified source of Binance-Peg ETH (`0x2170…933F8`) in full. Its `mint(uint256 amount)` function checks one thing: that the caller is the owner. No cap, no rate limit, no delay, no second approval. New tokens are created to the owner's own address. The contract has no pause and no blacklist, so in the code as currently written, tokens minted by whoever holds the key cannot be frozen at the contract level.

**I tested it without sending anything.** Reading code shows what a contract should do. A simulation shows what it would do right now. I used `eth_estimateGas`, which runs a call against current chain state and reports whether it would succeed, without broadcasting anything.

- `mint(1)` from `0xF68a…f62d` succeeds on all 19 tokens.
- The same call on Binance-Peg SOL, whose owner is different, reverts with "Ownable: caller is not the owner". So the check is real, not a call that passes everywhere.
- A mint of 10²⁷ base units, one billion tokens at 18 decimals, from the owner succeeds for ETH, USDT, USDC and BTCB at BNB Chain block 131,503,659. From an unrelated address it reverts. One billion BTCB against a supply of 65,301. That is what "no cap" means in practice.
- All nine proxies owned by `0xF68a…f62d` return `mintable() = true`.
- None of the 19 bytecodes contains the common selectors for `pause()` or for the usual blacklist functions.

**The owner address is the one Binance set six years ago.** The contract's event log holds exactly two `OwnershipTransferred` events. At block 326,031 the contract was created with owner `0x88eF…0566`, the address BscScan labels Binance: Deployer 2. Seventy-five blocks later, at block 326,106 in September 2020, ownership moved to `0xF68a…f62d`. It has not moved since. The owner itself was funded by Binance: Deployer 8. That chain of custody is why I say with confidence that this address belongs to Binance. An unchanged address does not mean unchanged protection: the MPC shares, participants, hardware and approval rules behind it may all have changed.

**The authority is in active use.** On October 28, 2026, the day before the theft, it minted Binance-Peg XLM at block 130,278,345 and about 100 blocks later sent 10,000,000 XLM, worth about $1.63 million, to `0x80b9…60f7`. Recent, regular use. That alone does not show whether signing happens online, offline, or through a separate MPC or HSM setup.

Together, USDT, USDC and ETH on this list account for more than $11.9 billion at an ETH price of about $2,280. BTCB, XRP, DOGE, ADA and the rest come on top.

### Why it matters

This one key decides how much Binance-Peg USDT, USDC, ETH and BTCB exist on BNB Chain. Tokens it mints land on its own address and are immediately spendable. Protocols that accept these tokens cannot tell a newly minted one from any other. The current token code has no freeze function, so stopping a bad mint would depend on other measures, such as a proxy upgrade where one exists, or a chain halt.

On October 29 a Binance hot wallet produced a valid authorization that Binance did not intend, by a path that has not been made public. If a comparable bypass of controls were possible for the mint address, the result would not be a drained wallet. It would be new money.

### What I do not know

An EOA on-chain can still be well protected off-chain. The key may be split across an MPC cluster with several approvers, and mints may be capped by internal policy. None of that is visible, and I do not assume it is missing.

I also do not know why the owner address has not changed since 2020, or whether the protection behind it has. On-chain, rotation is a single `transferOwnership` call. Off-chain, it may touch custody tooling, accounting, reconciliation and the systems that process deposits and withdrawals. There may be good reasons to keep it. The open questions:

- Is this key held in MPC or HSMs, and what approval threshold does a mint require?
- Is there an internal limit on how much can be minted per day, and who can override it?
- Does the signing system involved on October 29 also serve this key, or a sibling of it?
- Has the policy around this key been reviewed since October 29?

### What would fix it

No new token contracts needed. Ownership of a fixed-code token like Binance-Peg ETH can be moved from a key to a contract. That owner contract could be an on-chain multisig with a published threshold. It could also be a minter contract that enforces a daily cap, a delay on large mints, or a check against published reserves before each mint. Any of these turns an unlimited power into a bounded one, enforced by code anyone can read. Changing the address at the same time costs one transaction.

## Finding 2: a second key can rewrite ten tokens

Ten Binance-Peg contracts are not tokens in the usual sense. They are thin proxies that forward every call to a separate implementation contract: USDC, DOGE, XLM, UNI, SHIB, SOL, FIL, AVAX, MATIC and ETC. Reading the standard EIP-1967 storage slots, all ten point to the same implementation, `0xba5f…b5c`, and name the same administrator, `0xd2f93484f2D319194cBa95C5171B18C1d8cfD6C4`.

The administrator of a proxy does not need to mint anything. It can replace the implementation with code of its choosing, which means it can change every rule of the token at once: who may mint, who may move whose balance, whether transfers work at all. This is the exact path used in the Ankr exploit of December 2022, covered below.

The administrator is also an EOA. It holds no code, has sent 175 transactions and was funded six years ago by `0xF68a…f62d`, the mint key from Finding 1. BscScan labels both addresses as Binance. Its last outgoing transaction was 246 days ago, a burn of Binance-Peg BUSD, so this key is used far less often than the mint key. It still holds about $13.3 million in tokens.

The current implementation, `BEP20TokenImplementation`, has the same shape as the ETH contract. `mint` requires the owner and a `_mintable` flag, which is on for all of these proxies. No cap, no pause, no blacklist. For nine of the ten proxies the owner is again `0xF68a…f62d`. For Binance-Peg SOL the owner is a different EOA, `0xa6ca…d2aa`.

### Why it matters

An upgrade key is broader than a mint key. With it, the rules themselves can change: a new implementation could mint without the owner, move balances, or block transfers. For USDC on BNB Chain, that is 1.59 billion tokens whose behaviour depends on what one address decides to deploy.

It is also the key people check least. It signs rarely, and an idle privileged account is easy to forget. Gala's minter account had been idle for about six months when it was taken over.

### What I do not know

- Is this administrator key kept offline, and who must approve an upgrade?
- Why do 10 tokens use upgradeable proxies while the other 10 use fixed code?
- Has an upgrade ever been made, and would Binance announce one in advance?

### What would fix it

The standard pattern is to set the proxy admin to a timelock contract controlled by a multisig. A 48 to 72 hour delay means every upgrade is visible on-chain before it takes effect, so integrators, monitors and Binance itself can react. Where upgradeability is no longer needed, the admin can be renounced, freezing the code permanently.

## Finding 3: the collateral is visible, concentrated, and not fully reconciled

Binance publishes a separate [Proof of Collateral for B-Tokens](https://www.binance.com/en/land/transparency_of_funds) page. It says Binance has minted 199 tokens and lists, for each, the wrapped supply and the addresses holding the original asset. Unlike the Proof of Reserves exports, this page does show addresses. That makes part of the backing checkable. And part of it checks out.

**USDT matches.** The page names one Ethereum address for USDT collateral, `0x47ac0Fb4F2D84898e4D9E7b4DaB3C24507a6D503`. On November 3 it held 9,184,997,801 USDT. Binance-Peg USDT on BNB Chain had a supply of 9,184,991,740. The backing for the single largest B-Token covers its supply, with about 6,000 USDT to spare. Credit where it is due.

**Ten billion dollars sit on one plain key.** The same address also holds 454,999 ETH, about $1.04 billion, and 9,000,000 LINK. Together more than $10.2 billion. Like the mint and upgrade keys, it is an EOA: no code, 97 transactions sent. One signature moves all of it.

**ETH does not reconcile.** In the version of the page I captured on November 3, ETH collateral is listed as 454,999 ETH on Ethereum and 499 ETH on BNB Chain, about 455,500 in total. Wrapped ETH is listed as 483,563 BEP-20 plus 1,935 BEP-2, about 485,500. The page nonetheless shows a ratio of 100%. On-chain, `totalSupply()` of Binance-Peg ETH is 505,000. The gap is 30,000 ETH on the page's own numbers and about 49,500 ETH against the chain, roughly $68 million to $113 million.

There are innocent explanations. The page may count only tokens in circulation, excluding those still held in Binance's own wallets, as its "Circulation Model" link suggests. It may also aggregate collateral from addresses I did not see. I am not claiming Binance-Peg ETH is under-collateralized. I am saying a user cannot confirm it is fully collateralized from public data, and I invite Binance to publish the reconciliation.

**USDC is close but not exact.** The page lists 1,583,020,054 USDC of collateral against 1,582,625,124 wrapped. On-chain supply on November 3 was 1,588,999,877, about 6 million higher. This may simply reflect when the page was last updated. I did not independently read the USDC collateral address.

**BUSD is now backed by a different stablecoin.** The page lists 226,668,736 USD1 as collateral for Binance-Peg BUSD. Holders of a token called BUSD are relying on USD1.

This is not the first time the backing has been questioned. In January 2023 Binance acknowledged to Bloomberg that it had [mistakenly kept collateral for some B-Tokens in the same wallet as customer funds](https://www.bnnbloomberg.ca/binance-acknowledges-storing-user-funds-with-collateral-in-error-1.1874091.amp.html), Binance 8. The same month, ChainArgos found that about $1 billion of Binance-Peg USDC had at times been [publicly unbacked](https://dc.fortune.com/2023/01/18/binance-admits-to-further-management-issues-with-stablecoin-assets). Binance replied that assets on the exchange are always fully collateralized.

### Why it matters

The backing of a Binance-Peg token is the only thing that makes it worth its peg, and nothing in the token contract checks it. Supply is created by one key on BNB Chain. Collateral is held by another key on Ethereum. The two are tied together only by Binance's bookkeeping and a web page.

The USDT result shows the system can work exactly as promised. It also shows the size of the bet. More than $10 billion depends on one Ethereum address whose single signature can move all of it.

### What I do not know

- How does the Circulation Model count supply, and does it explain the ETH gap of 30,000 to 49,500 ETH?
- When is the Proof of Collateral page updated, and is the USDC difference of about 6 million a timing effect?
- Is the $10.2 billion collateral wallet controlled by MPC with a threshold, and is it separate from the systems that sign for hot wallets?
- Why is Binance-Peg BUSD now collateralized with USD1, and when did that change?

### What would fix it

A per-token reconciliation that a script can check: on-chain supply, amounts excluded by the circulation model with their addresses, and collateral addresses with balances at the same block. Collateral split across several cold wallets behind on-chain multisigs. For the largest tokens, an on-chain proof-of-reserve feed checked by the minter would make the 1:1 promise part of the code rather than a page.

## Finding 4: the hacked wallet is closed, but the same address still signs

Binance 14, `0x28C6c06298d514Db089934071355E5743bf21d60`, was one of Binance's main Ethereum hot wallets. In the January 1, 2025 reserve list it held 273,160 ETH and 1.24 billion USDT.

**The attacker's delegation is gone.** On November 3 the address returned empty code. An active EIP-7702 delegation would show as a short code pointer to the delegate contract, so the delegation has been revoked or overwritten. Its balance was 0.8 ETH.

**Binance still controls the address.** Its nonce stood at 18,915,339, 515 higher than the last nonce in the attacker's authorization batch. Under EIP-7702 a valid authorization also increments the nonce, so this is a nonce difference, not an exact transaction count. Hundreds of outgoing transactions were sent around October 30, and the ones I opened go to Binance. At 02:11 UTC on October 30, for example, Binance 14 sent 17,443,550 RSR to Binance: Cold Wallet 20, `0xF977…aceC`, itself one of the largest addresses in the January 2025 reserve list. Many of these sweeps failed and were retried.

The timing lines up across wallets. At 02:02 UTC on October 30 Ceffu 9 moved 453.61 Binance-Peg ETH to Ceffu: Custody Hot Wallet 2, and dozens of other tokens the same night. About six hours after the theft began, Binance and its custodian were evacuating hot wallets into addresses they consider safer.

That is a reasonable incident response. Binance says it found no evidence that the key behind Binance 14 leaked, and the address is still in use. Where exactly the controls failed has not been publicly established.

Binance has also announced a concrete change. It says it [updated the Proof of Reserves address list with a batch of newly generated wallet addresses](https://www.binance.com/en/square/post/383492275644204) and that all withdrawals are now processed through them. Beyond that, it describes "multiple preventive measures" and security assessments without technical detail. New withdrawal addresses mean new keys on the withdrawal path. They do not, on their own, tell us what changed in the system that decides what those keys sign. The mint key and the $10 billion collateral key also depend on some signing setup, and Binance does not disclose how it is separated from the one involved on October 29.

### Why it matters

If, as Binance says, no key leaked, keeping the key is not by itself a mistake. It moves the question to the layer that decides what gets signed, and every Binance key that moves money depends on such a layer in some form. Until Binance explains what changed there, users cannot judge whether the same path is still open for other wallets.

It also matters that Binance 14 held 1.24 billion USDT and 273,160 ETH. The amount kept in a single hot wallet is a policy choice. TRM's count of about 20 minutes for most of the $6.36 billion suggests that, whatever withdrawal limits existed, they did not slow this one down.

### What I do not know

- What exactly changed in the signing system after October 29?
- Were there per-wallet or per-hour withdrawal limits on Binance 14, and why did they not trigger?
- Was the EIP-7702 authorization type allowed by the signing policy, and is it blocked now?
- How much does Binance now keep in a single hot wallet?

### What would fix it

A full public post-mortem would answer most of these. On the technical side the fixes are well known: velocity limits that halt a wallet when outflows exceed a threshold, a signing policy that rejects transaction types the business never uses, and smaller hot wallets topped up from cold storage.

## Finding 5: the reserve address lists stop at January 2025

Binance's [Proof of Reserves](https://www.binance.com/en/proof-of-reserves) page has two halves. Liabilities are proved cryptographically: user balances go into a Merkle tree, and a zk-SNARK shows the total is computed correctly with no negative balances. Assets are shown as on-chain wallet balances, with a button to download every address behind them.

The liability half is good engineering, though it cannot show that every user was included. The asset half only works if the addresses can be checked. The address file for the October 31, 2026 snapshot contained one header row and nothing else. So did every other snapshot I tried after January 2025, December 2025 included. The most recent file with data was the January 1, 2025 snapshot.

Binance says the current list is available to users who log in and open the verification page. An empty public download may be a technical fault rather than a decision. What I can say is narrower: during my November 2–3 checks, the public downloads for every sampled snapshot after January 2025 returned header-only files. I cannot say from this how long they have been in that state.

The reserve ratios are worth a look too. In the October 31 snapshot, two days after the theft, ETH stood at 100.00%: 3,654,921.842 ETH on-chain against 3,654,919.15 ETH owed to users, a buffer of about 2.7 ETH. USDT also stood at 100.00%, with a buffer of about six dollars on $29.5 billion. The reported reserve perimeter shows little excess over reported customer balances. That does not measure Binance's total capacity to absorb losses; it has said it set aside more than $6.34 billion of company funds for this incident.

For reproducibility: the October 31 file I received, `PR31OCT26.xlsx`, is 3,527 bytes with SHA-256 `c057c88bda87ac5e72959a70a91def03c84320999739dd72d80ddfed96cc888b`, one sheet, header row only. The January 1, 2025 file, `PR01JAN25.xlsx`, is 42,061 bytes with SHA-256 `28271c47e1046d696f77fc49f9c7a1ef88c52b3e7e5bdf6f1ec29aed901201a1`. I did not run Binance's zk verifier myself, and an empty address file says nothing about whether the zk proof exists.

### Why it matters

A reserve ratio is only as good as the list of addresses behind it. Without the list, "100%" is Binance's statement about itself. With the list, anyone can check it in an afternoon, which is how I confirmed the USDT collateral in Finding 3. Proof of Reserves was introduced after FTX precisely to replace "trust us" with "check us". An empty file brings back the first.

And it matters most here, for tokens whose contracts do not check reserves at all.

### What I do not know

- Are the files empty on purpose, empty by error, or available only to logged-in users?
- Why do the public address lists stop after the January 1, 2025 snapshot?
- Does Binance plan to hold a buffer above 100% after the hack?

### What would fix it

Publish the full address list for every snapshot, without a login, in a machine-readable format. Pair it with the block height of each balance so the totals can be recomputed. An independent attestation of the liability side, which zk-SNARKs alone cannot give, would complete the picture.

## A side note: someone is fishing in the custodian's history

Smaller issue, but it shows how exposed operational wallets are. Ceffu 9, `0x0843…4083` on BNB Chain, is one of the custody addresses in Binance's January 2025 reserve file. Its token history is full of things Ceffu never did.

**Junk tokens.** Mass "multisend" airdrops drop worthless tokens into the wallet, 16,331.99 at a time, with names like 币安金库 ("Binance vault") and CZ人生 ("CZ life"). The point is visibility. A token that shows up in a famous wallet's holdings looks endorsed, and its creator can set any price in a tiny liquidity pool. Portfolio trackers multiply the balance by that price. The wallet looks richer than it is, and the scam looks more credible.

**Fake transfers out.** A token contract can emit a `Transfer` event naming any sender, without that sender's signature. Explorers then show a transfer "from Ceffu 9" that Ceffu never signed. One such entry shows 6,744,776.53 of a token rendered as U⁠S⁠DΤ, with invisible characters and a Greek tau, sent to `0xD3a2a95E…7CC4A1`.

**A lookalike address.** That recipient is a near-copy of `0xD3a22590…C4A1`, Ceffu: Custody Hot Wallet 2, the address that received about $187 million from Ceffu 9 between March and early May 2026. The first four and last four characters match. This is address poisoning: plant a convincing lookalike in the history and wait for an operator to copy the wrong line. In a 5,000-row export covering March to May 2026, 856 rows were tokens of this kind, including clones named BSC-USD and U5DT.

It is not theoretical. In May 2024 a victim sent 1,155 WBTC, about $70 million, to a poisoned lookalike address; the funds were later returned ([CertiK](https://www.certik.com/blog/vanity-address-and-address-poisoning)). I found targeting in Ceffu 9's history, not evidence that Ceffu ever sent money to the lookalike.

### Why it matters

Address poisoning is a numbers game. It costs a fraction of a cent per attempt on BNB Chain, and one success pays for millions of attempts. A custodian wallet that routinely sends tens of millions to a known counterparty is the ideal target. The 6.7 million fake "USDT" was sized to look like a routine transfer.

It also blinds outside observers. Anyone trying to audit an exchange wallet from its explorer page sees hundreds of fake entries and inflated valuations. Without filtering, the picture is wrong.

### What would fix it

On the operator side, an allow-list of destination addresses enforced by the signing system, so a lookalike is rejected however convincing it looks. On the observer side, tooling that separates transactions the wallet signed from events others emitted about it, and checks token contract addresses, receipts and balance changes, while keeping genuine incoming transfers. I applied a rough version of that filter by hand.

## Why a mint key is worse than a hot wallet

Binance 14 was a vault. Whoever controlled its signatures could take what was inside, and the loss was capped by its balance. A mint key is a printing press. Its own balance is irrelevant, because its power is to create tokens that the protocols accepting them on BNB Chain treat as real.

A newly minted Binance-Peg ETH is indistinguishable from any other. Same contract, ticker and price, and a DEX pool or lending market has no way to ask whether real ETH sits behind it. An attacker with the key would mint, then spread the tokens across pools, lending markets and bridges before anyone reacts. What limits the damage is not the contract but the depth of liquidity, lending caps, how fast monitors notice a large mint from the zero address, and whether BNB Chain's validators halt the network.

## We have seen this before

These precedents explain why the powers and verification gaps above deserve scrutiny. They are not evidence that Binance's mint or upgrade addresses have been compromised. The mechanisms differ, and attribution to a common attacker does not make them the same exploit.

| Date and case | What the record establishes | Connection to this review |
| --- | --- | --- |
| **May 7, 2019 — Binance** | Binance reported a theft of **7,000 BTC** from its hot wallet and covered it through SAFU. It said the withdrawal had passed its existing security checks before triggering alarms. [Binance's notice](https://www.binance.com/en/support/announcement/detail/360028031711). | **Finding 4 and compensation vs verifiability:** covering a loss protects customers financially; it does not by itself show how the withdrawal controls work. It does not establish that those controls are unchanged since 2019. |
| **October 2022 — BSC Token Hub** | A bridge exploit created **2 million BNB**, roughly **$570 million**. BNB Chain reported about **$100 million** moved off-chain before validators suspended the network. [BNB Chain's account](https://www.bnbchain.org/en/blog/bnb-chain-a-decentralized-response). | **Finding 1 and containment:** unauthorized supply can reach other systems before anyone intervenes. The entry point was a bridge-proof exploit, not the Binance-Peg mint owner. |
| **December 2022 — Ankr** | An attacker obtained a deployer key, changed the staking-token contract and minted **60 trillion aBNBc** in six transactions. Ankr estimated about **$5 million** of damage. [Ankr's report](https://www.ankr.com/blog/the-abnbc-token-report/). | **Finding 2:** privileged upgrade authority can introduce unrestricted minting. A mechanism precedent, not evidence of compromise in Binance's proxies. |
| **January 2023 — B-Token collateral** | Following public questions, Binance acknowledged collateral held outside dedicated wallets and timing mismatches, while maintaining its tokens were fully collateralized. [Binance's explanation and updates](https://www.binance.com/en/blog/ecosystem/7761334533351669941). | **Finding 3:** public reconciliation and internal backing claims are separate questions. |
| **May 3, 2024 — WBTC address poisoning** | A victim sent **1,155 WBTC**, about **$70 million**, to a lookalike address. The funds were later returned. [CertiK](https://www.certik.com/blog/vanity-address-and-address-poisoning). | **Side note:** poisoned histories have caused real large transfers. I found targeting at Ceffu 9, not a mistaken transfer. |
| **May 20, 2024 — Gala Games** | A compromised minter-role key created **5 billion GALA**. Gala contained it with a blocklist and later reported the return of sale proceeds. [Gala's incident report](https://news.gala.com/gala-games/incident-report-unauthorized-token-minting-blockchain-game-partners-inc/). | **Finding 1:** an authorized mint function can be abused without breaking the token contract. Gala's containment tool is absent from the Binance-Peg code I examined. |
| **February 21, 2025 — Bybit** | About **$1.5 billion** was stolen after a compromise of Safe's environment deceived Bybit's signers into approving a malicious transaction. [Bybit's statement](https://www.prnewswire.com/apac/news-releases/bybit-confirms-security-integrity-amid-safe-wallet-incident--no-compromise-in-infrastructure-302386279.html). | **Finding 4:** valid signatures can authorize an unintended operation. The developer environment belonged to Safe, a third party; this does not establish an identical path into Binance. |
| **April 18, 2026 — KelpDAO** | About **$292 million**, **116,500 rsETH**, released after attackers manipulated the infrastructure feeding a single-verifier cross-chain setup. Chainalysis links it to North Korea's Lazarus Group. [Chainalysis](https://www.chainalysis.com/blog/kelpdao-bridge-exploit-april-2026/). | **Findings 1 and 3:** a valid-looking on-chain release is not enough if the event meant to justify it never happened. A verifier failure, not an owner-key exploit. |
| **September 2026 — Bitget** | Chainalysis estimates the theft at **$387 million** and attributes it to North Korean actors. [Chainalysis](https://www.chainalysis.com/blog/387m-bitget-theft-2026/). | **Finding 4 and the wider threat:** another large custody incident one month before Binance, with linked fund flows. Not evidence of shared infrastructure or the same vulnerability. |

### Bybit is also a warning about my own fixes

Bybit already used a multisig. NCC Group's analysis describes a threshold of at least three signers and an altered Safe interface that misrepresented what they were approving. The required signatures were obtained; the approval process was deceived ([NCC Group](https://www.nccgroup.com/research/in-depth-technical-analysis-of-the-bybit-hack/)).

So a multisig is not a magic word. It makes a threshold visible and enforceable, but it does not guarantee independent judgment if every signer relies on the same compromised display or transaction-building service. Independent transaction decoding, separate verification paths, restricted permissions, mint limits and upgrade delays cover different parts of the problem. No single control replaces the others.

### A linked threat, not one identical exploit

Chainalysis reports that Binance funds commingled on-chain with funds from the Bitget theft, and cites that as evidence for its TraderTraitor attribution ([Chainalysis](https://www.chainalysis.com/blog/binance-exploit-latest-findings-and-response/)). That is Chainalysis's assessment, not an independent attribution by Karaptic. It supports a picture of repeated attacks by linked actors. It does not show that every incident in this table belongs to one campaign, or that Binance's mint and collateral systems are open to the October 29 entry point.

The recurring question is narrower and more useful: **what prevents an authorized action from producing an unauthorized economic result?** A token contract may accept a mint, a multisig may accept enough signatures, a bridge may accept a verified message. The missing safeguard can sit in the code, in the information supplied to it, or in the people and infrastructure authorizing it. My checks map those boundaries at Binance. They do not reconstruct every past breach.

## What I cannot see

An EOA on-chain is not necessarily one person with one key on one laptop. Exchanges of Binance's size usually sign through multi-party computation (MPC) or hardware security modules, with the key split across machines and policies that require several approvals, rate limits and anomaly checks. Binance may well have all of that behind `0xF68a…f62d`, `0xd2f9…d6c4` and `0x47ac…D503`.

The point is that none of it is visible or enforceable from outside. If those controls exist, they live in Binance's infrastructure, and October 29 showed that a valid authorization can be produced without Binance intending it. Binance says it found no evidence that the Binance 14 key leaked. If that holds, the attacker did not need the key. It needed a way to get it used.

I also did not test everything. I read the source of two implementations, the state of 21 contracts on BNB Chain, and simulated mints on 19 of them. I did not cover Binance-Peg tokens on other chains, the full list of 199 B-Tokens, or tokens such as TRX whose contracts follow a different pattern. The ETH and USDC reconciliation stays open until Binance explains its circulation model.

This review identifies a risk profile, not a breach. Nothing here shows that a Binance-Peg token is unbacked today, or that any of these keys is compromised.

## What Binance got right

A fair reading of the data has to include what worked.

- **Loss-coverage commitment and reported replenishment.** Binance pledged to cover all losses and reported replenishing about 95% of affected assets by November 2. Its October 31 snapshot shows ratios at or above 100% for the assets I looked at.
- **Fast containment.** Within about six hours Binance and Ceffu were sweeping hot wallets into cold and custody wallets. The attacker's EIP-7702 delegation on Binance 14 is gone.
- **Freezes.** About $3 billion was frozen with the help of Tether, Circle and other issuers, close to half of the total.
- **USDT backing checks out.** The largest Binance-Peg token is backed on-chain almost to the dollar, at an address Binance itself publishes.
- **Real cryptography on liabilities.** The zk-SNARK proof of user balances is more than most exchanges offer.
- **A collateral page with addresses.** Proof of Collateral for B-Tokens names its addresses, which is what made Finding 3 possible.

None of this contradicts the findings. It shows Binance has the people and the tools to do this well. Which makes it stranger that the base layer still relies on keys the chain does not constrain.

## Open questions for Binance

I would rather ask than assume. These are the questions public data cannot answer. If Binance responds, I will publish the answer.

1. How are the mint key `0xF68a…f62d`, the proxy admin `0xd2f9…d6c4` and the collateral wallet `0x47ac…D503` protected off-chain? Is each behind MPC or HSMs, and what approval threshold applies?
2. Are these keys served by the same signing system involved on October 29, or by a separate one?
3. Is there an internal cap on Binance-Peg minting per day or per transaction?
4. The owner address of Binance-Peg ETH has not changed since September 2020. Have the protections behind it been rotated, and is a change of address planned?
5. Would Binance consider moving ownership and proxy administration to on-chain multisigs and timelocks?
6. How does the circulation model reconcile Binance-Peg ETH: 505,000 on-chain against about 455,500 of listed collateral?
7. Why do public Proof of Reserves address files after January 2025 download empty?
8. What changed in the signing system after October 29, and when will a full root cause be published?

## What would change the picture

In a smart-contract audit, an owner who can mint without limit or replace the code is commonly flagged as a significant centralization risk, and "administrator can drain remaining funds" is a common high-severity finding. How severe it is depends on the guarantees a project makes and its context. Binance-Peg tokens carry that profile at a scale no DeFi protocol does. None of the fixes is exotic:

1. **Put ownership behind an on-chain multisig.** Move `owner` of every Binance-Peg token, and `admin` of every proxy, from EOAs to multisig contracts whose threshold anyone can read. MPC can stay underneath; the chain should enforce the minimum. And as Bybit showed, signers need independent ways to verify what they are actually signing.
2. **Add a timelock to upgrades.** A 48 to 72 hour delay on proxy upgrades gives monitors, integrators and Binance itself time to react to an upgrade nobody intended.
3. **Cap and rate-limit minting in the contract.** A per-day mint ceiling turns a compromised key from an unlimited loss into a bounded one. A reserve check at mint time would go further.
4. **Separate keys and change addresses.** One address should not own 19 tokens worth more than $11.9 billion in USDT, USDC and ETH alone.
5. **Split the collateral.** More than $10.2 billion on one EOA is a single point of failure, whatever sits behind it off-chain.
6. **Restore public reserve addresses and publish the reconciliation.** Monthly address lists, per-token collateral matching on-chain supply, and an explanation of the circulation model.
7. **Publish the root cause of October 29.** What changed in the signing system, and whether the same system signs for the mint, upgrade and collateral keys.

## And then Binance sent me an email

While I was finishing this, Binance sent its users an update. About 90% of affected assets replenished. Ten tokens fully backed 1:1. A new Proof of Reserves snapshot taken on October 31, and a zero-knowledge proof that takes 40 to 50 hours to build. Once it is ready, the email said, holders of those ten tokens will be able to check for themselves that their assets are backed at least 1:1. On November 2 Binance [announced the proof was done](https://www.binance.com/en/square/post/383927782377840). A day earlier it had said it [added new wallet addresses to the reserve list](https://www.binance.com/en/square/post/383492275644204).

So I did exactly what the email asked. On the evening of November 3, UTC, I went back to the Proof of Reserves page and downloaded the October 31 address file again.

3,527 bytes. A header row. Coin, network, address, balance, height, custodian. Nothing under it. The other files I re-checked: same.

You have got to be kidding me.

To be precise about what this is. It is not proof that the reserves are missing, and it is not proof that the zk proof does not exist. It is one public download button, as I used it, returning an empty file, at the exact moment Binance was inviting people to verify. Maybe the list only shows up after login. Maybe it is a bug. Either way, the invitation to check and the result I got did not match.

The scale of that gap is what stays with me. On one side, serious cryptography to prove user balances. On the other, the power to mint enormous amounts of tokens without the contract itself checking any collateral. And the public download through which you are supposed to check all of it returns an empty file.

The fixes are not a research problem. A mint cap, a delay on large operations, separated authorities, an address export that works. These are ordinary engineering measures. I will be fair, though: "easy to write" and "safe to roll out on a live exchange" are different things. Minting has to stay in sync with redemptions, emergency operations have to keep working, the migration has to be tested, and an upgrade must not become a way around the new limits. That explains why it is hard. It does not explain why, at this scale, there are still no visible limits at all.

What bothers me most is the asymmetry. As a user I can see exactly how large the powers are. I cannot see the rules that are supposed to stop them from being abused. Maybe those internal rules are very strong. But I am asked to take that on trust, precisely where a mistake is measured in billions.

So the real question of this article is simple. Why, with this much at stake, are some of the most basic limits still not enforced by publicly verifiable code? "We covered the losses" is not an answer to that question.

And that is the whole article in one example. Binance is paying. Binance has some of the best engineers in the industry. The USDT collateral matches to the dollar. And still, a key that can print a billion tokens answers to one address that has not changed since 2020, the collateral for ten billion dollars moves with one signature, and the public route to check it gives you an empty spreadsheet.

Blockchains are trust too, but trust that rests on math standing in the way. In the parts of Binance I checked, that math is not being used yet. A colossus can stand on clay feet for a long time. It is still worth knowing which parts are clay.

If Binance answers the questions above, I will publish the answer here.

---

## Appendix: reproduce every claim

Reads were taken on November 3, 2026, at BNB Chain block 131,453,648 and Ethereum block 26,335,069; mint simulations at BNB Chain block 131,503,659. An empty result from `eth_getCode` means the address is an EOA with no EIP-7702 delegation.

### Key addresses

| What | Address | Chain | Check |
| --- | --- | --- | --- |
| Mint key, owner of 19 tokens | `0xF68a4b64162906efF0fF6aE34E2bB1Cd42FEf62d` | BNB Chain | `owner()` / `getOwner()` on any token below; `eth_getCode` empty |
| Proxy admin, 10 tokens | `0xd2f93484f2D319194cBa95C5171B18C1d8cfD6C4` | BNB Chain | EIP-1967 admin slot on any proxy; `eth_getCode` empty |
| Proxy implementation | `0xba5fe23f8a3a24bed3236f05f2fcf35fd0bf0b5c` | BNB Chain | verified source `BEP20TokenImplementation` |
| Collateral wallet | `0x47ac0Fb4F2D84898e4D9E7b4DaB3C24507a6D503` | Ethereum | `balanceOf` on USDT: 9,184,997,801; ETH balance 454,999; `eth_getCode` empty |
| Binance 14 | `0x28C6c06298d514Db089934071355E5743bf21d60` | Ethereum | `eth_getCode` empty; nonce 18,915,339 |
| Binance: Cold Wallet 20 | `0xF977814e90dA44bFA03b6295A0616a897441aceC` | Ethereum | receives RSR from Binance 14 at 02:11 UTC, Oct 30 |
| Ceffu 9 | `0x08439901c2bB071cd0812eD329675C9657434083` | BNB Chain | listed as Ceffu custody in the Jan 1, 2025 reserve file |
| Ceffu: Custody Hot Wallet 2 | `0xD3a22590f8243f8E83Ac230D1842C9Af0404C4A1` | BNB Chain | receives 453.61 ETH from Ceffu 9 |
| Poisoning lookalike | `0xD3a2a95E952A18Cf71c348ec33683696E57CC4A1` | BNB Chain | fake "USDT" entry in Ceffu 9's history |

### All 21 contracts checked

"Mint sim" is `eth_estimateGas` of `mint(1)` (selector `0xa0712d68`) sent from `0xF68a…f62d`.

| Token | Contract | Type | Owner | Mint sim |
| --- | --- | --- | --- | --- |
| USDT | `0x55d398326f99059fF775485246999027B3197955` | fixed | `0xF68a…f62d` | succeeds |
| USDC | `0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d` | proxy | `0xF68a…f62d` | succeeds |
| ETH | `0x2170Ed0880ac9A755fd29B2688956BD959F933F8` | fixed | `0xF68a…f62d` | succeeds |
| BTCB | `0x7130d2A12B9BCbFAe4f2634d864A1Ee1Ce3Ead9c` | fixed | `0xF68a…f62d` | succeeds |
| XRP | `0x1D2F0da169ceB9fC7B3144628dB156f3F6c60dBE` | fixed | `0xF68a…f62d` | succeeds |
| DOGE | `0xbA2aE424d960c26247Dd6c32edC70B295c744C43` | proxy | `0xF68a…f62d` | succeeds |
| ADA | `0x3EE2200Efb3400fAbB9AacF31297cBdD1d435D47` | fixed | `0xF68a…f62d` | succeeds |
| DOT | `0x7083609fCE4d1d8Dc0C979AAb8c869Ea2C873402` | fixed | `0xF68a…f62d` | succeeds |
| LINK | `0xF8A0BF9cF54Bb92F17374d9e9A321E6a111a51bD` | fixed | `0xF68a…f62d` | succeeds |
| LTC | `0x4338665CBB7B2485A8855A139b75D5e34AB0DB94` | fixed | `0xF68a…f62d` | succeeds |
| ATOM | `0x0Eb3a705fc54725037CC9e008bDede697f62F335` | fixed | `0xF68a…f62d` | succeeds |
| BCH | `0x8fF795a6F4D97E7887C79beA79aba5cc76444aDf` | fixed | `0xF68a…f62d` | succeeds |
| XLM | `0x43C934A845205F0b514417d757d7235B8f53f1B9` | proxy | `0xF68a…f62d` | succeeds |
| UNI | `0xBf5140A22578168FD562DCcF235E5D43A02ce9B1` | proxy | `0xF68a…f62d` | succeeds |
| SHIB | `0x2859e4544C4bB03966803b044A93563Bd2D0DD4D` | proxy | `0xF68a…f62d` | succeeds |
| FIL | `0x0D8Ce2A99Bb6e3B7Db580eD848240e4a0F9aE153` | proxy | `0xF68a…f62d` | succeeds |
| AVAX | `0x1CE0c2827e2eF14D5C4f29a091d735A204794041` | proxy | `0xF68a…f62d` | succeeds |
| MATIC | `0xCC42724C6683B7E57334c4E856f4c9965ED682bD` | proxy | `0xF68a…f62d` | succeeds |
| ETC | `0x3d6545b08693daE087E957cb1180ee38B9e3c25E` | proxy | `0xF68a…f62d` | succeeds |
| SOL | `0x570A5D26f7765Ecb712C0924E4De545B89fD43dF` | proxy | `0xa6ca…d2aa` | reverts: not the owner |
| TRX | `0xCE7de646e7208a4Ef112cb6ed5038FA6cC6b12e3` | other | not found | reverts |

The one-billion-token simulation used 10²⁷ base units for ETH, USDT, USDC and BTCB; from the owner it succeeds, from an unrelated address it reverts.

Proxy storage slots (EIP-1967): admin `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`, implementation `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`. Selectors: `owner()` `0x8da5cb5b`, `getOwner()` `0x893d20e8`, `totalSupply()` `0x18160ddd`, `mintable()` `0x4bf365df`. `OwnershipTransferred` topic: `0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0`.

### Transactions referenced

| What | Chain | Hash or locator |
| --- | --- | --- |
| Attacker address, funded via Tornado Cash | Ethereum | `0x7c8601d4645b93cea45f71e118a729332e6b5ca0` |
| Attack sequence, per Beosin | Ethereum | `0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b`, `0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3` |
| Binance 14 sends RSR to Cold Wallet 20, Oct 30 02:11 UTC | Ethereum | `0x972a3db97d3feeb9fd22f9176b40e06ebefaeb868dba6c52f95215536052da66` |
| Ceffu 9 sends 453.61 ETH to Custody Hot Wallet 2, Oct 30 02:02 UTC | BNB Chain | `0x375bb46ffce103b4ab338cc5410cff47642b7dfd5bf8ccd2da2a4ec1b91706a9` |
| Mint key sends 10,000,000 XLM, Oct 28 12:07 UTC | BNB Chain | `0x0b481bc5d1d57a90e78519884cde8af02b80c433a3d5bd267c771d13d4b43162` |
| Binance-Peg ETH ownership history | BNB Chain | `OwnershipTransferred` events at blocks 326,031 and 326,106 |

Reserve files: `PR31OCT26.xlsx`, 3,527 bytes, SHA-256 `c057c88bda87ac5e72959a70a91def03c84320999739dd72d80ddfed96cc888b`, header only. `PR01JAN25.xlsx`, 42,061 bytes, SHA-256 `28271c47e1046d696f77fc49f9c7a1ef88c52b3e7e5bdf6f1ec29aed901201a1`, 784 rows.

## Sources

On-chain data: public RPC nodes for BNB Chain and Ethereum, BscScan and Etherscan, read November 2–3, 2026.

Binance disclosures:

- [Binance — Proof of Reserves](https://www.binance.com/en/proof-of-reserves)
- [Binance — Transparency of Funds and Proof of Collateral for B-Tokens](https://www.binance.com/en/land/transparency_of_funds)
- [Binance — update of October 31, 2026](https://www.binance.com/en/square/post/383244799724069)
- [Binance — new wallet addresses and withdrawals, November 1, 2026](https://www.binance.com/en/square/post/383492275644204)
- [Binance — update of November 2, 2026](https://www.binance.com/en/square/post/383927782377840)
- [Binance — Security Breach Update (May 2019)](https://www.binance.com/en/support/announcement/detail/360028031711)
- [Binance — How We Back Binance-Peg BUSD, with subsequent updates](https://www.binance.com/en/blog/ecosystem/7761334533351669941)

The October 29 theft:

- [SecurityWeek — $6 Billion Binance Hack Bears Hallmarks of North Korea's TraderTraitor](https://securityweek.com/6-billion-binance-hack-bears-hallmarks-of-north-koreas-tradertraitor)
- [The Record — Binance hit by record $6.3 billion crypto hack](https://therecord.media/binance-hit-by-record-6-billion-crypto-hack)
- [Euronews — How the Binance hack happened and who was behind it](https://www.euronews.com/2026/10/30/how-the-binance-hack-happened-and-who-was-behind-it)
- [CryptoTicker — Binance hack on-chain analysis](https://cryptoticker.io/en/binance-hack-on-chain-analysis/)
- [SOCRadar — Binance hack: $6.3B hot wallet theft](https://socradar.io/blog/binance-hack-6-3b-hot-wallet-theft/)
- [Decrypt — TRM and Chainalysis tie $6.4B Binance hack to North Korea's TraderTraitor](https://decrypt.co/382224/trm-and-chainalysis-tie-6-4b-binance-hack-to-north-koreas-tradertraitor)
- [Chainalysis — The Binance Hack: Tracing the North Korea Link](https://www.chainalysis.com/blog/binance-exploit-latest-findings-and-response/)

Earlier questions about B-Token collateral:

- [Fortune — Binance admits to further management issues with stablecoin assets (January 2023)](https://dc.fortune.com/2023/01/18/binance-admits-to-further-management-issues-with-stablecoin-assets)
- [BNN Bloomberg — Binance acknowledges storing user funds with collateral in error (January 2023)](https://www.bnnbloomberg.ca/binance-acknowledges-storing-user-funds-with-collateral-in-error-1.1874091.amp.html)

Precedents:

- [BNB Chain — A Decentralized Response (October 2022)](https://www.bnbchain.org/en/blog/bnb-chain-a-decentralized-response)
- [Blockworks — BNB Chain bridge exploit (October 2022)](https://blockworks.com/news/binance-pauses-trading-of-native-token)
- [Ankr — The aBNBc token report](https://www.ankr.com/blog/the-abnbc-token-report/)
- [Rekt — Ankr & Helio (December 2022)](https://rekt.news/ankr-helio-rekt)
- [CertiK — Vanity Address and Address Poisoning](https://www.certik.com/blog/vanity-address-and-address-poisoning)
- [Gala — Incident Report: Unauthorized Token Minting](https://news.gala.com/gala-games/incident-report-unauthorized-token-minting-blockchain-game-partners-inc/)
- [Rekt — Gala Games (May 2024)](https://rekt.news/gala-games-rekt)
- [Bybit — Forensic Investigation Update (February 2025)](https://www.prnewswire.com/apac/news-releases/bybit-confirms-security-integrity-amid-safe-wallet-incident--no-compromise-in-infrastructure-302386279.html)
- [NCC Group — In-Depth Technical Analysis of the Bybit Hack](https://www.nccgroup.com/research/in-depth-technical-analysis-of-the-bybit-hack/)
- [Chainalysis — Inside the KelpDAO Bridge Exploit](https://www.chainalysis.com/blog/kelpdao-bridge-exploit-april-2026/)
- [Chainalysis — How AI Helped Investigators Trace the $387 Million Bitget Theft](https://www.chainalysis.com/blog/387m-bitget-theft-2026/)

*Karaptic Research publishes independent analysis. This article is not investment advice and does not allege wrongdoing by Binance or Ceffu.*