Operational Flexibility: Different thresholds can be set for different operations. For example, a custodial rotation might use a lower threshold for day-to-day signing operations while maintaining a higher threshold for key rotation authority.

Delegation Patterns: Thresholds enable sophisticated delegation hierarchies where signing authority can be separated from rotation authority, allowing operational delegation without surrendering ultimate control.

Type Classification

Signing thresholds in KERI are classified into several types:

Simple Integer Thresholds: The most common form, specifying an exact number of required signatures. A threshold of "2" in a 3-key configuration creates a 2-of-3 multisig scheme.

Fractionally-Weighted Thresholds: Advanced configurations where different keys carry different weights. A threshold of "1/2" requires signatures totaling at least half the total weight. This is managed by the tholder object in KERI implementations.

Ample Thresholds: A special calculated threshold that ensures Byzantine fault tolerance. The ample value guarantees that at most one sufficient agreement can occur, preventing split consensus even with faulty participants.

Cryptographic Properties

Threshold Signature Schemes

KERI's signing threshold mechanism implements a form of Threshold Signature Scheme (TSS), though with important distinctions from traditional cryptographic TSS implementations:

Non-Interactive Verification: Unlike some TSS schemes that require interactive protocols, KERI's threshold verification is non-interactive. Each signature is independently verifiable against its corresponding public key, and threshold satisfaction is determined by counting valid signatures.

Flexible Cryptographic Agility: KERI supports multiple signature algorithms simultaneously within a single threshold configuration. Different keys in the set may use different cryptographic suites (Ed25519, ECDSA, etc.), with the threshold applying to the count or weight of valid signatures regardless of algorithm.

Post-Quantum Readiness: The threshold mechanism is algorithm-agnostic, allowing seamless integration of post-quantum signature schemes as they become standardized. The threshold logic remains unchanged while the underlying signature algorithms can be upgraded.

Security Properties

Fault Tolerance: A properly configured threshold provides resilience against key compromise. In an M-of-N scheme, up to (N-M) keys can be compromised without losing security, as long as M honest keys remain.

Liveness Guarantees: The threshold must be set such that enough keys are available to meet it under normal operations. Setting thresholds too high can create operational deadlock if key holders become unavailable.

Byzantine Resistance: When combined with witness infrastructure and the KAACE algorithm, thresholds provide Byzantine fault tolerance. The ample calculation ensures that even with faulty participants, at most one valid consensus can emerge.

Key Management Implications

Dual Threshold Architecture: KERI's pre-rotation mechanism requires managing two thresholds:

• Current threshold: For validating operations with current keys
• Next threshold: For validating rotation to pre-committed keys

This dual structure enables partial rotation, where only a threshold-satisfying subset of pre-rotated keys participates in a rotation event, with others held in reserve.

Threshold Transitions: During rotation events, both the prior next threshold and the new current threshold must be satisfied. This ensures cryptographic continuity across key state changes.

Data Format & Encoding

CESR Representation

Signing thresholds appear in CESR-encoded key events as JSON string fields within the event message body. The threshold is not itself a CESR primitive but rather a parameter that governs how CESR-encoded signatures are validated.

In Inception Events:

{
  "v": "KERI10JSON0000e6_",
  "t": "icp",
  "d": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
  "i": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
  "s": "0",
  "kt": "2",
  "k": [
    "DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
    "DwJh1Xl2lkqZG4NTdUdqnbFJDa6ZyxCCBJq7UABlttIN",
    "D1zxxf8u4Hx5IPraZzmStfSCZFZbDzMHjqVcFW5OfPBD"
  ],
  "nt": "2",
  "n": [
    "ETNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
    "EYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS",
    "EnmwyZdi0d8JZAoTNZYAfSVPzhzaU6JR2H3ULvS6b5CM"
  ],
  "bt": "2",
  "b": [
    "BBilc4-L3tFUnfM_wJr4S4OJanAv_VmF_dJNN6vkf2Ha",
    "BLskRTInXnMxWaGqcpSyMgo0nYbalW99cGZESrz3zapM"
  ],
  "c": [],
  "a": []
}

In this example:

• "kt": "2" specifies the current signing threshold of 2 signatures required from the 3 keys in the k array
• "nt": "2" specifies the next threshold of 2 signatures required from the 3 pre-rotated key digests in the n array
• "bt": "2" specifies the witness threshold (TOAD) of 2 witness receipts required

In Rotation Events:

{
  "v": "KERI10JSON000160_",
  "t": "rot",
  "d": "E8JZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d",
  "i": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
  "s": "1",
  "p": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
  "kt": "2",
  "k": [
    "DTNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
    "DYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS"
  ],
  "nt": "2",
  "n": [
    "EJR2nmwyZ2i0dzaU6ULvS6b5CM8JZAoTNZH3YAfSVPzh",
    "ETNZH3ULvS6bYAfSVPzhzaU6JR2nmwyZfi0d8JZ5s8bk"
  ],
  "br": [],
  "ba": [],
  "a": []
}

The rotation event maintains threshold fields that may differ from the prior event, enabling threshold changes during rotation.

Text and Binary Representations

Threshold values are represented as JSON string fields in the text domain and as UTF-8 encoded strings in the binary domain. They are not separately CESR-encoded primitives but rather parameters within the event structure.

Integer Thresholds: Simple numeric strings like "1", "2", "3"

Fractional Thresholds: Rational number strings like "1/2", "2/3", "3/5"

The tholder object in KERI implementations parses these strings and manages the threshold logic, including fractional weight calculations.

Derivation Codes

Thresholds themselves do not have derivation codes, as they are not cryptographic primitives. However, the keys that thresholds apply to are CESR primitives with derivation codes indicating their cryptographic type:

• D prefix: Ed25519 public key (44 characters)
• 1AAA prefix: ECDSA secp256k1 public key
• E prefix: Blake3-256 digest (used for pre-rotated key commitments)

The threshold mechanism is algorithm-agnostic, operating on the count or weight of valid signatures regardless of the underlying cryptographic scheme.

Usage in KERI/ACDC

In Establishment Events

Signing thresholds are fundamental to all establishment events in KERI:

Inception Events: The initial establishment event that creates an AID must specify:

• kt: Current signing threshold for the initial key set
• nt: Next threshold for pre-rotated keys

These thresholds define the governance model from the identifier's inception.

Rotation Events: Each rotation event specifies:

• kt: New current threshold (may differ from prior)
• nt: New next threshold for subsequent rotation

Rotation events must satisfy two thresholds:

1. The prior next threshold from the previous establishment event (validating rotation authority)
2. The new current threshold being established (validating the rotation event itself)

This dual validation is critical for partial rotation scenarios.

In Non-Establishment Events

Interaction events and other non-establishment events must satisfy the current threshold from the most recent establishment event. These events do not change key state but must prove authorization from the current key set.

In Witness Configuration

The witness threshold (field bt for "backer threshold" or TOAD - Threshold of Accountable Duplicity) specifies how many witness receipts are required for an event to be considered fully witnessed. This is distinct from but analogous to the signing threshold.

The witness threshold must satisfy the ample constraint to ensure Byzantine fault tolerance:

• Given n witnesses and f potentially faulty witnesses
• The ample threshold m must satisfy: (n + f + 1)/2 ≤ m ≤ n - f

This ensures that at most one valid consensus can emerge even with faulty witnesses.

In Delegation Hierarchies

When using delegated identifiers, thresholds apply at each level of the delegation tree:

Delegator Threshold: The delegating identifier's threshold must be satisfied to approve delegation events

Delegate Threshold: The delegated identifier has its own independent threshold for its operations

This enables hierarchical governance where different organizational levels maintain appropriate threshold policies.

Common Usage Patterns

Single-Signature (1-of-1): Simplest case, used for individual identifiers or testing:

"kt": "1",
"k": ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"]

Simple Multisig (M-of-N): Common for organizational identifiers:

"kt": "2",
"k": [
  "DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
  "DwJh1Xl2lkqZG4NTdUdqnbFJDa6ZyxCCBJq7UABlttIN",
  "D1zxxf8u4Hx5IPraZzmStfSCZFZbDzMHjqVcFW5OfPBD"
]

This 2-of-3 configuration requires any 2 of the 3 key holders to sign.

Fractionally-Weighted: Advanced governance with weighted voting:

"kt": "1/2",
"k": [
  "DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",  // weight: 1/3
  "DwJh1Xl2lkqZG4NTdUdqnbFJDa6ZyxCCBJq7UABlttIN",  // weight: 1/3
  "D1zxxf8u4Hx5IPraZzmStfSCZFZbDzMHjqVcFW5OfPBD"   // weight: 1/3
]

Requires signatures totaling at least 1/2 of total weight (any 2 of 3 equal-weight keys).

Verification Procedures

To verify that a message satisfies its signing threshold:

1. Extract the threshold value from the relevant establishment event (current threshold for non-establishment events, both current and prior next thresholds for rotation events)

2. Parse attached signatures from the CESR stream following the event message

3. Verify each signature against its corresponding public key from the key list

4. Count valid signatures (or sum fractional weights for weighted schemes)

5. Compare to threshold: If count/weight ≥ threshold, the message is fully signed

For rotation events, this process must be performed twice:

• Once against the prior next key list and prior next threshold
• Once against the new current key list and new current threshold

Related Primitives

Tholder Object

The tholder (threshold holder) is the implementation object that manages signing threshold logic, particularly for fractionally-weighted schemes. It provides methods to:

• Parse threshold strings (integer or fractional)
• Calculate whether a set of signatures satisfies the threshold
• Handle weighted voting calculations

Indexed Signatures

Signing thresholds work in conjunction with indexed signatures (also called sigers). Each signature attachment includes an index indicating which key from the key list was used to create it. This indexing is essential for threshold verification, as it maps signatures to their corresponding public keys.

Count Codes

In CESR streams, signature attachments use count codes to indicate how many signatures follow. The count code enables parsers to extract the correct number of signatures, which are then validated against the threshold.

Witness Receipts

While signing thresholds apply to controller signatures, witness receipts have their own threshold mechanism (the witness threshold or TOAD). Both threshold types work together to provide comprehensive validation of key events.

Implementation Considerations

Threshold Validation Logic

Implementations must carefully handle threshold validation, particularly for:

Partial Rotation: When only a subset of pre-rotated keys participate in a rotation, the implementation must verify that the participating keys satisfy the prior next threshold while the new key set satisfies the new current threshold.

Fractional Weights: The tholder object must correctly parse fractional threshold strings and perform rational arithmetic to determine if weighted signatures satisfy the threshold.

Edge Cases: Implementations must handle:

• Threshold of 0 (valid for non-transferable identifiers)
• Threshold equal to key count (requires all signatures)
• Threshold changes during rotation
• Empty key lists (for abandoned identifiers)

Security Considerations

Threshold Selection: Choosing appropriate thresholds requires balancing security and operational requirements:

• Too low: Insufficient security against key compromise
• Too high: Risk of operational deadlock if key holders become unavailable
• The ample calculation provides guidance for Byzantine fault tolerance

Key Management: Threshold schemes require careful key management:

• Keys should be distributed across independent security domains
• Key holders should have secure communication channels for coordination
• Backup and recovery procedures must account for threshold requirements

Threshold Transitions: Changing thresholds during rotation requires careful planning:

• Ensure new threshold is achievable with available keys
• Consider operational impact of threshold changes
• Document governance policies for threshold modifications

Performance Implications

Higher thresholds require more signatures, which impacts:

• Message size: More signature attachments increase CESR stream size
• Verification time: Each signature must be cryptographically verified
• Coordination overhead: Multiple parties must coordinate to produce required signatures

Implementations should optimize signature verification through:

• Parallel verification of independent signatures
• Early termination once threshold is satisfied
• Caching of verification results for repeated validations

Interoperability

Different KERI implementations must agree on threshold semantics:

• Integer threshold interpretation (exact count)
• Fractional threshold calculation (rational arithmetic)
• Threshold satisfaction criteria (≥ vs >)
• Handling of malformed threshold values

The KERI specification provides normative guidance to ensure consistent threshold behavior across implementations.

Error Handling

Implementations must handle:

• Malformed threshold strings: Invalid format, negative values, zero denominators
• Impossible thresholds: Threshold exceeds number of keys
• Insufficient signatures: Count/weight below threshold
• Invalid signatures: Signatures that fail cryptographic verification
• Index mismatches: Signature indices that don't correspond to valid keys

Performance Optimization

Parallel Verification: Signature verification is embarrassingly parallel—verify multiple signatures concurrently

Early Termination: Stop verification once threshold is satisfied (no need to verify remaining signatures)

Caching: Cache verification results for repeated validations of the same event

Batch Verification: Some signature schemes support batch verification for improved performance