Shape the future of Stacks.

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 -…

X402 introduces a standardized framework for blockchain-native agent payments, enabling autonomous software agents to transact, coordinate, and compensate one another without relying on traditional financial rails. By embedding payment logic directly into agent interactions, X402 defines a permissionless, programmable payment layer where identity, execution, and settlement are unified on-chain. This proposal outlines how X402 can serve as a foundational primitive for agent economies—supporting microtransactions, streaming payments, and conditional execution across decentralized networks. The r…

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…

A Proof of Transfer system integrating NFTs as dynamic rewards, aligning incentives, securing networks, and enhancing user participation through verifiable ownership.

This SIP proposes the integration of zero-authority infrastructure into a unified coordination layer enabling decentralized communities to operate without intermediaries. Powered by ConsoleDAO assets, the system introduces agent-driven workflows for events, gigs, bounties, and quests, with transparent onchain reputation and value distribution. By extending existing traction from the Stacks ecosystem into broader networks, the proposal establishes a scalable, permissionless framework for human and AI collaboration. CollectiveOS serves as the interface layer, providing seamless tools for governa…

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 proposes a framework for implementing a standardized reputation system on apps or websites. Reputation transactions will result in the minting of Non-Fungible Tokens (NFTs) to provide a verifiable and immutable record of reputation events. The proposal outlines standard attributes for reputation systems, the structure for XML and JSON representation, and the NFT minting process.

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 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 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 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 details Version 4 of the Clarity smart contract language, which introduces new operations to provide mechanisms for building more secure smart contracts on Stacks.

Stacks' goal as an ecosystem is to empower the creation of the Bitcoin economy - we envision that all projects that want to build on Bitcoin, from DeFi to gaming, memecoins to NFTs, and marketplaces to identity, should be built on top of Stacks. Stacks is transitioning from a tech-first to a traction-first phase, fueled by a new endowment and streamlined operations. The proposal raises fresh capital to put Stacks on par with other top projects, addressing historic underfunding and unlocking the ability to compete at scale. A new operational entity will scale execution, while a community-govern…

This SIP proposes a change to the stacking process so that Stackers can change their stacking settings without the so-called cooldown cycle. Furthermore, the relationship between Stackers and signers is strengthened and stacking overall is simplified. The specification defines that - solo Stackers and delegating Stackers have to follow the same flow and use the same contract functions: All users delegate block voting power to signers. - Stackers can change their stacking settings for the next cycle before the prepare phase, including the chosen signer (switch pools). - locked Stacks tokens are…

Proposes allowing Stacks transactions (notably sBTC) to use native Bitcoin address formats (e.g. bc1…) instead of Stacks SP… addresses. The goal is to reduce UX friction for Bitcoin users by aligning address formats with what they already recognize, while preserving existing Stacks address semantics under the hood. This is primarily a tooling and ecosystem standard rather than a consensus-breaking change.

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 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).

Proposes a standard trait extension to SIP-009 NFTs that supports encrypted or private metadata layers via on-chain commitments. The trait defines common methods and events so wallets, marketplaces, and indexers can recognize and interact with NFTs that include encrypted payloads, without requiring consensus changes. The aim is interoperability and consistent UX across encrypted NFT implementations.

Adapts the ERC-8004 agent registry standard from Ethereum to Stacks, enabling on-chain registries for agents, identities, or autonomous actors. The proposal defines discoverable and interoperable registry patterns that applications can rely on when interacting with agents. This SIP focuses on ecosystem standards for identity and agent coordination rather than core protocol changes.

This SIP defines a minimalist trait interface for liquidity pools on the Stacks blockchain. The standard enables independent implementation of liquidity pools while maintaining a unified interface, facilitating the development of swap aggregators and multi-hop transactions across multiple pools. The standard introduces an extensible opcode buffer system that enables advanced pool operations while maintaining a simple core interface.

This SIP corrects the behavior of the Clarity keyword burn-block-height inside of an at-block statement.

The first Stacks halving is expected to take place 210,384 Bitcoin blocks after the Stacks 2.0 starting height, 666,050, which is Bitcoin height 876,434, which is set to occur during Reward Cycle 100 in December 2024, cutting the STX block reward from 1,000 STX to 500 STX. This SIP proposes a modification to the emissions schedule given that the network is going through two major launches (Nakamoto and sBTC) which rely on predictable economic incentives. The proposed schedule modification and associated STX emission rate would create time for Nakamoto and sBTC to launch and settle in, but, bei…

Stacks Pay defines a URL-based payment-request format for the Stacks blockchain. By standardising how payment information is encoded, decoded, and displayed, it guarantees that any wallet or application implementing this specification can interoperate with any other. Stacks Pay is purely an application-layer standard: it introduces no changes to consensus, token emission, or on-chain data structures. Think of it as a shareable wrapper around an ordinary Stacks transaction. > RFC 2119 terminology > The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, > SHOULD, SHOULD NOT, RECOMMENDED, MAY,…

This SIP proposes a new wrapped Bitcoin asset, called sBTC, which would be implemented on Stacks as a SIP-010 token. sBTC enables seamless and secure integration of Bitcoin into the Stacks ecosystem, unlocking decentralized applications and expanding Bitcoin's utility through smart contracts. Stacks today offers a smart contract runtime for Stacks-hosted assets, and the forthcoming Stacks 3.0 release provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on threshold signatures, users would be able to lock their real BTC on t…

SIP-021 defines a threshold signature scheme called Weighted Schnorr Threshold Signatures (WSTS), a Schnorr signature scheme based on FROST whereby a set of mutually-distrustful parties produce a single Schnorr signature from shares of a private key. No party knows the private key; a signature can only be produced if a threshold of parties agree to produce a signature. WSTS is used in SIP-021 to provide a means for Stackers to collectively append blocks to the Stacks blockchain in a way that achieves Bitcoin finality for Stacks. Because a block can only be attached if a large fraction of the s…

Dynamic Dispatch is a pattern that developers can utilize in their smart contracts to enable routing of contract calls at runtime. This routing directs the calls to contracts deployed on the Stacks blockchain subsequent to the initial deployment of the smart contract. This is in contrast to Static Dispatch, where contract IDs are hard-coded into the contract. In the Clarity 1 and Clarity 2 implementations, the contract-call? function can be only be use with a contract ID coming from the list of arguments signed by the transaction author. This SIP reevaluates the existing approach and proposes…

This SIP proposes common RPC methods to use for the Stacks blockchain's "Connect" and "Auth" systems. The goal is to replace the current Connect interface, primarily used by web applications to connect with browser extensions and mobile apps with a more straightforward protocol. This proposal's goal is to standardize JSON compatible interfaces for use with wallet interfaces.

This document describes a consensus-breaking change to the Stacks blockchain that would enable faster and more reliable Stacks blocks. In this proposal, Stacks block production would no longer be tied to miner elections. Instead, miners produce blocks at a fixed cadence, and the set of PoX Stackers rely on the miner elections to determine when the current miner should stop producing blocks and a new miner should start. This blockchain will only fork if 70% of Stackers approve the fork, and chain reorganization will be as difficult as reorganizing Bitcoin. This proposal, dubbed the "Nakamoto" r…

This SIP proposes the creation of a trust-minimized 2-way peg in which BTC (the tokens of the current Stacks burnchain) can be manifested on Stacks as a SIP-010-compliant fungible token, called sBTC, and later redeemed for the same number of BTC. This proposal redefines the act of Stacking to be the act of maintaining an _sBTC wallet_, which is used to hold BTC and process sBTC redemptions. Stackers are collectively responsible for ensuring that all liquid sBTC are backed by an equal number of BTC, and that redemptions are processed in a timely manner. As a reward, they continue to receive PoX…

This Stacks Improvement Proposal (SIP) aims to address the issue of commingled collateral positions on the Stacks blockchain's Clarity-based DeFi applications. Currently, due to Clarity's design, it is challenging for users to identify their specific collateral positions within the Stacks Explorer. This SIP proposes the creation of a common interface for contracts that hold SIP-010 assets. Implementing this interface will enable users to view their collateral positions distinctly, improving the overall user experience of Stacks DeFi applications.

This SIP proposes a new multisig transaction format which is intended to be easier to use than the current format described in SIP-005. It does not remove support for the current format, rather it is intended to co-exist with the old format and give users a choice of which format to use. The issue with the current format is that it establishes a signer order when funds are sent to multisig account address, and requires signers to sign in the same order to spend the funds. In practice, the current format has proven difficult to understand and implement, as evidenced by the lack of Stacks multis…

One of the main use cases of Bitcoin Ordinal Inscriptions is the decentralized and censorship-resistant storage of arbitrary data in the Bitcoin blockchain, a feature which is most commonly used by artists and token creators to store artwork or metadata. Given that the Stacks network has a very close relationship to Bitcoin, Stacks developers are looking for a standardized way to reference the contents of inscriptions to use within their smart contracts or applications. This SIP defines a simple URI format that Stacks developers can use to make such a reference so that content can be used in a…

On 8 May 2023, a critical Denial-of-Service vulnerability manifested in the Stacks network. While the initial DoS threat was remedied through a non-consensus breaking hotfix, the underlying bug that triggered the vulnerability requires consensus changes to fix. This underlying bug has existed in the Stacks blockchain implementation since the launch of Stacks 2.0, and has the potential to impact the functionality of contracts even if they do not currently rely on the buggy behavior. This SIP proposes a consensus-breaking change to be included in the SIP-022 hardfork (Epoch 2.4) to remediate thi…

On 1 May 2023, it was discovered that smart contracts deployed prior to Stacks 2.1 that exposed public methods with trait arguments could not be invoked with previously working trait-implementing contract arguments. This bug was caused by the activation of Stacks Epoch 2.2 (https://github.com/stacksgov/sips/blob/main/sips/sip-022/sip-022-emergency-pox-fix.md). This SIP proposes an immediate consensus-breaking change to introduce a new Stacks epoch 2.3 that corrects this regression. This SIP proposes a Bitcoin activation height of 788,240

On 19 April 2023, it was discovered that there was a bug in the PoX smart contract which would allow a user to claim that they have stacked far, far more STX than they had locked. Exploiting this bug both allows the user to increase their PoX reward slot allotment, while also driving up the stacking minimum. Furthermore, it creates the conditions for a network-wide crash: if the total amount of STX stacked as reported by the PoX smart contract were to ever exceed the total amount of liquid STX, then the node would crash into an irrecoverable state. This bug has already been triggered in the wi…

This standard provides additional functions to digital assets (i.e. tokens) so that they can be made availble to buy from the owners public address. This in effect enables an open, decentralized marketplace for digital assets.

This standard aims to formalize a the commonly used traits to offer fungible or non-fungible tokens for sale, at a certain price in STX, from a non-custodial wallet.

This SIP adds bitwise operations to the Clarity language which could simplify the implementation of smart contracts that require manipulation of bits. The changes include the addition of the following operations: - Bitwise Xor (bit-xor) - Bitwise And (bit-and) - Bitwise Or (bit-or) - Bitwise Not (bit-not) - Binary Left Shift (bit-shift-left) - Binary Right Shift (bit-shift-right)

Web applications often provide their services only to authenticated users. In Web2, this was done through username and password or federated logins. In Web3, users can prove their digital identity by cryptographically signing that the user ownes the private key associated with that digital identity. SIP-018 defines the structure of signatures in general. This SIP defines the message format that web applications and similar off-chain services should use for their users to sign.

As the use of tokens (fungible and non-fungible) has grown in popularity, Stacks developers have found novel ways to define and use metadata to describe them. This rich data is commonly cached and indexed for future use in applications such as marketplaces, statistics aggregators, and developer tools like the Stacks Blockchain API. Occasionally, however, this metadata needs to change for a number of reasons: artwork reveals, media storage migrations, branding updates, etc. As of today, these changes do not have a standardized way of being propagated through the network for indexers to refresh…

This document evaluates the consequences of turning the tokens being burnt for minting Stacks into a source of funding for its base chain.

This SIP proposes appchains as a scaling solution for the Stacks blockchain. Instead of sharing a single blockchain, different applications can instantiate their own Stacks network, called an _appchain_, which is mined via a smart contract deployed on an existing Stacks network (which can be either the Stacks blockchain, or another appchain). Each appchain has its own native token, its own set of miners (who mine the appchain's token), and most importantly, its own block capacity. Appchain networks are organized hierarchically: the Stacks blockchain is the root of the hierarchy, and each appch…

The Signed Structured Data specification describes a standard way to deterministically encode and sign Structured Data. Structured Data is data that can be represented in human-readable format and used in applications and smart contracts. The aim of the standard is to produce signatures that are straightforward and inexpensive to verify by smart contracts.

This SIP proposes a set of updates to three major areas of the Stacks blockchain: Stacking, the Proof-of-Transfer (PoX) consensus algorithm as implemented in the Stacks chain and originally proposed in SIP-007. The proposed changes improve the user and developer experience of participating in Stacking, and add support for new behaviors and PoX reward address types. Clarity, the smart contract language supported on the Stacks blockchain. The proposed changes fix bugs and add new native functions and global variables that improve its support for interacting with off-chain services and blockchain…

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.

Non-fungible tokens - NFTs for short - are digital assets registered on blockchain with unique identifiers and properties that distinguish them from each other. SIP-009 defines the trait for how ownership of an NFT is managed. Fungible tokens - FTs for short - are digital assets where each token can be replaced by another token (see SIP-010). Semi-fungible tokens are digital assets where each token has a unique identifier and is dividable into fungible parts (see SIP-013). This SIP aims to provide a flexible standard to attach metadata to NFTs, like descriptions or urls to digital files. The s…

The Stacks 2.0 blockchain artificially constrains block goodput in two consensus-critical ways: it assesses storage costs for lists based on their maximum length instead of actual length, and it constrains the number of indexed I/O operations well below what the reference implementation is capable of handling. Changing either of these is breaking change, which requires a network-wide upgrade. This SIP proposes executing a breaking change to not only address these two constraints, but also to update all Clarity cost functions to more accurately reflect their true performance. The breaking chang…

Semi-Fungible Tokens, or SFTs, are digital assets that sit between fungible and non-fungible tokens. Fungible tokens are directly interchangeable, can be received, sent, and divided. Non-fungible tokens each have a unique identifier that distinguishes them from each other. Semi-fungible tokens have both an identifier and an amount. This SIP describes the SFT trait and provides a reference implementation.

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…

Fungible tokens are digital assets that can be sent, received, combined, and divided. Most forms of cryptocurrencies are fungible tokens. They have become a building block of almost all blockchains. This SIP aims to provide a flexible and easy-to-implement standard that can be used by developers on the Stacks blockchain when creating their own tokens.

A Stacks Improvement Proposal (SIP) is a design document that provides information to the greater Stacks ecosystem's participants concerning the design of the Stacks blockchain and its ongoing operation. Each SIP shall provide a clear and concise description of features, processes, and/or standards for the Stacks blockchain and its operators to adopt, with sufficient details provided such that a reasonable practitioner may use the document to create an independent but compatible implementation of the proposed improvement. SIPs are the canonical medium by which new features are proposed and des…

A Stacks Improvement Proposal (SIP) is a design document that provides information to the greater Stacks ecosystem's participants concerning the design of the Stacks blockchain and its ongoing operation. Each SIP shall provide a clear and concise description of features, processes, and/or standards for the Stacks blockchain and its operators to adopt, with sufficient details provided such that a reasonable practitioner may use the document to create an independent but compatible implementation of the proposed improvement. SIPs are the canonical medium by which new features are proposed and des…

This document describes the measured costs and asymptotic costs assessed for parsing Clarity code into an abstract syntax tree (AST) and the static analysis of that Clarity code (type-checking and read-only enforcement). This will not specify the _constants_ associated with those asymptotic cost functions. Those constants will necessarily be measured via benchmark harnesses and regression analyses.

This SIP proposes a new consensus algorithm, called Stacking, that uses the proof-of-work cryptocurrency of an established blockchain to secure a new blockchain. An economic benefit of the Stacking consensus algorithm is that the holders of the new cryptocurrency can earn a reward in a base cryptocurrency by actively participating in the consensus algorithm. This SIP proposes to change the mining mechanism of the Stacks blockchain. SIP-001 introduced proof-of-burn (PoB) where a base cryptocurrency is destroyed to participate in mining of a new cryptocurrency. This proposal argues that a new mi…

This document describes the measured costs and asymptotic costs assessed for the execution of Clarity code. This will not specify the _constants_ associated with those asymptotic cost functions. Those constants will necessarily be measured via benchmark harnesses and regression analyses. Furthermore, the _analysis_ cost associated with this code will not be covered by this proposal. The asymptotic cost functions for Clarity functions are modifiable via an on-chain voting mechanism. This enables new native functions to be added to the language over time. This document also describes the memory…

This SIP describes the structure, validation, and lifecycle for transactions and blocks in the Stacks blockchain, and describes how each peer maintains a materialized view of the effects of processing all state-transitions encoded in the blockchain's sequence of transactions. It presents the account model for the Stacks blockchain, and describes how accounts authorize and pay for processing transactions on the network.

Blockchain peers are replicated state machines, and as such, must maintain a materialized view of all of the state the transaction log represents in order to validate a subsequent transaction. The Stacks blockchain in particular not only maintains a materialized view of the state of every fork, but also requires miners to cryptographically commit to that view whenever they mine a block. This document describes a Merklized Adaptive Radix Forest (MARF), an authenticated index data structure for efficiently encoding a cryptographic commitment to blockchain state. The MARF's structure is part of t…

This SIP describes the design of the Stacks peer network, used for relaying blocks, transactions, and routing information. The document describes both the overall protocol design and rationale, and provides descriptions of each message's wire format (where applicable).

This proposal describes a mechanism for single-leader election using _proof-of-burn_ (PoB). Proof of burn is a mechanism for bootstrapping a new blockchain on top of an existing blockchain by rendering the tokens unspendable (i.e. "burning" them). Proof of burn is concerned with deciding which Stacks block miner (called _leader_ in this text) is elected for producing the next block, as well as deciding how to resolve conflicting transaction histories. The protocol assigns a score to each leader based on the fraction of tokens it burned, which is used to (1) probabilistically select the next le…

In order to support applications which require validation of some pieces of their logic, we present a smart contracting language for use with the Stacks blockchain. This smart contracting language can be used on the Stacks blockchain to support programatic control over digital assets within the Stacks blockchain (e.g., BNS names, Stacks tokens, etc.) While application-chains may use any smart-contract language that they like, this smart contracting language's VM will be a part of blockstack-core, and, as such, any blockstack-core node will be able to validate application chains using this smar…

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 extends the SIP-010 standard trait for fungible tokens on the Stacks blockchain to support composable fungible tokens with allowances. It adds further requirements to the previous standard, which is the bare minimum to have a standard for a fungible token, featuring mainly token tranfers. There are no specifications how to make transfers via third-party services. For atomic and composable transfers we introduce allowances. The new trait includes functions for transferring tokens (transfer limited to the contract-caller sender), approving allowances (approve and revoke), checking…