> For the complete documentation index, see [llms.txt](https://docs.stacks.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stacks.co/learn/block-production/mining.md).

# How Are Blocks Mined?

<div data-with-frame="true"><figure><img src="https://2842511454-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH74xqoobupBWwBsVMJhK%2Fuploads%2FKP7TV3rUxRBugJITtEOy%2Fmining-section-cover.png?alt=media&#x26;token=a3891617-2b64-4742-9a0c-004c6a70f944" alt=""><figcaption></figcaption></figure></div>

{% hint style="info" %}
**Builder Resources**

* For running your own Stacks miner, [here](https://docs.stacks.co/operate/run-a-miner).
  {% endhint %}

#### The Big Picture

* PoX selects a randomized single-leader block miner once per BTC block
* PoX incentivizes miners to make STX blocks and earn STX rewards + tx fees
* Miners send *block commit* transactions on Bitcoin L1.
* Block commits include: (block hash, VRF seed) pair
* Deterministic but unpredictable winner at each Bitcoin block
* PoX disincentivizes BTC L1 miners from interfering via ATC-C

***

### Intro

In Stacks mining, miners spend Bitcoin to earn the right to produce new Stacks blocks. Rather than introducing an entirely separate consensus mechanism, Stacks adapts and extends Bitcoin's existing Proof of Work. Stacks relies on Bitcoin's security and economic weight to secure the layer built on top of it.

When miners commit BTC as part of the mining process, that Bitcoin is not burned or wasted. Under PoX-5, it is routed into the reward pool, bridged automatically to sBTC, and distributed through the yield waterfall to staking participants: Bitcoin-paired protocol bonds first, then STX-only stakers and the protocol reserve. This flow of Bitcoin from miners to stakers is the core innovation behind Proof of Transfer (PoX). The "transfer" of BTC is what anchors Stacks to Bitcoin's security while aligning incentives between miners and network participants.

### Mining Flow Breakdown

In the previous version of Stacks (before the Nakamoto Upgrade), Stacks miners would mine new Stacks blocks at a one-to-one cadence with Bitcoin blocks. After Nakamoto, this is no longer the case. Under Nakamoto rules, miners are instead selected for a tenure that corresponds to a Bitcoin block. During this tenure, miners build and propose multiple Stacks blocks (roughly every 10 seconds) and signers will approve and append them.

{% hint style="info" %}
[What was the Nakamoto Upgrade?](/learn/block-production/what-was-the-nakamoto-upgrade.md)
{% endhint %}

<div data-with-frame="true"><figure><img src="https://2842511454-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH74xqoobupBWwBsVMJhK%2Fuploads%2Fca0oJCagFYDaEU3vw1e4%2Fmining-flow.png?alt=media&#x26;token=1d65f252-c0b3-4614-8166-726a22de4f42" alt="The mining cycle from registration through commitment and election to block assembly"><figcaption><p>The mining cycle, end to end</p></figcaption></figure></div>

Miners run Stacks nodes with mining enabled to participate in the PoX mechanism. The node handles each phase:

1. **Registration**: miners register for a future election by sending consensus data to the network
2. **Commitment**: registered miners transfer Bitcoin to participate in the election. Committed BTC is routed into the PoX-5 reward pool, where it is bridged to sBTC and paid out to staking participants.
3. **Election**: a verifiable random function chooses one miner for a new tenure to write blocks on the Stacks blockchain
4. **Assembly**: the elected miner writes the new blocks by pulling transactions from the mempool and collects rewards in the form of new STX tokens

### Miner Selection Process

As opposed to a block race, as in PoW, Stacks utilizes a single-leader election process called a cryptographic sortition. That is facilitated through an embedded verifiable random function state in Bitcoin transactions. This in turn allows for deterministic but unpredictable winners at each Bitcoin block.

<details>

<summary>What is a cryptographic sortition?</summary>

A cryptographic sortition is a process of randomly selecting one or more entities from a set using cryptography. This is a decentralized and verifiable way to select participants for a variety of tasks, such as consensus protocols, lotteries, and auctions.

More specifically, miner sortition in the context of Stacks is the weighted cryptographic sortition process by which a miner candidate is selected as the next miner (leader).

</details>

Every Stacks miner must register a VRF public key in a Bitcoin transaction. Once they do that, they can then issue *block commit* transactions on Bitcoin. Block commit transactions on Bitcoin contain:

`(block hash, VRF seed) pair`

These block commit transactions not only contain a pointer to the block stream they intend to produce, but also include all the relevant info to re-seed the next VRF for the next sortition. Miners cannot tamper with the VRF seed. This is enforced by the property:

`VRF seed = hash(VRF proof)`

And that VRF proof can only be generated by the miner's VRF private key.

<details>

<summary>How do block commits relate to each other?</summary>

<div data-with-frame="true"><figure><img src="https://2842511454-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH74xqoobupBWwBsVMJhK%2Fuploads%2F9l4YJ1AOry3SSTL724wd%2Fmining-leader-election-flow.png?alt=media&#x26;token=6dcfaefd-1362-4d10-a530-b726584b91d8" alt="Successive block commits, each carrying a VRF seed that re-seeds the next sortition"><figcaption><p>How one block commit feeds the next</p></figcaption></figure></div>

</details>

{% hint style="info" %}
To be considered for a tenure, a miner must have a block commit included in a Bitcoin block. If a miner wishes to update their commitment after submission, they may use Bitcoin's Replace-By-Fee.
{% endhint %}

#### Probability to mine next block

The miner who is selected to mine the next block is chosen depending on the amount of BTC the miners transfer. The probability for a miner to mine the next block is determined using a variation of the Assumed Total Commitment with Carryforward (ATC-C) [MEV](https://github.com/stacksgov/sips/blob/main/sips/sip-021/MEV-Report.pdf) mitigation strategy to allocate block rewards to miners. The probability a miner will win the sortition and be granted the current tenure will be based on a function that accounts for the total block commit spend on the blocks leading up to the current sortition.

While there is no minimum BTC commitment enforced by the protocol, in practice there is a floor constrained by dust: if the fees for a transaction exceed the value of the spent output, it is considered dust. How dust is [calculated](https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L14) depends on a number of factors. We have found 5,500 satoshis to be a good lower bound per output. Under PoX-5 a block commit carries a single PoX output, so a commitment of at least 5,500 satoshis / block is recommended.

To calculate the amount of BTC to send, miners should:

* Guess the price BTC/STX for the next day (100 blocks later)
* Guess the total amount of bitcoin committed by all miners

{% hint style="info" %}
Signers are in charge of both validating and appending new blocks and conducting miner tenure changes.
{% endhint %}

#### Block Commit Transactions (on Bitcoin)

Under PoX-5, miners commit Bitcoin to **one** address in every leader block commit transaction: the sBTC bridge address that feeds the reward pool. The same output form applies to every block of the cycle, including the prepare phase. Nothing is sent to a burn address. This replaces the pre-PoX-5 model, in which each commit paid two addresses drawn from the reward set of stacking participants.

<div data-with-frame="true"><figure><img src="https://2842511454-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH74xqoobupBWwBsVMJhK%2Fuploads%2FmPgihwk4yyZWRwlcHQ9k%2Fminer-btc-flow.png?alt=media&#x26;token=a2046c69-1021-414b-a487-d8837a96c2f5" alt="The block commit paying one output from the miner address to the sBTC bridge address on Bitcoin, and the automated flow on Stacks from the pox-5 contract through signer-managers to stakers"><figcaption><p>Where a miner's committed BTC ends up</p></figcaption></figure></div>

<details>

<summary>What does a block commit transaction actually look like?</summary>

* Watch this [clip](https://youtube.com/shorts/HPRsn-aSYrg?si=Y7hA7_9BeHFxV0zz) describing what goes into a block commit transaction on Bitcoin.
* Check out a previous block commit transaction on Bitcoin [here](https://mempool.space/tx/42834cb7ec9ca3e2b51e2ff16bd809ae049c925ed8d3da099c9ce3d5292d2a91).

</details>

### Miner rewards

Miners receive Stacks blocks' coinbase rewards for tenures they win.

The reward is a flat **1,000 STX per tenure**. [SIP-045](https://github.com/stacksgov/sips/blob/main/sips/sip-045/sip-045-pox-5-bitcoin-staking.md) restored the coinbase to 1,000 STX at Epoch 4.0 activation and removed the reduction schedule established under SIP-029, so no further scheduled reductions exist.

#### Transaction fees

Miners also receive Stacks fees for transactions mined in any block they produce.

#### Reward maturity

Block rewards and transaction fees take 100 blocks on the Bitcoin blockchain to mature. After successfully mining a block your rewards appear in your Stacks account after \~24 hours.

### Stacks mining in practice

Stacks runs with a small number of miners. That is a consequence of how the incentives work rather than a gap in them.

Stacks miners function similarly to sequencers in L2 systems in that they are only responsible for constructing and proposing new blocks, not appending them to the chain. But unlike most Ethereum L2s that operate with just a single centralized sequencer, Stacks consistently has at least 4-5 miners with open membership allowing anyone to join.

Block production on Stacks separates the work: miners construct and propose blocks, while signers, backed by stakers' locked STX, validate and append them. This separation limits what a miner can do to the chain.

Miners cannot reorganize the chain. In the worst case they can omit some kinds of transactions, and running your own miner addresses that.

More miners on the network would mean fewer rewards for stakers, as miners would have to spend more of their funds on Bitcoin L1 fees rather than sending it into the reward pool.

<details>

<summary><strong>Wouldn't more miners mean more competition, meaning more rewards?</strong></summary>

The reason more miners means fewer rewards is because miners act economically rationally, and they don't have an unlimited amount of BTC to work with.

Miners are paying their PoX commitments plus their Bitcoin fees for a chance to win the coinbase (1,000 STX) plus fees for a tenure. If there are more miners, they will each pay less, because they will have a lower chance of winning. They can't pay ever-increasing amounts of BTC because at some point they will never be profitable, so there is a limit to how much BTC they can spend in order to try and win a tenure.

As they pay less, the Bitcoin fee becomes a more significant portion of their expenses, and that also decreases their odds of winning the tenure.

Here's a concrete example:

Let's say Stacks is trading at 1,000 Sats per STX.

The total spend from all miners, if everyone is acting logically and we ignore Stacks fees, would be less than 1,000,000 Sats (1,000 STX coinbase \* 1000 Sats/STX).

If that is from 5 miners, then it could be 10,000 Sats (2,000 Sats for each transaction) going to Bitcoin fees and 990,000 Sats going to PoX.

If there are 100 miners, then it would be 200,000 Sats going to Bitcoin fees, and 800,000 Sats going to PoX.

</details>

This creates a natural economic equilibrium where:

{% stepper %}
{% step %}
**Enough miners participate to ensure blocks are produced reliably**
{% endstep %}

{% step %}
**Stakers receive optimal rewards**
{% endstep %}

{% step %}
**The network maintains censorship resistance without unnecessary mining competition**
{% endstep %}
{% endstepper %}

This design is intentional. Stakers act as complementary security guarantors who receive Bitcoin-denominated rewards via PoX, so Stacks achieves security without requiring an excessive number of miners competing solely to win block production rights.

Unlike other chains where miners alone determine the canonical chain, Stacks' two-party system provides stronger guarantees:

* Miners cannot force invalid transactions or blocks (signers won't sign them, and even if they did, the nodes would not accept them)
* No miner can unilaterally reorg the chain (signers control chain finality)
* Accepting a block requires signatures carrying at least 70% of total signer weight, ensuring broad consensus before blocks are accepted

This separation of concerns between miners and signers is why a small number of miners is not a weakness.

<details>

<summary>What happened to microblocks?</summary>

Microblocks are a legacy feature of the previous version of Stacks that no longer exist. They were originally created as a way to improve transaction throughput, but without the functionality of Nakamoto, they never worked in practice.

Nakamoto instead uses a block production structure that creates Stacks blocks at a rapid cadence. See [What was the Nakamoto Upgrade?](/learn/block-production/what-was-the-nakamoto-upgrade.md).

</details>

### Bitcoin MEV Mitigation

Miner Extractable Value (MEV) has been a longstanding issue across many blockchains, including Stacks pre-Nakamoto.

MEV refers to the potential profit miners can extract from the manipulation of transaction inclusion and ordering within the blocks they produce, which can lead to unfair practices and diminished trust in the network.

In pre-Nakamoto releases of Stacks, Bitcoin miners with a significant percentage of Bitcoin's hashrate had the ability to censor commitment transactions of other Stacks miners, ensuring they were able to win the block rewards and fees of Stacks blocks where they were also the winner of the Bitcoin block as a Bitcoin miner.

The Nakamoto system uses a variation of the Assumed Total Commitment with Carryforward (ATC-C) [MEV](https://github.com/stacksgov/sips/blob/main/sips/sip-021/MEV-Report.pdf) mitigation strategy to allocate block rewards to miners. The probability a miner will win the block and be granted the current tenure will be based on a function that accounts for the total block commit spend on the blocks leading up to the current block.

<div data-with-frame="true"><figure><img src="https://2842511454-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH74xqoobupBWwBsVMJhK%2Fuploads%2FKR4LNqlqDmrC4hBmUwOB%2FATCC-formula.png?alt=media&#x26;token=ade7ed3f-2d1e-4124-8768-467069afca60" alt="The Assumed Total Commitment with Carryforward formula"><figcaption><p>The ATC-C formula</p></figcaption></figure></div>

The ATC solution leaves the option for a block to have no valid winner. The TenureChange-Extend transaction mitigates the majority of adverse effects caused by a missed block.

***

#### Additional Resources

* \[[Stacks YT](https://youtu.be/F31B-my510A?si=E0SRw0bbhuevB4kj)] The Stacks & Bitcoin Miners Relationship
* \[[Stacks YT](https://youtu.be/bhVyM5CYoh4?si=3bQl8Q_iJ_3z5jX-)] Long Term Security Budget & Miner Incentives for Bitcoin


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.stacks.co/learn/block-production/mining.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.