Beyond the Vault. How the Money Left.

The 30-second version

Protecting a chip is not the same as protecting your money. Three incidents disclosed over the past month pushed the problem to three places outside the vault: whose transaction data a wallet trusted, who could see the secret that rebuilds a wallet while it was on screen, and who could get a system to sign. The evidence differs from case to case, but together they say the same thing: asking where the key is kept is not enough.

1 · It starts with "speed up"

You send a bitcoin payment. It sits unconfirmed. Your wallet offers a button: pay a little more, speed it up.

In older versions of the Electrum wallet, that button could have you sign a payment to an attacker.

Electrum is a "light" wallet. It doesn't download the whole blockchain; it asks a server about pending transactions and, by design, trusts the answer. According to Electrum's October 24 security advisory, a malicious server could hold back the payment you had just sent and show your wallet a fake one paying the attacker. The fake transaction had no valid signature, and older versions didn't check. When you clicked "speed up," the wallet signed a valid new version of it, and the attacker's payment became real.

In the cases reported, the advisory says, the attacker's address was ground to match the last four characters of the real one, and the fake transaction carried zero fee, "presumably in hope of the user bumping its fee."

The new transaction's signature would verify. The recipient was still wrong. The wallet signed what the server showed it. Version 4.8.3 now checks signatures on pending transactions that spend from the wallet's own addresses; pending transactions paying to you are still not validated until they are mined. (Advisory)

A related problem reached an exchange's multisig wallet in February 2025. Bybit lost about $1.5 billion, which the FBI attributed to North Korea (FBI alert, Feb 26, 2025). Safe, the multisig provider Bybit used, said its preliminary finding was that "a compromised Safe{Wallet} developer machine" resulted in "the proposal of a disguised malicious transaction," and that external forensics found no vulnerability in Safe's smart contracts (Safe statement, Feb 28, 2025). The two mechanisms differ. What they share is narrower: the information or presentation before signing was exploited.

2 · The secret that rebuilds a wallet, seen on screen

A hardware wallet is designed so that the private keys controlling your funds are used only inside a secure chip and never leave the device. But there is a second secret: the 24-word recovery phrase shown during setup, which can rebuild the whole wallet on another device. Showing it and writing it down are part of the security boundary too.

According to Ledger's security lab, the Donjon, an implant was confirmed inside one affected device sold by CryptoBilis, a reseller in Southeast Asia. It sits inside the enclosure and reads what the screen shows. When the device displays the recovery phrase, the implant decodes the words and sends them out over a cellular connection using a provisioned eSIM. The Donjon says it "does not modify the Secure Element or the Ledger operating system, and it does not alter transactions or signatures." (Ledger Donjon, Oct 13)

So an intact chip doesn't mean the money is safe: whoever has the recovery phrase can rebuild the signing keys elsewhere. Ledger's Genuine Check verifies the chip's identity; Ledger's buying guide says the check "cannot detect unauthorized physical modifications to the hardware — such as spying implants — if the original Secure Element remains intact." (Guide, version accessed Oct 19)

3 · This time, the signature wasn't for a payment

The third case happened at an exchange's hot wallet.

At 04:20 Beijing time on October 30 (20:20 UTC, October 29), a transaction reached Binance's hot wallet "Binance 14" carrying 50 EIP-7702 authorizations, each signed with that wallet's own key and numbered in a consecutive run (Etherscan, authorization list). According to the authorization list and the transaction's state changes, the wallet's counter went from 18,914,809 to 18,914,810, an increase of one: of the 50 authorizations, only one took effect.

What matters is what that one authorization was. EIP-7702, added to Ethereum in 2025, lets an ordinary wallet point its execution to a piece of program code (EIP-7702 specification). What was signed was not a payment but an authorization over how the wallet operates. If that code lets an attacker call it, later movements of funds may no longer need the holder to approve each one. What this particular code allowed still has to be read from the contract and its call records; it is not a property of every EIP-7702 authorization.

What does Binance say? Its first notice said the incident may have started with a DevOps engineer's compromised laptop, which gave an attacker access to a service container where unauthorized withdrawal transactions were submitted, and that "we have found no evidence of any wallet private key leak." A second update, dated October 30, said the investigation had uncovered "additional points of breach," that it still had found no evidence of key leakage, and that affected authorizations had been revoked. (Binance, Oct 30)

The blockchain analytics firm TRM adds a piece: beyond Ethereum, Binance wallets on other chains moved funds through ordinary signed transfers. TRM observed that wallets on several chains, with different key types, produced valid signatures for the attacker, and judged that the most likely explanation involves manipulation of Binance's hot-wallet signing system. (TRM, Oct 29) That is an analytics firm's assessment, not Binance's conclusion.

Put together, one possible explanation is that the attacker didn't take the key out; they got the system that holds it to sign. That is our inference, not an established fact. And "no evidence of a leak" is not the same as "proven not to have leaked." Where the signatures came from still needs fuller technical evidence; Binance says it will publish a detailed technical post-mortem.

4 · Side by side

The three cases rest on different evidence and different mechanisms. The same outcome doesn't require the same mechanism; setting them side by side is what shows where each one broke. Three questions outside the vault come out of it:

1. What is being signed? Who supplied the transaction you see? Is it a payment, or an authorization? 2. Who has seen the secret that can sign? When, and on which screen, was the recovery phrase displayed? 3. Who can make it sign? Who can send requests to the signing system, and what kinds of things will it sign?

For ordinary holders, that comes down to a few habits:

• If you use Electrum, update to 4.8.3 or later. In any wallet, read the whole recipient address, not just its ending, and check the amount before you sign (Note 010). It stops some scams; it doesn't replace fixing the flaw.
• Buy hardware wallets from the maker or an authorized channel, and know that the Genuine Check verifies the chip, not the whole device (Note 003).
• When a signing request says "authorize," "delegate" or "approve," find out whether it is asking for one payment or for ongoing control.

The exchange's part of the chain is invisible to holders. All they can do is read what the exchange says afterward, and whether it brings evidence.

5 · What we don't know yet

• Where Binance's signatures came from. That needs fuller technical evidence; we've written it down as Inference 1 below, to be checked on schedule. In Update #2, posted at 03:58 Beijing time on October 31, Binance said it expected to share further technical findings in about 48 hours, provided they had been verified and disclosure would not compromise the ongoing investigation. Counted from that post, that is around 03:58 Beijing time on November 2: a conditional expectation, not an unconditional deadline for a full root-cause report.
• At what point the Ledger devices were altered. Ledger says its investigation is ongoing.
• These boundaries rest on security advisories, company statements and on-chain records, with different strengths of evidence. We discuss them on that basis and vouch for no one.

Compensation and withdrawals are a separate matter. Binance says it will cover all losses with company funds. On October 31 it reportedly said it had replaced about 90% of the stolen assets and planned to begin restoring withdrawals on November 1; it has published a reserve snapshot, and a full cryptographic proof that lets users verify their own balances is expected on November 3 (CoinDesk, Oct 31). Those disclosures concern restoring funds and withdrawals. They don't answer how the signatures were obtained.

One question for you: the last time you pressed "confirm," besides the address and the amount, did you check whether it was asking for a single payment or for control going forward? Tell us in the comments.

IKOL's calls · two testable inferences

These are IKOL's calls, to be checked in public when they come due. Resolution rules are in Appendix 3.

Appendix 1 · What's documented, what's our view

Appendix 2 · Sources

Discovery layer. IKOL's archive from Aug 5 to Nov 1, 2026, searched for Electrum, Ledger implant, hardware wallet, EIP-7702, hot wallet, Bitget/Bybit/Binance theft, private key, multisig and signing infrastructure: 158 items after de-duplicating titles (Aug 13, Sep 26, Oct 113, Nov 6). The 2025 Bybit case falls outside the archive window and is covered by the FBI alert and Safe's statement.

Appendix 3 · Resolution rules (frozen Nov 1, 2026, v4)

Inference 1 (deadline Mar 31, 2027; checked April 2027): Only Binance's own technical post-mortem or formal technical statement counts (website, official blog, official X; media reports do not). Two parts: (A) explicitly attributes the valid signatures on the Oct 30 authorizations to unauthorized use, manipulation or approval-bypass of its hot-wallet signing system ("signing system" includes systems built by Binance or supplied by a vendor and used to sign for its hot wallets); (B) explicitly states an investigative finding ruling out leakage of the Binance 14 key or of key shares sufficient to sign alone. A and B are each scored supported, contradicted or not testable. If a formal technical statement explicitly contradicts either, the compound inference is a miss; only both supported is a hit; otherwise the part results are kept. No publication before the deadline: technical parts not testable, plus the note "no qualifying technical disclosure seen by IKOL's deadline"; published but insufficient: "disclosed; technical parts still not testable." These labels do not judge Binance to be in breach or late. The inference tests whether official disclosure matches it, not whether the disclosure exhausts the true causes.

Inference 2 (deadline June 30, 2027; checked July 2027): All times UTC. Both the incident and the official statement must fall between Nov 1, 2026 and June 30, 2027; later disclosure does not count. Loss is the total taken without authorization at the time of the incident: the institution's own figure first; without one, at least two independent estimates are required (two outlets citing the same analytics firm count once), and all credible estimates from the pre-set sources must be at least $100M; if estimates straddle $100M and cannot be reconciled, record "pending" rather than using the lower one as a miss; keep all credible estimates and their sources; recoveries and compensation are not netted out. "Official statement" means the institution's notice, official account, or CEO/co-CEO public remarks, and must contain both: (a) no evidence of key leakage found, or keys did not leak / were not stolen; (b) transaction data forged, a signing or approval process exploited, or a system induced to sign. The latest formal statement or correction before the deadline governs; follow-ups on the same attack do not count again; Binance's October 2026 incident does not count. Pre-set search channels: institution websites and official X, CoinDesk, Cointelegraph, The Block, Reuters. None found: "miss under the stated public-evidence standard."

Appendix 4 · Notes

• Authorizations and the counter. The 50 authorizations carry nonces 18,914,775 to 18,914,824; Etherscan's authorization tab marks only 18,914,809 as valid, sorted by nonce, without showing the original list order. Under EIP-7702, each successfully processed authorization increments the account nonce; the state-change tab shows Binance 14's nonce going from 18,914,809 to 18,914,810 across the transaction, consistent with only one taking effect (on the same page, the sending address's nonce went 10 → 11, the normal increment for sending a transaction). Transaction time: 20:20:59 UTC, Oct 29, 2026. Binance's Update #2 says its hot wallets were compromised at around 20:05 UTC.
• The sending address. The address that sent this authorization transaction, 0x7C8601d4…5CA0, was funded with 0.1 ETH through Tornado Cash; its first on-chain activity (a contract creation) came about 18 hours before this transaction. That is the observation window for one address, not the preparation time for the whole attack (Note 013).
• Freezes. Tether froze more than 1.567 billion USDT and Circle more than 800 million USDC; Binance put the total frozen on-chain at about $3 billion. ETH and bitcoin that were moved have no comparable issuer freeze. Frozen is not recovered (Note 013).
• Ledger figures. On-chain analytics firm Bitquery estimated on Oct 16 that $102.0 million was taken from 335 wallets across six chains; wallets are not victims or devices, and how each wallet was exposed was not established case by case (Note 003).
• Attribution. The FBI attributed both the Bybit case (Feb 26, 2025) and the Binance case (Oct 31, 2026) to activity it calls TraderTraitor. The FBI's Binance alert does not address where the signatures came from and cannot settle whether keys leaked.
• Bitget (Sep 24, 2026, about $351.6M). According to investingLive's account of its preliminary investigation, attackers breached a backend wallet system and forged transfer data that entered the normal signing process; key leakage was ruled out. Its CEO said in a livestream that North Korea was likely involved but not confirmed. The original was not independently re-checked; background to Inference 2 only.
• Dates. Oct 24 is when Electrum published the advisory and fix; attacks happened earlier (first report Oct 11). The Ledger implant was confirmed Oct 10 and announced Oct 13. "The past month" refers to disclosure dates.

IKOL · AI-assisted research, human-edited. We label what is documented, reported and inferred — and publish our corrections. Not investment advice.