These assumptions break down in decentralized systems where:

• No single party should have unilateral control over data creation or deletion
• Trust must be cryptographically verifiable rather than administratively granted
• Complete audit trails are essential for detecting malicious behavior
• Data authenticity must be independently verifiable by any party

The evolution toward RUN reflects broader trends in distributed systems design, including:

• Event sourcing patterns where state is derived from immutable event logs
• Blockchain and distributed ledger append-only architectures
• Certificate Transparency logs that make certificate issuance auditable
• CRDT (Conflict-free Replicated Data Types) that enable eventual consistency without central coordination

KERI's Approach

KERI implements RUN as the foundational data management model for its entire protocol stack, including Key Event Logs (KELs), Transaction Event Logs (TELs), and ACDC credential registries.

Key Event Logs and RUN

In KERI's KEL implementation:

• Controllers create inception events and rotation events that establish and update key state
• Witnesses and watchers read these events and provide receipts
• Events are updated by appending new events to the log, never modifying existing ones
• Compromised keys are nullified through rotation to new keys, but the rotation event itself remains in the log

The KEL structure ensures that:

• No server can create an AID on behalf of a controller
• No server can delete events from the authoritative log
• All state changes are cryptographically linked through hash chains
• Duplicity is detectable because multiple versions of the same log can be compared

BADA and RUN

KERI's Best Available Data Acceptance (BADA) mechanism implements RUN principles for asynchronous data flows:

• Servers accept updates from controllers following specific acceptance rules
• Replay attack protection is achieved through growing sequence numbers and timestamps
• Deletion attack protection comes from the append-only nature of the log
• The latest event is determined by the latest date-time for the latest key state

BADA provides a medium level of security through event ordering mechanisms, making it suitable for scenarios where the overhead of full TEL infrastructure is not justified.

Transaction Event Logs and RUN

TELs extend RUN to credential lifecycle management:

• Issuance events record credential creation
• Revocation events nullify credentials without deleting issuance records
• The complete history of credential state changes remains verifiable
• Registry state can be reconstructed from the event log at any point in time

Differences from Traditional Approaches

KERI's RUN implementation differs fundamentally from traditional database systems:

Traditional CRUD:

• Server creates records for clients
• Server can delete records, destroying audit trail
• Trust depends on server integrity
• State is current snapshot only

KERI RUN:

• Controllers create their own data
• Servers maintain logs but cannot delete
• Trust is cryptographically verifiable
• Complete state history is preserved

Benefits

The RUN model in KERI provides:

1. End-verifiability: Any party can verify data authenticity by processing the event log
2. Duplicity detection: Multiple versions of logs can be compared to detect malicious behavior
3. Portability: Logs can be moved between infrastructure providers without losing verifiability
4. Auditability: Complete history enables forensic analysis and compliance verification
5. Decentralization: No single party has unilateral control over data lifecycle

Practical Implications

Use Cases

RUN is particularly valuable in scenarios requiring:

Regulatory Compliance: Industries like finance and healthcare need complete audit trails that cannot be tampered with. RUN's append-only logs with nullification provide exactly this capability.

Multi-Party Workflows: When multiple organizations need to verify the same data independently, RUN enables each party to validate the complete history without trusting intermediaries.

Long-Lived Credentials: Digital credentials that may be verified years after issuance benefit from RUN's preservation of complete issuance and revocation history.

Dispute Resolution: When disagreements arise about data provenance or state changes, RUN's complete audit trail provides objective evidence.

Benefits

Security: The append-only nature prevents attackers from covering their tracks by deleting evidence of compromise. Even if an attacker gains temporary control, their actions remain in the log.

Transparency: All state changes are visible to authorized parties, enabling accountability and reducing opportunities for fraud.

Resilience: Logs can be replicated across multiple parties, making the system resistant to single points of failure.

Verifiability: Cryptographic linking of events enables mathematical proof of data integrity rather than relying on trust.

Trade-offs

Storage Requirements: Maintaining complete history requires more storage than keeping only current state. However, modern storage costs make this increasingly practical.

Complexity: Implementing append-only logs with proper cryptographic linking is more complex than traditional CRUD operations. KERI provides libraries and tools to manage this complexity.

Performance: Processing event logs to derive current state can be slower than direct database queries. KERI implementations use caching and indexing to mitigate this.

Privacy Considerations: Complete history preservation can conflict with "right to be forgotten" regulations. KERI addresses this through techniques like selective disclosure and private attributes in ACDCs.

Implementation Patterns

Successful RUN implementations typically follow these patterns:

Event Sourcing: Store all state changes as events, derive current state by replaying events.

CQRS (Command Query Responsibility Segregation): Separate write operations (appending to logs) from read operations (querying current state).

Eventual Consistency: Accept that different parties may temporarily have different views of state, with convergence over time.

Snapshot + Delta: Periodically create snapshots of current state to avoid replaying entire history, with deltas for subsequent changes.

The RUN model represents a fundamental rethinking of data management for decentralized systems, trading some traditional database conveniences for the security, verifiability, and auditability essential to trustworthy digital identity and credential systems.

Snapshot Strategies: Periodically create snapshots of current state with pointers to the log position.

Archival Policies: Define policies for archiving old log segments while maintaining verifiability.

Consistency Models

RUN systems must define consistency guarantees:

Eventual Consistency: Accept that different parties may temporarily have different views, with convergence over time.

Causal Consistency: Ensure that causally related events are seen in the correct order by all parties.

Strong Consistency: For critical operations, require synchronous confirmation from multiple parties before considering an event committed.