Key Revocation

Overview

Key revocation removes trust from a key before or at the end of its authorized lifetime. The action can update an on-chain authority, certificate status, validator registry, access-control list, or wallet policy. Merely deleting a local private key is not revocation because other systems may continue accepting signatures from the corresponding public key unless they receive an authoritative status change.

The effect is normally prospective. Historical transactions signed while the key was valid remain part of the chain and continue to verify cryptographically. Revocation changes whether new signatures or claims should be accepted after a defined time or block. Systems must therefore record the revocation point and distinguish signatures created before and after it. Clock ambiguity can be reduced by using block numbers or finalized timestamps.

Blockchain accounts vary in their recovery options. Some allow an Account Authority to replace keys, while immutable single-key accounts may have no protocol-level revocation path. In those cases, funds must be transferred to a new account before compromise, or the key remains effective for as long as assets or permissions remain associated with it.

An incident plan should combine revocation with Key Rotation, notification, monitoring for unauthorized signatures, and review of dependent systems. Revocation messages themselves must be authenticated and protected from rollback. Payment infrastructure should test whether every node, service, and signer observes the new status consistently before assuming that the old key is unusable.

When applying Key Revocation, teams should separate directly observed protocol facts from interpretation. key revocation changes future trust in a key; it does not erase historical signatures or help unless every relying system enforces the new status. For Key Revocation, keeping the underlying identifiers and validation context makes incident review, reconciliation, and future migrations more reliable.