Stacks Core Deep Dive: 3 Proposed Protocol Improvements

Epoch 3.4 brings Passkey support, stronger DeFi security through Originator Mode, and Chain State Pruning to drastically reduce node storage requirements, along with several other performance improvements.

Three SIPs make up this upgrade. SIP-039 is the core proposal that activates Epoch 3.4 and introduces Clarity 5. SIP-040 and SIP-042 are riders to SIP-039, meaning a "Yes" vote on SIP-039 includes approval of both.

Voting is open now and runs through March 20. If approved, the release targets March 20 with network activation planned for March 31.

This post breaks down what each SIP changes and why it matters, whether you're a user, builder, or node operator.

SIP-039: Clarity 5 & Epoch 3.4 Activation

This is the core proposal. It triggers the Epoch 3.4 consensus upgrade and introduces Clarity 5, which includes critical refinements to the Clarity execution engine. Here are some of the most notable features (see the full SIP for the complete list).

Passkey Compatibility

SIP-039 fixes cryptographic bugs that currently block native WebAuthn support. This enables seamless, password-less smart wallet onboarding through Passkeys, the same authentication standard already used by Apple, Google, and most major platforms. For users, this means signing into Stacks applications can be as simple as a fingerprint or face scan, with no seed phrases or passwords required.

Increased DeFi Scale

The maximum call stack depth doubles from 64 to 128. This matters because modern Bitcoin DeFi protocols often involve complex, multi-step contract calls that chain together (think multi-hop swaps, nested lending operations, or liquidation flows). The current limit of 64 has been a real constraint. Doubling it gives builders significantly more room to design sophisticated DeFi applications on Stacks.

Execution Reliability

Two changes here. First, Rejectable Transactions prevent "stuck" nonces, a frustrating issue where a failed transaction can block all subsequent transactions from the same account until the nonce clears. Second, MARF compression improvements reduce the storage footprint for node operators, contributing to overall infrastructure efficiency.

Read SIP-039 on GitHub

SIP-040: Improved Post Conditions (Rider)

Post conditions are one of Stacks' most distinctive security features. They let a transaction declare exactly which assets can move and under what constraints, and unlike protections embedded inside smart contracts on other chains, post conditions are enforced at the protocol level. If a transaction violates the limits a user specified, the chain rejects it. Users can override contract behavior, not just trust it.

The problem is that today's post conditions are all-or-nothing. You either enforce strict constraints on every asset movement in the transaction, or you don't use them at all. That creates friction for DeFi, where a user's assets need to be protected but the contract also needs to perform complex internal token movements (like routing through liquidity pools) to execute the trade.

SIP-040 introduces two key changes to solve this.

Originator Mode

Originator Mode resolves the all-or-nothing trade-off by enforcing strict protections on the signer's own assets while still allowing the complex internal contract movements that DeFi requires. A user swapping tokens through a DEX, for example, gets strong guarantees about what leaves and enters their wallet without blocking the contract from routing through intermediate pools.

NFT "May-Send" Support

A new post-condition type for non-fungible tokens. Users can authorize the transfer of a specific NFT only if certain conditions are met during execution. This brings NFT transactions closer to the same level of granular safety that fungible token transactions already have.

Together, these changes make both DeFi and NFT transactions on Stacks more robust, reducing failed transactions and eliminating ambiguity in how assets move.

Read SIP-040 on GitHub

SIP-042: Removal of at-block (Rider)

This proposal addresses long-term chain growth by deprecating the at-block function to enable Chain State Pruning.

The Problem

Clarity's at-block function lets contracts evaluate read-only expressions against historical chain state. You pass it a block hash, and it executes logic as if the chain were at that point in time. Because at-block can reference any block back to genesis, every node must store the full historical MARF (Merklized Adaptive Radix Forest) indefinitely. On mainnet, that's approaching ~1 TB and growing, with the majority dedicated to historical MARF data. Post-Nakamoto, that growth has accelerated.

The Solution

SIP-042 removes at-block entirely. Without it, the network can move to a pruned model where nodes only need to store recent state. Most historical use cases can be replaced with explicit checkpoints, accumulators, or bounded history patterns that localize storage costs to the contracts that actually need historical data.

The Impact

This drastically lowers the hardware requirements and costs for running a node (from ~1 TB down to GBs over time), helping ensure the Stacks network remains decentralized and sustainable as it scales.

Developer Notice

This is an epoch-level consensus change. All contracts, regardless of Clarity version, will be subject to this change once activated. If your contracts rely on at-block, review the SIP now and begin migrating to checkpoint- or accumulator-based designs before activation.

Read SIP-042 on GitHub

What This Means

For users: Seamless Passkey login, safer DeFi transactions through Originator Mode, and no more stuck transactions from nonce issues.

For node operators: Drastically lower hardware costs and storage needs (1 TB down to GBs) through Chain State Pruning.

For developers: Doubled stack depth for complex DeFi, new NFT post-condition support, and improved execution reliability. Contracts using at-block will need to migrate before activation.

Vote and Get Involved

Governance voting is open now through March 20. A "Yes" vote on SIP-039 includes approval of riders SIP-040 and SIP-042.

If approved, the release targets March 20 with network activation planned for March 31. As with all consensus changes, activation depends on community approval.

Review the proposals, join the forum discussions, and cast your vote.

‍