A wallet can send a transaction with a valid signature even when the business that owns it never intended to make that payment. That distinction sits at the centre of the question “how was Binance hacked?” following the exchange's October 2026 security incident.
The available evidence points investigators towards the systems that authorise transactions. It does not establish that Ethereum's entire network was breached, or that every Binance customer disclosed a password. For Indian developers and small teams handling crypto treasury operations, understanding those boundaries is more useful than treating every security layer as the same thing.
Published 31 October 2026. Incident analysis below uses findings released on 29–30 October; a final root-cause report was not available in the material checked.
How Was Binance Hacked? Start With What Investigators Observed
TRM Labs' investigation describes an Ethereum wallet being delegated to attacker-controlled code, alongside signed transfers from Binance wallets on other blockchains. Its assessment points to compromised hot-wallet signing infrastructure. That is an analytical conclusion from transaction evidence, rather than a completed forensic account of the initial intrusion.
Crystal Intelligence independently examined the Ethereum delegation and described a signing path as a plausible explanation. Its analysis distinguishes access to a signing service from possession of the underlying private key. Binance's preliminary account referred to a potentially compromised employee laptop and access to a service container; those early findings should remain qualified.
These observations describe different stages: entry into a company's environment, access to authorisation systems and execution on a blockchain. Evidence about the last stage does not automatically reveal every step that preceded it.
A Hot Wallet Is Part of an Operating System
TRM defines a hot wallet as an internet-connected wallet used by an exchange to process customer withdrawals. In an exchange, that public wallet also sits behind an operating process: a withdrawal request is checked, approved and eventually turned into a signed transaction.
Consider a hypothetical Indian business paying contractors from a crypto treasury. The finance manager's approval, the software's permission checks and the final cryptographic signature perform different jobs. A payment may satisfy the blockchain's signature rules while violating the company's spending policy. Calling it “valid on-chain” does not make it an authorised business payment.
This is an explanation of the trust boundaries, not a claim that Binance used that particular workflow. The precise internal architecture remains a matter for its investigation.
What EIP-7702 Changes on Ethereum
Ethereum's EIP-7702 specification lets an ordinary externally owned account authorise delegation to code. The account keeps its address, while subsequent execution can use the delegated code. The standard supports useful features such as batching and sponsored transactions, but delegation is a security-sensitive permission.
Its security section warns that poorly implemented delegated code can give an attacker extensive control. A familiar address is therefore insufficient evidence that the account's behaviour remains unchanged. A reviewer also needs to understand which code has been authorised and what that code is allowed to do.
For a non-developer, the practical distinction is between approving a single action and approving a mechanism that can affect later actions. An interface should make that difference understandable before anyone signs. A request labelled “verification” deserves scrutiny if its actual permission changes account execution.
Why the Ethereum Explanation Does Not Cover Every Chain
The reported incident involved wallets on multiple networks. EIP-7702 describes an Ethereum mechanism; it cannot, by itself, explain a Bitcoin transfer. TRM's broader signing-infrastructure assessment considers the activity across chains rather than assuming one Ethereum transaction accounts for the whole incident.
A useful way to read future reports is to ask two questions. What happened on the specific blockchain being discussed? What evidence connects that event to the exchange's wider systems? An answer to the first question can be well supported while the second remains provisional.
Claims that “all blockchains were hacked” skip that distinction. Equally, identifying one delegated wallet does not prove that investigators have resolved every unauthorised transfer.
Questions a Treasury Team Can Take to Its Security Review
The following are review questions for a team's own qualified security staff, rather than a reconstruction of Binance's controls:
- Can the approval screen explain the actual transaction or delegation, rather than displaying only an opaque signature request?
- Which people and services can request signatures, and how is their access reviewed?
- Can an unexpected permission change trigger an alert independently of a large balance movement?
- Does the team know who can pause activity and preserve evidence when something looks wrong?
A small team should be able to put an owner beside each question. If everyone assumes a wallet provider, developer or finance colleague handles it, that responsibility needs to be clarified before the next routine payment. This is a governance exercise, not an instruction to experiment on a live wallet.
What Account Holders Should Take Away
An exchange infrastructure incident and an individual account takeover require different investigations. Strong account authentication remains useful, but it does not replace a custodian's withdrawal controls. Our explainer on secure account recovery alongside strong login examines that separate account-access boundary.
Ordinary users should not run unofficial scripts or sign unfamiliar permissions to “repair” exchange infrastructure. Wait for instructions obtained through independently opened official channels. Understanding the incident should reduce the pressure to act on a technical-looking message, rather than create a new reason to sign one.
Conclusion
The strongest available explanation concerns unauthorised use of wallet-signing capabilities, with Ethereum delegation forming one observed part of the incident. Keep that evidence separate from an unproven final root cause. For teams, the useful next step is reviewing who can authorise what, and how an unexpected authorisation becomes visible.
Illustrative cryptocurrency photograph: Art Rachen / Unsplash, Unsplash License. Not an image of Binance's systems or the attack.
