Khamees Mustapha

𝐀𝐜𝐭𝐮𝐦: 𝐁𝐞𝐡𝐢𝐧𝐝 𝐕𝐚𝐥𝐢𝐝 𝐒𝐢𝐠𝐧𝐚𝐭𝐮𝐫𝐞𝐬, 𝐔𝐧𝐜𝐥𝐚𝐢𝐦𝐞𝐝 𝐁𝐞𝐡𝐚𝐯𝐢𝐨𝐫. Around 20:05 on Oct 29, Binance's hot wallets came under attack, and roughly $6.3 billion in assets was drained within tens of minutes. The largest on record, according to public reporting. The investigation is still underway — but several confirmed facts are worth a pause for anyone who builds systems, works in security, or deals with compliance. The timeline: The attack began at around 20:05 on Oct 29. Over the next 20 to 40 minutes, hot wallets across multiple chains were emptied one after another; a second wave of outflows followed at around 23:00. The pivotal move on Ethereum: at 20:20, a single transaction carried 50 EIP-7702 authorizations — all validly signed by the hot wallet's own key — delegating the wallet's execution rights to a contract the attacker had deployed in advance. About three minutes later (20:24), roughly $2.5 billion in assets left in a single transaction; the delegation wasn't revoked until around 00:10 on Oct 30. Binance's preliminary investigation points to a compromised laptop belonging to a DevOps engineer, with additional intrusion points discovered afterward; at the same time, no evidence of leaked wallet private keys has been found. The attacker used self-destructing tooling — destroying tools and traces as they went. That fatal delegation, in Binance's words, "did not go through normal approval controls." Afterward, roughly $3 billion in assets was frozen on-chain, Binance covered the losses with its SAFU fund and company funds, and withdrawals resumed in phases. 𝟏. 𝐄𝐯𝐞𝐫𝐲 𝐬𝐢𝐠𝐧𝐚𝐭𝐮𝐫𝐞 𝐰𝐚𝐬 𝐯𝐚𝐥𝐢𝐝. 𝐓𝐡𝐞 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 𝐰𝐚𝐬 𝐨𝐮𝐭𝐬𝐢𝐝𝐞 𝐭𝐡𝐞 𝐬𝐢𝐠𝐧𝐚𝐭𝐮𝐫𝐞𝐬. What was broken here wasn't cryptography. No private keys leaked, every signature was valid, and the system executed each step strictly by the rules. From the machine's perspective, everything was "correct." From the perspective of accountability, there is no evidence that any informed person ever approved these actions through proper process. This is the first distinction to get right: 𝐚 𝐯𝐚𝐥𝐢𝐝 𝐬𝐢𝐠𝐧𝐚𝐭𝐮𝐫𝐞 𝐩𝐫𝐨𝐯𝐞𝐬 𝐨𝐧𝐥𝐲 𝐭𝐡𝐚𝐭 "𝐚 𝐜𝐞𝐫𝐭𝐚𝐢𝐧 𝐤𝐞𝐲 𝐬𝐢𝐠𝐧𝐞𝐝." It cannot prove who was behind the key, whether they knew what they were signing, or which approval process was followed. The gap between the two is the real lesson of this incident — and the blind spot of most systems today. In Actum's four-chain framing: the authorization chain answers only "what was it allowed to do" — never "what did it actually do." Equating authorization with behavior is equating the key with the person holding it. 𝟐. 𝐀 𝐩𝐨𝐬𝐭-𝐦𝐨𝐫𝐭𝐞𝐦 𝐭𝐞𝐥𝐥𝐬 𝐭𝐡𝐞 𝐬𝐭𝐨𝐫𝐲. 𝐏𝐫𝐨𝐨𝐟 𝐫𝐞𝐪𝐮𝐢𝐫𝐞𝐬 𝐞𝐯𝐢𝐝𝐞𝐧𝐜𝐞. A detailed technical post-mortem will follow. It's necessary — but see it for what it is: an account reconstructed after the fact by the party involved, from whatever logs and records it could find. The question is: when the attacker destroys traces as they go, what does a post-mortem stand on? If the logs lived in the same environment the attacker may have compromised, can the logs themselves be trusted? What regulators, auditors, insurers, and users actually need are a few very concrete questions: what operations took place in those minutes, and in what order? Behind each critical action — which person, which device, which approval? Were the records altered afterward? Can they be handed to a third party for independent verification? There's a telling contrast in this incident: many key facts were reconstructed from the public ledger instead — every on-chain transaction timestamped and hashed, checkable by anyone, which is how analysts produced a minute-by-minute timeline within hours. But the public ledger records only "how the assets flowed out," not "who inside did what." The outside books are crystal clear; the inside actions have to wait for a post-mortem report. 𝐀 𝐩𝐨𝐬𝐭-𝐦𝐨𝐫𝐭𝐞𝐦 𝐜𝐚𝐧 𝐧𝐚𝐫𝐫𝐚𝐭𝐞 𝐰𝐡𝐚𝐭 𝐡𝐚𝐩𝐩𝐞𝐧𝐞𝐝. 𝐎𝐧𝐥𝐲 𝐞𝐯𝐢𝐝𝐞𝐧𝐜𝐞 𝐜𝐚𝐧 𝐩𝐫𝐨𝐯𝐞 𝐢𝐭. 𝟑. 𝐀𝐬 𝐀𝐈 𝐬𝐭𝐚𝐫𝐭𝐬 𝐚𝐜𝐭𝐢𝐧𝐠 𝐨𝐧 𝐨𝐮𝐫 𝐛𝐞𝐡𝐚𝐥𝐟, "𝐰𝐡𝐨 𝐝𝐢𝐝 𝐢𝐭" 𝐠𝐞𝐭𝐬 𝐛𝐥𝐮𝐫𝐫𝐢𝐞𝐫. Swap "hot wallet" for any critical system and the problem holds: did the approval really happen, or is it just an "approved" status in the system? Are operation logs stored independently of the protected system, where neither external attackers nor insiders can quietly erase them? And the trend is magnifying the problem: AI agents increasingly execute actions on our behalf — calling APIs, moving assets, changing parameters. As the executor shifts from human to agent, "who did this, and who is accountable" only gets blurrier. A post-mortem report will find it harder and harder to truly reassure regulators and customers. This is what Actum is building: the Behavioral Trust Layer. One critical action. Four questions: 𝐀𝐮𝐭𝐡𝐨𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧: what was it allowed to do? 𝐁𝐞𝐡𝐚𝐯𝐢𝐨𝐫: what did it actually do? 𝐄𝐯𝐢𝐝𝐞𝐧𝐜𝐞: can what was done be independently verified afterward, tamper-evident? 𝐂𝐨𝐦𝐩𝐥𝐢𝐚𝐧𝐜𝐞: does the record itself hold up to regulators and auditors? That's also what PoHA (Proof of Human Action) means: every critical behavior leaves a verifiable, traceable, immutable record, so responsibility lands on a specific, accountable subject — whether the executor is a human or an AI agent. To be clear: an evidence layer doesn't replace security, and it can't guarantee a system won't be breached. It solves one thing — after an incident, you can produce an independently verifiable chain of evidence showing what happened, who did what, and when. $6.3 billion is a number that will be remembered. But the question more worth remembering: if it were you tomorrow — in those few minutes, could you produce the evidence?