This release improves stacks-core performance by adding two database indexes which significantly reduce disk reads.
Depending on your hardware, index creation takes between 2-15 minutes per index (there are two).

We strongly recommend all signer operators to manually create indexes before applying this upgrade to avoid any downtime.

Apply the indexes as follows:
Note:

• The following commands require running from your config working_dir directory. ex: cd /stacks where working_dir = "/stacks"
• You may need to install the sqlite binary. On Debian based systems: sudo apt-get install sqlite3

$ echo "CREATE INDEX IF NOT EXISTS naka_block_headers_by_burn_hash ON nakamoto_block_headers(burn_header_hash);" | sqlite3 ./mainnet/chainstate/vm/index.sqlite

$ echo "CREATE INDEX IF NOT EXISTS naka_block_headers_by_burn_ht ON nakamoto_block_headers(burn_header_height);" | sqlite3 ./mainnet/chainstate/vm/index.sqlite

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-signer compatible with this release is 3.3.0.0.1.0, available at: https://github.com/stacks-network/stacks-core/releases/tag/signer-3.3.0.0.1.0.

Added

• Add indexes to nakamoto_block_headers to fix a performance regression. Node may take a few minutes to restart during the upgrade while the new indexes are created.

This release improves stacks-core performance by adding two database indexes which significantly reduce disk reads.
Depending on your hardware, index creation takes between 2-15 minutes per index (there are two).

We strongly recommend all signer operators to manually create indexes before applying this upgrade to avoid any downtime.

Apply the indexes as follows:
Note:

• The following commands require running from your config working_dir directory. ex: cd /stacks where working_dir = "/stacks"
• You may need to install the sqlite binary. On Debian based systems: sudo apt-get install sqlite3

$ echo "CREATE INDEX IF NOT EXISTS naka_block_headers_by_burn_hash ON nakamoto_block_headers(burn_header_hash);" | sqlite3 ./mainnet/chainstate/vm/index.sqlite

$ echo "CREATE INDEX IF NOT EXISTS naka_block_headers_by_burn_ht ON nakamoto_block_headers(burn_header_height);" | sqlite3 ./mainnet/chainstate/vm/index.sqlite

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-node compatible with this release is 3.3.0.0.1, available at: https://github.com/stacks-network/stacks-core/releases/tag/3.3.0.0.1.

This release implements the 3.3 Stacks consensus rules which activates at Bitcoin block 923,222. For more details see SIP-033.

This is a required upgrade

• Activation is estimated for November 11th, 2025 around 1600 UTC, or Bitcoin block 923,222.
• Upgrading after Bitcoin block 923,222 will require a genesis sync.

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-signer compatible with this release is 3.3.0.0.0.0, available at: https://github.com/stacks-network/stacks-core/releases/tag/signer-3.3.0.0.0.0.

Added

• Added support for new Clarity 4 builtin, secp256r1-verify? (not activated until epoch 3.3)
• New block_proposal_validation_timeout_secs configuration option in the connection options section, allowing to set the maximum duration a node will spend validating a proposed block.
• Activation height selected and set for epoch 3.3 at Bitcoin block 923,222

Changed

• Renamed Clarity 4's new block-time to stacks-block-time
• Improve cost-tracking for type-checking function arguments in epoch 3.3 (see #6425)
• Replaced libsecp256k1 with k256 and p256 from RustCrypto and removed separate Wasm implementations.
• Added limits in the type-checker for the number of parameters in functions (maximum 256), and the number of methods in traits (maximum 256). These limits are enforced starting in Epoch 3.3.

This release implements the 3.3 Stacks consensus rules which activates at Bitcoin block 923,222. For more details see SIP-033.

This is a required upgrade

• Activation is estimated for November 11th, 2025 around 1600 UTC, or Bitcoin block 923,222.
• Upgrading after Bitcoin block 923,222 will require a genesis sync.

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-node compatible with this release is 3.3.0.0.0, available at: https://github.com/stacks-network/stacks-core/releases/tag/3.3.0.0.0.

This release resolves a critical vulnerability and all node operators are strongly encouraged to upgrade

This release contains several bugfixes and improvements in the stacks-node and stacks-signer binaries, ensuring more consistent block production.

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-signer compatible with this release is 3.2.0.0.2.0, available at: https://github.com/stacks-network/stacks-core/releases/tag/signer-3.2.0.0.2.0.

Note: blockstack-cli binary has been renamed to stacks-cli from this release forward.

Added

• Renamed clarity-serialization to clarity-types.
• Add stackerdb_timeout_secs to miner config for limiting duration of StackerDB HTTP requests.
• When determining a global transaction replay set, the state evaluator now uses a longest-common-prefix algorithm to find a replay set in the case where a single replay set has less than 70% of signer weight.
• New endpoints /v3/tenures/blocks/, /v3/tenures/blocks/hash, /v3/tenures/blocks/height allowing retrieving the list of stacks blocks from a burn block
• New authenticated endpoint /v3/block/replay to replay the execution of any Nakamoto block in the chain (useful for validation, simulation, getting events...)
• Creates epoch 3.3 and costs-4 in preparation for a hardfork to activate Clarity 4
• Adds support for new Clarity 4 builtins (not activated until epoch 3.3):
  • contract-hash?
  • current-contract
  • block-time
  • to-ascii?
• Added contract_cost_limit_percentage to the miner config file — sets the percentage of a block’s execution cost at which, if a large non-boot contract call would cause a BlockTooBigError, the miner will stop adding further non-boot contract calls and only include STX transfers and boot contract calls for the remainder of the block.

Changed

• Clarity errors pertaining to syntax binding errors have been made more
  expressive (#6337)
• Removed affirmation maps logic throughout, upgrading chainstate DB schema to 11 and burnchain DB schema to 3 (#6314)

Fixed

• When running stacks-inspect decode-tx, print the correct version of the address (mainnet or testnet) based on the transaction passed in
• When a contract deploy is analyzed, it will no longer throw a CostError when the contract contains an undefined top-level variable. Instead, it will throw a UndefinedVariable error.

This release resolves a critical vulnerability and all node operators are strongly encouraged to upgrade

This release contains several bugfixes and improvements in the stacks-node and stacks-signer binaries, ensuring more consistent block production.

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-node compatible with this release is 3.2.0.0.2, available at: https://github.com/stacks-network/stacks-core/releases/tag/3.2.0.0.2.

Added

• Added two-phase commit to signer block responses ensuring signers only issue a signature in a BlockResponse when a majority threshold number have pre-committed to sign a proposed Naka block
• When determining a global transaction replay set, the state evaluator now uses a longest-common-prefix algorithm to find a replay set in the case where a single replay set has less than 70% of signer weight.

Changed

• Database schema updated to version 17

This hotfix release adds a new configuration option stackerdb_timeout_secs, which sets the maximum time the stacks-signer binary will wait for requests to complete (default is 120s).

This release resolves an issue where the stacks-signer binary would wait indefinitely for StackerDB HTTP requests if the remote peer does not close the connection.

The version of stacks-node compatible with this release is 3.2.0.0.1, available at: https://github.com/stacks-network/stacks-core/releases/tag/3.2.0.0.1.

Added

• Introduced stackerdb_timeout_secs: config option to set the maximum time (in seconds) the signer will wait for StackerDB HTTP requests to complete.

This release contains several bugfixes and improvements in the stacks-node and stacks-signer binaries, ensuring more consistent block production.

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-signer compatible with this release is 3.2.0.0.1.0, available at: https://github.com/stacks-network/stacks-core/releases/tag/signer-3.2.0.0.1.0.

This is a highly recommended upgrade for signers

Added

• Adds node-config-docsgen to automatically create config documentation (#6227)

Fixed

• Fixed a typo in the metrics_identifier route from /v2/stackedb/:principal/:contract_name/replicas to /v2/stackerdb/:principal/:contract_name/replicas. Note: This may be a breaking change for systems relying on the incorrect route. Please update any metrics tools accordingly.

This release contains several bugfixes and improvements in the stacks-node and stacks-signer binaries, ensuring more consistent block production.

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-node compatible with this release is 3.2.0.0.1, available at: https://github.com/stacks-network/stacks-core/releases/tag/3.2.0.0.1.

This is a highly recommended upgrade for signers

Changed

• Repurposes the capitulate_miner_view timeout to prevent needlessly checking for capitulation when blocks are globally accepted (#6307)
• Consider the local state machine update regardless of local vs global paths (#6325)
• Use the local supported version by default if no consensus is found (#6341)

This release implements the 3.2 Stacks consensus rules which activates at Bitcoin block 907,740. For more details see SIP-031.

This is a required upgrade

• Activation is estimated for July 29th, 2025 around 1800 UTC, or Bitcoin block 907,740.
• Upgrading after Bitcoin block 907,740 will require a genesis sync.

This release is compatible with chainstate directories from 3.x.x.x.x.

The version of stacks-signer compatible with this release is 3.2.0.0.0.0, available at: https://github.com/stacks-network/stacks-core/releases/tag/signer-3.2.0.0.0.0.

Added

• Added the clarity-serialization crate: A lightweight crate for serializing and deserializing Clarity values. This crate decouples core data types from the Clarity VM, making it easier to build off-chain tooling, and other applications that interact with Clarity data. It includes support for wasm32-unknown-unknown targets via the wasm-web and wasm-deterministic features.
• Added /v3/contracts/fast-call-read/:principal/:contract_name/:func_name api endpoint. It allows to run read-only calls faster by disabling the cost and memory trackers. This endpoint requires authentication.
• SIP-031 consensus rules, activating in epoch 3.2 at block 907_740

Changed

• The HTTP Date header in responses now strictly follows RFC7231.
• When a previous block commit is unable to be RBFed, the miner will now just wait for it to be confirmed instead of submitting a new block commit which breaks the miner's UTXO chain.
• When mining, only log new block proposal responses, not duplicates.

Fixed

• Fixed tenure downloader logic on reward cycle boundaries (#6234).
• Do not send events to event observers for stale StackerDB chunks.