> 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/reference/epoch-4-0-consensus-changes.md). # Epoch 4.0 Consensus Changes The consensus and language changes that activated at the Epoch 4.0 hard fork, for integrators and node operators. Epoch 4.0 activated on mainnet at Bitcoin block 960,230, on 30 July 2026. It replaced PoX-4 with PoX-5 and shipped Clarity 6 alongside a set of consensus changes. A node running anything older than `4.0.1` diverges from consensus after that block. This page covers the consensus and language changes. For what the fork did to stacked STX, see [What's Changed in PoX-5](https://docs.stacks.co/operate/staking-stx/whats-changed-in-pox-5). For upgrading a signer, see the [PoX-5 Upgrade Guide](https://docs.stacks.co/operate/run-a-signer/pox-5-upgrade-guide). | SIP | Scope | | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | SIP-045, PoX-5: Bitcoin Staking and Emission Schedule Alignment | PoX-5 replacing PoX-4, the yield waterfall, the emission change, removal of the miner BTC burn | | SIP-044, Clarity 6, staking and PoX post-conditions, and removal of the cost-voting contract | Clarity 6, the new post-condition types, the block header version scheme, cost-voting | SIP-044 describes itself as a rider on SIP-045. Both are ratified and both votes concluded before activation. SIP-045's vote closed at Bitcoin block 958,925 with 181,488,504 STX voting across 87 unique wallets; SIP-044 reports 161,443,320 STX across 77 voters. Each passed with all but 2 STX in favor. Each SIP reports its own total, and they are not the same number. ## Miner BTC no longer reaches a burn address Under PoX-4, miner BTC that matched no eligible reward address was sent to a Bitcoin burn address, and prepare-phase commitments went there by default. PoX-5 removes both cases. Every block-commit now pays a single output into the reward pool, which auto-bridges to sBTC and funds the waterfall. No miner BTC is destroyed. The block-commit transaction shape and how to verify it are on [Verify Miner](https://docs.stacks.co/operate/run-a-miner/verify-miner). ## The emission schedule SIP-029 lowered the coinbase block reward from 1,000 STX to 500 STX per Bitcoin block. That reduction took effect in April 2026 and was in force for roughly three months. SIP-045 restored the reward to 1,000 STX at Epoch 4.0 and removed the remaining SIP-029 reductions. The 1,000 STX rate is provisional for the PoX-5 bootstrap phase. SIP-045 commits the PoX-6 SIP to an explicit reassessment. SIP-031 emissions are a separate stream and are unaffected. ## Cost-voting is disabled, not removed The `cost-voting` contract is still deployed and still callable, and votes can still be cast. From Epoch 4.0 they have no effect on consensus: the node stops reading confirmed proposals and every cost function uses the boot defaults. From Epoch 4.0 the cost functions are implemented in Rust only. There is no `costs-5.clar` and no `SP000000000000000000002Q6VF78.costs-5` contract, unlike `costs-2`, `costs-3` and `costs-4`. Anything that resolved cost functions by reading an on-chain contract needs a different source after the fork. ## Block header version and problematic transactions The Nakamoto block header carries a single-byte version field. The high bit, `0x80`, is the shadow-block flag. The header version is the low seven bits, `version & 0x7f`. | Version | Applies to | | ------- | -------------------------------- | | 0 | Nakamoto epochs before Epoch 4.0 | | 1 | Epoch 4.0 and later | A block is invalid if `version & 0x7f` does not equal the version expected for its epoch. Version 1 headers serialize and hash a list of problematic-transaction markers. Read the version with the mask. A pre-4.0 shadow block has a version byte of `0x80`, which is version 0 with the flag set, and comparing the raw byte to `0` will reject it. ## Clarity 6 Clarity 6 activated with the fork. The full function reference is generated from the node source and lives at [Functions](/reference/clarity/functions.md). Four native functions are new. `ed25519-verify` and `secp256k1-decompress?` are general cryptography. `get-bitcoin-tx-output?` parses a serialized Bitcoin transaction and returns one output plus the canonical txid, and `verify-merkle-proof` checks a Bitcoin-style merkle inclusion proof. The two together replace the pattern of calling an external `clarity-bitcoin` contract, and they are what PoX-5 uses to verify Bitcoin payments. `concat` is not new. It has existed since Clarity 1, and Clarity 6 makes it variadic: it now takes two or more sequences in one call, at a runtime cost proportional to the combined input length rather than the quadratic cost of chaining binary calls. The `with-stacking` allowance used by `restrict-assets?` and `as-contract?` is replaced by two allowances in Clarity 6. `with-stacking` remains valid in Clarity 4 and 5 contracts. | Allowance | Governs, in pox-5 | | -------------- | ------------------------------------------------------------------------------- | | `with-staking` | `stake`, `register-for-bond`, `stake-update` | | `with-pox` | `unstake`, `unstake-sbtc`, `update-bond-registration`, `announce-l1-early-exit` | Two post-condition types are new. `Staking` constrains how much STX a principal may lock, and reuses the fungible condition codes. `PoX` constrains whether a principal may perform a position-altering PoX operation, and has its own condition codes. See [Post-conditions](https://docs.stacks.co/post-conditions/overview) for how to write them. ## For integrators: the PoX-4 unlock has no transaction and no event STX locked under PoX-4 became spendable at the activation height. There is no unlock transaction and no unlock event to watch for. The node carries a v4 unlock height and materialises the unlock the first time an account is touched, the same way the v2 and v3 unlocks worked. Anything that detects unlocks by watching for an event will see nothing. Read the account's locked balance instead. Calls to `.pox-4` other than read-only ones fail from Epoch 4.0 onward. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stacks.co/reference/epoch-4-0-consensus-changes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.