TLDR
- Sui introduced a decentralized Seal key server on testnet using MPC and threshold cryptography.
- The system distributes key control across operators so no single party holds the full key.
- Developers can integrate the new server using the same Seal SDK and encryption workflow.
- Key server membership can rotate without re encrypting existing data or changing policies.
Sui has introduced a decentralized Seal key server on its testnet. The system aims to strengthen encryption infrastructure for developers and applications on the network. The new server distributes key management across several independent operators instead of relying on a single authority.
Seal functions as Sui’s programmable encryption layer. It allows developers to control access to encrypted data using policies stored onchain. The new decentralized key server extends this design while keeping the existing developer workflow unchanged.
The announcement states that the system uses multi party computation and threshold cryptography. These methods distribute trust among operators and prevent any participant from holding a full master key.
Developers can test the decentralized server on testnet through the Seal SDK version 1.1.0 or later. Basic access on testnet does not require API credentials.
Distributed key management through MPC infrastructure
The decentralized Seal key server appears as a single logical service to applications. Developers configure one object ID, one public key, and one endpoint. The endpoint connects to a trustless aggregator that coordinates the system.
Behind the service, multiple operators maintain partial key shares. These shares are created through a Distributed Key Generation ceremony. The process produces separate pieces of the key without assembling a complete master key.
Each operator runs an independent key server that stores only its share. When a client requests a decryption key, the request goes through the aggregator. The aggregator collects encrypted partial responses from operators and combines them into a single encrypted output.
The client receives the final encrypted key and performs the final decryption locally. According to the announcement, “The aggregator cannot decrypt data and only coordinates encrypted responses.” This design keeps plaintext key material on the client side.
The distributed model allows groups of operators to form committees. Each committee can run its own decentralized key server with defined thresholds and governance rules.
Stable encryption even as operators change
Infrastructure providers may change over time. Operators may join or leave a committee for technical or operational reasons. The decentralized Seal key server addresses this by allowing membership rotation without changing the public key.
Operator updates occur through coordinated DKG rotation ceremonies. These ceremonies redistribute key shares among operators while maintaining the same public key and onchain object ID.
Because the public key remains unchanged, existing encrypted data stays valid. Applications do not need to re encrypt stored information when operators rotate. Policies defined onchain also remain unchanged.
This design helps long running applications maintain stable encryption infrastructure. Developers avoid operational work that usually appears during key rotation.
Developer workflow remains unchanged
Sui designed the decentralized key server to work with the existing Seal developer environment. Applications continue to use the same SDK, encryption flows, and Move based access policies.
The main change appears in configuration. Instead of listing multiple key servers in the SealClient setup, developers add a decentralized server object ID and an aggregator URL.
The aggregator manages communication with the internal operator network. It collects partial key responses and returns the combined result to the client.
The decentralized server also fits into existing threshold configurations. In the SDK, it counts as one server within a threshold model. Developers can combine decentralized servers with independent key servers.
This flexibility allows several trust models. Applications may rely on independent servers, decentralized servers, or a hybrid setup.
The first decentralized Seal key server currently operates on testnet with a three of five internal threshold. Operators are geographically distributed and include Mysten. A Mysten operated aggregator coordinates requests.





