Google Cloud previews distributed-key digital-asset custody service with policy-controlled signing

Google Cloud has published an institutional digital-asset signing architecture called Multi-party Compute, using distributed key shares and cryptographic policies rather than relying on one complete private key. Google’s October 2026 documentation identifies a v1beta interface but explicitly retains Preview and pre-general-availability terms. The launch is therefore best described as a preview for institutional builders, not a finished broadly available retail wallet or a licensed investment broker.[1][4]

The service targets a difficult custody problem: how banks, exchanges and professional asset managers can authorise blockchain transfers while limiting the risk that one operator, host or credential can expose every asset in a signing wallet. Its design distributes shares of a signing key among independent confidential-compute nodes, backed by hardware-protected encryption keys and attestation. That technical structure can alter the threat model, but does not transfer legal custody obligations to Google or by itself demonstrate compliance with a financial regulator's safeguarding rules.[1][2]

How threshold signatures change the failure scenario

Google describes a hardened variant of the DKLS23 threshold ECDSA protocol, in which nodes co-sign without assembling the entire private key as plaintext. A compromise of fewer nodes than the required signing threshold cannot alone produce an unauthorised signature in that model. Yet sufficient colluding or compromised parties, failures in transaction policy or administration, and poorly controlled recovery operations remain live risks. Hardware separation is not a substitute for segregated duties, audit logs and legal-entity controls.[1][3]

The Bitcoin reference architecture compares this method with Google Cloud KMS and Cloud HSM: a conventional single-key arrangement holds a complete cryptographic signing key inside an HSM, whereas the distributed arrangement protects independent shares in confidential virtual-machine enclaves. Google explains that non-hardened Bitcoin BIP32 child-derivation offsets can be applied to shares without an extra inter-node network round, offering an integration route for institutional wallet infrastructure that already tracks hierarchical addresses.[2]

Supported chains and unresolved commercial questions

The product documentation lists threshold ECDSA on secp256k1, relevant to Bitcoin, Ethereum and compatible EVM networks. It also lists EdDSA on Ed25519, typically used for Solana, as “coming soon”. Listing the latter in the architecture is not evidence that Solana signing is operational in the current preview. Developers need to confirm which chain, signing algorithm, key-policy mode and transaction workflow are enabled for their specific tenant.[1][3]

The Bitcoin custody documentation includes illustrative signing performance and service-design comparisons, but these are vendor documentation, not independent production benchmarks for a named banking customer. Pre-GA service terms warn of limited support and an as-is offering; no assured general-availability date, published production adoption figures or universal pricing schedule is established by the preview announcement. A broker evaluating the system must document concentration risk, recoverability, cross-region resilience, withdrawal limits and responsibility if the threshold cannot be met.[2][1]

This is a potentially material infrastructure development because signing controls sit at the junction of the custody ledger, exchange execution and operational settlement. Its immediate news value lies in Google's documented architecture and preview availability. It would be inaccurate to claim that customers can now deposit funds with Google as a regulated custodian, or that every digital-asset intermediary has access to a commercially supported production service.[1][4]

Report an error or submit an update