Google Wants To Be The Vault For Bank Crypto

Google is building a crypto custody product for banks, and on Wednesday it showed it in public. At its first digital assets symposium in New York, Google Cloud is presenting Google Multi-Party Compute (MPC), a service for storing and moving crypto and tokenized assets without any single machine holding a complete private key, CoinDesk reported. It's in private preview. Commercial launch is planned for early 2027, and there's no price yet.

The news spread on X the same day, with Scott Melker posting it as a "JUST IN" item.

Who's testing it? Google isn't saying. Several design partners and big financial institutions are in the preview, and none are named. The only confirmed user is Alphabet, which has started securing its own digital assets on Ethereum and Solana with the system. Which assets, and how much, stays undisclosed. Rich Widmann, Google Cloud's director of digital assets strategy, told CoinDesk that banks moving onto blockchains "need scalable, proven infrastructure to secure their clients' assets."

A Product, Not A DIY Kit

MPC itself isn't new. You split a private key into fragments, spread them across separate systems, and no single failure hands over the money. Google even published a guide in 2023 showing customers how to build this on its Confidential Space infrastructure. What's new is that Google now sells it finished. The company told CoinDesk it has never offered a dedicated MPC custody product for crypto. Until now, banks on Google Cloud got Key Management Service and Cloud HSM, then had to bolt signing, policies and recovery on themselves.

CoinDesk's example: a bank keeps one key share in Google Cloud, one on its own hardware and one with a competing cloud provider. When it wants to move funds, the transaction goes into Confidential Space, a hardware-isolated environment, where a policy engine checks it against the bank's rules before anything gets signed. Those rules can cap amounts, restrict destination wallets or demand approval from several departments. Thresholds are adjustable, 2-of-3 or 5-of-7. Google says it can't read the key material in unencrypted form, even for shares sitting on its own infrastructure.

At general availability the service is designed to support ECDSA and Ed25519 signatures. ECDSA is the scheme behind most Bitcoin and Ethereum wallets, and Ed25519 is Solana's.

There's a documentation trail too. Cointelegraph reported that Google updated the service docs on Monday, and the release notes show changes since August. On Oct. 1 it added Bitcoin rules covering transaction amounts, destination address types and change outputs. The product is still labeled preview, which means it's offered as is, with possibly limited support.

One loose end. Solana Compass noted that the public docs still list Solana as "coming soon", while Google told CoinDesk that Alphabet already runs the system on Solana. Google hasn't explained the gap.

Why Banks Care About Keys

Because keys are where the money gets stolen. Chainalysis data cited by CoinDesk puts compromised private keys behind 43.8% of crypto stolen in 2024. DeFiLlama figures show $16.69 billion lost to hacks and exploits cumulatively as of June, with roughly 40% of it tied to key compromises.

June's Humanity Protocol hack is the textbook case. On June 9, founder Terence Kwok posted that the private keys of a Humanity Foundation member had been compromised, and told users to stay away from the bridge and liquidity pools. Onchain analyst Specter had already been tracking the drain, with losses past $20 million in that post. CoinDesk later put the total above $32 million across at least 17 wallets, and the H token fell more than 80%. The numbers never fully lined up: PeckShield's monthly tally had $31 million, while the team's own estimate rose to roughly $36 million, according to The Block.

Not everyone bought the explanation. ZachXBT said he didn't believe the team's version and floated the idea that it was a market maker cashing out. That's his suspicion, not a finding.

Either way, this is the failure Google says MPC is built for: one stolen credential shouldn't be enough to move funds. CoinDesk's analysis is that a policy check before signing could stop transfers that break preset limits or approval rules. Whether that would have changed anything in a case like Humanity's, nobody can say from the outside.

What It Doesn't Cover

Google is also pitching the product against AI-powered attacks and quantum computing. Read that part carefully. CoinDesk points out that the current protections target stolen credentials and unauthorized transactions, not a break in the underlying cryptography.

That distinction matters this month. On Oct. 7, Ethereum Foundation researcher Justin Drake asked the industry to start planning for "bunker mode", his term for moving funds to addresses that have never exposed a public key, on the worry that AI could crack the signatures protecting Bitcoin and Ethereum wallets within months rather than years in a worst case. CoinDesk said the post pulled almost 4 million views. Vitalik Buterin said take the risk seriously but don't rush to move funds, and Samson Mow told followers not to panic. No AI system has shown it can break these signatures.

Google says its architecture can take post-quantum upgrades later without banks rebuilding their systems. It gave no timetable.

A Crowded Market

Google is walking into a field that already has Fireblocks, Fordefi and BitGo. Its pitch, per CoinDesk, is banking relationships plus security expertise, and neutrality for banks that don't want to rent infrastructure from a rival chasing the same customers.

Demand isn't the question. UniCredit was exploring digital asset custody and brokerage infrastructure in September, according to crypto.news, and Finance Magnates reported that JPMorgan plans to accept Bitcoin and Ether as loan collateral for institutional clients, using a third-party custodian.

The caveats are real, though. Even with shares spread around, banks may still lean on Google for parts of the software, the transaction policies and the operations. Security depends on how a bank configures approvals and who gets to edit the rules. A legitimate signer who is tricked into approving a bad transfer is still a problem. And Google offered no independently verified performance comparison with existing custody products.

I'd say the cryptography is the easy part to trust here. The harder question is whether a bank's risk committee wants one more critical dependency on Google. What I'd watch next: whether any testing bank goes on record, and what Google charges.