Humanity Protocol: Why a 3-of-6 Multisig Didn't Stop $36M

On June 8, 2026, an attacker drained approximately $36.4 million from Humanity Protocol by crossing the signature threshold of two perfectly legitimate multisig wallets. There was no bug in the contract. The multisig (a wallet requiring multiple signatures to move funds) was real: a Gnosis Safe configured with 3-of-6 signatures on Ethereum and 3-of-5 on BNB Chain (BSC). The problem was that several of those signer keys — seven in total according to the team's forensic report, including backups — lived on the same laptop belonging to Chong Yee Wai, Director of the Humanity Foundation, which had been infected days earlier by a spear-phishing email (a phishing attack targeted at a specific person) mimicking the Korean exchange Bithumb. When the malware gained control of that device, it obtained the entire quorum. This article reconstructs the three attack vectors, why a 3-of-6 protected nothing, and what key management lessons it leaves for any protocol safeguarding institutional funds.

What is Humanity Protocol and why does this hack matter?

Humanity Protocol is a digital identity project based on biometric verification — palm scanning — that has been marketed as an alternative to Worldcoin, with a focus on Asia. Its token, H, was trading around $0.70 before the incident. The founder, Terence Kwok, confirmed the exploit and, in the same move, admitted an uncomfortable fact about the project: of the approximately 9 million registered identities, fewer than 1 million correspond to real biometric verifications; the rest are, in his words, mostly bots.

The interest of the case lies not in biometrics, but in the mechanics of the theft. Humanity is the third major hack of 2026 that does not break a single line of smart contract code and instead attacks the person holding the keys. It fits a pattern we have already documented: attacks are targeting infrastructure and the human perimeter, not the contract. Here, the perimeter was a laptop.

How was the theft executed across three simultaneous vectors?

The attacker was not satisfied with draining a hot wallet. Once they had control of the director's device, they attacked three surfaces simultaneously on the same day, squeezing every permission those keys granted.

The bridge (a gateway that moves tokens between two blockchains by locking them on one and representing them on the other) was the cleanest hit: with three of the six necessary signatures, the attacker upgraded the bridge contract to a version they controlled and extracted over 141 million H tokens. On BSC, they exploited the ProxyAdmin — the administrator contract that decides which code an upgradeable contract executes — to turn on the ability to mint new tokens out of thin air. This is where the figure should be read carefully: 300 million H were authorized for minting, of which about 200 million were executed in the initial phase. The sudden supply, dumped on Uniswap and other DEX (decentralized exchanges), crashed the price.

The three vectors share a single origin, which is why they could be triggered at once: the keys authorizing each one — signing on the bridge, administering the proxy, moving the hot wallet — were within reach of the same compromised device. An attacker with a single point of control didn't have to choose; they executed all three routes in parallel on the same day. This simultaneity is the signature of a device compromise, not a specific exploit: when the source of the signatures falls, all surfaces governed by those signatures fall with it.

Why was a 3-of-6 multisig not enough?

This is the question that matters, and the answer is counterintuitive. A 3-of-6 multisig sounds robust: no single signer can move funds alone, and failures of several keys are tolerated. On paper, there are six people or devices distributing power.

The scheme only fulfills its promise if those six keys are truly separate: different people, different devices, ideally different physical locations and, for the most sensitive ones, air-gapped hardware (isolated from the network). The security of a cryptographic threshold depends on the fact that compromising one key does not bring the attacker closer to the others. If three keys — or more, counting backups — coexist on the same laptop, the attacker who takes that laptop does not need to break the scheme: they satisfy it. They gather the threshold in a single move. In Humanity, according to the team's forensic report, up to seven signer keys — totaling those from the two multisigs and their backups — were within reach of a single device: on paper a 3-of-6 and a 3-of-5; in practice, a 1-of-1, because falling for that machine was enough to have them all.

In other words: physical distribution is not the same as a cryptographic threshold. The numerical redundancy of the 3-of-6 was fictitious because physical redundancy did not exist. The multisig was well-configured in the contract and poorly deployed in the real world. It is exactly the failure that separates the theory of key management from its practice, and the reason why a reader starting from scratch should first understand what a multisig is and what it does not guarantee before trusting it with funds.

How did the attacker get in and what footprint points to North Korea?

The entry point was not cryptographic; it was social. On June 5, three days before the drain, a spear-phishing email arrived mimicking Bithumb, one of the major Korean exchanges. Chong Yee Wai, Director of the Humanity Foundation, opened the bait and the device was infected with malware signed with a certificate from Hancom — a South Korean software provider — a stolen signing technique that gives the executable an appearance of legitimacy.

This set of indicators — spear-phishing impersonating an exchange, malware with a compromised Korean certificate, a target in the Asian ecosystem — fits the modus operandi of North Korean (DPRK) state-sponsored actors. The security firm Quantstamp, after analyzing the incident, found patterns characteristic of DPRK intrusions, but did not issue a definitive attribution or name a specific subgroup. This is an important nuance: there is a footprint, but no nominal confirmation. The DPRK pattern is already widely documented in other 2026 hacks, and we covered it in detail in the analysis of the $577 million trail through Drift and Kelp; here it suffices to place Humanity within that series without reproducing the dossier.

Was it a rug pull (insider fraud) or an external hack?

During the first hours after the Humanity theft, suspicions circulated that the incident might have been an inside job. On-chain researcher ZachXBT labeled it "possibly staged" on June 9, a reasonable hypothesis when money leaves the team's own wallets. Shortly after, he revised that reading.

His final conclusion was more nuanced than a simple "it was a hack" or "it was a rug pull": the activity of the market maker (the entity providing liquidity to the token) and the key compromise are independent events. That is, what looked like internal coordination was noise from two things happening at once without being connected. ZachXBT did not claim to have confirmed an external exfiltration with closed proof; he discarded the internal setup narrative as a necessary explanation. The full arc — suspicion, revision, separation of the two facts — is part of the value of the case: it shows how difficult it is to distinguish theft from fraud when funds leave proprietary wallets.

What does the attack timeline say?

The dated sequence makes it clear that the theft was not an instant event, but an operation with days of preparation and a tail that remains open.

What key management lessons does the case leave behind?

Beyond the names and figures, Humanity is a manual of what not to do when safeguarding institutional keys. The three operational lessons:

• Real physical separation, not just nominal. Multisig signatures must live on different devices, in the hands of different people. Co-locating several keys — or their backups — on a single machine turns a 3-of-6 into a disguised 1-of-1. The threshold number means nothing if physical distribution does not back it up.
• Air-gap for keys that move the treasury. Signatures with power over bridges, minting, and ProxyAdmin should never touch a laptop connected to email. The device that opens a Bithumb PDF cannot be the same one that holds the key to the bridge.
• Environment separation and timelock on critical contracts. The ProxyAdmin that allows upgrading a contract or minting tokens should be behind a timelock (a mandatory delay between order and execution) to provide time to detect and revert a malicious order. Without that pause, gathering the threshold is equivalent to instant execution, as happened here.

This last point links to a direct precedent from 2026: the Drift Protocol hack in April, where a similarly compromised multisig allowed actors with a DPRK footprint to execute actions without restraint. The pattern repeats: cryptography isn't broken; the human process around it is. For the individual reader, the domestic version of this same error is exactly what we describe in how people lose their cryptocurrencies: operational drift, not protocol failure.

The difference between protocols that survive a key compromise and those that don't usually comes down to whether the administrator contract had a timelock. With a mandatory delay between the upgrade order and its execution, the Humanity team would have had a window — hours, not seconds — to detect the malicious bridge upgrade and revoke it before anything was drained. Without a timelock, gathering three signatures and emptying the bridge are the same act. The BSC ProxyAdmin that remains compromised to this day is the other side of the same problem: an administrator without a temporal brake is a permanent master key, and as long as the attacker retains it, the risk of new minting does not disappear. The cost of adding that timelock is minutes of operational friction; the cost of not having it, in this case, was tens of millions.

What is the status of the project and recovery?

As of June 17, the situation remained open at a critical point: the BSC ProxyAdmin continued under the attacker's control, which keeps the ability to mint more tokens alive. Of the 300 million H authorized for minting, about 200 million had been executed; the remaining margin is the risk that continues to hang over the BSC network.

On the response side, on June 16, the team announced its recovery plan: a 1:1 airdrop (free distribution of tokens to those affected) of a new H token, this time as an ERC-20 on Ethereum, using a snapshot (a record of the network state) from before the attack as a reference. This is not an "H2" or a strange ratio — it is a one-to-one replacement of the affected token. The effectiveness of that plan depends on first closing the compromised ProxyAdmin; otherwise, the new token inherits the same risk of uncontrolled supply. As of June 17, the team itself described the BSC H as "permanently compromised" and had not regained control of the ProxyAdmin.

What changes in key management after the Humanity case?

Humanity Protocol was not hacked because it had a bad contract or a bad multisig. It was hacked because it deployed a good multisig in a way that its guarantee did not exist. The lesson is not "use multisig" — it already was — but that the scheme is only worth as much as the physical and operational separation of its keys. Three signatures out of six protect nothing if three signatures live on the same hard drive.

For 2026, this is already the dominant pattern of major thefts: social engineering against a person with access, not exploits against code. Three of the year's largest incidents — Drift and Kelp in April, Humanity in June — share the same skeleton: a footprint of DPRK actors, entry via human or social compromise, and a control mechanism (multisig or proxy administrator) that is satisfied rather than broken. The defensible perimeter has moved from the contract to the laptop. Anyone safeguarding funds — institution or individual — is today defending a device and a process, not just a line of Solidity.

The practical question for any team reading this is not "do we have a multisig?", but three more uncomfortable questions: where do our keys physically live, including backups? How many of them could someone gather by compromising a single device? And how much time would a timelock give us to revert a malicious order? Humanity failed all three. Answering them well isn't glamorous and doesn't appear on the roadmap, but it is the difference between a scare and a 36-million-dollar headline.

Sources and links: Rekt.news — Humanity Protocol post-mortem (Jun-16-2026) · Halborn — technical analysis of the hack · crypto.news — ZachXBT analysis · CryptoBriefing — DPRK patterns (Quantstamp) · CryptoTimes — recovery plan and airdrop · CoinDesk — the multisig that lived on one laptop