The Decentralized Key Generation (DKG) ceremony for the Zama mainnet has completed successfully. Between 19:06 UTC on November 25, 2025 and 01:46 UTC on November 28, 2025, 13 independent parties jointly carried out one of the most advanced cryptographic protocols ever deployed in production. All parties completed the protocol successfully, with no crashes, dropouts, or invalid messages.
Key stats:
The goal of the Zama DKG is to generate the public encryption key for the Zama Confidential Blockchain mainnet, along with a distributed, secret-shared version of the corresponding private key—without any single party ever knowing the full secret. No individual, organization, or system ever had access to the full private key at any point. Together with the threshold decryption protocol, this DKG forms the Zama decentralized Key Management Service (KMS).
These genesis operators are well-established entities—such as validators, infrastructure providers, and custodians—which together secure over $100b in assets outside of Zama. Any attempt to misbehave would be detected by the other operators and would likely damage the offending party’s broader business interests. This provides security not only through cryptography, but also through strong economic incentives and reputation.
.webp)
The Zama mainnet uses Fully Homomorphic Encryption (FHE), specifically the TFHE scheme, to compute on encrypted data. In FHE systems, performance is highly sensitive to how cryptographic keys are generated. While faster methods exist to generate distributed keys, they produce keys with different properties and worse performance than keys generated using the standard, non-distributed algorithm.
Our MPC protocol was designed to overcome this limitation and offer similar performances as non-decentralized FHE flavors. However, most MPC protocols work over prime fields, which are easier to handle, while TFHE relies on arithmetic modulo powers of two, which requires working over Galois rings—a much more difficult setting.
Another difficulty with decentralized key generation is that participants can go offline at any time, for example due to a networking or data center issue, or they can act maliciously trying to disrupt the computation. Restarting the key generation each time a single operator is unresponsive or disruptive would make it nearly impossible to complete, which is why we need resiliency against this, something called “robustness” in MPC. Our protocol was designed to withstand up to 4 offline or malicious operators, meaning that as long as 9 operators are running the software correctly, we are guaranteed that the keys will have been generated according to the specifications. In the end, it took 55 hours for the Zama DKG to complete and produce the mainnet keys.
To the best of our knowledge, this is the first time a robust MPC protocol over Galois rings has been executed at this scale in a production environment.
MPC is a well established technology used extensively in blockchain for managing wallets. However, these deployments typically involve only 3 parties and do not offer robustness. The Zama DKG on the other hand involved 13 parties running a protocol, making it the largest robust MPC protocol in production today.
Successfully running the DKG required more than advanced mathematics. The execution environment was hardened using multiple layers of security:
Hardware Enclaves
Each MPC node runs inside an AWS Nitro Enclave, which provides strong hardware-level isolation. Even a system administrator with full machine access cannot read enclave memory. This means Amazon would need to collude with operators to break the security of the Zama KMS.
Hardware Security Modules (HSMs)
Encrypted key material is stored in the AWS KMS, using remote attestations to ensure the secret shares can only be accessed by Nitro enclaves running the approved, verified software version. This ensures secret key shares are never stored in plaintext, while being decrypted only inside verified enclaves and destroyed when an operator leaves the protocol.
Mutual TLS (mTLS) and Attested Enclave-to-Enclave Communication
Unlike standard TLS, mTLS authenticates both ends of a connection. This prevents a malicious party from impersonating an honest operator. Operators can thus only communicate with peers that present valid cryptographic identities and attestations that they are running the expected software. If a party runs modified or malicious code, other operators simply refuse to connect. While remote attestation itself is not new, we are not aware of any other production MPC system that combines it this tightly with protocol-level authentication.
News, research and product releases
Protocol
Solutions
PRODUCTS
Resources
community
company
.svg)
.svg){kind=icon}
