Stacks Roadmap and Product Vision Update

Community
#27

Curious, for the three main block production factors you noted in your response what are the best metrics to monitor for each one? Also, is there a publicly available dashboard you use to monitor those metrics?

I don’t think we have these yet.

Also, separate topic, but curious where signature schema fits into the roadmap conversation? (i.e. SIP-025 ). In your opinion, is iterating closer towards the original SIP-021 schema (WSTS, I believe) a high / med / low priority?

I’d put WSTS as low priority at the moment, since the current signer implementation is fine for the current needs. When we want to integrate sBTC signers into the consensus mechanism, then we’ll need WSTS, but until we’re ready for that, I think this is a low priority task.

2 Likes
#28

Looking from a PMF perspective.

Watch Bob’s newly launched Odin Fun platform video to see how fast and smooth the UI/UX is, which has been a massive success.

:star: Let’s imagine this as the end goal:
*The best UI/UX for any Bitcoin Layer 2, whether it’s for Stacks assets or L1 assets.

Transactions are settled and confirmed at lightning speed. (In the video, the user completed 50 runes purchases/transactions in just 10 seconds.)

:repeat: Now, let’s work backwards from this endgame:

*What types of Stacks technological infrastructure (Blockchain, APIs, Wallet Integration, etc.) are needed to make this possible?

Thinking in this way may help us map out a roadmap for the required steps to achieve this goal.

(Note: I’m not a big blocker either, reason attracted me to Stacks is ability to run on low requirement same ethos as Bitcoin. So I am hoping the solutions to achieve this endgame UI/UX can be implemented without relying solely on centralized databases and servers.)

Problem Statement:
*Current UI/UX in the Stacks ecosystem lacks the speed and smoothness needed for seamless transactions, with delays in settlement and confirmation, hindering user experience.

Solution Statement:
*Create the fastest UI/UX for Bitcoin L2 (Stacks and L1 assets), enabling near-instant transaction settlements. Success will be measured by transaction speed, user satisfaction, and increased transaction volume.

Expected Impact:
*Improved user experience through lightning-fast transaction processing
*Enhanced users adoption due to smooth and responsive UI/UX
*Increased transaction volume and usage within the Stacks ecosystem

How Success Will Be Measured:
*Speed of transaction settlement and confirmation
*User satisfaction and engagement with the UI/UX
*Increased number of successful transactions per user within a short period (e.g., 50 purchases in 10 seconds)

2 Likes
#29

The recent work with tenure-extends have drastically reduced the latency for all kinds of transactions’ confirmations. You can see evidence of this here: Stacks Hub

3 Likes
#30

Agree. Had to write something for “problem statement” so. :laughing:
My experience with Stacks transactions over the past month been very joyful and smooth in ~less than 5 seconds.

Let me reframe the problem statement to reflex more accurately.

Problem Statement
Stacks has a strong UI/UX foundation with the Nakamoto upgrade, but there’s an opportunity to further enhance transaction speed and responsiveness for a near-instant experience, ensuring competitiveness in the Bitcoin L2 market. Since most users prioritize fast, seamless interactions, refining the end-to-end flow could help drive greater adoption.

2 Likes
#31

Solana and Ethereum are centralized platforms with massive marketing budgets due to insider pre-mints. Stacks should not try to win their game by centralizing itself. In the longer run, SOL and ETH are just testnets for Bitcoin network applications. Why would China ever use SOL or ETH for anything if they can’t control it or, at the least, have no one control it. Lightning Network has no marketing budget and yet attracts many of the best minds in bitcoin. It (not they) just won over support from Tether and El Salvador. Decentralization, security, speed and alignment with bitcoin “values” seem to be key. It’s a neutral platform that scales institutionally and globally. How can Stacks be the smart contract platform for bitcoin in as close a way as Lightning seems to evolving as the neutral and uncensorable platform for payments. More decentralization of mining, stacking and signing.
Specialized Stacks subnets will attract institutions wanting SOL speed and capacity, but anchored in bitcoin security. Those might get regulated and controlled, but Stacks itself should always be seen as free from coercion and control, just like Bitcoin.
SOL and ETH can be selectively banned and key personnel can be detained. Why trust any network to that? Ask Russia. Stacks is the best chance as a platform for smart contract freedom technology. That should be it’s critical advantage over other L2 bitcoin solutions and especially over alt chains.

4 Likes
#32

“Find out what you’re good at and double down” - Scott Galloway.

Stacks wins by playing to its strengths—not by trying to be everything, but by doubling down on what makes it unique and valuable.

:rocket: Marketing & Narrative

  • Stacks = Bitcoin’s Smart Contract Layer—this message needs to be crystal clear and everywhere.
  • We win by owning the Bitcoin economy narrative, making it obvious that Stacks is the best place to build on Bitcoin—secure, scalable, and decentralized.
  • sBTC needs to be positioned as the dominant Bitcoin-backed asset, the go-to for DeFi, payments, and beyond.

:chart_with_upwards_trend: Sales & Adoption

  • Focus on high-value integrations—getting sBTC into major DeFi protocols, exchanges, and wallets. Every integration is an adoption multiplier.
  • Make it frictionless for builders—if we want devs to come, we need better tooling, smoother onboarding, and incentives that drive real usage.
  • Attract big players—funds, institutions, and power users need to see Stacks as a place where real Bitcoin liquidity lives.

:key: Strategy & Execution

  • Lean into Bitcoin’s strengths—security, liquidity, and trust. sBTC and Nakamoto bring finality and security—sell that hard.
  • Interoperability is key—Bitcoin is becoming multi-layered, and Stacks should be the most connected, whether that’s to Lightning, Ordinals, Runes, or other Bitcoin layers.
  • No distractions, no fluff—we should be obsessed with real-world traction, not just speculative hype.

:hammer_and_wrench: Products & Ecosystem

  • sBTC Utility First—drive use cases in DeFi, payments, and integrations.
  • Fast, scalable, and easy to build on—Stacks should be the best developer experience for Bitcoin smart contracts.
  • Community-driven innovation—giving builders and contributors a clear path to ship and scale their projects.

:zap: Regaining Our First-Mover Advantage

Stacks was here first, but being first isn’t enough—we need to move faster and execute harder than the competition. Other Bitcoin L2s are catching up, but they lack Nakamoto, they lack sBTC, and they lack a thriving builder community.

  • sBTC needs to dominate—it should be the Bitcoin-backed asset across all of crypto.
  • First-mover means nothing if we don’t out-ship, out-integrate, and out-innovate—we already have the foundation, now it’s about momentum and network effects.
  • Bitcoin DeFi is up for grabs—Stacks has the best shot at winning it, but we need execution, urgency, and focus.

:point_right: The bottom line: We win by being the default Bitcoin layer for smart contracts, assets, and innovation. The race for Bitcoin L2 dominance is on—let’s take back the lead.

3 Likes
#33

Looking at this thread I feel like commenting on all that has been said. But I also want to keep it brief.

I think it is important to keep Stacks decentralized, it should remain easy for anyone to run a node but I do believe that we should actively thrive to look for the optimums reliable and fast yet with limits to remain decentralized and open. Or we lose the value we have been working for. When tenures are ~15 MB and they renew every 2 minutes or even every 30 sec there is a lot of capacity to work with.
We will need our occasional congestion event to really know and test the limits of the network. Can we start planning those as a community and have a bi-yearly Stacks-congestion-day, everybody chips in?

I would love to see progress in Stacks mining pools to make it easier and economical for more people to participate in mining activities on Stacks. WSTW support for signers may be a low priority target when it comes to support for signers but I think it is important for trust minimized stacks mining pools.

Problem statement: BNSv2

Not everyone in the ecosystem has adopted BNSv2 yet, due to some uncertainties about subdomains and incompatible zonefiles.
BNSv2 should be standardized with a stacks improvement proposal (SIP) it should include details for subdomains, and profile schema (I have seen request for RPC standard and this eric’s proposal Proposal for Enhancing BNS Zonefile Configuration).

Solution statement:

Writing the standard for BNSv2 to iron out the details that, so far, have been deliberately left to be decided on later. Success will be measured by the ease with which new apps integrate with BNSv2. We will see those BNSv2 names when you’re connected on a dapp with any account that holds a name. Centralized exchanges adopt BNS(v2) names for transfers.

Problem statement:
Running your own stacks node (with hiro API) should be easy and reliable (a personal node doesn’t necessarily have to be as fast but any Stacks users should have the ability to check the chain state for themselves if they want to, just like a bitcoiner can with bitcoin L1).
Running your own stacks node for personal use can be a stepping stone for more sophisticated uses of a node such as running a public node, a signer, a subnet, chain analysis tools and more.

5 Likes
#34

Increasing the hardware requirement will be against the ethos of the mother chain Stacks is extending the capabilities and making it more centralized imo.

Second thing: Solana’s speed-like means you are completely trading off the mempool to be just available privately to Signers (validators). Just one of the trade-offs, I mean. I would never trade mempool for anything in blockchain

#35

You completely get Stacks

#36

+1 @Werner1

#37

We think the biggest opportunity to:

  1. Rapidly expand the sBTC supply into Stacks
  2. Gain free, organic marketing
  3. Which both, in turn, will be a positive driver for STX demand

… is to focus on Restaking as a feature. The data does not lie:

/defillama.com/chain/Bitcoin?groupBy=cumulative

Bitcoin TVL has gone from <$1B to >$6B since just October 2024 and almost the entire rise is attributable to Restaking. Not only have BTC owners rushed towards this opportunity it seems like partners have lined up for it as well. What’s amazing is that right now the yield is only being paid in “points” and the strong demand is still there.

Stacks has a unique advantage in that it could hypothetically pay a yield in sBTC or STX (which we know pays yield in BTC). We know Muneeb has mentioned this in his Korea AMA and that it’s on the product roadmap, but we think this should be priority 1, 2 and 3.

Thanks!

1 Like
#38

Hi,
It’s nice to see the development of sBTC.
I think we need to have a stablecoin which can be withdrawn from CEXes. This stablecoin (either USDT or USDC, or both) will bring more liquidity and be easier for taking profit.
Cheers,

#39

+1 werner all.

Not sure where the threshold would be re nodes.
Maybe as an idea, if we could agree on setup cost USD$ amount (and maintenance cost) and work backwards to find rough technical spec?

on the topic of BNS registration fee burned now as well, if this burned STX be put to better use would be nice.

& that if the price of $STX is at $3.5 or $9, would registration STX fee amount be possible to adjust dynamically maybe periodically? Or maybe set up a table and say by X $STX price, it would auto adjust to X amount of STX.

Or that burned fee could be directly used towards “common goods/function” such as an idea: a “sponsor transactions fees pool” for sBTC pegging in/out usage for the network which we all neutrally need. But I understand this topic about BNS cannot often find common ground quickly. So not super super urgent I guess.

(will not open a can of worm here so I’ll stop. Just ideas!)

#40

The stablecoin backed by real assets support should be a primary focus. A bridged solutions from other chains is one option, however that would be just an unofficial bridged version of the token prone to manipulation/vulnerabilities based on the third party bridge. I’ve seen the cautiousness in other ecosystems with these solutions.

A proper solution would be to bring an official e.g. USDC from Circle, they support even L2s so there could be way. They do have an official standard for bridging USDC (an official bridged solution is definitely better than a third party one… and additionally it’s one step closer to bringing usdc natively to Stacks), but that’s only for EVM chains, so maybe a compatibility with EVM chains would help this endeavour?

#41

I think 5-10 seconds is a reasonable UX for most apps.

The most important thing is to keep fees low while ensuring the capacity to process a high volume of transactions.

What absolutely cannot happen is a miner stopping block production for a while—that was the worst issue I’ve seen since Nakamoto’s release.

For specific apps that require faster transactions, there are solutions available. I’ve just created a protocol for instant sBTC transactions, and the same principle can be applied to any app. (If you wanna see how it works)

Another point worth exploring is how Stacks can replace the Lightning Network while offering a better UX. Opening channels introduces significant friction, which Stacks can eliminate using this protocol.

Additionally, having an official bridge for USDC and USDT is crucial for credibility.

#42

I completely agree with this. The read operation limit is an outdated bottleneck that unnecessarily slows down smart contracts, even though reading data is much lighter on resources than writing. Removing or significantly increasing the read limit would immediately improve Stacks’ transaction speed and app performance without requiring a hard fork, expensive hardware upgrades, or sacrificing decentralization.

The benefits of this approach are clear. Smart contracts would execute faster, especially under heavy network usage. It would prevent unnecessary slowdowns as more dApps and users join the network. It’s also one of the easiest, high-impact fixes that could improve scalability without major protocol changes.

If Stacks wants to surpass Ethereum while maintaining Bitcoin finality, optimizing the read system should be a priority.

#43

I think I’ve answered this in another comment, but I don’t mind sharing it again here.

Stacks’ TPS limitations can be improved immediately by implementing off-chain virtual balances, batch settlements, optimized smart contract read/writes, and payment channels to reduce on-chain congestion while maximizing tenure efficiency. Instead of processing each transaction on-chain, users can preload balances, transact off-chain, and settle net balances periodically, significantly increasing effective TPS without requiring a hard fork or expensive node upgrades. Developers can also batch multiple transactions into a single on-chain operation to reduce network load while maintaining decentralization. These optimizations work within the current Stacks framework and, when combined with the upcoming Clarity WASM upgrade, will further enhance transaction throughput without increasing hardware costs.

I’m actively working on a large-scale project
myself and have been implementing these strategies to ensure smooth, efficient transactions while maintaining Bitcoin security. These optimizations have been key to overcoming Stacks’ current limitations, and I believe they can benefit other projects looking to scale effectively.

#44

I think Stacks should balance speed and decentralization by improving Layer 1 performance without making it too expensive for people to participate. Gradually increasing hardware requirements while optimizing Layer 2 scaling could make Stacks both fast and secure. This way, it stays competitive with high-speed chains like Solana while keeping Bitcoin’s security and decentralization.

#45

I think Stacks’ TPS limitations can be mitigated immediately by implementing off-chain virtual balances, batch settlements, optimized smart contract read/writes, and payment channels to reduce on-chain congestion and maximize tenure efficiency. Instead of processing individual transactions on-chain, users can preload balances, transact off-chain, and only settle net balances periodically, significantly increasing effective TPS without requiring a hard fork or expensive node upgrades. Developers can also batch multiple transactions into single on-chain operations, reducing network load while maintaining decentralization. These optimizations work within the current Stacks framework, and when combined with the upcoming Clarity WASM upgrade, will further enhance transaction throughput without increasing hardware costs.

#46

One conversation that’s been gaining traction in the Bitcoin world is “Quantum Resistance”.

Taproot addresses expose public keys before spending, increasing vulnerability to quantum attacks compared to legacy addresses, which reveal public keys only when funds are spent.

Resources:
1 - GitHub Bitcoin core PR – BIP-360: BIP-360: QuBit - Pay to Quantum Resistant Hash by cryptoquick · Pull Request #1670 · bitcoin/bips · GitHub
2 - Most recent podcast with BIP author Hunter Beast (with timestamps – as of April 10, 2025): https://x.com/isabelfoxenduke/status/1909607168481149257

Hunter Beast frames it as a “low probability but high impact” scenario.

That got me wondering:
-Would this have a meaningful impact on Stacks? Should we start discussing it now and consider putting it on the medium-term roadmap?
-Or would any quantum-resistant improvements at the Bitcoin base layer naturally extend/inherit to us, meaning there’s nothing we need to proactively do?

1 Like