Humanity Protocol's $36M Key Compromise: A Runbook for Wallets That Touch Contracts

TL;DR

On the night of June 8, 2026 (UTC), an attacker drained Humanity Protocol's H token across Ethereum and BNB Smart Chain. The team put the loss at roughly $36 million across both chains; independent trackers tallied about $32 million in drained funds while the attack was still running. H fell about 90% from near $0.70 to the $0.07 to $0.08 range, briefly touching about $0.05.

There was no smart contract bug. A key compromise is when an attacker obtains a project's legitimate private keys and signs valid transactions instead of exploiting a code flaw, so the contracts, access controls, and audit all pass while the funds leave. The bridges, the token, and the Safes all worked as written. The attacker signed every transaction with legitimately authorized keys, because a single compromised developer machine held seven of them: one admin hot wallet key, three of the six owner keys on the Ethereum bridge Gnosis Safe, and three of the five owner keys on the BSC Safe. One laptop cleared two multisig thresholds on two chains.

This is the failure domain auditors do not cover and audits cannot see. Below is the recap, then the runbook: how to segregate, monitor, and build emergency revoke paths for the project-owned wallets that touch your contracts.

What happened

Humanity Protocol is a palm-biometric "Proof of Humanity" identity project founded by Terence Kwok, often framed as a Worldcoin rival (palm scans instead of iris scans). It raised about $50 million across two rounds, a $30 million seed led by Kingsway Capital in May 2024 and a $20 million round co-led by Pantera Capital and Jump Crypto in January 2025, at what the company described as a $1.1 billion fully diluted valuation. Its H token launched on June 25, 2025 with a 10 billion total supply.

The attack ran for roughly fourteen hours and unfolded in three vectors, per the project's own post-mortem, each step verifiable on-chain by transaction hash:

1. Ethereum hot-wallet theft. An admin hot wallet (an EIP-7702 smart account) had its private key stolen. The attacker moved 6,045,060 H out as direct theft and pre-loaded another 15 million H into the bridge to pad its balance before the main sweep.
2. Ethereum bridge drain. Three of the six owner keys on the Safe controlling the bridge's ProxyAdmin were compromised. The attacker assembled the Safe transaction offline, transferred ProxyAdmin ownership to their own wallet, upgraded the bridge proxy to a malicious implementation, and swept 141,182,632 H in a single transaction at 19:52:23 UTC.
3. BSC unlimited mint. Three of the five owner keys on a separate BSC Safe (a different set of keys from the Ethereum side) were compromised. Same ProxyAdmin seizure, then a malicious token implementation with an open mint(). The attacker minted 100 million H three times (02:09, 03:51, and 08:58 UTC on June 9), inflating BSC supply from about 141 million to about 441 million H.

Counting without double-counting, the project estimated total impact at roughly 447 million H stolen or minted across both chains. Note that about two-thirds of that figure is freshly minted paper, not value taken from holders, which is why the dollar loss (~$36 million by the project's count) is far below any naive token-count-times-price math. The price had already collapsed and pool liquidity was thin as the attacker dumped.

Blockaid flagged the BSC proxy takeover and the first 100 million H mint in real time, valuing that first mint at about $12.9 million at the time. PeckShield tracked the Ethereum side, putting drained funds near $30 million across a victim set that grew from an initial 17-plus wallets into the hundreds. Cyvers CTO Meir Dolev told Decrypt the incident was "an operational security failure, not a smart-contract bug," and named the structural flaw directly: "one key trusted with both the funds and the power to rewrite the rules."

No nation-state or named threat group has been linked to this hack. On-chain investigator ZachXBT initially floated that the incident looked "possibly staged" and a convenient exit for the project's market maker, then publicly reversed the same day after tracing the laundering: "the sketchy MM / OTC & private key compromise are independent of one another and not related." The attacker remains unidentified, and the project says it is working with police.

The root cause: seven keys, one laptop

Humanity Protocol's incident update traced the breach to a compromised developer machine. In the post-mortem, the project was specific: a colleague's machine was confirmed infected with malware that gave the attacker full root access. During the mainnet launch about a year earlier (around June 2025), seven production private keys were inadvertently backed up to that one device:

• the admin hot wallet key
• three of the six Ethereum bridge Safe owner keys
• three of the five BSC Safe owner keys

From that single point of compromise, the attacker obtained everything needed to clear both multisig thresholds on both chains. Kwok reportedly explained that the keys had been "set up in one place before being dispersed," which left some backed up on the device. Trading Strategy co-founder Mikko Ohtamaa put the consequence more bluntly: "3 of their 6 multisig key holders were the same person. They did not apply their own protocol."

This is the entire lesson in one sentence. A failure domain is the set of keys, devices, or people that can all fall to a single breach, and threshold security only holds when no two signing keys share one. A 3-of-6 multisig where three keys live in the same failure domain is not a 3-of-6 multisig. It is a 1-of-1 wearing a costume. The threshold math only protects you if compromising one signer cannot compromise the others, and "one laptop" is one signer no matter how many keyfiles sit on its disk.

An audit would not have caught this. Every contract behaved exactly as specified. There was no reentrancy, no oracle manipulation, no overflow, no missing access-control modifier. The access control was present and correct, and the attacker satisfied it with real signatures. The failure was entirely in how the keys behind that access control were generated, stored, and watched. That is operational security, and it sits outside the scope of a normal smart contract audit.

What actually worked: segregation, by accident

One part of Humanity's setup survived, and it is the most useful thing in the whole incident.

The Ethereum H token contract had its ProxyAdmin controlled by a different Safe than the bridge: a clean 4-of-7 Safe whose keys were not on the compromised laptop. Those signers were added in July 2025, after the launch-time backup. When the team realized what was happening, that clean Safe still had the authority to act, and at 01:05:11 UTC on June 9 it upgraded the Ethereum H token to a new implementation that hard-blocks all transfers. The Ethereum token was frozen and remains under the project's control.

The BSC token had no such independent controller. Its ProxyAdmin sat behind the BSC Safe whose keys had fallen, so once the attacker held it, there was no clean key left to fight back with. The project now describes the BSC token as permanently compromised: the attacker still owns its ProxyAdmin and can mint, pause, or drain at will. The canonical Arbitrum bridge, on separate infrastructure, was untouched and still holds about 87 million H.

So the same incident ran the experiment twice. Where a critical control was held by keys in a separate failure domain, the team kept the emergency brake and used it. Where it was not, the asset was lost outright. That contrast is the spine of the runbook.

The runbook: how to prevent a key compromise

This is written for the people who hold or manage the keys behind a protocol: founders, foundation operators, and the engineers who set up the Safes. It assumes you already have an audit. The audit is not the boundary here. Key custody is. If a compromise is already underway, our incident response team can run this playbook with you in real time.

Key custody checklist

1. One signing key per device, per human. Never co-locate threshold keys.
2. Independent signers must be independent people, not one person holding three keys.
3. Production keys on hardware, an HSM, or a cloud KMS. Never a daily-driver laptop.
4. Generate each key on the device that will hold it. Never assemble keys in one place.
5. Split upgrade and rewrite authority from funds and operational keys, in separate failure domains.
6. Keep an independent pause or freeze key the operational keys cannot reach.
7. Alert in real time on ProxyAdmin and ownership transfers, proxy upgrades, Safe owner and threshold changes, and mint and pause calls.

1. Inventory every wallet that can touch a contract

You cannot protect what you have not listed. Build a register of every key and role that can move funds or change behavior, and keep it current. For each entry, record the role, the address, the chain, the key's custody (hardware, HSM, cloud KMS, hot, paper), and which human holds it.

The roles that matter most are the ones that can rewrite the rules, not just move money:

• proxy ProxyAdmin / upgrade authority
• contract owner and any DEFAULT_ADMIN_ROLE
• bridge owner and bridge admin
• mint and pause authorities on tokens
• Safe owner sets, their thresholds, and any enabled Safe modules, which execute without owner signatures
• deployer accounts that retain residual privileges, especially those with keys in CI environment variables
• admin hot wallets and relayers that hold standing approvals

Humanity Protocol produced exactly this table, with addresses, thresholds, and per-key status, in its post-mortem. It was excellent work. It was also written after the loss. The register has to exist before the incident, because during one you will not have time to reconstruct it.

2. Segregate: no two threshold keys in one failure domain

This is the control that would have prevented the entire incident. The principle is simple to state and easy to violate: compromising any one device, person, or environment must never be enough to cross a multisig threshold.

Concretely:

• One key per device, per human. Never back up multiple signer keys to the same machine. The moment three of six keys live on one laptop, your 3-of-6 is a 1-of-1.
• Independent signers must be independent humans. Three keyholders who are the same person are one keyholder. Spread owner keys across people who do not share a laptop, a password manager vault, or a cloud backup.
• Production keys never touch a general-purpose machine. Use hardware wallets, an HSM, or a hardened cloud KMS for anything that can upgrade or move funds. A developer's daily-driver laptop, with its browser extensions, npm installs, and IDE plugins, is the worst place a production signing key can live. (For why that machine is such a soft target, see our breakdown of the GitHub VS Code extension breach.)
• Fix key generation, not just key storage. Humanity's keys ended up co-located because they were "set up in one place before being dispersed." Generate each key on the device that will hold it. A key that was ever assembled in one place was, for that moment, a single point of failure, and backups of that moment outlive the dispersal.
• Do not share signer infrastructure across chains. Humanity ran separate Safes on Ethereum and BSC, which is correct, but the same compromised machine held keys for both. Cross-chain deployments multiply the blast radius of one breach unless the custody is genuinely separate per chain.
• Split the money key from the rewrite key. Dolev's line is the design rule: never let one key both hold funds and hold the power to change the contract. The authority to upgrade a proxy should be a different key set, in a different failure domain, from the one that operates day to day.

3. Separate the upgrade path from the pause path

The single reason Humanity kept its Ethereum token is that the token's upgrade authority lived in a Safe distinct from the bridge's. Design that separation in on purpose.

• Put the emergency pause / freeze authority on a key set that is segregated from the operational and upgrade keys. If your only "stop" button is held by the same keys an attacker just stole, you have no stop button.
• Give every upgradeable contract a clean, independent controller, not a shared ProxyAdmin reused across the bridge and the token. Humanity's bridge and BSC token shared ProxyAdmin patterns that fell together; the token that had its own clean Safe survived.
• Add a timelock to admin actions. Every privileged step in this attack (the ProxyAdmin transfer, the upgrade, the mint) executed instantly. A timelock on ownership transfer or implementation upgrade would not stop a thief who holds the keys, but it converts a silent, instant takeover into a delayed, observable one and buys the window in which a clean key can intervene. Instant admin power is a design choice, and it is the wrong one for anything holding user funds.

4. Monitor: the fourteen-hour window was visible the whole time

This attack was not fast or quiet. It ran from 11:59 UTC to nearly 09:00 the next morning, and every step it took emitted a public event. A probe transfer to the bridge. A Safe execTransaction transferring ProxyAdmin ownership. An Upgraded event as the proxy pointed at a malicious implementation. A 141-million-token sweep. A fresh contract deployment on BSC. Three mint() calls hours apart. Independent trackers like Specter, PeckShield, Lookonchain, and Blockaid all saw it and narrated it in real time. The only party not watching with automated urgency was the protocol itself.

Decide in advance what should page a human at 3am, and wire alerts to it:

• OwnershipTransferred, AdminChanged, and Upgraded on any proxy or ProxyAdmin you control
• owner-set or threshold changes on any Safe (AddedOwner, RemovedOwner, ChangedThreshold)
• new implementation deployments that get wired into your proxies
• mint() on a token that is supposed to have a fixed or capped supply
• any outbound movement from an admin hot wallet, especially a probe-sized test transfer
• large or unusual transfers out of a bridge or lockbox

Then make the response automatic where you can. Alerts that land in a Slack channel nobody is reading at midnight are not monitoring. Pre-configured circuit breakers that pause on an anomalous admin event, without waiting for a war room to convene, are. On-chain forensics later noted attacker wallets that had been pre-funded weeks earlier and mint authority that appeared "warmed up" days before execution; treat that as a reminder that the setup phase is also observable, not just the drain.

5. Build and rehearse the emergency revoke path

Humanity's clean Safe was able to act because it existed before the attack. The teams that survive a key compromise are the ones that built the brake in advance and knew how to pull it.

• Keep an independent kill switch. A pause or freeze authority, in a separate failure domain, that can stop transfers or upgrades on a contract whose operational keys are gone. This is the single control that saved the Ethereum token.
• Know your revoke paths cold. For users, that means revoking token approvals to a compromised contract, which is exactly the advisory Humanity issued. For the protocol, it means knowing which clean key can transfer authority away from a captured ProxyAdmin, and having it staged.
• Pre-stage incident comms. Humanity's first warning, do not interact with the bridge or any liquidity pools, is the right message and it went out fast. Have those channels and that message ready before you need them, so the warning beats the laundering rather than trailing it.
• Run the tabletop. Walk through "a developer laptop is compromised and the attacker has three of our six bridge keys" as a drill, with the clock running. The first time you trace your own revoke path should not be during a live drain.

Lessons for protocol security

1. The audit is not the boundary. Key custody is. This was not a code exploit and a code review would not have surfaced it. The contracts were correct and the attacker used real signatures. Auditing the code while leaving production keys on a developer laptop is locking the front door and leaving the keys under the mat, and $10.77 billion in hack data says attackers know it.

2. A multisig is only as strong as the independence of its signers. Three keys on one laptop is one key. The threshold is a promise that compromising one signer is not enough, and that promise is void the moment two threshold keys can fall to a single breach.

3. Segregate the power to rewrite from the power to spend, and from each other. The Ethereum token lived because its controller was a different Safe in a different failure domain. The BSC token died because its controller fell with everything else. Separation is not bureaucracy. It is the difference between a freeze and a total loss.

4. Instant admin power is a liability, not a convenience. Every privileged step here executed with no delay. A timelock turns a silent takeover into an observable, contestable one and creates the window your clean keys need.

5. If it can change behavior, watch it in real time. The attack was on-chain and legible for fourteen hours. Continuous monitoring of admin and ownership events, with automated circuit breakers, is what closes the gap between "an attacker has our keys" and "they have drained the protocol."

Current status

As of June 10, 2026, and noting that this incident is less than 48 hours old and the loss figure was still moving when the project last reported:

• The Ethereum H token is frozen, transfers hard-blocked by a clean 4-of-7 Safe that the attacker never reached.
• The BSC H token is described by the project as permanently compromised; the attacker retains its ProxyAdmin and the ability to mint more H at will.
• The team halted deposits and withdrawals on the affected (Hyperlane) bridges and warned users away from the bridge and liquidity pools. H continued trading on exchanges throughout; no exchange has publicly confirmed a freeze or delisting.
• The project says it has engaged external security experts for a forensic investigation, is working with police, and is developing a recovery program for affected users, with compensation specifics not yet finalized. Reporting indicates the team also offered a $1 million bounty for information leading to recovery and pledged to use recovered funds to buy back H.
• Most of the stolen value had already been swapped to ETH and BNB. The project says it does not yet know when the device was compromised or how long the attacker held the keys.
• A 266.5 million H token unlock (about 9.4% of circulating supply, worth roughly $28 million at post-crash prices) is scheduled for June 25, 2026, which is the token's one-year cliff. The project has not said how the incident affects it.

Don't wait for the post-mortem

Humanity Protocol's post-mortem is a clear, honest, well-built document. It is also a forensic reconstruction of an attack that ran for fourteen hours in plain view of every on-chain tracker except the protocol's own. The events that mattered, a ProxyAdmin transfer, a proxy upgrade, a 141-million-token sweep, three mints on a capped token, were all public the instant they happened.

Tripwire's real-time monitoring watches that exact surface in production: ProxyAdmin and ownership transfers, proxy upgrades, Safe owner and threshold changes, mint and pause calls, and admin hot wallet movements across your deployed contracts and their dependencies. Alerts land in seconds via Slack, Telegram, or email, and pre-configured circuit breakers can freeze operations before the drain completes rather than after.

Audits tell you the code was correct on the day it was reviewed. Tripwire tells you whether the keys and admin paths that govern that code are still behaving right now, in production. If you operate project-owned wallets that can upgrade contracts, move treasury, or mint tokens, talk to us.

Related security research

• GitHub's 3,800-repo breach via a poisoned VS Code extension. Why a developer's laptop is the softest target in the stack, and why secrets must never live on it.
• Drift Protocol's $270M durable-nonce exploit. Another nine-figure loss with no Solidity bug, this time social-engineering multisig signers instead of stealing their keys.
• Kelp DAO's $292M LayerZero DVN exploit. A configuration that sat readable on-chain for over a year, in the same class of unaudited operational risk.
• The human factor in DeFi security. Why most of the money now leaves through people and operations, not code.

Forensic appendix: contracts and transactions

Figures and addresses below are drawn from Humanity Protocol's official post-mortem and verified on-chain. The first BSC mint resolves on BscScan (the explorer's dollar tag reflects the recovered price, not the value at mint time).

Compromised controls

Key transactions (UTC)

Reconciling the numbers

• ~$32 million is the drained-funds figure independent trackers confirmed while the attack ran (about $23.7 million already swapped to ETH plus roughly $7.9 million still in H, per Specter). The earlier $30M and $31M figures are snapshots of the same growing total.
• ~$36 million is the project's own cross-chain figure, time-qualified as "as of right now." It adds the BSC damage. Attribute it to Humanity Protocol rather than treating it as an independently audited number.
• ~447 million H is the project's total token-impact count (about 6M direct theft + about 141M bridge sweep + about 300M minted). Roughly two-thirds is newly minted supply, so this token count does not convert to dollars at the pre-attack price.
• The price collapse was about 90% peak-to-trough (from a June 8 high near $0.73 to lows around $0.07 to $0.08, briefly about $0.05 per CoinDesk), settling near $0.12 to $0.13 before rebounding toward $0.16 to $0.20 later on June 9.

Frequently asked questions

How was Humanity Protocol hacked?

A developer's machine was compromised with malware and held seven production signing keys that had been backed up to it during the ~June 2025 mainnet launch: one admin hot wallet key, three of six Ethereum bridge Safe keys, and three of five BSC Safe keys. With those, the attacker cleared both multisig thresholds, seized the bridge and token ProxyAdmin contracts, upgraded them to malicious implementations, drained the Ethereum bridge, and minted new H on BSC. No smart contract bug was involved.

How much was stolen?

The project put the loss at roughly $36 million across Ethereum and BNB Smart Chain. Independent trackers confirmed about $32 million in drained funds as the attack unfolded. The attacker additionally minted about 300 million new H on BSC, which is not counted in the dollar figure because the token had already crashed about 90%.

Was it an audit failure?

No. The contracts behaved exactly as written, and the attacker used legitimately authorized private keys. Cyvers called it "an operational security failure, not a smart-contract bug." This is a key custody and operations failure, which is outside the scope of a normal smart contract audit.

Why did the Ethereum token survive but not the BSC token?

The Ethereum H token's upgrade authority was held by a separate, clean 4-of-7 Safe whose keys were not on the compromised laptop. That Safe froze the Ethereum token. The BSC token's controller fell with the rest of the keys, so the attacker kept control of it, and the project describes it as permanently compromised.

Was it North Korea or an insider?

Neither has been established. No nation-state or named threat group has been linked to the hack. An early "possibly staged / insider exit" theory from ZachXBT was publicly retracted by him the same day after he traced the laundering. The attacker remains unidentified, and the project says it is working with police.

Sources

Primary sources

• Humanity Protocol, H Token Incident Update (official post-mortem). Retrieved: 2026-06-10
• BscScan, first BSC mint transaction (100,000,000 H). Retrieved: 2026-06-10
• Terence Kwok, initial incident statement on X. Retrieved: 2026-06-10

News and analysis

• CoinDesk, Humanity Protocol token crashes more than 80% after a $32 million private-key hack. Retrieved: 2026-06-10
• Decrypt, Humanity Protocol loses $36M after private keys compromised. Retrieved: 2026-06-10
• The Crypto Times, Three breach vectors, 447M tokens: Humanity Protocol details H exploit. Retrieved: 2026-06-10
• crypto.news, Humanity Protocol says compromised admin keys led to $36M exploit. Retrieved: 2026-06-10
• Protos, One laptop: How poor security ruined Humanity Protocol. Retrieved: 2026-06-10
• crypto.news, ZachXBT rules out insider theft in Humanity Protocol's exploit. Retrieved: 2026-06-10
• The Block, Humanity Protocol exploit. Retrieved: 2026-06-10

Context

• The Block, Pantera Capital and Jump Crypto lead $20 million round for Humanity Protocol. Retrieved: 2026-06-10
• EIP-7702, Set EOA account code. Retrieved: 2026-06-10

Disclosure: SigIntZero has no commercial relationship with Humanity Protocol or any party mentioned in this article. This piece covers an incident less than 48 hours old; figures the project described as preliminary are attributed as such, and details may change as the investigation continues.