Overview

This upgrade enables Passkey support, secures DeFi via Originator Mode, and introduces Chain State Pruning to drastically reduce node storage requirements, among other performance features.

NOTE: A "Yes" vote on SIP-039 includes the approval of Riders SIP-040 and SIP-042.

1. SIP-039: Clarity 5 & Epoch 3.4 Activation

This serves as the core consensus trigger for the Epoch 3.4 upgrade and introduces Clarity 5, with critical refinements to the Clarity execution engine. Below are some of the most notable features - please see the full SIP for more information.

• Passkey Compatibility: Fixes cryptographic bugs to enable native WebAuthn support, allowing for seamless, password-less smart wallet onboarding.
• Increased DeFi Scale: Doubles the maximum "stack depth" (from 64 to 128), enabling the complex, multi-step contract calls required by modern Bitcoin DeFi.
• Execution Reliability: Introduces Rejectable Transactions and MARF compression to prevent "stuck" nonces and improve overall node storage efficiency.
• Read more on Github

2. [Rider] SIP-040: Improved Post Conditions

Introduces a new security layer for transactions to solve the "all-or-nothing" trade-off in current post-conditions:

• Originator Mode: Solves the “all-or-nothing” security trade off by enforcing strict protections on the signer’s assets while allowing the complex internal contract movements required for DeFi.
• NFT “May-Send” Support: Introduces a new post-condition for non-fungible tokens, allowing users to authorize the transfer of an NFT only if specific conditions are met during execution.
• The Impact: These changes make both DeFi and NFT transactions on Stacks more robust, reducing failed transactions and eliminating ambiguity in how assets move.
• Read more on Github

3. [Rider] SIP-042: Removal of at-block

Addresses long-term chain growth by deprecating the at-block function to enable Chain State Pruning:

• The Problem: Currently, every node must store ~1TB of historical data (and growing) because at-block allows contracts to read state from any point in history back to genesis.
• The Solution: Removing this function allows the network to move to a pruned model where nodes only need to store recent state.
• The Impact: Drastically lowers the hardware requirements and costs for running a node, ensuring the Stacks network remains decentralized and sustainable as it scales.
• Read more on Github

Summary of Impact

• For Users: Seamless Passkey login, safer DeFi via Originator Mode, and no more "stuck" transactions.
• For Operators: Drastically lower hardware costs and storage needs (1TB → GBs) via Chain State Pruning.
• For Developers: Double the power for complex apps (128 stack depth) and improved Clarity 5 efficiency.

Dust Voting

If you are using a custody provider or wallet other than Leather or Xverse, you can use the provided dust voting option. The voting platform will pre-fill your transaction for you in many cases, but instructions are also provided if you need or prefer to send a transaction manually. Yes and No addresses are provided, just send the smallest amount your wallet allows to the address aligned with your vote.

STX Voting Addresses (also available via vote options below):

YES: SP00000000001WPAWSDEDMQ0B9K76XTZ79N

NO: SP000000000006WVSDEDMQ0B9K76JZVAKY

Note: Xverse seems to require a minimum send of .02 STX, please keep this in mind if you’re voting via the dust method with their wallet.

BTC Voting Addresses:

YES: 11111111111mdWK2VXcrA1eceSntcp

NO: 111111111111ACW5wa4RwyepZ84byy

Note: Voters using the BTC method should expect additional time for their vote to appear in the results.

Ledger Voters: If you’re using a Ledger wallet to vote, please select the “Dust Send” option rather than the contract call method to ensure your vote is recorded correctly.