End-to-end signing path
Operation processing path
A signing operation passes through eight sequential handoffs between client request and signed transaction: admission, execution, publication, and evidence. Each handoff has a named input, a named output, and a receipt.
typed act, key id, display hash, idempotency key
CanonicalIntentpolicy roots, approvals, limits, epoch, roster
AdmissionDecisionself_peer, score, facts, CallResult values
TraceRootCallContext, permit_handle, step_permit
PermitEventstate-derived egress and validation-first ingress
PendingRemotecontrolled local_private result reference
ResultHandlescope, result_ref, policy context
PublicationReceiptevents, receipts, reason codes, trace roots
EvidenceBundleIntent to admitted operation
A client request arrives with a key id, display hash, idempotency key, and deadline. The API normalizes this into a canonical operation — a transport-independent representation the DVM evaluates.
Policy admission runs against that canonical form. It checks policy roots, approvals, rate limits, account binding, epoch, roster membership, and display binding. The result is either POLICY_DENIED, a PendingApproval waiting on an external confirmation, or an AdmissionDecision that admits the operation into execution.
Admitted execution to secret step
Once admitted, a node evaluates the DVM score as itself — under its self_peer identity, against the current replicated state, with whatever validated peer facts have arrived. When the score reaches a point that needs secret material, the runtime delegates it to the Local Secret Kernel through a typed CallContext.
PrepareStep reserves the one-time local material for the next transition. AdvanceStep then consumes exactly one step permit and returns the public output the transition produced. The kernel returns one of three things — an opaque descriptor, a public result, or a denial reason — and keeps raw shares and nonces on its own side.
Peer frontier and pending state
When a node emits peer facts, those facts are derived from state: bound to execution_id, roster_hash, lane, phase, slot, origin site, sender, and recipient. The receiving peer checks all of those fields before the frame enters DVM state.
While a needed peer fact is still in flight, execution parks in PendingRemote, carrying the active site, slot, dependencies, and deadline. The projection is preserved. Execution resumes from that same point when the fact arrives, or closes with timeout evidence at the deadline.
Local completion to publication and evidence
When the threshold computation finishes, the result is local_private — it exists under local control and stays private until publication. Execution and publication are separate states.
PublishGate is the boundary where that changes. It checks whether the result can be disclosed for a given scope, emits a PublicationReceipt if yes, or closes with PUBLICATION_DENIED if not. Evidence packaging then assembles the chain: admission events, trace roots, pending events, publication receipt, reason codes, and event hashes into a portable export.
How this documentation maps each handoff
Every handoff in this walkthrough has a dedicated section. boundary covers the execution/kernel split at the secret step. kernel-contract covers PrepareStep, AdvanceStep, and the permit lifecycle. choreography covers peer frontier emission and PendingRemote. publication covers PublishGate decision logic, hold/deny/approve outcomes, and disclosure scope. evidence covers audit chain assembly and EvidenceBundle export.
recovery covers what happens when any handoff fails — how the profile determines durability, how recover_step re-enters the sequence, and how journal conflict produces verifiable evidence. threat-model names what each boundary is protecting against and what is explicitly out of scope. error-codes maps every reason code to the boundary that produces it. invariants is the consolidated assurance surface that cross-references all handoffs.