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