The process is executed through KERI's rotation event mechanism, which provides the cryptographic foundation for changing the set of entities responsible for witnessing and validating the identifier's key state.

Process Flow

Initial State: Ledger-Anchored Identifier

The transfer-off-ledger process begins with an identifier that is anchored to a blockchain or distributed ledger. In this initial state:

1. Identifier Creation: A KERI identifier is created with its inception event anchored to a ledger
2. Ledger Registration: The identifier's KEL is registered on the ledger, making the ledger the authoritative source for the identifier's state
3. Ledger-Based Verification: Validators query the ledger to verify the identifier's current key state and event history
4. Ledger Dependency: The identifier's verifiability depends on the availability and integrity of the ledger infrastructure

This initial configuration provides the benefits of blockchain-based verification but creates dependencies on specific ledger implementations and their associated costs and constraints.

Step 1: Establish KERI Witness Infrastructure

Before executing the transfer, the controller must establish alternative verification infrastructure:

1. Witness Selection: Identify and configure a set of witnesses that will replace the ledger as the verification infrastructure
2. Witness Pool Configuration: Establish a witness pool with appropriate threshold settings to ensure adequate security
3. Witness Availability: Ensure witnesses are operational and accessible via OOBIs (Out-Of-Band Introductions)
4. Threshold Determination: Configure the threshold of accountable duplicity (TOAD) to specify the minimum number of witness confirmations required

The witness infrastructure must be fully operational before initiating the transfer to ensure continuous verifiability throughout the migration process.

Step 2: Execute Rotation Event

The core of the transfer-off-ledger process is a rotation event that changes the identifier's backing infrastructure:

1. Rotation Event Creation: The controller creates a rotation event that:

   • Specifies the new witness set as the backing infrastructure
   • Removes the ledger anchor from the identifier's configuration
   • Maintains the same identifier prefix (ensuring continuity)
   • Includes pre-rotated keys for future rotations

2. Event Signing: The rotation event is signed using the current authoritative keypairs, proving the controller's authority to execute the transfer

3. Event Broadcasting: The signed rotation event is broadcast to:

   • The existing ledger (as the final ledger-anchored event)
   • The new witness set (establishing their role as the new backing infrastructure)
   • Any watchers monitoring the identifier

4. Witness Confirmation: The new witness set receives, validates, and signs receipts for the rotation event, establishing their role as the authoritative verification infrastructure

Step 3: State Transition and Verification

Following the rotation event, the identifier's verification infrastructure transitions:

1. KEL Update: The rotation event is appended to the identifier's KEL, creating a verifiable record of the infrastructure change

2. Witness Receipt Collection: The controller collects signed receipts from the witness set, forming a KERL (Key Event Receipt Log) that proves witness agreement

3. Verification Path Change: Validators now verify the identifier by:

   • Querying witnesses instead of the ledger
   • Validating witness receipts using KAACE (KERI's Agreement Algorithm for Control Establishment)
   • Confirming the rotation event's validity through cryptographic verification

4. Ledger Independence: The identifier becomes fully independent of the ledger, with all subsequent events verified through the witness infrastructure

Step 4: Post-Transfer State

After successful transfer, the identifier operates in a fully KERI-native mode:

1. Portable Identifier: The identifier is now a non-ledger based portable identifier that can be verified without any ledger dependencies

2. Witness-Based Verification: All key events are witnessed and verified by the KERI witness infrastructure

3. Continued Evolution: The identifier can undergo further rotations, changing witness sets or other configuration parameters as needed

4. Optional Re-Anchoring: If desired, the identifier can be anchored to a different ledger through another rotation event (subject to the single-anchor constraint)

Technical Requirements

Cryptographic Requirements

Rotation Authority: The controller must possess the current signing keys and the pre-rotated keys necessary to execute a valid rotation event. Without these keys, the transfer cannot be cryptographically authorized.

Signature Verification: All rotation events must include valid digital signatures that can be verified against the current key state. The signatures must meet the threshold requirements specified in the previous establishment event.

Cryptographic Strength: All cryptographic operations must maintain cryptographic strength of at least 128 bits of entropy, with consideration for post-quantum security in long-lived identifiers.

Digest Integrity: The rotation event must include correct digests of the previous event, maintaining the backward-chaining integrity of the KEL. Any digest mismatch invalidates the rotation.

Single Anchor Constraint

A critical technical limitation explicitly documented in the source materials is the single anchor constraint: an identifier can only be anchored to one ledger at a time. This constraint has several implications:

1. No Multi-Ledger Anchoring: An identifier cannot be simultaneously anchored to multiple ledgers (e.g., both Hyperledger Indy and Ethereum)

2. Sequential Migration Only: If moving between ledgers, the identifier must first transfer off the current ledger, then optionally anchor to a new ledger through a subsequent rotation

3. Clear Control Authority: The single-anchor constraint ensures unambiguous control authority and prevents conflicting state representations across different ledgers

4. Verification Simplicity: Validators have a single, clear source of truth for the identifier's state, avoiding the complexity of multi-ledger consensus

This constraint is fundamental to KERI's architecture and cannot be circumvented through configuration or implementation choices.

Timing Considerations

Witness Availability: The new witness infrastructure must be operational and accessible before executing the rotation event. If witnesses are unavailable, the transfer may fail or leave the identifier in an unverifiable state.

Event Propagation: Time must be allowed for the rotation event to propagate to all witnesses and for witness receipts to be collected. The controller should not consider the transfer complete until sufficient witness confirmations are received.

Validator Synchronization: Existing validators may continue querying the ledger until they discover the rotation event. The controller should maintain ledger accessibility during a transition period to ensure validator continuity.

Grace Period: Organizations should plan for a grace period where both ledger and witness infrastructure remain operational, allowing validators to discover and adapt to the new verification path.

Error Handling

Insufficient Witness Receipts: If the controller cannot collect sufficient witness receipts to meet the TOAD threshold, the rotation may not achieve the desired level of verifiability. The controller must either:

• Wait for additional witnesses to respond
• Adjust the witness set or threshold requirements
• Abort the transfer and maintain ledger anchoring

Rotation Event Rejection: If witnesses reject the rotation event (due to invalid signatures, incorrect digests, or other validation failures), the transfer fails and the identifier remains ledger-anchored. The controller must diagnose and correct the issue before retrying.

Ledger Finality: Some ledgers have finality delays where transactions are not immediately immutable. Controllers should ensure the final ledger-anchored event achieves finality before considering the ledger relationship terminated.

Duplicity Detection: If duplicity is detected during the transfer (e.g., conflicting rotation events), the transfer should be halted and the duplicity resolved before proceeding. KERI's duplicity detection mechanisms provide ambient verifiability of such conflicts.

Usage Patterns

Migration from Hyperledger Indy

The most commonly documented use case involves migrating identifiers from Hyperledger Indy to KERI-native infrastructure:

Initial State: Organization has DIDs anchored to an Indy ledger, with all verification dependent on Indy node availability and consensus.

Migration Strategy:

1. Create KERI identifiers that are initially anchored to the Indy ledger
2. Establish a KERI witness infrastructure independent of Indy
3. Execute rotation events to transfer control authority from Indy to witnesses
4. Gradually phase out Indy dependencies as identifiers become fully portable

Benefits:

• Reduced operational costs (no ledger transaction fees)
• Improved performance (direct witness queries vs. ledger consensus)
• Enhanced portability (identifiers work across different networks)
• Vendor independence (no lock-in to Indy infrastructure)

Hybrid Deployment Strategy

Organizations may adopt a hybrid approach where some identifiers remain ledger-anchored while others transfer off-ledger:

High-Value Identifiers: Critical identifiers (e.g., root AIDs for organizational hierarchies) may remain ledger-anchored for additional assurance and regulatory compliance.

Operational Identifiers: Day-to-day operational identifiers transfer off-ledger to reduce costs and improve performance.

Gradual Migration: New identifiers are created as KERI-native (never ledger-anchored), while legacy identifiers migrate off-ledger as operational requirements permit.

Risk Mitigation: The hybrid approach allows organizations to validate KERI witness infrastructure reliability before committing all identifiers to off-ledger operation.

Cross-Ledger Migration

While not KERI's primary design goal, the transfer-off-ledger capability enables cross-ledger migration:

Process:

1. Transfer identifier off the current ledger (e.g., Indy) to KERI witnesses
2. Execute a subsequent rotation to anchor the identifier to a different ledger (e.g., Ethereum)
3. The identifier maintains continuity throughout both transitions

Constraints:

• Must respect the single-anchor constraint (cannot be on both ledgers simultaneously)
• Requires two separate rotation events (off first ledger, onto second ledger)
• Validators must be able to discover and verify both rotation events

Use Cases:

• Regulatory requirements change, mandating different ledger infrastructure
• Cost optimization by moving to more economical ledger platforms
• Technical requirements evolve, requiring different ledger capabilities

Best Practices

Pre-Transfer Validation: Before executing transfer-off-ledger:

• Verify witness infrastructure is fully operational
• Test witness availability and response times
• Confirm OOBI endpoints are accessible to validators
• Validate cryptographic key material is available and secure

Witness Selection: Choose witnesses that provide:

• Geographic distribution (resilience against regional failures)
• Organizational diversity (no single point of control)
• Proven reliability (established operational track record)
• Appropriate threshold configuration (balance security and availability)

Communication Strategy: Inform stakeholders about the transfer:

• Notify validators of the upcoming infrastructure change
• Provide updated OOBIs for witness discovery
• Document the migration timeline and expected impacts
• Establish support channels for validator questions

Rollback Planning: Maintain the ability to reverse the transfer if issues arise:

• Keep ledger infrastructure operational during transition period
• Document the process for re-anchoring to the ledger if needed
• Monitor validator adoption of the new verification path
• Establish success criteria for declaring the transfer complete

Integration Considerations

Validator Updates: Applications and services that validate the identifier must be updated to:

• Query witnesses instead of the ledger
• Implement KAACE consensus verification
• Handle OOBI resolution for witness discovery
• Process KERL data structures instead of ledger queries

Credential Issuance: If the identifier is used for issuing ACDCs or other verifiable credentials, the transfer-off-ledger process affects:

• Credential verification paths (validators must follow the new infrastructure)
• TEL (Transaction Event Log) anchoring (may need to migrate alongside the identifier)
• Revocation registry access (must be accessible through new infrastructure)

Monitoring and Observability: Implement monitoring for:

• Witness availability and response times
• Receipt collection success rates
• Validator adoption of new verification paths
• Duplicity detection alerts

Design Philosophy and Limitations

The source documents explicitly state that while KERI can move identifiers across networks through transfer-off-ledger, this capability was not KERI's primary design goal. KERI's architecture prioritizes:

1. Portable Identifiers from Inception: Creating identifiers that are inherently portable rather than requiring migration
2. Infrastructure Independence: Designing identifiers that never depend on specific ledger implementations
3. Cryptographic Control Authority: Deriving identifier integrity from key management rather than infrastructure dependencies

The transfer-off-ledger capability exists to provide a migration path for existing ledger-based identity systems, not as the primary operational mode. Organizations adopting KERI are encouraged to create new identifiers as KERI-native from inception rather than relying on ledger anchoring and subsequent transfer.

This design philosophy reflects KERI's goal of creating a truly decentralized key management infrastructure (DKMI) where identifier portability and controller autonomy are fundamental properties, not features achieved through complex migration processes.

Insufficient Receipts: If witness receipt collection fails to meet threshold, implementations should:

• Retry receipt collection with exponential backoff
• Provide diagnostic information about which witnesses failed to respond
• Allow manual intervention to adjust witness set or threshold
• Maintain ledger anchoring until transfer can be successfully completed

Duplicity Detection: If conflicting rotation events are detected during transfer:

• Halt the transfer process immediately
• Alert the controller to the duplicity
• Provide tools to investigate and resolve the conflict
• Do not proceed with transfer until duplicity is resolved

Network Partitions: If network connectivity issues prevent witness communication:

• Implement retry logic with appropriate timeouts
• Provide offline operation capabilities where possible
• Queue rotation events for transmission when connectivity restores
• Warn controllers about potential verification delays

Performance Optimization

For large-scale deployments transferring many identifiers:

• Batch rotation events where possible to reduce network overhead
• Implement parallel receipt collection across witness sets
• Cache witness OOBI resolutions to avoid repeated lookups
• Use connection pooling for witness HTTP endpoints
• Monitor witness response times and adjust timeouts accordingly

Security Hardening

Key Protection: During transfer-off-ledger, implementations must protect:

• Current signing keys used to authorize the rotation
• Pre-rotated keys that enable future rotations
• Any seed material used for key derivation

Compromise of key material during transfer can enable unauthorized rotations or identifier hijacking.

Witness Verification: Implementations must cryptographically verify:

• Witness AID authenticity before accepting receipts
• Receipt signatures match witness public keys
• Receipt content matches the rotation event being witnessed
• No witness provides conflicting receipts for the same event

Accepting invalid receipts can create false confidence in transfer completion.

Monitoring and Observability

Production implementations should instrument:

• Transfer initiation and completion events
• Witness receipt collection success/failure rates
• Time-to-completion metrics for transfer operations
• Validator adoption rates of new verification paths
• Duplicity detection alerts during transfer

This telemetry enables operational teams to identify and resolve issues quickly.

Testing Requirements

Comprehensive testing should cover:

• Successful transfer with all witnesses responding
• Partial witness failures (below threshold)
• Complete witness failures (no receipts collected)
• Network partition scenarios
• Concurrent rotation attempts (duplicity scenarios)
• Validator behavior during and after transfer
• Cross-ledger migration sequences
• Rollback and recovery procedures

Testing should use both simulated and real witness infrastructure to validate production readiness.