Ingress before facts

Network admission

Peer messages become DVM facts only after a validation gate — binding hash, sender and recipient, session, roster, lane, phase, slot, origin site, replay check, and decryptable typed payload. Only then does the interpreter see them.

network admission gateA peer message becomes a DVM fact after full binding verification
Signed envelopeexecution_idroster_hashlanephase / slotorigin_sitefrom_peer / to_peerschema_tagnonce
Admission checksverify bindingdecrypt payloadmaterialize typed value
DVM InboxTypedFactInboxEntryStateDelta
wrong recipientreject
wrong rosterreject
duplicatemerge / replay evidence
conflictequivocation evidence
N-01

Egress carries a value graph

When a distributed site needs to send something to a peer, the runtime derives the egress from current DVM state. The envelope carries execution_id, roster_hash, lane, phase, slot, origin_site, from_peer, to_peer, schema_tag, and nonce. The receiver checks all of those fields before accepting the message.

N-02

Ingress is validation-first

A received frame passes internal consistency checks first, then gets verified, decrypted for the local peer, checked against the active session binding, and materialized into typed graph values. Only after that boundary does the runtime commit it as a DVM fact. Raw transport behavior, relay details, and malformed messages stay on the protocol side, outside DVM state.

The failure taxonomy is specific. A mismatched envelope nonce produces EnvelopeNonceMismatch evidence. A frame that arrives twice produces DuplicateIngress, handled through idempotent merge as a normal case. Messages from the same sender that carry conflicting valid payloads produce equivocation evidence. Distinct failure types separate a transient network fault from a replay attempt and from an equivocating peer.

N-03

Failure shape

Each network failure maps to a distinct status. Timeout, duplicate delivery, wrong binding, replay, and equivocation each map to a distinct protocol-plane status, reason code, and evidence artifact. Any-node operation rests on one rule: a node accepts a peer message only when the frame proves it belongs to the same operation projection the node is currently running.

N-04

Delivery model

Protocol traffic runs over a full or partial mesh between cluster nodes, with a separate centralized contour for configuration, monitoring, audit, and service functions. Delivery is at-least-once: duplicates are expected and resolved by idempotent, commutative merge rather than by ordering. The secret kernel stays off the network — every inbound message is validated in the external runtime first, and only admissible step calls reach the kernel.

A lost or delayed frame parks the operation in PendingRemote, carrying the active phase, slot, and dependencies, and it resumes from that exact point when the fact arrives; deadline expiry turns the wait into terminal REMOTE_TIMEOUT evidence.

N-05

Untrusted relay

Peer protocol traffic passes through a relay component the design treats as untrusted. The relay is a pure forwarding layer — it sees ciphertext frames and envelope metadata, while plaintext payload, protocol state, and session keys stay out of its reach. An operator can swap or inspect the relay while the MPC session's security holds.

Compromise of the relay degrades to a network adversary: it can drop, reorder, or replay frames. All three cases are handled at the admission gate — replay produces replay evidence, equivocation from a tampered frame produces equivocation evidence, and dropped messages park the operation in PendingRemote until they arrive or SLA expires.

N-06

Mutual node authentication

Nodes authenticate each other end-to-end across the relay and the underlying network. Every inter-node message carries a binding envelope that includes roster hash, session, sender, and recipient; the receiver verifies the full envelope before the frame reaches the runtime. For the paired runtime-to-secret-kernel link, an additional private channel — mTLS, vsock, WireGuard, or an equivalent authenticated tunnel — with an optional BLAKE3 keyed MAC keeps the secret kernel reachable only by its paired runtime and off the network.

Cluster membership is defined by the set of node public keys recorded in the active DomainManifest. A node outside the active epoch roster has no valid sender slot; its messages fail the envelope check before any protocol state is touched.