Regulated Design

A custody product lives inside a compliance framework. SOC 2, ISO 27001, regional licensing regimes (NYDFS BitLicense, MAS Payment Services Act, FCA crypto-asset registrations, EU MiCA) all impose the same broad shape of control: no single party can move funds unilaterally; approvals are documented and reviewable; operational duties are segregated; the audit trail is complete and tamper-evident; the regulator can examine and revoke when needed.

Building those controls from scratch on top of single-key wallets is months of custom engineering. Building them on Zafeguard's MPC primitives plus the workflow canvas gives you platform features that already implement most of the controls, and an audit surface that maps cleanly to what your auditor expects to see.

This page maps the platform's actual features to the controls regulators ask for. Where a control needs a feature the platform does not yet ship as an API, the page says so.

The five controls regulators ask for

Most custody compliance frameworks, stripped to essentials, ask for:

1. No single party can move funds. Including you, including any single employee, including any single piece of infrastructure.
2. Every fund-moving operation has a documented approval flow. Who approved, when, against what policy.
3. Operational duties are segregated. The person who approves does not also sign. The person who configures policy does not also approve operations.
4. The audit trail is complete and tamper-evident. Every operation, every approval, every policy evaluation is captured and verifiable.
5. Sovereignty can be demonstrated. Where required, key material does not leave defined jurisdictional or organisational perimeters.

Control 1 — No single party can move funds

The cryptographic guarantee comes from threshold MPC. Every key is provisioned with m-of-n shares; no single party holds enough material to sign. This is enforced by the mathematics of the threshold protocol — not by access control on top.

The property is built into the cryptographic protocol, not bolted on as a software access-control layer. Two architectural guarantees of the SDK back this up:

• Each signing node only ever sees its own share plus cryptographically-sealed envelopes from peers. The full private key never exists anywhere — every party's share is one Lagrange-evaluation of a polynomial that no one can reconstruct without threshold-many shares.
• The cluster never assembles a finalised signature. Signing ceremonies on the cluster produce partial signatures only; assembly happens off-line in the consuming SDK via Scheme.finalizeSignature.

The cluster cannot sign on behalf of a user even if compromised — it can only produce partial signatures that the integrator combines off-line. A compromised platform operator cannot drain funds; a compromised cluster node cannot drain funds; only threshold-many parties cooperating can produce a valid signature.

Combining built-in and self-hosted parties strengthens this control. A cohort with two built-in nodes and one self-hosted node requires both your infrastructure and the platform's infrastructure to participate.

→ Hot Wallet → Cluster topology → Cold Wallet → Topology → MPC Agent → How it works → What the agent never does

Control 2 — Documented approval flow

Every signing operation runs inside a workflow. The workflow is a graph of typed components — policy checks, approval gates, operator authentication, time locks — that the platform executes faithfully and logs every step in full.

The execution log captures:

• Trigger. Who or what initiated (your application, an operator, a schedule, a webhook).
• Input. The full request payload, including destination, amount, asset, requesting operator's identity.
• Stage-by-stage execution. Every component that ran, its outcome (approved, rejected), its duration, its message.
• Signing event. The signing component's invocation against the MPC cluster, including the ceremony sessionId.
• Submission and confirmation. The chain broadcast, the transaction hash, the block of confirmation.

The structure of the log IS the documentation of the approval flow. An auditor asking "show me the approval flow for cold-tier withdrawals above $1M" gets a workflow definition; asking "show me an executed flow" gets a full execution log with operator identities, policy outcomes, and on-chain settlement.

Workflow versions are tracked; an execution log for any historical transaction references the version that ran. Reconstructing the policy in force at any point in time is straightforward.

→ Hot Wallet → Policy enforcement → Cold Wallet → Multi-party approval flow

Control 3 — Segregation of duties

Segregation of duties is structural — it sits in the way you define roles, workflow access, and approval pools at the workspace level. The platform supports the structure; you implement the role definitions for your operating model.

The standard segregation pattern for a custody operation:

The workspace role and access surface lets you enforce these structurally — a treasury operator's workflow access is read-only on policy workflows and write on payout-request workflows. Conflict-of-interest detection (the requester cannot also be the approver) is a property your workflow's approval-collection component should check at execution time.

The platform-side primitives the canvas exposes for this:

• Workflow access rules. Restrict which roles can trigger or edit which workflows.
• Component-level approver lists. A "collect-approvals" component takes a pool and a quorum — when the requester's identity is in the pool, the component rejects the approval for that operator.

Control 4 — Complete and tamper-evident audit

The audit trail spans three layers, each with its own surface:

Workflow execution log — captures every component execution in every workflow run, with timestamps, outcomes, and signed payloads.

Stream over SSE for live UI feedback or for SIEM ingestion:

GET /v1/sdk/workflows/executions/:runId/stream

Cluster ceremony audit log — captures every MPC ceremony event the cluster ran (envelope sealing failures, peer disconnects, license refusals, threshold convergence). Queryable per node:

const logs = await agent.sessions.auditLogs({
  sessionId,
  failuresOnly: false,
  limit: 1000,
});

Chain confirmation — the on-chain transaction hash and block. Independently verifiable; binds the cluster ceremony output to externally observable evidence.

Together these mean: an auditor cannot be told "we ran this workflow" without being able to verify the run. The ceremony's sessionId ties the workflow log to the cluster log; the workflow log's signed payload ties to the chain confirmation. Tampering with one breaks the chain.

Streaming to your SIEM

The standard production pattern: a worker in your environment subscribes to the workflow execution stream and forwards events to your SIEM target (Splunk, Elastic, Datadog). The cluster audit logs are polled per-node into the same SIEM. Events are replayable from the workflow execution endpoint so SIEM outages do not lose audit data.

The platform does not ship a workspace.observability.subscribe(...) SDK call today. The integration is done via the existing SSE workflow stream and the agent.sessions.auditLogs(...) cluster query.

Control 5 — Sovereignty

Some jurisdictions require key material to not leave a defined perimeter. Some clients require the same. The platform supports two patterns:

Mixed deployment

One or more cohort agents run in your self-hosted environment; the rest run on the platform's built-in infrastructure. The cryptographic guarantee — threshold required to sign — extends across the deployment. Sovereignty for the self-hosted agent is yours; sovereignty for the built-in ones is jointly enforced by the threshold property.

Fully self-hosted

Every agent runs in your environment. The platform provides the SDK, the workflow canvas, the audit emission, and the management surface — but no share leaves your perimeter. The workflows that orchestrate signing can also be hosted in your environment for end-to-end sovereignty.

The same SDK, the same workflows, the same operational shape; only the deployment topology differs.

→ See MPC Agent → Deployment for the cluster setup.

Right-to-revoke

Regulated custody products need the ability to revoke an operator's access, retire a compromised key, or wind down a client relationship. The platform supports each:

Operator revocation

Removing an operator's signing or approval rights is a workspace role change. After revocation:

• The operator cannot authenticate to the cohort agents.
• Pending workflows requiring their approval mark them as unavailable; quorum is recomputed against the remaining pool.
• Historical signing events the operator participated in remain in the audit log — revocation does not retroactively void past operations.

Key retirement

Retiring a compromised or end-of-life key is a controlled move-funds-out operation:

1. Provision a successor key with the same topology and policy (DKG ceremony via agent.sessions.createKeyShare(...)).
2. Build a transfer workflow that drains the old key's balances to the successor.
3. Optionally delete the old key share from the cluster via agent.keyShares.delete(id) after a documented retention period — though most operations keep the share inert in storage so historical audit can re-verify past signatures against the retired key.

Client wind-down

For custody-as-a-service operators with multiple clients, ending a client relationship is the same key-retirement pattern scoped to that client's keys, plus archival of the relevant workflows. The audit trail for the wound-down client is exportable to your records and to the client's records before any platform-side cleanup.

Mapping table (for your compliance team's reference)

What the platform does not give you

The platform does not write your compliance policy. It does not decide:

• What the threshold should be for any given key.
• Who counts as an authorised operator, an approval officer, or an executive guardian.
• What velocity limits, denylists, or jurisdictional restrictions to apply.
• How to design the approval pool for cold-tier operations.
• How long the time-lock window should be.
• Which jurisdiction's audit requirements take precedence.

These are policy decisions your compliance program designs. The platform gives you the primitives — MPC keys with configurable thresholds, workflow components for every policy check you can describe, a workflow canvas to compose policy in, a structured audit surface across the SDK and cluster — and faithfully executes the policy you specify.

The split is important. A platform that made policy decisions for you would not be defensible in a regulator's review. A platform that executes the policy you wrote, with full evidence of every execution, is what an auditor wants to see.

Next

• Dynamic Configuration — multi-tenant patterns, per-client policy, runtime policy reconfiguration.
• Hot Wallet — the 24/7 tier's mechanics in detail.
• Cold Wallet — the air-gapped tier's mechanics in detail.
• MPC Agent reference — every cluster-side option.