Node identity

Composite node

A node_id names a composite: the Execution Plane, Local Secret Kernel, invocation interface, active epoch, and deployment profile evidence bound together into one auditable roster member.

Composite node identity bindingnode_id binds execution plane, local secret boundary, and profile evidence into one auditable identity
node_idOne composite, auditable identitydomain · keyset_id · roster · active_epoch · policy_hash
execution planeRuntime contractops · receipts · trace roots
secret kernelShares & noncessession-bound · local
local interfaceCall adapterCallContext · request_digest
profile evidenceProfile artifactsmanifest · custody_class

Invariantssingle active binding per node_id · epoch / roster / keyset change only via manifest transition · every transition emits manifest-linked evidence

two-contour nodeThe external runtime drives choreography; the HSM kernel executes secret-dependent steps
External layer · client API + request admission
External MPC runtime
Transportingress / egress manifests, signatures
Control · interpreterSans-I/O step over verified facts
Instructionruns signing-algorithm steps
Statereplicated execution state
Protocol cryptonon-secret protocol math
HSM secret kernel
HSM servicestime · randomness · identity
Secret layershares · nonces · ephemeral data
Crypto over secretsFROST · DKLS23 · CGGMP primitives
N-01

The identity binding

The Execution Plane and Local Secret Kernel can run in separate processes, separate devices, or separate isolation domains. The active node identity binds both into one auditable membership record the cluster verifies.

The binding's contents depend on the deployment profile. HSM deployments include the HSM identity. Software deployments bind the isolated process or platform vault. Mobile deployments include the native runtime and vault profile. The cluster validates the full composite, including both the runtime and the kernel half.

A DomainManifest fixes the deployment profile, active epoch, node set, threshold, policy roots, and cryptographic-profile roots for the binding.

N-02

Network shape

The peer network is validation-first and at-least-once. Messages are checked against binding, session, roster, and payload before they enter DVM state as facts. Duplicate delivery converges through idempotent merge — replicated state merges commutatively and associatively, so any order and any retry reach the same state. Conflicting valid messages from the same sender produce equivocation evidence rather than a last-writer-wins overwrite.

Delayed delivery results in PendingRemote, an explicit wait state carrying the active phase, slot, and dependencies. Quorum resumes from that same point when the fact arrives. Deadline expiry produces terminal evidence.

N-03

Operations model

Infrastructure teams rotate runtime processes, add observability, manage delivery queues, and tune transport while the custody boundary holds. The same model covers an HSM-backed datacenter node, an isolated software node, and a mobile participant with a local keyshare vault.