A signing key is a working file, and working files die. This page walks through why keys are replaced, how ordinary rotation differs from KERI-style pre-rotation, what a key-event witness receipt is, and how three identifier styles (did:key, KERI AIDs and Blockchain Commons XIDs) answer the same question. Every claim here is checkable against the linked estate tools and public documentation.
A key that must live forever is a key that will eventually be used by someone who did not create it.
Compromise and loss are operational: the bytes leak or the holder can no longer produce them. Algorithm age is slower and just as final: a signature scheme that resists today's computers can fall to a larger or a fundamentally different computer, which is why key agility (the ability to switch algorithms without changing the identifier) is designed in advance rather than improvised after the fact.
Ordinary rotation publishes a new key after the fact. Pre-rotation commits to the whole sequence of future keys at inception, so nobody can substitute a key later.
With pre-rotation, the inception event does not just name the first key. It carries the digest of the next key, and each later key event carries the digest of the one after it. Because a digest hides its input and any change to the input changes the digest, an attacker who steals the current key cannot point the identifier at a key of their choosing: the replacement was fixed and witnessed before the attacker existed in the story. The cost is discipline. Lose the committed sequence and the identifier can lose its ability to rotate at all.
KERI records every key change as a signed key event, and independent witnesses countersign those events so the history is not just the controller's word.
The result is a replayable log: anyone can read the events in order, check each signature against the key the previous event committed to, and confirm the witnesses' countersignatures. The estate already teaches the supporting pieces: key revocation and the revocation lifecycle and the Ed25519 guide cover what it means to sign with a key and to take one away.
A self-addressing identifier (SAID) is a digest of a document embedded in the document itself, so any edit to the document breaks the identifier.
This is the same self-certification move the estate uses on every OpenChainGraph artifact: the execution_hash is computed over the artifact's own bytes, so a reader can recompute it and detect any tampering without asking a third party. ACDC credentials use SAIDs for exactly this reason, and the estate's vLEI / ACDC SAID structural checker recomputes the SAIDs of a pasted credential to check its internal self-addressing integrity.
did:key, KERI AIDs and Blockchain Commons XIDs each answer "what is this thing's identifier" differently, and that answer decides how the identifier survives a key change.
| Style | What the identifier is | Across key rotation | Status |
|---|---|---|---|
| did:key | The public key itself, encoded in the identifier | None. Rotation means a new identifier, because the identifier is the key | Widely deployed |
| KERI AID | A prefix derived from the inception key event | Stable. Pre-rotation commits each next key inside the signed event log | Specification and implementations, with operational deployments in the vLEI ecosystem |
| XID | A 32-byte digest of the inception signing key, per Blockchain Commons | Stable across rotations. The controller document is an Envelope and rotation is sequenced by provenance marks | Beta. Unaudited, experimental; see the Blockchain Commons XID documentation |
The trade is between portability and continuity. did:key is the simplest thing that can work: no registry, no log, but no continuity either. KERI and XID both buy a stable identifier that outlives any single key, at the cost of maintaining the signed history (a key event log for KERI, an Envelope with provenance marks for XID). Threshold cryptography adds a further question, who holds the key, which this wave's threshold explainer takes up separately.
The estate does not use pre-rotation, KERI or XID today. It does rotate and check agent keys, and it already verifies receipts by taking the key from the artifact.
What the estate does today: the Agent Key Rotation Auditor (art-132) checks agent key freshness and rotation posture, key age against a max-age policy, the presence of a staged next key, and the algorithm, emitting HEALTHY, ROTATION_STAGED or ACTION_REQUIRED. The OCG Receipt Verifier (T568) recomputes an artifact's execution_hash and verifies its ed25519 signature by deriving the public key from the did:key verificationMethod carried in the artifact itself, which is why a receipt signed by a since-retired key still verifies: the verifier reads the key from the artifact rather than from a current key directory. How to take a key away is covered in the key revocation explainer.