SDK boundaries

The MPC SDK is opinionated. It ships strong primitives for the topologies it targets, and it deliberately doesn't ship others. This page is the honest list of what's not in scope — read it before designing a system around requirements the SDK can't meet.

Hard boundaries (no workaround inside the SDK)

Air-gapped DKG and air-gapped signing

EmbeddedAgent.create() and ClusterAgent.sessions.createKeyShare() both run their ceremonies over HTTPS to cohort agents. There is no offline DKG path that produces shares without any network — the protocol exchanges encrypted shares between parties during the ceremony, and that exchange uses HTTP transport.

What this blocks: sovereign nation digital-asset reserves, military-grade key management, FedRAMP High custody systems where regulators require zero internet connectivity to the signing keys.

What you can do offline: RecoveryBundle.recover() runs license-free on a fully air-gapped machine — see Embedded Agent — cold recovery. The recovery flow extracts the raw root private key from threshold-many shards; the air-gapped machine needs only the bundle bytes and the RSA private key, no network. So you can use the SDK as the cold-recovery half of a hybrid system whose signing half uses a different protocol (FROST, CGGMP, hardware-token-based threshold).

Hardware-token integration (HSM PKCS#11, smart cards)

The SDK signs through software shares loaded in process memory, with hardware sealing applied at rest via P256Plugin + HardwareWrappedStorage. It does not expose the share to a hardware token (PKCS#11 HSM, smart card, FIDO2 authenticator) and ask the token to compute the share's contribution to the signature ceremony.

What this blocks: regulatory regimes that require every signing operation to occur inside an FIPS 140-2 Level 3 module (some financial / government tiers).

Closest workaround: pair P256Plugin with a Secure Enclave / Android Keystore / cloud KMS key for at-rest sealing — the share is decrypted into process memory only at signing time and remains in memory only for the duration of the cohort round-trip.

Multi-cluster active-active replication

ClusterAgent.connect() binds to one cluster at a time. There is no built-in MultiCluster that fans signing requests across two geographically-separated clusters in parallel with automatic failover. migrateKeyShare() moves a wallet between clusters but is not a hot-failover primitive.

What this blocks: zero-downtime regional failover where a sign call must succeed within X ms even if one entire cluster is down.

Closest workaround: orchestrate at your platform layer — wrap two ClusterAgent clients with a fallback retry, accept that a fresh migration is needed if a cluster is truly lost (not just degraded).

Soft boundaries (integrator-side workarounds available)

Multi-party off-line ceremony orchestration

A 4-of-7 board signing flow where the seven board members are scattered across continents, signing asynchronously over days, with handoff via encrypted email — the SDK does not orchestrate this directly. It ships per-device primitives (loaded.sign() returns this device's partial; Utils.finalizeSignature combines partials from N hosts) and the rest is your queueing / state-machine job.

What you build: a backend that holds a signing-session state machine. Each board member's device runs loaded.sign(...) independently against the same cohort, ships its partial up to your backend, and your backend calls Utils.finalizeSignature once threshold-many partials arrive. The cohort agents see threshold-many partial-signing rounds spread across time; as long as the same presignature session id is used, the partials combine.

Tenant isolation at the cluster layer

The SDK does not enforce that customer A cannot trigger signing on customer B's keyId — the cluster API key is platform-wide, and access control sits at your platform's HTTP layer, not inside ClusterAgent. See Multi-tenant SaaS pattern.

Per-tenant rate limiting and quota allocation

Presignature pool auto-refill is per-EmbeddedAgent instance. For multi-tenant platforms, large tenants can starve smaller ones on agent throughput; the SDK provides per-wallet presignaturePoolStats for observability, but quota allocation is your platform's responsibility.

High-frequency signing event hooks

The presignature pool's auto-refill is fire-and-forget by design — there are no event callbacks for "refill task started / failed / completed." For HFT workloads use the polling pattern against presignaturePoolStats and forward to your metrics stack.

Things the SDK does support that are easy to miss

If your design needs something that isn't in the table above and isn't in the hard-boundaries list, it's probably documented but discovery is your job — open the page that owns the topology and search the reference for the closest method. If it doesn't exist, reach out to Zafeguard support before designing around it.