🔧 Starknet Speeds Up: Block Times Drop to 1.​5s

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.

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