Anchor-DKG: Distributed Key Generation with Repeating Parties

A party may participate in multiple threshold cryptosystems. For example, it may serve on multiple overlapping threshold committees in a proof-of-stake blockchain or a distributed oracle network, or act as a client of multiple cryptocurrency wallet services built on threshold cryptography. With conventional distributed key generation (DKG), each threshold system independently generates its key shares, imposing significant key-management overhead on such a repeating party. In contrast, modern key-management practice favors deriving all cryptographic material deterministically from a single master key, raising a fundamental question: Can DKG be reconciled with key derivation while preserving security and compatibility with legacy threshold systems? We present Anchor-DKG, a new DKG protocol that allows up to t rec (the reconstruction threshold) parties to deterministically fix their secret key shares while retaining standard security guarantees. Anchor-DKG supports concurrent executions with overlapping participants across multiple DKG instances and remains fully compatible with legacy threshold schemes, including ECDSA, BLS, Schnorr, and ElGamal. At the core of Anchor DKG lies a new technique: fixed-point distributed polynomial sampling (FpDpS). FpDpS allows parties to jointly sample a random (t rec -1)-degree polynomial f such that f (i) = s i at designated points i, where each s i can be a private input, e.g., a key derived from a master secret. The final secret key remains f (0), ensuring compatibility with existing discrete-log-based threshold systems. We provide an efficient construction of Anchor DKG under standard cryptographic assumptions, which, compared to classical constructions such as Gennaro et al. (J.Cryptol. 2007), only incurs one more point-to-point round and marginal computation. Experimental results show that, for a network size of n = 128, our protocol incurs a per-party computation cost of 1.59 s, compared to 1.36 s for GJKR. * Part of this work was done while Hanwen was at the University of Sydney. 1 decentralized oracle networks [3] , and in mitigating long-range attacks [29] and MEV attacks in Decentralized Finance [13] . A classical (n, t rec ) threshold cryptosystem begins with a setup phase in which a public key pk is generated and the corresponding secret key sk is shared among n participants so that any subset of t rec shares can reconstruct sk. Without a trusted dealer to generate and distribute the shares, the n parties must run a distributed key generation (DKG) protocol to complete the setup. DKG is thus a cornerstone of threshold cryptography, and a substantial body of work (see, e.g., [8, 6, 28, 29, 38, 39, 27, 37] ) has sought to improve it along various dimensions, including communication and round complexity, setup assumptions, and corruption thresholds. Key management challenges in complex threshold systems. Prior work on distributed key generation has primarily focused on the efficiency and security of generating distributed keys for individual threshold cryptosystems. We investigate a complementary dimension: how to make these keys easier to manage, especially when a user participates in multiple threshold cryptosystems and therefore holds multiple secret key shares. A natural example arises from cryptocurrency wallet services built on threshold cryptography. A user often needs to manage multiple cryptocurrency keys. In self-custody settings, such as those adopted by BitGo Wallet 1 , the user may retain some of the shares themselves. This directly creates the burden of managing multiple independent secret values on the user side. The challenge is further amplified when some shares are intended to be kept on a "cold" device or even written down on paper for additional security, making the management of multiple key shares both cumbersome and error-prone. Beyond cryptocurrency wallets, an increasing number of real-world systems deploy overlapping threshold cryptosystems. Examples include restaking protocols, such as EigenLayer [4] , where parties may serve on committees for different decentralized applications, and decentralized oracle networks, such as Chainlink [3] , where nodes may belong to multiple committees. These scenarios reveal a common pattern: a party may repeatedly participate in multiple threshold cryptosystems and consequently hold multiple secret key shares. We refer to such a participant as a repeating party. Under conventional DKG, a repeating party involved in k threshold systems must execute k independent DKG instances and manage k distinct secret key shares, making secure key management a fundamental challenge in complex threshold systems. Recommended practice in the non-threshold setting. Key storage and management is a long-standing challenge even in conventional, non-threshold settings. A standard approach is to protect critical secret keys using secure hardware modules, such as HSMs, TPMs, hardware wallets, or other secure elements. These mechani