Crypto Custody Security Lives in the Approval | Elacity
Bitget lost about $387 million without losing a private key. October's thefts show crypto custody security fails where one machine can approve, not where a key hides.
Bitget Kept Its Keys and Still Lost $387 Million: Crypto Custody Security Lives in the Approval
If you hold crypto anywhere, you have probably been told one rule: protect the private key and you protect the money. Crypto custody security, as most guides teach it, is the craft of hiding that key. Three thefts in the last four weeks say the rule is incomplete, and the gap costs you.
In the largest, Bitget lost about $387 million from its hot and warm wallets, yet the exchange and its investigators say its private keys were never compromised. The signatures were real. The intent behind them was forged.
The Failure: One Machine Could Say Yes
According to BleepingComputer's summary of the SlowMist and Mandiant findings, attackers used a zero-day in third-party security appliances, moved onto a production wallet job server, and planted a custom withdrawal tool.
SlowMist recovered that tool: it forged risk-control parameters, built withdrawal requests and called the normal withdrawal process. The signing service did its job perfectly. It signed what the compromised backend told it was approved.
That is the honest lesson, and it is uncomfortable. A blockchain checks that a signature is valid. It cannot check that a person actually asked for the payment. Whoever controls the step that declares intent controls the money, key or no key.
Two More Versions of the Same Bug
On October 7, 79th Vault said an attacker obtained an operator's private key through weak account-permission management. Nexus Mutual's security roundup describes the root cause plainly: a single hot key with the power to drain a trading pair through a function that worked as written.
Then came the quietest one. Ledger confirmed that devices sold through the reseller CryptoBilis carried a hidden implant that read the 24-word recovery phrase off the screen and sent it out over a mobile network. The secure chip was untouched. The secret was simply shown, once, in the clear, and once was enough. Ledger has since asked resellers across Southeast Asia and Hong Kong to halt sales.
Three incidents, three different layers. Each had one place where a single actor could say yes, or one moment where the whole secret existed in readable form.
The Paradigm Shift: Crypto Custody Security Is About Authority, Not Secrecy
This is the old problem of ambient authority, which we unpacked in our explainer on capability-based security. A process that can act on everything it can reach is a liability the moment anyone else steers it. Hiding the key harder does not change who can point it.
Institutions are moving fast here. BNY expanded regulated digital asset custody in the EU this month, and Standard Chartered says it plans custody for selected cryptoassets and tokenised real-world assets in Singapore. Regulated custody is useful. It still has to answer the October question: which component is allowed to decide, and can it be lied to?
We have argued before that digital asset custody comes down to who owns the lock. October adds a corollary. Owning the lock is not enough if one server can forge the instruction to open it.
The Elacity Solution: Every Share Checks the Rights Itself
Elacity's crown jewel is turning data, work and IP into Wealth Capsules: encrypted, programmable goods with rights written in, unlocked only for whoever holds those rights. The engine beneath is ElastOS, a computer you own. The custody mechanism that makes it hold together answers the Bitget failure directly.
1. An owned 2-of-3 key quorum
The key that unlocks what you bought is split across multiple independent machines. No single operator, Elacity included, holds it. A compromised server, whether a security appliance or a wallet job host, holds at most one share, which unlocks nothing.
2. Each machine re-checks your on-chain rights
This is the part Bitget lacked. Every node in the quorum independently verifies your on-chain rights before releasing its share. There is no upstream approval flag to forge, because no node trusts another node's word that you are entitled. The chain settles who holds the right; each share holder reads it for itself.
3. Keys are used, never owned
The CryptoBilis implant worked because a secret was displayed to a human. In Elacity's design, a key can sign or decrypt for you while the secret exists in the clear only for a split second inside a sealed sandbox, welded to that one transaction, then wiped. You sign in with a passkey, not a seed phrase, and recovery is an explicit, signed, audited act.
What This Does Not Solve
Honesty is part of the design. The quorum is trust-minimised, not trustless: today it is an owned, operator-run set, and a colluding quorum could in principle reconstruct a key. Permissionless node markets are something we are building toward, not something shipped. And none of this replaces exchange-grade operations for a firm moving customer funds.
What it does change is the shape of failure. Instead of one machine that can say yes, you need several independent machines to agree on a fact anyone can verify. That is a harder target than a hidden key, and it fails closed.
- Bitget: approval forged upstream. Answer: no single approval to forge.
- 79th Vault: one hot operator key. Answer: no single key holder.
- CryptoBilis: secret shown in the clear. Answer: no seed phrase, keys used never seen.
As our Founder Sasha Mitchell puts it: "The people who create the value should own it. That is the entire reason Elacity exists." Owning it means no single server gets to decide otherwise.
If you want to follow how we harden this layer in public, follow Elacity on X.