• Simple Threshold: M-of-N schemes where M signatures from a set of N keys are required (e.g., 2-of-3, 5-of-7)
• Weighted Threshold: Keys assigned different weights, requiring total weight to exceed threshold (e.g., CEO=3, CFO=2, threshold=4)
• Fractional Weights: Precise fractional weight specifications for complex governance (e.g., 0.5, 0.25, 0.25 with threshold 0.75)
• Hierarchical Multisig: Nested structures where multisig groups can themselves be members of higher-level multisig groups

Cryptographic Properties

Underlying Algorithms

KERI's multisig implementation follows a "dumb crypto" philosophy, using well-established, freely available cryptographic primitives:

Signature Algorithms:

• Ed25519: Edwards-curve Digital Signature Algorithm providing ~128 bits of security
• ECDSA secp256k1: Elliptic Curve Digital Signature Algorithm used in Bitcoin
• ECDSA secp256r1: NIST P-256 curve for standards compliance

Key Derivation:

• Hierarchically deterministic key generation from seeds
• BIP32/BIP39-compatible derivation paths for key management
• Cryptographically secure pseudo-random number generators (CSPRNG) for entropy

Security Properties

KERI multisig provides several critical security guarantees:

Non-Repudiation: Each signature is individually verifiable and cannot be denied by the signer. The KEL provides an immutable audit trail of which keys authorized which operations.

Threshold Security: An attacker must compromise M keys to gain control, where M is the signing threshold. For a 3-of-5 scheme, compromising 2 keys is insufficient for unauthorized operations.

Independent Verification: Each signature can be verified independently without requiring coordination between signers, enabling asynchronous signing workflows.

Duplicity Detection: KERI's duplicity detection mechanisms work with multisig - if a controller produces conflicting events with valid multisig signatures, both versions serve as cryptographic proof of malfeasance.

Pre-Rotation Protection: Multisig identifiers benefit from KERI's pre-rotation mechanism, where next rotation keys are cryptographically committed in advance. Even if current signing keys are compromised, attackers cannot rotate to their own keys without the pre-rotated keys.

Key/Output Sizes

Multisig operations in KERI produce variable-length outputs:

Individual Signatures:

• Ed25519: 64 bytes raw, 88 characters in CESR qualified base64
• ECDSA: 64-72 bytes raw (depending on curve), 88-96 characters qualified

Indexed Signatures: Each signature includes an index indicating which key signed:

• Index encoded in CESR derivation code (1-2 characters)
• Total: ~90 characters per signature in text domain

Threshold Specifications:

• Simple thresholds: Single integer (e.g., "3")
• Weighted thresholds: Array of fractional weights (e.g., ["1/2", "1/4", "1/4"])
• Encoded compactly in CESR for event serialization

Data Format & Encoding

CESR Encoding Format

KERI uses CESR (Composable Event Streaming Representation) for all cryptographic material, including multisig components:

Threshold Encoding:

Current threshold (kt): "2"  // Simple 2-of-N
Next threshold (nt): "3"     // Pre-rotated threshold

Weighted threshold (kt): ["1/2", "1/4", "1/4"]  // Fractional weights

Key List Encoding:

Current keys (k): [
  "DKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx",  // Key 0
  "D8KY1sKmgyjAiUDdUBPNPyrSz_ad_Qf9yzhDNZlEKiMc",  // Key 1
  "DEe1vHfH6HHq9INeqO0gKWPaq4fmuCTbxD0kJASe1Yg8"   // Key 2
]

Each key is a qualified CESR primitive with:

• Derivation code prefix (e.g., 'D' for Ed25519)
• Base64 URL-safe encoded public key
• Self-describing format enabling parsing without external schema

Indexed Signature Encoding:

"sigs": [
  "AABg3eESB_Pc2IxJhzFSvjrciYJxEX8-cL-SXVcKqLLPqLqvKvJO5lXhWq7Xt8aqmLqvKvJO5lXhWq7Xt8aqmLqv",
  "ABBh4fFTC_Qd3JyKi0GTwksdjZKyFY9-dM-TYWdLrMqMMrwLvKwKP6mYiXr8Yu9brNmMrwLvKwKP6mYiXr8Yu9br"
]

Each indexed signature includes:

• AA/AB/AC: Dual indexed code indicating signature type and key index
• Base64 signature: The actual cryptographic signature
• Self-framing format enabling stream parsing

Text and Binary Representations

CESR provides text-binary composability, allowing multisig data to be represented in either domain:

Text Domain (Base64 URL-safe):

• Human-readable for debugging and logging
• Used in JSON serializations of events
• 4 characters per 3 bytes (33% overhead)
• Example: "AABg3eESB_Pc2IxJhzFSvjrciYJxEX8-cL-SXVcKqLLPq..."

Binary Domain (raw bytes):

• Compact for network transmission and storage
• Used in CESR binary streams
• Direct byte representation
• 25% smaller than text representation

Round-Trip Conversion: CESR guarantees lossless conversion between text and binary domains, enabling efficient transmission (binary) with human-readable logging (text).

Derivation Codes

CESR derivation codes identify signature types and key indices:

Signature Type Codes:

• 0B: Ed25519 signature (64 bytes)
• 0C: ECDSA secp256k1 signature
• 2A: ECDSA secp256r1 signature

Indexed Signature Codes (dual indexed):

• AA: Index 0, Ed25519 signature
• AB: Index 1, Ed25519 signature
• AC: Index 2, Ed25519 signature
• Pattern continues for higher indices

Count Codes (for signature groups):

• -AAA: Count of 0 signatures
• -AAB: Count of 1 signature
• -AAC: Count of 2 signatures
• Enables self-framing signature attachment groups

Usage in KERI/ACDC

In Which Event Types

Multisig applies to all KERI event types:

Inception Events (icp):

{
  "v": "KERI10JSON00011c_",
  "t": "icp",
  "d": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
  "i": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
  "s": "0",
  "kt": "2",  // Signing threshold: 2-of-3
  "k": [       // Current keys (3 keys)
    "DKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx",
    "D8KY1sKmgyjAiUDdUBPNPyrSz_ad_Qf9yzhDNZlEKiMc",
    "DEe1vHfH6HHq9INeqO0gKWPaq4fmuCTbxD0kJASe1Yg8"
  ],
  "nt": "2",  // Next threshold: 2-of-3
  "n": [       // Next key digests (pre-rotation)
    "ETNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
    "EYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS",
    "EnmwyZdi0d8JZAoTNZYAfSVPzhzaU6JR2H3ULvS6b5CM"
  ],
  "bt": "2",  // Witness threshold
  "b": [...],  // Witness identifiers
  "c": [],
  "a": []
}

Rotation Events (rot):

• Must satisfy both current signing threshold AND next threshold from prior event
• Enables secure key rotation even with multisig
• Pre-rotation commitments prevent unauthorized rotation

Interaction Events (ixn):

• Require current signing threshold
• Used for anchoring credentials, seals, and external data
• Enable multisig authorization of credential issuance

Delegated Events (dip, drt):

• Require multisig from delegate
• Require approval from delegator (which may also be multisig)
• Enables hierarchical multisig structures

Common Usage Patterns

Pattern 1: Organizational Governance

A legal entity creates a 3-of-5 multisig AID for its board of directors:

1. Inception: 5 board members each generate key pairs
2. Threshold: Set to 3 (majority required)
3. Operations: Any 3 board members can authorize credential issuance
4. Rotation: When board composition changes, rotate to new key set

Pattern 2: Personal Security

An individual creates a 2-of-3 multisig AID across devices:

1. Device Keys: Laptop, phone, hardware security module
2. Threshold: 2-of-3 (any two devices)
3. Daily Operations: Use laptop + phone
4. Recovery: If laptop compromised, use phone + HSM to rotate

Pattern 3: Custodial Delegation

A company delegates signing authority to a custodian while retaining rotation authority:

1. Root AID: Company's 3-of-5 multisig
2. Delegated AID: Custodian's 2-of-3 multisig
3. Signing: Custodian handles daily operations
4. Rotation: Company retains ability to revoke delegation

Pattern 4: Hierarchical Multisig

GLEIF's vLEI ecosystem uses nested multisig:

1. GLEIF Root: 3-of-5 GLEIF Authorized Representatives
2. QVI Multisig: 2-of-3 QVI Authorized Representatives (delegated from GLEIF)
3. Legal Entity: 2-of-N Legal Entity Authorized Representatives (credentials from QVI)

Verification Procedures

Step 1: Retrieve Current Key State

Verifiers must determine which keys were authoritative when the event was signed:

# Walk the KEL to find key state at event sequence number
key_state = kel.get_key_state_at_sequence(event.sequence)
current_keys = key_state.keys
current_threshold = key_state.threshold

Step 2: Extract and Parse Signatures

Parse indexed signatures from event attachments:

for sig in event.signatures:
    index = sig.index  # From dual indexed code
    signature = sig.raw  # Raw signature bytes
    public_key = current_keys[index]  # Look up key by index

Step 3: Verify Individual Signatures

Verify each signature against its corresponding public key:

valid_signatures = []
for sig in event.signatures:
    if verify_signature(event.serialize(), sig.raw, current_keys[sig.index]):
        valid_signatures.append(sig.index)

Step 4: Check Threshold Satisfaction

Ensure sufficient valid signatures:

if len(valid_signatures) >= current_threshold:
    # Event is validly signed
    return True
else:
    # Insufficient signatures
    return False

Step 5: Verify Rotation Authority (for rotation events)

Rotation events must satisfy BOTH:

• Current signing threshold (from current keys)
• Next threshold (from pre-rotated keys in prior event)

This dual requirement prevents unauthorized rotation even if current keys are compromised.

Related Primitives

Threshold Structures

Multisig relies on threshold specifications that define signing requirements:

• Simple Thresholds: Integer values ("2", "3", "5")
• Weighted Thresholds: Fractional weight arrays (["1/2", "1/4", "1/4"])
• Tholder Objects: Python/Rust objects managing threshold logic

Thresholds appear in two contexts:

• kt (current threshold): For current signing operations
• nt (next threshold): For next rotation authorization

Indexed Signatures (Sigers)

Indexed signatures are the mechanism for associating signatures with keys:

• Each signature includes an index (0, 1, 2, ...)
• Index maps to position in key list
• Enables efficient verification without trying all keys
• Supports both establishment and non-establishment events

Key Lists

Multisig requires ordered key lists:

• k: Current public keys
• n: Next key digests (pre-rotation commitments)
• Order matters - indices reference positions
• Keys are qualified CESR primitives

Witness Pools

Multisig AIDs typically use witness pools for event confirmation:

• Witnesses provide receipts (counter-signatures)
• Witness threshold (bt) specifies required receipts
• Witnesses may themselves be multisig AIDs
• Enables distributed consensus without blockchain

Delegation

Multisig combines with delegation for hierarchical structures:

• Delegator may be multisig
• Delegate may be multisig
• Both must cooperate for delegated operations
• Enables organizational hierarchies with distributed control

Implementation Considerations

Signature Collection Workflows

Multisig requires coordinating multiple signers:

Synchronous Signing: All signers present simultaneously

• Video conference with all participants
• Each signer provides signature in real-time
• Suitable for small groups with scheduling flexibility

Asynchronous Signing: Signatures collected over time

• First signer creates event, signs, shares with others
• Subsequent signers add their signatures
• Event published once threshold reached
• Suitable for distributed teams or large groups

Escrow Mechanisms: Events held until threshold satisfied

• Partially signed events stored in escrow
• Released when sufficient signatures collected
• Timeout mechanisms for abandoned signing attempts

Key Management Challenges

Key Distribution: Each signer needs their private key

• Hardware security modules for high-value keys
• Secure key generation ceremonies
• Key backup and recovery procedures

Key Rotation Coordination: Rotating multisig keys requires cooperation

• All signers must participate in rotation
• Pre-rotation commitments must be coordinated
• Partial rotation enables reserve keys

Threshold Selection: Choosing appropriate thresholds

• Too low: Insufficient security
• Too high: Operational inflexibility
• Consider ample requirements for Byzantine fault tolerance

Performance Implications

Signature Verification Cost: Linear in number of signatures

• Each signature requires elliptic curve operation
• Batch verification can improve performance
• Caching verified events reduces repeated verification

Event Size: Grows with number of signatures

• Each signature adds ~90 characters (text) or ~70 bytes (binary)
• 5-of-7 multisig adds ~450 characters per event
• CESR compression helps but size still significant

Network Coordination: Asynchronous signing requires message passing

• Mailbox services for offline signers
• OOBI resolution for discovering signers
• Witness coordination for event publication

Security Best Practices

Threshold Selection: Use ample calculations

• For n participants with f potential faults: n ≥ 3f + 1
• Threshold m must satisfy: (n + f + 1)/2 ≤ m ≤ n - f
• Ensures unique agreement despite faults

Key Isolation: Keep signing keys on separate systems

• Prevents single point of compromise
• Use hardware security modules where possible
• Implement multi-factor authentication

Pre-Rotation: Always use pre-rotation for multisig

• Protects against live key compromise
• Enables recovery even if current keys compromised
• Provides post-quantum security properties

Witness Configuration: Use sufficient witnesses

• Minimum 5 witnesses recommended
• Witness threshold should prevent single witness control
• Geographically distributed witnesses improve resilience

Threshold Checking: For weighted thresholds, sum the weights of valid signatures and compare to the threshold. For fractional weights, use exact rational arithmetic to avoid floating-point errors.

Error Handling

Insufficient Signatures: If an event has fewer than threshold signatures, place it in escrow rather than rejecting it immediately. It may receive additional signatures later.

Invalid Signatures: Log which signatures failed verification for debugging. This helps identify compromised keys or implementation bugs.

Threshold Violations: If a rotation event doesn't satisfy both current and next thresholds, reject it as unauthorized. This prevents rotation attacks even if current keys are compromised.

Performance Optimization

Caching: Cache verified events and key states to avoid redundant verification. Invalidate caches when new events are received.

Batch Processing: When processing multiple events, batch signature verifications to amortize setup costs.

Parallel Verification: Verify signatures from different events in parallel, as they are independent operations.

Security Considerations

Key Isolation: Ensure each multisig participant's key is stored on a separate system. This prevents a single compromise from gaining control.

Pre-Rotation: Always use pre-rotation for multisig identifiers. This provides recovery capability even if current signing keys are compromised.

Witness Configuration: Use at least 5 witnesses with a threshold of 3 or higher. This provides Byzantine fault tolerance and prevents single witness control.

Audit Logging: Log all multisig operations, including who signed what and when. This provides accountability and helps detect unauthorized access attempts.