Overview

The MPC Agent is the cluster-side counterpart to the device-side Embedded Agent. Each agent instance holds ONE share in a threshold-MPC cohort and participates in DKG, presigning, signing, and reshare ceremonies as one party. Multiple agents typically run together as a cluster — three nodes per logical "Zafeguard cluster" is the canonical deployment.

The agent is a single binary. You either:

• Use Zafeguard's hosted cluster (the default agent your EmbeddedAgent constructor points at when the URL is one of Zafeguard's published endpoints). Nothing to deploy.
• Run your own agent cluster (this section). Your devices point EmbeddedAgent at your URLs; you operate the cluster.

Self-hosting is the right path when:

• You want your devices to talk to MPC nodes you operate yourself for compliance, sovereignty, or trust-model reasons.
• You're building a custody product where your backend is one of the MPC parties (server-side hot wallet, multi-tenant signing service).
• You're integrating Embedded Agent in a regulated environment where the agent has to live inside your network perimeter.

---

The mental model

        ┌──────────────────────────────┐
        │   Your application           │
        │   (device or backend)        │
        │                              │
        │   ┌────────────────────┐     │
        │   │  EmbeddedAgent    │     │
        │   │  or ClusterAgent client│     │
        │   └─────────┬──────────┘     │
        └─────────────┼────────────────┘
                      │  HTTPS / API key
                      ▼
       ┌─────────────────────────────────┐
       │       Your agent cluster        │
       │                                 │
       │  ┌──────┐  ┌──────┐  ┌──────┐   │
       │  │ node │  │ node │  │ node │   │
       │  │  1   │  │  2   │  │  3   │   │
       │  └──┬───┘  └──┬───┘  └──┬───┘   │
       │     │         │         │       │
       │     └── intra-cluster ──┘       │  ← message broker
       │          transport              │     (you operate)
       └─────────────────────────────────┘

• HTTPS interface. Every agent exposes a REST API on port 3000 (configurable). Embedded Agent and ClusterAgent clients talk to one agent at a time; if the topology has more than one agent, the client points at multiple URLs.
• Intra-cluster transport. Within a cluster, agents coordinate ceremonies (envelope routing, peer-to-peer messaging) over a message broker (the agent supports any AMQP 0.9.1 broker). The broker is intra-cluster only — your clients never see it.
• Local state per node. Each agent holds its own MPC share, identity keypair, and per-session data. State is normally persisted to disk so restarts don't lose shares.

A cluster is operationally one logical unit (one license, one DNS name typically) but cryptographically multiple parties. Each node holds a distinct share; the cluster as a whole holds the agent-side of every wallet's threshold MPC cohort.

---

When to read this section

The MPC Agent docs are for operators — the team running the cluster. If you're integrating from the application side (mobile app, browser extension, custody backend), you want the Embedded Agent or ClusterAgent client docs instead.

---

What's in this section

• Deployment → — Docker compose for a 3-node cluster, Kubernetes manifests, bare-metal install. Includes the storage volume and intra-cluster transport layout.
• Configuration → — every config knob: node identity, license certificate, the message broker, database and storage, API auth, rate limits, policy webhooks, performance and limits.
• How it works → — cluster topology, ceremony coordination, the coordination + identity layer.
• Integration patterns → — Embedded Agent setup (the agent serves device-side wallets), custody-backend setup (the agent serves your server-side signing), hybrid setups (both at once).

---

Operational checklist

A self-hosted cluster is a piece of production infrastructure. Before you run one in earnest:

• License certificate. The agent requires an issuer-signed license cert at startup. Without it the binary refuses every ceremony. The cert pins the licensee identity and the allowed curves.
• Identity keypair per node. Each node has a static Ed25519 keypair that pins its cluster-internal identity. Generate with agent gen-secret per node; never reuse across nodes.
• Storage volume. Per-node persistent storage holds the share and per-session DB rows. Lose the volume → lose every wallet whose share that node held → cohort recovery via cold recovery. Back it up.
• Intra-cluster transport. A message broker (any AMQP 0.9.1-compatible broker) for ceremony envelope routing between cluster nodes. One broker per cluster; survives node restarts; secure inside your network — exposing it externally is a security incident.
• TLS for the HTTPS interface. Either terminate at a load balancer (ACM + ALB pattern) or configure api.tls on each node directly. Plain HTTP works for local dev only.
• API authentication. Every external request to the agent's REST API needs an API key (the same key your EmbeddedAgent / ClusterAgent constructor passes as apiKey). Configure under api.auth in the config file.

Each of these is covered in detail on Configuration. Start with Deployment to get a 3-node cluster running locally first.