Shape the future of Stacks.

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…

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

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

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

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…

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.

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.

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…

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.

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…

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