Shape the future of 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…

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…

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…

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

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

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…

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…

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.

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…

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…