The KERI foundational specification establishes that backers provide "secondary root-of-trust" for KELs, distinguishing them from the "primary root-of-trust" which is the cryptographic self-certifying identifier itself.

Purpose and Objectives

Backers serve several critical functions in KERI architecture:

1. Distributed Consensus: Provide independent verification of key events through redundant storage
2. Availability: Ensure KEL availability even when the controller is offline
3. Duplicity Detection: Enable detection of conflicting key event histories through independent observation
4. Hybrid Trust Models: Allow integration of blockchain-based trust mechanisms with KERI's native cryptographic trust
5. Migration Paths: Enable transition from ledger-based identity systems to KERI through ledger-backed identifiers

Evolution and Version History

The backer concept has evolved through KERI's development:

• Early KERI (2019-2020): Initial focus on native witnesses only
• KERI v1.0 (2021): Introduction of backer terminology to encompass alternative witness implementations
• PTEL Specification (2022): Formalization of backers in TEL context as "Registrars"
• vLEI Production (2023-2024): Real-world deployment of hybrid backer architectures combining witnesses and ledger backers

Protocol Architecture

Layering and Component Organization

Backers operate within KERI's layered architecture:

┌─────────────────────────────────────┐
│   Application Layer (Credentials)   │
├─────────────────────────────────────┤
│   ACDC/TEL Layer (Data Containers)  │
├─────────────────────────────────────┤
│   KERI Layer (Key Event Logs)      │
│   ┌─────────────────────────────┐   │
│   │  Backers (Witness Services) │   │
│   │  - Native Witnesses         │   │
│   │  - Ledger Backers          │   │
│   │  - Registrars (TEL)        │   │
│   └─────────────────────────────┘   │
├─────────────────────────────────────┤
│   CESR Layer (Encoding)             │
├─────────────────────────────────────┤
│   Transport Layer (HTTP/TCP)        │
└─────────────────────────────────────┘

Backer Types and Variants

The KERI ecosystem recognizes several backer implementations:

1. Traditional KERI Witnesses

Native KERI protocol witnesses that:

• Store KELs in local databases
• Provide signed receipts for observed events
• Participate in KAACE consensus
• Operate independently without blockchain dependencies

2. Ledger-Registered Backers

As defined in the glossary: "A witness in KERI that is ledger-registered. It's a type of backer that proof its authenticity by a signing key anchored to the public key of a data item on a (public) blockchain."

Key characteristics:

• Blockchain Anchoring: Signing keys cryptographically anchored to blockchain data
• Dual Verification: Events verifiable through both KERI signatures and blockchain proofs
• Hybrid Trust: Combines KERI's cryptographic trust with blockchain immutability

3. Registrars (TEL Context)

In the Transaction Event Log context, backers are called "Registrars":

• Serve as backers for credential issuance/revocation TELs
• Tracked by management TELs
• Analogous to witnesses in KEL context but operating on credential state

Data Flow Architecture

Event Flow with Backers

┌──────────────┐
│  Controller  │
│   (AID)      │
└──────┬───────┘
       │ 1. Generate Key Event
       │
       ▼
┌──────────────────────────────────────┐
│     Key Event Message (Signed)       │
└──────┬───────────────────────────────┘
       │ 2. Broadcast to Backers
       │
       ├─────────────┬─────────────┬──────────────┐
       ▼             ▼             ▼              ▼
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────────┐
│ Witness  │  │ Witness  │  │ Witness  │  │Ledger Backer │
│  (DB)    │  │  (DB)    │  │  (DB)    │  │ (Blockchain) │
└────┬─────┘  └────┬─────┘  └────┬─────┘  └──────┬───────┘
     │             │             │                │
     │ 3. Verify & Store         │                │
     │             │             │                │
     ▼             ▼             ▼                ▼
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────────┐
│ Receipt  │  │ Receipt  │  │ Receipt  │  │   Tx Hash    │
│(Signature)│  │(Signature)│  │(Signature)│  │  (Proof)     │
└────┬─────┘  └────┬─────┘  └────┬─────┘  └──────┬───────┘
     │             │             │                │
     └─────────────┴─────────────┴────────────────┘
                   │ 4. Return Receipts
                   ▼
            ┌──────────────┐
            │  Controller  │
            │   (KERL)     │
            └──────────────┘

State Management Approach

Backers maintain state through different mechanisms:

Native Witnesses:

• Store complete KEL in local database (LMDB, SQLite, etc.)
• Maintain witness receipt log
• Track escrow state for out-of-order events

Ledger Backers:

• Anchor KEL digests to blockchain transactions
• Store full KEL off-chain or on-chain depending on implementation
• Use blockchain transaction ordering as additional timestamp proof

Registrars (TEL):

• Store TEL events for credential lifecycle
• Maintain registry state (issued/revoked)
• Reference management TEL for backer list updates

Message Formats & Encoding

Backer Configuration in Inception Events

Backers are designated in the inception event of an AID through the backer configuration fields:

{
  "v": "KERI10JSON00011c_",
  "t": "icp",
  "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "i": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "s": "0",
  "kt": "1",
  "k": ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
  "nt": "1",
  "n": ["EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"],
  "bt": "2",
  "b": [
    "BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo",
    "BuyRFMideczFZoapylLIyCjSdhtqVb31wZkRKvPfNqkw",
    "Bgoq68HCmYNUDgOz4Skvlu306o_NY-NrYuKAVhk3Zh9c"
  ],
  "c": [],
  "a": []
}

Backer-Related Fields:

• bt (Backer Threshold): Minimum number of backer receipts required ("2" in example)
• b (Backer List): Array of backer AIDs that will witness this identifier
• c (Configuration): May include backer-specific configuration traits

Backer Receipt Format

Backers provide receipts in CESR format:

-FABELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM0AAAAAAAAAAAAAAAAAAAAAAAELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM-AABAADGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo0BDaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM

Receipt Structure:

• -FAB: CESR group code for receipt
• Event Identifier: SAID of the event being receipted
• Sequence Number: Event sequence in KEL
• Event Digest: Cryptographic commitment to event content
• Witness Signatures: Indexed signatures from backers

Ledger Backer Transaction Format

For blockchain-based backers, the Cardano implementation demonstrates transaction structure:

On-Chain Data:

{
  "metadata": {
    "674": {
      "prefix": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
      "sn": "0",
      "digest": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
    }
  }
}

Verification Path:

1. Query blockchain for transactions from backer address
2. Extract metadata containing KEL event digests
3. Verify cryptographic binding between backer AID and blockchain address
4. Validate event digest matches KEL event

TEL Backer (Registrar) Configuration

In TEL context, backers are configured in management TEL inception:

{
  "v": "KERI10JSON000160_",
  "t": "vcp",
  "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "i": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "ii": "EJJR2nmwyYAZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b",
  "s": "0",
  "bt": "2",
  "b": [
    "BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo",
    "BuyRFMideczFZoapylLIyCjSdhtqVb31wZkRKvPfNqkw"
  ],
  "c": []
}

TEL-Specific Fields:

• t: "vcp": Registry inception event type
• ii: Issuer identifier (controller of the registry)
• b: Registrar list (backers for this TEL)

Protocol Mechanics

Backer Selection and Configuration

Initial Backer Pool Establishment

Controllers establish backer pools during AID inception:

1. Backer Discovery: Controllers discover available backers through:

   • OOBI (Out-Of-Band Introduction)
   • Well-known URIs (RFC-8615)
   • DHT (Distributed Hash Table) lookups
   • DID resolution for ledger backers
   • Direct configuration in production environments

2. Backer Selection Criteria:

   • Geographic Distribution: Reduce single-jurisdiction risk
   • Infrastructure Diversity: Mix of native witnesses and ledger backers
   • Trust Relationships: Existing business relationships or reputation
   • Performance Requirements: Latency and availability needs
   • Cost Considerations: Ledger transaction fees vs. witness hosting costs

3. Threshold Configuration:

   • Set bt (backer threshold) based on security requirements
   • Common configurations:
     • 5 backers, threshold 3: Standard production configuration
     • 3 backers, threshold 2: Minimum viable configuration
     • 7+ backers, threshold 4+: High-security applications

Event Witnessing Flow

Standard Witness Flow

1. Event Generation: Controller creates and signs key event
2. Broadcast: Controller sends event to all configured backers
3. Backer Verification:
   • Verify event signature against current key state
   • Check sequence number continuity
   • Validate event structure and CESR encoding
   • Verify pre-rotation commitments for establishment events
4. Storage: Backer stores event in KEL
5. Receipt Generation: Backer creates signed receipt
6. Receipt Return: Backer sends receipt to controller
7. KERL Formation: Controller collects receipts to form KERL

Ledger Backer Flow

The Cardano backer implementation demonstrates ledger-specific mechanics:

1. Event Reception: Backer receives key event via HTTP endpoint
2. Event Queuing: Event placed in queue for blockchain confirmation delay
3. Confirmation Wait: System waits for configurable number of block confirmations
4. Transaction Creation: Backer creates blockchain transaction with event digest
5. Transaction Submission: Transaction broadcast to blockchain network
6. Confirmation Monitoring: Wait for transaction inclusion and confirmations
7. Receipt Generation: After confirmation, generate receipt with transaction hash
8. Dual Verification: Event verifiable through both KERI signatures and blockchain proof

Key Implementation Detail: The queuing mechanism addresses blockchain reorganization risks by waiting for sufficient confirmations before considering events stably anchored.

Backer Rotation

Backers can be rotated through rotation events:

{
  "v": "KERI10JSON00013a_",
  "t": "rot",
  "d": "E8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM-i0d",
  "i": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "s": "1",
  "p": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "kt": "1",
  "k": ["DZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"],
  "nt": "1",
  "n": ["EYAfSVPzhzS6b5CM-i0d8JZAoTNZH3ULvaU6JR2nmwy"],
  "bt": "3",
  "br": ["BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo"],
  "ba": ["BNewBackerAIDForRotation12345678901234567890"],
  "a": []
}

Rotation Fields:

• br (Backer Rotation - Cuts): Backers being removed
• ba (Backer Rotation - Adds): New backers being added
• bt: Updated backer threshold

Rotation Process:

1. Controller generates rotation event with backer changes
2. Event sent to both old and new backers
3. Old backers witness the rotation (their final duty)
4. New backers begin witnessing subsequent events
5. Threshold must be satisfied by old backers for rotation validity

Consensus and Agreement

Backers participate in KAACE (KERI's Agreement Algorithm for Control Establishment):

Agreement Requirements:

• Each backer must observe the exact same version of an event
• Backers exchange receipts with each other
• Agreement achieved when threshold number of backers have mutually receipted
• First-seen policy: First version observed is authoritative

Duplicity Detection:

• If backer observes conflicting event versions, duplicity is detected
• Backer stores both versions in DEL (Duplicitous Event Log)
• Duplicity evidence can be presented to validators
• Controller reputation damaged by proven duplicity

State Transitions

Backer state evolves through KEL progression:

┌─────────────┐
│ Uninitialized│
└──────┬──────┘
       │ Receive Inception Event
       ▼
┌─────────────┐
│  Witnessing │◄────┐
│   Active    │     │
└──────┬──────┘     │
       │            │ Receive Interaction/Rotation
       │            │
       ├────────────┘
       │
       │ Rotation with br (cut)
       ▼
┌─────────────┐
│  Witnessing │
│   Inactive  │
└─────────────┘

State Descriptions:

• Uninitialized: Backer operational but not witnessing any AID
• Witnessing Active: Actively receiving, verifying, and receipting events
• Witnessing Inactive: Removed from backer pool via rotation, maintains historical KEL

Security Properties

Threat Model

Backers operate within KERI's comprehensive threat model:

Adversary Capabilities

Network Adversary:

• Can intercept, delay, or drop messages
• Can perform man-in-the-middle attacks
• Cannot break cryptographic primitives (128-bit security assumption)

Compromised Backer:

• May attempt to sign conflicting events
• May collude with other compromised backers
• May refuse to provide receipts (availability attack)
• May attempt to rewrite history

Compromised Controller:

• May attempt to create conflicting KEL versions
• May attempt to rotate keys maliciously
• Detected through duplicity evidence from honest backers

Attack Scenarios

Eclipse Attack on Backers:

• Attacker isolates controller from honest backers
• Controller only communicates with attacker-controlled backers
• Mitigation: Geographic and infrastructure diversity in backer selection

Backer Collusion:

• Threshold number of backers collude to sign conflicting events
• Mitigation: Threshold set below total backer count (e.g., 3-of-5)
• Detection: Honest minority can prove duplicity

Ledger Reorganization (Ledger Backers):

• Blockchain reorganization could invalidate backer receipts
• Mitigation: Confirmation delay in Cardano backer implementation
• Design: Queue events until sufficient confirmations achieved

Security Guarantees

Duplicity Evidence

Backers provide duplicity evident properties:

1. First-Seen Policy: Backers record first version of event observed
2. Immutable Storage: Backers cannot retroactively change stored events
3. Signed Receipts: Backer signatures create non-repudiable evidence
4. Conflict Detection: Any conflicting event versions create provable duplicity

Duplicity Proof Structure:

Duplicity Evidence = {
  Event_Version_A + Backer_Receipt_A,
  Event_Version_B + Backer_Receipt_B,
  Proof: Same (AID, Sequence_Number), Different Event_Digest
}

Availability Guarantees

Backer pools provide availability through redundancy:

• Threshold Requirement: Only bt backers needed for valid event
• Fault Tolerance: Can tolerate N - bt backer failures
• Example: 5 backers with threshold 3 tolerates 2 failures

Availability Formula:

System_Availability = 1 - P(failures >= N - bt + 1)

For independent backers with 99% individual availability:

• 5 backers, threshold 3: 99.999% system availability
• 3 backers, threshold 2: 99.97% system availability

Ledger Backer Security Properties

Ledger-registered backers add additional security properties:

1. Blockchain Immutability: Event digests anchored to immutable ledger
2. Timestamp Proof: Blockchain provides additional timestamp evidence
3. Public Auditability: Anyone can verify blockchain anchoring
4. Cryptographic Binding: Backer AID cryptographically linked to blockchain address

Security Trade-offs:

• Advantage: Additional trust anchor through blockchain
• Disadvantage: Dependency on blockchain availability and security
• Advantage: Public verifiability without KERI infrastructure
• Disadvantage: Transaction costs and confirmation delays

Attack Resistance

Resistance to Key Compromise

Backers enable recovery from key compromise through pre-rotation:

1. Pre-Rotation Commitment: Next keys committed in current event
2. Compromise Detection: Backers detect unauthorized rotation attempts
3. Recovery Rotation: Controller uses pre-rotated keys to recover
4. Backer Validation: Backers verify recovery rotation against pre-rotation commitment

Attack Scenario:

• Attacker compromises current signing keys
• Attacker attempts malicious rotation
• Honest backers detect conflicting rotation (duplicity)
• Controller performs legitimate rotation using pre-rotated keys
• Backers validate legitimate rotation, reject attacker's version

Resistance to History Rewriting

Backers prevent history rewriting through:

1. Forward Chaining: Each event includes digest of previous event
2. Backward Validation: Backers verify chain integrity
3. Distributed Storage: Multiple independent copies prevent single-point tampering
4. Signed Receipts: Backer signatures create immutable evidence of event observation

Attack Scenario:

• Attacker attempts to modify historical event
• Modified event has different digest
• Forward chain breaks (next event references wrong digest)
• Backers detect chain break, reject modified history
• Original backer receipts prove authentic history

Resistance to Sybil Attacks

Backer selection resists Sybil attacks through:

1. Controller Selection: Controller explicitly chooses backers
2. Reputation Systems: Backers build reputation over time
3. Infrastructure Diversity: Mix of witness types prevents single-point control
4. Cost Barriers: Ledger backers require blockchain transaction costs

Interoperability

Dependencies on KERI Protocols

Backers integrate with core KERI components:

Key Event Log (KEL) Integration

• Backers store and validate KEL events
• Must understand all KEL event types:
  • Inception events (icp)
  • Rotation events (rot)
  • Interaction events (ixn)
  • Delegated inception (dip)
  • Delegated rotation (drt)

CESR Encoding Dependency

• All backer messages use CESR encoding
• Backers must parse CESR primitives:
  • Qualified cryptographic primitives
  • Indexed signatures
  • Count codes and group codes
  • Attachment formats

OOBI Protocol Integration

• Backers discovered via OOBI
• Backer endpoints published as OOBI URLs
• Example: http://witness.example.com:5642/oobi/BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo

Transaction Event Log (TEL) Integration

Backers serve as Registrars in TEL context:

Management TEL

• Management TEL tracks registrar lists
• Registrars witness TEL events for credential lifecycle
• Analogous to KEL witnesses but for credential state

Credential Registry

• Registrars back public verifiable credential registries
• Track issuance and revocation state
• Provide receipts for TEL events

TEL Event Types Witnessed by Registrars:

• vcp: Registry inception
• vrt: Registry rotation
• iss: Credential issuance
• rev: Credential revocation
• bis: Backseat issuance (registry-backed)
• brv: Backseat revocation (registry-backed)

ACDC Integration

Backers indirectly support ACDC (Authentic Chained Data Container) credentials:

1. KEL Anchoring: ACDCs anchor to KEL events via seals
2. Backer Validation: Backers witness KEL events containing ACDC seals
3. Credential Verification: Verifiers check backer receipts for KEL events anchoring ACDCs
4. Registry Backing: Registrars (TEL backers) track ACDC issuance/revocation state

DID Method Integration

Ledger backers enable DID method integration:

did:keri Method

• Native KERI DID method
• Backers provide witness services for did:keri identifiers
• DID resolution queries backer endpoints

did:webs Method

• Web-based KERI DID method
• Backers may be discovered via web endpoints
• Supports hybrid web/KERI infrastructure

Ledger-Based DID Methods

• Ledger backers enable anchoring to blockchain DIDs
• Examples: did:indy, did:sov, did:cardano
• Provides migration path from ledger DIDs to KERI

Blockchain Integration Patterns

Ledger backers integrate with various blockchains:

Cardano Integration

The Cardano backer implementation demonstrates:

• Address Derivation: Cardano address derived from same Ed25519 seed as backer AID
• Metadata Storage: KEL event digests stored in transaction metadata
• Transaction Signing: Backer signs blockchain transactions with same key material
• Verification Path: Cryptographic link between backer AID and blockchain address

Other Blockchain Integrations

Ethereum/EVM Chains:

• Smart contract-based backer implementations
• Event logs for KEL digest storage
• Gas cost considerations for transaction frequency

Hyperledger Indy:

• Transfer off ledger capability
• Anchor KERI identifiers to Indy ledger initially
• Rotate to native KERI witnesses over time

Bitcoin:

• OP_RETURN for digest storage
• Higher transaction costs limit practicality
• Strongest immutability guarantees

Implementation Considerations

Backer Infrastructure Deployment

Native Witness Deployment

Infrastructure Requirements:

• Persistent storage for KEL database (LMDB, SQLite, PostgreSQL)
• HTTP/TCP endpoints for event reception
• Cryptographic key management for witness AID
• Network connectivity for receipt exchange

Scaling Considerations:

• Database size grows with number of witnessed AIDs
• Receipt exchange bandwidth scales with event frequency
• Horizontal scaling through witness pool expansion

Operational Concerns:

• Backup and disaster recovery for KEL databases
• Monitoring for duplicity detection
• Key rotation for witness AIDs
• Geographic distribution for resilience

Ledger Backer Deployment

Additional Requirements:

• Blockchain node access (full node or API service)
• Wallet funding for transaction fees
• Transaction queuing and confirmation monitoring
• Dual storage: blockchain + off-chain KEL database

Cost Considerations:

• Transaction fees per event witnessed
• Storage costs for on-chain vs. off-chain data
• Node operation costs if running full node

Performance Trade-offs:

• Confirmation delays (seconds to minutes)
• Transaction throughput limits
• Blockchain reorganization risks

Backer Selection Strategy

Implementers should consider:

Trust Model Selection

Pure KERI Model:

• All native KERI witnesses
• No blockchain dependencies
• Maximum portability and performance
• Suitable for: High-throughput applications, cost-sensitive deployments

Hybrid Model:

• Mix of native witnesses and ledger backers
• Balanced trust and performance
• Suitable for: Production identity systems, regulated environments

Ledger-Heavy Model:

• Primarily ledger backers
• Maximum auditability and immutability
• Suitable for: High-stakes credentials, regulatory compliance

Threshold Configuration

Common patterns:

5-of-7 Configuration:

• 7 total backers (4 witnesses, 3 ledger backers)
• Threshold of 5 required
• Tolerates 2 failures
• Balanced security and availability

3-of-5 Configuration:

• 5 total backers (3 witnesses, 2 ledger backers)
• Threshold of 3 required
• Tolerates 2 failures
• Minimum production configuration

2-of-3 Configuration:

• 3 total backers (all witnesses or mixed)
• Threshold of 2 required
• Tolerates 1 failure
• Development/testing configuration

Performance Optimization

Event Batching

For high-frequency events:

• Batch multiple events in single backer request
• Reduce network round-trips
• Amortize ledger transaction costs

Parallel Receipt Collection

• Send events to all backers simultaneously
• Collect receipts asynchronously
• Return when threshold reached (don't wait for all)

Caching Strategies

• Cache backer endpoints from OOBI resolution
• Cache recent KEL state to avoid repeated queries
• Cache backer public keys for receipt verification

Error Handling and Recovery

Backer Unavailability

Temporary Failure:

• Retry with exponential backoff
• Continue if threshold still achievable
• Log failures for monitoring

Permanent Failure:

• Rotate to new backer via rotation event
• Maintain threshold during transition
• Preserve historical receipts from failed backer

Duplicity Detection

Detection Process:

1. Backer observes conflicting event versions
2. Store both versions in DEL
3. Generate duplicity evidence
4. Notify controller and other backers
5. Refuse further witnessing until resolved

Resolution:

• Controller must acknowledge duplicity
• Perform recovery rotation if compromise suspected
• Reputation damage may be permanent

Blockchain Reorganization

For Ledger Backers:

• Monitor for transaction reversal
• Maintain confirmation depth requirement
• Re-submit transactions if reorganized out
• Queue events during reorganization

Testing and Validation

Backer Compliance Testing

Functional Tests:

• Event reception and storage
• Receipt generation and signing
• Duplicity detection
• Rotation handling

Security Tests:

• Signature verification
• Chain integrity validation
• Threshold enforcement
• Attack scenario simulation

Performance Tests:

• Event throughput
• Receipt latency
• Storage scaling
• Network resilience

Integration Testing

Multi-Backer Scenarios:

• Threshold satisfaction
• Partial backer failures
• Conflicting event handling
• Rotation coordination

Cross-Implementation Testing:

• KERIpy witnesses with Rust backers
• Native witnesses with ledger backers
• Different blockchain integrations

Production Deployment Checklist

Infrastructure:

• Persistent storage configured and backed up
• Network endpoints secured (TLS/HTTPS)
• Monitoring and alerting configured
• Geographic distribution achieved

Security:

• Key material properly secured (HSM/TEE)
• Access controls implemented
• Duplicity detection operational
• Incident response procedures documented

Operations:

• Backup and recovery tested
• Scaling plan documented
• Cost monitoring for ledger backers
• Performance baselines established

Governance:

• Backer selection criteria documented
• Threshold rationale documented
• Rotation procedures defined
• Service level agreements established

Conclusion

Backers represent a critical component of KERI's distributed trust architecture, providing secondary roots-of-trust through redundant, independent event witnessing. The flexibility to use native KERI witnesses, ledger-registered backers, or hybrid configurations enables KERI to adapt to diverse trust models, performance requirements, and regulatory environments while maintaining its core security properties of duplicity evidence and end-verifiability.

The backer abstraction successfully bridges traditional blockchain-based identity systems with KERI's cryptographic trust model, providing migration paths for existing deployments while enabling pure KERI implementations for new systems. This architectural flexibility, combined with rigorous security properties and practical implementation guidance, positions backers as a foundational element in KERI's vision of a trust spanning layer for the internet.

Hybrid Deployment Patterns

Recommended Configuration for Production:

• 5-7 total backers
• Mix: 60% native witnesses, 40% ledger backers
• Threshold: 60-70% of total (e.g., 4-of-6 or 5-of-7)
• Geographic distribution across 3+ regions
• Infrastructure diversity across 2+ providers

Cost Optimization:

• Use native witnesses for high-frequency events
• Use ledger backers for high-value establishment events
• Implement event batching for ledger backers
• Consider blockchain transaction costs in threshold design

Operational Monitoring

Key Metrics to Track:

• Receipt latency (time from event to receipt)
• Backer availability (uptime percentage)
• Duplicity detection events
• Storage growth rate
• Network bandwidth utilization
• Blockchain confirmation times (ledger backers)
• Transaction costs (ledger backers)

Alerting Thresholds:

• Backer unavailability > 5 minutes
• Receipt latency > 10 seconds (native) or > 5 minutes (ledger)
• Duplicity detection (immediate alert)
• Storage capacity < 20% remaining
• Transaction failure rate > 1%

Security Hardening

Access Control:

• Separate backer configuration from controller keys
• Implement role-based access for backer administration
• Use separate credentials for witness host vs. witnessing operations
• Regular security audits and penetration testing

Duplicity Response:

• Automated duplicity detection and evidence collection
• Immediate notification to controller and other backers
• Suspension of witnessing until duplicity resolved
• Forensic logging for incident investigation

Disaster Recovery:

• Regular KEL database backups (daily minimum)
• Geographically distributed backup storage
• Documented recovery procedures
• Regular recovery testing (quarterly minimum)
• Backup of backer AID key material in secure offline storage

Testing Strategies

Unit Testing:

• Event parsing and validation
• Receipt generation and signing
• Chain integrity verification
• Threshold calculation

Integration Testing:

• Multi-backer coordination
• Partial failure scenarios
• Rotation event handling
• Duplicity detection

Performance Testing:

• Event throughput under load
• Receipt latency distribution
• Storage scaling characteristics
• Network resilience to packet loss

Security Testing:

• Invalid signature rejection
• Malformed event handling
• Replay attack resistance
• Eclipse attack simulation

Migration and Upgrade

Adding New Backers:

1. Deploy and configure new backer infrastructure
2. Generate backer AID and publish OOBI
3. Create rotation event with new backer in ba field
4. Broadcast rotation to all backers (old and new)
5. Verify new backer begins witnessing subsequent events

Removing Backers:

1. Create rotation event with backer to remove in br field
2. Ensure threshold still satisfied after removal
3. Broadcast rotation to all backers
4. Removed backer witnesses rotation (final duty)
5. Removed backer stops witnessing subsequent events

Upgrading Backer Software:

1. Test new version in staging environment
2. Upgrade backers sequentially (not all at once)
3. Verify receipt generation after each upgrade
4. Monitor for duplicity or errors
5. Rollback plan if issues detected

Compliance and Governance

vLEI Ecosystem Requirements (from governance framework):

• Minimum 5 witnesses using KAACE sufficient majority threshold
• Publication via well-known URIs, search engines, KERI DHT, and DID resolvers
• GLEIF-approved DID methods for ledger registrars
• Documented backer selection criteria
• Service level agreements for availability

Audit Trail:

• Comprehensive logging of all witnessed events
• Receipt generation timestamps
• Duplicity detection events
• Backer rotation history
• Access logs for backer administration

Documentation Requirements:

• Backer selection rationale
• Threshold configuration justification
• Disaster recovery procedures
• Incident response playbooks
• Service level objectives and agreements