The operator states the cryptographic act, its policy context, limits, and the public effect they want.
Key & policy lifecycle · institutional custody
Threshold signing as one inspectable lifecycle.
DVM-MPC runs an approved act as a single governed lifecycle — policy admission, peer performance, a publication gate, and evidence receipts — behind a narrow secret boundary you can inspect at every step.
Mental model
Intent, score, performance, chronicle, witness.
DVM-MPC lowers intent into a reproducible, backend-neutral program: dependencies, gates, and receipt obligations.
Peers and backends perform the score; secret-dependent steps run behind a narrow Runtime–Secret Kernel boundary.
Admitted, PendingRemote, Executed, Published, and recovered states become a readable operational history.
Evidence and publication receipts make the act inspectable, with execution and disclosure kept as separate states.
Operation workbench
Step through a governed signing act.
The workbench is the proof surface: step the act as a real program — admission, backend microtrace, PendingRemote, publication gates, and evidence — while the secret boundary stays narrow.
Open the workbenchBackend microtracecustody.release
admitpolicy bound to op · key · epochshare_invL0 backend microstepPendingRemoteawaiting peer / transportfinalize_sigcontrolled artifact producedPublishGateexecuted — release still gatedSeparated planes of responsibility
One narrow boundary. Everything else is inspectable.
A single trust line runs between the outer execution contour and the secret kernel. Minimizing what sits behind it keeps the certifiable computing base small.
Client API
Applications submit a typed act. Infrastructure can inspect the score and runtime surface; protocol detail stays inside.
DVM execution
Admission, peer choreography, transport, recovery, and the publication gate stay in the auditable outer contour.
Secret kernel
Shares, nonces, and presign artifacts never leave the kernel in the clear — HSM-backed or isolated software.
Evidence plane
Admission, denial, recovery, publication, and backend trace are emitted as a verifiable evidence bundle.
End-to-end lifecycle
Execution and publication are separate states.
A computed signature is not a public effect. Each stage emits its own receipt, denial reason, or recovery evidence — so the result can wait at the gate until release is allowed.
- 01Submitted
The API edge accepted the request and assigned correlation data.
- 02Admitted
Policy and replay checks accepted the act into the runtime.
- 03PendingRemote
A normal wait on peers, transport, approval, or publication input.
- 04Executed
The cryptographic computation produced a controlled artifact.
- 05Published
A publication gate released the artifact to the configured rail.
- 06Settled / Reconciled
External confirmation is attached and the operation closes.
Trust & verifiability
One contract. Different trust classes.
Run with a hardware secret boundary or an isolated software kernel. The API, lifecycle, reason codes, and evidence stay compatible across assurance classes.
Secret-dependent steps and local secret state run on a Kontinent or compatible HSM, the strongest trust class.
The same Runtime–Secret Kernel contract under OS, process, or container isolation — a full v1 deployment mode.
API, lifecycle, reason codes, and evidence bundles stay compatible across assurance classes and export to SIEM.
Governed performance. Verifiable witness. One runtime for cryptographic acts.
Walk the model in the architecture map, explore the API, or step the act in the workbench.