Starknet v0.14.4 Prerelease Notes

🆙 Versions Upgrade
1

Starknet v0.14.4 Prerelease Notes

Starknet v0.14.4 is a small, mostly transparent version. It carries one new user-facing capability: proving block-sized transactions through the SNIP-36 flow. In addition, small cost-alignment changes to pricing, the removal of long-deprecated feeder gateway endpoints, and internal sequencer work that is invisible to users.

Upgrade dates

  • Testnet – 15 Sep 2026
  • Mainnet – 05 Oct 2026 (pending governance approval)

Changes

Proving full-size Starknet blocks with SNIP-36

Until now, the SNIP-36 client-side proving flow was limited to small virtual OS blocks. Starting v0.14.4, a proof may be generated for any SNOS-valid virtual block that contains a single transaction, does not use syscalls unsupported by the virtual OS, and would have fit inside a Starknet block gas-wise, up to 1.1B L2 gas.

This lets an application compress logic that would not fit in a regular transaction into a single proven one, and pay for it as a proof rather than as execution.

Two practical notes:

  • Large proofs are slower to generate. Expect up to 1–2 minutes, versus the 3–5 seconds typical of the current small-proof flow.
  • Large proofs use a separate prover entry point. The starknet_transaction_prover service continues to call the existing small-proof path, which stays optimized for privacy transactions. Generating a full-block proof means calling privacy_recursive_prove_large in the privacy-prove crate directly. It is not a configuration option on the service.

Updated pricing weights

v0.14.4 updates the gas weights the OS charges for several operations, following a review that found misalignments between what certain operations actually cost the sequencer and the network and what users are charged for them. The intent is cost alignment, not a fee increase. Based on the traffic during the last 3 months on mainnet, these changes have less than 1% effect on the pricing of the vast majority of the txs.

Deprecating old feeder gateway endpoints

The following feeder gateway endpoints are removed in v0.14.4:

  • call
  • get_storage_at
  • get_nonce
  • get_class_hash_at
  • get_code
  • get_full_contract

These endpoints have not been supported on new blocks for years and only continued to function on very old (roughly pre-0.12.3) blocks.

In addition, get_compiled_class_by_class_hash and get_class_by_hash change behavior: they no longer accept block_number as an input, and they may return results that are not part of the current Starknet state. They will return any class ever declared on Starknet, behaving as a static map.

Finally, all requests to get_preconfirmed_block must use the delta protocol. Requests without the delta-protocol flags are no longer served.

Transparent change: Committer migration to Apollo

The block committer moves from the centralized Python component and Aerospike fact storage into the Apollo sequencer processes.

v0.14.4 Breaking Changes

Proofs generated under 0.14.3 are rejected

The v0.14.4 verifier is not backward compatible with proofs generated under the 0.14.3 prover, and this version does not support running two prover versions in parallel. See the action items below for the upgrade procedure.

Feeder gateway endpoint removal

The six endpoints listed above (call, get_storage_at, get_nonce, get_class_hash_at, get_code, get_full_contract) are deprecated.

Class endpoints change behavior

get_compiled_class_by_class_hash and get_class_by_hash no longer accept block_number as an input, and may return classes that were not part of the state at any given block.

get_preconfirmed_block requires the delta-protocol flags

All requests to get_preconfirmed_block require the delta-protocol flags. Full nodes still on the old polling protocol must move to the flagged protocol before the upgrade.

Pricing weight changes

Transactions consume a different amount of L2 gas than they do under 0.14.3. Fee estimation must be run against a 0.14.4 node. Estimates carried over from 0.14.3 will be wrong for the affected operations.

v0.14.4 Action items

SNIP-36 prover upgrade: coordinated upgrade required

The v0.14.4 verifier is not backward compatible with proofs generated under 0.14.3, and this version does not support running two prover versions in parallel. Every operator of a SNIP-36 transaction prover must upgrade their prover during the same window in which the network is upgraded.

Consequence: expect a few minutes of downtime for private transactions during the prover upgrade window.

Full nodes

Anyone running a full node must upgrade to Pathfinder v0.24.0 and Juno v0.16.6 before the network upgrade.