Skip to main content
This page covers remote signing for validators and Cosmos-KMS, the Cosmos stack’s remote signer. The guides in this section set both up.

​
What is remote signing?

Remote signing splits a validator into two processes: a node that participates in consensus, and a signer that holds the consensus key and produces signatures on the node’s behalf. The node handles blocks, gossip, and peers; the signer holds the one secret that matters. Separating the two keeps signing secure and makes the node replaceable. The key moves off the node’s exposed filesystem into a hardware security module (HSM) or a cloud key service, where the people and automation that maintain the node never touch it. And because the node holds no secrets, it can be rebuilt, upgraded, or replaced at will. Once replaced, the signer reconnects and signing continues. CometBFT supports this through privval, the seam between the node and whatever holds the key. With priv_validator_laddr set in config.toml, the node signs nothing locally: it listens for a signer connection and sends each vote and proposal out for signature. The wire protocol carries three requests: sign this vote, sign this proposal, and return the public key. The node does not care what is on the other end.

​
Cosmos-KMS

The cosmos-kms repo is a remote signer for CometBFT, written in Go. It implements the signer side of privval and answers a node’s signing requests from a backend that holds the key. One signer process can sign for multiple chains, with each chain backed by exactly one key, and can hold connections to multiple nodes per chain. It is built for operators who must keep validator keys in real custody, an HSM or a cloud key service, rather than in files on chain infrastructure. Three backends are supported:
  • File: a key file on the signer’s disk, for development and testing, not production custody.
  • PKCS#11: a hardware security module, signing on-device through the standard HSM interface.
  • AWS KMS: a key that never leaves AWS KMS, using standard AWS credentials and IAM.
Cosmos-KMS is designed to work with existing validator infrastructure. If you run TMKMS today, Cosmos-KMS is its successor: TMKMS is deprecated, and operators should migrate.

​
How it works

A running signer comes down to five moving parts:
  • Configuration: one file, kms.yaml, in three blocks, the chains it signs for, the validators it dials, and the keys binding each chain to exactly one backend. The kms init command scaffolds it; kms start serves until stopped.
  • Signing: requests travel the privval connection, the backend signs in place, on disk, on the HSM, or inside AWS KMS, and only the signature returns. The private key never crosses the wire.
  • Connection: the signer dials out, so the signing host needs no inbound ports. The address scheme selects the transport: tcp:// uses CometBFT’s SecretConnection, and noise:// adds mutual peer pinning, where each side refuses any connection from an unexpected peer.
  • Key types: ed25519 on every backend, and mldsa65 post-quantum keys on the file backend.
  • Double-sign protection: a per-chain last-signed state file refuses anything at or below a height, round, and step already signed. The protection lives with the key, so even a misbehaving or duplicated validator node cannot force a double sign.

​
Next steps