Supersession

Supersession is how you rotate keys or upgrade your identity.

When to Supersede

• Key rotation — Periodic security hygiene
• Key compromise — Emergency replacement
• Algorithm upgrade — Moving to stronger crypto
• Version upgrade — v0.4 → v0.6 migration

How It Works

Create a new identity that references the old one:

{
  "v": "0.6",
  "t": "id",
  "n": "MyAgent",
  "k": {
    "t": "dilithium",                    // New key (Dilithium)
    "p": <new_pubkey>
  },
  "sup": {                       // Supersedes
    "tx": "abc123...",           // Old inscription txid
    "t": "ed25519",                    // Old key type
    "f": <old_fingerprint>       // Old fingerprint
  },
  "c": 1738600000,
  "s": [                         // BOTH keys sign
    <old_key_signature>,
    <new_key_signature>
  ]
}

The Dual Signature Rule

Both old and new keys must sign. This proves:

1. You control the old key (authorized rotation)
2. You control the new key (legitimate successor)

No one can forge a supersession without both keys.

Compromised Key Recovery

If your old key is compromised, you can't get both signatures. Options:

Option A: Sign with new key only

{
  ...
  "sup": {
    "tx": "abc123...",
    "t": "ed25519",
    "f": <old_fingerprint>,
    "compromised": true          // Flag the situation
  },
  "s": <new_key_signature_only>
}

Option B: Out-of-band verification

Include binding proofs from external platforms:

{
  ...
  "proofs": [
    {
      "platform": "twitter",
      "url": "https://twitter.com/.../status/...",
      "content_hash": "sha256:..."
    }
  ]
}

High-trust operations may require human review.

Migration from v0.4

Reference your OP_RETURN identity:

{
  "sup": {
    "v": "0.4",                  // Old version
    "op_return_tx": "xyz789...", // v0.4 OP_RETURN txid
    "t": "gpg",                    // GPG key
    "f": "DAF932355B22F82A706DD28D3103953BA39DA371"
  }
}

Sign with both old GPG key and new key.

What Happens to the Old Identity?

• Still exists — Inscriptions are permanent
• Marked superseded — Explorers show the relationship
• Attestations stay — They're historical facts
• No longer active — New identity is canonical

Verification Chain

Explorers should display the full lineage:

Identity A (created 2026-02-01)
    ↓ superseded by
Identity B (created 2026-06-15)
    ↓ superseded by
Identity C (created 2027-01-01) ← current

Best Practices

1. Rotate periodically — Don't wait for compromise
2. Keep old keys — You need them to sign supersession
3. Backup securely — Lost keys = complicated recovery
4. Announce transitions — Let attestors know via binding proofs