Execution choreography

Any node with the right combination — operation state, roster view, admission binding, and local secret-kernel access — can drive execution for its own peer identity. It advances until completion, a local service request, egress emission, or PendingRemote, then waits for verified ingress to continue.

Protocol roles determine what counts as active work. A signer, aggregator, or recipient is assigned one site while other peers hold a reproducible parked state. Every peer evaluates the same score under a different identity, so their views stay consistent.

The DVM score coordinates the cluster directly, in place of a message-passing protocol layered on top of it. It defines sites, dependencies, phases, slots, locality, and publication boundaries. Each node evaluates that score under its local peer identity. Transport moves signed envelopes and relay entries; admission decides whether a particular frame earns fact status.

PendingRemote represents a valid wait: for a peer fact, for a turn that belongs to another node in the roster, or for a backend-local result still in progress. Receipts expose that wait directly — a client polling for progress sees a structured state with the active site and dependencies, in place of a generic pending.

In practice, a deployment routes client requests to one admitted node per operation. That node binds the operation to the active domain manifest, policy roots, epoch, roster, and local secret boundary. Polling and recovery work the same way: the node needs either the operation projection or the durable facts required to reconstruct it.

DVM execution is choreographic: within a signing or keygen session, coordination comes from the shared score rather than a central coordinator — every admitted peer evaluates its own projection of the score independently and emits at distributed frontiers.

The DVM governance layer operates at a different level. A designated governance coordinator linearizes cluster events (which DVM execution sessions are authorized to start, what sequence they run in, when transitions commit) using a Raft-based failover model. The two levels stay separate: DVM execution choreography governs work within a session; DVM governance orchestrates which sessions are authorized to run and records their committed outcomes in the cluster event log.