Skip to main content
The signing cluster is the custody boundary. Where its nodes run, and therefore who holds the key shares, is the choice that defines your deployment model. The API, the operation ledger and chain operations are the same in every model.

​
Managed

Blockops operates a three-node signing cluster with a two-of-three threshold on independent infrastructure, so that no single machine, account or administrative domain holds enough to sign. Blockops also runs the observability, backup and recovery workflows for the cluster. You integrate with the API and the console; the cluster is not exposed to you directly.
Three key shares, each on a different substrate: AWS Nitro Enclave, Google Cloud with AMD SEV, and Blockops Talos BMS, connected in a triangle.

The managed cluster: three key shares on three different substrates.

The three substrates are chosen to be different rather than identical, each with its own provider boundary, identity system, secret store and operations path. The aim is to remove correlated failure, so that compromising one provider, one identity system or one operations team never reaches the signing threshold.

​
Hybrid

Your institution runs one or more nodes of the cluster in infrastructure it owns (its own cloud account, Kubernetes cluster or data centre) and Blockops runs the rest. With a two-of-three threshold and one institution-held share, no transaction can be signed without your node taking part. Blockops provides the node runtime, the deployment automation, and the monitoring, upgrade and recovery workflows; your institution controls the substrate, the network policy, the secret store and access to the machine.

​
Self-hosted

All signing nodes run in your infrastructure. Blockops provides the same runtime, automation and operational workflows, and continues to operate the control plane your applications integrate with, but never holds a key share. This is the model for institutions whose policy requires key material to stay inside their own perimeter. In the hybrid and self-hosted models the institution can own: the cloud account or cluster, network policy and firewall rules, IAM and the secret store, storage and backup targets, the logging destination, upgrade approval, incident response, and the signing nodes themselves.

​
Moving between models

Because signing keys are held as shares, the cluster can be reshared to a new set of nodes, or a new threshold, without changing the wallet’s public key or any address. That is how a deployment moves from managed to hybrid, or adds an institution-operated node, without migrating funds. Resharing is a governed operation, recorded in the audit trail. See Continuity and recovery.