Run a Signer
How to Use This Guide
If you are not familiar with the concept of signing and stacking, and how they work together, be sure to check out the Stackers and Signing concept guide.
This guide is a step-by-step walkthrough for actually setting up and running a signer. If you need to troubleshoot your signer setup, you can check out the Signer Troubleshooting section.
If you need to Stack your STX, or have questions about how that process works, check out the Stack STX guide.
Background and High-Level Process
In order to run a signer, you'll need to run a signer and a Stacks node side-by-side. Specifically, you'll want to run a testnet follower node. Instructions for doing this are listed below in the "Running Your Stacks Node" section. The signer will monitor for events coming from the stacks node and is in charge of using the generated account (next section) to sign incoming Stacks blocks sent from the Stacks node.
This doc will provide instructions on how to set up both using either Docker or building from source. Binaries will not be available in the initial release but will be released at a later date.
It will also walk through how to set up the config files to get the signer and Stacks node communicating correctly.
Knowledge Prerequisites
Docker and basic knowledge of pulling and running images
Basic knowledge of Stacks accounts
Basic knowledge of stacking and the Stacking flow
Minimum System Requirements
These are the minimum required specs to be able to run a node and signer, but it is recommended to have more than the minimum for optimal performance.
Signer, Stacks node and Bitcoin node
4 vcpu
4GB memory if running only a Stacks node and signer
10GB memory if running Stacks + Bitcoin node + signer
1.5+ TB storage (1TB for Bitcoin node, 350GB for Stacks node, and 50 GB for signer)
Signer only
1 cpu
256MB memory
50GB storage
Preflight Setup
Before you get your signer set up, you'll need to generate a new private key on testnet. The stacks-cli
provides a mechanism for quickly generating a new account keychain via a simple CLI interface. The linked guide will show you how to create one of those accounts on testnet.
Once you follow the instructions linked above, be sure to save the information in a secure location, you'll need it in a future step.
What should the networking setup look like?
Signers are intended to work with a local node. The node<->signer connection is not run over SSL, which means you can be exposed to a man-in-the-middle attack if your signer and node are hosted on separate machines. Be sure you are aware of your networking setup, especially making sure your signer isn't allowing requests from the public internet. We recommend setting up your infrastructure to either have the signer and node running locally on the same machine or use only internal networking between them.
Create a Configuration File
Create a new file called signer-config.toml
. In that file, put the contents from the example signer config file from the Sample Configuration Files page. Each field is described on that page.
Running the Signer
There are two options for running the signer: Docker and building from source. The recommended option is to use Docker. If you want to run as a binary, you will need to build stacks-core
from source. Instructions for how to do this are contained below in the relevant section.
Note that at the moment the signer should only be run on testnet using these instructions. The mainnet release is still under development.
Running the Signer with Docker
You can run the signer as a Docker container using the blockstack/stacks-signer:3.1.0.0.0.0
image.
When running the Docker container, you’ll need to ensure a few things:
The port configured as the
endpoint
(in the above linked example, “30000”) must be exposed to your Stacks node. Note that this endpoint should not be public, but must be exposed to your Stacks nodeYou’ll need a volume with at least a few GB of available storage that contains the folder your
db_path
is in. In the above example, that would be /varYou’ll need to include your
signer-config.toml
file as noted below with the first-v
flag
An example command for running the Docker image with ”docker run
” is shown below.
Be sure to replace the STX_SIGNER_PATH
with the correct path to your config file and where you want to install and run the signer. In this example it will be doing so in the current directory.
If you get an error saying that the manifest cannot be found or about the requested image platform not matching the host platform, you are probably running on system architecture other than x64 arch. Since you are using a PR release you'll need to specify your platform with the --platform
flag.
For example, if you are running on M1 Mac, you would add --platform=linux/amd64
to the above command.
Or, with a custom Dockerfile:
Running the Signer as a Binary
If you do not want to use Docker, you can alternatively run your stacks node as a binary.
Official binaries are available from the Stacks Core releases page on Github. Each release includes pre-built binaries. Download the ZIP file for your server’s architecture and decompress it. Inside of that folder is a stacks-signer
binary.
You can run the signer with the following command (be sure to replace ../signer-config.toml
with the actual path of your config file).
Verify the Signer is Running
To make sure your signer is running successfully, run docker ps
to list your running containers.
You should see something like this
Now check the logs of that container by running:
Be sure to replace the container ID at the end with your actual container ID.
You should see a message that says Signer spawned successfully. Waiting for messages to process...
.
You may also see a message indicating that your signer is not registered, like this:
This means your signer is running successfully. Your next step is to begin stacking in order to get your signer registered. First, if you haven't yet, get your Stacks node up and running following the instructions below and then proceed to How to Stack to get started stacking.
Even after you Stack, you may still see a message that says:
This is normal and means that you have stacked, but have not yet reach the prepare phase for your chosen reward cycle. Assuming you have met the stacking minimum, your signer will be picked up and registered during this prepare phase.
Set Up Your Bitcoin Node
While optional, we strongly recommend running your own Bitcoin node in order to optimize signer health and performance.
We have created guides for running both a full Bitcoin node and a pruned Bitcoin node you can follow.
Set Up Your Stacks Node
Once your signer is running, the next step is to set up and run a Stacks node. It’s important to have the signer already running, because the node will not run unless it is able to send events to the signer.
Stacks Node Configuration
Create a file called node-config.toml
. On the Sample Configuration Files page you'll find the full configuration file contents you'll need to add to this file.
The important aspects that you’ll need to change are:
working_dir
: a directory path where the node will persist dataauth_token
: an authentication token that your signer uses to authenticate certain requests to your node. This must match the value you used asauth_password
in the signer’s configuration.events_observer.endpoint
: This is the host (IP address and port) where your signer is configured to listen for events. An example string would be ”127.0.0.1:30000
” or ”my-signer.local:30000
”
Start with an archive
If you are running your Stacks node on the primary testnet, it will be much faster to start with an archive of the chain state rather than syncing from genesis.
Archives can be found from https://archive.hiro.so. For the Stacks node testnet, the latest snapshot can be found at https://archive.hiro.so/testnet/stacks-blockchain/testnet-stacks-blockchain-latest.tar.gz. You can also browse all testnet snapshots.
You’ll want to download this on the same machine that will run the Stacks node. One way to do this is:
This will decompress the snapshot and create a xenon
folder in the same place that you downloaded the archive.
For the Stacks node to use this archive, you must specify working_dir
in your config file to be the place where you can find the xenon
folder.
For example:
The snapshot is available at /Users/blah/xenon
You will set working_dir to equal ”/Users/blah”
Note that the string does not include the “xenon” part
Run a Stacks Node with Docker
You can run the Stacks node as a Docker container using the blockstack/stacks-core
image, currently on version 3.1.0.0.0. When running the Docker container, you’ll need to ensure a few things:
The port configured for
p2p_bind
must be exposed to the internetThe port configured for
rpc_bind
must be accessible by your signerworking_dir
needs to be on a volume with 500GB-1TB of available storageYou’ll need to include your
node-config.toml
file
An example for running the node’s Docker image with docker run is below. Be sure to run this from the same directory as your node-config.toml
file or change the STX_NODE_CONFIG
option.
Or, using a custom Dockerfile:
If when running your node you get a connection refused error that looks like this, you may need to point to Docker.
First, be sure that you have the proper entry point specified in your node-config.toml
file.
If you are inside a Docker container with default bridging mode, then localhost is not available, and you'll need to point to the Docker host.
Run a Stacks Node with a Binary
If you do not want to use Docker, you can alternatively run your stacks node as a binary.
Official binaries are available from the Stacks Core releases page on Github. Each release includes pre-built binaries. Download the ZIP file for your server’s architecture and decompress it. Inside of that folder is a stacks-node
binary.
You can start the binary with:
Verify Stacks Node is Running
Once you’ve started the Stacks node, you’ll see logs that start like this:
It’s important to ensure that you see the log message Registering event observer at XXX
with your signer’s endpoint included. Once Bitcoin headers have been synced, you may also be able to send a GET request to /v2/info
on your Stacks node’s RPC endpoint (port 20443 by default).
You may see a lot of messages while the node is syncing with Bitcoin blocks. You can check the How to Read the Signer Logs section if any of these concern you, but in all likelihood you can ignore any messages until Bitcoin blocks are synced.
Setup Your Stacks Accounts
For more information on the relationship between stacking and signing and how stacking works, check out the Stack STX guide.
As a signer you’ll need to fund and manage two Stacks accounts:
A “pool operator” wallet, which commits delegated STX to your signer
Your signer’s wallet
For testing, make sure that you are using testnet, and not mainnet, STX. You can change network settings within your wallet, and testnet STX can be requested from a faucet.
Setup Your Pool Operator Wallet
You can set up your pool operator wallet using any Stacks wallet, such as Leather or Xverse. You may choose to generate a new account or use an existing one. If you prefer to use a hardware wallet, Leather has support for the Ledger hardware wallet.
Once your wallet has been created, you’ll need to fund it with enough STX to cover transaction fees. For testnet, you can use a faucet exposed by the Stacks Explorer.
Finally, share this wallet’s STX address with the parties that will be delegating STX to you. For improved user experience, you might want to use the helper contract that allows to specify a btc address for stackers (pox4-pools) and to add your pool to lockstacks.com.
Last updated