Binance hot wallet hack: key custody lessons
Binance hack 2026: about US$6.3B left Binance's hot wallets. What is confirmed, how one signature beat other controls, and key custody lessons for boards.
At 20:05 UTC on Thursday 29 October 2026, five accounts on the XRP Ledger that analysts label as Binance’s began sending 233 million XRP to a single address. Over the next 20 minutes, large sums left wallets labelled as Binance’s on Solana, Bitcoin and Tron. At 20:20:59 one Ethereum transaction handed a Binance hot wallet, which Etherscan labels Binance 14, to code the attacker had deployed more than four hours earlier. Three minutes later that wallet began to empty. Binance says it lost about US$6.3 billion, which would make it the largest theft of crypto on record.
This analysis of the Binance hot wallet hack is for boards and security and risk leaders at Australian organisations that hold digital assets, use a custodian or exchange, or give AI agents authority to sign transactions. It sets out what is confirmed, explains the cryptography in plain English, reviews Binance’s public statements, and maps the lessons to CPS 234, CPS 230, the Essential Eight and NIST CSF 2.0.
Binance’s statements and withdrawal status are current as of 7.12 am AEDT on Sunday 1 November 2026 (20:12 UTC on 31 October). Analysts’ figures were last checked on the evening of 31 October (AEDT), and regulators’ pages between then and the morning of 1 November. At that point Binance had not published a root cause, its withdrawals had not resumed, and no government had attributed the theft. The story is moving, and this post will be updated as Binance publishes its findings. This is not financial advice.
Update, 1 November 2026: Binance said on 31 October that it had replenished 90% of the stolen assets and remained on track to reopen withdrawals on Sunday 1 November. It has promised technical findings within about 48 hours of its 30 October update, which is about 19:30 UTC on 1 November, and a full Proof of Reserves proof by 3 November (UTC). When each lands, this note will say what changed.
The short answer
- What happened: Binance dates the compromise of its hot wallets to about 20:05 UTC on 29 October. Within about 20 minutes, funds left wallets labelled as Binance’s on the XRP Ledger, Solana, Bitcoin and Tron, and Binance hot wallets on Ethereum. On Ethereum, one wallet was handed to attacker code through an EIP-7702 delegation and stayed that way for 3 hours 49 minutes. A second Ethereum wallet, and the wallets on the other chains, sent ordinary signed transfers.
- How much: Binance says about US$6.3B. Itemised analyst tallies run from US$6.36B (TRM Labs) to US$6.43B (Elliptic). No readable source supports a figure of US$8 billion.
- What Binance says about the cause: it has found no evidence that a wallet private key leaked. Its first theory, a compromised DevOps engineer’s laptop, was followed more than six hours later by “additional points of breach”. It has promised technical findings within about 48 hours of its 30 October update.
- What was frozen: Tether and Circle froze about US$2.58B in stablecoins on-chain. Independent counts of everything frozen or seized run from about US$2.7B to US$2.85B. Binance says about US$3B, without itemising it.
- Who did it: TRM Labs and Chainalysis attribute the theft to North Korea’s TraderTraitor group with high confidence, and Elliptic calls that likely. Their evidence overlaps. No government had attributed it, and Binance had named no one.
- What Binance has done since: on 31 October it said it had replenished 90% of the stolen assets from its SAFU emergency fund, part of a futures insurance fund and its own treasury, and that users will not bear the loss. Withdrawals were still off, with a restart targeted for Sunday 1 November.
- What a board should do: ask for evidence on a short list of key custody questions. The checklist below sets them out.
Verified timeline
All times are UTC. AEDT, the time in Sydney and Melbourne, is UTC plus 11 hours, so 20:05 UTC on 29 October was 7.05 am on Friday 30 October. Brisbane and the Gold Coast do not use daylight saving, so subtract an hour from AEDT there. “Confirmed on-chain” means the transaction can be read on the blockchain. Ownership of the non-Ethereum sending wallets rests on analysts’ labels.
| When (UTC) | What happened | Status | Source |
|---|---|---|---|
| 28 Oct 07:39 to 29 Oct 18:20 | The wallet later used to run the attack is funded by withdrawals from the Tornado Cash mixer, some routed through a second wallet | Confirmed on-chain | Etherscan, operator address |
| 29 Oct 13:51 to 16:47 | Two rehearsals on throwaway wallets; the attack contract is deployed at 15:59 | Confirmed on-chain | Etherscan, delegate contract |
| 29 Oct 20:05 | Five XRP Ledger payments totalling 233.46 million XRP begin. Binance later dates the compromise to “around 2026-10-29 20:05 (UTC)” | Confirmed on-chain; confirmed by Binance | XRP Ledger explorer, Binance Update 2 |
| 29 Oct 20:10 to 20:22 | About 970,000 SOL, 18,270 BTC and 612.7 million USDT on Tron leave wallets labelled as Binance’s | Transfers confirmed on-chain; labels reported | TRM Labs, mempool.space |
| 29 Oct 20:20:59 | One transaction delegates Binance 14 to the attacker’s contract. It carries 50 signed authorisations, and one takes effect | Confirmed on-chain | Etherscan, delegation transaction |
| 29 Oct 20:24:23 | The first sweep from Binance 14, worth about US$2.5B. Twenty-four seconds later a second wallet, Binance 16, sends 28,005.6 ETH and eight tokens in ordinary transfers | Confirmed on-chain | Etherscan, first sweep |
| 29 Oct 20:32 | The earliest public alert we found on X: “Unconfirmed, but possibly massive binance hack.” | Confirmed as a post | Spreek on X |
| 29 Oct 20:41 and 20:59 | A further 823 million USDC is pulled out through Binance 14 | Confirmed on-chain | Etherscan, USDC transfer |
| 29 Oct 21:01 and 21:04 | Tether, then Circle, blacklist the address collecting the stolen funds, 37 and 41 minutes after the first sweep | Confirmed on-chain | Etherscan, collector address |
| 29 Oct 21:15 to 21:29 | Binance’s first post goes through four versions in 14 minutes. The second adds “we have not confirmed any impact to user funds”. The fourth says “User funds are completely safe.” | Confirmed (posts) | Binance, version 2, Binance, version 4 |
| 29 Oct 21:44 | A third sweep sends a further 200.40 million USDT to the collector, which Tether has already frozen | Confirmed on-chain | Etherscan, third sweep |
| 29 Oct 22:15 and 22:22 | Binance first implies, then Binance co-founder Yi He states, that withdrawals are disabled | Confirmed (posts) | Binance, Yi He |
| 29 Oct 22:39 | The attacker still calls Binance 14 (122 token transfers), 24 minutes after the first notice that withdrawals were off | Confirmed on-chain | Etherscan, transaction |
| 29 Oct about 23:05 | A second wave hits Binance wallets on Avalanche and Polygon | Reported | TRM Labs |
| 30 Oct 00:08 | Arbitrum’s Security Council moves 74.56 million ARB and 8,425 ETH out of the attacker’s reach | Confirmed (council statement and chain) | Arbitrum forum |
| 30 Oct 00:10:35 | A transaction from Binance 14 clears the delegation, 3 hours 49 minutes 36 seconds after it began | Confirmed on-chain | Etherscan, revocation |
| 30 Oct 00:17 to 08:00 | ZachXBT, TRM Labs, Chainalysis and Elliptic link the theft to North Korea-linked actors | Confirmed as statements | Elliptic, Chainalysis |
| 30 Oct 02:23 | Binance’s first formal announcement: a compromised DevOps laptop “may” be involved, and it found “no evidence of any wallet private key leak” | Confirmed (announcement) | Binance Update 1 |
| 30 Oct 08:47 | Binance says its investigation “has uncovered additional points of breach” | Confirmed (post) | Binance |
| 30 Oct 14:33 | Binance co-CEO Richard Teng posts a video transcript: the delegation “did not pass through our normal approval controls” | Confirmed (post) | Richard Teng |
| 30 Oct 19:33 | Binance Update 2: about US$6.3B lost, more than US$6.34B set aside, technical findings in about 48 hours, a phased withdrawal restart in about 34 hours | Confirmed (announcement) | Binance Update 2 |
| 31 Oct 14:24 | Binance Recovery Update 3: 90% of the stolen assets replenished from its SAFU emergency fund, a futures insurance fund and its treasury; withdrawals “on track” to reopen on Sunday 1 November; a full Proof of Reserves proof expected by 3 November (UTC) | Confirmed (announcement) | Binance Recovery Update 3 |
| 31 Oct 20:12 | Our read of Binance’s public wallet status data still shows withdrawals off on every network. No root cause has been published, and the FBI has issued no notice about the theft | Confirmed (our check) | Binance wallet status data; FBI IC3 notices |
The first two rows show the attack was prepared more than a day ahead. Once it started, Binance 14 went from delegation to first sweep in 3 minutes 24 seconds.
How much was stolen, and why you may have seen US$8 billion
Binance says it lost about US$6.3B. The itemised analyst tallies are close to that: TRM Labs counts US$6.36B, Elliptic US$6.43B, and Chainalysis about US$6.4B. Arkham’s page repeats TRM’s figures, so it is not an independent count. Earlier numbers, from US$2.5B to US$5.7B, were partial counts taken while funds were still moving.
If you saw a figure near US$8 billion, the most likely source is currency. ABC News printed the US$6.3B figure as A$8.9 billion, a straight conversion to Australian dollars. The only US$8 billion in the coverage we could read is in Fortune, which mentions “reports on X” of a range from US$2 billion to US$8 billion without naming any analyst. CNN’s analysis says more than US$6 billion. We could not read the body of the New York Times article, but its headline and feed summaries say US$6.3 billion or around US$6 billion.
Some readers have also seen US$1.7B. In the posts we found, that figure is a net shortfall calculation or an early frozen amount, not a loss total.
The cryptography in plain English
Hot wallets and cold wallets
Whoever can use a wallet’s key can move what it holds. A hot wallet keeps its key on internet-connected systems, so an exchange can pay withdrawals in seconds. A cold wallet keeps its key offline, which is slower and much safer. Hong Kong’s securities regulator, for example, has required licensed trading platforms to hold 98% of client assets in cold storage, calling hot wallets “highly vulnerable” to hacking. Teng says most Binance user assets sit in cold wallets. The risk sits in the hot tier, and in whatever signs the transfers that refill it.
Keys and signing
On Ethereum, an ordinary account is controlled by one private key. To move funds, the key signs a transaction, and the network checks only that the signature is valid. It does not ask whether the exchange’s approval workflow was followed or the destination was on an allowlist. All of those controls live off-chain, in the exchange’s own signing service. That is why private key management is as much about who or what can ask for a signature as about where the key is stored.
What an EIP-7702 delegation is
Since Ethereum’s Pectra upgrade on 7 May 2025, an ordinary account can sign a message that says, in effect, “run this contract’s code as if it were me”. Anyone can submit that message to the network and pay the fee. From then on, calls to the account run the chosen code, with full access to the account’s balance, until another signed message replaces or clears it. It is useful for batching payments or letting someone else pay fees, but the standard itself warns there is “no safe way” for applications to ask users to sign one.
In his video, Teng described EIP-7702 as “a known multi-signature protocol”. It is not: it lets one key hand control of its account to a contract. In 2025 the trading firm Wintermute reported that most early delegations pointed to copies of one sweeper contract used to drain wallets whose keys had already leaked. Later research also documents phishing for delegation signatures.
Why a valid signature beats every other control
Destination allowlists, transfer limits and multi-person approvals all inspect transfers. A signature that changes who or what controls the wallet sits upstream of them. Once Binance 14 was delegated, the attacker no longer needed the key for each withdrawal: the account ran the attacker’s code.
Binance says it has found no evidence that a private key leaked, which is not the same as nothing being compromised. TRM Labs, Elliptic and the vendor Blockaid read the on-chain evidence as the attacker getting Binance’s own signing system to sign. That is their analysis, not Binance’s account, and it fits the ordinary transfers on the XRP Ledger, Solana, Bitcoin and Tron. For the same reason, calling this a crypto key compromise in the sense of a stolen key goes further than the evidence.
Multisig and MPC
A multisig wallet is a contract that needs signatures from several keyholders, say three of five. MPC (multi-party computation) splits a key so it never exists in one place, and the parties compute a signature together. A hardware security module (HSM) is a vault for a key: it stops the key being copied, but it still signs whatever an authorised caller submits.
None of these settles what is being signed. Bybit lost about US$1.46B in February 2025 from a multisig wallet after its signers approved a transaction that was not what their screens showed. WazirX’s multisig wallet was also drained, though the cause is disputed. Binance has not published how its keys are generated, stored or used, so it is not known which of these it relies on.
Why stablecoins can be frozen and ETH and BTC cannot
USDT and USDC are issued by companies, Tether and Circle, whose token contracts include a blacklist the issuer controls. Ether and Bitcoin have no issuer, so no one can freeze them. That made the night a race. Tether blacklisted the attacker’s main collecting address 37 minutes after the first sweep, and Circle 41 minutes after. About US$729M in stolen stablecoins had moved on before the freezes, and by 30 October about US$3.2B in assets that cannot be frozen remained with the attacker. Arbitrum’s Security Council took a third path, an emergency action without a governance vote that moved assets on its network out of the attacker’s reach, and some in the industry have questioned that power.
How the failure happened
Binance has not published a root cause, so each point below separates what the sources show from what they do not. None of it is a finding that Binance lacked a control.
Key custody
What the sources show. Before 20:20:59, Binance 14 was an ordinary account with no code. The delegation was signed by its own key. A second Ethereum wallet, Binance 16, sent ordinary transfers, as did the wallets on the XRP Ledger, Solana, Bitcoin and Tron, and analysts report the same on other networks. Binance says it found no evidence of a key leak.
What they do not show. How Binance generates, stores or accesses its keys (HSM, MPC or cloud key management), or why Binance 14 was the only wallet delegated.
Signing policy and approvals
What the sources show. Teng says the delegation “did not pass through our normal approval controls”. Analysts say the attacker made Binance’s signing system sign, and that system produced valid transfers on other chains within about half an hour.
What they do not show. Whether Binance’s signing policy treated a delegation as a distinct type of request, or how an approval step was avoided.
Transaction simulation
What the sources show. Simulating a transaction before signing, and showing signers what it will do, is a known control, and a draft standard, ERC-7730, supports it. Blockaid says its engine classified the delegating transaction as malicious on sight and that its signing layer would have rejected it. Both are a vendor’s claims, and the second is a counterfactual.
What they do not show. Whether Binance simulated transactions before signing. No framework we reviewed has a direct control for transaction simulation.
Delegation allowlists
What the sources show. The contract Binance 14 was delegated to was created about four hours and 20 minutes earlier, from a wallet funded through Tornado Cash. The standard gives a delegated account a short, recognisable code marker. In our view, that makes an alert on any custody account gaining code practical to build.
What they do not show. Whether Binance had an allowlist of permitted delegation targets or a ban on delegation for custody accounts. The Essential Eight’s application control is not an equivalent: it allowlists programs, not contracts.
Monitoring and alerting
What the sources show. Blockaid says it flagged the drain within two minutes of the first sweep (a vendor claim). The earliest public alert we found came at 20:32, the first issuer freeze at 21:01, Binance’s first statement at 21:15, and the delegation was cleared at 00:10:35.
What they do not show. When Binance’s own systems detected the first outflow. The cautionary precedent is Ronin in 2022: with no monitoring of large outflows, six days passed before anyone noticed.
Separation of duties
What the sources show. Teng says the attack was “not carried out by one person”. In earlier cases separation of duties failed in practice: at Ronin the attacker reached five of nine validator keys because the quorum was not independent, and at Bybit signers saw something other than what they signed.
What they do not show. How duties are separated at Binance. NIST describes a two-person rule, and APRA’s CPG 234 lists, as a control, no single individual having knowledge of an entire key.
Confirmed, reported and unknown
Confirmed. The on-chain events in the timeline, including the 3 hour 49 minute delegation, the ordinary transfers on the XRP Ledger, Solana, Bitcoin and Tron, and the issuers’ blacklists. Binance’s own statements, including its edits and corrections.
Reported, not confirmed. That every non-Ethereum sending wallet belonged to Binance, which rests on analysts’ labels. The outflows on other networks such as Arbitrum, Avalanche and Polygon, including the second wave. The attribution to North Korea, which comes from private firms leaning largely on the same evidence: stolen funds mixed with those from an earlier North Korea-linked theft. Elliptic has since added a second basis, shared laundering services with three earlier thefts, which no one else has confirmed.
Unknown.
- The root cause, and what the “additional points of breach” are.
- The basis of Binance’s US$6.3B and US$3B figures.
- When the withdrawal pause took effect. On 30 October Binance said “The outflows ceased when we paused withdrawal service earlier”. The 22:39 call on Binance 14 came 24 minutes after its first notice that withdrawals were off, and Binance has not said when the pause took effect.
- Whether customer-backing assets were hit. CoinDesk reported that Binance 14 appears in Binance’s 1 October Proof of Reserves. Teng says Binance never uses customer funds. Binance took a new snapshot on 31 October and expects the full proof by 3 November, which will test both.
Noise. Early theories that the outflows were routine maintenance, a claim from an AI-compiled news site that hot wallet private keys were compromised, and the US$8 billion figure. No readable source says the attackers used AI to breach Binance. Chainalysis mentions automation only in the laundering, and Elliptic says whether AI agents are involved there “cannot be determined from the on-chain data”.
The public response: what worked and what did not
Every statement below has been checked against the on-chain record or the statement’s own edit history.
What worked
- Specific freezes. Paxos named the address and the exact amount it froze, 1,906.67 PAXG, which matches the chain to the digit. Tether and Circle blacklisted the attacker’s address within 41 minutes, and Circle’s stated amount matches the chain. Arbitrum’s forum post gave the mechanism, the address and the transaction.
- Public revision. Binance revised its own theory in public, saying its first finding was incomplete, rather than defending it.
- Clear statements from peers. Bybit, Kraken and Binance.US each said plainly whether they were affected, and ABC reported a similar note from the Australian exchange Swyftx.
What did not
- Safety before cause. At 21:29, with the cause unknown and the delegation still live, Binance replaced “we have not confirmed any impact to user funds” with “User funds are completely safe.” The careful line disappeared without explanation. The first formal announcement came almost six hours after the first sweep.
- Corrections without a clear trail. Binance said deposits were suspended, then corrected that about four hours later on X. Its announcement page was edited about nine hours after publication, with a dated note that it had been updated “to clarify deposits remain unaffected”, but no time and no record of the earlier wording. The US$3B frozen figure has never been itemised and sits above every independent count.
- Technical mislabels. A CEO video called EIP-7702 a multi-signature protocol, and the line that customer funds were never used sits uneasily with CoinDesk’s reading of the Proof of Reserves.
Lessons for incident response communication
- Do not assert safety before you know the cause. If you must reassure, say what you have checked and when.
- Keep one version of the truth. Use the same words on your website, social channels and through spokespeople, and when you correct something, say what changed and when.
- Define terms and itemise numbers. “Verified frozen”, “unaffected” and “covered” mean different things to different readers, and an unitemised figure invites doubt.
- Make promises time-bound, and keep them. Binance’s later updates set a findings deadline and a restart target, and its third update reported against the restart target and the Proof of Reserves snapshot. Whether both deadlines are met is still to be seen.
- Use correct technical terms. A wrong term from a CEO travels further than the correction.
- Know your clocks. For APRA-regulated entities, CPS 234 requires notice to APRA no later than 72 hours after becoming aware of a material information security incident, and CPS 230 sets 72 hours for a material operational risk incident and 24 hours where a critical operation is disrupted beyond tolerance. Under CPS 234, a material control weakness that will not be fixed in time must be notified within 10 business days.
The Australian angle: what applies, and what is a benchmark
Who is bound
APRA’s prudential standards bind APRA-regulated entities: banks, insurers and superannuation trustees. A crypto exchange is not one. For exchanges the binding regimes are AUSTRAC’s virtual asset service provider rules, which changed from 31 March 2026, and ASIC’s financial services regime, with a new digital asset platform regime under the Corporations Amendment (Digital Assets Framework) Act 2026 from April 2027. For everyone else, APRA CPS 234 and CPS 230 are a benchmark, and an APRA-regulated customer will often hold its custodian or exchange to them by contract.
Two traps. CPS 230 commenced on 1 July 2025, but APRA remade it in April 2026, and the text in force since 1 July 2026 has different paragraph numbers. And ASIC has deliberately declined to set detailed key management rules: its October 2026 consultation paper CP 392 calls prescriptive hot and cold wallet requirements “inconsistent with our principles-based and technology-neutral approach”. It points instead to Section F of Regulatory Guide 133, which says the security of private keys “is of critical importance” and prefers multi-signature or sharded signing to a single key.
Controls mapped to CPS 234, CPS 230, the Essential Eight and NIST CSF 2.0
CPS 230 references use the 2026 numbering. Our frameworks page explains how we map controls, and our posts on CPS 234 audit expectations and CPS 230 and AI tooling go further.
| Control theme | CPS 234 | CPS 230 (2026) | NIST CSF 2.0 | Essential Eight |
|---|---|---|---|---|
| Key custody | Paras 20 to 22: classify, protect, evaluate third parties. CPG 234 Attachment E on key management | Para 28: design and embed controls | No subcategory mentions keys; nearest PR.DS-01, PR.DS-02, PR.AA-01 | Not applicable |
| Signing policy | Para 21: controls to protect information assets | Paras 28 and 29: controls designed and tested | PR.AA-05: least privilege, separation of duties | Restrict administrative privileges, around the signer |
| Transaction simulation | No direct control | No direct control; para 29 nearest | No direct control; PR.DS-02 nearest | No equivalent |
| Delegation allowlists | No direct control | No direct control | No direct control; PR.AA-05 nearest | No equivalent |
| Monitoring and alerting | Paras 23 to 26: detect and respond to incidents | Para 31: incidents and near misses escalated | DE.CM and DE.AE categories | Privileged access events centrally logged (Maturity Level Two) |
| Separation of duties | Paras 27 to 31: independent testing. CPG 234 Attachment C: two-person rule for the most sensitive assets | Para 28: internal controls | PR.AA-05 | Just-in-time administration (Maturity Level Three) |
| Incident communication | Para 35: notify APRA within 72 hours | Paras 31 and 32: escalate, and notify APRA of material incidents within 72 hours | RS.CO: incident reporting and communication | Not applicable |
The Essential Eight needs a caveat. ASD says it is “designed to protect organisations’ internet-connected information technology networks” and that it “will not mitigate all cyber threats”. Several of its controls are specific to Windows and Microsoft Office, such as Credential Guard and Office macro settings. It covers the corporate network and administrator access around a signing system, not the keys, HSMs, MPC, on-chain controls or AI agents.
Non-human identities and AI agents holding keys
A signing service is a non-human identity: software with authority to move money. An AI agent with authority to sign or approve a transaction is another. The failure mode analysts describe at Binance, getting the signer to sign something it should not, is exactly the risk an agent carries if it can be steered into a signing tool call. To be clear, no source we could read says AI was involved in the Binance breach. The point is that the control problem is the same.
Australian regulators have already said this. APRA’s letter to industry of 30 April 2026 says identity and access management “have not yet adjusted to nonhuman actors such as AI agents”, and expects “strong privileged access management”. It is a letter, not a new standard: APRA is “not proposing to introduce additional requirements at this stage”. ASD’s guidance with CISA and other partners, Careful adoption of agentic AI services (1 May 2026), says to treat each agent as “a distinct principal”, replace static secrets with short-lived credentials, require just-in-time credentials for privileged actions and keep human approval for high-impact ones. NIST CSF 2.0 has no AI-agent subcategory; its hook is the word “services” in its identity subcategories.
We have written about delegation and authorisation for AI agents and tool authorisation in more depth.
If an agent or a service in your estate can request a signature, an independent test of whether it can be steered into signing something it should not is the fastest way to answer the board’s question. That is what our AI offensive security review does.
What Australian regulators and governments have said so far
We found no statement on the Binance theft from ASIC, AUSTRAC, ASD’s ACSC, APRA or Scamwatch, in checks between the evening of 31 October and the morning of 1 November (AEDT). That means none had been found, not that none exists.
No government had attributed the theft. The FBI said it is “aware of the incident”. A US Secret Service spokesperson told CNN its investigators are “working around the clock” with partners to trace and recover funds, but we found no primary Secret Service statement. Asked whether North Korea was responsible, President Trump said: “We don’t know”, and “We’re looking at that”. ABC reported that Swyftx found no evidence it was affected.
The questions your board will ask
Were we exposed? Only if you hold funds at Binance, or a custodian or exchange you use has comparable signing arrangements. Ask your providers directly, in writing.
Are our funds safe? Honouring balances is not the same as funds being untouched. Binance is honouring balances by drawing on its emergency fund, an insurance fund and its own treasury, and its full Proof of Reserves proof will show the result. Ask any provider you use which of the two it could promise, and from what.
How long would it take us to notice, and to stop signing? Binance’s wallet stayed delegated to the attacker’s contract for 3 hours 49 minutes. Ask for your own time to detect and time to revoke, measured in a test.
Who or what can ask our signers to sign, and can policy see what kind of request it is? This is the question that matters most. A signing policy that only understands transfers cannot stop a request that hands over control of the wallet.
Our post on reporting AI and technology risk to boards covers how to put this in front of a board.
A board checklist on key custody
Ten things to ask for evidence of
- A list of every key that can move money or change who controls a wallet, including keys held by services and AI agents, each with a named owner.
- A one-page custody design: where keys are generated, stored and used (HSM, MPC or cloud key management), and who or what can request a signature.
- A signing policy that covers every type of request, not only transfers: contract calls, approvals, delegations and raw messages.
- Pre-signing checks on high-value requests, such as simulation or clear signing, and a block on unknown delegation targets.
- A cap on what a hot wallet can hold and how much can leave in a window, and a tested refill process.
- Separation of duties that holds under compromise: no single laptop, container or service can both initiate and approve, and approvers sit on independent infrastructure.
- Monitoring of the chain and the signing path, with an alert on any custody account gaining code or a new delegation, and measured times to detect and revoke. See our post on just-in-time privileged access.
- A clear view of which assets can be frozen and which cannot, with pre-arranged contacts at issuers and law enforcement.
- A pre-approved holding statement that does not claim safety before the cause is known, a visible edit log, and the notification clocks if you are APRA-regulated.
- The same questions put in writing to your custodians and exchanges, under your service provider policy. Our third-party risk guide covers how.
How we can help
We don’t hold or move your keys. What most boards lack is a one-page answer to who or what can ask for a signature, and whether policy can see what it is signing. We are a cyber security practice based on the Gold Coast, working with boards across Australia:
- Our AI defence and agent containment service is for organisations whose AI agents hold keys or approval authority, and sets limits on what those agents can do.
- Our security posture assessment is a two-week, evidence-based review against the Essential Eight, CPS 234, ISO 27001 and NIST CSF 2.0.
- Our fractional AI and information risk officer gives you a named person accountable to your board for decisions like these.
Further reading
- Binance: Security Incident Update (30 October), Update #2 (30 October) and Recovery Update #3 (31 October)
- TRM Labs: its analysis of the theft and the attribution
- Elliptic: its analysis of the theft and the attribution
- Chainalysis: its tracing of the theft
- Ethereum Improvement Proposals: EIP-7702, Set Code for EOAs
- APRA: Letter to industry on artificial intelligence (30 April 2026)
- ASD’s ACSC and partners: Careful adoption of agentic AI services (1 May 2026)
- APRA: CPS 234 Information Security and CPS 230 Operational Risk Management (2026 text)
- ASIC: Consultation Paper 392 and Regulatory Guide 133
- ASD: Essential Eight maturity model and NIST: Cybersecurity Framework 2.0
- Vendor and anonymous analysis, useful for detail: Blockaid’s report (its title refers to Blockaid’s own detection models, not the attackers), Bitquery’s investigation and 808bits on the authorisations
Frequently asked questions
How much was stolen in the Binance hack?
Binance says about US$6.3 billion. Itemised analyst tallies run from US$6.36 billion (TRM Labs) to US$6.43 billion (Elliptic). No readable source supports US$8 billion. ABC News’s A$8.9 billion is the same US$6.3 billion converted to Australian dollars.
Was this an EIP-7702 exploit?
Only in the sense that the attacker used an EIP-7702 delegation on one Ethereum wallet. No source says the standard itself is flawed. A second Ethereum wallet and the wallets labelled as Binance’s on the XRP Ledger, Solana, Bitcoin and Tron were drained with ordinary signed transfers, and analysts report the same on other networks, so the delegation was one route among several.
Were customer funds affected?
Binance says users will not bear the loss. By 31 October it said it had replenished 90% of the stolen assets from its own funds, and that ten major tokens, including BTC, ETH and USDT, are fully backed. CoinDesk reported that one drained wallet appears in Binance’s Proof of Reserves. A full proof is expected by 3 November.
Has Binance said what caused it?
Not yet. Its first theory was a compromised DevOps engineer’s laptop. More than six hours later it said it had found “additional points of breach”. It says it has found no evidence that a wallet private key leaked, and has promised technical findings within about 48 hours of its 30 October update, which is about 19:30 UTC on 1 November.
Who did it, and was AI used?
TRM Labs and Chainalysis attribute the theft to North Korea’s TraderTraitor group with high confidence, and Elliptic calls it likely. No government has attributed it, and Binance has named no one. No readable source says the attackers used AI to breach Binance.
Why could Tether and Circle freeze funds but not Bitcoin or Ether?
USDT and USDC are issued by companies whose token contracts include a blacklist they control. Ether and Bitcoin have no issuer and no freeze function. That is why thieves swap stablecoins into native assets quickly, and why the first hour decides how much can be frozen.
Does APRA CPS 234 apply to a crypto exchange?
Not unless the exchange is an APRA-regulated entity, and exchanges generally are not. AUSTRAC and ASIC regulate exchanges in Australia. CPS 234 is still a useful benchmark, and APRA-regulated organisations often hold their providers to it by contract.
Could an AI agent with signing authority fail the same way?
The shape of the failure analysts describe is the same: something with authority to sign is steered into signing what it should not. No source we could read says AI was involved at Binance. APRA’s April 2026 letter and ASD’s May 2026 agentic AI guidance describe the controls: distinct identities, short-lived credentials and human approval for high-impact actions.
Where to start
This week, ask your own team, or your custodian, for the one-page answer to who or what can ask your signers to sign. If you want help working that out, book a discovery call. If you want a baseline first, the maturity assessment takes ten minutes.
Continue reading
Related pieces
26 min read
eMudhra TLS certificate compromise: browsers are fixed, your estate is not
Eight eMudhra certificate authority keys were so weak anyone could recover them. Chrome and Firefox blocked them in hours. Servers, containers and Java did not.
- Cryptography
- Supply chain
- Third-party risk
19 min read
AI supply chain security: four ways code now enters your estate without a vendor review
Model weights, agent skills, MCP servers and packages your coding assistant invented all execute in your environment, and none of them trigger a vendor assessment. The documented incidents, the measured scale, and the controls that close the gap before CPS 230 makes it an audit finding.
- Supply chain
- Third-party risk
- AI agents
21 min read
OpenAI Medicare hack: what it means for Australia's AI guardrails
An OpenAI agent got into a Medicare portal and Australia found out three months later. The verified timeline, legal gaps, coming guardrails, and what to do.
- AI governance
- AI agents
- Regulation