Run a Signer
What a Stacks signer is made of, what it needs from the machine and the network, and where each piece is set up.
A signer validates proposed Stacks blocks and signs the ones it accepts. This section covers the infrastructure: what has to be running, what it needs from the machine and the network, and where each piece is set up.
If signing is new to you, start with the Signing concept guide.
What has to be running
These run alongside each other, and each depends on the one below it.
stacks-node
Follows the chain and streams block proposals to the signer. A follower, not a miner
Signer Quickstart, step 4
bitcoind
Feeds the Stacks node its view of Bitcoin. Run your own, dedicated to this signer
A shared or third-party Bitcoin node is the usual reason a Stacks node falls behind tip and stays there, and a signer whose node is behind tip stops signing. Treat a dedicated Bitcoin node as part of the signer, not as an optional extra.
The Quickstart runs both the signer and the node end to end, with binary and Docker paths. Field-by-field descriptions of both config files live in Signer Configuration and Stacks Node Configuration.
Minimum system requirements
These are minimums for the signer, the Stacks node and a Bitcoin node together. Provision above them if you can.
4 vCPU
8 GB memory for the signer and Stacks node, 16 GB with a Bitcoin node alongside them
1.5 TB storage or more: roughly 1 TB for the Bitcoin node, 500 GB for the Stacks node, 50 GB for the signer
Networking
The signer and the node talk over plain HTTP. The signer builds its node URL as http://{node_host}, and the auth_password it sends is your node's auth_token, in the clear. Anything that can observe that link can read the token and impersonate your node to the signer.
Keep both on the same private network, with the signer reachable only from the node. Loopback on a single machine is the simplest way to do that. Separate hosts on a trusted private subnet is the better one, because a host running stacks-node participates in the peer-to-peer network and is easier to enumerate, so keeping the signer off it hides the signer. Either way, the signer's endpoint must never be reachable from the public internet.
User separation, systemd hardening and firewalling are covered in OpSec Best Practices.
Setup checklist
Generate the signer key
A fresh Stacks account, whose private key becomes stacks_private_key. Store it somewhere you can restore from. See Signer Quickstart, step 1.
Confirm both are healthy
The signer logs Signer spawned successfully. The node logs Registering event observer at with your signer's endpoint, then begins syncing Bitcoin headers. Until your signer is in a reward set it will also log that it is not registered for the current cycle, which is expected.
Registering, once it runs
A running signer is not yet part of the signer set. Your signer key has to be bound to a signer-manager contract, and stakers have to route at least 50,000 STX through that manager in aggregate before it enters a cycle's signer set.
Under PoX-5 that binding is a standing on-chain grant rather than PoX-4's per-transaction signature: you sign a SIP-018 message with your signer key, the signer-manager submits it through grant-signer-key, and then calls register-signer.
Generate a Signer Signature produces the grant
Staking STX covers the staking side
Key and Address Rotation covers changing the key later
Running it well
Best Practices to Run a Signer, including redundancy, fall-back deployments and auto-restart
Last updated
Was this helpful?