Custody, gaming, stablecoins, and RWA are different products — a signature, a payout, a redemption — but the same control problem, and each one rebuilds the boundary from scratch.
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.
The problem
Every regulated act rebuilds the same trust boundary.
Mature platforms prove the need for governance. The hard part is the boundary between an approved request and one exact, irreversible operation, with audit-grade evidence. Today it is re-implemented for every product.
The gap between an approved request and one exact, irreversible operation is where insider risk, prompt-injection, and unauditable glue accumulate.
Every product invents its own audit trail, so proving to a regulator that policy actually gated the act is reinvented for each — and fragile.
The solution
Build the boundary once. Reuse it everywhere.
DVM turns the line between approved policy and irreversible action into one inspectable execution contract — threshold-signing protocols lowered to bytecode the runtime enforces, backend-neutral, with audit-grade evidence by default.
The approved-policy → irreversible-action line becomes a single reusable contract. Bind policy to execution one time and every product inherits it.
Threshold-signing schemes lower to bytecode the runtime enforces — the policy runs as a step inside the signing trace, welded to the key itself.
Swap DKLS23 for another scheme or move to an HSM; admission, the secret kernel, the publication gate, and the evidence bundle stay identical.
See it run
Step through a governed signing act.
This is the execution contract itself, running. Drive the act through its lifecycle yourself: admission, the secret kernel, PendingRemote, and the publication gate, with execution kept separate from disclosure. Every instruction runs distributed across the MPC signer set — zoom from L1 sites into L0 microcode, and switch domains to see the same boundary hold across custody, stablecoins, RWA, and regulated gaming.
Open the workbenchLive trace
custody.releaseMPC · 3 signers · t-of-n
runtimesecret kernel
ExecutedSignature — computed · held at gate
- admission gate · policy before secret access
- publication gate · disclosure decision
The artifact is computed inside the secret kernel but not observable — release still waits at the publication gate.
Evidence
submitc24416admitae661epresign19d5b0exec653612
Drag, click the track, or use ← → · ‹ ›Step through the operation
deny at
Separated planes of responsibility
One narrow boundary. Everything else is inspectable.
The contract keeps exactly one trust line — between the outer execution contour and the secret kernel. Everything outside it stays inspectable; 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.
Governance & policy
Normalized intent meets policy roots, approvals, limits, account binding, and epoch — yielding an admission decision before any secret access.
DVM execution
Peer choreography, transport, recovery, and the publication gate stay in the auditable outer contour. Execution is deterministic over admitted inputs; approvals and release holds are admission- and gate-time decisions, each recorded as an artifact.
Secret kernel
Shares, nonces, and presign artifacts stay sealed inside the kernel — HSM-backed or isolated software.
Evidence plane
Admission, denial, recovery, publication, and backend trace are emitted as a verifiable evidence bundle.
Every formal security assumption maps to a concrete detecting control — monitoring, backpressure, limits, and safe mode run across all planes as explicit operational decisions.
Deployment
Choose where your secrets live.
Because that boundary is narrow and backend-neutral, you choose where the secret kernel runs. Go fully managed in CipherAct's SaaS, or move the runtime and secret material into your own boundary — up to a hardware module. The same execution contract and audit evidence hold across every mode.
CipherAct hosts the full runtime, including an isolated software secret kernel. Fully hands-off — connect policy and start signing.
Run the same Runtime–Secret Kernel contract in your own boundary under OS, process, or container isolation — secret material stays on your infrastructure.
Keep secret material in your own HSM — the strongest trust class, with the identical contract and evidence.
Governed performance. Verifiable witness. One runtime for cryptographic acts.
You've seen the problem, the contract, and the boundary. Walk the full model, explore the API, or step the act yourself.