Star DKG is a composable distributed key generation protocol designed for hardware-bound shares and mandatory co-signer wallet architectures. Read to learn more.
Many production MPC wallets and custody systems converge on the same operating model: a private key is split into shares across multiple devices or parties, so no single device ever holds the full key. Signing happens jointly across those shares. In practice, a user holds one or more devices (phone, hardware wallet, recovery device), while a service provider must co-sign every transaction for compliance, risk controls, fraud detection, or policy enforcement. This is the mandatory co-signer architecture.
Most production MPC wallets today rely on two realities:
- Hardware-enforced key isolation (TEEs, HSMs, Secure Enclaves, KMS) that prevents key export
- Mandatory co-signers for compliance, risk controls, and policy enforcement
Individually, these are well-understood and widely deployed. Together, they break the assumptions behind standard Distributed Key Generation (DKG). Classic DKG protocols assume you can open, export, or reshare secret shares to enforce consistency, or rerun protocol steps under different challenges. Non-exportable key (NXK) hardware and rollback-resistant devices make both impossible.
Wallets are composed systems. DKG runs alongside signing, policy checks, recovery, enrollment, rotation, and monitoring, often concurrently. If you're deploying MPC wallets on TEEs, HSMs, or cloud KMS, this creates a gap between how composable DKG is proved secure and how it actually runs in production.
Star DKG (SDKG) is the protocol introduced in our accompanying preprint for the mandatory co-signer topology. SDKG is designed to work with NXK constraints (non-exportability and state continuity) rather than against them. SDKG is proved UC-secure (universally composable), meaning its guarantees hold even when composed with the rest of the wallet stack under concurrency. Furthermore, it treats dynamic device enrollment as a first-class feature, with an important nuance: the star over devices is realized as a two-leaf star over roles (primary + recovery). Post-DKG enrollment installs additional KeyBox-bound instances of the recovery-role share on new devices, so the wallet public key stays fixed while “n” grows via redundant recovery devices.
TL;DR
Problem: NXK hardware blocks exported-share enforcement (openings/complaints/resharing), and state continuity blocks “rerun the same proof under a different challenge” style techniques.
Contribution: SDKG enforces transcript-level consistency in an NXK/KeyBox model and matches the mandatory co-signer (star) wallet topology, with post-DKG enrollment of additional recovery-role devices.
For the base run, the base SDKG transcript fits in ≈ 11–13 KiB at a 128-bit instantiation. After that, each additional recovery device is enrolled via a small one-shot post-DKG flow that preserves the existing public key. Full protocol details and proofs are in the preprint.
What NXK Breaks
DKG has two jobs: (1) jointly generate a public key without a trusted dealer, and (2) ensure each party ends with a secret share such that everyone agrees those shares define a single consistent key.
Figure 1: SDKG: The service provider (center) must participate in every signing ceremony, and either the primary role device or the recovery-role device completes an authorized pair. Additional recovery devices are enrolled post-DKG as redundant front-ends, each hosting its own KeyBox-bound instance of the recovery-role share.
When shares are movable, many DKGs enforce consistency with a verifiable-sharing enforcement layer (complaints, openings, and sometimes resharing/reconfiguration). In composable (UC-style) analyses, related mechanisms also support the proof strategy: ruling out equivocation and “split views” even under concurrency.
Under NXK-style isolation, two constraints bite at once:
- NXK blocks exported-share enforcement. A share created inside a restricted keystore/KMS/HSM cannot be extracted—not as raw bytes, and not as any caller-invertible affine image that would enable reconstruction outside the KeyBox boundary.
- State continuity blocks rewinding. Rollback-resistant hardware rejects forking/resetting, so techniques that rely on rerunning a prover (or the same protocol state) under a different challenge do not match operational reality.
A useful rule of thumb is: if your consistency proof needs “open your share” or “rerun the same proof with a different challenge,” a rollback-resistant enclave/KMS profile simply won’t let you do that. So to get composable security in an NXK setting, you need enforcement mechanisms with straight-line (non-rewinding) extraction.
Figure 2: KeyBox boundary: resident shares and key-dependent arithmetic stay inside. Only public certificates, proofs, sealed blobs, and public keys leave. Consistency checks are driven by the public transcript and host-side verification.
The Core Idea: Separate Confidentiality from Consistency
In the NXK setting, it helps to separate two obligations that classic DKGs often bundle together:
- Confidentiality: do not leak the share.
- Consistency: ensure the public transcript pins down one well-defined key (no equivocation or split views).
As illustrated in Figure 2, SDKG delegates confidentiality to the hardware boundary itself. The remaining task is to enforce consistency without exporting shares or relying on rewinding. SDKG does this with three ingredients.
1. Unique Structure Verification (USV)
If a scalar lives entirely inside hardware, verifiers still need a way to derive (and agree on) the corresponding public group element; otherwise the transcript is not checkable. In some KMS-style profiles, even retrieving the public point for an ephemeral scalar is gated behind separate permissions.
USV is a non-interactive publicly verifiable certificate attached to commitment-shaped material that lets anyone deterministically derive the canonical public point from the transcript without learning the underlying scalar. Under the Discrete Logarithm assumption, USV is equivocation-resistant: an adversary cannot produce two valid certificates for the same commitment that yield different public points.
Beyond DKG: USV as a reusable primitive
USV is not inherently specific to DKG. For builders working with rollback-resistant enclaves outside DKG, such as commit-reveal schemes, threshold BLS, or randomness beacons, USV provides an analogous certificate mechanism for binding hardware-resident scalars to public group elements. See Section 5 of the preprint for more details.
2. Straight-Line Extractable Proofs (No Rewinding)
SDKG enforces the affine relations that VSS-style mechanisms typically certify using non-interactive arguments of knowledge built via the Fischlin transform. These proofs support straight-line extraction: the extractor recovers witnesses by observing the prover’s hash-oracle interactions, without rewinding. This aligns directly with state-continuous hardware that rejects rollback.
3. KeyBox-to-KeyBox Sealing for Device Enrollment
SDKG separates the base DKG from device enrollment. After the base run completes, additional recovery devices are enrolled without resharing and without re-running DKG. Existing devices encrypt enrollment material directly to a new device’s attested hardware boundary (hardware-to-hardware sealing). The new device decrypts the material internally and installs a new KeyBox-bound instance of the recovery-role share; no share-derived plaintext ever appears in the external transcript.
Protocol at a Glance
SDKG is designed for the star access structure.
Base run (1+1-out-of-3). A constant-round protocol among the service, a primary-role device, and a recovery role device. The transcript fixes a single wallet public key, and each participant installs a non-exportable share inside its hardware boundary. USV makes the transcript structure-complete so verifiers can derive the public points they need for consistency checks. Fischlin-based proofs then certify the required cross-party relations in straight-line, replacing complaint/opening/resharing logic that assumes movable shares.
Device enrollment (post-DKG). Additional recovery devices are added later through the KeyBox-to-KeyBox sealing mechanism described above. Enrollment is one-shot per device and preserves the existing public key by installing further KeyBox-bound instances of the recovery-role share.
Caveats (In Brief)
SDKG is proved UC-secure in an idealized KeyBox abstraction with non-exportability and state continuity, rather than for a specific hardware product. The proof uses a Random Oracle Model (specifically, a global RO with context-restricted programmability). If you don’t live in proof-land: this is a standard way to model hash functions in Fiat-Shamir-style non-interactive proofs, and “context-restricted” means the proof only programs hashes within the intended protocol session.
The protocol targets the star (mandatory co-signer) access structure rather than general t-out-of-n threshold DKG. As is typical for DKG-style protocols without guaranteed output delivery, SDKG does not provide fairness: a malicious party can selectively abort. The preprint discusses these assumptions, maps them to deployment families, and provides a profile-capture checklist and concrete size estimates.
Where the Work Fits
This work sits at the intersection of two production realities: (i) wallets and custody systems increasingly want hardware-enforced non-exportability as a strong mitigation against key exfiltration, and (ii) real systems compose many protocols and services under concurrency, so arguments that survive composition matter, especially when cryptographic logic is pushed into hardware boundaries.
If you’re building multi-device wallets on TEEs, HSMs, or cloud KMS-like APIs, the preprint formalizes why “classic DKG + exported-share enforcement” breaks under NXK constraints, and provides a concrete alternative for the mandatory co-signer pattern, including post-DKG enrollment of additional recovery devices as redundant front-ends.
How to read the preprint (quick guide)
• If you want the model: Section 2 (KeyBox/NXK profiles, key-opacity, state continuity).
• If you want the incompatibility argument: Section 3 (why VSS/exported-share enforcement clashes with NXK).
• If you want the new primitive: Section 5 (USV certificates).
• If you want the protocol: Section 7 (SDKG).
• If you want the UC proof: Sections 8–9 (hybrids, gRO-CRP, extraction/simulation).
• If you want deployment mapping: Appendix B + checklist (candidate KeyBox families).
The preprint is available on arXiv: 2602.22187.
*The views expressed in this post are solely those of the author and do not necessarily reflect those of Circle Internet or any affiliated organizations. This post accompanies a research preprint and does not constitute a product announcement. Circle has commercial interests in the topics discussed in this post, including as a provider of wallet infrastructure. This analysis reflects the author's independent research and does not constitute investment advice or a representation of Circle's product roadmap.*
