How to Stack (as a signer)
This doc assumes you are familiar with stacking at a conceptual level. If not, you may want to read the Stacking section of Stacks 101.
Much of the technical instructions below apply to users who are interested in either solo stacking or becoming a pool operator. Both of those types of stackers will need to run a signer.
However, if you prefer to participate in a pool by delegating your STX, you do not need to also operate a signer. Simplified instructions for delegating your STX token using Leather and Lockstacks can be found in the Nakamoto for Stackers doc.
In Nakamoto, stacking flows have significant changes in comparison to previous versions of Stacks. Because Nakamoto requires stackers to run a signer, which validates blocks produced by Stacks miners, stackers need to provide new information when making Stacking transactions.
These changes affect both solo Stacking and delegated Stacking. This document outlines the new flows for both cases.
If you aren't familiar with the general block production process under Nakamoto and what role signers and stackers play, you may want to read Nakamoto in 10 Minutes to get up to speed.
The following sections will walk you through how to begin operating as a solo stacker or pool operator.
If you are only interested in delegating your STX to a pool operator and not running your own signer, the Nakamoto for Stackers guide may be a better guide to follow.
Stacking utilizes the pox-4
contract. There is a detailed walkthrough of the stacking contract that you can look at to see what functions are being called at each phase and some common errors you may encounter.
Before we get into the step-by-step of how to actually stack, it's important to make sure you have an understanding of the different roles, processes and functions involved in Stacking.
Definitions and Roles
Stacker: an entity locking their STX to receive PoX rewards. This is a broad term including solo Stackers and Stackers who use pools.
Solo stacker: an entity that locks their own STX and runs a signer. They don’t receive delegation.
Delegator: a stacker who locks their STX and delegates to a signer or pool operator. They don’t run the signer.
Pool operator: an entity that runs a Signer and allows others to delegate their STX to them. A pool operator doesn’t need to Stack their own STX, but they can. They will also run a signer, but the pool operator and signer address may be different
Signer: an entity that runs the stacks-signer software and participates in block validation. This can be either a solo Stacker or an entity receiving delegated STX. Depending on context, this may also refer to the signer software that validates blocks.
It's important to understand that in the context of the pool operator and signer, these are likely the same entity but may not be the same S_tacks address._
This distinction will be discussed further as we cover the step-by-step process below.
As mentioned above, there are three primary ways you can stack:
Solo stacking
Pool operator
Delegator
This guide is focused on 1 and 2. Let's walk through the flow for each of these now, and then we'll get into the step-by-step process for actually carrying out these stacking transactions.
As you read through these, it may be helpful to follow along with the functions in the pox-4 contract to get an idea of what each function is doing.
Solo Stacker Flow
Note that in order to solo stack, you need to have the minimum number of STX tokens. This number can be found by visiting the pox endpoint of Hiro's API at https://api.testnet.hiro.so/v2/pox and looking at the min_threshold_ustx
field. (1 STX = 1,000,000 uSTX)
Call the function stack-stx
stack-stx
The first thing solo stackers will need to do is call the stack-stx
function.
Just like in previous versions of PoX, Stackers call stack-stx
, but with the new arguments added in Nakamoto. The arguments are:
Amount: Denoted in ustx (1 stx = 1,000,000 ustx)
PoX Address: the BTC wallet to receive Stacking rewards
Start burn height: the current BTC block height
Lock period: the number of cycles to lock for (1 minimum, 12 max)
Signer key: the public key that your signer is using
Signer signature: the signature that proves control of this signer key
max-amount: This parameter is used to validate the signer signature provided. It represents the maximum number of ustx that can be locked in this transaction.
auth-id: This parameter is used to validate the signer signature provided. auth-id is a random integer that prevents re-use of this particular signer signature.
Act as a signer
In the “prepare phase” before the next stacking cycle (100 blocks), the exact set of Stackers will be selected based on the amount of STX stacked. Just like in previous versions of PoX, each Stacker will have some number of reward slots based on the amount of STX locked.
It is critical that solo stackers have their signer running during this period. The prepare phase is when distributed key generation (DKG) occurs, which is used when validating blocks by signers.
In general, you don’t need to do anything actively during this period, other than monitoring your signer software to ensure it’s running properly.
Extending their stacking period
Just like in the current version of PoX, you can extend your lock period while still Stacking. The function called is stack-extend
.
You can “rotate” your signing key when extending your lock period.
The arguments are:
Extend count: the number of cycles to add to your lock period. The resulting lock period cannot be larger than 12. For example, if currently locked with 6 cycles remaining, the maximum number you can extend is 6.
Pox Address: the BTC address to receive rewards
Signer public key: the public key used for signing. This can stay the same, or you can use a new key.
Signer signature: a signature proving control of your signing key
max-amount: This parameter is used to validate the signer signature provided. It represents the maximum number of ustx (1 stx = 1,000,000 ustx) that can be locked in this transaction.
auth-id: This parameter is used to validate the signer signature provided. auth-id is a random integer that prevents re-use of this particular signer signature.
Pool Operator Stacking Flow
For pool operators, the flow is a bit different. Remember that as a pool operator, other stackers are delegating their STX to you to stack on behalf of them. This additional role adds a couple of extra steps to your stacking flow if operating as a pool operator.
Similar to the changes to solo Stacking, the big difference for delegation flows is the inclusion of signer keys and signatures. Because signers need to make transactions to “finalize” a delegation, these new arguments add new complexities to the signer.
Delegator initiates delegation
This step does not apply to pool operators/signers. It is included here to illustrate the end-to-end flow, but if you are operating as a pool operator/signer you will not perform this step. Instead, users delegate their stx to you as the pool operator.
The first step, where the delegator sets up their delegation to a pool operator, is to call delegate-stx
. This function does not directly delegate the stx, but rather allows the pool operator to issue the stacking lock on behalf of the user calling this function.
The arguments here are unchanged from previous versions of PoX:
Amount: Denoted in ustx (1 stx = 1,000,000 ustx)
Delegate to: the STX address of the pool operator they're delegating to. Note that this is different from the “signer key” used. Instead, this is the STX address that is used to make PoX transactions.
Until burn height: an optional argument where the delegation expires
Pox Address: an optional BTC address that, if specified, the signer must use to accept this delegation
Pool operator “activates” the delegation
Just as in the current PoX contract, after a delegator calls the delegate-stx
function, the pool operator calls delegate-stack-stx
to commit the delegator’s STX.
The arguments are:
Stacker: the STX address of the delegator
Amount: denoted in ustx (1 stx = 1,000,000 ustx)
Pox Address: The BTC address for the delegator to receive stacking rewards
Start burn height: the current BTC block height
Lock period: number of cycles to lock for. If the delegator provided the until burn height argument, then the end of these cycles cannot be past the expiration provided.
This step also allows the pool operator to proactively choose which Stackers they’ll accept delegation from. For “closed” pools, the pool operator will only call this function for approved Stackers. It is up to each pool operator who runs a closed pool to implement this process.
This step can happen for many Stackers before going to the next step.
If you look at the function source code, you'll see that the delegate-stack-stx
function sets the stacker's reward cycle to be the next reward cycle.
When generating your signature and your stack-aggregation-commit
transaction, you'll want to make sure that the reward cycles match.
So if you are in cycle 557 when you call the delegate-stack-stx
function, you'll want to pass in cycle 558 when you generate your signature and your stack-aggregation-commit
transaction.
With stack-aggregation-commit
, the reward-cycle
arg is saying "I'm commiting these stacks to be stacked in cycle N". But the delegate-stack-stx
transaction gets you setup for next cycle, aka 558.
Also make sure that, when you generate your signature, you use 558 as the reward cycle. in solo stacking methods, you use the current reward cycle in the signature, but not for stack-aggregation-commit
. This is because with stack-aggregation-commit
you can commit stacks for future cycles, not just the n+1 cycle
Pool operator “commits” delegated STX
The next step is for the pool operator to call stack-aggregation-commit
.
At this point, the STX are committed to the pool operator, and the pool operator has some “aggregate balance” of committed STX. The pool operator is not actually eligible for rewards and signer slots until this step is called.
The pool operator cannot call this until the total number of STX committed is larger than the minimum threshold required to Stack. This threshold is a function of the total number of liquid STX.
This number varies and can be found by visiting the pox endpoint of Hiro's API at https://api.testnet.hiro.so/v2/pox and looking at the min_threshold_ustx
field. (1 STX = 1,000,000 uSTX).
Once the threshold is reached, the pool operator calls stack-aggregation-commit
. This is the point where you as the pool operator must provide your signer key and signer key signature. The arguments are:
Pox Address: the BTC address tp receive rewards
Reward-cycle: the current reward cycle (see the note above on passing the correct reward cycle here)
Signer key: the public key of your signer (remember that this may be different than the address you are using to operate the pool, but this step is how you associate the two together)
Signer signature: Your generated signer signature (details on how to do this are below)
In the Definitions and Roles section at the top of this document, we described how the pool operator and signer may be the same entity, but not necessarily have the same address.
Signers who are also pool operators and have stx delegated to them also need a separate keychain to make Stacking transactions such as delegate-stack-stx
listed earlier.
So as a signing entity operating a pool, you will have two accounts:
Your pool operator account, which you will use to conduct all of the stacking operations we have covered here
Your signer account, which is what you used to set up your signer. This signer public key is what you will pass in to the above aggregation commit function, and is also the key you will use when generating your signer signature
If you are operating as a signer and a pool operator, you'll need a separate key because you need to have the ability to rotate your signer key when necessary.
The PoX contract is designed to support rotating the signer key without needing your Stackers to un-stack and re-stack later. You cannot rotate a pool operator key without needing to wait for all delegated Stackers to un-stack and finally re-stack to the new pool operator address.
Because of this limitation of being unable to rotate pool operator addresses, it’s highly recommended to have a separate pool operator key. The benefit of a separate pool operator key is that it can easily be used in existing wallets, including hardware wallets.
Once this succeeds, the signer is eligible for reward slots. The number of reward slots depends on the amount of STX committed to this signer. Even if the signer commits more than the “global minimum”, the minimum amount to receive a slot depends on the amount of STX locked for each cycle.
To act as a signer, each step up to this point must be taken before the prepare phase of the next cycle begins. It is crucial that the signer software is running.
Pool operator increases amount committed
Even after the signer commits to a certain amount of STX in the previous step, the signer can increase this amount once more delegations are received. The initial steps must be taken for each Stacker (delegate-stx
and then delegate-stack-stx
), and then stack-aggregation-increase
can be called.
Step by Step Stacking Guide
Now that you are familiar with the overall stacking flow and the different roles played, let's dive into the step-by-step guide for actually conducting the stacking process.
There are several ways you can go about stacking. This guide will cover using Lockstacks, which is a stacking web application and the simplest option.
Additionally, you can choose to call the stacking functions directly from the deployed contract in the explorer.
The fields and process will be the same, but the UI will differ.
Finally, you can stack using JS and the @stacks/stacking package if you prefer. Again, the functions and parameters will be the same, you will just be writing your JS code directly instead of using a UI.
If you are interested in using this method, you'll want to follow the stacking guide created by Hiro, and be sure to integrate the new parameters described in Hiro's Nakamoto update doc.
Step 1: Run a signer
This is a necessary prerequisite to stacking as a solo stacker or pool operator.
Running a signer involves setting up a hosted production environment that includes both a Stacks Node and the Stacks Signer. For more information, refer to the running a signer doc.
Once the signer software is running, you'll to keep track of the stacks_private_key
that you used when configuring your signer software. This will be used in subsequent Stacking transactions.
In the note above about pool operator vs signer keys, this corresponds to your signer key, not your pool operator wallet
Step 2: Generate a signer key signature
Overview of signer keys and signatures
The main difference with Stacking in Nakamoto is that the Signer (either solo Stacker or signer running a pool) needs to include new parameters in their Stacking transactions. These are Clarity transactions that pool operators will call when interacting with the pox-4.clar
contract. Interacting with that contract is how you as a pool operator actually stack your STX tokens.
Here is an overview of the fields you will need to pass. We'll cover how to get and pass these fields as we dive further into this doc.
The current pox-4 contract address can be found by visiting the following endpoint of the Hiro API: https://api.testnet.hiro.so/v2/pox.
You can then visit the Nakamoto Explorer to view the contract and pass in the contract id.
You may want to review this contract to familiarize yourself with it.
signer-key
: the public key that corresponds to thestacks_private_key
your signer is usingsigner-signature
: a signature that demonstrates that you actually controls yoursigner-key
. Because signer keys need to be unique, this is also a safety check to ensure that other Stackers can’t use someone else’s public keymax-amount
: The maximum amount of ustx (1 stx = 1,000,000 ustx) that can be locked in the transaction that uses this signature. For example, if callingstack-increase
, then this parameter dictates the maximum amount of ustx that can be used to add more locked STXauth-id
: a random integer that prevents re-use of a particular signature, similar to how nonces are used with transactions
Signer signatures are signatures created using a particular signer key. They demonstrate that the controller of that signer key is allowing a Stacker to use their signing key. The signer signature’s message hash is created using the following data:
method
: a string that indicates the Stacking method that is allowed to utilize this signature. The valid options arestack-increase
,stack-stx
,stack-extend
, oragg-commit
(for stack-aggregation-commit)max-amount
: described aboveauth-id
: described aboveperiod
: a value from 0-12, which indicates how long the Stacker is allowed to lock their STX for in this particular Stacking transaction. Foragg-commit
, this must be equal to 1reward-cycle
: This represents the reward cycle in which the Stacking transaction can be confirmed (see the note above on passing in the correct reward cycle forstack-stx
vsstack-aggregation-commit
)pox-address
: The Bitcoin address that is allowed to be used for receiving rewards. This corresponds to the Bitcoin address associated with your signer
Now that we have an overview of role and contents of signatures, let's see how to actually generate them. You have several options available.
Generating your signature with stacks.js
The @stacks/stacking NPM package provides interfaces to generate and use signer signatures. You'll need to use @stacks/stacking
package version 6.13.0.
There is a new function called signPoxSignature
that will allow you to generate this signature and pass it in to the stacking function.
More information and code samples can be found on Hiro's Nakamoto docs.
Generating your signature using the stacks-signer CLI
If you already have your signer configured and set up, you can use the stacks-signer CLI to generate this signature. You can either SSH into your running signer or use the stacks-signer CLI locally. If using the CLI locally, you will need to ensure you have a matching configuration file located on your filesystem. Having a matching configuration file is important to ensure that the signer public key you make in Stacking transactions is the same as in your hosted signer.
The CLI command is:
These arguments are:
pox-address: the BTC address where the signer wants to receive Stacking rewards
reward-cycle: For solo stacking, this must refer to the current reward cycle where the user will broadcast their Stacking transaction. For the stack-aggregation-commit transaction, used in delegated signing, this should match the reward-cycle they are using as an argument in stack-aggregation-commit.
config: path to a local Signer configuration file
period: for solo stacking, this refers to the lock-period argument the user makes in stack-stx and the extend-count argument in stack-extend. For stack-aggregation-commit, this must equal 1.
topic: This string is dependent on the Stacking function where the signature will be used.
For stack-stx, the topic needs to be
stack-stx
For stack-extend, the topic needs to be
stack-extend
For stack-aggregation-commit, the topic needs to be
agg-commit
Once the command is run, the CLI will output two fields:
Signature: 0xaaaaaaaaa
Public Key: 0xbbbbbb
You will use both the signature and public key when calling Stacking transactions from your pool operator address as outlined above. Remember that this may be different than your signer address.
Generating your signature with Lockstacks
Lockstacks is a web application that provides an easy-to-use interface for stacking and generating signatures. We'll cover using Lockstacks for stacking at the end of this document, here we will cover how to use it to generate a signature.
At the time of writing, this has only been tested using the Leather wallet.
You can visit lockstacks.com to generate a signer key signature. Make sure you’re connected to the correct network. To generate a signer key signature, it’s important that you’ve logged in Leather with the same secret key that was used to generate your signer key, not the account that will serve as your pool operator address. Once you’ve setup that account on Leather, you can log in to Lockstacks. Click the link “Signer key signature” at the bottom of the page. This will open the “generate a signer key signature” page.
The fields are:
Reward cycle:
For all solo stacking transactions, this must equal the current reward cycle, not the cycle in which they will start stacking. The field defaults to the current reward cycle.
For stack-aggregation-commit, this field must equal the cycle used in that function’s “reward cycle” argument. Typically, that equates to current_cycle + 1.
Bitcoin address: the PoX reward address that can be used
Topic: the stacking function that will use this signature
Max amount: max amount of STX that can be used. Defaults to “max possible amount”
Auth ID: defaults to random int
Duration: must match the number of cycles used in the stacking transaction. For stack-aggregation-commit, use “1”.
Each of these fields must be exactly matched in order for the Stacking transaction to work. Future updates to Lockstacks will verify the signature before the transaction is made.
Click the “generate signature” button to popup a Leather page where you can generate the signature. Once you submit that popup, Lockstacks will have the signer key and signature you generated.
After you sign that message, you'll see the information you need to share with Stackers who are delegating to you, including the signer public key and signature.
You can click the “copy” icon next to “signer details to share with stackers”. This will copy a JSON string, which can be directly pasted into the Lockstacks page where you make your Stacking transaction. Alternatively, this information can be shared and entered manually.
We'll cover the Lockstacks pages for actually making those transactions in the next section of this document.
Using a hardware or software wallet to generate signatures
When the signer is configured with a stacks_private_key
, the signer may want to be able to use that key in a wallet to make stacking signatures.
If the signer uses a tool like @stacks/cli to generate the key, the CLI also outputs a mnemonic (aka “seed phrase”) that can be imported into a wallet. Because the Stacks CLI uses the standard derivation path for generating Stacks keys, any Stacks wallet will default to having that same private key when the wallet is imported from a derivation path. Similarly, if a hardware wallet is setup with that mnemonic, then the Signer can use a wallet like Leather to make stacking signatures.
The workflow for using a setting up a wallet to generate signatures would be:
Use @stacks/cli to generate the keychain and private key.
Typically, when using a hardware wallet, it’s better to generate the mnemonic on the hardware wallet. For this use case, however, the signer software needs the private key, and hardware wallets (by design) don’t allow exporting private keys.
Take the
privateKey
from the CLI output and add it to your signer’s configuration.Take the mnemonic (24 words) and either:
Setup a new hardware wallet with this mnemonic
Store it somewhere securely, like a password manager. When the signer needs to generate signatures for Stacking transactions, they can import it into either Leather or XVerse.
When the user needs to generate signatures:
Setup your wallet with your signer key’s private key. Either:
Setup your Leather wallet with a Ledger hardware wallet
Import your mnemonic into Leather, XVerse, or another Stacks wallet
Open an app that has stacking signature functionality built-in
Connect your wallet to the app (aka sign in)
In the app, enter your PoX address and “submit”
The app will popup a window in your wallet that prompts you to sign the information
The app will show clear information about what you’re signing
Create the signature
If using a Ledger, confirm on your device
The app will display two results:
Your signer key, which is the public key associated with your signer’s key
Your signer signature
Finally, make a Stacking transaction using the signer key and signer signature.
Now that you have your signer signature generated, it's time to start stacking. This process will vary depending on your chosen method. We've included instructions for solo stacking and stacking as a pool operator below.
Step 3a: Stack as a solo stacker
stack-stx
To start, you'll visit Lockstacks and click the “Stack independently” button on the home page.
This page will allow you to input the following input:
The amount of STX you want to lock
The duration (in number of cycles) to lock for
Your BTC address where you will receive Stacking rewards
New fields:
Your signer public key
Your signer key signature (this is what you generated in the previous step)
Auth ID
Max amount
stack-extend
If you want to extend the amount of time that your STX will be locked for, you can use the stack-extend page on Lockstacks.
If you’re already stacking, the home page will provide a link to “view stacking details”. From there, you can choose to extend.
On this page are the following fields:
The number of cycles you want to extend for
Your BTC address to receive rewards
New fields:
Signer public key
Signer key signature
Step 3b: Stack as a pool operator
The first step with delegated stacking involves a stacker delegating their Stacks to a specific pool operator. Stackers can do this by visiting the “Stack in a pool” page on Lockstacks.
As the pool operator, you must provide a STX address (a “pool admin address”) that will manage delegations. As discussed in previous sections, this is a separate address from the signer’s private key, and this can be any address. This address is what will be used when making transactions to confirm and aggregate delegated STX.
Pool operators can log in to LockStacks and visit https://lockstacks.com/pool-admin to make pool management transactions.
delegate-stack-stx
Once a user has delegated to a pool operator, the pool operator must call delegate-stack-stx
for each individual stacker.
stack-aggregation-commit
Once a pool has enough delegated STX to become a signer, the pool admin needs to visit the stack-aggregation-commit
page on Lockstacks. The pool operator enters the following information:
Reward cycle: the reward cycle where the operator is “commiting” delegated STX. This must be done for every individual reward cycle where the pool will be acting as a signer.
BTC address
New fields:
Signer public key
Signer key signature (generated in a previous step using the signer key)
Auth ID
Max amount
Once this transaction has been confirmed, the pool operator is eligible to be a signer for an upcoming reward cycle.
Relationship between manual stacking transactions and the running signer
This section describes the various transactions that signers need to make in order to be registered as a signer for a certain reward cycle. The order of operations between the automated signer and the stacking transactions that need to be done “manually” is important for ensuring that a signer is fully set up for a certain reward cycle.
Prerequisite: ensure the signer is hosted and running
It's important to emphasize the importance of getting the signer running in a hosted environment before making Stacking transactions. If the signer doesn’t do that, they run the risk of being registered as a signer without their signer software being ready to run DKG and other important consensus mechanisms.
Some of the important things to double check to ensure the signer is “running” are:
The signer software is configured with a private key that the user can access (either through SSH or other means). This is important because their signer needs to utilize this private key to generate signer key signatures that are used in Stacking transactions.
The signer software is properly configured to make RPC calls to a Stacks node. This refers to the
endpoint
signer configuration field. If properly configured, there should be logs in the Stacks node that show the RPC calls being made from the signer.The stacks node is properly configured to send events to the signer. This refers to the [[
event_observers
]] field in the Stacks Node’s configuration. If properly configured, the signer should have logs indicating that it’s receiving events from the Stacks node.
How a signer becomes registered in the signer set
Each of the stacking transactions described above are done “manually”. More specifically, this means that none of these transactions are executed automatically by the signer software. The transactions must be done “out of band”.
In order for a signer to actually be registered in a reward cycle, there need to be manual transactions made in the pox-4
contract. While the signer software is running, it is continually polling the Stacks node and asking “am I a signer in reward cycle N?”.
If these manual transactions are confirmed, and the signer has enough STX associated with the signer’s public key, the signer will be registered as a signer in the signer set.
Solo stacking
The workflow for solo stackers is more simple, because there are less stacking transactions that need to be made.
For solo stacking, the only transaction that needs to be made is stack-stx
. Included in this transaction’s payload is the signer’s public key.
In order for the signer to be registered in reward cycle N+1, the stack-st
x transaction must be confirmed during the first 2000 blocks of reward cycle N. The last 100 blocks of cycle N (the “prepare phase”) is where DKG occurs.
The start of the prepare phase is when Stacks nodes determine the official signer set of the next reward cycle.
Delegated Stacking
The workflow for delegated signers is more complex, because it requires more transactions.
This workflow is explained more in a previous section, but the high-level workflow is:
Stackers delegate their STX to a pool operator
The pool operator makes
delegate-stack-stx
transactions to “approve” specific stackers. This needs to be called for every individual stacker that delegates to them.The pool operator makes a
stack-aggregation-commit
transaction to “commit” all of its delegated STX up to this point.
Similar to solo stacking, these steps must be made before the prepare phase of an upcoming reward cycle.
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.
Once a signer is registered in the signer set
During the prepare phase before a reward cycle, Stacks nodes automatically determine the signer set for the upcoming cycle. When this occurs, the Stacks nodes make an “internal” transaction to update the .signers
contract with the list of signers.
The signer software is continuously polling the Stacks node to see if it is registered for a cycle. If the signer software finds that it is registered (by matching its public key to the signers stored in the signers
contract) it begins performing its duties as a signer.
During the prepare phase, the signers perform DKG through StackerDB messages. Once an aggregate public key is determined, the signer automatically makes a vote-for-aggregate-key
transaction. No out-of-band action is needed to be taken for this to occur.
During the instantiation phase (before fast blocks and full Nakamoto rules go live), the signer must pay a STX transaction fee for this transaction to be confirmed. Critically, this means that a minimum balance must be kept in the STX address associated with the signer’s key. There is a config field called tx_fee_ms
(transaction fee in micro-stacks) that can be optionally configured to set the fee for these transactions. If the config field is omitted, the fee defaults to 10,000 micro-stacks (0.01 STX).
During the Activation phase (after fast blocks and full Nakamoto rules have been activated), the signer doesn’t need to pay fees for this transaction, so no STX balance needs to be kept in that address.
Last updated