Self-hosted signing

In the hybrid and self-hosted deployment models, your institution operates some or all of the signing nodes. Each node runs citadel-core, the MPC node software, and holds one share of every wallet key. This section is the operator’s guide: what to provision, how to install, how to configure, and how to run the cluster day to day.

What a signing cluster is

A cluster is n citadel-core nodes with a signing threshold t, where t ≥ ⌊n/2⌋ + 1. Key generation, signing and resharing are protocols run between the nodes; a private key is never assembled in one place. The nodes talk to each other over a NATS message broker and find each other through Consul. Every message between nodes is signed with the sending node’s Ed25519 identity and encrypted to the receiving node. Each node needs:

Component	Purpose
Identity	An Ed25519 key pair unique to the node. The public half is shared with every peer; the private half stays on the node, optionally encrypted at rest with `age`.
Share store	An embedded BadgerDB database, encrypted with AES-256 under a password you set, holding the node’s key shares.
Configuration	A `config.yaml` with the cluster threshold, the initiator’s public key, the shared chain code and the NATS and Consul connection details.
Peer registry	A `peers.json` listing every node’s name and ID, mirrored into Consul.

Who initiates operations

Nodes do not act on their own. Key generation, signing and resharing requests arrive on NATS from the event initiator (in practice citadel-api, the wallet API) and every request is signed with the initiator’s key. Nodes verify that signature against the event_initiator_pubkey in their configuration and drop anything that does not match. Optionally, a set of named authorizers can be required to co-sign each request. This is the boundary between the control plane and the signing plane: the API decides whether a transaction may be signed (policy, approvals, limits); the nodes decide only that the request is authentic before contributing their share.

What Blockops provides

The citadel-core binaries and container image for self-hosted customers.
The citadel-core-cli tool for generating peers, identities and initiator keys, and for recovering a share store from backup.
Deployment guides for systemd on Linux hosts, Kubernetes and AWS ECS Fargate.
Upgrade notes with each release, and support through hello@blockops.network.

What your operators own

The hosts, cluster or cloud account the nodes run in, and the NATS and Consul services they depend on.
The identity passwords, the share-store password and the chain code: if these are lost, the node’s shares cannot be recovered.
Backups of the share store and identity files, and their restore.
Network controls between nodes and to NATS and Consul, and the TLS material for NATS.

The security checklist lists these controls in a form you can hand to a reviewer.

Start here

Install on Linux hosts

Three nodes as hardened systemd services.

Install on Kubernetes

A StatefulSet with secrets, network policy and probes.

Install on AWS ECS

Fargate tasks with Secrets Manager, S3 and EFS.

Configuration reference

Every config.yaml key, environment override and command-line flag.

Introduction

Core concepts

Security & trust

Wallets & signing

Networks

Solutions