Starknet v0.14.3 Goes Live with 1.5s Blocks and Dynamic Gas Fees
Starknet v0.14.3 Goes Live with 1.5s Blocks and Dynamic Gas Fees
⚡ Starknet cuts block times
Starknet has deployed version 0.14.3 to mainnet, introducing several technical improvements to the network.
Key updates include:
- Dynamic L2 gas base fee - An automatic algorithm (SNIP-35) adjusts minimum gas fees based on STRK token price, aiming to stabilize costs in real-world value rather than nominal token terms
- 1.5-second block times - Reduced from previous intervals to lower transaction latency
- Enhanced prover/verifier capabilities - New support for privacy-related transaction flows
- BLAKE-based SNOS hash - Part of the network's long-term security infrastructure
Developers working on fee estimation, sponsored transactions, paymasters, wallets, or account abstraction should review their implementations. The dynamic fee adjustment may require larger buffers during price volatility periods.
Full technical documentation and compatibility details are available through the governance proposal and community forums.
Resources: Governance Proposal: governance.starknet.io/#/sn:0x009feda… Pre-release notes, questions, and troubleshooting: community.starknet.io/t/starknet-0-1… More information on SNIP-35: community.starknet.io/t/snip-35-auto… More information on SNIP-40: community.starknet.io/t/snip-40-more…
Starknet v0.14.3 is live on Mainnet. This upgrade makes Starknet faster and more predictable: • Dynamic L2 gas base fee for more stable fees in real-world value • 1.5s block times for lower latency • Enhanced prover/verifier capabilities for privacy-related flows •
Starknet v0.14.3 is going live on Mainnet this Wednesday, the 8th of July. This upgrade improves fee predictability, lowers latency, adds proving support for new privacy flows, and includes breaking changes some projects must prepare for. Here’s what changes and how to be
Dynamic L2 gas base fee: SNIP-35 v0.14.3 introduces an automatic algorithm that adjusts the minimum L2 gas base fee according to the STRK price. This helps keep fees more predictable in real-world value, instead of only in nominal STRK terms. If you build fee estimation,
Starknet v0.14.3 is going live on Mainnet this Wednesday, the 8th of July. This upgrade improves fee predictability, lowers latency, adds proving support for new privacy flows, and includes breaking changes some projects must prepare for. Here’s what changes and how to be
🚨 RPC 0.8 Support Ends: Migration Required
**Breaking Change Alert** Starting with v0.14.3, RPC 0.8 is officially deprecated. Full nodes and SDKs will no longer release versions supporting it. **Action Required:** - Migrate to RPC 0.9 or RPC 0.10.1/0.10.2 immediately - Review your infrastructure if you rely on candidate transaction timing **Key Change:** Candidate transaction latency will now match preconfirmed transactions - no performance advantage. Apps depending on faster candidate transaction speeds need to reassess UX and infrastructure assumptions. This follows the earlier deprecation of RPC versions below 0.7, which was announced with Starknet v0.13.4. Developers should ensure they're using starknet-js v6.9.0 or later for compatibility.
🚨 Starknet Mainnet v0.14.3 Launch Checklist
Starknet v0.14.3 launches on Mainnet July 8th with critical updates requiring immediate action from builders. **Key upgrades include:** - Improved fee predictability - Lower latency - New privacy flow proving support - Breaking changes requiring preparation **Required actions before launch:** - **RPC users**: Migrate from 0.8 now - **Node operators**: Upgrade to v0.14.3 before launch - **Large transaction senders**: Review [SNIP-40 limits](https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-40.md) for transactions with thousands of reads/writes - **SNIP-36 users**: Upgrade provers alongside version update - **Hash-dependent projects**: Check Pedersen → BLAKE change impacts - **Timing-sensitive apps**: Review candidate transaction timing expectations This is a mandatory upgrade with breaking changes - projects must prepare to avoid disruption.
Starknet Core Contract Switches to Quantum-Resistant BLAKE Hash
**Starknet is upgrading its security infrastructure** by transitioning from Pedersen to the quantum-secure BLAKE hash function for program hash and config hash in its core contract. **Key changes:** - Program hash and config hash now use BLAKE instead of Pedersen - Enhanced quantum resistance for core contract security - SNOS (Starknet Operating System) verification affected **Action required:** Developers and infrastructure operators should verify compatibility if their systems depend on: - Program hash operations - Config hash operations - SNOS verification processes - Indexing services - Monitoring tools - Custom core-contract tooling This upgrade represents a proactive step toward quantum-safe blockchain infrastructure as the industry prepares for potential future quantum computing threats.
Starknet Adds Keccak Support for EVM-Compatible Private Transactions
Starknet's SNIP-36 verifier now supports Keccak built-in invocations in virtual OS blocks, enabling **virtual private transactions signed with EVM signatures**. **Key changes:** - New verifier functionality allows EVM-style signatures for private transactions - Requires prover service upgrade to v0.14.3 - **Breaking change**: Proofs from v0.14.2 are incompatible with the new verifier **Action required:** If you're using SNIP-36 proving, upgrade your prover services immediately alongside the v0.14.3 release to maintain compatibility.