Contract Rotation

Periodically rotating contracts limits the exposure window of a compromised root secret.

Contract rotation is the primary mechanism for limiting the exposure window of a compromised root secret. It's not a special protocol operation — it's simply creating a new contract using the standard flow.

How It Works

1. Alice creates a new contract request with fresh ephemeral keys
2. Bob accepts and contributes his own ephemeral keys
3. Both derive a completely new root secret
4. Alice starts sending events under the new contract_id

The old root secret is replaced by a new one. Events sent under the new contract are encrypted with entirely different keys.

Rotation Triggers

Rotation is a client-side policy decision. Each client independently tracks contract age or event count and initiates a new contract when its threshold is reached:

• Time-based — e.g., every 24 hours of active use
• Event-count-based — e.g., every 1,000 events
• Manual — either party explicitly requests rotation

Old Contract Cleanup

After rotation, the old contract's root secret must be retained until pending events are drained:

1. Continue decrypting events that reference the old contract_id
2. When the counterparty sends an event under the new contract_id, they have confirmed the switch
3. Drain remaining pending events under the old contract, then delete the old root secret
4. If the counterparty has not confirmed within 7 days, purge the old secret regardless

Trade-offs

Contract rotation provides a different security posture than per-message forward secrecy (like Signal's Double Ratchet):

Decentrl accepts a longer break-in recovery window in exchange for stateless encryption that enables seamless multi-device support and device-independent message history.