Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 38 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
A threshold signature scheme (TSS) is a cryptographic protocol that enables a group of participants to collectively produce a valid digital signature, where only a threshold number (t-of-n) of participants must cooperate to generate the signature, without any single party having access to the complete private key.
A threshold signature scheme (TSS) is a type of digital signature protocol used in distributed cryptographic systems, particularly by Multi-party Computation (MPC) wallets. In TSS, signature authority is shared among multiple parties such that any subset of t participants (where t ≤ n) can cooperatively generate a valid signature, but fewer than t participants cannot. This is commonly expressed as a t-of-n threshold scheme.
According to the canonical KERI/GLEIF glossary, TSS serves two primary purposes:
KERI supports multi-sig AIDs where control authority requires threshold-based signatures. The protocol distinguishes between different multi-signature configurations:
: Multiple cooperatively manage an identifier, with each controller holding one or more keys. The determines how many signatures are required.
When implementing threshold signature schemes in KERI systems:
Security Analysis: Determine the maximum number of participants you can tolerate being compromised (f). Set threshold t ≥ n - f to maintain security.
Availability Requirements: Ensure t is low enough that the required number of participants will typically be available. For high-availability systems, consider t ≤ n/2.
Byzantine Fault Tolerance: For BFT properties, use t ≥ 2f + 1 where f is the maximum number of Byzantine (arbitrarily faulty) participants.
Operational Overhead: Higher thresholds increase coordination complexity. Balance security needs against operational practicality.
Witness Threshold Configuration: In establishment events, set witness threshold (wt) based on your trust model. GLEIF vLEI credentials typically use 4 witnesses with threshold 2, balancing security and availability.
TOAD Selection: The Threshold of Accountable Duplicity should satisfy M ≥ N - F where N is total witnesses and F is maximum faulty witnesses. This ensures sufficient witness confirmation for accountability.
Pre-rotation with Thresholds: When using threshold signatures with pre-rotation, ensure next key digests (n field) represent the threshold configuration for the next rotation, not individual key digests.
Fractional Weights: Use tholder objects with fractional weights when different participants should have different authority levels. Ensure weights sum appropriately for your threshold requirements.
Key Share Protection: Treat key shares with the same security as complete private keys. Compromise of t shares enables complete key reconstruction.
Distributed Key Generation: Use DKG protocols to generate key shares without any party ever possessing the complete private key, eliminating setup vulnerabilities.
Proactive Refresh: Implement periodic key share refreshing to provide forward security against gradual compromise, especially in long-lived identifiers.
Secure Communication: Ensure all multi-party computation rounds use authenticated, encrypted channels to prevent man-in-the-middle attacks during signing.
Weighted Multi-Sig: Different controllers can have different voting power through fractional weights. The KERI glossary describes a weight-of-weights architecture with two levels in multi-signature weighted thresholds, specifically designed for "tightly cooperating teams":
This two-level approach addresses KERI's focus on specific use cases rather than attempting to solve all coordination scenarios. Other use cases can be addressed through alternative KERI mechanisms such as delegation.
Threshold signatures are fundamental to KERI's establishment events. An establishment event is a key event that establishes or changes the key state, including the current set of authoritative keypairs for an AID.
Inception Events: The inception event establishes the initial key state, including:
kt): Number or fractional weights of signatures required from current keysnt): Threshold for the next rotationk): Ordered list of public keysn): Pre-rotated commitments to future keysRotation Events: Rotation events change the key state and require signatures meeting the previous event's next threshold. The rotation establishes new current and next thresholds for subsequent operations.
The KERI glossary defines current threshold as representing "the number or fractional weights of signatures from the given set of current keys required to be attached to a Message for the Message to be considered fully signed." Similarly, next threshold represents the requirements for future establishment events.
KERI's witness infrastructure also employs threshold concepts:
Witness Threshold (wt): The minimum number of witness receipts required to consider an event sufficiently witnessed, as specified in establishment events.
Threshold of Accountable Duplicity (TOAD): A critical threshold concept where the controller declares accountability for an event when any subset M of the N witnesses confirm that event. The KERI glossary defines TOAD as: "The threshold number M that the controller declares to accept accountability for an event when any subset M of the N witnesses confirm that event. The threshold M indicates the minimum number of confirming witnesses the controller deems sufficient given some number F of potentially faulty witnesses, given that M >= N - F."
This mechanism enables controllers to provide themselves with any degree of protection against potentially faulty witnesses while maintaining accountability.
KAACE Algorithm: KERI's Agreement Algorithm for Control Establishment uses witness thresholds to achieve consensus. The glossary defines KAACE as "Agreement on an event in a key event log KEL means each witness has observed the exact version of the event and each witness' receipt has been received by every other witness. Control establishment means that the set of agreeing witnesses, along with the controller of the identifier and associated keypairs, create a verifiable way to establish control authority for an identifier by reading all of the events in the KEL that have been agreed upon by the witnesses and the controller."
The KERI ecosystem documentation emphasizes threshold structure security as a fundamental principle. As described in the glossary: "A threshold structure for security allows for weaker key management or execution environment infrastructure individually, but achieve greater overall security by multiplying the number of attack surfaces that an attacker must overcome to compromise a system."
This principle appears in the KERI Security Deep Dive presentation, which positions threshold structures as complementary to other security approaches:
Defense Through Multiplication: Rather than relying on a single highly-secure component, the system distributes trust across multiple components. An attacker must successfully compromise multiple independent components to breach the system.
Multi-Factor Authentication Analogy: The documentation uses MFA as an example, combining "something you have" (hardware token) with "something you know" (password), where the combination provides significantly stronger security than either factor alone.
Witness and Watcher Networks: The KERI architecture exemplifies this principle, as noted in the glossary: "each individual witness or watcher may be relatively insecure" but "the networks independently multiply attack surfaces," achieving high overall security despite individually weaker components.
In KERI's CESR (Composable Event Streaming Representation) encoding, threshold signatures in multi-key scenarios are represented as indexed signatures. The glossary defines an indexed signature (also called siger) as:
"An indexed signature attachment is used when signing anything with a multi-key autonomic identifier. The index is included as part of the attachment, so a verifier knows which of the multiple public keys was used to generate a specific signature."
The format embeds an index indicating which key from a multi-key AID's key set was used:
03.<binary signature>
The prefix 03 indicates the signature was created using the public key at index 3 in the AID's ordered key list. The entire structure is encoded using CESR qualified base64.
For threshold multi-signature schemes, CESR employs dual indexed codes - "a context-specific coding scheme, for the common use case of thresholded multi-signature schemes in CESR." The glossary further explains this as "a specialized encoding technique within the Composable Event Streaming Representation (CESR) protocol, specifically optimized for thresholded multi-signature schemes."
For 64-byte signatures with pad size 2, the encoding uses two characters:
This compact approach enables efficient stream processing while maintaining CESR's self-describing composability properties.
CESR supports dual text-binary encoding with full composability. The glossary defines composability as "short for text-binary concatenation composability. An encoding has Composability when any set of Self-Framing concatenated Primitives expressed in either the Text domain or Binary domain may be converted as a group to the other Domain and back again without loss."
Text Domain: Signatures encoded as URL-safe base64 strings with prepended derivation codes indicating the cryptographic algorithm and encoding format.
Binary Domain: Compact binary representation with equivalent derivation codes in binary format, enabling efficient storage and transmission.
Round-trip Conversion: Any set of concatenated CESR primitives can be converted between text and binary domains without loss, supporting both human-readable formats and efficient binary protocols.
KERI uses tholder objects (threshold holder) to manage fractionally-weighted thresholds. The glossary defines a tholder as "a t-holder object that supports fractionally-weighted thresholds."
A tholder supports:
Integer Thresholds: Simple t-of-n schemes (e.g., "2-of-3" requires 2 signatures from 3 possible signers)
Fractional Weights: Different keys carry different weights, enabling sophisticated governance models where some participants have greater signing authority. The glossary notes this enables "weighted multi-sig" configurations where "different controllers can have different voting power."
Dynamic Thresholds: Threshold values can change across rotation events, allowing governance evolution over time as the key state changes.
The KERI glossary distinguishes between threshold signatures and collective signatures. A collective signature is defined as "a group signature scheme, that (i) is shared by a set of signing groups and (ii) combined collective signature shared by several signing groups and several individual signers."
Key characteristics of collective signatures:
Variable Length: "Collective signature have a variable length as a function of the number of signers." This distinguishes them from threshold signatures, which typically produce fixed-size outputs.
PKI Compatibility: The glossary notes "possibility of their practical using on the base of the existing public key infrastructures" as a significant merit.
Protocol Types: The scheme encompasses two types - signatures shared by signing groups, and combined signatures shared by multiple groups and individual signers.
The glossary provides a precise definition of signing threshold: "The minimum required number of participants in an event to have a supermajority so that one and only one agreement or consensus on an event may be reached."
A practical example illustrates the concept: "In a 2-of-3 signature scheme: In this configuration, the threshold is set to 2. This means that only 2 valid signatures out of a possible 3 are required. Once 2 valid signatures are provided, the signature requirement is fulfilled."
This concept is critical for:
As a contrast to threshold signature schemes, the glossary defines single-signature identifiers (also called "single-sig identifiers" or "single-sig AIDs") as "an identifier controlled by a one-of-one signing keypair." This represents the simplest form of identifier control:
This contrasts with multi-sig identifiers that require coordination among multiple signing parties according to threshold rules.
The KERI documentation provides practical context for threshold signature implementation:
The provided 100-event KEL example demonstrates how threshold signatures appear in practice:
icp) establishes initial threshold of 1rot) maintain threshold configurationkt) and next threshold (nt) parametersbt) set to 2 (backer threshold)This structure shows how threshold values are explicitly declared in CESR-encoded events and can evolve through the identifier's lifecycle.
The GLEIF vLEI ecosystem documentation demonstrates threshold signatures in organizational identity:
GAR Multisig Setup: The GAR (GLEIF Authorized Representative) system uses multi-signature identifiers where multiple representatives must coordinate to authorize credential issuance operations.
Challenge-Response Protocol: A "12-word challenge mechanism" establishes authenticated communication between threshold signature participants before cooperative signing operations.
Multisig Inception: The system uses configuration files specifying threshold parameters for group identifier creation, demonstrating practical threshold signature deployment.
The KERI pre-rotation mechanism works in conjunction with threshold signatures. As defined in the glossary, pre-rotation provides "cryptographic commitment to next rotated key set in previous rotation or inception event." The glossary further explains:
"The pre-rotation mechanism supports partial pre-rotation or more exactly partial rotation of pre-rotated keypairs. It's a rotation operation on a set of pre-rotated keys that may keep some keys in reserve (i.e unexposed) while exposing others as needed."
This enables reserve rotation, where "pre-rotated key pairs designated in one establishment event can be held in reserve and not exposed at the next (immediately subsequent) establishment event." This mechanism supports sophisticated threshold signature schemes where key exposure is carefully controlled.
The glossary describes cooperative delegation as "the way KERI addresses the security-cost-performance architecture trade-off via delegation of identifier prefixes." Delegation creates nested threshold structures:
Multi-valent Delegation: "A delegator may have multiple delegates, thereby enabling elastic horizontal scalability. Multiple delegates from a single delegator. Furthermore, each delegate may act as a delegator for its own delegates to form a nested delegation tree."
Bivalent Key Management: The glossary describes a "nested set of layered delegations in a delegation tree" that "wraps each layer with compromise recovery protection of the next higher layer." This maintains security "all the way out to the leaves in spite of the leaves using less secure key management methods."
These delegation structures often incorporate threshold signatures at multiple levels, creating hierarchical security architectures.
The KERI Security Deep Dive presentation emphasizes threshold signatures as part of a "combined arms" security strategy:
Minimally Sufficient Means: The presentation establishes that "every component of KERI is necessary to protect against known attacks" and "removing any part exposes vulnerabilities." Threshold signatures form part of this necessary security infrastructure.
Attack Surface Multiplication: Threshold structures force attackers to compromise multiple independent components. The glossary notes this principle: "An attacker must successfully compromise multiple independent components to breach the system, making the combined system more secure than any individual part."
Duplicity Detection: KERI's duplicity detection mechanisms work in conjunction with threshold signatures. Witnesses using threshold consensus can detect when a controller attempts to create conflicting event histories, even when threshold signatures are properly formed.
The KERI glossary emphasizes precise technical terminology:
Threshold vs. Multi-Signature: While related, these terms have distinct meanings. "Multi-sig" generally refers to any scheme requiring multiple signatures, while "threshold signature" specifically refers to schemes where a subset of a larger group can authorize operations.
Current vs. Next Threshold: KERI explicitly distinguishes between the threshold required for current operations (kt - current threshold) and the threshold required for the next rotation (nt - next threshold), enabling threshold evolution.
Signing vs. Rotation Authority: The glossary distinguishes signing authority ("authority to sign on behalf of the controller") from rotation authority ("exclusive right to rotate the authoritative key pair"). Threshold schemes can apply to either or both.
Threshold signature schemes in KERI represent a carefully designed approach to distributed control authority that balances security, flexibility, and practical implementation concerns. The protocol's support for weighted thresholds, reserve rotation, and nested delegation structures provides a comprehensive framework for organizational and individual identity management while maintaining the fundamental security properties of duplicity detection and cryptographic verifiability that distinguish KERI from other identity systems.
Minimize Rounds: Choose TSS protocols with minimal communication rounds to reduce latency, especially important for interactive signing scenarios.
Batch Operations: When multiple signatures are needed, batch signing operations to amortize setup costs across multiple signatures.
Caching: Cache intermediate computation results and participant public keys to accelerate repeated signing operations.
Parallel Verification: When verifying multiple threshold signatures, parallelize verification operations to utilize multi-core processors.
CESR Encoding: Ensure threshold signatures are properly encoded as indexed signatures in CESR format, maintaining composability with other KERI primitives.
Event Validation: Implement proper validation logic that checks threshold requirements against the current key state when verifying establishment events.
Witness Coordination: Coordinate threshold signing with witness infrastructure, ensuring witness receipts properly validate threshold signatures.
Rotation Protocols: Follow KERI's pre-rotation scheme when rotating threshold keys, maintaining forward security properties through cryptographic commitments to next keys.