2024 saw the launch of Nakamoto (fast blocks, bitcoin finality) and sBTC on the Stacks network. Since its launch a few months ago, sBTC has quickly filled each of the caps instituted as part of its phased, secure rollout. Those minting sBTC include industry leaders like SNZ, Jump Crypto, UTXO, and more, and the asset has also been added to leading custody platforms, including BitGo and Hex Trust. Momentum remains strong: withdrawal features went live on April 30th, and the third deposit cap was filled within hours on May 22, 2025.

With Stacks TVL steadily growing (recently hitting an all-time high), core developers have been learning from the system operating in production, taking feedback from builders, liquidity providers, signers, users, and other stakeholders to inform the next phase of development. With the “design principles” for sBTC in mind, this preview outlines a series of upgrades and advancements for Stacks and sBTC diving deeper into sBTC and providing overviews and links to more information on Stacks Core related work.

Collectively, we’re dubbing these the ‘Satoshi Upgrades’ and they will ensure Stacks remains the leading Bitcoin L2 with sBTC becoming entrenched as the most secure programmable Bitcoin asset. Designs include paths to increased security, liquidity, TVL, and user growth, while enabling new use cases alongside ever-improving trust assumptions for the underlying BTC. These upgrades will be released iteratively as they are available, with many improvements rolling out as soon as Q3.

• Create a self-custodial on-ramp into sBTC
• Expand access for institutional capital
• Preserve or improve UX and DeFi composability
• Unlock new, exciting use cases

While sBTC already has a high trust, distributed signer network securing it, major BTC holders have indicated to us that there are tens of billions of dollars in BTC capital wanting to deploy in even more trust-minimized setups. We’ve identified two technical advancements that will allow sBTC to evolve to meet these objectives. We’ll cover these innovations at a high level, expand on how they meet the objectives, and then outline a possible implementation path.

• Self-custodial minting: A programmable Bitcoin asset would ideally require that any transaction that could move a Bitcoin holder's underlying BTC must be signed by them, thereby eliminating any custodial risk. As we’ll show later, using a combination of zero-knowledge proofs, HTLCs and the fact that Stacks nodes have access to Bitcoin state (and therefore can independently verify the existence of any given Bitcoin transaction), it is indeed possible to design this into sBTC. Extra care must be taken when transfers happen to other users or into a smart contract – when transferring to another Stacks user, the custody of the underlying BTC needs to be updated accordingly; while when deploying to a smart contract, ownership moves to a decentralized signer set by default. A new data structure, called the Redemption DAG, is used to manage and track all these state changes on the Stacks L2.
• Post-conditions on the underlying Bitcoin: When self-custodial sBTC is transferred into a smart contract the default is that the underlying BTC is held by the sBTC signer set. While this is adequate for many situations today, certain use-cases might desire more control over the underlying BTC and we can enable this. The high-level idea is that just like there are post-conditions for Stacks transactions, we can introduce post-conditions that govern the custody of the underlying Bitcoin. For instance, a lending application could specify (in their Clarity contract) that upon liquidation, the BTC will be released to a particular bitcoin address. This is only possible because Stacks has full access to Bitcoin state and is tightly integrated with the Bitcoin L1.

With these underlying capabilities, we can unlock a number of new use cases on the Stacks network.

• Self-custodial minting: The system we described earlier meets the needs of individuals, institutions or really anyone who needs or prefers a fully self-custodial minting option. In effect, your sBTC at rest is just as self-custodial as your Bitcoin at rest.
• Self-custodial payments: In addition, you can freely send and receive this self-custodial sBTC. In effect, this unlocks fully self-custodial payments – similar to Lightning, but without any of the liquidity or routing issues! And you benefit from the speed and security of Stacks – transactions confirm in seconds and inherit Bitcoin finality. You can send 10 cents in BTC or $100M in BTC, there are no liquidity or routing limitations, but sBTC remains self-custodial with unilateral exit.
• Expand access to institutional capital for DeFi: Lastly, self-custodial minting allows institutions to retain control of their underlying Bitcoin and also leverage custodians for minting from segregated addresses. Such self-custodial minting through qualified custodians has been a frequently asked feature by institutional users of sBTC.

But what if users want to deploy it into DeFi? While they may want the trustless minting, from in-depth discovery conversations with interested users, we’ve identified that large BTC holders are sophisticated and understand that the same asset in different contexts has different trust assumptions and properties. For instance, BTC in your exchange account vs. with a custody provider vs. deployed in DeFi vs. in your mobile wallet vs. in your hardware wallet all have different safety guarantees and trust assumptions.

Furthermore, with post-conditions we can give app developers and institutions alike more control. Builders could specify additional constraints on the custody of the underlying BTC for the sBTC in DeFi apps, giving institutions stronger guarantees as to the results by regulating if, when, and how the underlying assets will move.

Here’s one way to sequence these upgrades – the goal is to incrementally provide value and rapidly unlock utility at each step, rather than wait for one huge upgrade.

First, enable institutional minting in collaboration with trusted custody providers. This unlocks access to institutional capital and enables new capital inflows into DeFi.

Next, roll out self-custodial minting. This unlocks self-custodial, Lightning-style payments.
Finally, implement post-conditions for the underlying Bitcoin. This lowers the trust requirements when sBTC is deployed into smart contracts and gives applications/users more control for use-cases that need it.

One question that may arise is how this connects with the planned move to an open signer set for sBTC: while we still plan to use an open signer set as part of the future model for sBTC, we believe the advancements in this preview can offer larger leaps forward in trust assumptions in the same time frame as rolling out the open signer set would right now. As such, the open signer set remains on the roadmap, but the self-custodial sBTC minting will be the priority for implementation in the coming months.

Self-custodial minting will likely require a new asset because each transfer will require two signatures (one on Stacks and one on Bitcoin, signed and appended to the DAG). As always, user and builder experience is our first priority: we will jointly design the system with wallets and all other stakeholders to ensure that the user experience will not need to change to adopt the new assets.

When deploying the self-custodial sBTC into a smart contract, it will automatically be converted to the existing SIP-10 sBTC. This allows maintaining compatibility with wallets, DeFi apps and exchanges and ensuring a good user experience.

There are still design corner cases that core devs are working on, but we are really excited about this breakthrough. For instance, we could adopt Bitcoin addresses on Stacks so that self-custodial sBTC is held on these new addresses, while the moment it is transferred to a “legacy” Stacks address it becomes SIP-10. If an exchange doesn’t yet support the new Bitcoin addresses format self-custodial sBTC then the exchange can keep using SIP-10 sBTC. If an exchange upgrades their setup to start using Bitcoin addresses and self-custodial sBTC then the exchange can actually take custody of the underlying BTC on behalf of their users. Further technical specifications will be released over the coming months.

The last piece of technology is post-conditions. Today, when users deploy sBTC into a smart contract the ownership of the underlying BTC is with the signer set. The signers, in theory, can send that BTC anywhere. As the Satoshi Upgrades roll out, we can not only have self-custodial sBTC (where the underlying BTC remains in the control of the user/owner), but we can do better when sBTC is deployed into smart contracts as well. Developers of L2 apps can build specialized Bitcoin scripts that can hold the underlying BTC. These specialized scripts (like DLCs) can use L2 contracts as an oracle and have very narrowly defined conditions under which the BTC can move to another address.

For example, imagine an advanced decentralized lending pool allowing a user to collateralise sBTC for a USD representation. Such a sophisticated smart contract exposes a Bitcoin address through a Stacks Clarity trait that constrains where the underlying BTC can go on the L1. The execution on the L2 contract acts as an oracle for a narrowly defined script on the L1, and the user knows that instead of blindly trusting a signer set, the Bitcoin script holding the underlying BTC has only a few exit/post conditions, limiting the attack surface area.

Through post-conditions, sBTC users can significantly lower their trust assumptions. They will still need to trust the DeFi app they are deploying capital to, but not the sBTC signer set: a DeFi deployment will become as “self-custodial” as possible. The smart contract itself will govern where and how assets will move on the L1. In a way, L2 contracts work hand-in-hand with L1 scripts to achieve this. Again, this is only possible because of the tight integration of the Stacks L2 with Bitcoin and how all L2 contracts have full access to Bitcoin state.

It’s no secret that many of the best parts of sBTC are directly enabled by the unique aspects of Stacks’ design, especially Proof-of-Transfer, which provides a secure connection to Bitcoin. To ensure a system that is self-sustainable in the long term, we must also be evolving the Stacks token economics and value accrual mechanisms in a way that more use of sBTC (and activity on the network in general) directly makes Stacks more valuable and rewards the STX holders who run validators and signers.

Early explorations on a number of key Stacks Core upgrades that will not only serve sBTC, but boost support for general use cases like NFTs, DAOs, AI agents, and more are underway. This section will cover the basics of these explorations, but we invite you to browse the Stacks Roadmap and the linked deep dives for each item.

The number one desire from Bitcoin holders is to be able to earn a native Bitcoin yield on their holdings, and the Proof-of-Transfer design of the Stacks network provides a unique opportunity to offer a BTC yield with no need for lending or counterparty risk.

• Dual Stacking: Dual Stacking is a mechanism that would allow users to stake BTC, STX, or both to earn BTC-denominated rewards via the PoX mechanism. While BTC holders could earn a small base yield by holding just sBTC, by supplementing their BTC holdings with a proportion of STX holdings they would unlock greater BTC earnings. The Dual-Stacking model is designed to do three things: (1) Attract and retain Bitcoin capital through sustainable BTC yield , (2) Strengthen Stacks protocol security via Bitcoin economic security, (3) Create a sustainable value accrual mechanism for STX. The majority of yield will still go to the STX holders.
• Programmable BTC Vaults: Simple, Scalable Yield on Stacks: DeFi on all chains today is complex and requires frequent interactions from users, lowering adoption. Programmable BTC Vaults on Stacks are a simple, plug-and-play Bitcoin yield product that enable users to deposit BTC and earn yield through modular, composable strategies with just a few clicks. These vaults are designed to be fully extensible — offering “BTC in, yield out” simplicity for both retail and institutional users. Future versions may include the ability to borrow against BTC to access real-world yield opportunities, or other fixed-income products.
• ‘Pox5’: In the continual drive to improve user experience, there are several major improvements on the horizon for Stacking aimed at reducing the downtime when switching stacking methods, making operations simpler for pool operators, and increasing the percentage of rewards paid each cycle. This group of upgrades will come together as the fifth generation of the Proof-of-Transfer system (hence, Pox5). This upgrade doubles down on the most unique aspect of Stacks, ensuring that Bitcoin yield from the protocol remains a powerful primitive for Stacks DeFi that, in turn, drives the sustainability of the network.

Protocol Revenue: Simplifying UX and Aligning STX Value Capture Through Fee Abstraction

One of the UX barriers for Bitcoin holders using sBTC is the requirement to hold and use STX for transaction fees. For a Bitcoin-native audience, the need to acquire and manage a separate token just to move BTC is unintuitive and adds friction during the onboarding step. If we want to reach millions of Bitcoin users, we must meet them where they are — with an experience that feels native to BTC.

Fee abstraction offers a powerful solution. Under this model, users have the option to pay gas fees directly in sBTC. Behind the scenes, the protocol automatically converts those fees into STX, paying the actual transaction fee to the miners while capturing the additional fee as protocol revenue. This preserves the integrity of the Stacks economic model (STX remains the underlying gas token) while unlocking a smoother user experience. Developers gain the freedom to build wallets and apps that feel Bitcoin-native, while the underlying protocol mechanisms continue to drive demand for STX through every transaction. The sBTC fees can even be higher than the rate for direct STX fees, and the additional margin on sBTC fees can help protocol revenue.

Removing UX barriers will increase the transaction volume on Stacks and increase STX value accrual. This simplified onboarding flow will enable more seamless experiences in Stacks DeFi, helping teams acquire users and remove friction as they interact across the ecosystem.

Speed, block production, UX: The need for fast, consistent transaction confirmations is table stakes for any top ecosystem. To paraphrase from our friends in Solana, increasing throughput and reducing latency are evergreen goals and the long-term goal is for the Stacks layer to be the most performant Bitcoin L2. Related efforts, like Clarity Wasm go hand-in-hand with these efforts to enable a more secure, performant network.

Other growth & integrations: Stacks Core is also in line for a number of new integrations, including bridges, stablecoins, and wallets. These key connections at the core layer will offer easier access to Stacks DeFi and enable fast growth of upcoming features like Dual Stacking, covered above.

Together, the “Satoshi Upgrades” will iteratively establish the next generation of the Stacks network and further cement sBTC as a critical enabler of the Bitcoin economy. With self-custodial minting and transfers for sBTC, post-conditions on the underlying Bitcoin, Dual Staking, and more, we will unlock access to institutional capital for Bitcoin DeFi, payments, and other use cases, all with ever-improving safety guarantees. While plenty of R&D work remains, we are excited to share this overview and will continue to fill in design details for each upgrade as progress continues.