Introducing the Decentralized Seal Key Server, Now live on Testnet

Main Takeaways

• Seal now supports a Decentralized Key Server that distributes trust across multiple independent operators using threshold cryptography, so no single party ever holds a complete key.
• Membership can rotate over time without re-encrypting existing data, keeping public keys and onchain policies stable as infrastructure evolves.
• Integration requires minimal changes: same SDK, same encryption flows, same Move policies, just a new server type to configure.

Overview

Seal is Sui’s programmable encryption layer, letting developers define onchain policies for who can access encrypted data, without relying on a centralized service to manage keys. From day one, developers have been able to spread trust across independent key servers, choosing their own client-level threshold before access is granted. That flexibility remains core to Seal’s design.

Today, we’re expanding those options with the Decentralized Seal Key Server, powered by multi-party computation (MPC), now live on Testnet.

This new server type embeds distributed key trust directly into the infrastructure layer. To your application, it looks like a single logical key server. Internally, it enforces threshold cryptography across multiple independent operators. You gain stronger decentralization and smoother operator rotation, without changing how you build with Seal.

Inside the Decentralized Key Server

From your application’s perspective, a Decentralized Seal Key Server is simple. It exposes one onchain object ID, one public key, and one endpoint (via a trustless aggregator). You configure it like any other Seal key server, and your policies and encryption flows remain unchanged.

Behind the scenes, operators coordinate through a Distributed Key Generation (DKG) ceremony to produce distributed key shares. No single operator ever holds the full master key. Each operator runs a key server that holds only its partial share. When a client requests a decryption key, the request flows through an aggregator, which collects encrypted partial responses and combines them into a single encrypted result. The client decrypts the final key locally.

The aggregator cannot decrypt data. It only coordinates encrypted responses. The master key never exists in one place, and plaintext key material remains client-side.

The model is open by design. Any group of operators can coordinate to form their own decentralized committee, run a DKG ceremony, and deploy a decentralized key server with their chosen membership, threshold, and governance process. Seal simply defines the server type and integration pattern; how committees are formed and operated remains flexible.

Rotation without Re-Encryption

Infrastructure evolves. Operators may need to be added, removed, or replaced over time. Within a Decentralized Seal Key Server, membership changes are handled through coordinated DKG rotation ceremonies that update operator shares while preserving the same public key and onchain object ID.

Because the public key remains stable, data encrypted against that decentralized key server does not need to be re-encrypted when membership rotates. Your onchain policies remain the same, and clients do not require updates.

This behavior applies to rotations within a decentralized key server. For long-lived applications, this reduces operational overhead without weakening trust guarantees.

Same Code, Stronger Infrastructure

One of the primary goals of this release was simple: expanding the trust model without introducing new complexity for developers.

From an integration standpoint, very little changes. You continue to use the same Seal SDK, the same encryption and decryption flows, and the same seal_approve Move policies that define your access control logic onchain. Your policy layer remains untouched. Your application still encrypts data client-side, and decryption still requires policy approval followed by key retrieval.

The main difference is in configuration. Instead of listing multiple independent key servers in your SealClient, you configure a single decentralized key server object ID and provide the corresponding aggregator URL. The aggregator acts as the gateway that coordinates partial key responses from internal operators. Beyond specifying that URL, your encryption and decryption logic does not change.

Threshold composition also remains familiar. A decentralized key server counts as one server in your threshold configuration, just like an independent key server would. This means you can continue to compose trust however you like, using decentralized-only setups, independent-only setups, or hybrid configurations that combine both. The SDK treats them consistently, and your application logic remains the same.

In short, the decentralized model strengthens infrastructure-level guarantees while preserving the developer experience Seal users already know.

Expanding Seal’s Trust Model and Providing Optionality

The Decentralized Seal Key Server doesn’t replace independent key servers, rather it expands the range of trust configurations available in Seal. 

Independent key servers remain a core primitive. They offer direct operator relationships, explicit threshold composition at the client layer, and a simple, modular deployment model. For many builders, especially those who want granular control over operator selection or lightweight infrastructure, this model continues to make sense.

The decentralized model introduces a different operational tradeoff. By embedding threshold cryptography inside the server layer, it reduces coordination overhead and enables seamless membership rotation with a stable public key. This can be especially useful for long-lived applications or deployments that prioritize infrastructure-level decentralization.

Because both models share the same SDK, policy framework, and encryption flows, you don’t have to choose one globally. You can use independent servers, decentralized servers, or combine them in hybrid configurations, tuning trust assumptions to match your application’s needs. The decentralized key server simply adds another dimension to how you express and manage trust.

Available Now on Testnet

The first Decentralized Seal Key Server is now live on Testnet. It runs with a 3-of-5 internal threshold, geo-distributed operators (including Mysten), and a Mysten-operated aggregator. Basic Testnet usage does not require API credentials.

Support is available in Seal SDK v1.1.0+. You can find the object ID and aggregator URL in the verified key servers list, along with full integration details in the Seal documentation.

Configure it in your Seal SDK, and experiment with different trust models: independent, decentralized, or hybrid, within the same policy and encryption framework.

If you are an infrastructure provider, node operator, or enterprise interested in operating your own Decentralized Seal Key Server, you can follow the committee operator guide to set up an MPC committee with your preferred members and trust assumptions. We encourage early operators to experiment on Testnet and reach out with feedback or questions as we continue refining the operator experience.

Mainnet support and expanded deployment options are coming next.