The RUN Alternative

KERI's RUN model addresses these issues:

• No Create: Data always originates from controllers, not servers. Servers only maintain logs of controller-generated events
• No Delete: Instead of deletion, KERI uses Nullify operations that mark data as invalid while preserving the historical record
• Read and Update: Servers can read logs and append updates (including nullifications) but cannot modify or remove existing entries

OOBI Context: "Running Off the CRUD"

In OOBI (Out-Of-Band Introduction) contexts, KERI systems are described as "running off the CRUD" because:

• The source of truth for each data item is a decentralized controller peer, not a centralized database
• Databases hosted by peers do not create records in the traditional server-creates-for-client sense
• Each AID controller maintains their own KEL as the authoritative record

Security Implications

The shift from CRUD to RUN enables KERI's critical security properties:

• Non-Interactive Replay Monotonicity: Append-only logs with sequence numbers and timestamps prevent replay attacks
• Duplicity Detection: Complete event history enables detection of conflicting versions
• End-Verifiability: Anyone can verify the complete history without trusting intermediaries
• BADA Policy: Best Available Data Acceptance mechanisms work with monotonic update policies

Related Terms

• RUN (Read, Update, Nullify): KERI's alternative to CRUD for decentralized systems
• BADA (Best Available Data Acceptance): Security mechanism that works with RUN's monotonic updates
• KEL (Key Event Log): Append-only data structure incompatible with CRUD's Delete operation
• Controller: Entity with authority over identifiers, replacing server authority in CRUD