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.

operation walkthroughOne signing operation, step by step.
01Client intent

typed act, key id, display hash, idempotency key

CanonicalIntent
02Policy admission

policy roots, approvals, limits, epoch, roster

AdmissionDecision
03DVM execution

self_peer, score, facts, CallResult values

TraceRoot
04Secret step

CallContext, permit_handle, step_permit

PermitEvent
05Peer frontier

state-derived egress and validation-first ingress

PendingRemote
06Local result

controlled local_private result reference

ResultHandle
07PublishGate

scope, result_ref, policy context

PublicationReceipt
08Evidence package

events, receipts, reason codes, trace roots

EvidenceBundle
N-01

Intent 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.

N-02

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.

N-03

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.

N-04

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.

N-05

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.