Starknet 0.14.3 pre-release notes

🆙 Versions Upgrade
1

Starknet v0.14.3 Prerelease Notes

Testnet – 22 Jun 2026

Mainnet – 06 Jul 2026

Dynamic L2gas base fee

Starknet v0.14.3 introduces an automatic algorithm to adjust minimum base fee according to SNIP-35.

More frequent (and on average, smaller) blocks

Following SNIP-40, this version reduces block times to reduce Starknet’s latency. Adjacent changes include reducing the target L2gas of a block by 30% (the maximum block size remains unchanged), as well as increase of read and write L2gas amounts to compensate for this change.

Keccak support for client-side proving.

Starting v0.14.3, the SNIP-36 verifier within the Starknet gateways will support virtual OS blocks that contain invocations of the keccak builtin. The goal: Supporting virtual private transactions signed with EVM signatures.

Quantum-resistant SNOS hash

Starting v0.14.3, the hash that is used to calculate the “program hash” and “config hash” in the Starknet core contract will be the quantum secure Blake hash function instead of the Pedersen hash function used so far.

v0.14.3 Breaking Changes

RPC 0.8 deprecation

RPC version 0.8, introduced on May 2025, is no longer supported starting 0.14.3. Fullnodes and SDKs won’t release new versions that support it. Applications should migrate to RPC version 0.9 or 0.10.1 (recommended)

Candidate status - soft deprecation

Version 0.14.3 makes several efficiency improvements to the communication between the feeder gateway and the fullnodes. As part of these changes, the feeder gateway will not return transactions that are executed to fullnodes, before their execution results are also known

This isn’t breaking any interface with the fullnodes, and applications can still ask to get candidate transactions in the interface they used so far. But the latency here will be no better than “preconfirmed”.

SNIP-40 breaking changes

These breaking changes are described in more detail in SNIP 40, but their TLDR is rewritten here for your convenience

  • Although SNIP-40 increases maximum transaction size, a transaction valid before SNIP-40 could theoretically become too large to execute if it makes thousands of writes and is right near the threshold
  • Upgrading full nodes before 0.14.3 will be required to keep gas estimations aligned with SNIP-40 recommendations.

SNIP-36 breaking changes

The new keccak-supporting verifier within the Starknet gateway is incompatible with proofs generated under 0.14.2. Prover services that are integrated with SNIP-36 flows will need to be upgraded simultaneously with the version upgrade to remain operational

2

Thanks for the detailed writeup.

We are ready on our side for the upgrade.

3

Looks good, upgraded and running the latest versions on Sepolia and Main Net. Lets go!!

4

The following reflects the views of L2BEAT’s governance team, composed of @krst and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.

We tried to vote, but were unable to do so due to technical issues with Snapshot; that said, we would still like to share our thoughts on this proposal.

We are inclined to vote AGAINST.

As part of our diligence, we discussed this proposal internally with our research team, and our position reflects the combined assessment of L2BEAT’s governance and research teams.

We support the goal of improving Starknet’s latency and making fees more predictable, and we think parts of v0.14.3 move in the right direction.

Our main concern is with SNIP-35. The mechanism limits how quickly the minimum base fee can change, but it does not really prevent a majority of sequencers from gradually pushing fees away from the intended target. Since the collected fees go to sequencers, this creates a clear incentive issue, especially if Starknet moves toward a more decentralized sequencer set.

We would like to see stronger protocol-level constraints, better transparency around fee proposals, or a different incentive design before this is adopted on Mainnet.

Because of these concerns, we have decided to vote against the proposal.