Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 14 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 sufficient majority threshold that is immune from certain kinds of attacks or faults, guaranteeing that at most one valid agreement occurs (or none at all) despite the presence of faulty or malicious participants.
A supermajority represents a consensus threshold that goes beyond simple majority (>50%) to achieve stronger security guarantees in distributed systems. Unlike a simple majority, which only requires more than half of participants to agree, a supermajority is specifically designed to be immune from certain classes of attacks and fault conditions.
The core principle is that by requiring a larger proportion of participants to reach agreement, the system can tolerate a known number of faulty or malicious actors while still guaranteeing that:
This concept is fundamental to Byzantine Fault Tolerant systems where participants cannot necessarily trust each other, and some may behave arbitrarily (maliciously or due to failures).
The supermajority concept emerges from decades of research in distributed consensus, particularly the Byzantine Generals Problem formalized by Lamport, Shostak, and Pease in 1982. This classical problem demonstrated that in a system with N participants where up to F may be faulty, achieving consensus requires specific mathematical relationships between N, F, and the agreement threshold M.
Traditional Byzantine Agreement algorithms like Practical Byzantine Fault Tolerance (PBFT) established that systems need N ≥ 3F + 1 participants to tolerate F Byzantine faults. The supermajority threshold in these systems typically requires M ≥ 2F + 1 confirmations to guarantee safety and liveness properties.
In blockchain systems, supermajority thresholds appear in various forms:
The supermajority threshold must satisfy Byzantine Fault Tolerance requirements:
n ≥ 3f + 1 to tolerate f Byzantine faults(n+f+1)/2 ≤ m ≤ n-f ensures both safety and achievabilityf ≥ 1 if n > 0)Weak mode (weak=True):
m = (n+f+1)/2Strong mode (weak=False):
m = n-fWhen configuring witness pools:
f_max = (n-1)/3m ≤ n (threshold cannot exceed total witnesses)Controllers should explicitly declare their TOAD threshold in inception events:
For multi-sig groups, always set signing threshold ≥ ample:
The key insight across all these systems is that the supermajority threshold must be carefully calculated based on the assumed fault model to provide meaningful security guarantees.
KERI implements supermajority consensus through the concept of ample - the minimum required number of participants needed to achieve supermajority guarantees. This is formalized in KAACE (KERI's Agreement Algorithm for Control Establishment), which establishes consensus between witnesses on the key state of a KERI identifier.
According to section 11.4.2.4 of the KERI whitepaper v2.60:
"Satisfaction of this constraint guarantees that at most one sufficient agreement occurs or none at all despite a dishonest controller but where at most F of the witnesses are potentially faulty."
KERI's supermajority implementation differs from traditional approaches in several key ways:
KERI defines the ample constraint through precise mathematical relationships:
f ≥ 1 if n > 0 (at least one fault must be tolerated if there are participants)n ≥ 3f + 1 (Byzantine fault tolerance requirement)(n+f+1)/2 ≤ m ≤ n-f (bounds on the supermajority threshold)These constraints ensure that the supermajority threshold M is both:
KERI applies supermajority thresholds in two critical scenarios:
Witness Pools: For witnessed events, the supermajority determines how many witnesses must confirm a key event to establish its validity. This prevents a dishonest controller from creating conflicting event versions that could both appear valid, enabling duplicity detection.
Multi-Signature Groups: For multi-sig identifier control, the supermajority sets the signing threshold for group operations. Using the ample threshold prevents accidental lockout - where a group could lose access to their identifier if the signing threshold were set too low.
KERI's supermajority consensus forms the basis for accountability - determining what actions a controller of a KERI identifier can be held legally responsible for. When a supermajority of witnesses confirm an event, the controller becomes accountable for that event's effects, even if they later claim it was unauthorized.
This accountability mechanism is captured in the TOAD (Threshold of Accountable Duplicity) - 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.
KERI's implementation allows controllers to choose their desired fault tolerance level by selecting:
This flexibility enables different security/performance trade-offs for different use cases:
The KERI implementation includes a weak parameter that determines whether to minimize or maximize M for a given F:
weak=True): Finds maximum F and minimizes M - more permissive, easier to reach consensusweak=False): Finds maximum F and maximizes M - more restrictive, harder to reach consensus but more secureThis allows fine-tuning of the security/liveness trade-off based on application requirements.
Supermajority thresholds provide concrete security guarantees:
Duplicity Prevention: A dishonest controller cannot create two conflicting versions of their KEL that both achieve supermajority confirmation, making duplicity detectable.
Fault Tolerance: The system continues to function correctly even when up to F witnesses are compromised, offline, or behaving maliciously.
Unambiguous Consensus: Either a supermajority is reached (providing certainty) or no agreement occurs (failing safely).
High-Value Identity Management: Organizations managing critical identities (corporate identities, credential issuers) can use larger witness pools with higher supermajority thresholds to ensure maximum security and accountability.
Delegated Authority: When delegating authority to sub-identifiers, the delegator can require supermajority confirmation from the delegate's witnesses before accepting delegated events, preventing unauthorized delegation.
Multi-Signature Operations: Groups controlling shared identifiers (corporate boards, multi-party agreements) use supermajority thresholds to ensure that key operations require broad consensus while preventing lockout scenarios.
Credential Issuance: QVIs and other credential issuers can use supermajority witness confirmation to ensure that credential issuance events are properly witnessed and accountable.
Liveness vs. Safety: Higher supermajority thresholds (larger M) provide stronger safety guarantees but may reduce liveness - if too many witnesses are offline, consensus cannot be reached. Lower thresholds improve liveness but reduce fault tolerance.
Cost vs. Security: More witnesses (higher N) enable higher fault tolerance (higher F) but increase operational costs (witness hosting, network communication). Applications must balance security requirements against resource constraints.
Latency vs. Certainty: Waiting for supermajority confirmation introduces latency compared to accepting events immediately. However, this latency provides cryptographic certainty that the event is valid and accountable.
Flexibility vs. Complexity: KERI's flexible supermajority configuration (choosing N, F, weak/strong modes) provides powerful customization but requires understanding the mathematical relationships and security implications.
Calculate Ample Correctly: Always use the ample calculation to determine M based on your chosen N and F - never set thresholds arbitrarily.
Consider Fault Models: Choose F based on realistic threat models - how many witnesses might realistically be compromised or fail simultaneously?
Plan for Growth: When establishing witness pools, consider future growth - adding witnesses later requires rotation events.
Monitor Witness Health: Regularly verify that sufficient witnesses are online and responsive to maintain liveness guarantees.
Document Accountability: Clearly communicate the TOAD threshold to all parties so accountability expectations are understood.
The supermajority concept in KERI provides a mathematically rigorous foundation for distributed consensus that balances security, accountability, and operational flexibility - enabling trustworthy decentralized identity systems without relying on centralized authorities or global ledgers.
Balance these costs against security requirements when choosing N and F.