Platform overview

Zafeguard is one platform for the wallet, signing, and workflow primitives every on-chain product needs. Threshold-MPC keys, a visual workflow canvas, an embedded-agent SDK, and 80+ on-chain components share a single API, a single SDK, and a single billing surface.

This page walks through what that buys you — the capabilities, when each one matters, and where to read deeper.

MPC made easy for any developer

Threshold-signature schemes have historically meant a serious cryptographic engineering project: shipping a distributed-key-generation ceremony, running an MPC cluster, and reviewing protocol papers before writing a single line of product code.

Zafeguard collapses that integration into a few lines of TypeScript.

import { EmbeddedAgent, Curve, RecoveryKind } from '@zafeguard/mpc-sdk';

const signer = new EmbeddedAgent({
  agents: [{ baseUrl: 'https://node-1', apiKey: '…' }],
  threshold: 2,
  curve: Curve.Secp256k1,
});

const loaded = await signer.create({
  signerId: 'user-wallet',
  recovery: { kind: RecoveryKind.Noop },
  passphrase,                                  // seals loaded.exportedBlob in one round-trip
});
const sigPartials = await loaded.sign({ messageHash });
const sig = await loaded.finalizeSignature({
  messageHash: sigPartials.messageHash,
  partials: sigPartials.partials,
  derivationPath: sigPartials.derivationPath,
});

That snippet:

• Runs a real distributed-key-generation ceremony — no single party ever holds the full private key.
• Provisions the share on the user's device plus the configured cohort of cloud signing parties.
• Returns a LoadedKeyShare exposing signerId, publicKey, curve, threshold, and the sign / pool / export methods.
• Signs against a threshold of parties — the resulting signature is a standard ECDSA signature, indistinguishable on-chain from a single-key transaction.

There is no DKG plumbing to write, no MPC cluster to operate, no cryptographic primitive to audit at the application layer. The complexity stays inside the SDK; your product code stays normal.

A signer instance is single-curve — Curve.Secp256k1 covers EVM and Bitcoin, Curve.Ed25519 covers Solana. Apps that need both run two signer instances under the same signerId namespace (see Embedded Agent reference). On-chain addresses are derived from loaded.publicKey by your application or by the COMPUTE_EVM_ADDRESS / COMPUTE_PUBLIC_KEY components in a workflow.

One platform, every on-chain shape

The same MPC wallet is the signer for every workflow shape Zafeguard supports. You do not provision a different vendor for payments, embedded sign-in, gas sponsorship, cross-chain swap, NFT checkout, or autonomous agent execution — those are all workflows composed from the same component library against the same wallet primitive.

Each shape is a workflow. Each workflow can be triggered from your code, on a schedule, by a webhook, or by an AI agent through MCP. The signer never changes — only the workflow around it.

→ Browse the component library

Multi-chain coverage

Two curves cover every supported chain. A secp256k1 signer covers EVM and Bitcoin from one share; an Ed25519 signer covers Solana from another. Apps that need all three run both signers under the same logical wallet identity.

loaded.sign({ messageHash, derivationPath? }) produces a curve-appropriate signature; the chain-specific transaction shape (RLP for EVM, PSBT for Bitcoin, Solana transaction format) is composed by the corresponding chain component in your workflow. Address derivation uses the standard BIP-32 / SLIP-0010 paths against loaded.publicKey — either by your app or via the COMPUTE_EVM_ADDRESS / COMPUTE_PUBLIC_KEY components.

→ EVM components · Solana components · Bitcoin components

Hosted, embedded, or fully self-hosted

The same SDK works across three deployment models. Move between them as your product matures — no rewrite.

Built-in MPC

The fastest path. Every workspace on the Professional plan and above is provisioned with MPC-backed key protection by default. No infrastructure to run, no servers to monitor. Keys are sharded across geographically distributed signing parties. Suitable for production from day one.

Embedded signer

Your user's device holds one share. A cohort of cloud signing parties holds the rest. Threshold signing requires the device plus the configured number of parties. This is the warm-cold-wallet shape — the device pre-mints a presignature pool to cut per-sign latency, and the cohort guarantees recovery if the device is lost.

Suitable for consumer wallet apps, embedded social-login flows, and any product where the end user should hold a meaningful share of their own key without managing a seed phrase.

Self-hosted MPC

Deploy the MPC signing cluster entirely on your own infrastructure — your cloud, your on-premises servers, or a mix. No party outside your environment ever participates in any signing operation. Suitable for institutions with strict data-sovereignty requirements, regulated custody products, and white-label deployments.

The SDK surface is identical across all three. Code written against built-in MPC moves to embedded or self-hosted by changing configuration, not by changing application logic.

→ Embedded Agent reference · MPC Agent reference

The visual workflow canvas

Most signing operations in production are not standalone — they are one step in a chain that includes reading on-chain state, calling external APIs, branching on a condition, iterating over a list, sponsoring gas, sending notifications, and waiting on a webhook.

Zafeguard exposes that chain as a visual canvas. You drag components, connect typed ports, and run the resulting graph from code:

const [{ runId }] = await fetch(
  `https://api.zafeguard.com/v1/sdk/workflows/${workflowId}`,
  { method: 'POST', headers: { 'X-Api-Key': process.env.ZAFEGUARD_API_KEY! } },
).then(r => r.json());

Every run streams live status by SSE, exposes every stage's output for inspection, and reports the credit cost per stage. The same workflow can be triggered by API call, by schedule, by webhook, or by an AI agent through MCP — without changes to the graph.

→ SDK quickstart · Streaming reference

Composable security and recovery

The MPC primitive is the foundation. The security policy on top is yours to compose — partly in SDK configuration, partly in the workflow canvas.

The cryptographic primitives ship in the SDK; the policy around them composes on the canvas.

Runtime configuration

The SDK is constructed per-user in your application. Threshold, cohort agents, curve, storage backend, recovery clause, and presignature-pool policy are all runtime parameters — your application decides which to pass based on tier, region, risk, or any other dimension. The signer that ends up on a starter-tier user's device can differ from a premium-tier user's signer without any change to your application code beyond the config resolver.

What does NOT change at runtime in the SDK: the cohort topology of an existing signer. reshare({}) only rotates shares within the same cohort. Reshaping a signer to add or replace parties is not currently exposed.

What composes on the workflow canvas instead: policy stages, gas sponsorship, audit emission, and approval gates. Editing these is a dashboard change; the workflow ID your application triggers stays the same and the new policy applies on the next run.

Where to go next

Quickstart → Five-minute walkthrough from API key to a signed transaction.

SDK reference → Caller SDK and MPC SDK — every public surface.

Embedded Agent → Build a non-custodial wallet inside a mobile or web app.

MPC Agent → Server-side cluster client for institutional custody.

Component library → All 80+ on-chain components with input and output schemas.

Examples → End-to-end walkthroughs for the common workflow shapes.