Stacks Improvement Proposals.

This SIP details Version 4 of the Clarity smart contract language, which introduces new operations to provide mechanisms for building more secure smart contracts on Stacks.

This SIP details a rider to SIP-033, including a new variant of the tenure change control transaction. This variant allows the tenure change to specify which dimension of the block budget to reset.

This SIP proposes the adoption of Bitcoin address formats (P2PKH and P2WPKH) as the standard user-facing address format for Stacks network transactions, including those involving sBTC. Currently, Stacks transactions use a unique address format distinct from that of Bitcoin. Aligning with Bitcoin's established address formats aims to reduce user friction, improve the user experience for Bitcoin users interacting with sBTC and the Stacks layer, and enhance the perception of sBTC as a Layer 2 Bitcoin solution. This change is intended to be implemented at the developer tool, library, and applicati…

This proposal introduces a standard primitive for secure coordination among multiple independent agents on the Stacks blockchain. It defines an intent message format and protocol by which an initiator posts a desired action (the intent) and other participants submit cryptographic acceptances. The intent becomes executable once all required participants have provided acceptance attestations before a specified expiry. This standard specifies the data structures, canonical status codes, Clarity contract interface, and rules needed to implement this coordination framework on Stacks. It leverages o…

This SIP proposes a minimal, composable trait interface for “Encrypted NFTs” (eNFTs): NFTs that commit on-chain to a private off-chain payload (“private metadata”) while keeping the payload itself off-chain. The standard defines: 1) A public commitment interface, 2) An optional owner-gated envelope descriptor for wallet user experience. 3) Indexer-friendly event conventions. This enables interoperable private-metadata NFT patterns across contracts, wallets, marketplaces, and indexers without requiring consensus changes.

This version of Clarity is being proposed solely to address and resolve documented issues with existing functionality, specifically those that require a hard-fork to change. The implementation for this SIP should only resolve problems in the current Clarity implementation or make beneficial changes to under-specified aspects of the Clarity language and virtual machine (VM).

This proposal improves on the current transaction post-conditions by introducing a third post-condition mode, Originator mode, and a new condition code for non-fungible tokens, MAY SEND. Allow mode provides high flexibility, but it does not provide protection for callers, so it should not be used outside of development. Deny mode provides maximum security, but for complex applications, it can be difficult, or impossible to enumerate all of the asset movement that a transaction may cause. Originator mode offers a hybrid approach. It applies Deny logic strictly to the origin account's assets, wh…

This SIP defines a standard set of traits for AI agent registries on the Stacks blockchain. It establishes three core registries: an Identity Registry implementing the SIP-009 NFT trait for agent registration and ownership, a Reputation Registry supporting signed value scoring with WAD normalization and three authorization paths (permissionless, on-chain approval, SIP-018 signed), and a Validation Registry enabling progressive third-party verification responses. The Identity Registry includes an agent wallet system via reserved metadata keys, enabling agents to control their own wallets separa…

This SIP proposes the removal of the at-block built-in function in Clarity, effective from Epoch 3.4. Following activation of this SIP, new contracts that reference at-block will fail during static analysis, and existing contracts that invoke it will fail at runtime. This removes the only mechanism that requires nodes to retain the full historical MARF, enabling future chainstate pruning1.

This SIP specifies a deterministic way to derive a visual identifier (an "identicon") for any Clarity smart contract deployed to the Stacks blockchain. The identicon is a pure function of the contract's source code after canonicalization: two deployments of the same source — on any address, at any height, on any network — render the same icon. Wallets, explorers, and apps that implement the specification allow users to recognize known code at a glance and to notice when contracts that share a name or author address do not share code. The specification pins three things: the canonical form of t…

This SIP defines the consensus changes that activate with Stacks Epoch 4.0. First, it introduces Clarity 6, which extends the concat function to accept more than two arguments, adds new cryptographic built-in functions, adds built-ins for trustlessly verifying Bitcoin transaction outputs on-chain, and adds new Clarity allowances for the PoX-5 staking model. In addition to the Clarity changes, this SIP introduces a mechanism for handling problematic transactions in blocks, and the deprecation of the long-unused cost-voting contract. These changes are motivated by real-world developer experience…

Stacks exists to activate the Bitcoin economy: to bring Bitcoin into productive use while preserving the security properties that define it. Bitcoin Staking is a proposed upgrade to Stacks Proof-of-Transfer (PoX) that enables participants to lock BTC on Bitcoin and STX on Stacks and earn BTC-denominated yield without giving up custody. This SIP and the companion Bitcoin Staking white paper specify the consensus changes required for Bitcoin Staking and include an alignment of the STX emissions schedule. - View full PDF in app: Bitcoin Staking SIP PDF Viewer - Source proposal text: PoX-5 draft -…

This SIP describes the sanctioned procedures for recovering the state of the Stacks blockchain in the event of a _catastrophic_ failure. A failure qualifies as a _catastrophic_ failure if and only if there is no conceivable way for the correct nodes in the network to make progress and preserve safety without human intervention. This document describes how to identify a catastrophic failure, and how the various parties in the Stacks ecosystem should work together to resuscitate the blockchain. Importantly, these procedures seek to minimize the degree of human intervention and code change whenev…

Decentralized application often require the authentication of their users. This SIP specifies a protocol between the application and an authenticator that results in the exchange of a public key controlled by the user and a private key specific for the application for the user.