DVM governance over execution sessions
Key lifecycle
Key lineage is one projection of the governance event log, distinct from roster, epoch, and incident. This section covers the key axis. The plane-level model — milliseconds vs months, authorize vs certify, conservativity — is covered in DVM Governance. Here the focus is the key lineage state machine, the three distinct key operations, and the publication barrier that separates a generated key from an activated one.
TransitionAuthorized · DvmWorkflowStartedKeyObjectPublished · key_ready_cidpublication barrier: cryptographic fact → signing authoritysame public key · same roster · new share_epochsame public key · new roster — callers keep the same addressnew key · new address — old key co-signs until window closesold key drained · address migration completeEpochFenceInstalled · KeyDeactivated · disposition recordedIncidentState moves first — key axis follows on governance action- Epoch
- Setup · Active · Closing · Closed — lifecycle of the cluster-epoch container that holds the key
- Roster health
- Healthy · Degraded · BelowThreshold — a frozen node moves this axis while the key stays Active; signing continues as long as threshold holds
- Incident
- None · Suspected · Confirmed · Emergency — a compromise moves this axis; the key stays Active until a governance decision marks it compromised
Key lineage as one axis of four
Key lineage is one of four orthogonal projections (epoch, key, roster, incident) — see DVM Governance for the orthogonality argument. The key axis itself tracks: None, DkgRunning, Generated (DKG complete but not yet activated), Active, Refreshing, Resharing, Rotating, Retiring, or Deactivated.
The other three axes are not key states. A frozen node moves roster health to Degraded, not the key to a 'degraded key' state — if threshold is still reachable, the key stays Active and signing continues. A compromise moves the incident axis, not the key lineage, until governance explicitly marks the key compromised.
- Roster health (Degraded) is not a key state. Signing can continue while the roster is Degraded if threshold is still reachable.
- Generated ≠ Active: DKG produces a cryptographic fact; activation is a separate governance decision.
- Incident state is independent — a compromised node affects IncidentState, not KeyLineageState directly.
Three key operations — not two
ShareRefresh, RosterReshare, and KeyRotation are distinct operations with different effects. ShareRefresh replaces key material on the same roster without changing the public key or the roster composition — it is proactive security hygiene, limiting the exposure window of any given share. RosterReshare moves key material to a new roster (add, remove, or change nodes) while preserving the same public key — callers see no address change. KeyRotation produces an entirely new private key and public key, which changes the on-chain address for every derived path — it is the only operation that requires an address migration.
This distinction drives custody UX and operations planning. ShareRefresh and RosterReshare are transparent to downstream callers. KeyRotation requires coordinating a migration: old addresses must be drained, new addresses registered, and the old key kept in Retiring state until existing commitments settle.
Governance authorization before DVM execution
DVM execution sessions do not start autonomously. Every lifecycle transition requires a GovernanceDecision — a threshold-signed authorization from the PolicyAuthoritySet. In institutional deployments, GovernanceDecision is produced in a key ceremony: Security Officers authenticate on HSM-backed hardware (YubiHSM, Thales Luna) and co-sign the transition intent. The GovernanceDecision is a content-addressed artifact that binds the cluster manifest, policy epoch, roster epoch, and target key epoch.
The DVM governance coordinator records a TransitionAuthorized event when the GovernanceDecision is accepted, then a DvmWorkflowStarted event when the DVM execution session begins. The transition_id ties these events together and survives leader failover — the DVM execution session carries an execution_id but the lifecycle transition is tracked by a separate transition_id. One transition may span multiple DVM execution sessions if a session is aborted and retried.
DKG publication barrier and activation as separate events
DKG completion and key activation are two distinct committed facts. The DVM keygen session terminates when publish_pubkey succeeds, producing a key_ready_cid and a publication_receipt_cid. The DVM governance plane records KeyObjectPublished at that point — the key exists as a cryptographic fact. Activation then requires a separate GovernanceDecision: the KeyActivated event is written only after the governance quorum signs off.
This separation exists because the two events are different in kind: DKG produces a cryptographic fact the protocol proved; activation is a governance decision that this key is now the authority for signing operations. Merging them would allow a key to silently become the signing authority as a side effect of DKG completing, without an explicit governance action. The publication barrier enforces the invariant: a key cannot be the active signing key until the DVM governance plane explicitly decides it is.
Event log, WORM anchoring, and replay
Every lifecycle transition — authorized, started, completed, failed, timed out — is committed to a hash-linked cluster event log. The log carries typed artifact references at each event: the GovernanceDecision CID, the DVM execution session trace root, the publication receipt, the key_ready_cid. These references let an auditor trace from the DVM governance authorization through the cryptographic execution to the published artifact, without access to secret material.
After each TransitionCommitted event, a CheckpointRecorded event captures the Merkle root of the event range and the current cluster projection. That checkpoint is then anchored to write-once-read-many (WORM) storage, producing a WormCheckpointAnchored event. WORM anchoring is available in every deployment; the backend follows the deployment profile. A SaaS deployment anchors to a cloud immutable object store — S3 Object Lock in Compliance mode, or Azure Immutable Blob. An on-prem deployment anchors to a hardware WORM appliance (NetApp SnapLock, Hitachi HCP, Dell EMC Centera) or a self-hosted transparency log (private Rekor); an air-gapped site keeps the appliance as primary and replicates to a second WORM target. An external auditor verifies any event independently by finding its checkpoint, checking the Merkle inclusion proof, and confirming the checkpoint exists in WORM.
Lifecycle operations as DVM scores: the audit composition advantage
DKG, share refresh, resharing, and rotation each run as a DVM score, on the same path as signing. Audit-emit, invariant-check, evidence-publish, and log instructions are opcodes alongside the protocol steps, composable without modifying the protocol code itself.
A signing operation already gets step permits, one-shot nonce consumption, ingress validation, publication gating, evidence packaging, and OTLP emission — because it runs through the DVM interpreter. A lifecycle operation gets the same treatment. The K formal specifications and DVM-SL scenario tests cover lifecycle scores exactly as they cover signing scores — a .dvms file can model a key refresh where a node equivocates mid-round just as easily as it models a signing session.